Object Oriented Analysis & Design

Unit -5
UML

The Unified Modeling language (UML) is used to specify, visualize, modify, construct and document the
artifacts of an object oriented software intensive system under development.UML offers a standard way
to visualize a system’s architectural blueprints, including elements such as:

 Actors
 Business processes
 Components
 Activities
 Programming language statements
 Database schemas
 Reusable software components

UML combines techniques from data modeling (entity-relationship diagram), business modeling (work
flows), object modeling and component modeling. It can be used with all processes throughout the
software development life cycle and across different implementation technologies.UML has synthesized
the notations of the Booch method, the object-modeling technique(OMT) and object oriented software
engineering(OOSE) by fusing them into a single, common and widely usable modeling language.UML
aims to be a standard modeling language which can model concurrent and distributed systems.UML is a
de facto industry standard and is evolving under the auspices of the object management group(OMG).
Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled.
Since structure diagrams represent the structure they are used extensively in documenting the
architecture of software systems.

 Class Diagram: describes the structure of a system by showing the system's classes, their
attributes, and the relationships among the classes.
 Component diagram: describes how a software system is split up into components and
shows the dependencies among these components.
 Composite structure Diagram: describes the internal structure of a class and the
collaborations that this structure makes possible.
 Deployment Diagram: describes the hardware used in system implementations and the
execution environments and artifacts deployed on the hardware.

Behavior diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since behavior
diagrams illustrate the behavior of a system, they are used extensively to describe the
functionality of software systems.

 Activity diagram: describes the business and operational step-by-step workflows of components
in a system. An activity diagram shows the overall flow of control.
 UML state machine diagram: describes the states and state transitions of the system.
 Use case diagram: describes the functionality provided by a system in terms of actors, their
goals represented as use cases, and any dependencies among those use cases.

Package Diagram

A package diagram provides the means to organize the artifacts of the development process to clearly
present the analysis of the problem space and the associated design. The specific reasons will be varied
but will either focus on physically structuring the visual model itself or on clearly representing the model
elements through multiple views.

The Notation for the package is a rectangle with a tab on the top left.
Visibility of elements

Access to the services by a group of collaborating classes within a package-or more generically to any
elements within a package is determined by the visibility of the individual elements including nested
packages. The visibility of the elements defined by the containing package to be either public or private,
applies both to contained elements and to those that are imported.

Elements with public visibility can be thought of as a part of the package’s interface
because these elements are visible to all other elements. Those elements with private visibility are not
visible outside the containing package.

 Public (+) : Visible to elements within its containing package, including nested packages and to
external elements.
 Private (-): Visible to elements within its containing packages and to nested packages.

The Dependency Relationship

If an element has the appropriate visibility to afford access, a dependency relationship to it can be
shown representing this access. Dependencies between UML elements are shown an open arrowhead.
The tail of the arrow is located at the element having the dependency (client), and the arrowhead is
located at the element that supports the dependency (supplier).

Import & Access concepts in package diagram

Import and access are really two sides of the same coin-import is a public package import, whereas
access is a private package import. what this really means is that in an import, other elements that have
visibility into the importing package can see the imported items. But when a package performs an access
no other elements can see those elements that have been added to the importing package’s
namespace.
Component Diagram

A component diagram shows the internal structure of components and their dependencies with other
components. This diagram provides the representation of components, collaborating through well-
defined interfaces, to provide system functionality.

In the Unified Modeling Language, a component diagram depicts how

components are wired together to form larger components and or software systems.
Components diagrams are used to illustrate the structure of arbitrarily complex systems.

The Component Notation

Since a component is a structured classifier, its detailed assembly can be shown with a composite
structure using parts, ports and connectors. Its name EnvironmentalControlSystem in this case is
included within the classifier rectangle in bold lettering. In addition one or both of the component tags
should be included: the keyword label <<component>> and the component icon shown in the upper
right-hand corner of the classifier.

On the boundary of the classifier rectangle we have seven ports which are denoted by
small squares. Ports have public visibility unless otherwise noted. Components may also have hidden
ports, which are denoted by same small squares, but they are represented totally inside the boundary of
the composite structure, with only one edge touching its internal boundary. Hidden ports may be used
for capabilities such as test points that are not to be publically available. ports are used by the
component for its interaction with its environment and they provide encapsulation to the structured
classifier.

To the ports we have connected interfaces which define the component’s interface details. The
interface is shown in the ball and socket notation. Provided interfaces use the ball notation to specify
the functionality that the component will provide to its environment; Light Control is an example of
provided interface.

