Vidyalankar. T.Y. Diploma : Sem. VI [IF/CM] Object Oriented Modeling and Design Prelim Question Paper

Transcription

1 1. (a) T.Y. Diploma : Sem. VI [IF/CM] Object Oriented Modeling and Design Prelim Question Paper (i) Describe Booch Methodology It is a widely used object-oriented method that helps us design a system. It covers the analysis and design phases of an object oriented system. It starts with designing class and objects diagrams in the analysis phase and refines these diagrams in various steps. It consists of following diagrams: Class diagram State transition diagram Interaction diagram Object diagram Module diagram Process diagram The Booch Methodology prescribes a macro development process and micro development process: Macro development process: the macro process specifies a framework for the micro process and can take weeks or months to complete. The primary concern of the macro process is technical management of the system. The macro development process consists of the following steps: Conceptualization: during conceptualization, enlist core requirement of the system. One can decide a set of goals and develop a prototype to prove the concept. Analysis and development of the model: in this step one can use the class diagram to describe the roles and responsibilities of objects that are required in desired behavior of the system. Then one can use the object diagram or interaction diagram to describe behavior of the system in terms of scenarios. Design and create the system architecture: in the design phase, one can use the class diagram to decide what classes exist and how they relate to each other. Use object diagram to decide what mechanism is used to regulate how objects collaborate. Use module diagram to map out where each class and object should be declared. Use process diagram to determine to which processor to allocate a process. Also determine the schedule for multiple processes on each relevant-processor. Evolution or implementation: successively refine the system through much iteration. Produce a stream of software implementations where each of which is a refinement of prior one. Maintenance: make localized changes to the system to add new requirements and eliminate bugs. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 1

2 : T.Y. Diploma OOMD Micro development process: each micro development process has its own micro development processes. The micro process is a description of the dayto-day activities by a single or small group of software developers. The micro development process consists of the following steps: Identify classes and objects Identify class and object semantics Identify class and object relationships Identify class and object interfaces and implementation 1. (a) (ii) Explain Object Modeling Technique (OMT) Object Modeling Technique (OMT), includes four stages: 1. Analysis : starting from a statement of the problem, the analyst builds a model of the real-world situation showing its important properties. The analyst works with the requestor to understand the problem statement. The analysis model is a concise, precise abstraction of what the desired system must do, not how it will be done. A good model can be understood and criticized by application experts who are not programmers. The analysis model does not contain any implementation details. 2. System design : system designer makes high level decisions about the overall architecture. During system design, the target system is organized into subsystems based on both the analysis structure and the proposed architecture. The system designer decides what performance characteristics to optimize, choose a strategy of attacking the problem and make tentative resource allocations. 3. Object design : the object designer builds a design model based on the analysis model but contains implementation details. The designer adds details to the design model in accordance with the strategy established during system design. The focus of object design is the data structures and algorithms needed to implement each class. 4. Implementation: the object classes and relationships developed during object design are finally translated into a particular programming language, database or hardware implementation. During implementation, it is important to follow good software engineering practice so that traceability to the design is straightforward and so that the implemented system remains flexible and extensible. OMT includes three models to describe a system: 1. Object model 2. Dynamic model 3. Functional model (iii) There are four kinds of relationships in the UML: 1. Dependency : it is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label, as in figure below: 1. (a) /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

3 Prelim Question Paper Solution 1. (a) 2. Association : it is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names, as in figure below: 3. Generalization : it is a specialization / generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent). In this way, the child shares the structure and the behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent, as in figure below: 4. Realization : it is a semantic relationship between classifiers, wherein one classifier classifies a contract that another classifier guarantees to carry out. Realization relationships encounters in two places: between interfaces and the classes or components that realize them and between use cases and the collaborations that realize them. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship, as in figure below: (iv) The UML is largely process independent i.e. it is not tied to any particular software development life cycle. However, to get the most benefit from the UML, you should consider a process that is Use case driven Architecture centric Iterative and incremental Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing and for communicating among the stakeholders of the project Architecture centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing and evolving the system under development An interative process is one that involves managing a stream of executable release. An interactive is one that involves the continuous integration of the system's architecture to produce these releases, with each new release embodying incremental improvements over the other. Together, an iterative and incremental process is risk-driven, meaning that each new release is focused on attacking and reducing the most significant risks to the success of the project 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 3

