CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

STAFF NAME: E.LAVANYA CLASS: III/CSE SEM: V

SUBJECT CODE: CS8592 SUBJECT NAME: OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT III- DYNAMIC AND IMPLEMENTATION UML DIAGRAMS
Dynamic Diagrams – UML interaction diagrams - System sequence diagram – Collaboration diagram –
When to use Communication Diagrams - State machine diagram and Modelling –When to use State
Diagrams - Activity diagram – When to use activity diagrams
Implementation Diagrams - UML package diagram - When to use package diagrams - Component and
Deployment Diagrams – When to use Component and Deployment diagrams
PART – A
1. What is meant by System Sequence Diagrams? (APRIL/MAY 2011) (MAY/JUNE 2012)
A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case,
the events that external actors generate their order, and inter-system events. Sequence Diagrams are an
easy way of describing the behavior of a system by viewing the interaction between the system and its
environment. All systems are treated as a black box; the emphasis of the diagram is events that cross the
system boundary from actors to systems.
Uses:
1. To investigate and define system behaviour before proceeding with a detailed design of how a
software application will work.
2. To know what events are coming into our system, so that software can be designed to handle these
events and execute a response.
2. What is meant by System Behavior? (NOV/DEC 2015)
System behavior is a description of what a system does, without explaining how it does it. One
Part of that description is a system sequence diagram. Other parts include the Use cases, and
system contracts.
3. What is meant by Inter-System SSDs?
SSDs can also be used to illustrate collaborations between systems, such as between the Next
Gen POS and the external credit payment authorizer. However, this is deferred until a later iteration in
the case study, since this iteration does not include remote systems collaboration.
4. Define System Events and the System Boundary.
To identify system events, it is necessary to be clear on the choice of system boundary, as
discussed in the prior chapter on use cases. For the purposes of software development, the system
boundary is usually chosen to be the software system itself; in this context, a system event is an external
event that directly stimulates the software.
5. How to Naming System Events and Operations?
System events (and their associated system operations) should be expressed at the level of intent
rather than in terms of the physical input medium or interface widget level.
It also improves clarity to start the name of a system event with a verb Thus "enter item" is better
than "scan" (that is, laser scan) because it captures the intent of the operation while remaining abstract
and noncommittal with respect to design choices about what interface is used to capture the system
event.
6. Mention the purpose of drawing SSD.
1. To investigate and define system behavior (black box) before proceeding with a detailed design
of how a software application will work.
2. To know what events are coming into our system, so that software can be designed to handle
these events (from mouse, keyboard or another system) and execute a response.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 1
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
7. What are the three events that affect the software system?
 External Events from actors (humans or computers).
 Timer events.
 Faults or Exceptions.
8. What is the relationship between sequence diagram & use cases?
 Sequence Diagrams demonstrate the behavior of objects in a use case by describing the
objects and the messages they pass.
 Sequence Diagram can be drawn for each use case Scenario.

9. What are the Elements in SSD?

 Operation name
 Parameters
 Return Data

10. How to explain SSD’s within the UP?

 SSD’s are part of the use Case Model – a visualization of the interactions shown in use-case
scenarios.
 SSD’s are an example of widely used analysis and design artifacts or activities that the UP or
RUP documents do no mention.

11. What is a Logical Architecture?

 Logical Architecture is the organization of software classes into packages, subsystems and
layers.
 Logical Architecture does not tells us how these elements are deployed.
 Logical Architecture does not depict how these elements are deployed across different
operating system processes or across physical computers in a network which will be
explained by Deployment Architecture.

12. Define Layer?

 A layer is a coarse grained of classes, packages or subsystems.
 Layers are organized in such a way that higher layers (UI layer) call upon services of lower
layers.

13. What are the layers in Object Oriented System?

 User Interface
 Application Logic and Domain Objects.
 Technical Services.

14. Difference between strict layered architecture and relaxed layered architecture.
Sl. No. Strict Layered Architecture Relaxed Layered Architecture
1 An architecture in which a layer calls only An architecture in which a higher layer calls
their services of the layer directly below it. upon several lower layers.
2 Used in network protocol stack. Used in information systems.

15. What do you mean by Software Architecture?

 Architecture with the set of significant decisions about the organization of a software system.
 The system is composed of structural elements with their behavior specified in the collaborations
and their interfaces.
 Structural and behavioral elements are then combined into larger subsystems.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 2

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
16. Provide the Guideline to Design Layers.
1. Organize the large scale logical structure of a system into discrete layers of distinct, related
responsibilities with a clean, cohesive separation of concerns such that the lower layers are low
level and general services and the higher layers are more application specific.
2. Collaboration and coupling is from higher to lower layers.
3. Avoid coupling from lower to higher layers.

17. What are the Benefits of using layers?

i. Reduces coupling and dependencies by separating high level services from low level services
and application specific from general services.
ii. Improves cohesion.
iii. Some layers can be replaced with new implementations.
iv. Increases reusability.
v. Increases clarity.
18. Define Domain Objects.
Software objects that resembles real world entities to which application logic responsibilities are
assigned known as Domain Objects. Each domain object represents a thing in the problem domain
space.
Example: Fees object able to calculate the semester fees for the students.
19. Differentiate Domain Layer and Domain Model.
1. Domain layer is a part of the software where as Domain model is a part of conceptual analysis.
2. Domain layer contains domain objects to handle application logic whereas domain model is a
visualization of domain concepts.
Example: For a course registration system, registration is a concept in the Domain Model whereas
registration is a class in the domain layer.
20. What is a Domain Model?
 Domain model in problem solving is a conceptual model of a system which describes the various
entities involved in that system and their relationships.
 Domain model is a visual representation of noteworthy concepts.
21. What is meant by Domain Layer?
 Domain Layer is a layer that contains domain objects (real world objects mapped into software
objects) to handle application logic.
 Domain Layer thus acts as a part of software.
22. Define Tier in Logical Architecture.
Tier is a layer which could be physically separated from the layers consuming it.
Example: Client tier indicates client computer.
23. What is Model View Separation?
 Model-Synonym for the domain layer of objects.
 View- Synonym for UI objects such as windows, web pages, applets and reports.
 Model-View Separation Principle – It states that the model objects should not have direct
knowledge of view objects.
24. Provide the Guideline for Model View Separation.
Guideline: Model-View Separation Principle
1. Do not connect or couple non-UI objects directly to UI objects.
Example: Transaction or Register software objects should not have a reference to a Java Swing
JFrame Window Object.
2. Do not put application logic in the UI object methods.
Example: Checking Balance, updating balance of an account should not be included in the GUI
object methods.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 3

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
25. What are the 2 design decisions at an architectural level?
1. What are the big parts?
2. How are they connected?

26. Define the terms Packages Versus Subsystems.

1. Packages groups the factory and Strategies used.
2. Packages are used to represent the different layers of source code.
Example: Pricing, Payroll, Foundation Packages such as java.util
1. Subsystems are a type of stereotyped component that represent independent, behavioral units in a
system.
Example: Persistence, POS rule Engine, Jess.

27. What is a Facade?

1. Facade is the most common pattern of access for packages that represent subsystems.
2. Facade is a GoF design pattern.
3. Public Facade object defines the services for the subsystem and clients collaborate with the
facade not internal subsystem components.
Example: POS Rule Engine Facade and Persistence Facade for access to the rules engines and
Persistence Subsystem.

