5 oomd soln - vidyalankar coaching classesvidyalankar.org/.../computer/4_oomd_soln.pdfprelim...

0414/TY/Pre_Pap/2014/CP/Comp/OOMD_Soln 1

Vidyalankar 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.

1. (a)

Vidyala

nkar

Vidyalankar : 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 day-to-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

(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)

1. (a) Vidy

alank

ar

Prelim Question Paper Solution


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

1. (a)

Vidyala

nkar



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

1. (b)

Vidyala

nkar



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.

(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.

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.

1. (b)

2. (a) Vidy

alank

ar



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.

Figure

Color center position pen thickness pen type move select rotate display

1 Dimensional

orientation scale

0 Dimensional

1 Dimensional

orientation fill type scale fill

Point

display

Line

Endpoints

display

Arc

radius start angle arc angle

display

Spline

Control pts

display

Polygon

num of sides vertices display

Circle

diameter display rotate

Dimensionality

Fig.1 : Inheritance for graphic figures

Vidyala

nkar



Fig.: A Class Diagram

Following are the UML diagrams Structural diagrams 1) Class diagram

2. (b)

Student

Name Address Phone no Percentage

Engineering PCM Marks

Arts Medical PCB Marks CET Marks

Computer FY SY TY Display

Electronics FY SY TY Display

IT FY SY TY Display

Fig. 2

Vidyala

nkar



Fig. An Object Diagram

Fig: A Component Diagram

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 : 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 :

Vidyala

nkar



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

Vidyala

nkar



LIBRARY MANAGEMENT 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

2. (c) Registration

Request-Book

Check Availability

Issue Book

Accept Book

Calculate Fine

Collect Fine

Return Book

Refer Journal

Rafer Magazine

Update Database

Check Identity Student Librarian

<<e>>

<<e>>

<<e>>

<<e>> : extends

1 Liberian

empid Name

Display( )

<< Library >> Location : string

Display( )

Place Order

id

Bill( )

<< Book >>

id Name Author Purchase( )

<< Journal >>

id Name Publication

Purchase( )

<< Newspaper >>

id Name Publication

Purchase( )

<< Magazine >>

id Name Publication

Purchase( )

has>

1 *

Issue Book

Display( )

Ref. Book

Display( )

National

Display( )

International

Display( )

is a is a is a is a

3. (a) Vidy

alank

ar



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.

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.

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. ObjectOriented Software Engineering : Objectory

Object oriented software engineering (OOSE), also called Objectory, is a method of objectoriented development with the specific aim to fit the development of large, real time systems. The development process called usecase driven development, stresses that use cases involved in several phases of the development including analysis, design, and validation and testing. OOSE is an

3. (b)

Directory File File name

Fig.1 : A qualified association

Person Company Employee

Works-for

Employer

Fig. 2 : Role names for an association

Vidyala

nkar



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 (usecase) 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. 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.

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

Fig.: Jacobson’s Object Oriented Software Engineering

Usecase diagram

State transition diagram

Problem domain object diagram

Analysis diagram

Analysis model

Design model

Implementation model

Test model

Domain object model

Interaction Diagram

Uppercase diagram

Vidyala

nkar



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.

Vidyala

nkar



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.

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

College Branch Department

Staff Aggregation Part

Whole

Fig.1 : Aggregation and Association

Fig.3 : Recursive t

Fig.2 : Aggregation and Generalization

3. (c)

Vidyala

nkar



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.