4 : T.Y. Diploma OOMD 1. (b) The above 3 process i.e. use case driven, architecture-centric and iterative/incremental process can be broken into phases. A phase is the span of time between two major milestones of the process, when a well- 0 defined set of objectives are met, artifacts are completed and decisions are made whether to move into the next stage Fig.1 below shows, there are 4 phases in the SDLC: inception, elaboration, construction and transition Fig. 1 : Software development life cycle (i) Constraints are functional relationships between entities of an object model Constraint restricts the values that entities can assume e.g. employee's salary cannot exceed the salary of the employee's boss Notation: 1. Constraints are text (string) delimited by braces and positioned near the constrained entity 2. A dotted line connects multiple constrained entities. An arrow may be used to connect constrained entities. An arrow may be used to connect a constrained entity to the entity it depends on Constraints can be specified on an association such as multiplicity /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

5 Prelim Question Paper Solution The notation {ordered} is also a type of constraint at many end of an association that have an explicit order which is to be preserved e.g. The chair of a committee must be a member of the committee. A chair of association is a subset of member of association. 1. (b) (ii) A model is an abstract representation of a system, constructed to understand system prior to building or modifying it. Building a model for a software system prior to its construction is like preparing a blueprint for building a large building. Model includes fundamental modeling concepts and semantics, notations and guidelines. Models help us to visualize a system as it is or as we want it to be. It permits us to specify the structure or behavior of a system. Models give us a template that guides us in constructing a system. It documents the decisions we have made. Four principles of modeling: 1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped: it means choose your model well. The right models will brilliantly illuminate the most wicked development problems. The wrong models will mislead you, causing you to focus on irrelevant issues. 2. Every model may be expressed at different levels of precision: all the users and developers both may visualize a system at different levels of details at different times. 3. The best models are connected to reality: in object oriented systems, it is possible to connect all the nearly independent views of a system into one semantic whole. 4. No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models: to understand the architecture of a system, you need multiple interlocking views such as use case view, design view, process view, implementation view and deployment view. Each of these views may have structural as well as behavioral aspects. Together these views represent a system. 2. (a) GENERALISATION AND INHERITANCE Generalization and Inheritance are powerful techniques of abstraction. By using these two concepts we can classify the similarities among the class by preserving their differences. For example, each price equipment has manufacturer, weight and cost. Pumps also have suction pressure and flow rate. Tanks also have volume and pressure. We would like to define equipment features just once, and then add details for pump, tank and other equipment types. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 5

6 : T.Y. Diploma OOMD Generalization means combining common features in a one class which is superclass and other classes will have dissimilarities which are called subclasses. Inheritance means the mechanism by which more specific elements incorporate the structure and behavior or more general elements. Each subclass inherits the features of superclass. For example, parents is a superclass and child is subclass then we can say that child inherits the features of parents. In other words child looks like his mother. The notation for generalization is a triangle connecting a superclass to its subclasses. Figure 2 shows inheritance for graphic figures. Here, figure is superclass which has attributes like colour, centre position, pen thickness, pen type which are common for all classes and operations like move, select, rotate, display are common for all classes. Figure class is having subclasses 0 Dimensional, 1 Dimensional and 2 Dimensional. These subclasses are further having subclass as point for 0 Dimensional. So we can say that point class inherits figure class. Point display Figure Color center position pen thickness pen type move select rotate display 0 Dimensional 1 Dimensional 1 Dimensional Line Endpoints display orientation scale Arc radius start angle arc angle display Dimensionality Spline Control pts display orientation fill type scale fill Fig.1 : Inheritance for graphic figures Polygon num of sides vertices display Circle diameter display rotate /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

7 Prelim Question Paper Solution Student Name Address Phone no Percentage 2. (b) Arts Computer FY SY TY Display Engineering PCM Marks Electronics FY SY TY Display Following are the UML diagrams Structural diagrams 1) Class diagram Fig. 2 IT FY SY TY Display Medical PCB Marks CET Marks Fig.: A Class Diagram 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 7