28. Define Observer Pattern.

 Observer Pattern is used for upward collaboration i.e., when the lower application or domain
layer needs to communicate with upward UI layer via observer pattern.
 UI objects in the higher UI Layer implement an interface such as
 Property Listener or Alarm Listener and are subscribers or listeners to events coming from
objects in the lower layers.
 Lower layer objects directly sends message to the upper layer UI objects. Coupling takes place
only to the objects viewed as a thing that implements an interface.

29. What is Relaxed Layered Coupling?

 An architecture in which elements of a layer collaborate with or are coupled to several other
layers called as relaxed layered or transparent layered architecture.
 Coupling that takes place in this kind of architecture known as Relaxed layered coupling.

30. Distinguish logical views vs deployment and process views of architecture.

The architectural layers are logical view of architecture, not a deployment view of elements to
processes and processing nodes. All the layers can be deployed within the same process on the same
node depends upon the platform.
Example: Application within a handheld PDA.
UP Deployment model maps this logical architecture to processes and nodes which is strongly
influenced by the choice of software and hardware platform and the relevant application frameworks.
Example: J2EE Vs. . .NET influences the deployment architecture.
31. Define Application Layer.
Application Layer contains objects responsible for knowing the session state of clients,
meditating between UI and Domain Layers and controlling the flow of work. Flow is organized by
controlling the order of windows or web pages.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 4
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
32. When Application Layer is useful?
 If one or more of the following conditions are evaluated to true, then the application Layer
becomes useful.
 Multiple user Interfaces used for the system.
 The application Layer objects can act as Adapters that collect and consolidate the data as needed
for different UIs.
 It is a distributed system and the domain layer is on a different node than the UI layer and shared
by multiple clients.
 The Domain Layer cannot or should not maintain session state.
 There is a defined workflow in terms of the controlled order of windows or webpages that must
be presented.
33. Define Fuzzy Set.
A fuzzy set is a function that identifies the degree of membership of an element in a set. Some
elements are harder to classify between
 Technical Services and Foundation Layer.
 Domain and Business Layer.
Some elements are strongly a member of one layer.
Example: Math Class is part of foundation layer.
34. Mention the Layers in Tree Tier Architecture.
 Interface-runs on desktop PC or workstation and uses a standard GUI.
 Application logic-consists of one or more separate modules running on a workstation or
application server.
 Storage-RDBMS on a database Server or mainframe contains the computer data storage logic.
35. What is Upward Communication?
The upward communication from the model to the view or to the view model is done through
events.
Windows obtain information by sending messages to domain objects, querying for information
which they then display in widgets – a polling or pull – from above model of display updates.
36. What is a class?
A class is an encapsulation of attributes and methods. Class is a collection of objects. A class
encapsulates both data and behavior.

37. Define UML Class Diagram.

A class diagram is a collection of static modeling elements such as classes and their relationships,
connected as a graph to each other and to their contents. Class Diagrams show the static structure of the
model and also referred to as object modeling.

Student
Regn no: Int
Name:String
Mark:int
Calavg()
38. Define classifier.
Classifier is an abstract meta class used to describe set of instances having common features. A feature
declares a structural or behavioral characteristic of instances of classifiers.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 5
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Classifiers are a generalization of many of the elements of the UML including classes, interfaces, use
cases and actors. Classifiers can also be specialized.
39. Provide the Steps to show Attributes as Associations.
 Use a navigability arrow pointing from the source to the target object indicating that source object
has an attribute of one target object.
 Use multiplicity at the target end but not at the source end.
 Place role name only at the target end to show the attribute name.
 Don’t provide association name.
40. What is an association End?
An association end is an endpoint of an association which connects the association to a classifier.
An association end has
 Role name(to indicate the role played by the entity or object which is optional)
 Navigability arrow.
 Multiplicity (indicates the number of objects that participate in the association)
 Property string with UML defined keywords such as ordered, unique, list.
41. Define Note.
A UML note is a modeling construct for adding textual information such as a comment, constraint
definition or method body to UML diagrams. Notes are depicted as rectangle with the flip at the top right
most corner.
42. What is a Constraint?
A Constraint refines a model element by expressing a condition or a restriction in a textual statement
to which the model element must conform. Constraints must be placed within braces {….}

43. What is a Stereotype?

A Stereotype is one of the extensibility mechanisms in the UML. Stereotypes allow designers to
extend the vocabulary of UML in order to create new model elements, derived from existing ones.
Stereotypes are shown with guillements symbols. (<< >>)

44. Define Profile.

Profiles are the traditional way to specialize UML Semantics. A profile in the UML provides a
generic extension mechanism for customizing UML models for particular domains and platforms. Profiles
are defined using stereotypes, tags and constraints that are applied to specific model elements such as
classes, attributes, operations, etc.
45. Define Tag.
A second extension mechanism that is closely linked to the stereotype is the tag. Stereotypes allow
users to define new concepts in UML whereas tags allow users to store additional information about these
new concepts.
Stereotype declares a set of tags, using the attribute syntax.
Example: When an element such as employee class is marked with a stereotype, all the tags apply to
the elements can be assigned values.

46. What is Property String?

Property String is a textual way of representing the properties of elements.
Syntax: property string {name1=value 1, name2=value2}
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 6
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Example: {abstract, visibility = private}
Properties can also be shown without values such as abstract and this indicates a Boolean
property i.e., {abstract=true}

47. Define Generalization.

Generalization: Generalization in UML is a kind of relationship in which one model element is
based on another model element.
Notation: Generalization is represented as a solid line ended with a fat triangular arrow from the
subclass to a super class.
In other words, Generalization is a relationship between more generalized class and specialized
class.

48. What is an Abstract classes?

Abstract class is a class that cannot be instantiated. An abstract class is designed only as a parent
class from which child classes may be derived.
i.e., Abstract classes are super classes which contain abstract operation and are defined such that
concrete subclasses are to extend them by implementing the methods.

49. What is dependency?

A dependency relationship is a relationship in which one element, the client, uses or depends on
another element, the supplier.
In other words, dependency is a relationship in which changes to one model element affects
another model element.
Notation: Dependency is denoted by a dashed arrow line from the client to the supplier.

50. What is an interface?

Interfaces are a collection of operation signature and/or attribute a definition that ideally defines
a cohesive set of behaviors. In UML interface implementation is formally called as interface realization.
To realize an interface, a class or component must implement the operations and attributes defined by
the interface.

51. Define Aggregation & Composition. (APRIL/MAY 2011)

Aggregation is a specialization of association, specifying a whole-part relationship between two
objects.
Aggregation can occur when a class is a collection or container
A composition association association relationship represents a whole-Sale relationship and is a
form of aggregation. A composition association specifies that the lifetime of the part classifier is
dependent on the lifetime of the whole classifier.

52. What is meant by interaction diagram? What is the use of Interaction Diagram? (NOV / DEC 2012)
(MAY / JUNE 2013)
Interaction diagrams are models that describe how a group of objects collaborate in some
behaviour.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 7

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Interaction diagrams models the behaiour of use cases by describing the way groups of objects
interact to complete the task
The term interaction diagram is a generalization of two more specialized UML diagram types; both
can be used to express similar message interactions:
 Collaboration diagrams
 Sequence diagrams

53. What is meant by link?

