Use-case Driven Object oriented

Analysis
Chapter 3
 Goals of UML
• UML is a standard language for specifying, visualizing, constructing, and
documenting the artifacts of software systems.
• UML stands for Unified Modeling Language.
• UML is different from the other common programming languages such as
C++, Java, COBOL, etc.
• UML is a pictorial language used to make software blueprints

• Goals of UML
• A picture is worth a thousand words, this idiom absolutely fits describing
UML. Object-oriented concepts were introduced much earlier than UML.
• At that point of time, there were no standard methodologies to organize
and consolidate the object-oriented development.
• It was then that UML came into picture.
• This chapter describes all the UML building blocks. The building blocks of
UML can be defined as −
– Things
– Relationships
– Diagrams
– Things
• Things are the most important building blocks of UML. Things can be −
– Structural
– Behavioral
– Grouping
– Annotational
 Structural Things
• Structural things define the static part of the model. They represent the
physical and conceptual elements. Following are the brief descriptions of
the structural things.
• Class − Class represents a set of objects having similar responsibilities.

• Interface − Interface defines a set of operations, which specify the

responsibility of a class.
• Collaboration −Collaboration defines an interaction between elements.

• Use case −Use case represents a set of actions performed by a system for
a specific goal.

• Component −Component describes the physical part of a system.

• Node − A node can be defined as a physical element that exists at run

time.
• Behavioral Things
• Interaction − Interaction is defined as a behavior that consists of a group
of messages exchanged among elements to accomplish a specific task.

• State machine − State machine is useful when the state of an object in its
life cycle is important. It defines the sequence of states an object goes
through in response to events. Events are external factors responsible for
state change

• Package − Package is the only one grouping thing available for gathering
structural and behavioral things.
• Annotational things can be defined as a mechanism to capture remarks,
descriptions, and comments of UML model elements. Note - It is the only
one Annotational thing available. A note is used to render comments,
constraints, etc. of an UML element.

• Dependency :Dependency is a relationship between two things in which

change in one element also affects the other.

• Association: Association is basically a set of links that connects the

elements of a UML model. It also describes how many objects are taking
part in that relationship
• Generalization: Generalization can be defined as a relationship which
connects a specialized element with a generalized element. It basically
describes the inheritance relationship in the world of objects.

• Realization : Realization can be defined as a relationship in which two

elements are connected. One element describes some responsibility,
which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

•
• There are three important types of UML modeling.
• Structural Modeling
– Classes diagrams
– Objects diagrams
– Deployment diagrams
– Package diagrams
– Composite structure diagram
– Component diagram
• Structural model represents the framework for the system and this
framework is the place where all other components exist. Hence, the class
diagram, component diagram and deployment diagrams are part of
structural modeling. They all represent the elements and the mechanism
to assemble them.
• The structural model never describes the dynamic behavior of the system.
Class diagram is the most widely used structural diagram.
• Behavioral Modeling
• Behavioral model describes the interaction in the system. It represents the
interaction among the structural diagrams. Behavioral modeling shows the
dynamic nature of the system. They consist of the following −
– Activity diagrams
– Interaction diagrams
– Use case diagrams
• All the above show the dynamic sequence of flow in a system.
• Architectural Modeling
• Architectural model represents the overall framework of the system. It
contains both structural and behavioral elements of the system.
Architectural model can be defined as the blueprint of the entire system.
Package diagram comes under architectural modeling.
• Structural Things
• Graphical notations used in structural things are most widely used in UML.
These are considered as the nouns of UML models. Following are the list
of structural things.
– Classes
– Object
– Interface
– Collaboration
– Use case
– Active classes
– Components
– Nodes
• Class Notation
– The top section is used to name the class.
– The second one is used to show the attributes of the class.
– The third section is used to describe the operations performed by the
class.
– The fourth section is optional to show any additional components.
• Object Notation
• The object is represented in the same way as the class. The only difference
is the name which is underlined as shown in the following figure.
• Interface Notation
• Collaboration Notation
• Collaboration is represented by a dotted eclipse as shown in the following
figure. It has a name written inside the eclipse
• Actor Notation
• An actor can be defined as some internal or external entity that interacts
with the system
• Initial State Notation
• Initial state is defined to show the start of a process. This notation is used
in almost all diagrams.

• Final State Notation

• Final state is used to show the end of a process. This notation is also used
in almost all diagrams to describe the end
• Class diagram is a static diagram.
• It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software
application.
• Class diagram describes the attributes and operations of a class and also
the constraints imposed on the system.
• The class diagrams are widely used in the modeling of object-oriented
systems because they are the only UML diagrams, which can be mapped
directly with object-oriented languages.
 Purpose of Class Diagrams
• The purpose of class diagram is to model the static view of an application.
Class diagrams are the only diagrams which can be directly mapped with
object-oriented languages and thus widely used at the time of
construction.
– The purpose of the class diagram can be summarized as −
– Analysis and design of the static view of an application.
– Describe responsibilities of a system.
– Base for component and deployment diagrams.
– Forward and reverse engineering.
 How to Draw a Class Diagram?
