UNIT-V

What is an Activity Diagram?

An activity diagram visually presents a series of actions or flow of control in a process.
They are often used for modeling business processes, workflows, data flows and
complex algorithms. They can also describe the steps in a use case diagram. Activities
modeled can be sequential and concurrent. In both cases an activity diagram will have a
beginning and an ending.

Basic Activity Diagram Notations and Symbols

Initial State or Start Point
A small filled circle followed by an arrow represents the initial action state or the start
point for any activity diagram. For activity diagram using swimlanes, make sure the start
point is placed in the top left corner of the first column.

Activity or Action State

An action state represents the non-interruptible action of objects. It is represented using
a rectangle with rounded corners.

Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state
to another. They are usually drawn with an arrowed line.

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow
arrow from an action to an object means that the action creates or influences the object.
An object flow arrow from an object to an action indicates that the action state uses the
object.

Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a
decision prior to moving on to the next activity, add a diamond between the two
activities. The outgoing alternates should be labeled with a condition or guard
expression. You can also label one of the paths "else."

Guards
In UML, guards are a statement written next to a decision diamond that must be true

1
 UNIT-V
before moving next to the next activity. These are not essential, but are useful when a
specific answer, such as "Yes, three names are printed," is needed before moving
forward.

Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is
represented as a straight, slightly thicker line.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.

Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.

Merge Event
A merge event brings together multiple flows that are not concurrent.

Sent and Received Signals

Signals represent how activities can be modified from outside the system. They usually
appear in pairs of sent and received signals, because the state can't change until a
response is received. For example, an authorization of payment is needed before an
order can be completed.

2
 UNIT-V
Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.

Swim lanes
Swim lanes group related activities into one column.

Final State or End Point

An arrow pointing to a filled circle nested inside another circle represents the final action
state.

Example activity diagram for point-of-sale System using swim lanes

What is a Component Diagram?

A Component diagram is used to visualize the physical components in a system. These
components are documents, database table, files, and executables, all physical
elements with a location.

In UML 1.0, components included in these diagrams were physical. In UML 2.0,
these components are less physical and more conceptual stand-alone design elements
such as a business process that provides or requires interfaces to interact with other
constructs in the system. The physical elements described in UML 1, like files and

3
 UNIT-V
documents are now referred to as artifacts.

Component diagrams can be used to :

 Model the components of a system.
 Model the database schema.
 Model the executables of an application.
 Model the system's source code.

Purpose of Component Diagrams

It does not describe the functionality of the system but it describes the components used
to make those functionalities. They can also be described as a static implementation
view of a system. The purpose of the component diagram can be summarized as −
 Visualize the components of a system.
 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.

Basic notations and symbols

Component
A component represents a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces. It may, for example, be
source code, binary, or executable.

It is represented as a rectangle with a smaller rectangle in the upper right corner with
tabs.

A Component can have

1. Interfaces
2. Usage dependencies
3. Ports
4. Connectors
Interface
A component defines its behavior in terms of provided and required interfaces.
An interface
 Is the definition of a collection of one or more abstract operations
 Implementation is normally provided by a class/component
 In complex systems, the physical implementation is provide by a group of classes
rather than a single class.
It may be represented using a rectangle symbol with key word <<interface>> preceding
the name.

4
 UNIT-V

For displaying full signature, the interface rectangle can be expanded to show details.

It can be
 Provided interface
 Required interface

Provided interface
It characterizes the services that the component offers to its environment. It represented
using a circle, labeled with its name, attached by a solid line to the component.

Required interface
It characterizes the services that the component expects from its environment. It
represented using a half-circle, labeled with its name, attached by a solid line to the
component.

When two components/classes provide and require the same interface, these notations
may be combined.

Dependencies
Components can be connected by usage dependencies. A usage dependency is a
relationship which one element requires another element for its full implementation. It is
represented using a dashed arrow with a <<use>> keyword

5
 UNIT-V

Ports