A link is a connection path between two objects; it indicates some form of navigation and visibility
between the objects is possible. More formally, a link is an instance of an association. For example, there is
a link or path of navigation from a Register to a Sale, along which messages may flow, such as the make 2
Payment message.

54. What is meant by Messages?

Each message between objects is represented with a message expression and small arrow indicating
the direction of the message. Many messages may flow along this link. A sequence number is added to show
the sequential order of messages in the current thread of control.

55. How to create an instance?

Any message can be used to create an instance, but there is a convention in the UML to use a
message named create for this purpose. If another (perhaps less obvious) message name is used, the
message may be annotated with a special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of initial values. This indicates,
for example, a constructor call with parameters in Java.

56. What is meant by Low Coupling?

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on
other elements. An element with low (or weak) coupling is not dependent on too many other elements; "too
many" is context-dependent, but will be examined. These elements include classes, subsystems, systems,
and so on.

57. What is meant by High cohesion?

Cohesion (or more specifically, functional cohesion) is a measure of how strongly related and
focused the responsibilities of an element are. An element with highly related responsibilities, and which
does not do a tremendous amount of work, has high cohesion. These elements include classes, subsystems,
and so on.

58. Define Controller.

Assign the responsibility for receiving or handling a system event message to a class representing
one of the following choices:
- Represents the overall system, device, or subsystem (facade controller).
- Represents a use case scenario within which the system event occurs, often named
<UseCaseName>Handler, <UseCaseName>Coordinator, or
<Use-CaseName>Session (use-case or session controller).
- Use the same controller class for all system events in the same use case scenario.
-Informally, a session is an instance of a conversation with an actor.
-Sessions can be of any length, but are often organized in terms of use cases (use case sessions).
59. What is meant by CRC card?
CRC cards are index cards, one for each class, upon which the responsibilities of the class are
briefly written, and a list of collaborator objects to fulfill those responsibilities. They are usually

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 8

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
developed in a small group session. The GRASP patterns may be applied when considering the design
while using CRC cards.
60. What is meant by Pure Fabrication?
This is another GRASP pattern. A Pure Fabrication is an arbitrary creation of the designer, not a
software class whose name is inspired by the Domain Model. A use-case controller is a kind of Pure
Fabrication.
61. List the relationships used in class diagram? (NOV/DEC 2013) (NOV/DEC 2015)
o Generalization (class to class)
o Association (object to object)
o Aggregation (object to object)
o Composition (object to object)
62. Define package. (MAY/JUNE 2012) (MAY/JUNE 2013)(NOV/DEC 2013)
A package is a grouping of model elements .A package may contain other packages and other
model elements. Notation: A package is represented as a folder shown as a large rectangle with a tab
attached to its upper left corner, UML Package

Domain

Core elements

63. What do you mean by sequence number in UML? Where and for what it is used? (NOV / DEC 2011)
(NOV / DEC 2012)
Message Number Sequencing
The order of messages is illustrated with sequence numbers. The numbering scheme is:
1. The first message is not numbered. Thus, msg1 is unnumbered.
2. The order and nesting of subsequent messages is shown with a legal numbering scheme in which
nested messages have a number appended to them. You denote nesting by prepending the incoming
message number to the outgoing message number.
Sequence numbering

64. What is sequence Diagram?( NOV / DEC 2011)

A sequence diagram is a kind of interaction diagram that shows how processes operate
with one another and in what order.
Sequence Diagram

From the above diagram, we infer that class A has method –do one and an attribute of type B
Class B has method --do Two and do Three
PART – B
1. Explain System Sequence Diagrams in detail?(NOV/DEC 2015)

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 9

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and
output events related to the systems under discussion. They are input to operation contracts and
most importantly object design.
 The use case text and its implied system events are input to SSD creation. The SSD operations
can in turn be analyzed in the operation contracts, detailed in the Glossary, and most important
serve as the starting point for designing collaborating objects.

 The UML includes sequence diagrams as a notation that can illustrate actor interactions and the
operations initiated by them.
 An SSD shows, for a particular course of events within a use case, the external actors that
interact directly with the system, the system, and the system events that the actors generate.
 Time proceeds downward and the ordering of events should follow their order in the scenario.

What are System Sequence Diagrams?

 A system sequence diagram is a picture that shows, for one particular scenario of a use case, the
events that external actors generate, their order, and inter-system events.
 All systems are treated as a black box; the emphasis of the diagram is events that cross the
system boundary from actors to systems.
 Use cases describe how external actors interact with the software system we are interested in
creating. During this interaction an actor generates system events to a system, usually requesting
some system operation to handle the event.
 For example, when a cashier enters an item's ID, the cashier is requesting the POS system to
record that item's sale (the enterItem event). That event initiates an operation upon the system.
The use case text implies the enterItem event, and the SSD makes it concrete and explicit.
Why Draw an SSD?
 An interesting and useful question in software design is this: What events are coming in to our
system? Why? Because, we have to design the software to handle these events and execute a
response. Basically, a software system reacts to three things:
1) External events from actors (humans or computers),
2) Timer events, and
3) Faults or exceptions (which are often from external sources).
 Therefore, it is useful to know what, precisely, are the external input events the system events.
They are an important part of analyzing system behavior.

 System behavior is a description of what a system does, without explaining how it does it. One
part of that description is a system sequence diagram. Other parts include the use cases and
system operation contracts.
 Don't create SSDs for all scenarios, unless you are using an estimation technique that requires
identification of all system operations. Rather, draw them only for the scenarios chosen for the
next iteration.
 SSDs are also very useful when you want to understand the interface and collaborations of
existing systems, or to document the architecture.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 10

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 Inception SSDs are not usually motivated in inception, unless you are doing rough estimating
involving a technique that is based on identifying system operations, such as function points or
COCOMO.
 Most SSDs are created during elaboration, when it is useful to identify the details of the system
events to clarify what major operations the system must be designed to handle, write system
operation contracts, and possibly to support estimation.
 SSDs are part of the Use-Case Model a visualization of the interactions implied in the scenarios
of use cases. SSDs were not explicitly mentioned in the original UP description, although the UP
creators are aware of and understand the usefulness of such diagrams.
 SSDs are an example of the many possible skillful and widely used analysis and design artifacts
or activities that the UP or RUP documents do not mention. But the UP, being very flexible,
encourages the inclusion of any and all artifacts and practices that add value.
Sequence Diagrams
The UML does not define something called a "system" sequence diagram but simply a "sequence
diagram." The qualification is used to emphasize its application to systems as black boxes.

SSD for a Process Sale scenario

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 11

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

2. Explain with an example Interaction diagram and how it is used to model the dynamic aspects of a
system? (NOV / DEC 2013) (NOV / DEC 2012) (NOV / DEC 2011)(APRIL/MAY 2011)
UML Interaction Diagrams
The UML includes interaction diagrams to illustrate how objects interact via messages. They are
used for dynamic object modeling. There are two common types: sequence and communication
interaction diagrams.
Sequence and Communication Diagrams
 The term interaction diagram is a generalization of two more specialized UML diagram types:
 sequence diagrams
 communication diagrams
Both can express similar interactions.
 A related diagram is the interaction overview diagram; it provides a big-picture overview of how
a set of interaction diagrams are related in terms of logic and process-flow.
 Sequence diagrams are the more notationally rich of the two types, but communication diagrams
have their use as well, especially for wall sketching.
 Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is