The Component Diagram

Components are wired together by using an assembly connector to connect the required
interface of one component with the provided interface of another component. This illustrates
the service consumer - service provider relationship between the two components.

An assembly connector is a "connector between two components that defines that one
component provides the services that another component requires. An assembly connector is a
connector that is defined from a required interface or port to a provided interface or port."
When using a component diagram to show the internal structure of a component, the provided
and required interfaces of the encompassing component can delegate to the corresponding
interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as
specified by its ports) to the internal realization of that behavior by the component’s parts."

Components Interface

Environmental Controller realizes the cool Control interfaces; this means that it provides the
functionality specified by the interface. This functionality is starting,stopping,setting the
temperature and setting the fan speed for any component using the interface.
 

Figure 1. UML 2.x component diagram.

Deployment Diagram

A deployment diagram is used to show the allocation of artifacts to nodes in the physical design
of a system. A single deployment diagram represents a view into the artifacts structure of a
system. During development we use deployment diagram to indicate the physical collection of
nodes that serve as the platform for execution of our system.

The three essential elements of a deployment diagram are artifacts, nodes and
their connections.

The Artifact Notation

The Node Notation

A node is a computational resource, typically containing memory and processing on which artifacts are
deployed for execution. Nodes may contain other nodes to represent complex execution capability.
There are two types of nodes: devices and execution environments.

A device is a piece of hardware that provides computational capabilities such as a

computer modem or a sensor. An execution environment is software that provides for the development
of specific types of executing artifacts; examples include <<database>> and <<j2EE>>.
Figure 2. Concise UML 2 deployment diagram.
Use Case Diagram

A use case diagram depicts the context of the system to be built and the functionality provided by that
system. Use case diagrams depict who interacts with the system. They show what the outside world
wants the system to do.

Actors

Actors are entities that interface with the system. They can be people or other systems.Actors,which are
external to the system they are using are depicted as:

Use Cases

Use cases represent what the actors want your system to do for them. Use cases are not just any
capability that your system may provide. A use case must be a complete flow of activity, from the actor’s
point of view that provides value to the actor.
 A use case is a specific way of using the system by using some part of the
functionality…A use case is thus a special sequence of related transaction per-formed by an actor and
the system in a dialogue…Each use case is a complete course of events in the system from a user’s
perspective.

The Use Case Diagram

<<Include>> & <<extend>> relationship

During analysis we determine that the Nutrionist actor using that use case will have to see what is in the
crop encyclopedia prior to updating it. This is why the Nutrionist can invoke the view Reports use case.
The same is true for the Gardener actor whenever invoking Maintain Storage Tanks. Neither actor
should be executing the use cases blindly.Therefore, the View Report use case is a common functionality
that both other use cases need. This can be depicted on the case model via an <<include>> relationship.
 In the diagram as the Gardener actor executes the Manage Garden use case, he or she
may want to look at some reports. This could be done by using the View Reports use case. However
View Reports is not required when Manage Garden is run. Manage Garden is completed in and of
itself.So,we modify the use diagram to indicate that the View Reports use case extends the Manage
garden use case as shown…

Activity Diagram

An activity diagram provides the visual depiction of the flow of activities, whether in a system, business,
workflow or other process. These diagrams focus on the activities performed and who is responsible for
the performance of those activities.

The Elements of an activity diagram are action nodes, control nodes and object nodes.
There are three types of control nodes: initial and final (final nodes have two varieties, activity final and
flow final), decision and merge and fork and join.

Actions

Actions are the elemental unit behavior in an activity diagram. Activities can contain many actions which
are what activity diagrams depict.
Starting & Stopping

Since an activity diagram shows a process flow, that flow must start and stop somewhere. The starting
point (initial node) for an activity flow is shown as a solid dot and the stopping point (activity final node)
is shown as a bull’s eye.

Decision & Merge Nodes

Decision and merge nodes control the flow in an activity diagram. Each node is represented by a
diamond shape with incoming and outgoing arrows. A decision node has one incoming flow into one of
the node’s outgoing flows.

Merge nodes take multiple input flows and direct any and all of them to one outgoing flows.
There is no waiting or synchronization at a merge node.
Forks, Joins and Concurrency

Fork and join nodes are analogous to decision and merge nodes respectively. The critical difference is
concurrency. Fork has one flow in and multiple flows out, as do decision node. The difference is where a
decision node selects a single outbound flow a single flow into a fork results in multiple outbound flows.
All the outbound flows occur concurrently.