8 : T.Y. Diploma OOMD A class diagram shows a set of classes interfaces and collaborations and their relationships. Class diagrams are the most common diagram found in modeling object-oriented systems. We can use class diagrams to illustrate the static design view of a system. Class diagram that include active classes are used to address the static process view of a system. 2) Object diagram : Fig. An Object Diagram An object diagram shows a set of objects and their relationships. We use object diagrams to illustrate data structures, the static snapshots of instances of the things found in class diagrams. Object diagrams address the static design view or static process view of a system just as do class diagrams, but from the perspective of real or prototypical cases. 3) Component diagram : Fig: A Component Diagram /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

9 Prelim Question Paper Solution A component diagram shows a set of components and their relationships. We use component diagrams to illustrate the static implementation view of a system. Component diagrams are related to class diagrams in that a component typically maps to one or more classes, interfaces or collaborations. (4) Deployment diagram : A deployment diagram shows a set of nodes and their relationships. We use deployment diagrams to illustrate the static deployment view of an architecture. Deployment diagrams are related to component diagrams in that a node typically encloses one or more components. Fig: A Deployment Diagram 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 9

10 : T.Y. Diploma OOMD 2. (c) LIBRARY MANAGEMENT Student Registration Check Identity Request-Book Check Availability Librarian <<e>> <<e>> : extends Place Liberian empid Name Display( ) Order id Bill( ) Issue Book Display( ) 1 Issue Book Accept Book Calculate Fine <<e>> Collect Fine Return Book Refer Journal Rafer Magazine Update Database << Library >> Location : string << Book >> id Name Author Purchase( ) Display( ) <<e>> << Journal >> id Name Publication Purchase( ) << Newspaper >> id Name Publication Purchase( ) << Magazine >> id Name Publication Purchase( ) Qualification The qualifier is a special attribute that reduced the effective multiplicity of an association. Figure 1 shows example of qualified association. Normally, directory has many files. A file may only belong to a single directory. Within a directory, the file name is unique. In figure 1 directory and file are object classes and file name is the qualifier. Directory + Filename identifies a file. So file corresponds to directory has> 1 * is a is a is a is a Ref. Book Display( ) National Display( ) International Display( ) 3. (a) /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

11 3. (b) Prelim Question Paper Solution and filename. Thus, qualification reduces the effective multiplicity of this association from one-to-many to one-to-one. A qualifier is drawn as a small box on the end of association line near to the class which it qualifies. In figure 1, Directory + Filename yields a file, therefore filename is listed in a box contiguous to directory. Directory File name Fig.1 : A qualified association Some points regarding qualification : It improves semantic accuracy. It increases visibility of links. Model becomes more informative. It is useful for giving names in real problems. It resolves context (confusion) within names. It reduces multiplicity from many to one. It partitions a set of related objects into disjoint sublets. Role Names A role is one end of association. A role name is a name written at one end of association. Figure 2 shows role names for an association. A person assumes the role of employee with respect to a company and a company assumes the role of employer with respect to a person. A role name is written next to the association line near the class that plays the role. Employee Employer Person Company Works-for Some points regarding role names: Role names are necessary for association between two objects of the same class. It is useful to distinguish between two: associations of same air of classes. All role names on the far end of associations attached to the class must be unique. It is really a derived attribute of the source class. So it should be unique. No role name should be same as an attribute name of the source class. Role name do not represent derived attributes of the participating classes. Object Oriented Software Engineering : Objectory Object oriented software engineering (OOSE), also called Objectory, is a method of object oriented development with the specific aim to fit the development of large, real time systems. The development process called use case driven development, stresses that use cases involved in several phases of the development including analysis, design, and validation and testing. OOSE is an File Fig. 2 : Role names for an association 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 11