• The following points should be remembered while drawing a class diagram
– The name of the class diagram should be meaningful to describe the
aspect of the system.
– Each element and their relationships should be identified in advance.
– Responsibility (attributes and methods) of each class should be clearly
identified
– For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
– Use notes whenever required to describe some aspect of the diagram.
At the end of the drawing it should be understandable to the
developer/coder.
– Finally, before making the final version, the diagram should be drawn
on plain paper and reworked as many times as possible to make it
correct.
• The following diagram is an example of an Order System of an application.
It describes a particular aspect of the entire application.
– First of all, Order and Customer are identified as the two elements of
the system. They have a one-to-many relationship because a customer
can have multiple orders.
– Order class is an abstract class and it has two concrete classes
(inheritance relationship) Special Order and Normal Order.
– The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().
• The following class diagram has been drawn considering all the points
mentioned above.
 Object diagram
• The purpose of the object diagram can be summarized as −
– Making the prototype of a system.
– Reverse engineering.
– Modeling complex data structures.
– Understanding the system from practical perspective.
 Associations and links
• The major difference between link and association is that link is a physical
or theoretical connection between the objects whereas association is a
group of links with same structure and semantics.
• Associations are implemented in programming languages as a reference
model in which one object is referenced from the another.
• While links cannot be referenced as these are not objects by itself, but rely
on the objects.
 Aggregation
• Aggregation is a special case of association. A directional association
between objects.
• When an object ‘has-a’ another object, then you have got an aggregation
between them.
• Direction between them specified which object contains the other object.
Aggregation is also called a “Has-a” relationship
 Composition
• The UML representation of a composition relationship shows composition
as a filled diamond shape on the containing class end of the lines that
connect contained class(es) to the containing class.
• Composition is a special case of aggregation. In a more specific manner, a
restricted aggregation is called composition.
• When an object contains the other object, if the contained object cannot
exist without the existence of container object, then it is called
composition

• Example: A class contains students. A student cannot exist without a class.

There exists composition between class and students
 Containment
• The idea of Containment in object-oriented programming is the idea that
an outer class contains an instance of another class and allows access to
the contained object through its own methods.
• Aggregation is one form of containment where the contained object can
exist independently from the outer object.
• For example, a Family object might contain an instance of a Dog object,
representing a dog that the family owns.
 Use case Diagram
• A use case diagram at its simplest is a representation of a user's
interaction with the system that shows the relationship between the user
and the different use cases in which the user is involved.
• A use case diagram can identify the different types of users of a system
and the different use cases and will often be accompanied by other types
of diagrams as well.
• The use cases are represented by either circles or ellipses.
• use case diagram for ATM machine
 Use case Diagram
• How to Draw a Use Case Diagram?
– Use case diagrams are considered for high level requirement analysis
of a system.
– When the requirements of a system are analyzed, the functionalities
are captured in use cases
– We can say that use cases are nothing but the system functionalities
written in an organized manner. The second thing which is relevant to
use cases are the actors. Actors can be defined as something that
interacts with the system.
– Actors can be a human user, some internal applications, or may be
some external applications. When we are planning to draw a use case
diagram, we should have the following items identified.
• Functionalities to be represented as use case
• Actors
• Relationships among the use cases and actors.
• Use the following guidelines to draw an efficient use case diagram
– The name of a use case is very important. The name should be chosen
in such a way so that it can identify the functionalities performed.
– Give a suitable name for actors.
– Show relationships and dependencies clearly in the diagram.
– Do not try to include all types of relationships, as the main purpose of
the diagram is to identify the requirements.
– Use notes whenever required to clarify some important points
 Activity Diagram
• Activity diagrams are graphical representations of workflows of stepwise
activities and actions with support for choice, iteration and concurrency.
• In the Unified Modeling Language, activity diagrams are intended to
model both computational and organizational processes (i.e., workflows),
as well as the data flows intersecting with the related activities.
• Although activity diagrams primarily show the overall flow of control, they
can also include elements showing the flow of data between activities
through one or more data stores.
Example
• activity diagram for Customer Process in
online buying of toys.
• Activity Diagram for Enrollment in Aerobic
Training.
 Sequence diagram