A join has multiple incoming flows and a single outbound flow, similar to merge
nodes. However, with a join all incoming flows must be completed before the outbound flow
commences.
Class Diagram

A class diagram shows the existence of classes and their relationship in the logical design of a system.
During analysis, class diagram indicate the common roles and responsibilities of the entities that provide
the system’s behavior. During design, class diagrams capture the structure of the classes that form the
system’s architecture.

Overview
The class diagram is the main building block in object oriented modeling. They are being used
both for general conceptual modelling of the systematics of the application, and for detailed
modelling translating the models into programming code. The classes in a class diagram
represent both the main objects and or interactions in the application and the objects to be
programmed. In the class diagram these classes are represented with boxes which contain
three parts:
A class with three sections.

 The upper part holds the name of the class

 The middle part contains the attributes of the class
 The bottom part gives the methods or operations the class can take or undertake

In the system design of a system, a number of classes are identified and grouped together in a
class diagram which helps to determine the statical relations between those objects. With
detailed modeling, the classes of the conceptual design are often split in a number of
subclasses.

In order to further describe the behavior of systems, these class diagrams can be
complemented by state diagram or UML state machine. Also instead of class diagrams Object
role modeling can be used if you just want to model the classes and their relationships.

Members
UML provides mechanisms to represent class members, such as attributes and methods, and
additional information about them.

Visibility

To specify the visibility of a class member (i.e., any attribute or method) there are the following
notations that must be placed before the member's name.

Scope

The UML specifies two types of scope for members: instance and classifier.In the case of
instance members, the scope is a specific instance. For attributes, it means that its value can
vary between instances. For methods, it means that its invocation affects the instance state, in
other words, affects the instance attributes. Otherwise, in the classifier member, the scope is
the class. For attributes, it means that its value is equal for all instances. For methods, it means
that its invocation does not affect the instance state. Classifier members are commonly
recognized as "static" in many programming languages. To indicate that a member has the
classifier scope, its name must be underlined. Otherwise, as default, the instance scope is
considered.

Relationships
A relationship is a general term covering the specific types of logical connections found on class
and object diagrams. UML shows the following relationships:

Instance Level Relationships

External links

A Link is the basic relationship among objects. It is represented as a line connecting two or
more object boxes. It can be shown on an object diagram or class diagram. A link is an instance
of an association. In other words, it creates a relationship between two classes.

Association

Class diagram example of association between two classes

An Association represents a family of links. Binary associations (with two ends) are normally
represented as a line, with each end connected to a class box. Higher order associations can be
drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names,
ownership indicators, multiplicity, visibility, and other properties. There are five different types
of association. Bi-directional and uni-directional associations are the most common ones. For
instance, a flight class is associated with a plane class bi-directionally. Associations can only be
shown on class diagrams. Association represents the static relationship shared among the
objects of two classes. Example: "department offers courses", is an association relation.

Aggregation

Class diagram showing Aggregation between two classes

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific
than association. It is an association that represents a part-whole or part-of relationship. As a
type of association, an aggregation can be named and have the same adornments that an
association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the
contained classes do not have a strong life cycle dependency on the container—essentially, if
the container is destroyed, its contents are not.

In UML, it is graphically represented as a hollow diamond shape on the containing class end of
the tree of lines that connect contained class(es) to the containing class.

Composition

Class diagram showing Composition between two classes at top and Aggregation between two classes at
bottom

Composition is a stronger variant of the "owns a" or association relationship; composition is

more specific than aggregation. It is represented with a solid diamond shape.

Composition usually has a strong life cycle dependency between instances of the container class
and instances of the contained class(es): If the container is destroyed, normally every instance
that it contains is destroyed as well. Note that a part can (where allowed) be removed from a
composite before the composite is deleted, and thus not be deleted as part of the composite.

The UML graphical representation of a composition relationship is a filled diamond shape on

the containing class end of the tree of lines that connect contained class(es) to the containing
class.

Differences between Composition and Aggregation

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a

car, the composition relationship is most appropriate. However, when representing a software
or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an
aggregation relationship is best, as the engine, ENG01 may be also part of a different car model.
Thus the aggregation relationship is often called "catalog" containment to distinguish it from
composition's "physical" containment.
The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must
belong to only one whole; the part may have any multiplicity. For example, consider University
and Department classes. A department belongs to only one university, so University has
multiplicity 1 in the relationship. A university can (and will likely) have multiple departments, so
Department has multiplicity 1..*.

Class Level Relationships