12 : T.Y. Diploma OOMD approach to object oriented analysis and design that centres on understanding the ways in which a system actually is used. The method produces systems that are both usable and more robust, adapting more easily to changing usage. Objectory is built around several different models : Use case model : Defines the outside (actors) and inside (use case) of the system s behavior. Domain object model : The objects of the real world are mapped into this object model. Analysis object model : Presents how the source code (implementation) should be carried out and written. Implementation model : Represents the implementation of the system. Test model : Constitutes the test plans, specification and reports. Domain object model Problem domain object diagram Use case diagram Analysis model Analysis diagram State transition diagram Upper case diagram Design model Implementation model Interaction Diagram Fig.: Jacobson s Object Oriented Software Engineering Jacobson s Analysis Model Jacobson s Analysis Model defines three types of objects in a system : interface objects, entity objects, and control objects. Entity object Information about an entity object is stored after a use case is completed. Control object A control object illustrates functionality that is not contained in any other object in the system. Interface object Interface objects interact directly with the environment. Test model Jacobson s Design Model : Jacobson s design model shows how the system behaves. There are two types of diagrams under this model : interaction diagrams and state transition diagrams. Interaction diagrams are similar to UML s sequence diagrams. State /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

13 Prelim Question Paper Solution transition diagrams are like UML state chart diagrams, but Jacobson also employs a number of unique symbols listed below. Send message Receive message Return message Send message Receive signal Perform task Decision Label Advantages : The three object categories in OOSE : entity interface and control effectively integrate the interfaces into modeling. Its analysis in terms of use cases is original and brings together the modular and incremental aspects of system. In addition, that OOSE development cycle is the most complete. Disadvantages : A criticism for this approach is that the dual approach, systemic and structural, is used without any clear statement of how to map specifications from one to the other. Similarly, the construction rules for the design level are not clear, especially as far as the grouping of objects into blocks and the choice of implementation of these objects are concerned. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 13

14 : T.Y. Diploma OOMD 3. (c) Recursive Aggregates Aggregation can be fixed, variable or recursive. A fixed aggregate has a fixed structure, the member and types of subparts are predefined. A variable aggregate has a finite number of levels, but the number of parts may vary. A recursive aggregate contains directly or indirectly an instance of the same kind of aggregate, the number of potential levels is unlimited. The lamp in figure 2 has a fixed aggregate structure. In figure 1, the college is a variable aggregate with a two level tree structure. There are many branches in college and departments per branch. Fig. 3 shows the example of recursive aggregate. Whole College Branch Department Staff Aggregation Fig.3 : Recursive t In figure 3, a computer program is an aggregation of blocks, with optionally recursive compound statements the recursion terminates with sample statements. Blocks can be nested to arbitrary depth. figure 3 illustrates the usual form of a recursive aggregate, a superclass and two subclasses, one of which is Part Fig.1 : Aggregation and Association Fig.2 : Aggregation and Generalization /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

15 Prelim Question Paper Solution in an intermediate node of the aggregate and one of which is a terminal node of the aggregate. The intermediate node is an assembly of instances of the abstract superclass. 3. (d) Figure 3. (e) Point display Color center position pen thickness pen type move select rotate display 0 Dimensional 1 Dimensional 1 Dimensional Line Endpoints display orientation scale Arc radius start angle arc angle display Dimensionality Spline Control pts display Fig. : Inheritance for graphic figures orientation fill type scale fill Polygon num of sides vertices display Circle diameter display rotate (i) Object An object is a concept, abstraction or thing with crisp boundaries and meaning for the problem. Object is an instance of a class. e.g. abc, top window are objects (ii) Constraints Constraints are functional relationship between entities of an object model constraints restrics the values that entity can assume. (iii) Multiplicity Multiplicity is often described being one or many. Multiplicity shows how many instances of one class may relate to single instance of an associated class. Multiplicity shows the number of related objects. (iv) Message Message represents procedure calls. Messages are used in interacting with different object. Messages are sent from one object to another object. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 15