A port specifies an interaction point through which a component can communicate with
its environment, with other components, or with its internal parts. Ports are represented
using a square along the edge of the system or a component. A port is often used to
help expose required and provided interfaces of a component.

An example component diagram for library management system

Deployment Diagram
It shows the assignment of concrete software artifacts to computational nodes. It shows
the deployment of software elements to physical architecture and communication
between elements.

Symbols and Notations

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

1. Device node ( or device): A physical computing resource with processing and

memory services to execute software , such as pc, laptop, mobile phone, etc

2. Execution environment node(EEN): This is a software computing resource

6
 UNIT-V
that runs with in device node. For example:
a. An operating system (OS) is software that hosts and executes programs.
b. A virtual machine hosts and executes programs.
c. A database engine receives SQL program requests and executes them,
and hosts/executes internal stored procedures.
d. A web browser hosts and executes JavaScript, applets, flash and other
executable technologies.
e. A servlet or EJB container

Linux OS Execution Environment Oracle 10g DBMS Execution Environment

Communication Path
A communication path is association between two deployment targets, through which
they are able to exchange signals and messages. It is represented using an undirected
solid line.

Fig. Communication path between several application and database servers.

When deployment targets are some physical devices, communication path will typically
represent a physical connection between the nodes.

Fig. Gigabit Ethernet as communication path between application and database servers.
When deployment targets are execution environments, communication path will typically
represent some protocol.

TCP/IP protocol as communication path between J2EE server and database system.
Deployment
A deployment is a dependency relationship which describes allocation (deployment) of
an artifact to a deployment target. Deployment could be shown as a dependency that is
drawn from the artifact (supplier) to the deployment target (client) and is labeled with
«deploy».
7
 UNIT-V
J2EE web application archive portfolio.war deployed on Apache Tomcat Server.

An example deployment diagram for Point-of-Sale System.

State/ State chart/ State machine Diagram

A UML state machine diagram illustrates the interesting events and states of an object,
and the behavior of an object in reaction to an event.
(Or)
A state machine diagram shows the lifecycle of an object: what events it experiences, its
transitions, and the states it is in between these events.

Definitions
Event: An event is a significant or noteworthy occurrence. For example: A telephone
receiver is taken off the hook.

State: A state is the condition of an object at a moment in time—the time between

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

The UML defines the following kinds of states:

1. simple state,
2. composite state,
8
 UNIT-V
3. Submachine state.
Simple State
A simple state is a state that does not have substates - it has no regions and it has
no sub machine states.

Composite State
Composite state is defined as state that has sub states (nested states). Sub states could
be sequential (disjoint) or concurrent (orthogonal). UML 2.4 defines composite state as
the state which contains one or more regions..

Submachine State
A submachine state specifies the insertion of the specification of a submachine state
machine. The state machine that contains the submachine state is called the containing
state machine. The same state machine may be a submachine more than once in the
context of a single containing state machine.

Transition: 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. Transitions
are shown as arrows, labeled with their event. For example: When the event "off hook"
occurs, transition the telephone from the "idle" to "active" state.

Initial Pseudo state

An initial pseudostate represents start of a state machine. An initial pseudo state is

shown as a small solid filled circle.

Initial pseudostate transitions to Waiting for User Input state

Final State
Final state is a special kind of state signifying that the enclosing region is completed.
A final state is shown as a circle surrounding a small solid filled circle.

Transition to final state.

The below figure represents the state machine diagram for Telephone
9
 UNIT-V

How to apply state machine diagrams?

A state machine diagram may be applied to a variety of UML elements, including:
 State-Independent Objects
 State-Dependent Objects

State-Independent 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. For example, if an object receives
a message, and the responding method always does the samething—the method will
typically have no conditional logic.

State-Dependent Objects
State-dependent objects react differently to events depending on their state. For
example, a telephone is a very state-dependent object. The phone’s reaction to pushing
a particular button depends on the current mode of the phone – offhook, engaged, , in a
configuration subsystem and so on.