added to the right.
What is Sequence diagram (Briefly explain about the Sequence Diagram? MAY/JUNE 2013)

That class A has a method named doOne and an attribute of type B. Also, that class B has
methods named doTwo and doThree. Perhaps the partial definition of class A is:
public class A
{
private B myB = new B();

public void doOne()

{
myB.doTwo();
myB.doThree();
}
// …
}
Communication diagrams illustrate object interactions in a graph or network format, in which
objects can be placed anywhere on the.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 12

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

Communication diagram

What are the Strengths and Weaknesses of Sequence vs. Communication Diagrams?
 Each diagram type has advantages, and modelers have idiosyncratic preference there isn't
an absolutely "correct" choice. However, UML tools usually emphasize sequence diagrams,
because of their greater notational power.
 Sequence diagrams have some advantages over communication diagrams. Perhaps first
and foremost, the UML specification is more sequence diagram centric more thought and effort
has been put into the notation and semantics.
 Thus, tool support is better and more notation options are available. Also, it is easier to
see the call-flow sequence with sequence diagrams simply read top to bottom.
 With communication diagrams we must read the sequence numbers, such as "1:" and
"2:". Hence, sequence diagrams are excellent for documentation or to easily read a reverse-
engineered call-flow sequence, generated from source code with a UML tool.
 But on the other hand, communication diagrams have advantages when applying "UML
as sketch" to draw on walls (an Agile Modeling practice) because they are much more space-
efficient.
 This is because the boxes can be easily placed or erased anywhere horizontal or vertical.
Consequently as well, modifying wall sketches is easier with communication diagrams it is
simple (during creative high-change OO design work) to erase a box at one location, draw a new
one elsewhere, and sketch a line to it.
 In contrast, new objects in a sequence diagrams must always be added to the right edge,
which is limiting as it quickly consumes and exhausts right-edge space on a page (or wall); free
space in the vertical dimension is not efficiently used.
 Developers doing sequence diagrams on walls rapidly feel the drawing pain when
contrasted with communication diagrams.

Type Strengths Weaknesses

clearly shows sequence or time ordering of forced to extend to the right when
sequence messages adding new objects; consumes
large set of detailed notation options horizontal space
space economicalflexibility to add new more difficult to see sequence of
communication objects in two dimensions messages
fewer notation options

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 13

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Example Sequence Diagram: makePayment
1. The message makePayment is sent to an instance of a Register. The sender is not identified.
2. The Register instance sends the makePayment message to a Sale instance.
3. The Sale instance creates an instance of a Payment.

public class Sale

{
private Payment payment;

public void makePayment( Money cashTendered )

{
payment = new Payment( cashTendered );
//…
}
// …
}

Example Communication Diagram: makePayment

The static-view class diagrams are indeed useful, the dynamic-view interaction diagrams or more
precisely, acts of dynamic interaction modeling are incredibly valuable.
Guideline
Spend time doing dynamic object modeling with interaction diagrams, not just static object
modeling with class diagrams.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 14

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

3. Explain in detail about UML Interaction Notation Illustrating participants with Lifeline Boxes?
UML Interaction Diagram Notation
Illustrating Participants with Lifeline Boxes
 In the UML, the boxes you've seen in the prior sample interaction diagrams are called lifeline boxes.
 Their precise UML definition is subtle, but informally they represent the participants in the
interaction related parts defined in the context of some structure diagram, such as a class diagram.
 It is not precisely accurate to say that a lifeline box equals an instance of a class, but informally and
practically, the participants will often be interpreted as such.
Lifeline boxes to show participants in interactions

Basic Message Expression Syntax

Interaction diagrams show messages between objects; the UML has a standard syntax for these
message expressions:
return = message(parameter : parameterType) : returnType
Parentheses are usually excluded if there are no parameters, though still legal.
Type information may be excluded if obvious or unimportant.
For example:
initialize(code)
initialize
d = getProductDescription(id)
d = getProductDescription(id:ItemID)
d = getProductDescription(id:ItemID) : ProductDescription
Singleton Objects
 In the world of OO design patterns; there is one that is especially common, called the Singleton
pattern.
 It is explained later, but an implication of the pattern is that there is only one instance of a class
instantiated never two.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 15

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 In other words, it is a "singleton" instance. In a UML interaction diagram (sequence or
communication), such an object is marked with a '1' in the upper right corner of the lifeline box.
 It implies that the Singleton pattern is used to gain visibility to the object the meaning of that won't
be clear at this time.
Singletons in interaction diagrams

4. Explain in detail about basic sequence diagram notation?

Basic Sequence Diagram Notation
Lifeline Boxes and Lifelines
In contrast to communication diagrams, in sequence diagrams the lifeline boxes include a
vertical line extending below them these are the actual lifelines.
Although virtually all UML examples show the lifeline as dashed, in fact the UML 2
specification says it may be solid or dashed.
Messages
Each (typical synchronous) message between objects is represented with a message expression
on a filled-arrowed solid line between the vertical lifelines.
The time ordering is organized from top to bottom of lifelines.
Messages and focus of control with execution specification bar

In the example of Figure the starting message is called a found message in the UML, shown with
an opening solid ball; it implies the sender will not be specified, is not known, or that the message is
coming from a random source.
However, by convention a team or tool may ignore showing this, and instead use a regular
message line without the ball, intending by convention it is a found message.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 16
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

Focus of Control and Execution Specification Bars

As illustrated in Figure, sequence diagrams may also show the focus of control using an
execution specification bar. The bar is optional.
Guideline: Drawing the bar is more common when using a UML CASE tool, and less common when
wall sketching.
Illustrating Reply or Returns
There are two ways to show the return result from a message:
1. Using the message syntax returnVar = message(parameter).
2. Using a reply (or return) message line at the end of an activation bar.
Both are common in practice. I prefer the first approach when sketching, as it's less effort. If the
reply line is used, the line is normally labelled with an arbitrary description of the returning value.
Two ways to show a return result from a message

Messages to "self" or "this"

You can show a message being sent from an object to itself by using a nested activation bar.
Messages to "this"

Creation of Instances
Note the UML-mandated dashed line. The arrow is filled if it's a regular synchronous, or open
(stick arrow) if an asynchronous call.
The message name create is not required anything is legal but it's a UML idiom.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 17

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
The typical interpretation of a create message on a dashed line with a filled arrow is "invoke the
new operator and call the constructor".
Object Lifelines and Object Destruction
In some circumstances it is desirable to show explicit destruction of an object. For example,
when using C++ which does not have automatic garbage collection, or when you want to especially
indicate an object is no longer usable. The UML lifeline notation provides a way to express this
destruction.
Object destruction

Diagram Frames in UML Sequence Diagrams

To support conditional and looping constructs, the UML uses frames. Frames are regions or
fragments of the diagrams; they have an operator or label (loop) and a guard (conditional clause).
Example UML frame

The following table summarizes some common frame operators:

Frame
Operator Meaning
Alt Alternative fragment for mutual exclusion conditional logic expressed in the guards.
Loop Loop fragment while guard is true. Can also write loop(n) to indicate looping n times.
There is discussion that the specification will be enhanced to define a FOR loop, such as
loop(i, 1, 10)
Opt Optional fragment that executes if guard is true.
Par Parallel fragments that execute in parallel.
Region Critical region within which only one thread can run.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 18

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Looping
Conditional Messages
An OPT frame is placed around one or more messages. Notice that the guard is placed over the
related lifeline.