16 : T.Y. Diploma OOMD 4. (a) (i) DYNAMIC MODEL Different steps for building the Dynamic Model : i) Prepare scenarios of typical dialogues in the system. A scenario consists of sequences of events, actors. First scenarios for normal cases have to be prepared, followed by scenarios for special cases as omitted input sequences, maximum and minimum values, repeated values and error conditions. ii) Identify the events from the prepared scenarios. Events may be signals, inputs, decisions, interrupts, transitions and actions to or from users or devices. iii) Each event must be allocated to the object classes that send and receives it. Sender and Receiver can be the same object. iv) For each class with nontrivial dynamic behaviour, a state diagram has to be made to show the events that these objects send and receive. First the state diagrams for the normal events of an object have to be drawn then the boundary and special cases can be added. v) Matching events between objects can check the completeness and consistency of the state diagrams. Every event must have a sender and receiver, and states must have predecessors and successors, unless they are starting or termination states. Sample Dynamic Model These UMLs five behavioural diagrams are used to visualize specify, construct, and document the dynamic aspects of a system. We can think of the dynamic aspects of a system as representing its changing parts. Just as the dynamic aspects of a house \ encompass airflow and traffic through the rooms of a house. The UMLs behavioural diagrams are roughly organized around the major ways you can model the dynamics of a system : Use case diagram (Organizes the behaviour or the system) Sequence diagram (Focused on the time ordering of the messages) Collaboration diagram (Focused on the structural organization of objects that send and receive messages) State chart diagram (Focused on the changing state of a system driven by events) Activity diagram (Focused on the flow of control from activity to activity) Example: Dynamic/Behavioural modeling through the control flow and state chart diagram for the photocopier software system is explained below /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

17 Prelim Question Paper Solution A "state" is any observable mode of behaviour. For example, states for a monitoring and control system for pressure vessel might be "monitoring state", "alarm state", "pressure release state", and so on. Each of these states represents a mode of behaviour of the system, "A state transition diagram indicates how the system moves from state to state." Fig. : Control Flow for Photocopier Software. Fig. : State Transition Diagram for Photocopier Software 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 17

18 : T.Y. Diploma OOMD 4. (a) (ii) Class Diagram for Different Dimensional Figures on Window Screen 4. (a) 4. (a) (iii) Realization : it is a semantic relationship between classifiers, wherein one classifier classifies a contract that another classifier guarantees to carry out. Realization relationships encounters in two places: between interfaces and the classes or components that realize them and between use cases and the collaborations that realize them. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship, as in figure below: (iv) MULTIPLE INHERITANCES A class can inherit features of two or more classes, this is known as multiple inheritance. In other words, multiple inheritance permits a class to have more than one superclass and to inherit features from all parents. This allows us to combine features of several existing classes as a starting point for defining new classes. Multiple inheritance permits mixing of Information from two or more sources. This generalization form is more complex compared to single inheritance which restricts the class hierarchy to a tree. The advantage of /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

19 Prelim Question Paper Solution multiple inheritances is greater power specifying classes and an increased opportunity for reuse. It brings object modeling closer to the way people link. The disadvantage of multiple inheritance is a loss of conceptual and implementation simplicity. 4. (b) Concepts and Definition A class may inherit features from more than one superclass. A class with more than one superclass is called a join class. A feature from the same ancestor class found along more than one path is inherited only once, it is the same feature. Conflicts among parallel definitions create ambiguities that must be resolved in implementations. In practice, such conflicts should be avoided or explicitly resolved to avoid ambiguities or misunderstandings, even if a particular language provides a priority rules for resolving conflicts. Following example with figure gives the proper understanding of multiple inheritances. Fig. : Multiple inheritance. Here, amphibious vehicle derives its features from two different classes i.e. land vehicle and water vehicle. Amphibious vehicle is a join class. (i) 1. Name : an association can have a name, and you use that name to describe the nature of the relationship. You can give a direction to the name by providing a direction triangle that point in the direction you intend to read the name. 2. Role : when a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the near end of the association presents to the class at the other end of the association. You can explicitly name the role a class plays in an association. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 19

20 : T.Y. Diploma OOMD 3. Multiplicity : an association represents a structural relationship among objects. "How many" is called the multiplicity of an association's role, and is written as an expression that evaluates to a range of values or an explicit value. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). 4. Aggregation: a "whole / part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole has objects of the part. 5. Navigation: navigating from objects of one kind to objects of the other kind. Association is bidirectional. You can explicitly represent the direction of navigation by adorning an association with an arrowhead pointing to the direction of traversal /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