Modeling State-Dependent Objects

State machines are applied in two ways:

1. To model the behavior of a complex reactive objects in response to events.

2. To model the legal sequences of operations  protocol or language
specifications.

The following list of common objects which are often state-dependent and which may be
useful to create state machine diagram.

Complex reactive objects

 Physical devices controlled by software.

o Phone ,car, microwave oven: the have complex and rich reactions to
events and the reaction depends upon their current mode
 Transactions and related business objects
o How does a business object (a sale, order, payment ) reaction to event?
For example , what should happen to an order if a cancel event occurs.

10
 UNIT-V
 Role Mutators  These are objects that change their role. Each role is
represented by a state.
o A Person changing roles from being a student to employee.

Protocols and Legal Sequences

1. Communication protocols
2. UI Page/ Window Flow/ Navigation
3. UI Flow Controllers or sessons
4. Use case system operations
5. Individual UI Window Event handling

State machine diagram for POS System

Object Diagram

Object is an instance of a particular moment in runtime, including objects and data

values. A static UML object diagram is an instance of a class diagram.

An object diagram shows a set of objects and their relationships at a point in time. It may
be considered a special case of a class diagram.

Uses
1. It shows a snapshot of the detailed state of a system at a point in time.
2. They are used test accuracy of class diagram.
3. They examine specific iteration of a general system.
4. They are used to represent executable system.

Basic Symbols and Notations

Object Names
Objects are instances of a class. For example, if "car" is a class, a Nissan Sunny is an
object of a class.

11
 UNIT-V
Every object is actually symbolized like a rectangle, that offers the name from the
object and its class underlined as well as divided with a colon.

Object Attributes
Similar to classes, list object attributes inside a separate compartment. However,
unlike classes, object attributes should have values assigned for them.

Links
Links are for connecting different objects. Here we can use all the relationships used in
class diagram like association, composition, generalization, aggregation, etc.

A Sample object diagram for Point-of-Sale System

12
 UNIT - V

Types of Use Cases

There are four types of use cases:

1. Concrete use case

2. Abstract use case
3. Base use case
4. Addition use case

A concrete use case is initiated by an actor and performs the entire behavior desired by
the actor.These are the elementary business process use cases. For example, Process
Sale is a concrete use case.

An abstract use case is never instantiated by itself; it is a sub-function use case that is
part of another use case. HandlePayment is abstract; it is always part of Process Sale
use case.

A use case that includes another use case, or that is extended or specialized by another
use case is called a base use case. Process Sale is a base use case with respect to the
included HandlePayment sub-function use case.

A use case that is an inclusion, extension, or specialization is called an addition use

case. Handle Payment is the addition use case inthe include relationship to Process
Sale. Addition use cases are usually abstract. Base use cases are usually concrete.

Relationships in use cases

In UML, a relationship is a connection between modeling elements. A UML relationship is a
type of model element that adds semantics to a model by defining the structure and behavior
between the model elements.

There can be 5 relationship types in a use case diagram.

1. Association between actor and use case

2. Generalization of an actor
3. Generalization of a use case
4. Extend between two use cases
5. Include between two use cases

1. Association between actor and use case

Each use case represents a unit of useful functionality that subjects provide to actors.
An association between an actor and a use case indicates that the actor and the use
case somehow interact or communicate with each other. It can be represented using
solid line.

Points to remember:
1. Only binary associations are allowed between actors and use cases.
2. An actor must be associated with at least one use case.
3. An actor can be associated with multiple use cases.
4. Multiple actors can be associated with a single use case.
 UNIT - V

Example

If there are several actors associated to the same use case, it may not be obvious from
use case diagram which actor initiates the use case, i.e. is a "primary actor". (In non-
standard UML, primary actors are those using system services, and supporting
actors are actors providing services to the system).

2. Generalization of an actor
A generalization is a binarydirected relationship between a more generalthing(super
class)and a more specific kind of that thing (subclass).