Conditional Messages in UML 1.x StyleStill Useful?

The UML 2.x notation to show a single conditional message is heavyweight, requiring an entire
OPT frame box around one message.
The older UML 1.x notation for single conditional messages in sequence diagrams is not legal in
UML 2, but so simple that especially when sketching it will probably be popular for years to come.
A conditional message in UML 1.x notation simple style.

Guideline: Use UML 1 style only for simple single messages when sketching.
Mutually Exclusive Conditional Messages
An ALT frame is placed around the mutually exclusive alternatives.
Mutually exclusive conditional messages

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 19

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Iteration over a Collection
 A common algorithm is to iterate over all members of a collection, sending the same message to
each. Often, some kind of iterator object is ultimately used, such as an implementation of
java.util.Iterator or a C++ standard library iterator, although in the sequence diagram that low-level
"mechanism" need not be shown in the interest of brevity or abstraction.
 At the time of this writing, the UML specification did not (and may never) have an official idiom for
this case. Two alternatives are shown reviewed with the leader of the UML 2 interaction
specification in
Iteration over a collection using relatively explicit notation

Iteration over a collection leaving things more implicit

Note the selector expression lineItems[i] in the lifeline of Figure. The selector expression is used
to select one object from a group. Lifeline participants should represent one object, not a collection.
In Java, for example, the following code listing is a possible implementation that maps the
explicit use of the incrementing variable i in Figure to an idiomatic solution in Java, using its enhanced
for statement.
public class Sale
{
private List<SalesLineItem> lineItems =
new ArrayList<SalesLineItem>();
public Money getTotal()
{
Money total = new Money();
Money subtotal = null;

for ( SalesLineItem lineItem : lineItems )

{

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 20

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
subtotal = lineItem.getSubtotal();
total.add( subtotal );
}
return total;
}
// …
}

the intent is the same, but details are excluded. A team or tool could agree on this simple style by
convention to imply iteration over all the collection elements.
Nesting of Frames
Frames can be nested.
Nesting of frames

How to Relate Interaction Diagrams?

 An interaction occurrence (also called an interaction use) is a reference to an interaction within
another interaction.
 It is useful, for example, when you want to simplify a diagram and factor out a portion into another
diagram, or there is a reusable interaction occurrence.
 UML tools take advantage of them, because of their usefulness in relating and linking diagrams.
Example interaction occurrence, sd and ref frames

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 21

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
They are created with two related frames:
 a frame around an entire sequence diagram, labeled with the tag sd and a name, such as
AuthenticateUser
 a frame tagged ref, called a reference, that refers to another named sequence diagram; it is the
actual interaction occurrence
Interaction overview diagrams also contain a set of reference frames (interaction occurrences).
These diagrams organized references into a larger structure of logic and process flow.
Guideline: Any sequence diagram can be surrounded with an sd frame, to name it. Frame and name one
when you want to refer to it using a ref frame.
Messages to Classes to Invoke Static (or Class) Methods
You can show class or static method calls by using a lifeline box label that indicates the
receiving object is a class, or more precisely, an instance of a metaclass.
Invoking class or static methods; showing a class object as an instance of a metaclass

For example, in Java and Smalltalk, all classes are conceptually or literally instances of class
Class; in .NET classes are instances of class Type.
The classes Class and Type are metaclasses, which means their instances are themselves classes.
A specific class, such as class Calendar, is itself an instance of class Class.
Thus, class Calendar is an instance of a metaclass! It may help to drink some beer before trying
to understand this.
In code, a likely implementation is:
public class Foo
{
public void doX()
{
// static method call on class Calendar
Locale[] locales = Calendar.getAvailableLocales();
// …
}
// …
}

Polymorphic Messages and Cases

Polymorphism is fundamental to OO design. How to show it in a sequence diagram? That's a
common UML question.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 22
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
One approach is to use multiple sequence diagrams one that shows the polymorphic message to
the abstract superclass or interface object, and then separate sequence diagrams detailing each
polymorphic case, each starting with a found polymorphic message.

An approach to modeling polymorphic cases in sequence diagrams

Asynchronous and Synchronous Calls

An asynchronous message call does not wait for a response; it doesn't block. They are used in
multi-threaded environments such as .NET and Java so that new threads of execution can be created and
initiated.
In Java, for example, you may think of the Thread.start or Runnable.run (called by Thread.start)
message as the asynchronous starting point to initiate execution on a new thread.
The UML notation for asynchronous calls is a stick arrow message; regular synchronous
(blocking) calls are shown with a filled arrow.

Asynchronous calls and active objects

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 23

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

An object such as the Clock is also known as an object each instance runs on and controls its
own thread of execution.
In the UML, it may be shown with double vertical lines on the left and right sides of the lifeline
box. The same notation is used for an active class whose instances are active objects.
Notice that the Thread object in the code is excluded from the UML diagram, because it is
simply a consistent "overhead" mechanism to realize an asynchronous call in Java.
public class ClockStarter
{
public void startClock()
{
Thread t = new Thread( new Clock() );
t.start(); // asynchronous call to the 'run' method on the Clock
System.runFinalization(); // example follow-on message
}
// …
}
// objects should implement the Runnable interface in Java to be used on new threads
public class Clock implements Runnable
{
public void run()
{
while ( true ) // loop forever on own thread { // … }
}
// …
}

5. Explain in detail about basic communication diagram and discuss about the links creation of
instances?
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 24
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
A communication diagram in the Unified Modeling Language (UML) 2.0, is a simplified
version of the UML 1.x collaboration diagram.
Basic Communication Diagram Notation
Links
A link is a connection path between two objects; it indicates some form of navigation and
visibility between the objects is possible.
More formally, a link is an instance of an association. For example, there is a link or path of
navigation from a Register to a Sale, along which messages may flow, such as the makePayment
message.
Link lines

Messages
Each message between objects is represented with a message expression and small arrow
indicating the direction of the message.
Many messages may flow along this link. A sequence number is added to show the sequential
order of messages in the current thread of control.
Messages

Messages to "self" or "this"

A message can be sent from an object to itself. This is illustrated by a link to itself, with
messages flowing along the link.
Messages to "this."

Creation of Instances
Any message can be used to create an instance, but the convention in the UML is to use a
message named create for this purpose. If another (less obvious) message name is used, the message
may be annotated with a UML stereotype, like so: «create».

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 25

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
The create message may include parameters, indicating the passing of initial values. This
indicates, for example, a constructor call with parameters in Java.
Furthermore, the UML tagged value {new} may optionally be added to the lifeline box to
highlight the creation. Tagged values are a flexible extension mechanism in the UML to add
semantically meaningful information to a UML element.
Instance creation

Message Number Sequencing

The order of messages is illustrated with sequence numbers. The numbering scheme is:
i. The first message is not numbered. Thus, msg1 is unnumbered.
ii. The order and nesting of subsequent messages is shown with a legal numbering scheme
in which nested messages have a number appended to them. You denote nesting by
prepending the incoming message number to the outgoing message number.
Sequence numbering

Complex sequence numbering

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 26

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

Conditional Messages
You show a conditional message by following a sequence number with a conditional clause in
square brackets, similar to an iteration clause. The message is only sent if the clause evaluates to true.
Conditional message

Mutually Exclusive Conditional Paths

The example in Figure illustrates the sequence numbers with mutually exclusive conditional
paths.
Mutually exclusive messages