21 Prelim Question Paper Solution 6. Visibility: given an association between two classes, objects of one class can see and navigate to objects of the other, unless otherwise restricted by an explicit statement of navigation. In the UML, you can specify three levels of visibility for an association end. The visibility of a role is public. Private visibility indicates that objects at that end are not accessible to any objects outside the association; protected visibility indicates that objects at that end are not accessible to any objects outside the association, except for children of the other end. association 1 UserGroup User Password + user + owner key association viability 7. Qualification: a qualifier, which is an association attribute whose values partition the set of objects related to an object across an association. You render a qualifier as a small rectangle attached to the end of an association, placing the attributes in the rectangle. 8. Interface specifier: an interface is a collection of operations that are used to specify a service of a class or a component; every class may realize many interfaces. Collectively, the interfaces realized by a class represent a complete specification of the behavior of that class. 9. Composition: composition is a form of aggregation, with strong ownership and coincident lifetime as part of the whole. Parts with nonfixed multiplicity may be created after the composite itself, but once created they live and die with it. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 21

22 : T.Y. Diploma OOMD 4. (b) 10. Association classes: in an association between two classes, the association itself might have properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties. You render an association class as a class symbol attached by a dashed line to an association. 11. Constraints: Constraints are functional relationships between entities of an object model. Constraint restricts the values that entities can assume. (ii) Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. 1. Class: it is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

23 Prelim Question Paper Solution 2. Interface: it is a collection of operations that specify a service of a class or component. Graphically, an interface is rendered as a circle together with its name. 3. Collaboration: it.defines an interaction and is a society of roles and other elements hat work together to provide some cooperative behavior that's bigger than the sum of all the elements. Graphically, collaboration is rendered as an ellipse with dashed liens, usually including only its name. 4. Use case: it is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name. 5. Active class: it a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 23

24 : T.Y. Diploma OOMD 6. Component: it is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs, usually including only its name. 7. Node: it is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name. 8. Interaction: it is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. An interaction involves a number of other elements, including messages, action sequences, and links. Graphically, a message is rendered as a directed line, almost always including the name of its operation. 9. State machine: it is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates, if any /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

25 Prelim Question Paper Solution 10. Package: it is a general-purpose mechanism for organizing elements into groups, structural things, behavioral things, and even other grouping things may be placed in a package. Graphically, a package is rendered as a tabbed folder, usually including only its name and sometimes, its contents. 5. (a) 11. Annotational things: they are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate, and remark about any element in a model. There is one primary kind of annotational thing, called a note. Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment. Sequence diagram for placing purchase order : C 1 : Customer S : Stock Broker by Securities Exchange 1 : log in 2 : Secure Communication 3 : Display profile 4 : Enter purchase data 5 : Request confirmation 6 : Confirm purchase 7 : Display order 9 : Log out 2 : Insure Couch 3 : Display good bye 8 : Place order Branching Simple, sequential transitions are common, but they aren t the only kind of path you ll need to model a flow of control. As in a flowchart, you can include a branch, which specifies alternate paths taken based on some Boolean expression. As Figure 1 shows, you represent a branch as a diamond. A branch may have one incoming transition and two or more outgoing ones. On each outgoing transition, you place a Boolean expression, which is evaluated only 5. (b) 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 25

26 : T.Y. Diploma OOMD once on entering the branch. Across all these outgoing transitions, guards should not overlap (otherwise, the flow of control would be ambiguous), but they should cover all possibilities (otherwise, the flow of control would freeze) As a convenience, you can use the keyword else to mark one outgoing transition, representing the path taken if no other guard expression evaluates to true. branch Guard expression [materials ready] Release work order Assign tasks [materials not ready] Reschedule guard expression You can achieve the effect of iteration by using one action state that sets the value of an iterator, another action state that increments the iterator, and a branch that evaluates if the iteration is finished. Forking : As Figure 2 shows, a fork represents the splitting of a single flow of control into two or more concurrent flows of control. A fork may have one incoming transition and two or more outgoing transitions, each of which represents an independent flow of control. Below the fork, the activities associated with each of these paths continues in parallel. Conceptually, the activities of each of these flows are truly concurrent, although, in a running system, these flows may be either truly concurrent (in the case of a system deployed across multiple nodes) or sequential yet interleaved (in the case of a system deployed across one node), thus giving only the illusion of true concurrency. Prepare for speech Fig. 1 : Branching Decompress Gesture ( ) Synch mouth ( ) Stream audio ( ) fork join Cleanup Fig. 2: Forking /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