Generalization of an actor means that one actor can inherit the role of the other actor.
The descendant inherits all the use cases of the ancestor. The descendant has one or
more use cases that are specific to that role.

Generalization between actors is rendered as a solid directed line with a large hollow
triangle arrowhead.

For Example

3. Generalization of a use case

Generalization of use cases is similar to generalization between classes – child use case
inherits properties and behavior of the parent use case and may override the behavior of
the parent.

Generalization is shown as a solid directed line with a large hollow triangle arrowhead,
 UNIT - V

the same as for generalization between actors, directed from the more specific use case
to the general use case.

4. Include between two use cases

Use case include is a directed relationship between two use cases which is used to
show that behavior of the included use case (addition) is inserted into the behavior of
the including use case (base).
Theinclude relationship could be used:

 To simplify large use case by splittingit into several use cases,

 To extract common parts of the behaviors of two or more use cases.

Include relationship between usecases is shown by a dashed arrow with an open

arrowhead from the including (base) use case to the included (common part) use case.
The arrow is labeled with the keyword «include».

Case 1: Example
A large use case could have some behaviors which might be detached into distinct
smaller use cases to be included back into the base use case using the UML include
relationship.

Fig. Use cases B and C are extracted from larger use case A into separate use cases.
For example, Checkout use case includes several use cases - Scan Item, Calculate
Total and Tax, and Payment
 UNIT - V

Case2: Example
When two or more use cases have some common behavior, this common part could be
extracted into a separate use case to be included back by the use cases with the
UML include relationship.

Fig. Use case C is extracted from use cases A and B to be reused by both use cases

For example, DepositFunds and WithdrawCash use cases include Update Balance
use case.

5. Extend between two use cases

Extend is a directed relationship that specifies how and when the behavior defined in
supplementary (optional) extending use case can be inserted into the behavior defined
in the extended use case.

Extend relationship between usecases is shown by a dashed arrow with an open

arrowhead from the extending (optional) use case to the extended (base) use case. The
arrow is labeled with the keyword «extend».

Here are few things to consider when using the <<extend>> relationship.
1. The extending use case is dependent on the extended (base) use case.
2. The extending use case is usually optional and can be triggered conditionally.
3. The extended (base) use case must be meaningful on its own.

Example:
 UNIT - V

1. In the above diagram the “Calculate Bonus” use case doesn’t make much sense
without the “Deposit Funds” use case.
2. In the diagram, you can see that the extending use case is triggered only for
deposits over 10,000 or when the age is over 55.
3. This means it should be independent and must not rely on the behavior of the
extending use case.

Domain Model Refinement

Generalization in UML
A generalization is a binary directed relationship between a more general thing (parent)
and a more specific kind of that thing (child).

Generalization is the activity of identifying commonality among concepts and defining

super class (general concept) and subclass (specialized concept) relationships. It is a
way to construct taxonomic classifications among concepts which are then illustrated in
class hierarchies.

Identifying a super class and subclasses is of value in a domain model because their
presence allows us to understand concepts in more general, refined and abstract terms.
It leads toeconomy of expression, improved comprehension and a reduction in repeated
information.

The concepts CashPayment, CreditPayment, andCheckPayment are all very similar. In

this situation, it is possible to organize them into a generalization-specialization class
hierarchy in which the superclass Payment represents a more general concept, and the
subclasses more specialized ones.
 UNIT - V

Fig. Generalization - Specialization hierarchy.

In UML, the generalization relationship between elements is shown as a solid line with a
large hollow triangle arrowhead pointing to the more general element from the more
specialized one. Either a separate-target or shared-target arrow style may be used.

CashPayment, CreditPayment, and CheckPayment are generalized by Payment. This

notation is referred to as the "separate-target style."

Fig.Class hierarchy with separate-target style notation.

Generalization relationships that reference the same general classifier can also be
connected together in the "shared-target style."