In this case we must modify the sequence expressions with a conditional path letter. The first
letter used is a by convention. Figure states that either 1a or 1b could execute after msg1. Both are
sequence number 1 since either could be the first internal message.
Note that subsequent nested messages are still consistently prepended with their outer message
sequence. Thus 1b.1 is nested message within 1b.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 27

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
Iteration or Looping
Iteration notation is shown in Figure. If the details of the iteration clause are not important to the
modeler, a simple * can be used.
Iteration

Iteration over a Collection

A common algorithm is to iterate over all members of a collection (such as a list or map),
sending the same message to each. In communication diagrams, this could be summarized as shown in
Figure, although there is no official UML convention.
Iteration over a collection

Messages to a Classes to Invoke Static (Class) Methods

Messages to a class object (static method invocation)

Polymorphic Messages and Cases

Refer to Figure for the related context, class hierarchy, and example for sequence diagrams. As
in the sequence diagram case, multiple communication diagrams can be used to show each concrete
polymorphic case.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 28

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
An approach to modeling polymorphic cases in communication diagrams

Asynchronous and Synchronous Calls

As in sequence diagrams, asynchronous calls are shown with a stick arrow; synchronous calls
with a filled arrow.
Asynchronous call in a communication diagram

6. Explain about UML State Machine Diagrams and Modeling. (April-May’13) (Nov-Dec’11)
Introduction
 The UML includes statechart diagram notation to illustrate the events and states of things—
transactions, use cases, people, and so forth. The most important notational features are shown,
 The use of statechart diagrams is emphasized for showing system events in use cases, but they
may additionally be applied to any class.
Events, States, and Transitions
1. An event is a significant or noteworthy occurrence. For example:
 A telephone receiver is taken off the hook.
2. A state is the condition of an object at a moment in time—the time between events. For
example:
 A telephone is in the state of being "idle" after the receiver is placed on the hook and
until it is taken off the hook.
3. A transition is a relationship between two states that indicates that when an event occurs, the
object moves from the prior state to the subsequent state. For example:
 When the event "off hook" occurs, transition the telephone from the "idle" to "active"
state.

Statechart Diagrams
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 29
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 A UML statechart diagram, as shown in Figure 29.1, illustrates the interesting events and states
of an object, and the behavior of an object in reaction to an event.
 Transitions are shown as arrows, labeled with their event.
 States are shown in rounded rectangles.
 It is common to include an initial pseudo-state, which automatically transitions to another state
when the instance is created.

 A statechart diagram shows the lifecycle of an object:

 what events it experiences, its transitions, and the states it is in between these events.
 It need not illustrate every possible event; if an event arises that is not represented in
the diagram, the event is ignored as far as the statechart diagram is concerned.
Subject of a Statechart Diagram
A statechart diagram may be applied to a variety of UML elements, including:
 classes (conceptual or software)
 use cases
Use Case Statechart Diagrams
A useful application of statechart diagrams is to describe the legal sequence of external system
events that are recognized and handled by a system in the context of a use case. For example:
 During the Process Sale use case in the NextGen POS application, it is not legal to perform the
makeCreditPayment operation until the endSale event has happened.
 During the Process Document use case in a word processor, it is not legal to perform the File-
Save operation until the File-New or File-Open event has happened.
 A statechart diagram that depicts the overall system events and their sequence within a use case
is a kind of use case statechart diagram.
 The use case statechart diagram in Figure 29.2 shows a simplified version of the system events
for the Process Sale use case in the POS application. It illustrates that it is not legal to generate a
makePayment event if an endSale event has not previously caused the system to transition to the
WaitingForPayment state.


Classes that Benefit from Statechart Diagrams
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 30
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
In addition to statechart diagrams for use cases or the overall system, they may be created for
virtually any type or class.

State-Independent and State-Dependent Objects

 If an object always responds the same way to an event, then it is considered state-
independent (or modeless) with respect to that event.
 State-dependent objects react differently to events depending on their state.

Common State-dependent Classes

Following is a list of common objects which are usually state-dependent, and for which it may be
useful to create a statechart diagram:
1. Use cases
 Viewed as a class, the Process Sale use case reacts differently to the endSale event
dependent of if a sale is underway or not.
1. Stateful sessions
 These are server-side software objects representing ongoing sessions or conversations
with a client; for example, EJB stateful session objects.
2. Systems This is a class representing the overall application or system.
 The "POS system."
3. Windows
 The Edit-Paste action is only valid if there is something in the "clipboard" to paste.
4. Controllers—These are GRASP controller objects.
 The Register class, which handles the enterltem and endSale system events.
5. Transactions
 These are ways a transaction (a sale, order, payment) reacts to an event is often
dependent on its current state within its overall lifecycle.
 If a Sale received a makeLineltem message after the endSale event, it should either raise
an error condition or be ignored.
6. Devices
 TV, microwave oven: they react differently to a particular event depending upon their
current state.
7. Role Mutators
 These are classes that change their role.
 A Person changing roles from being a civilian to a veteran. Illustrating External and
Interval Events
Event Types
It is useful to categorize events as follows:
External event
 It is also known as a system event, is caused by something (for example, an actor) outside
our system boundary. SSDs illustrate external events.
 When a cashier presses the "enter item" button on a POS terminal, an external event has
occurred.
Internal event
 It is caused by something inside our system boundary.
 In terms of software, an internal event arises when a method is invoked via a message or
signal that was sent from another internal object.
 Messages in interaction diagrams suggest internal events.
 When a Sale receives a makeLineltem message, an internal event has occurred.

Temporal event
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 31
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 It is caused by the occurrence of a specific date and time or passage of time.
 In terms of software, a temporal event is driven by a realtime or simulated-time clock.
 Suppose that after an endSale operation occurs, a makePayment operation must occur within
five minutes, otherwise the current sale is automatically purged.
Statechart Diagrams for Internal Events
 A statechart diagram can show internal events that typically represent messages received from
other objects.
 Since interaction diagrams also show messages and their reactions (in terms of other messages),
 why use a statechart diagram to illustrate internal events and object design?
 The object design paradigm is that of objects that collaborate via messages to fulfill tasks;
the UML interaction diagrams directly illustrates that paradigm.
 It is somewhat incongruous to use a statechart diagram to show a design of object
messaging and interaction.
 Consequently, I have reservations about recommending the use of statechart diagrams
that show internal events for the purpose of creative object design. However, they may be
useful to summarize the results of a design, after it is complete.
 A statechart diagram for external events can be a helpful and succinct tool.
 Statechart diagrams to illustrate external and temporal events, and the reaction to them, rather
than using them to design object behavior based on internal events.

Additional Statechart Diagram Notation

The UML notation for statechart diagrams contains a rich set of features that are not exploited in
this introduction. Two significant features are:
 transition actions transition
 guard conditions nested states

Transition Actions and Guards

 A transition can cause an action to fire. In a software implementation, this may represent the
invocation of a method of the class of the statechart diagram.
 A transition may also have a conditional guard—or boolean test. The transition only occurs if the
test passes.

Nested States
 A state allows nesting to contain substates; a substate inherits the transitions of its superstate (the
enclosing state). This is a key contribution of the Harel state-chart diagram notation that UML is
based on, as it leads to succinct statechart diagrams.
 Substates may be graphically shown by nesting them in a superstate box.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 32

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

 For example, when a transition to the Active state occurs, creation and transition into the