27 Prelim Question Paper Solution 5. (c) Activity diagram for Withdrawing money from ATM Password Correct [No more transaction] Withdraw money Insert ATM Card Enter Password Verify Password Select type of transaction Enter Amount Perform transaction Take the card [Password incorrect] Update database [More transaction] 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 27

28 : T.Y. Diploma OOMD 6. (a) Class diagram for railway reservation system Passenger Name Age Gender add Phone Book ( ) interacts Coach Serial no. Capacity Class Category add coach ( ) Booking Clerk Request Cancel Search Create query ( ) Create add ( ) Consist of Railway Staff Name Comp. ID Scale Service City Ticket NO : Source Destination Display Train Name ID Category engine type Makes Administration Designation add new data delete new data query ( ) Issued for Follows reason Schedule Day Month Year Departure time Arrival time delete ( ) add ( ) Interact with Route Source Destination Intermediate stops add route ( ) delete route ( ) Server Name Search /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

29 A diagram for online reservation system Ticket available Booking Confirmed User logging into system successful Entering credit card details Waiting not available no vacancy Selecting train date and class Cancelled successful get information not available Getting printed ticket Prelim Question Paper Solution 6. (b) State chart diagram It help to understand dynamic behavior of system. In this we can focus on the event-order behavior of an object. It is useful in modeling lifetime of an object or behavior of object throughout life time. States A state is a condition or situation during the life of an object during which it satisfy some condition, perform some activity, or wait for some event. Object remain in sate for a finite amount of time. It is value of attribute of object at particular instant of time. State name Event An event is something that happens at a point. Cancellation Searching for train Every event has unique occurance. Event is a one-way transmission of information from one object to another. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 29

30 : T.Y. Diploma OOMD An event does not have duration. An object sending an event to another may expect a reply but that reply is a separate event. It is activity due to which there is change in state of object. 6. (c) Starting point denoted by a solid circle. Transition An arrow indicating the object to transition Event name / Action [Guard condition] end state from one state to another Unified Modeling Language (UML) and OMG s Model driven Architecture (MDA): The UA (Unified Approach) uses the UML to describe the model and analysis and design phases of system development. The unified modeling language was developed by the joint efforts of the leading objects technologies Graddy Booch, Ivar Jacobson, and James Rumbaugh with contributions from many others. The UML merges the best of notations used by the three most popular analysis and design methodologies: Booch s methodology, Jacobson et al. s object modeling technique. The UML is becoming the universal language for modeling systems; it is intended to be used to express models of many different ways. The UML has become the standard notation for object oriented modeling system. It is an evolving notation that still is under development. The UML notations are as follows : Class3 #attribute1:int +operation 10:void code Interface Interface1 Class1 +operation10:void +operation20:void AssociationClass Class2 Class3Role Class2Role +Class2() <<stereotype>> Class5 Class4 attribute1:int operation1(args:type):void Fig.1 : Class diagram /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

31 Prelim Question Paper Solution Fig. 2: Object diagram Fig. 3: Use Case diagram Fig. 4: State Chart Diagram 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 31

32 : T.Y. Diploma OOMD Fig. 5: Sequence diagrams Fig.6: Activity diagram /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

33 Prelim Question Paper Solution Fig.7: Deployment diagram Fig. 8 : Component diagram 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 33

34 : T.Y. Diploma OOMD 6. (d) HOSPITAL MANAGEMENT Patient Hospital Management System Request for form Fill the form patient goes to doctor Accepts medicine Pay Bill form Handed overs to patient Accept form Verify form Updates date Base Appoint patient Doctor treats patient Updates Data of patients prescribes medicine Accept Bill 6. (e) Deployment diagram : A deployment diagram shows a set of nodes and their relationships. We use deployment diagrams to illustrate the static deployment view of an architecture. Deployment diagrams are related to component diagrams in that a node typically encloses one or more components /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

35 Prelim Question Paper Solution Fig: A Deployment Diagram Behavioral Diagrams : i) Use case diagram: A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. We apply use case diagrams to illustrate the static use case view of a system. Use case diagrams are especially important in organizing and modeling the behavior of a system. Interaction diagram is the collective name given to sequence diagrams and collaboration diagrams. All sequence diagrams and collaborations are interaction diagrams, and an interaction diagram is either a sequence diagram or a collaboration diagram. Fig: A Use Case Diagram 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 35

