END TERM EXAMINATION- Sample Paper (2) FORTH SEMESTER [MCA] Code: MCA208 Time: 3 Hours Subject: Object-Oriented Analysis and Design Maximum Marks: 60 Note: Attempt five questions including Q.no. 1 which is compulsory. Select one question from each unit. Q1 (a) Attempt the following:- i. (2 x 10 = 20) What is the Object Modeling Techniques (OMT).. The object-modeling technique (OMT) is an object modeling approach for software modeling and designing. It was developed around 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-oriented systems and to support object-oriented programming. Describes Object model or static structure of the system. OMT was developed as an approach to software development. The purposes of modeling according to Rumbaugh are: • Testing physical entities before building them (simulation), • Communication with customers, • Visualization (alternative presentation of information), and • Reduction of complexity. OMT has proposed three main types of models: • Object Model • Dynamic Model • Functional Model ii. What is the role of Swim lanes & Guard condition in Activity diagram. Swimlanes: • Swimlanes (or activity partitions) indicate where activities take place.
• • Swimlanes can also be used to identify areas at the technology level where activities are carried out Swimlanes allow the partition an activity diagram so that parts of it appear in the swimlane relevant to that element in the partition Guard Conditions: You can add a guard condition to an activity edge between two nodes, where the guard condition defines a condition that must be satisfied before the target activity node can be invoked. You can define the guard condition in the following ways: • • name [guard condition] - The guard condition is created and is assigned a name. [guard conditon] - The guard condition is created, but is not assigned a unique name. In the following figure, one activity node called OpaqueAction is connected to a second activity node, called OpaqueAction2. A guard condition, called Guard1, specifies that the value of g coming from OpaqueAction must be greater than 10 for OpaqueAction2 to be invoked. iii. Explain the different among Bidirectional, Unidirectional & Reflexive Association. An association is a relationship between two classes represented by a solid line. Associations are bi-directional by default, so both classes know about each other and about the relationship between them. Either end of the line can have a role name and multiplicity. In the example, Student has the role of "tenant" in relation to Apartment and Apartment has the role of "accommodation" in relation to Student. Also, any instance of Apartment can be associated with up to four students and any student could be associated with 0 or 1 Apartment (a student either has an apartment to live in or does not). Associations can also be unidirectional, where one class knows about the other class and the relationship but the other class does not. Such associations require an open arrowhead to point to the class that is known and only the known class can have a role name and multiplicity. In the
example, the Customer class knows about any number of products purchased but the Product class knows nothing about any customer. The multiplicity "0..*" means zero or more. An alternative to using role names is to provide a single name for an association centered between the two classes. A direction indicator can also be used to show the direction of the name, but is not necessary if the direction is obvious: An association can also link a class to itself. Such an association is reflexive: iv. Compare OOAD & SSAD. SSAD (Structured Analysis): In Structured Analysis, the focus is only on process and procedures. Modeling techniques used in it are DFD(Data Flow Diagram), Flowcharts etc. This approach is old and is not preferred. OOAD (Object Oriented Analysis ): Whereas in Object Oriented Analysis, the focus is more on capturing the real world objects in the current scenario that are of importance to the system. It stresses more on data structure and less on procedural structure. Without actually identifying objects, what are you going to interact with, and whose state will you change. In this approach, objects are identified, their relationships among each other, possible states that each object can be in, and finally how all objects collaborate with each other to achieve a broader system goal are identified. v. Explain the term OORASS & HOOD.
The Object Oriented Role Analysis and Modeling (OOram) is a method, based on the concept of role, for performing object-oriented modeling. Originally (1989) coined Object Oriented Role Analysis, Synthesis and Structuring (OORASS), the method focuses on describing patterns of interaction without connecting the interaction to particular objects/instances. OOram was originally developed by Trygve Reenskaug (1996), a professor at the University of Oslo and the founder of the Norwegian IT company Taskon. HOOD: Hierarchical Object-Oriented Design (HOOD) has been developed for the European Space Agency as a design/notation method for Ada. Robinson introduces it in this way: "The top-down hierarchical decomposition approach is not new. After all, this is the method used with data flow diagrams starting from a context diagram which shows all the external interfaces with one central process. This process is then decomposed into other processes with data flows and control flows interacting between them, with consistency checks between levels. In the same way, the purpose of HOOD is to develop the design as a set of objects which together provide the functionality of the program." The phases can be summarized as follows: • • • • Problem definition. o Statement of the problem - the designer states the problem in correct sentences which provides: o Analysis and structuring of requirement data Development of solution strategy. Formalization of the strategy. o Objet identification. o Operation identification. o Grouping objects and operations (object operation table). o Graphical description. o Justification of design decisions. Formalization of the solution. vi. Discuss different goals of UML. A picture is worth a thousand words, this absolutely fits while discussing about UML. Object oriented concepts were introduced much earlier than UML. So at that time there were no standard methodologies to organize and consolidate the object oriented development. At that point of time UML came into picture. There are a number of goals for developing UML but the most important is to define some general purpose modeling language which all modelers can use and also it needs to be made simple to understand and use.