(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.

3. (e)

3. (d)

Figure

Color center position pen thickness pen type move select rotate display

1 Dimensional

orientation scale

0 Dimensional

1 Dimensional

orientation fill type scale fill

Point

display

Line

Endpoints

display

Arc

radius start angle arc angle

display

Spline

Control pts

display

Polygon

num of sides vertices display

Circle

diameter display rotate

Dimensionality

Fig. : Inheritance for graphic figures

Vidyala

nkar



(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.

4. (a)

Vidyala

nkar



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

Vidyala

nkar



(ii) Class Diagram for Different Dimensional Figures on Window Screen (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

4. (a)

4. (a)

4. (a)

Vidyala

nkar



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. 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.

4. (b)

Vidyala

nkar



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.

Vidyala

nkar



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.

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 non-fixed multiplicity may be created after the composite itself, but once created they live and die with it.

UserGroup User Password + user + owner key

association viability

1

association

Vidyala

nkar



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.

4. (b)

Vidyala

nkar



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.

Vidyala

nkar



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.

Vidyala

nkar



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.

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 :

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. (a)

1 : log in

C1 : Customer S : Stock Broker by Securities Exchange

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

5. (b) Vidy

alank

ar



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.

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.

Release work order

Assign tasks

Reschedule

guard expression

[materials not ready]

branch

[materials ready]

Guard expression

Fig. 1 : Branching

Prepare for speech

Decompress

Synch mouth ( )

Gesture ( )

Cleanup

join Stream audio ( )

fork

Fig. 2: Forking

Vidyala

nkar



Activity diagram for Withdrawing money from ATM

5. (c)

Insert ATM Card

Enter Password

Verify Password

Select type of transaction

Password Correct

Enter Amount

Perform transaction

Withdraw money

Update database

Take the card

[No more transaction]

[More transaction]

[Password incorrect]

Vidyala

nkar



Class diagram for railway reservation system

6. (a)

Train Name

ID Category

engine type

Passenger Name Age

Gender add

Phone Book ( )

Railway Staff

Name Comp. ID

Scale Service

City

Schedule Day

Month Year

Departure time Arrival time delete ( ) add ( )

Booking Clerk Request Cancel Search Create

query ( ) Create add ( )

Administration Designation

add new data delete new data

query ( )

Server Name Search

Coach Serial no. Capacity

Class Category

add coach ( )

Ticket NO :

Source Destination

Display

Route Source

Destination Intermediate

stops add route ( )

delete route ( )

Consist of

Issued for

reason

Interact with

interacts

Makes

Follows

Vidyala

nkar



A diagram for online reservation system 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. Event An event is something that happens at a point. Every event has unique occurance. Event is a one-way transmission of information from one object to another.

6. (b)

State name

logging into system Searching for

train

successful

Selecting train date and class

successful

User

get information

Entering credit card details

Getting printed ticket

not available

Booking Confirmed available

Waiting

not available

Cancellation

Cancelled no vacancy

Ticket

Vidyala

nkar



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. Starting point denoted by a solid circle. Transition An arrow indicating the object to transition Event name / Action 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 :

6. (c)

[Guard condition]

end state

Class4

attribute1:int

operation1(args:type):void

Class5

<<stereotype>>

code

Class3

#attribute1:int

+operation 10:void Class2Role

Class2

+Class2()

AssociationClass

Interface Interface1

Class1

+operation10:void +operation20:void

Class3Role

Fig.1 : Class diagram

Vidyala

nkar



Fig. 2: Object diagram

Fig. 3: UseCase diagram

Fig. 4: State Chart Diagram

Vidyala

nkar



Fig. 5: Sequence diagrams

Fig.6: Activity diagram

Vidyala

nkar



Fig.7: Deployment diagram

Fig. 8 : Component diagram

Vidyala

nkar



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.

6. (e)

6. (d) HOSPITAL MANAGEMENT

Patient Hospital Management System

Request for form

Fill the form

Accepts medicine

Pay Bill Accept Bill

prescribes medicine

Doctor treats patient

Appoint patient

Updates date Base

Verify form

Accept form

form Handed overs to patient

patient goes to doctor

Updates Data of patients

Vidyala

nkar



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 Deployment Diagram

Fig: A Use Case Diagram

Vidyala

nkar



Fig.: Sequence Diagram

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.

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.

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.

Fig.: Collaboration Diagram Vidyala

nkar



Fig.: Statechart Diagram

Fig. Activity Diagrams

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.

Vidyala

nkar



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).

Vidyala

nkar



Fig. : Modeling an Embedded System

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.

Vidyala

nkar

5 oomd soln - vidyalankar coaching classesvidyalankar.org/.../computer/4_oomd_soln.pdfprelim...

Documents