Fig.Class hierarchy with shared-target style notation.

Defining Conceptual Super classes

Definition: A conceptual super class definition is more general than a subclass
definition.

For example, consider the superclass Payment and its subclasses (CashPayment,
CreditPayment, and CheckPayment).Assume the definition of Payment is that it
represents the transaction of transferring money for a purchase from one party to
another, and that all payments have an amount of money transferred. The model
 UNIT - V

corresponding to this is shown in Figure.

Fig. Payment class hierarchy.

Generalization and class sets

Conceptual subclasses and super classes are related in terms of set membership.

Definition: All members of a conceptual subclass set are members of their super class
set.

For example, in terms of set membership, all instances of the set Credit Payment are
alsomembers of the set Payment. In a Venn diagram, this is shown as:

Fig. Venn diagram of set relationships.

When to Define a Conceptual Super class?

Start with a set of sub-classes and look for commonalities that help the model. Create a
superclass in a generalization relationship to subclasses when:
1. The potential conceptual subclasses represent variations of a similar concept.
2. The subclasses will conform to the 100% and Is-a rules.
3. All subclasses have the same attribute that can be factored out.
4. All subclasses have the same association that can be factored out.

Defining Conceptual Subclasses

Definition: A potential subclass should conform to the:
1. 100% Rule (definition conformance)
2. Is-a Rule (set membership conformance)

What is 100% rule?

100% of the conceptual super class's definition should be applicable to the subclass. The
subclass must conform to 100% of the super class's:
 attributes
 associations
 UNIT - V

For example, below figure states that all Payments have an amount and are associated
with a Sale. All Payment subclasses also have an amount and paying for a Sale. This rule
of conformance to a super class definition is the 100% Rule.

What is is-A rule?

All the members of a subclass set must be members of their superclass set.

For example: CreditPaymentshould be a member of the set of Payments. Informally, this

expresses CreditPayment is-a Payment. This kind of conformance is the Is-a Rule.

When to Define a Conceptual Subclass?

Start with the super-class and look at differences to find the sub-classes that make
sense. Create a conceptual subclass of a superclass when:
1. The subclass has additional attributes.
2. The subclass has additional associations.
3. The subclass usage is differs from super class.
4. The subclass concept represents an animate thing (for example, animal,
robot)that behaves differently than the super class or other subclasses.

For example: In POS, men and women pay different amounts based different criteria,
e.g. have specific gender and age discounts. It is only useful for POS

Customer Correct subclasses.

But useful?

Male Female
Customer Customer

Abstract Conceptual Classes

If every member of a “class C” must also be a member of a subclass, then “class C” is
called an abstract conceptual class.

For example, assume that every Payment instance must more specifically be an
instance of the subclass CreditPayment, CashPayment, or CheckPayment. This is
illustrated in the below Venn diagram. Since every Payment member is also a member
of a subclass, Payment is anabstract conceptual class by definition.
 UNIT - V

Abstract Class Notation in the UML

The UML provides a notation to indicate abstract classes the class name is italicized.

Payment abstract class

indicated by italics
amount : Money

Cash Credit Check

Payment Payment Payment

Association Classes
In a domain model, if a class C can simultaneously have multiple values for the same
kind of attribute A, then place attribute A in another class that is associated with C.

An association class is a class that is part of an association relationship between two

other classes and allows you to add attributes, operations, and other features to
associations. An association class is connected to an association by a dotted line.

When to use association class

 An attribute is related to the association, not a class
 Instances of association class have a lifetime dependency on the association
 Many-to-many associations between two concepts can produce multiple values
simultaneously.
 UNIT - V

Association Role Names

Each end of an association is a role, which has various properties, such as:
 Name
 Multiplicity

A role name identifies an end of an association and describes the role played by objects
in the association. Below figure shows role name example:

It usually starts with a lowercase letter. If not explicitly present, assume that the default
role name is equal to the related class name, though starting with a lowercase letter.