36 : T.Y. Diploma OOMD ii) Sequence diagram : A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. A sequence diagram shows a set of objects and the messages sent and received by those objects. The objects are typically named or anonymous instances of classes, but may also represent instances of other things, such as collaborations, components and nodes. We use sequence diagram to illustrate the dynamic view of a system. Fig.: Sequence Diagram iii) Collaboration diagram : A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. A collaboration diagram shows a set of objects, links among those objects, and messages sent and received by those objects. The objects are typically named or anonymous instances of classes, but may also represent instances of other things, such as collaborations, components, and nodes. You use collaboration diagrams to illustrate the dynamic view of a system. Fig.: Collaboration Diagram iv) Statechart diagram : A state chart diagram shows a state machine, consisting of states, transitions, events and activities. We use statechart diagrams to illustrate the dynamic view of a system. They are especially important in modeling the behaviour of an interface, class or collaboration. Statechart diagrams emphasize the event ordered behaviour of an object, which is especially useful in modeling reactive systems /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

37 Prelim Question Paper Solution Fig.: Statechart Diagram v) Activity Diagram : An activity diagram shows the flow from activity to activity within a system. An activity shows a set of activities, the sequential or branching flow from activity to activity and objects that act and are acted upon. We use activity diagrams are especially important in modeling the function of a system. Activity diagrams emphasize the flow of control among objects. Fig. Activity Diagrams 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 37

38 : T.Y. Diploma OOMD Deployment Diagram A deployment diagram shows a set of nodes and their relationships. You use deployment diagrams to illustrate the static deployment view of an architecture. Deployment diagrams are related to component diagrams in that a node typically encloses one or more components. A deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them. Graphically, a deployment diagram is a collection of vertices and arcs. Common Properties A deployment diagram is just a special kind of diagram and shares the same common properties as all other diagrams- a name and graphical contents that are a projection into a model. What distinguishes a deployment diagram from all other kinds of diagrams is its particular content. Contents Deployment diagrams commonly contain Nodes Dependency and association relationships Like all other diagrams, deployment diagrams may contain notes and constraints. Deployment diagrams may also contain components, each of which must live on some node. Deployment diagrams may also contain packages or sub-systems, both of which are used to group elements of your model into larger chunks. Sometimes, you ll want to place instances in your deployment diagrams, as well, especially when you want to visualize one instance of a family of hardware topologies. Deployment diagram for Embedded System:- Modeling an Embedded System Developing an embedded system is far more than a software problem. You have to manage the physical world in which there are moving parts that break and in which signals are noisy and behavior is nonlinear. When you model such a system, you have to take into account its interface with the real world, and that means reasoning about unusual devices, as well as nodes. Deployment diagrams are useful in facilitating the communication between your project s hardware engineers and software developers. By using nodes that are stereotyped to look like familiar devices, you can create diagrams that are understandable by both groups. Deployment diagrams are also helpful in reasoning about hardware/software trade-offs. You ll use deployment diagrams to visualize, specify, construct, and document your system engineering decisions. To model an embedded system, Identify the devices and nodes that are unique to your system. Provide visual cues, especially for unusual devices, by using the UML s extensibility mechanisms to define system-specific stereotypes with appropriate icons. At the very least, you ll want to distinguish processors (which contain software components) and devices (which, at that level of abstraction, don t directly contain software) /TY/Pre_Pap/2014/CP/Comp/OOMD_Soln

39 Fig. : Modeling an Embedded System Prelim Question Paper Solution Model the relationships among these processors and devices in a deployment diagram. Similarly, specify the relationship between the components in your system s implementation view and the nodes in your system s deployment view. As necessary, expand on any intelligent devices by modeling their structure with a more detailed deployment diagram. For example, Figure shows the hardware for a simple autonomous robot. You ll find one node (Pentium motherboard) stereotyped as a processor. Surrounding this node are eight devices, each stereotyped as a device and rendered with an icon that offers a clear visual cue to its real-world equivalent. 0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 39