Generalization

Class diagram showing generalization between one superclass and two subclasses

The Generalization relationship indicates that one of the two related classes (the subtype) is
considered to be a specialized form of the other (the super type) and supertype is considered as
'Generalization' of subtype. In practice, this means that any instance of the subtype is also an
instance of the supertype. An exemplary tree of generalizations of this form is found in binomial
nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so
on. The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, a
mammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape on the

supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalization relationship is also known as the inheritance or "is a" relationship.

The supertype in the generalization relationship is also known as the "parent", superclass, base
class, or base type.

The subtype in the specialization relationship is also known as the "child", subclass, derived
class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child relationship: the
use of these terms is extremely common, but can be misleading.

 Generalization-Specialization relationship
 A is a type of B
E. g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

Realization

In UML modeling, a realization relationship is a relationship between two model elements, in

which one model element (the client) realizes (implements or executes) the behavior that the
other model element (the supplier) specifies. A realization is indicated by a dashed line with a
unfilled arrowhead towards the supplier.

Realizations can only be shown on class or component diagrams.

A realization is a relationship between classes, interfaces, components, and packages that

connects a client element with a supplier element. A realization relationship between classes
and interfaces and between components and interfaces shows that the class realizes the
operations offered by the interface.

General Relationship

Class diagram showing dependency between "Car" class and "Wheel" class

Dependency

Dependency is a weaker form of relationship which indicates that one class depends on another
because it uses it at some point of time. Dependency exists if a class is a parameter variable or
local variable of a method of another class.

Multiplicity

The association relationship indicates that (at least) one of the two related classes makes
reference to the other. In contrast with the generalization relationship, this is most easily
understood through the phrase 'A has a B' (a mother cat has kittens, kittens have a mother cat).
The UML representation of an association is a line with an optional arrowhead indicating the
role of the object(s) in the relationship, and an optional notation at each end indicating the
multiplicity of instances of that entity (the number of objects that participate in the
association).

Common multiplicities are:...

0..1 No instances, or one instance (optional, may)

1 Exactly one instance

0..* or * Zero or more instances

1..* One or more instances (at least one)

1..3, 6, 9..* Mixed instances

Analysis Stereotypes
In the early stages of a project's technical analysis, class diagrams can be used to produce early
conceptual models of the system. Classes at this stage often take the form of boundaries,
controls and entities and rarely survive into the design without heavy changes.

Boundaries

Boundary classes handle the communication between actors and the system's internal
components. They might be user interfaces, system interfaces or device interfaces (for
example). They are typically identified by each actor–use-case pair on the system's use-case
diagram.
They are drawn as circles with a short line to the left attached to a vertical line the same height
as the circle (as though it is attached to the side of the use-case system boundary).
Alternatively, they can be drawn as normal classes with the «boundary» stereotype notation
above the class name.

Entities

Entity classes model the information handled by the system, and sometimes the behaviour
associated with the information. They should not be identified as database tables or other data-
stores.

They are drawn as circles with a short line attached to the bottom of the circle. Alternatively,
they can be drawn as normal classes with the «entity» stereotype notation above the class
name

Controls

Control classes handle the flow of control for a use-case and can therefore be seen as co-
ordinating representation classes. These do not do everything in the use case, but co-ordinate
with other classes that can do the work for them.

Composite Structure Diagrams

Composite structure diagram provide a way to depict a structured classifier with the definition of its
internal structure. This internal structure is comprised of parts and their interconnections, all within the
namespace of the composite structure. Structured classifiers can be nested, so each part could be
another structured classifier. This diagram is also useful during design to decompose classes into their
constituent parts and model their runtime collaborations.

The essential elements of a composite structure are its parts, ports, interfaces and
connectors.

Composite structure parts

The composite structure diagram for the Hydroponics Gardening System’s Water Tank is shown. Its
name is placed in the top. Water Tank contains the Heater and tank parts which collaborate to provide
its functionality, that of providing appropriately heated water for the gardeners to use. The name of a
composite structure part uses the format of role name: Class name [multiplicity].
Composite structure ports and interfaces

The composite structure and its parts interface with their external environment through ports, denoted
by a small square on the boundary of the part or composite structure. We see that Heater and Tank
both have ports through which they interact with each other to provide the functionality of water Tank.

Using ports for all interactions provides encapsulation to the structured classifier. These
ports have public visibility unless otherwise noted. Hidden ports are denoted by a small square that
appears totally inside the composite structure, with only one edge touching its boundary. To these
ports, we connect the interfaces that define the details of the composite structure’s interactions. These
interfaces are commonly shown in the ball-and-socket notation.