Roles as Concepts versus Roles in Associations

In a domain model, a real-world role specially a human role may be modeled in a
number of ways, such as a discrete concept, or expressed as a role in an association.

For example, the role of cashier and manager may be expressed in at least the two
ways illustrated in Figure.

Roles in associations are interesting because they are a relatively accurate way to
express the notion that the same instance of a person takes on multiple (and
dynamically changing) roles in various associations.

roles as concepts provides ease and flexibility in adding unique attributes,

associations, and additional semantics.
 UNIT - V

Reflexive Associations
A concept may have an association to itself; this is known as a reflexive association.

Qualified Associations
A qualifier may be used in an association; it distinguishes the set of objects at the far
end of the association based on the qualifier value. An association with a qualifier is a
qualified association.

Fig. Qualified associations in UML.

Qualification reduces the multiplicity at the target end of the association, usually down
from many to one.

Derived Elements
A derived element can be determined from others. Attributes and associations are the
most common derived elements. In the UML, it is shown with a "/" preceding the element
name.

For example, a Sale total can be derived from SalesLineItem and ProductDescriptions
information.

Another Example, a SalesLineItem quantity is actually derivable from the number of

instances of Items associated with the line item.
 UNIT - V

Aggregation
Aggregation is a special form of association that models a whole-part relationship
between an aggregate (the whole) and its parts. This kind of relationship is called
aggregation.

It is a "weak" form of aggregation when part instance is independent of the whole. Whole
is usually referred to as composite.

It is represented using solid line with hollow diamond symbol pointing to the whole part.

Shared aggregation has the following characteristics:

 It is binary association,
 It is asymmetric - only one end of association can be an aggregation.
 It is transitive - aggregation links should form a directed, acyclic graph, so that no
composite instance could be indirect part of itself,
 The small part can exist independently of the composite.

Example:

Composition
Composite aggregation (composition) is a "strong" form of aggregation with the
following characteristics:
 It is binary association,
 It is a whole/part relationship,
 A part could be included in at most one composite (whole) at a time, and
 If a composite (whole) is deleted, all of its composite parts are "normally" deleted
with it.
It is represented using solid line with filled diamond symbol pointing to the whole
part.
 UNIT - V

Example:

Using Packages to Organize the Domain Model

A domain model can easily grow large enough that it is desirable to factor it into
packages of strongly related concepts. A package is a general purpose mechanism for
organizing elements into groups. Packages help you organize the elements in your
models so that you can more easily understand them.

A UML package is shown as a tabbed folder. Subordinate packages may be shown

within it. The package name is within the tab if the package depicts its elements;
otherwise, it is centered within the folder itself.

Fig. A UML Package

Ownership and References
An element is owned by the package within which it is defined, but may be referenced in
other packages. In that case, the element name is qualified by the package name using
the pathname format PackageName::ElementName.(see below Figure).

A class shown in a foreign package may be modified with new associations, but must
otherwise remain unchanged.

Fig. A referenced class in a package

 UNIT - V

Package Dependencies
A package dependency indicates that elements of the dependent package in some way
know about or are coupled to elements in the target package such the dependency may
be shown with a dependency relationship, depicted with an arrowed line.

For example, if a package references an element owned by another, a dependency

exists. Thus, the Sales package has a dependency on the Core Elements package (see
below figure).

Fig. A package dependency

How to Partition the Domain Model

To partition the domain model into packages, place elements together that:
 are in the same subject area - closely related by concept or purpose.
 are in a class hierarchy together.
 participate in the same use cases.
 are strongly associated

It is useful if all elements related to the domain model are rooted in a package called
Domain, and all widely shared, common, core concepts are defined in a packaged
named something like Core Elements or Common Concepts, in the absence of any other
meaningful package within which to place them.

POS Domain Model Packages

Based on the above criteria, the package organization for the POS Domain Model is
shown in below Figure.

Fig. Domain Concept packages