PlayingDialTone substate occurs.
 No matter what substate the object is in, if the on hook event related to the Active superstate
occurs, a transition to the Idle state occurs.

7.Explain about activity diagram with an example. APRIL/MAY 2011, NOV / DEC 2011, APRIL/MAY 2012, NOV /
DEC 2012, MAY / JUNE 2013 & NOV / DEC 2013
UML activity diagram
Basic UML activity diagram notation is shown in Figure, illustrating an action, partition, fork,
join, and object node. In essence, this diagram shows a sequence of actions, some of which may be
parallel. Most of the notation is self-explanatory; two subtle points:
 Once an action is finished, there is an automatic outgoing transition
 The diagram can show both control flow and data flow
Basic UML activity diagram notation.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 33

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
How to Apply Activity Diagrams?
A UML activity diagram offers rich notation to show a sequence of activities, including parallel
activities. It may be applied to any perspective or purpose, but is popular for visualizing business
workflows and processes, and use cases.

Business Process Modeling

 One of my clients is in the express parcel shipping business.
 The process of shipping a parcel is very non-trivial; there are many parties involved and many
steps.
 Although this process can be captured in text, in this case activity diagrams are a great example
of pictures being worth a thousand words.
 My client uses activity diagrams to understand their current complex business processes by
visualizing them. The partitions are useful to see the multiple parties and parallel actions
involved in the shipping process, and the object nodes illustrate what's moving around.
 After modeling their current process they visually explore changes and optimizations.

Data Flow Modeling

 Starting in the 1970s, data flow diagrams (DFD) became a popular way to visualize the major
steps and data involved in software system processes.
 This is not the same as business process modeling; rather, DFDs were usually used to show data
flows in a computer system, although they could in theory be applied to business process
modeling. DFDs were useful to document the major data flows or to explore a new high-level
design in terms of data flow.
 See Figure for an example DFD in the classic Gane-Sarson notation. Observe that the process
steps are numbered, to indicate order.

Classic DFD in Gane-Sarson notation.

Figure illustrates the same information as the DFD in Figure, but using a UML activity diagram.

Applying activity diagram notation to show a data flow model

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 34
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

Concurrent Programming and Parallel Algorithm Modeling

 Parallel algorithms in concurrent programming problems involve multiple partitions, and fork
and join behavior.
 For example, such algorithms are used in 3D simulations with finite element or finite difference
modeling, and are applied to oil reservoir modeling, materials stress analysis, and weather
modeling. The overall physical space is subdivided into large blocks, and many parallel threads
(or processes) execute, one for each sub-block.
 In these cases the UML activity diagram partitions can be used to represent different operating
system threads or processes.
 The object nodes can be used to model the shared objects and data. And of course, forking can be
used to model the creation and parallel execution of multiple threads or processes, one per
partition.
More UML Activity Diagram Notation
How to show that an activity is expanded in another activity diagram? and illustrate, using the
rake symbol.
An activity will be expanded in another diagram.

 How to show conditional branches? See the decision symbol used in Figure. The related merge
symbol shows how flows can come back together.
 Signals are shown in Figure. They are useful, for example, when you need to model events such
as time triggering an action, or a cancellation request.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 35

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

There's a lot more UML activity notation available. This short introduction merely highlights
some of the most common elements.
8. For the Hospital management system draw the following UML diagram. NOV / DEC 2012
(i) Conceptual Class diagram (Overall system)
(ii) Activity diagram (Billing).
Activity diagram

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 36

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
9. Explain about Logical Architecture and UML Package Diagrams ?

Logical Architecture
We have transitioned from analysis-oriented work to software design. The design of a typical OO
system is based on several architectural layers, such as a UI layer, an application logic layer, and so forth.
What is the Logical Architecture? And Layers?
The logical architecture is the large-scale organization of the software classes into packages,
subsystems, and layers. It's called the logical architecture because there's no decision about how these elements
are deployed across different operating system processes or across physical computers in a network.
A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive
responsibility for a major aspect of the system. Also, layers are organized such that "higher" layers (such as the
UI layer) call upon services of "lower" layers, but not normally vice versa. Typically layers in an OO system
include:
 User Interface.
 Application Logic and Domain Objects software objects representing domain concepts that fulfill
application requirements, such as calculating a sale total.
 Technical Services general purpose objects and subsystems that provide supporting technical services,
such as interfacing with a database or error logging. These services are usually application-independent
and reusable across several systems.
In a strict layered architecture, a layer only calls upon the services of the layer directly below it. This
design is common in network protocol stacks, but not in information systems, which usually have a relaxed
layered architecture, in which a higher layer calls upon several lower layers. For example, the UI layer may call
upon its directly subordinate application logic layer, and also upon elements of a lower technical service layer,
for logging and so forth.
Although OO technology can be applied at all levels, this introduction to OOA/D focuses on the core
application logic (or "domain") layer, with some secondary discussion of the other layers.

Software Architecture
An architecture is the set of significant decisions about the organization of a software system, the
selection of the structural elements and their interfaces by which the system is composed, together with their
behavior as specified in the collaborations among those elements, the composition of these structural and
behavioral elements into progressively larger subsystems, and the architectural style that guides this
organization these elements and their interfaces, their collaborations, and their composition.
Regardless of the definition the common theme in all software architecture definitions is that it has to do
with the large scale the Big Ideas in the motivations, constraints, organization, patterns, responsibilities, and
connections of a system.
Package Diagrams
UML package diagrams are often used to illustrate the logical architecture of a system the layers,
subsystems, packages, etc. A layer can be modeled as a UML package; for example, the UI layer modeled as a
package named UI.
A UML package diagram provides a way to group elements. A UML package can group anything:
classes, other packages, use cases, and so on. Nesting packages is very common. A UML package is a more
general concept than simply a Java package or .NET namespace, though a UML package can represent those
and more.
The package name may be placed on the tab if the package shows inner members, or on the main folder,
if not.
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 37
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
It is common to want to show dependency (a coupling) between packages so that developers can see the
large-scale coupling in the system. The UML dependency line is used for this, a dashed arrowed line with the
arrow pointing towards the depended-on package.
A UML package represents a namespace so that, for example, a Date class may be defined in two
packages. If you need to provide fully-qualified names, the UML notation is, for example, java::util::Date in the
case that there was an outer package named "java" with a nested package named "util" with a Date class.
The UML provides alternate notations to illustrate outer and inner nested packages. Sometimes it is awkward to
draw an outer package box around inner packages.

Alternate UML approaches to show package nesting, using embedded packages, UML fully-qualified
names, and the circle-cross symbol

10. Discuss about UML deployment diagrams. (April-May’13) (April-May’11) (April-May’12)

Deployment Diagrams.
(or)

What is a Physical Model? How will you design this model in UML? With an example explain the
diagrams in the physical model. (Nov-Dec’12)
 A deployment diagram shows the assignment of concrete software artifacts (such as executable
files) to computational nodes (something with processing services).
 It shows the deployment of software elements to the physical architecture and the
communication between physical elements.
 Deployment diagrams are useful to communicate the physical or deployment architecture, for
example, in the UP Software Architecture Document.

A deployment diagram
PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 38
 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN

The basic element of a deployment diagram is a node, of two types:

 Device node (or device) A physical (e.g., digital electronic) computing resource with processing