Timing Diagrams

A timing diagram is used to design and understand time-critical systems. A state machine diagram
expresses behavior as a progression through a series of states, triggered by events and the related
actions that may occur. These are also known as behavioral state machines. Timing diagram are a type
of interaction diagram. Their purpose is to show how the states of an element or elements change over
time ad how events change those states.

Notations & Layout

Timing diagrams have one or more lifelines for each object in the diagram. The possible states of the
object are listed inside the lifeline.Also,a timeline shows how the object changes from one state to
another. Events that drive the state changes are shown along the timeline. The horizontal axis shows
time and may also show tick marks to help the reader of the diagram better understand specific timing.
Alternate Representation

In case where timing diagram have many lifelines or objects that have many states, instead of using a
timeline, we can use a more compact representation as shown.

Communication Diagram

A communication diagram is a type of interaction diagram that focuses on how objects are linked and
the messages they pass, as they participate in a specific interaction.

Objects, Links & Messages

A link may exist between two objects if and only if there is an association between their corresponding
classe.The existences of an association between two classes denotes a path of communication between
instances of the classes, whereby object may send messages to another.
 Given object A with a link L to object B, may invoke any operation that it applicable
to B’s class and accessible to A; the reverse is true for operations invoked by B on A. We will refer to the
object that invokes the operation as client and whichever object provides the operation as the supplier.
In general the sender of a message knows the receiver but the receiver does not necessarily know the
sender.

Messages & Synchronization

In the example the message startup () is an example of a simple call and is represented with a directed
line with a solid arrowhead. This indicates a synchronous message. In the case of the startup () and
isready () messages, the client must wait for the supplier to completely process the message before
control can resume.

In the case of the message turnOn (), the semantics are different. This is an example of an
asynchronous message, indicated by the open arrowhead. Here the client sends the event to the
supplier for processing, the supplier queues the message and the client then proceeds without waiting
for the supplier.
Iteration Clauses & Guards

An iteration clause optionally can be added to indicate a series of messages to be sent. It is shown as an
asterisk followed by the iteration clause in brackets. This example indicates that the turnOn message is
to be sent sequentially, 1 to n times. If the message were to be sent concurrently, the asterisk would be
followed by a double bar (i.e. *||[i=1…n]).

Guard conditions can also adorn message. The notation is similar to an iteration clause,
but without the asterisk. The guard condition is placed within brackets, as shown.
Interaction overview Diagrams

Interaction overview diagrams are a combination of activity diagrams and interaction diagrams that are
intended to provide an overview of the flow of control between interaction diagram elements. Though
any type of interaction diagram may be used, the sequence diagram will likely be the most prevalent.

Frames

The interaction overview diagram is typically surrounded by a frame; however the frame is optional
when the context is clear. We see the surrounding frame with the named sd Maintain Temperature
lifelines: EnvironmentalController,: Heater,:Cooler in the compartment in the upper left-hand corner.
The meaning of this name is as follows:

 Sd: a tag that indicates this is an interaction diagram.

 Maintain Temperature: a name describing the purpose of the diagram

 Lifelines: EnvironmentalController,: Heater,: Cooler.

Sequence Diagram

A sequence diagram is used to trace the execution of a scenario in the same context as a
communication diagram. To a large degree a sequence diagram is simply another way to
represent an object diagram.

The advanyage of using sequence diagram is that it is easier to read the

passing of messages in relative order.Sequence diagram are often better than object diagram for
capturing the semantics of scenarios early in the development lifecycle,before the protocols of
individual classes have been identified.

Lifelines & Messages

In sequence diagram,the entities of interest are written horizontally across the top of the
diagram.A dashed vertical line called the lifeline is drawn below each object.These indicate the
existence of the object.
 Messages are shown horizontally.The endpoints of the message icons connect
with the vertical lines that connect with the entities at the top of the diagram.Messages are
drawn from the sender to the receiver.Ordering is indicated by the vertical position with the first
message shown at the top of the diagram and the last message shown at the bottom.

Execution Specification

Simple sequence diagrams may not indicate the focus of control as messages are passed.For example if
object A sends messages X and Y to other objects,it may not be clear whether X and Y are independent
messages from A or whether they have been invoked as part of the same enclosing message Z.
Control Constructs

Just as we saw fragments being used to simplify sequence diagrams, they can similarly be used
to indicate flow control constructs on sequence diagrams.