• A sequence diagram shows object interactions arranged in time sequence.
• It depicts the objects and classes involved in the scenario and the
sequence of messages exchanged between the objects needed to carry
out the functionality of the scenario.
• Sequence diagrams are typically associated with use case realizations in
the Logical View of the system under development.
• Sequence diagrams are sometimes called event diagrams or event
scenarios.
• A sequence diagram shows, as parallel vertical lines (lifelines), different
processes or objects that live simultaneously, and, as horizontal arrows,
the messages exchanged between them, in the order in which they occur.
• This allows the specification of simple runtime scenarios in a graphical
manner.
• Actors – An actor in a UML diagram represents a type of role where it
interacts with the system and its objects. It is important to note here that
an actor is always outside the scope of the system we aim to model using
the UML diagram.
• Lifelines – A lifeline is a named element which depicts an individual
participant in a sequence diagram. So basically each instance in a
sequence diagram is represented by a lifeline
• Messages – Communication between objects is depicted using messages.
The messages appear in a sequential order on the lifeline. We represent
messages using arrows. Lifelines and messages form the core of a
sequence diagram.
Messages can be broadly classified into the following
• Synchronous messages – A synchronous message waits for a reply before
the interaction can move forward. The sender waits until the receiver has
completed the processing of the message. The caller continues only when
it knows that the receiver has processed the previous message i.e. it
receives a reply message. A large number of calls in object oriented
programming are synchronous. We use a solid arrow head to represent a
synchronous message.
• Asynchronous Messages – An asynchronous message does not wait for a
reply from the receiver. The interaction moves forward irrespective of the
receiver processing the previous message or not. We use a lined arrow
head to represent an asynchronous message.
• Self Message – Certain scenarios might arise where the object needs to
send a message to itself. Such messages are called Self Messages and are
represented with a U shaped arrow.
• Draw the sequence diagram for sending an
email.
• Sequence diagram for online shopping system
example
• Draw the sequence diagram for ATM
A sequence diagram for an music player –
 Collaboration Diagram
• COLLABORATION DIAGRAMS
• The collaboration diagram also comes under the UML representation
which is used to visualize the organization of the objects and their
interaction.
• The collaboration diagram are used to represent the structural
organization of the system and the messages that are sent and received.
• The collaboration diagram is used when object organization is main focus.
• The collaboration diagrams are better suited for depicting simpler
interactions of the smaller number of objects.
• Collaboration Diagram represents the interaction of the objects to
perform the behavior of a particular use case or a part of use case.
• The designers use the Sequence diagram and Collaboration Diagrams to
define and clarify the roles of the objects that perform a particular flow of
events of a use case
• A collaboration diagram resembles a flowchart that portrays the roles,
functionality and behavior of individual objects as well as the overall
operation of the system in real time.
• The four major components of a collaboration diagram are:
• Objects- Objects are shown as rectangles with naming labels inside. The
naming label follows the convention of object name: class name. If an
object has a property or state that specifically influences the
collaboration, this should also be noted.
• Actors- Actors are instances that invoke the interaction in the diagram.
Each actor has a name and a role, with one actor initiating the entire use
case.
• Links- Links connect objects with actors and are depicted using a solid line
between two elements. Each link is an instance where messages can be
sent.
• Messages- Messages between objects are shown as a labeled arrow
placed near a link. These messages are communications between objects
that convey information about the activity and can include the sequence
number.
Collaboration Diagram for e- mail with attachment
 State Transition Diagram
• A state diagram is used to represent the condition of the system or part of
the system at finite instances of time.
• It’s a behavioral diagram and it represents the behavior using finite state
transitions.
• State diagrams are also referred to as State machines and State-chart
Diagrams.
• These terms are often used interchangeably.
• So simply, a state diagram is used to model the dynamic behavior of a
class in response to time and changing external stimuli.
• We can say that each and every class has a state but we don’t model every
class using State diagrams.
• We prefer to model the states with three or more states.
• Uses of state diagram –
• We use it to state the events responsible for change in state (we do not
show what processes cause those events).
• We use it to model the dynamic behavior of the system .
• To understand the reaction of objects/classes to internal or external
stimuli.
• Basic components of a state chart diagram –
• Initial state – We use a black filled circle represent the initial state of a
System or a class.
• Transition – We use a solid arrow to represent the transition or change of
control from one state to another. The arrow is labeled with the event
which causes the change in state.

• State – We use a rounded rectangle to represent a state. A state

represents the conditions or circumstances of an object of a class at an
instant of time.
• Fork – We use a rounded solid rectangular bar to represent a Fork
notation with incoming arrow from the parent state and outgoing arrows
towards the newly created states.
• We use the fork notation to represent a state splitting into two or more
concurrent states.
• Join – We use a rounded solid rectangular bar to represent a Join notation
with incoming arrows from the joining states and outgoing arrow towards
the common goal state. We use the join notation when two or more states
concurrently converge into one on the occurrence of an event or events.
• Self transition – We use a solid arrow pointing back to the state itself to
represent a self transition. There might be scenarios when the state of the
object does not change upon the occurrence of an event. We use self
transitions to represent such cases.
• Steps to draw a state diagram –
• Identify the initial state and the final terminating states.
• Identify the possible states in which the object can exist (boundary values
corresponding to different attributes guide us in identifying different
states).

• Label the events which trigger these transitions.

• Example – state diagram for an online order –
Draw state Diagram for phone call
• Draw state transition diagram or stack
operation