and memory services to execute software, such as a typical computer or a mobile phone.
 Execution environment node (EEN) This is a software computing resource that runs within an
outer node (such as a computer) and which itself provides a service to host and execute other
executable software elements. For example:
 an operating system (OS) is software that hosts and executes programs
 a virtual machine (VM, such as the Java or .NET VM) hosts and executes
programs
 a database engine (such as PostgreSQL) receives SQL program requests and
executes them, and hosts/executes internal stored procedures (written in Java or a
proprietary language)
 a Web browser hosts and executes JavaScript, Java applets, Flash, and other
executable technologies
 a workflow engine
 a servlet container or EJB container
 As the UML specification suggests, many node types may show stereotypes, such as «server»,
«OS», «database», or «browser», but these are not official predefined UML stereotypes.
 Note that a device node or EEN may contain another EEN. For example, a virtual machine
within an OS within a computer.
 A particular EEN can be implied, or not shown, or indicated informally with a UML property
string; for example, {OS=Linux}. For example, there may not be value in showing the OS EEN
as an explicit node.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 39

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 The normal connection between nodes is a communication path, which may be labeled with the
protocol. These usually indicate the network connections.
 A node may contain and show an artifact concrete physical element, usually a file. This includes
executables such as JARs, assemblies, .exe files, and scripts. It also includes data files such as
XML, HTML, and so forth.
 A deployment diagram usually shows an example set of instances (rather than classes). For
example, an instance of a server computer running an instance of the Linux OS.
 Generally in the UML, concrete instances are shown with an underline under their name, and the
absence of an underline signifies a class rather than an instance.
 Note that a major exception to this rule is instances in interaction diagrams there, the names of
things signifying instances in lifeline boxes are not underlined.
 In any event, in deployment diagrams, you will usually see the objects with their name
underlined, to indicate instances. However, the UML specification states that for deployment
diagrams, the underlining may be omitted and assumed. Therefore, you can see examples in both
styles.

11. Discuss about UML component diagrams. (April-May’11) (April-May’12)

Component Diagrams
 Components are a slightly fuzzy concept in the UML, because both classes and components can
be used to model the same thing.
 For example, to quote Rumbaugh:
o The distinction between a structured class and a component is somewhat vague and more
a matter of intent than firm semantics.
 A component represents a modular part of a system that encapsulates its contents and whose
manifestation is replaceable within its environment.
 A component defines its behavior in terms of provided and required interfaces. As such, a
component serves as a type, whose conformance is defined by these provided and required
interfaces.
 Again, this idea can be modeled with a regular UML class and its provided and required
interfaces. Recall that a UML class can be used to model any level of software element, from an
entire system to subsystem to small utility object.
 But when one uses a UML component, the modeling and design intent is to emphasize
1) that the interfaces are important, and
2) it is modular, self-contained and replaceable.
The second point implies that a component tends to have little or no dependency on other
external elements (except perhaps standard core libraries); it is a relatively stand-alone module.
 UML components are a design-level perspective; they don't exist in the concrete software
perspective, but map to concrete artifacts such as a set of files.
 A good analogy for software component modeling is a home entertainment system; we expect to
be able to easily replace the DVD player or speakers. They are modular, self-contained,
replaceable, and work via standard interfaces.
 For example, at a large-grained level, a SQL database engine can be modeled as a component;
any database that understands the same version of SQL and supports the same transaction
semantics can be substituted. At a finer level, any solution that implements the standard Java
Message Service API can be used or replaced in a system.

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 40

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
 Since the emphasis of component-based modeling is replaceable parts (perhaps to upgrade for
better non-functional qualities, such as performance), it's a general guideline to do component
modeling for relatively large-scale elements, because it is difficult to think about or design for
many small, fine-grained replaceable parts.
UML components

12.Consider the Hospital Management System application with the following requirements

(i) System should handle the in-patient, out-patient information through receptionist.
(ii) Doctors are allowed to view the patient history and give their prescription.
(iii) There should be a information system to provide the required information.
Give the state chart, component and deployment diagrams.(6 + 6 + 4) (Nov-Dec’11) (Nov-Dec’12)

State Chart Diagram

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 41

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
COMPONENT DIAGRAM

equipment
database

<<use>> <<use>>

HOSPITAL MANAGEMENT HOSPITAL MANAGEMENT

SYSTEM LOCAL SERVER DATABASE

<<use>>

<<reside>>

Utility User Interface

HMS DATA
PROCESSING

DEPLOYMENT DIAGRAM

Desktop Printer
client <<Primary network>>

HOSPITAL LOCAL <<Private network>>

SERVER

<<Private network>> Database

server

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 42

 CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
ANNA UNIVERSITY QUESTIONS

NOV/DEC 2015
PART – A
1. List the relationships used in class diagram. (Q.No.61)
2. What is meant by System behavior? (Q.No.2)
PART – B
1. How to Add New SSDs and contracts to the design diagram?(Q.NO.1,2)
2. What are the concepts involved in domain refinement? (Q.NO.4)
3. Explain about Interaction Diagram Notation for inventory management system.(Q.NO.7)

ANNA UNIVERSITY QUESTIONS(OLD REGULATION)

Part – A

1. Define Aggregation and Composition. (Q. No. 51)

2. What is the use of System sequence diagram? (Q. No. 1)
3. What do you mean by sequence diagram? Mention its use. (Q. No. 1)
4. What do you mean by sequence number in UML? Where and for what it is used? (Q. No. 63)
5. What is the use of System sequence diagram? (Q. No. 1)
6. Define Package and draw the UML notation for Package. (Q. No. 62)
7. What are interactive diagrams? List out the components involved in interactive diagrams. (Q. No. 52)
8. What do you mean by sequence number in UML? Where and for what it is used?( Q. No. 63)
9. What is the use of Interaction Diagram? (Q. No. 52)
10. Define Package and Draw the UML Notation for Package? (Q. No. 62)
11. What is the use of UML package Diagram? (Q. No. 62)
12. List the relationship used in class diagram? (Q. No. 61)

Part – B
1. Illustrate with an example, the relationship between sequence diagram and use cases. (Q. No. 2)
2. Explain with an example Interaction diagram. (Q. No. 7)
3. With a suitable example explain how to design a class. Give all possible representation in a class
(name, attribute, visibility, methods, and responsibilities). (Q. No. 5)
4. What do you mean by interaction diagrams? Explain them with a suitable example. (Q. No. 7)
5. Compare Sequence versus Collaboration diagram with suitable example. (Q. No. 11)
6. With a suitable example explain how to design a class. Given all possible representation in a class
(such as: name, attribute, visibility, methods, and responsibilities). (Q. No. 5)
7. Explain interaction diagram with a suitable example. (Q. No. 7)
8. Briefly explain about the Sequence Diagram? (Q. No. 7)
9. Explain with example how interaction diagrams are used to model the dynamic aspects of a system?
(Q. No. 7)
10. Describe the UML notation for the Class Diagram with an example .Explain the concept of
Association and Inheritance? (Q. No. 5)
11. Illustrate with an example the relationship with the sequence diagram and the use cases? (Q. No. 2)
12. (i) Describe the UML notation for class diagram with an example. (Q. No. 5)
(ii) Explain the concept of Link, Association and Inheritance. (Q. No. 5)

PREPARED BY: Mrs. E.LAVANYA, Asso.Prof./CSE 43