Later on, behavioral models and state-charts were introduced in the UML which were invented by

David Harel.

UML was recognized as a standard by Object Management Group (OMG) during 1997. Object
Management Group is responsible for managing UML ever since it was adopted as a standard.

In 2005, the International Organization for Standardization approved UML as an ISO standard. It is
used in various industries for creating object-oriented models.

The latest UML version is 2.5.1 which was released in December 2017.

UML Versions
Date Version About
UML was adopted by Object Management
November 1997 1.1
Group. This was the first version of UML.
A minor upgrade was done to the existing
March 2000 1.3 model with notable changes in semantics,
notations, and meta-models of UML.
This was the period of the major update to the
UML. It scaled UML by providing various
September 2001 1.4
extensions. Visibility, artifact, stereotypes were
introduced in diagrams.
Features such as procedures, data flow
March 2003 1.5
mechanism were added to the UML.
January 2005 1.4.2 UML was accepted as a standard by ISO.
New diagrams such as the object, package,
timing, interaction were added to the UML.
New features were added to the activity and
August 2005 2.0 sequence diagrams. Collaboration diagram
was renamed as communication diagram.
Multiple features and changes were introduced
in the existing diagrams.
April 2006 2.1 Corrections were made to the UML 2.0.
February 2007 2.1.1 Upgrades were introduced in the UML 2.1.
November 2007 2.1.2 UML 2.1.1 was redefined.
February 2009 2.2 UML 2.1.2 bugs were fixed.
UML 2.2 was revised, and minor changes were
May 2010 2.3
made to the component diagrams.
Classes, packages, and stereotypes changes
August 2011 2.4.1 were made. UML 2.3 was revised with
enhancement features.
UML 2.4.1 was revised with minor changes.
UML was made simple than it was before.
Rapid functioning and the generation of more
June 2015 2.5
effective models were introduced. Outdated
features were eliminated. Models, templates
were eliminated as auxiliary constructs.
Characteristics of UML
1. It is a generalized modeling language.
2. It is different from software programming languages such as Python, C, C++, etc.
3. It is a pictorial language which can be used to generate powerful modeling elements.
4. It is related to object-oriented designs and analysis.

3
 5. It has unlimited applications even outside the software industry. It can be used to visualize
the workflow of a factory.

Conceptual model
Before beginning with the UML concept, one must understand the basics of the conceptual model.

A conceptual model is made up of various concepts which are interrelated. It helps us to

understand

 What the objects are?

 How interaction takes place to execute a process?

A conceptual model is required in UML. You have to understand the entities and relationships
between them before actually modeling the system.

Following object-oriented concepts are required to begin with UML:

 Object: It is a real-world entity. There are multiple objects available within a single system.
It is a fundamental building block of UML.
 Class: A class is nothing but a container where objects and their relationships are
maintained.
 Abstraction: It is a mechanism of representing an entity without showing the
implementation details. It is used to visualize the behavior of an object.
 Inheritance: It is a mechanism of extending an existing class to create a new class.
 Polymorphism: It is a mechanism of representing an object having multiple forms which
are used for different purposes.
 Encapsulation: It is a method of binding the object and the data together as a single unit. It
ensures tight coupling between the object and the data.

Above are also called as the basic building blocks of a UML.

UML Diagrams
UML diagrams are the output of the Unified Modeling Language. It is a pictorial representation of
classes, objects, and relationships between them. UML diagram is a model that describes a part of
a system. It is used to define the functionality or a design of a system. A diagram must be clear
and concise so that the viewer will readily understand it.

UML diagrams are divided into three different categories such as,

 Structural diagram
 Behavioral diagram
 Interaction diagram

Structural diagrams
Structural diagrams are used to represent a static view of a system. It represents a part of a
system that makes up the structure of a system. A structural diagram shows various objects within
the system.

Following are the various structural diagrams in UML:

4
  Class diagram
 Object diagram
 Package diagram
 Component diagram
 Deployment diagram

Behavioral diagrams
Any real-world system can be represented in either a static form or a dynamic form. A system is
said to be complete if it is expressed in both the static and dynamic ways. The behavioral diagram
represents the functioning of a system.

UML diagrams that deals with the static part of a system are called structural diagrams. UML
diagrams that deals with the moving or dynamic parts of the system are called behavioral
diagrams.

Following are the various behavioral diagrams in UML:

 Activity diagram
 Use case diagram
 State machine diagram

Interaction diagrams
Interaction diagram is nothing but a subset of behavioral diagrams. It is used to visualize the flow
between various use case elements of a system. Interaction diagrams are used to show an
interaction between two entities and how data flows within them.

Following are the various interaction diagrams in UML:

 Timing diagram
 Sequence diagram
 Collaboration diagram

The detailed explanation of the above diagrams is explained in further tutorials.

UML Tools
There are many tools available in the market to generate UML diagrams. Some are desktop based
while others can be used online. Following is a curated list of tools which can be used for the
creation of UML models:

 Star UML
 Argo UML
 Dia
 Visual Paradigm
 U-Model
 UML lab
 Enterprise Architect

5
 Summary
 UML stands for unified modeling language.
 It is used for creating object-oriented models for representing the design and functioning of
a system.
 It was developed by Grady Booch, Ivar Jacobson, and James Rumbaugh.
 UML is a successor of object-oriented languages, but it is far different than them.
 Structural, behavioural, and interaction are three types of UML diagrams.
 UML is recognized as an ISO standard which is used by many industries for developing
documentation and model blueprints.

Goal of uml
 Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
 Provide extensibility and specialization mechanisms to extend the core concepts.
 Be independent of particular programming languages and development processes.
 Provide a formal basis for understanding the modeling language.
 Encourage the growth of the OO tools market.
 Support higher-level development concepts such as collaborations, frameworks, patterns
and components.
 Integrate best practices.

What're the Purposes of UML?

 To reason about system behavior.

 To detect errors and omissions early in the life cycle.

 To present proposed designs and communicate with stakeholders.

 To understand requirements.

 To drive implementation.

UML Views
UML plays an important role in defining different perspectives of a system. These
perspectives are −

● Design
● Implementation

6
 ● Process
● Deployment

The center is the Use Case view which connects all these four. A Use Case represents the
functionality of the system. Hence, other perspectives are connected with use case.

Design of a system consists of classes, interfaces, and collaboration. UML provides class
diagram, object diagram to support this.

Implementation defines the components assembled together to make a complete physical

system. UML component diagram is used to support the implementation perspective.

Process defines the flow of the system. Hence, the same elements as used in Design are
also used to support this perspective.

Deployment represents the physical nodes of the system that forms the hardware. UML
deployment diagram is used to support this perspective.

7
RELATIONSHIPS IN UML
In UML modeling, a relationship is a connection between two or more UML model
elements that adds semantic information to a model.
In the product, you can use several UML relationships to define the structure
between model elements. Examples of relationships include associations,
dependencies, generalizations, realizations, and transitions.

Relationship Description

Association An association relationship is a structural

relationship between two model elements that
shows that objects of one classifier (actor, use case,
class, interface, node, or component) connect and
can navigate to objects of another classifier. Even in
bidirectional relationships, an association connects
two classifiers, the primary (supplier) and secondary
(client),

Dependency A dependency relationship indicates that changes to

one model element (the supplier or independent
model element) can cause changes in another
model element (the client or dependent model
element). The supplier model element is
independent because a change in the client does
not affect it. The client model element depends on
the supplier because a change to the supplier
affects the client.

Generalization A generalization relationship indicates that a

specialized (child) model element is based on a
general (parent) model element. Although the parent
model element can have one or more children, and
any child model element can have one or more
parents, typically a single parent has multiple
children. In UML 2.0, several classes can constitute
a generalization set of another class. Generalization
relationships appear in class, component, and
use-case diagrams.

8
Realization A realization relationship exists between two model
elements when one of them must realize, or
implement, the behavior that the other specifies. The
model element that specifies the behavior is the
supplier, and the model element that implements the
behavior is the client. In UML 2.0, this relationship is
normally used to specify those elements that realize
or implement the behavior of a component.

EXTENSIBILITY MECHANISMS IN UML.

Basically Extensibility mechanism allows you to extend and customize UML by adding
new building blocks, creating new properties and specifying new semantics in order to make
the language suitable to your specific problem domain.
There are 3 Type of extensibility mechanisms:
1. Stereotypes.
2. Tagged Values.
3. Constraints.

Stereotypes:

Stereotypes allow you to increase vocabulary of UML. You can add, create new model
elements, derived from existing ones but that have specific properties that are suitable to
your problem domain. Stereotypes are used to introduce new building blocks that speak the
language of your domain and look primitive. It allows you to introduce new graphical
symbols.
For example: When modeling a network you might need to have symbols for router,
switches , hubs etc. A stereotype allows you to make these things appear as primitive.

Tagged Values:

Tagged values are used to extend the properties of UML so that you can add additional
information in the specification of a model element. It allows you to specify keyword value
pairs of a model where keywords are the attributes. Tagged values are graphically rendered
as string enclose in brackets.
For Example: Consider a release team responsible for assembling, testing and deployment
of a system. In such case it is necessary to keep a track on version and test results of the
main subsystem. Tagged values are used to add such info.
Tagged values can also be used to add administrative info such as author name, date
modifies etc.

9
Constraints:

They are the properties for specifying semantics or conditions that must be held true at all
the time. It allows you to extend the semantics of UML building block by adding new
protocols. Graphically a constraint is rendered as string enclose in brackets placed near
associated element.
For example: In development of a real time system it is necessary to adorn the model with
some necessary information such as response time.

UNIFIED PROCESS
The Unified Software Development Process or Unified Process is an iterative and
incremental software development process framework. The best-known and extensively
documented refinement of the Unified Process is the Rational Unified Process (RUP). Other
examples are OpenUP and Agile Unified Process.
The Unified Process is not simply a process, but rather an extensible framework which should be
customized for specific organizations or projects. The Rational Unified Process is, similarly, a
customizable framework. As a result, it is often impossible to say whether a refinement of the
process was derived from UP or from RUP, and so the names tend to be used interchangeably.
The name Unified Process as opposed to Rational Unified Process is generally used to describe
the generic process, including those elements which are common to most refinements.

Project lifecycle (Phases of Unified Process)

The Unified Process divides the project into four phases:
● Inception
● Elaboration (milestone)
● Construction (release)
● Transition (final production release)

Inception phase
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception
Phase is long then it may be an indication of excessive up-front specification, which is contrary to
the spirit of the Unified Process.
The following are typical goals for the Inception phase:
● Establish
● Prepare a preliminary project schedule and cost estimate
● Feasibility
● Buy or develop it
The Lifecycle Objective Milestone marks the end of the Inception phase.

10
Develop an approximate vision of the system, make the business case, define the scope, and
produce rough estimate for cost and schedule.

Elaboration phase
During the Elaboration phase, the project team is expected to capture a healthy majority of the
system requirements. However, the primary goals of Elaboration are to address known risk
factors and to establish and validate the system architecture. Common processes undertaken in
this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with
only basic notation) and package diagrams (architectural diagrams).
The architecture is validated primarily through the implementation of an Executable Architecture
Baseline. This is a partial implementation of the system which includes the core most
architecturally significant components. It is built in a series of small time-boxed iterations. By the
end of the Elaboration phase, the system architecture must have stabilized and the executable
architecture baseline must demonstrate that the architecture will support the key system
functionality and exhibit the right behavior in terms of performance, scalability, and cost.
The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the
Construction phase. At this point the plan should be accurate and credible since it should be
based on the Elaboration phase experience and since significant risk factors should have been
addressed during the Elaboration phase.

Construction phase
Construction is the largest phase of the project. In this phase, the remainder of the system is built
on the foundation laid in Elaboration. System features are implemented in a series of short,
time-boxed iterations. Each iteration results in an executable release of the software. It is
customary to write full-text use cases during the construction phase and each one becomes the
start of a new iteration. Common Unified Modeling Language (UML) diagrams used during this
phase include activity diagrams, sequence diagrams, collaboration diagrams, State Transition
diagrams and interaction overview diagrams. Iterative implementation for the lower risks and
easier elements are done. The final Construction phase deliverable is software ready to be
deployed in the Transition phase.

Transition phase
The final project phase is Transition. In this phase the system is deployed to the target users.
Feedback received from an initial release (or initial releases) may result in further refinements to
be incorporated over the course of several Transition phase iterations. The Transition phase also
includes system conversions and user training.

11
 Profile of a typical project showing the relative sizes of the four phases of the Unified Process.

Unified Process characteristics

Iterative and incremental

Diagram illustrating how the relative emphasis of different disciplines changes over the course of the
project

The Unified Process is an iterative and incremental development process. The Elaboration,
Construction and Transition phases are divided into a series of timeboxed iterations. (The
Inception phase may also be divided into iterations for a large project.) Each iteration results in
an increment, which is a release of the system that contains added or improved functionality
compared with the previous release.

12
 Although most iterations will include work in most of the process disciplines (e.g. Requirements,
Design, Implementation, Testing) the relative effort and emphasis will change over the course of
the project.

Architecture-centric
The Unified Process insists that architecture sits at the heart of the project team's efforts to
shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified
Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline
which is created during the Elaboration phase. This partial implementation of the system serves
to validate the architecture and act as a foundation for remaining development.

Risk-focused
The Unified Process requires the project team to focus on addressing the most critical risks early
in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase,
must be selected in order to ensure that the greatest risks are addressed first.

What is a Functional Requirement?

A functional requirement defines a system or its component. It describes the functions a software
must perform. A function is nothing but inputs, its behavior, and outputs. It can be a calculation,
data manipulation, business process, user interaction, or any other specific functionality which
defines what function a system is likely to perform.

Functional software requirements help you to capture the intended behavior of the system. This
behavior may be expressed as functions, services or tasks or which system is required to perform.

What is Non-Functional Requirement?

a non-functional requirement defines the quality attribute of a software system. They represent a
set of standards used to judge the specific operation of a system. Example, how fast does the
website load?

A non-functional requirement is essential to ensure the usability and effectiveness of the entire
software system. Failing to meet non-functional requirements can result in systems that fail to
satisfy user needs.

Non-functional Requirements allows you to impose constraints or restrictions on the design of the
system across the various agile backlogs. Example, the site should load in 3 seconds when the
number of simultaneous users are > 10000. Description of non-functional requirements is just as
critical as a functional requirement.

13
 Example of Functional Requirements
 The software automatically validates customers against the ABC Contact Management
System
 The Sales system should allow users to record customers sales
 The background color for all windows in the application will be blue and have a
hexadecimal RGB color value of 0x0000FF.
 Only Managerial level employees have the right to view revenue data.
 The software system should be integrated with banking API
 The software system should pass Section 508 accessibility requirement.

Examples of Non-functional requirements

Here, are some examples of non-functional requirement:

1. Users must change the initially assigned login password immediately after the first
successful login. Moreover, the initial should never be reused.
2. Employees never allowed to update their salary information. Such attempt should be
reported to the security administrator.
3. Every unsuccessful attempt by a user to access an item of data shall be recorded on an
audit trail.
4. A website should be capable enough to handle 20 million users with affecting its
performance
5. The software should be portable. So moving from one OS to other OS does not create any
problem.
6. Privacy of information, the export of restricted technologies, intellectual property rights, etc.
should be audited.

Functional vs Non Functional Requirements

Parameters Functional Requirement Non-Functional Requirement

What it is Verb Attributes
Requirement It is mandatory It is non-mandatory
Capturing type It is captured in use case. It is captured as a quality attribute.
End-result Product feature Product properties
Capturing Easy to capture Hard to capture
Helps you verify the functionality of Helps you to verify the performance of
Objective
the software. the software.
Area of focus Focus on user requirement Concentrates on the user's

14
Parameters Functional Requirement Non-Functional Requirement
expectation.
Documentation Describe what the product does Describes how the product works
Functional Testing like System, Non-Functional Testing like
Type of
Integration, End to End, API testing, Performance, Stress, Usability,
Testing
etc. Security testing, etc.
Test Execution is done before non-
Test Execution After the functional testing
functional testing.
Product Info Product Features Product Properties
Advantages of Functional Requirement
Here, are the pros/advantages of creating a typical functional requirement document-

 Helps you to check whether the application is providing all the functionalities that were
mentioned in the functional requirement of that application
 A functional requirement document helps you to define the functionality of a system or one
of its subsystems.
 Functional requirements along with requirement analysis help identify missing
requirements. They help clearly define the expected system service and behavior.
 Errors caught in the Functional requirement gathering stage are the cheapest to fix.
 Support user goals, tasks, or activities for easy project management
 Functional requirement can be expressed in Use Case form or user story as they exhibit
externally visible functional behavior.

Advantages of Non-Functional Requirement

Benefits/pros of Non-functional testing are:

 The nonfunctional requirements ensure the software system follow legal and compliance
rules.
 They ensure the reliability, availability, and performance of the software system
 They ensure good user experience and ease of operating the software.
 They help in formulating security policy of the software system.

Summary:
 A functional requirement defines a system or its component
 A non-functional requirement defines the performance attribute of a software system.
 Functional requirements along with requirement analysis help identify missing requirements
 The advantage of Non-functional requirement is that it helps you to ensure good user
experience and ease of operating the software
 Transaction corrections, adjustments, and cancellations, Business Rules, Certification
Requirements, Reporting Requirements, Administrative functions, Authorization levels,
Audit Tracking, External Interfaces, Historical Data management, Legal or Regulatory
Requirements are various types of functional requirements
 Types of Non-functional requirement are Scalability Capacity, Availability, Reliability,
Recoverability, Data Integrity, etc.
 Functional Requirement is a verb while Non-Functional Requirement is an attribute

15
USE CASE MODELING
Use Case Modeling/Diagram
A use-case model is a model of how different types of users interact with the system to solve
a problem. As such, it describes the goals of the users, the interactions between the users
and the system, and the required behavior of the system in satisfying these goals.
A use-case model consists of a number of model elements. The most important model
elements are: use cases, actors and the relationships between them.
A use-case diagram is used to graphically depict a subset of the model to simplify
communications. There will typically be several use-case diagrams associated with a given
model, each showing a subset of the model elements relevant for a particular purpose. The
same model element may be shown on several use-case diagrams, but each instance must
be consistent. If tools are used to maintain the use-case model, this consistency constraint
is automated so that any changes to the model element (changing the name for example)
will be automatically reflected on every use-case diagram that shows that element.
The use-case model may contain packages that are used to structure the model to simplify
analysis, communications, navigation, development, maintenance and planning.
Much of the use-case model is in fact textual, with the text captured in the Use-Case
Specifications that are associated with each use-case model element. These specifications
describe the flow of events of the use case.
The use-case model serves as a unifying thread throughout system development. It is used
as the primary specification of the functional requirements for the system, as the basis for
analysis and design, as an input to iteration planning, as the basis of defining test cases and
as the basis for user documentation

Basic model elements

The use-case model contains, as a minimum, the following basic model elements.

Actor
A model element representing each actor. Properties include the actors name and brief
description.

Use Case
A model element representing each use case. Properties include the use case name and
use case specification.

Associations
Associations are used to describe the relationships between actors and the use cases they
participate in. This relationship is commonly known as a “communicates-association”.

Advanced model elements

The use-case model may also contain the following advanced model elements.

16
Subject
A model element that represents the boundary of the system of interest.

Use-Case Package
A model element used to structure the use case model to simplify analysis, communications,
navigation, and planning. If there are many use cases or actors, you can use use-case
packages to further structure the use-case model in much the same manner you use folders
or directories to structure the information on your hard-disk.
You can partition a use-case model into use-case packages for several reasons, including:
● To reflect the order, configuration, or delivery units in the finished system thus
supporting iteration planning.
● To support parallel development by dividing the problem into bite-sized pieces.
● To simplify communication with different stakeholders by creating packages for
containing use cases and actors relevant to a particular stakeholder.

Generalizations
A relationship between actors to support re-use of common properties.

Dependencies
A number of dependency types between use cases are defined in UML. In particular,
<<extend>> and <<include>>.
<<extend>> is used to include optional behavior from an extending use case in an extended
use case.
<<include>> is used to include common behavior from an included use case into a base
use case in order to support re-use of common behavior.
The latter is the most widely used dependency and is useful for:
● Factoring out behavior from the base use case that is not necessary for the
understanding of the primary purpose of the use case to simplify communications.
● Factoring out behavior that is in common for two or more use cases to maximize
re-use, simplify maintenance and ensure consistency.

Example Use-Case Diagram

Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case
model.

17
 Figure 1: ATM Use-Case Diagram

This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and
Maintenance Person), five use cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill
Machine and Validate User), three <<includes>> dependencies, and the associations
between the performing actors and the use cases.
The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how
the customer is identified to the system. This behavior can be extracted to a new inclusion
use case called Validate User, which the three base use cases <<include>>. The base use
cases are independent of the method used for identification, and it is therefore encapsulated
in the inclusion use case. From the perspective of the base use cases, it does not matter
whether the method for identification is to read a magnetic bank card, or perform a retinal
scan. They only depend on the result of Validate Customer.

FINDING ACTORS AND USE CASES

Finding Actors
Find the external entities with which the system under development must interact.
Candidates include groups of users who will require help from the system to perform their
tasks and to execute the system's primary or secondary functions, as well as external
hardware, software, and other systems.

18
Define each candidate Actor by naming it and writing a brief description. Include the Actor's
area of responsibility and the goals that the Actor will attempt to accomplish when using the
system. Eliminate Actor candidates who do not have any goals. For more information on
Actors and their properties.
These questions are useful for identifying Actors:
● Who will supply, use, or remove information from the system?
● Who will use the system?
● Who is interested in a certain feature or service provided by the system?
● Who will support and maintain the system?
● What are the system's external resources?
● What other systems will need to interact with the system under development?
Review the list of stakeholders that you captured in the Vision Statement. Not all
stakeholders will be Actors (meaning, they will not all interact directly with the system under
development), but this list of stakeholders is useful for identifying candidates for Actors.

Finding likely use cases

The best way to find use cases is to consider what each Actor requires of the system. For
each Actor, human or not, ask:
● What are the goals that the Actor will attempt to achieve with the system?
● What are the primary tasks that the Actor wants the system to perform?
● Will the Actor create, store, change, remove, or read data in the system?
● Will the Actor need to inform the system about sudden external changes?
● Does the Actor need to be informed about certain occurrences in the system, such as
unavailability of a network?
● Will the Actor perform a system startup or shutdown?
Understanding how the target organization works and how this information system might be
incorporated into existing operations gives an idea of system's surroundings. That
information may reveal other use case candidates.
Give a unique name and brief description that clearly describes the goals for each use case.
If the candidate use case does not have goals, ask yourself why it exists, and then either
identify a purpose for it or eliminate the use case.

USE CASE SCENARIO(...FLOW)

A use case describes the interactions between one of more Actors and the system in order
to provide an observable result of value for the initiating actor.
The functionality of a system is defined by different use cases, each of which represents a
specific goal (to obtain the observable result of value) for a particular actor.
In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash
from an account, transfer funds between accounts, or deposit funds to an account. These
correspond to specific goals that the actor has in using the system.

Figure 1: ATM use case example.

19
Each use case is associated with a goal of one of the actors. The collection of use cases
constitutes all the possible ways of using the system. You should be able to determine the
goal of a use case simply by observing its name.
A use case describes the interactions between the actor(s) and the system in the form of a
dialog between the actor(s) and the system, structured as follows:
1. The actor <<does something>>
2. The system <<does something in response>>
3. The actor <<does something else>>
4. The system…
Each dialog of this form is called a “Flow of Events”.
Because there are many flows of events possible for achieving the goal (for example, the
flow may differ depending upon specific input from the actor), and there are situations in
which the goal cannot be achieved (for example, a required network connection is currently
unavailable), each use case will contain several flows, including one “Basic Flow of Events”
and several “Alternative Flows”.
The Basic Flow of Events specifies the interactions between the actor(s) and the system for
the ideal case, where everything goes as planned, and the actor’s goal (the observable
result of value) is met. The basic flow represents the main capability provided by the system
for this use case.
As the name implies, Alternative Flows specify alternative interactions associated with the
same goal.
Closely related to use cases is the concept of a scenario. A scenario is a specific flow of
events, for a specific set of inputs to the system, states of the system, and states of the
system’s environment. Scenarios are closely related to test cases.

Properties of Use Cases

Name

20
Each use case should have a name that clearly describes the main goal of the use case.
The name may have to be several words long to be understood. Typically the name is a verb
phrase, for example: Withdraw Cash.
Note: No two use cases can have the same name.

Brief Description
The brief description of the use case should reflect its purpose.

Flow of Events -- Contents

The flow of events should describe the interactions between the actor(s) and the system
clearly enough for an outsider to easily understand. The flow of events should represent
what the system does, not how the system is design to perform the required behavior.
Follow these guidelines for the contents of the flow of events:
● Describe how the use case starts and ends.
● Describe what data is exchanged between the actor and the use case.
● Do not describe the details of the user interface, unless it is necessary to understand
the behavior of the system. Specifying user interface details too early will limit design
options.
● Describe the flow of events, not only the functionality. To enforce this, start every
action with "When the actor ... ".
● Avoid vague terminology.
● Detail the flow of events. Specify what happens when, for each action. Remember
this text will be used to identify test cases.
If you have used certain terms in other use cases, be sure to use the exact same terms in
this use case, and that the meaning of the terms is consistent. To manage common terms,
put them in a Glossary.

Flow of Events -- Structure

The two main parts of the flow of events are basic flow of events and alternative flows of
events. The basic flow of events should cover what "normally" happens when the use case is
performed. The alternative flows of events cover behavior of optional or exceptional
character in relation to the normal behavior, and also variations of the normal behavior. You
can think of the alternative flows of events as detours from the basic flow of events, some of
which will return to the basic flow of events and some of which will end the execution of the
use case.
The straight arrow in Figure 2 represents the basic flow of events, and the curves represent
alternative paths in relation to the normal. Some alternative paths return to the basic flow of
events, whereas others end the use case.

Figure 2: Typical structure of a use case flow of events

21
To clarify where an alternative flow of events fits in the structure, you need to describe the
following for each detour to the basic flow of events:
● Where the alternative flow can be inserted in the basic flow of events
● The condition that needs to be fulfilled for the alternative behavior to start
● How and where the basic flow of events is resumed, or how the use case ends
It might be tempting, if the alternative flow of events is very simple, to just describe it in the
basic flow of events section (using some informal "if-then-else" construct). This should be
avoided. Too many alternatives will make the normal behavior difficult to see. Also, including
alternative paths in the basic flow of events section will make the text more pseudo-code like
and harder to read.
Both the basic and alternative flows may be further structured into subflows. In doing this,
your main goal should be readability of the text. A guideline is that a subflow should be a
segment of behavior within the use case that has a clear purpose, and is "atomic" in the
sense that you do either all or none of the actions described.

Preconditions and Post-conditions

A precondition is the state of the system and its surroundings that is required before the use
case can be started. Post-Conditions are the states the system can be in after the use case
has ended. It can be helpful to use the concepts of precondition and post-condition to clarify
how the flow of events starts and ends. However, only use them if the audience for the
description of the use case agrees that it is helpful. Figure 3 shows an example.

Figure 3: Illustration of preconditions and resulting post-conditions

22
 Examples

A precondition for the use case Cash Withdrawal in the ATM machine: The customer
has a personally issued card that fits in the card reader, has been issued a PIN number, and
is registered with the banking system.
A post-condition for the use case Cash Withdrawal in the ATM machine: At the end of
the use case, all account and transaction logs are balanced, communication with the
banking system is reinitialized, and the card is returned to the customer.

OR
Description:-
A precondition of a use case explains the state that the system must be in for the use case
to be able to start. Be careful in describing the system state. Avoid describing the detail of
other, incidental activities that may already have taken place.
A post-condition of a use case lists possible states that the system can be in after the use
case runs. The system must be in one of those states. A post-condition also states actions
that the system performs at the end of the use case, regardless of what occurred in the use
case. Post-conditions may be categorized as Minimal Guarantees or Success Guarantees:
● Minimal Guarantees represent conditions that will be true when the use cases end,
regardless of how they terminate.
● Success Guarantees represent condition that will be true when the use cases end
successfully, regardless of which paths they took.
Consider the following when specifying preconditions and post-condition:
● The states described by pre- or post-conditions should be states that the user can
observe. "The user has logged on to the system" or "The user has opened the
document" are examples of observable states.
● A precondition is a constraint on when a use case can start. It is not the event that
starts the use case.

23
 ● A precondition for a use case is not a precondition for only one subflow, although you
can define preconditions and post-conditions at the subflow level.
● A post-condition for a use case should be true regardless of which alternative flows
were executed; it should not be true only for the main flow. If something could fail,
you would cover that in the post-condition by saying "The action has completed," or if
something failed, "The action was not performed," rather than just "The action is
completed.

Level of detail necessary in use cases

There will often be use cases in your model that are so simple that they do not need a
detailed structured description of the use case (that is, a step-by-step outline is quite
enough). The criteria for making this decision is that you don't see disagreement among
different readers on what the use case means, and that designers and testers are
comfortable with the level of detail provided by the step-by-step format. Examples are use
cases that describe simple data entry or retrieval in your system

Relationship Between Use Cases and Actors

Running each use case includes communication with one or more actors. A use-case
instance is always started by an actor asking the system to do something. This implies that
every use case should have communicates-associations with actors. The reason for this rule
is to enforce that the system provides only the functionality that users need and nothing else.
Having use cases that no one requests is an indication that something is wrong in the
use-case model or in the requirements.
However, there are some exceptions to this rule:
● An "included" use case might not interact with an actor if the base use case does.
● A use case may be initiated according to a schedule (for example, once a week or
once a day), which means that the system clock is the initiator. The system clock is
internal to the system; therefore, the use case is not initiated by an actor but by an
internal system event. If no other actor interaction occurs in the use case, it will not
have any associations to actors. However, for clarity, you can use "time" as an actor
to show how the use case is initiated in your use-case diagrams. CAUTION: if you
have a lot of "time" actors in your model, challenge them. Perhaps you missed a real
actor, such as an administrator responsible for scheduling reports, etc.

USE CASE DIAGRAMS

To model a system, the most important aspect is to capture the dynamic behavior. Dynamic
behavior means the behavior of the system when it is running/operating.
Only static behavior is not sufficient to model a system rather dynamic behavior is more
important than static behavior. In UML, there are five diagrams available to model the
dynamic nature and use case diagram is one of them. Now as we have to discuss that the

24
use case diagram is dynamic in nature, there should be some internal or external factors for
making the interaction.
These internal and external agents are known as actors. Use case diagrams consists of
actors, use cases and their relationships. The diagram is used to model the
system/subsystem of an application. A single use case diagram captures a particular
functionality of a system.
Hence to model the entire system, a number of use case diagrams are used.

Purpose of Use Case Diagrams

The purpose of use case diagram is to capture the dynamic aspect of a system. However,
this definition is too generic to describe the purpose, as other four diagrams (activity,
sequence, collaboration, and Statechart) also have the same purpose. We will look into
some specific purpose, which will distinguish it from other four diagrams.
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. Hence, when a
system is analyzed to gather its functionalities, use cases are prepared and actors are
identified.
When the initial task is complete, use case diagrams are modelled to present the outside
view.
In brief, the purposes of use case diagrams can be said to be as follows −
● Used to gather the requirements of a system.
● Used to get an outside view of a system.
● Identify the external and internal factors influencing the system.
● Show the interaction among the requirements are actors.

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 case diagrams are drawn to capture the functional requirements of a system. After
identifying the above items, we have to 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.

25
 ● 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.
Following is a sample use case diagram representing the order management system.
Hence, if we look into the diagram then we will find three use cases (Order, SpecialOrder,
and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence,
they have extended relationship. Another important point is to identify the system boundary,
which is shown in the picture. The actor Customer lies outside the system as it is an external
user of the system.

Where to Use a Use Case Diagram?

As we have already discussed there are five diagrams in UML to model the dynamic view of
a system. Now each and every model has some specific purpose to use. Actually these
specific purposes are different angles of a running system.
To understand the dynamics of a system, we need to use different types of diagrams. Use
case diagram is one of them and its specific purpose is to gather system requirements and
actors.
Use case diagrams specify the events of a system and their flows. But use case diagram
never describes how they are implemented. Use case diagram can be imagined as a black
box where only the input, output, and the function of the black box is known.
These diagrams are used at a very high level of design. This high level design is refined
again and again to get a complete and practical picture of the system. A well-structured use
case also describes the pre-condition, post condition, and exceptions. These extra elements
are used to make test cases when performing the testing.
Although use case is not a good candidate for forward and reverse engineering, still they are
used in a slightly different way to make forward and reverse engineering. The same is true
for reverse engineering. Use case diagram is used differently to make it suitable for reverse
engineering.

26
In forward engineering, use case diagrams are used to make test cases and in reverse
engineering use cases are used to prepare the requirement details from the existing
application.
Use case diagrams can be used for −
● Requirement analysis and high level design.
● Model the context of a system.
● Reverse engineering.
● Forward engineering.

27
ANALYSIS

Finding Analysis Classes:-

28
29
NOUN/VERB ANALYSIS

30
31
32
33
CRC ANALYSIS
A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that
have been divided into three sections, as depicted in Figure 1. A class represents a
collection of similar objects, a responsibility is something that a class knows or does, and a
collaborator is another class that a class interacts with to fulfill its responsibilities. Figure 2
presents an example of two hand-drawn CRC cards.

Figure 1. CRC Card Layout.

Figure 2. Hand-drawn CRC Cards.

34
A class represents a collection of similar objects. An object is a person, place, thing, event,
or concept that is relevant to the system at hand. For example, in a university system,
classes would represent students, tenured professors, and seminars. The name of the class
appears across the top of a CRC card and is typically a singular noun or singular noun
phrase, such as Student, Professor, and Seminar. You use singular names because each
class represents a generalized version of a singular object. Although there may be the
student John O'Brien, you would model the class Student. The information about a student
describes a single person, not a group of people. Therefore, it makes sense to use the name
Student and not Students. Class names should also be simple. For example, which name is
better: Student or Person who takes seminars?

35
A responsibility is anything that a class knows or does. For example, students have names,
addresses, and phone numbers. These are the things a student knows. Students also enroll
in seminars, drop seminars, and request transcripts. These are the things a student does.
The things a class knows and does constitute its responsibilities. Important: A class is able
to change the values of the things it knows, but it is unable to change the values of what
other classes know.
Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For
example, as you see in Figure 3 students enroll in seminars. To do this, a student needs to
know if a spot is available in the seminar and, if so, he then needs to be added to the
seminar. However, students only have information about themselves (their names and so
forth), and not about seminars. What the student needs to do is collaborate/interact with the
card labeled Seminar to sign up for a seminar. Therefore, Seminar is included in the list of
collaborators of Student.

Figure 3. Student CRC card.

Collaboration takes one of two forms: A request for information or a request to do something.
For example, the card Student requests an indication from the card Seminar whether a
space is available, a request for information. Student then requests to be added to the
Seminar, a request to do something. Another way to perform this logic, however, would have
been to have Student simply request Seminar to enroll himself into itself. Then have Seminar
do the work of determining if a seat is available and, if so, then enrolling the student and, if
not, then informing the student that he was not enrolled.
So how do you create CRC models? Iteratively perform the following steps:
● Find classes. Finding classes is fundamentally an analysis task because it deals
with identifying the building blocks for your application. A good rule of thumb is that
you should look for the three-to-five main classes right away, such as Student,
Seminar, and Professor in Figure 4. I will sometimes include UI classes such as
Transcript and Student Schedule, both are reports, although others will stick to just
entity classes. Also, I'll sometimes include cards representing actors when my
stakeholders are struggling with the concept of a student in the real world (the actor)
versus the student in the system (the entity).
● Find responsibilities. You should ask yourself what a class does as well as what
information you wish to maintain about it. You will often identify a responsibility for a
class to fulfill a collaboration with another class.

36
 ● Define collaborators. A class often does not have sufficient information to fulfill its
responsibilities. Therefore, it must collaborate (work) with other classes to get the job
done. Collaboration will be in one of two forms: a request for information or a request
to perform a task. To identify the collaborators of a class for each responsibility ask
yourself "does the class have the ability to fulfill this responsibility?". If not then look
for a class that either has the ability to fulfill the missing functionality or the class
which should fulfill it. In doing so you'll often discover the need for new
responsibilities in other classes and maybe even the need for a new class or two.
● Move the cards around. To improve everyone's understanding of the system, the
cards should be placed on the table in an intelligent manner. Two cards that
collaborate with one another should be placed close together on the table, whereas
two cards that don't collaborate should be placed far apart. Furthermore, the more
two cards collaborate, the closer they should be on the desk. By having cards that
collaborate with one another close together, it's easier to understand the
relationships between classes.

Figure 4. CRC Model.

● Advantages of CRC Index Cards:

- simple
- Portable
- Readily available
- Easy to apply technique

37
USING RUP STEREOTYPEPES
Analysis classes may be stereotyped as one of the following:
● Boundary classes
● Control classes
● Entity classes

This stereotyping results in a robust object model because changes to the model tend to
affect only a specific area. Changes in the user interface, for example, will affect only
boundary classes. Changes in the control flow will affect only control classes. Changes in
long-term information will affect only entity classes.

Boundary Class

A boundary class is a class used to model interaction between the system's surroundings
and its inner workings. Such interaction involves transforming and translating events and
noting changes in the system presentation (such as the interface).

Boundary classes model the parts of the system that depend on its surroundings. Entity
classes and control classes model the parts that are independent of the system's
surroundings. Thus, changing the GUI or communication protocol should mean changing
only the boundary classes, not the entity and control classes.

Boundary classes also make it easier to understand the system because they clarify the
system's boundaries. They aid design by providing a good point of departure for identifying
related services. For example, if you identify a printer interface early in the design, you will
soon see that you must also model the formatting of printouts.

You should model boundary classes according to what kind of boundary they represent.
Communication with another system and communication with a human actor (through a user
interface) have very different objectives. During user-interface modeling, the most important
concern is how the interface will be presented to the user. During system-communication
modeling, the most important concern is the communication protocol.

Finding Boundary Classes

A boundary class intermediates the interface to something outside the system. Boundary
objects insulate the system from changes in the surroundings (changes in interfaces to other
systems, changes in user requirements, etc.), keeping these changes from affecting the rest
of the system.

A system may have several types of boundary classes:

● User interface classes - classes which intermediate communication with human

users of the system

38
 ● System interface classes - classes which intermediate communication with other
system
● Device interface classes - classes which provide the interface to devices (such
as sensors), which detect external events

Control Class
A control class is a class used to model control behavior specific to one or a few use cases.
Control objects (instances of control classes) often control other objects, so their behavior is
of the coordinating type. Control classes encapsulate use-case specific behavior.

The behavior of a control object is closely related to the realization of a specific use case. In
many scenarios, you might even say that the control objects "run" the use-case realizations.
However, some control objects can participate in more than one use-case realization if the
use-case tasks are strongly related. Furthermore, several control objects of different control
classes can participate in one use case. Not all use cases require a control object. For
example, if the flow of events in a use case is related to one entity object, a boundary object
may realize the use case in cooperation with the entity object. You can start by identifying
one control class per use-case realization, and then refine this as more use-case realizations
are identified and commonality is discovered.

Control classes can contribute to understanding the system because they represent the
dynamics of the system, handling the main tasks and control flows.

When the system performs the use case, a control object is created. Control objects usually
die when their corresponding use case has been performed.

Note that a control class does not handle everything required in a use case. Instead, it
coordinates the activities of other objects that implement the functionality. The control class
delegates work to the objects that have been assigned the responsibility for the functionality.

Finding Control Classes

Control classes provide coordinating behavior in the system. The system can perform some
use cases without control objects (just using entity and boundary objects)—particularly use
cases that involve only the simple manipulation of stored information.

More complex use cases generally require one or more control classes to coordinate the
behavior of other objects in the system. Examples of control objects include programs such
as transaction managers, resource coordinators, and error handlers.

Control classes effectively de-couple boundary and entity objects from one another, making
the system more tolerant of changes in the system boundary. They also de-couple the
use-case specific behavior from the entity objects, making them more reusable across use
cases and systems.

Control classes provide behavior that:

39
 ● Is surroundings-independent (does not change when the surroundings change),
● Defines control logic (order between events) and transactions within a use case.
● Changes little if the internal structure or behavior of the entity classes changes,
● Uses or sets the contents of several entity classes, and therefore needs to
coordinate the behavior of these entity classes.
● Is not performed in the same way every time it is activated (flow of events features
several states).

Determine whether a Control Class is Needed

The flow of events of a use case defines the order in which different tasks are performed.
Start by investigating if the flow can be handled by the already identified boundary and entity
classes. For simple flows of events which primarily enter, retrieve and display, or modify
information, a separate control class is not usually justified; the boundary classes will be
responsible for coordinating the use case.

The flows of events should be encapsulated in a separate control class when it is complex
and consists of dynamic behavior that may change independently from the interfaces
(boundary classes) or information stores (entity classes) of the system. By encapsulating the
flows of events, the same control class can potentially be re-used for a variety of systems
which may have different interfaces and different information stores (or at least the
underlying data structures).

Example: Managing a Queue of Tasks

You can identify a control class from the use case Perform Task in the
Depot-Handling System. This control class handles a queue of Tasks, ensuring
that Tasks are performed in the right order. It performs the next Task in the queue
as soon as suitable transportation equipment is allocated. The system can
therefore perform several Tasks at the same time.

The behavior defined by the corresponding control object is easier to describe if

you split it into two control classes, Task Performer and Queue Handler. A Queue
Handler object will handle only the queue order and the allocation of
transportation equipment. One Queue Handler object is needed for the whole
queue. As soon as the system performs a Task, it will create a new Task
Performer object, which will perform the Task. We thus need one Task Performer
object for each Task the system performs.

Complex classes should be divided along lines of similar responsibilities

The principal benefit of this split is that we have separated queue handling
responsibilities (something generic to many use cases) from the specific activities
of task management, which are specific to this use case. This makes the classes
easier to understand and easier to adapt as the design matures. It also has
benefits in balancing the load of the system, as many Task Performers can be
created as necessary to handle the workload.

40
Encapsulating the Main Flow of Events and Alternate/Exceptional Flows of Events in separate
Control Classes

To simplify changes, encapsulate the main flow of events and alternate flows of events in
different control classes. If alternate and exception flows are completely independent,
separate them as well. This will make the system easier to extend and maintain over time.

Divide Control Classes where two Actors share the same Control Class

Control classes may also need to be divided when several actors use the same control
class. By doing this, we isolate changes in the requirements of one actor from the rest of the
system. In cases where the cost of change is high or the consequences dire, you should
identify all control classes which are related to more than one actor and divide them. In the
ideal case, each control class should interact (via some boundary object) with one actor or
none at all.

Example: Call Management

Consider the use case Local Call. Initially, we can identify a control class to
manage the call itself.

The control class handling local phone calls in a telephone system can quickly be
divided into two control classes, A-behavior and B-behavior, one for each actor
involved.

In a local phone call, there are two actors: A-subscriber who initiates the call,
and B-subscriber who receives the call. The A-subscriber lifts the receiver,
hears the dial tone, and then dials a number of digits, which the system stores
and analyzes. When the system has received all the digits, it sends a ringing tone
to A-subscriber, and a ringing signal to B-subscriber. When B-subscriber
answers, the tone and the signal stop, and the conversation between the
subscribers can begin. The call is finished when both subscribers hang up.

Two behaviors must be controlled: What happens at A-subscriber’s place and

what happens at B-subscriber’s place. For this reason, the original control object
was split into two control objects, A-behavior and B-behavior.

You do not have to divide a control class if:

● You can be reasonably sure that the behavior of the actors related to the objects
of the control class will never change, or change very little.
● The behavior of an object of the control class toward one actor is very insignificant
compared with its behavior toward another actor, a single object can hold all the
behavior. Combining behavior in this way will have a negligible effect on
changeability.

41
Entity Class
An entity class is a class used to model information and associated behavior that must be
stored. Entity objects (instances of entity classes) are used to hold and update information
about some phenomenon, such as an event, a person, or some real-life object. They are
usually persistent, having attributes and relationships needed for a long period, sometimes
for the life of the system.

An entity object is usually not specific to one use-case realization; sometimes, an entity
object is not even specific to the system itself. The values of its attributes and relationships
are often given by an actor. An entity object may also be needed to help perform internal
system tasks. Entity objects can have behavior as complicated as that of other object
stereotypes. However, unlike other objects, this behavior is strongly related to the
phenomenon the entity object represents. Entity objects are independent of the environment
(the actors).

Entity objects represent the key concepts of the system being developed. Typical examples
of entity classes in a banking system are Account and Customer. In a network-handling
system, examples are Node and Link.

If the phenomenon you wish to model is not used by any other class, you can model it as an
attribute of an entity class, or even as a relationship between entity classes. On the other
hand, if the phenomenon is used by any other class in the design model, you must model it
as a class.

Entity classes provide another point of view from which to understand the system because
they show the logical data structure, which can help you understand what the system is
supposed to offer its users.

Finding Entity Classes

Entity classes represent stores of information in the system; they are typically used to
represent the key concepts the system manages. Entity objects are frequently passive and
persistent. Their main responsibilities are to store and manage information in the system.

A frequent source of inspiration for entity classes are the Glossary (developed during
requirements) and a business-domain model (developed during business modeling, if
business modeling has been performed).

MODELING CLASSES

ASSOCIATION
Association is a relationship between classifiers which is used to show that instances of
classifiers could be either linked to each other or combined logically or physically into some
aggregation.\ OR

42
ROLE NAME

43
MULTIPLICITY

NAVIGABILITY
This means that if an association exists between two classes, then both objects know about
each other. However, when creating a class diagram it is possible to use a navigable
association between two classes. This is shown by adding an arrowhead at one end of the
association. If “A” is the source class and “B” is the target class, the arrowhead would be
placed on the “B” side of the association. A navigable association of this type means that at
runtime object “A” knows about object “B”, but object “B” has no knowledge of or visibility
into object “A”.

Deprecated navigability convention:

● non-navigable ends were assumed to be owned by the association

● navigable ends were assumed to be owned by the classifier at the opposite end.

44
Notation:
● navigable end is indicated by an open arrowhead on the end of an association
● not navigable end is indicated with a small x on the end of an association
● no adornment on the end of an association means unspecified navigability

Both ends of association have unspecified navigability.

A2 has unspecified navigability while B2 is navigable from A2.

A3 is not navigable from B3 while B3 has unspecified navigability.

A4 is not navigable from B4 while B4 is navigable from A4.

A5 is navigable from B5 and B5 is navigable from A5.

A6 is not navigable from B6 and B6 is not navigable from A6.

A visibility symbol can be added as an adornment on a navigable end to show the end’s
visibility as an attribute of the featuring classifier.

ASSOCIATION CLASS
In UML diagrams, an association class is a class that is part of an association relationship
between two other classes.

45
You can attach an association class to an association relationship to provide additional
information about the relationship. An association class is identical to other classes and can
contain operations, attributes, as well as other associations.
For example, a class called Student represents a student and has an association with a
class called Course, which represents an educational course. The Student class can enroll
in a course. An association class called Enrollment further defines the relationship between
the Student and Course classes by providing section, grade, and semester information
related to the association relationship.
As the following figure illustrates, an association class is connected to an association
by a dotted line.

QUALIFIER ASSOCIATION
● A qualier is a value that selects a unique object from the set of related objects
across an association.
● A association with a qualifier is called qualified association.
A qualified association has a qualifier that is used to select an object (or objects) from a
larger set of related objects, based upon the qualifier key. Informally, in a software
perspective, it suggests looking things up by a key, such as objects in a HashMap. For
example, if a ProductCatalog contains many ProductDescriptions, and each one can be
selected by an itemID, then the UML notation in Figure 16.15 can be used to depict this.

There’s one subtle point about qualified associations: the change in multiplicity. For
example, as contrasted in Figure 16.15 (a) vs. (b), qualification reduces the multiplicity at the
target end of the association, usually down from many to one, because it implies the
selection of usually one instance from a larger set.

Figure 16.15 Qualified associations in the UML.

46
DEPENDENCIES
Dependency is a directed relationship which is used to show that some UML element or
a set of elements requires, needs or depends on other model elements for specification or
implementation. Because of this, dependency is called a supplier - client relationship,
where supplier provides something to the client, and thus the client is in some sense
incomplete while semantically or structurally dependent on the supplier element(s).
Modification of the supplier may impact the client elements.
Dependency is a relationship between named elements, which in UML includes a lot of
different elements, e.g. classes, interfaces, components, artifacts, packages, etc.
There are several kinds of dependencies shown on the diagram below.

Dependency relationship overview diagram - usage, abstraction, deployment.

Usage is a dependency in which one named element (client) requires another named
element (supplier) for its full definition or implementation.
The abstraction relates two elements representing the same concept but at different levels
of abstraction.

47
The deployment is a dependency which shows allocation (deployment) of an artifact to a
deployment target.
A dependency is generally shown as a dashed arrow pointing from the client (dependent) at
the tail to the supplier (provider) at the arrowhead. The arrow may be labeled with an
optional stereotype and an optional name. Because the direction of the arrow goes opposite
to what we would normally expect, I usually stereotype it as client «depends on» supplier.

Class SearchController depends on (requires) SiteSearch interface.

Usage

A usage is a dependency relationship in which one element (client) requires another

element (or set of elements) (supplier) for its full implementation or operation.
The usage dependency does not specify how the client uses the supplier other than the fact
that the supplier is used by the definition or implementation of the client. For example, it
could mean that some method(s) within a (client) class uses objects (e.g. parameters) of the
another (supplier) class.
A usage dependency is shown as a dependency with a «use» keyword attached to it.

Class SearchController uses SearchEngine class.

Create

Create is a usage dependency denoting that the client classifier creates instances of the
supplier classifier. It is denoted with the standard stereotype «create».

Class DataSource creates Connection.

48
Create could also specify that the designated feature creates an instance of the classifier to
which the feature is attached. This dependency may be promoted to the classifier containing
the feature.
Create may relate an instance value to a constructor for a class, describing the single value
returned by the constructor operation. The operation is the client, the created instance the
supplier. The instance value may reference parameters declared by the operation.

Account constructor creates new instances of Account

Instantiate is another usage dependency among classifiers indicating that operations on

the client create instances of the supplier. It is denoted with the standard stereotype
«instantiate».
It is not very clear why UML 2.4 standard has both «create» and «instantiate».

Call

Call is a usage dependency that specifies that the source operation invokes the target
operation. This dependency may connect a source operation to any target operation that is
within the scope including, but not limited to, operations of the enclosing classifier and
operations of other visible classifiers.
Call is denoted with the standard stereotype «call» whose source is an operation and
whose target is also an operation.
This relationship may also be applied to the class containing an operation, with the meaning
that there exists an operation in the class to which the dependency applies.

Send

Send is a usage dependency whose source is an operation and whose target is a signal,
specifying that the source sends the target signal.
Send is denoted with the standard stereotype «send».

Required Interface

49
Required interface specifies services that a classifier needs in order to perform its
function and fulfill its own obligations to its clients. It is specified by a usage dependency
between the classifier and the corresponding interface.
The usage dependency from a classifier to an interface is shown by representing the
interface by a half-circle or socket, labeled with the name of the interface, attached by a solid
line to the classifier that requires this interface.

Interface SiteSearch is used (required) by SearchController.

If interface is represented using the rectangle notation, interface usage dependency is

denoted with dependency arrow. The classifier at the tail of the arrow uses (requires) the
interface at the head of the arrow.

Interface SiteSearch is used (required) by SearchController.

ABSTRACTION

Abstraction is a dependency relationship that relates two named elements or sets of

named elements representing the same concept but at different levels of abstraction or
from different viewpoints.
Because abstraction is dependency, it is usually defined as a relationship between client(s)
and supplier(s) where client (subset of source) depends on supplier (subset of target)
Abstraction allows mapping between the supplier and the client to be formal or informal,
and unidirectional or bidirectional, depending on the specific subclass or stereotype of
abstraction. For example, Derivation could be formal and unidirectional, while Trace
could be informal and bidirectional.
If an abstraction has more than one client, the supplier maps into the set of clients as a
group. For example, an analysis level class could serve as an abstraction for one or several
design level classes. Use case could be abstraction for several collaborations.

50
 ● Abstraction has two subclasses - Realization and Manifestation. A manifestation
is labeled with the keyword «manifest», and is used in deployment diagrams.
● Abstraction also has few standard stereotypes - «Derive», «Refine», and
«Trace», defined in the Standard Profile.

Notation

An abstraction relationship is shown as a dependency relationship arrow from the client

at the tail to the supplier at the arrowhead, with the «abstraction» keyword or some other
predefined stereotype name attached to.
For example, an analysis level class Customer (supplier, subset of target) might be
implemented as design level class CustomerInfo (client, subset of source).

Customer from Domain is abstraction for CustomerInfo from DataTransfer.

(Common convention example - the more abstract element as supplier.)

If some UML modeler decides that it is better to show a more abstract element dependent on
the more specific element, the relationship will be reversed.

Customer from Domain is abstraction for CustomerInfo from DataTransfer.

(Reverse notation example - the less abstract element as supplier.)

51
Derive

«Derive» is a standard abstraction stereotype which is used to specify a derivation

relationship among model elements that are usually, but not necessarily, of the same type.
This derivation is defined in UML as "the client may be computed from the supplier". The
reason to have such "computed client" could be implementation efficiency. The mapping
from the abstraction relationship specifies the computation.
The derivation relationship is related to derived properties, properties which values are
produced or computed from other information, for example, by using values of other
properties.

Age class is derived from BirthDate class

«Refine»

«Refine» is a standard abstraction stereotype which is used to specify a refinement

relationship between model elements at different semantic levels, such as analysis, design,
and implementation. It can be used to model transformations from analysis to design, design
to implementation, etc. The abstraction mapping may or may not be computable, and it may
be unidirectional or bidirectional.
Models can have refinement dependencies between them, typically represented by
dependencies between the elements contained in the models.

Customer class from Design model refines Customer class from Analysis model.

52
TRACE

Trace is a standard abstraction stereotype which is mainly used for tracking requirements
and changes across Models for the elements or sets of elements that represent the same
concept in different models. Thus trace is "inter-model" relationship.
These tracing/mapping dependencies between Models are typically represented by
dependencies between the elements contained in the models.
Some examples of using Trace are:

● Use case in Use Case Model might trace to collaborations or a package in

corresponding Design Model.
● Interfaces and classes from Design Model could trace to components in
Implementation Model.
● Components in Implementation Model might trace to artifacts in Deployment
Model. In this case though, an alternative is to use specialized manifestation
relationship.

Withdraw Cash use case in Use Case Model trace to Withdraw Cash collaboration in Design Model.

The direction of trace (i.e., the designation of the client and supplier) is at the discretion of
the modeler, and since model changes can occur in both directions, the direction of the
dependency can often be ignored. The mapping specifies the relationship between the two,
but it is rarely computable and is usually informal.

CLASS GENERALIZATION
● In UML modeling, a generalization relationship is a relationship in which one
model element (the child) is based on another model element (the parent).
● OR A generalization is a binary taxonomic (i.e. related to classification) directed
relationship between a more general classifier (superclass) and a more specific
classifier (subclass)

53
 ● Generalization relationships are used in class, component, deployment, and
use-case diagrams to indicate that the child receives all of the attributes,
operations, and relationships that are defined in the parent.
● The parent model element can have one or more children, and any child
model element can have one or more parents. It is more common to have a
single parent model element and multiple child model elements.
● Generalization relationships do not have names.
A generalization is shown as a line with a hollow triangle as an arrowhead between the
symbols representing the involved classifiers. The arrowhead points to the symbol
representing the general classifier. This notation is referred to as the "separate target
style."

Checking, Savings, and Credit Accounts are generalized by Account

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

Checking, Savings, and Credit Accounts are generalized by Account

INHERITENCE
the ability of a class to inherit behaviors and features from superclass.

MULTIPLE INHERITENCE
the ability of a class to inherit behaviors and features from more than one superclass.

54
GENERALIZATION SETS
● Generalization set is a packageable element that allows us to define
classification hierarchies by combining some generalizations of a particular general
classifier into (sub)sets.
● Each Generalization is a binary relationship that relates a specific Classifier to a more
general Classifier (i.e., from a class to its superclasses).
● Each GeneralizationSet defines a particular set of Generalization relationships that
describe the way in which a general Classifier (or superclass) may be divided using
specific subtypes.
For example, a Generalization set could define a partitioning of the class Person into two
subclasses: Male Person and Female Person. Here, the Generalization set would associate
two instances of Generalization. Both instances would have Person as the general classifier;
however, one Generalization would involve Male Person as the specific Classifier and the
other would involve Female Person as the specific classifier. In other words, the class Person
can here be said to be partitioned into two subclasses: Male Person and Female Person.
Person could also be divided into North American Person, Asian Person, European Person,
or something else. This collection of subsets would define a differentGeneralization set
that would associate with three other Generalization relationships. All three would have
Person as the general Classifier; only the specific classifiers would differ (i.e., North
American Person, Asian Person, and European Person).
Each generalization set has two properties - isCovering (complete or incomplete
constraint) and isDisjoint (disjoint or overlapping constraint), to clarify what kind of set
it is.
The isCovering property of generalization set specifies whether the set of specific classifiers
in that generalization set is complete. For the covering ({complete}) generalization set,
every instance of the general classifier is also an instance of (at least) one of the specific
classifiers. If the set is not covering ({incomplete}), there could be some instances of the
general classifier that could not be classified as any of the specific classifiers from the
generalization set.
The isDisjoint property specifies whether the specific classifiers of the generalization set
may overlap. Generalization set constrained as {disjoint} has no instance of any specific
classifier may also be an instance of another specific classifier (i.e there is no overlapping of
classifiers). If generalization set is {overlapping}, some or all of its specific classifiers could
share common instances.

55
POWER TYPE
A generalization set may optionally be associated with a classifier called its power type. The
power type instances in this case may be treated as semantically equivalent to each of the
corresponding specializing classifiers in every generalization in the generalization set.
On the diagram, the generalization set constraints are placed next to the sets, close to the
common arrowhead of the generalization set or near the dashed line for the generalization
set.
Power type specification is shown as colon followed by the name of the power type
classifier near the corresponding generalization set.

Health insurance policy generalization sets and powertypes example -

Coverage type is complete and overlapping while insurance plan is incomplete and disjoint.

USE CASE REALIZATION

A use-case realization represents how a use case will be implemented in terms of
collaborating objects. This artifact can take various forms. It may include, for example, a
textual description (a document), class diagrams of participating classes and subsystems,

56
and interaction diagrams (communication and sequence diagrams) that illustrate the flow of
interactions between class and subsystem instances.
In a model, a use-case realization is represented as a UML collaboration that groups the
diagrams and other information (such as textual descriptions) that form part of the use-case
realization.
The reason for separating the use-case realization from its use case is that doing so allows
the use cases to be managed separately from their realizations. This is particularly important
for larger projects, or families of systems where the same use cases may be designed
differently in different products within the product family. Consider the case of a family of
telephone switches which have many use cases in common, but which design and
implement them differently according to product positioning, performance and price.
For larger projects, separating the use case and its realization allows changes to the design
of the use case without affecting the baselined use case itself.
For each use case in the use-case model, there is a use-case realization in the
analysis/design model with a realization relationship to the use case. In the UML this is
shown as a dashed arrow, with an arrowhead like a generalization relationship, indicating
that a realization is a kind of inheritance, as well as a dependency (i.e. it could have been
shown as a dependency stereotyped with <<realize>>).

A use-case realization in the analysis/design model can be traced to a use case in the
use-case model.

CLASS DIAGRAMS
For each use-case realization there may be one or more class diagrams depicting its
participating classes. The figure below shows a class diagram for the realization of the
Receive Deposit Item use case. A class and its objects often participate in several use-case
realizations. It is important during design to coordinate all the requirements on a class and its
objects that different use-case realizations may have.

57
The use case Receive Deposit Item and its class diagram.

SEQUENCE DIAGRAMS
In most cases, we use a sequence diagram to illustrate use-case realizations (see Work
Product: Use-Case Realizations), i.e. to show how objects interact to perform the behavior of
all or part of a use case. One or more sequence diagrams may illustrate the object
interactions which enact a use case. A typical organization is to have one sequence diagram
for the main flow of events and one sequence diagram for each independent sub-flow of the
use case.
Sequence diagrams are particularly important to designers because they clarify the roles of
objects in a flow and thus provide basic input for determining class responsibilities and
interfaces.

Sequence Diagrams –
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place. We can also use the terms event diagrams or
event scenarios to refer to a sequence diagram. Sequence diagrams describe how and in
what order the objects in a system function. These diagrams are widely used by
businessmen and software developers to document and understand requirements for new
and existing systems.

Sequence Diagram Notations –

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

Figure – notation symbol for actor

58
We use actors to depict various roles including human users and other external subjects. We
represent an actor in a UML diagram using a stick person notation. We can have multiple
actors in a sequence diagram.
For example – Here the user in seat reservation system is shown as an actor where it exists
outside the system and is not a part of the system.

2. 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. Lifeline elements are located at the top in a sequence diagram. The
standard in UML for naming a lifeline follows the following format – Instance Name :
Class Name

Figure – lifeline

We display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
model an unnamed instance, we follow the same pattern except now the portion of lifeline’s
name is left blank.
Difference between a lifeline and an actor – A lifeline always portrays an object internal to
the system whereas actors are used to depict objects external to the system.

3. 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 categories :

59
Figure – a sequence diagram with different types of messages
○ 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.

Figure – a sequence diagram using a synchronous message

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

○ Create message – We use a Create message to instantiate a new object in

the sequence diagram. There are situations when a particular message call
requires the creation of an object. It is represented with a dotted arrow and
create word labelled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would
require a new object of Order class to be created.

Figure – a situation where create message is used

○
○ Delete Message – We use a Delete Message to delete an object. When an
object is deallocated memory or is destroyed within the system we use the
Delete Message symbol. It destroys the occurrence of the object in the
system.It is represented by an arrow terminating with a x.
For example – In the scenario below when the order is received by the user,
the object of order class can be destroyed.

61
 Figure – a scenario where delete message is used
○ 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.

Figure – self message

For example – Consider a scenario where the device wants to access its
webcam. Such a scenario is represented using a self message.

62
 Figure – a scenario where a self message is used
○ Reply Message – Reply messages are used to show the message being sent
from the receiver to the sender. We represent a return/reply message using
an open arrowhead with a dotted line. The interaction moves forward only
when a reply message is sent by the receiver.

Figure – reply message

For example – Consider the scenario where the device requests a photo from
the user. Here the message which shows the photo being sent is a reply
message.

Figure – a scenario where a reply message is used

○ Found Message – A Found message is used to represent a scenario where
an unknown source sends the message. It is represented using an arrow
directed towards a lifeline from an end point. For example: Consider the
scenario of a hardware failure.

63
 Figure – found message
It can be due to multiple reasons and we are not certain as to what caused
the hardware failure.

Figure – a scenario where found message is used

○ Lost Message – A Lost message is used to represent a scenario where the
recipient is not known to the system. It is represented using an arrow directed
towards an end point from a lifeline. For example: Consider a scenario where
a warning is generated.

Figure – lost message

The warning might be generated for the user or other software/object that the
lifeline is interracting with. Since the destination is not known before hand, we
use the Lost Message symbol.
○

64
 Figure – a scenario where lost message is used
4. Guards – To model conditions we use guards in UML. They are used when we need
to restrict the flow of messages on the pretext of a condition being met. Guards play
an important role in letting software developers know the constraints attached to a
system or a particular process.
For example: In order to be able to withdraw cash, having a balance greater than
zero is a condition that must be met as shown below.

Figure – sequence diagram using a guard

65
A sequence diagram for an emotion based music player –

Figure – a sequence diagram for an emotion based music player

The above sequence diagram depicts the sequence diagram for an emotion based music
player:
1. Firstly the application is opened by the user.
2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Uses of sequence diagrams –

● Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
● They are also used to show details of UML use case diagrams.
● Used to understand the detailed functionality of current or future systems.

66
 ● Visualise how messages and tasks move between objects or components in a
system.

COLLABORATION/COMMUNICATION DIAGRAMS\
Collaboration Diagram has been renamed to Communication Diagram.
Communication diagrams are used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case. Along with sequence diagrams, communication
diagrams are used by designers to define and clarify the roles of the objects that perform a
particular flow of events of a use case. They are the primary source of information used to
determining class responsibilities and interfaces.
Unlike a sequence diagram, a communication diagram shows the relationships among the
objects. Sequence diagrams and communication diagrams express similar information, but
show it in different ways. Communication diagrams show the relationships among objects
and are better for understanding all the effects on a given object and for procedural design.
Because of the format of the communication diagram, they tend to better suited for analysis
tasks. . Specifically, they tend to be better suited to depicting simpler interactions of smaller
numbers of objects. As the number of objects and messages grows, the diagram becomes
increasingly hard to read. In addition, it is difficult to show additional descriptive information
such as timing, decision points, or other unstructured information that can be easily added to
the notes in a sequence diagram.

Contents of Communication Diagrams

You can have objects and actor instances in communication diagrams, together with links
and messages describing how they are related and how they interact. The diagram
describes what takes place in the participating objects, in terms of how the objects
communicate by sending messages to one another. You can make a communication
diagram for each variant of a use case's flow of events.

67
A communication diagram that describes part of the flow of events of the use case Receive
Deposit Item in the Recycling-Machine System.

Objects
An object is represented by an object symbol showing the name of the object and its class
underlined, separated by a colon:
objectname : classname
You can use objects in communication diagrams in the following ways:
● An object's class can be unspecified. Normally you create a communication diagram
with objects first and specify their classes later.
● The objects can be unnamed, but you should name them if you want to discriminate
different objects of the same class.
● An object's class can itself be represented in a communication diagram, if it actively
participates in the interaction.

Actors
Normally an actor instance occurs in the communication diagram, as the invoker of the
interaction. If you have several actor instances in the same diagram, try keeping them in the
periphery of the diagram.

Links
Links are defined as follows:
● A link is a relationship among objects across which messages can be sent. In
communication diagrams, a link is shown as a solid line between two objects.
● An object interacts with, or navigates to, other objects through its links to these
objects.
● A link can be an instance of an association, or it can be anonymous, meaning that its
association is unspecified.
● Message flows are attached to links, see Messages.

Messages
A message is a communication between objects that conveys information with the
expectation that activity will ensue. In communication diagrams, a message is shown as a
labeled arrow placed near a link. This means that the link is used to transport, or otherwise
implement the delivery of the message to the target object. The arrow points along the link in
the direction of the target object (the one that receives the message). The arrow is labeled
with the name of the message, and its parameters. The arrow may also be labeled with a
sequence number to show the sequence of the message in the overall interaction. Sequence
numbers are often used in communication diagrams, because they are the only way of
describing the relative sequencing of messages.
A message can be unassigned, meaning that its name is a temporary string that describes
the overall meaning of the message. You can later assign the message by specifying the
operation of the message's destination object. The specified operation will then replace the
name of the message.

68
 CLASS DIAGRAMS
Class Diagram gives the static view of an application. A class diagram describes the types of
objects in the system and the different types of relationships that exist among them. This modeling
method can run with almost all Object-Oriented Methods. A class can refer to another class. A
class can have its objects or may inherit from other classes.

UML Class Diagram gives an overview of a software system by displaying classes, attributes,
operations, and their relationships. This Diagram includes the class name, attributes, and
operation in separate designated compartments

Benefits of Class Diagram

 Class Diagram Illustrates data models for even very complex information systems
 It provides an overview of how the application is structured before studying the actual code.
This can easily reduce the maintenance time
 It helps for better understanding of general schematics of an application.
 Allows drawing detailed charts which highlights code required to be programmed
 Helpful for developers and other stakeholders.

Essential elements of A UML class diagram

Essential elements of UML class diagram are:

1. Class Name
2. Attributes
3. Operations

Class Name

The name of the class is only needed in the graphical representation of the class. It appears in the
topmost compartment. A class is the blueprint of an object which can share the same
relationships, attributes, operations, & semantics. The class is rendered as a rectangle, including
its name, attributes, and operations in sperate compartments.

Following rules must be taken care of while representing a class:

69
 1. A class name should always start with a capital letter.
2. A class name should always be in the center of the first compartment.
3. A class name should always be written in bold format.
4. An abstract class name should be written in italics format.

Attributes:
An attribute is named property of a class which describes the object being modeled. In the class
diagram, this component is placed just below the name-compartment.

A derived attribute is computed from other attributes. For example, an age of the student can be
easily computed from his/her birth date.

Attributes characteristics

 The attributes are generally written along with the visibility factor.
 Public, private, protected and package are the four visibilities which are denoted by +, -, #,
or ~ signs respectively.
 Visibility describes the accessibility of an attribute of a class.
 Attributes must have a meaningful name that describes the use of it in a class.

70
 Relationships
There are mainly three kinds of relationships in UML:

1. Dependencies
2. Generalizations
3. Associations

Dependency

A dependency means the relation between two or more classes in which a change in one may
force changes in the other. However, it will always create a weaker relationship. Dependency
indicates that one class depends on another.

In the following example, Student has a dependency on College

Generalization:

A generalization helps to connect a subclass to its superclass. A sub-class is inherited from its
superclass. Generalization relationship can't be used to model interface implementation. Class
diagram allows inheriting from multiple superclasses.

In this example, the class Student is generalized from Person Class.

Association:

This kind of relationship represents static relationships between classes A and B. For example; an
employee works for an organization.

Here are some rules for Association:

 Association is mostly verb or a verb phrase or noun or noun phrase.

71
  It should be named to indicate the role played by the class attached at the end of the
association path.
 Mandatory for reflexive associations

In this example, the relationship between student and college is shown which is studies.

Multiplicity

A multiplicity is a factor associated with an attribute. It specifies how many instances of attributes
are created when a class is initialized. If a multiplicity is not specified, by default one is considered
as a default multiplicity.

Let's say that that there are 100 students in one college. The college can have multiple students.

Aggregation

Aggregation is a special type of association that models a whole- part relationship between
aggregate and its parts.

72
For example, the class college is made up of one or more student. In aggregation, the contained
classes are never totally dependent on the lifecycle of the container. Here, the college class will
remain even if the student is not available.

Composition:

The composition is a special type of aggregation which denotes strong ownership between two
classes when one class is a part of another class.

For example, if college is composed of classes student. The college could contain many students,
while each student belongs to only one college. So, if college is not functioning all the students
also removed.

Aggregation vs. Composition

Aggregation Composition

Aggregation indicates a relationship where Composition display relationship where

the child can exist separately from their the child will never exist independent of
parent class. Example: Automobile (Parent) the parent. Example: House (parent) and
and Car (Child). So, If you delete the Room (child). Rooms will never separate
Automobile, the child Car still exist. into a House.
Abstract Classes
It is a class with an operation prototype, but not the implementation. It is also possible to have an
abstract class with no operations declared inside of it. An abstract is useful for identifying the
functionalities across the classes. Let us consider an example of an abstract class. Suppose we
have an abstract class called as a motion with a method or an operation declared inside of it. The
method declared inside the abstract class is called a move ().

This abstract class method can be used by any object such as a car, an animal, robot, etc. for
changing the current position. It is efficient to use this abstract class method with an object
because no implementation is provided for the given function. We can use it in any way for
multiple objects.

In UML, the abstract class has the same notation as that of the class. The only difference between
a class and an abstract class is that the class name is strictly written in an italic font.

An abstract class cannot be initialized or instantiated.

73
 Abstract Class Notation

In the above abstract class notation, there is the only a single abstract method which can be used
by multiple objects of classes.

Example of UML Class Diagram

Creating a class diagram is a straightforward process. It does not involve many technicalities.
Here, is an example:

ATMs system is very simple as customers need to press some buttons to receive cash. However,
there are multiple security layers that any ATM system needs to pass. This helps to prevent fraud
and provide cash or need details to banking customers.

Below given is a UML Class Diagram example:

74
 Class Diagram in Software Development Lifecycle
Class diagrams can be used in various software development phases. It helps in modeling class
diagrams in three different perspectives.

1. Conceptual perspective: Conceptual diagrams are describing things in the real world. You
should draw a diagram that represents the concepts in the domain under study. These concepts
related to class and it is always language-independent.

2. Specification perspective: Specification perspective describes software abstractions or

components with specifications and interfaces. However, it does not give any commitment to
specific implementation.

75
3. Implementation perspective: This type of class diagrams is used for implementations in a
specific language or application. Implementation perspective, use for software implementation.

Best practices of Designing of the Class Diagram

Class diagrams are the most important UML diagrams used for software application development.
There are many properties which should be considered while drawing a Class Diagram. They
represent various aspects of a software application.

Here, are some points which should be kept in mind while drawing a class diagram:

 The name given to the class diagram must be meaningful. Moreover, It should describe the
real aspect of the system.
 The relationship between each element needs to be identified in advance.
 The responsibility for every class needs to be identified.
 For every class, minimum number of properties should be specified. Therefore, unwanted
properties can easily make the diagram complicated.
 User notes should be included whenever you need to define some aspect of the diagram.
At the end of the drawing, it must be understandable for the software development team.
 Lastly, before creating the final version, the diagram needs to be drawn on plain paper.
Moreover, It should be reworked until it is ready for final submission.

Conclusion
 UML is the standard language for specifying, designing, and visualizing the artifacts of
software systems
 A class is a blueprint for an object
 A class diagram describes the types of objects in the system and the different kinds of
relationships which exist among them
 It allows analysis and design of the static view of a software application
 Class diagrams are most important UML diagrams used for software application
development
 Essential elements of UML class diagram are 1) Class 2) Attributes 3) Relationships
 Class Diagram provides an overview of how the application is structured before studying
the actual code. It certainly reduces the maintenance time
 The class diagram is useful to map object-oriented programming languages like Java, C++,
Ruby, Python, etc

What is a State Machine Diagram?

State machine diagrams are also called as state chart diagrams. State machine diagrams are
used to capture the behavior of a software system. UML State machine diagrams can be used to
model the behavior of a class, a subsystem, a package, or even an entire system. It is also called
a Statechart or State Transition diagram.

Statechart diagrams provide us an efficient way to model the interactions or communication that
occur within the external entities and a system. These diagrams are used to model the event-
based system. A state of an object is controlled with the help of an event.

Statechart diagrams are used to describe various states of an entity within the application system.

76
There are a total of two types of state machine diagrams:

1. Behavioral state machine

 It captures the behavior of an entity present in the system.

 It is used to represent the specific implementation of an element.
 The behavior of a system can be modelled using behavioral state machine diagrams.

2. Protocol state machine

 These diagrams are used to capture the behavior of a protocol.

 It represents how the state of protocol changes concerning the event. It also represents
corresponding changes in the system.
 They do not represent the specific implementation of an element.

Notation and Symbol for State Machine

Following are the various notations that are used throughout the state chart diagram. All these
notations, when combined, make up a single diagram.

UML state diagram notations

Initial state
The initial state symbol is used to indicate the beginning of a state machine diagram.

Final state
This symbol is used to indicate the end of a state machine diagram.

Decision box
It contains a condition. Depending upon the result of an evaluated guard condition, a new path is
taken for program execution.

77
 Transition
A transition is a change in one state into another state which is occurred because of some event.
A transition causes a change in the state of an object.

State box
It is a specific moment in the lifespan of an object. It is defined using some condition or a
statement within the classifier body. It is used to represent any static as well as dynamic situations.

It is denoted using a rectangle with round corners. The name of a state is written inside the
rounded rectangle.

The name of a state can also be placed outside the rectangle. This can be done in case of
composite or submachine states. One can either place the name of a state within the rectangle or
outside the rectangle in a tabular box. One cannot perform both at the same time.

A state can be either active or inactive. When a state is in the working mode, it is active, as soon
as it stops executing and transits into another state, the previous state becomes inactive, and the
current state becomes active.

Types of State
Unified Modeling Language defines three types of states:

 Simple state
o They do not have any substrate.
 Composite state
o These types of states can have one or more than one substrate.
o A composite state with two or more substates is called an orthogonal state.
 Submachine state
o These states are semantically equal to the composite states.
o Unlike the composite state, we can reuse the submachine states.

State char diagrams are used,

1. To model objects of a system.

2. To model and implement interactive systems.
3. To display events that trigger changes within the states.

Example of State Machine

Following state chart diagram represents the user authentication process.

78
 UML state diagram

There are a total of two states, and the first state indicates that the OTP has to be entered first.
After that, OTP is checked in the decision box, if it is correct, then only state transition will occur,
and the user will be validated. If OTP is incorrect, then the transition will not take place, and it will
again go back to the beginning state until the user enters the correct OTP.

State machine vs. Flowchart

Statemachine FlowChart

It represents various states of a system. The Flowchart illustrates the program

execution flow.

The state machine has a WAIT concept, The Flowchart does not deal with waiting
i.e., wait for an action or an event. for a concept.

State machines are used for a live Flowchart visualizes branching sequences
running system. of a system.

The state machine is a modeling A flowchart is a sequence flow or a DFD

diagram. diagram.

79
 The state machine can explore various Flowchart deal with paths and control flow
states of a system.

Summary
 Statechart diagrams are also called as state machine diagrams.
 These diagrams are used to model the event-based system.
 A state of an entity is controlled with the help of an event.
 There is a total of two types of state machine diagrams: 1) Behavioral 2) State machine 3)
Protocol state machine
 Statechart diagram is used to capture the dynamic aspect of a system.
 A state is a specific moment in the lifespan of an object.

DESIGN
WELL FORMED DESIGN CLASSES
 Design model is where the customer requirements, business needs and technical considerations all
come together in the formulation of a product or system.

- The design model provides detail about the software data structures, architecture, interface and
components.

- Following are the characteristics of well-formed design class;

Primitiveness
High cohesion
Low coupling

Primitiveness: In this, each method of a class focuses on accomplishing one service for the class.

High cohesion: A cohesive design class has a small, focused set of responsibilities and implement
those responsibilities.

Low coupling: It is necessary for design classes to collaborate with one another. If a design model is
highly coupled the system is difficult to implement, to test and to maintain over time.

 NESTED CLASSES
 A class or interface in the UML could be used as a namespace for other classifiers including
other classes, interfaces, use cases, etc. This nesting of classifiers limits the visibility of the
classifier defined in the class or interface to the scope of the namespace of the container. It
could be used for reasons of information hiding.

80

 Class or interface could nest (contain) other classifiers.
 Nested classifier is a classifier that is defined within the (namespace of) class or interface.
Note, that UML 2.x specification uses "defined within", "nested within" and "owned by" as
synonyms which causes a bit of confusion. Relationship between the namespace and nested
classifier is called namespace ownership.
 Now obsolete UML 1.4.2 Specification defined nested class as a class declared within another
class and belonging to the namespace of the declaring class. Relationship between those
classes was called "namespace owned element association".
 Nested classifier, e.g. nested class, nested interface, or nested use case could be used
like any other classifier but only inside the containing class or interface.
 Per UML 1.4.2 a declaring (nesting) class and a nested class could be shown connected by a
line, with an "anchor" icon on the end connected to the declaring class. An anchor icon is a
cross inside a circle.
 UML 2.x specifications - including the recent UML 2.4.1 - describe nesting of classifiers
within structured classes without providing explicit notation for the nesting. Note, that UML's
1.4 "anchor" notation is still used in one example in UML 2.4.x for packages as an "alternative
membership notation" and without providing any other details or explanations.


 Class LinkedList is nesting the Element interface.
The Element is in scope of the LinkedList namespace.

81
 
 Class InnerOddIterator is nested by DataStructure class.
Class DataElement is aggregated by DataStructure class.
 The nesting (owning) of a use case by a classifier is represented using the standard notation for
nested classifiers.


INHERITANCE
 In OOAD inheritance is usually defined as a mechanism by which more specific classes (called
subclasses or derived classes) incorporate structure and behavior of more general classes
(called superclasses or base classes).
 Inheritance was explained in UML 1.4.2 using the concepts of a full descriptor and a segment
descriptor. A full descriptor contains a description of all of the attributes, associations,
operations, and constraints that the object contains, and is usually implicit because it is built out
of incremental segments combined together using inheritance.
 In an object-oriented language, the description of an object is built out of incremental segments
that are combined using inheritance to produce a full descriptor for an object. The segments are
the modeling elements that are actually declared in a model. They include elements such as
class and other generalizable elements. Each generalizable element contains a list of features
and other relationships that it adds to what it inherits from its ancestors.
 Each kind of generalizable element has a set of inheritable features. For any model element,
these include constraints. For classifiers, these include features ( attributes, operations, signal
receptions, and methods) and participation in associations.


What is Deployment Diagram?

Deployment Diagram is a type of diagram that specifies the physical hardware on which the
software system will execute. It also determines how the software is deployed on the underlying
hardware. It maps software pieces of a system to the device that are going to execute it.

The deployment diagram maps the software architecture created in design to the physical system
architecture that executes it. In distributed systems, it models the distribution of the software
across the physical nodes.

The software systems are manifested using various artifacts, and then they are mapped to the
execution environment that is going to execute the software such as nodes. Many nodes are

82
involved in the deployment diagram; hence, the relation between them is represented using
communication paths.

There are two forms of a deployment diagram.

 Descriptor form
o It contains nodes, the relationship between nodes and artifacts.
 Instance form
o It contains node instance, the relationship between node instances and artifact
instance.
o An underlined name represents node instances.

Purpose of a deployment diagram

Deployment diagrams are used with the sole purpose of describing how software is deployed into
the hardware system. It visualizes how software interacts with the hardware to execute the
complete functionality. It is used to describe software to hardware interaction and vice versa.

Deployment Diagram Symbol and notations

Deployment Diagram Notations

A deployment diagram consists of the following notations:

1. A node
2. A component
3. An artifact
4. An interface

What is an artifact?
An artifact represents the specification of a concrete real-world entity related to software
development. You can use the artifact to describe a framework which is used during the software
development process or an executable file. Artifacts are deployed on the nodes. The most
common artifacts are as follows,

1. Source files
2. Executable files
3. Database tables
4. Scripts

83
 5. DLL files
6. User manuals or documentation
7. Output files

Artifacts are deployed on the nodes. It can provide physical manifestation for any UML element.
Generally, they manifest components. Artifacts are labeled with the stereotype <<artifact>>, and it
may have an artifact icon on the top right corner.

Each artifact has a filename in its specification that indicates the physical location of the artifact.
An artifact can contain another artifact. It may be dependent on one another.

Artifacts have their properties and behavior that manipulates them.

Generally, an artifact is represented as follows in the unified modeling language.

artifact
Artifact Instances
An artifact instance represents an instance of a particular artifact. An artifact instance is denoted
with same symbol as that of the artifact except that the name is underlined. UML diagram allows
this to differentiate between the original artifact and the instance. Each physical copy or a file is an
instance of a unique artifact.

Generally, an artifact instance is represented as follows in the unified modeling language.

artifact instance
What is a node?
Node is a computational resource upon which artifacts are deployed for execution. A node is a
physical thing that can execute one or more artifacts. A node may vary in its size depending upon
the size of the project.

Node is an essential UML element that describes the execution of code and the communication
between various entities of a system. It is denoted by a 3D box with the node-name written inside
of it. Nodes help to convey the hardware which is used to deploy the software.

84
An association between nodes represents a communication path from which information is
exchanged in any direction.

Generally, a node has two stereotypes as follows:

 << device >>

It is a node that represents a physical machine capable of performing computations. A

device can be a router or a server PC. It is represented using a node with stereotype
<<device>>.

In the UML model, you can also nest one or more devices within each other.

Following is a representation of a device in UML:

device node

 << execution environment >>

It is a node that represents an environment in which software is going to execute. For

example, Java applications are executed in java virtual machine (JVM). JVM is considered
as an execution environment for Java applications. We can nest an execution environment
into a device node. You can net more than one execution environments in a single device
node.

Following is a representation of an execution environment in UML:

execution environment node

How to draw a deployment diagram?

85
Deployment diagram visualizes the topological view of an entire system. It represents the
deployment of a system.

A deployment diagram consists of nodes which describe the physical devices used inside the
system. On these nodes, artifacts are deployed. We can also have node instances on which
artifact instances are going to be implemented.

Node and artifacts of a system participate in the final execution of a system.

A deployment diagram plays a critical role during the administrative process, and it must satisfy
the following parameters,

 High performance
 Maintainability
 Scalability
 Portability
 Easily understandable

Nodes and artifacts are the essential elements of deployment. Before actually drawing the
deployment diagram, all nodes and the relationship between every node of the system must be
identified.

You must know the architecture of a system, whether an application is a web application, cloud
application, desktop application, or a mobile application. All these things are critical and plays a
vital role during the development of a deployment diagram.

If all the nodes, relations, and artifacts are known, then it becomes easy to develop a deployment
diagram.

Example of a Deployment diagram

Following deployment diagram represents the working of HTML5 video player in the browser:

86
 Deployment Diagram
When to use a deployment diagram?
Deployment diagrams are mostly used by system administrators, network engineers, etc. These
diagrams are used with the sole purpose of describing how software is deployed into the hardware
system. It visualizes how software interacts with the hardware to execute the complete
functionality.

To make the software work efficiently and at a faster rate, the hardware also must be of good
quality. It must be designed efficiently to make software work properly and produce accurate
results in quick time.

Deployment diagrams can be used for,

1. Modeling the network topology of a system.

2. Modeling distributed systems and networks.
3. Forward and reverse engineering processes.

Summary
 The deployment diagram maps the software architecture created in design to the physical
system architecture that executes it.
 It maps software pieces of a system to the hardware that are going to execute it.
 Deployment diagram visualizes the topological view of an entire system.

87
 Nodes and artifacts are the essential elements of deployment.
 Node and artifacts of a system participate in the final execution of a system

88
 UNIT-I
Architecture 2

History of uml 2

Characteises of uml 3

Conceptual modal 4

Uml diagram 4

Uml tool 5

Goal of uml 6

Purpose of uml 6
UML Views
6
RELATIONSHIPS IN UML 8
EXTENSIBILITY MECHANISMS IN UML. 9
Stereotypes: 9
Tagged Values: 9
Constraints: 10
UNIFIED PROCESS 10
Project lifecycle (Phases of Unified Process) 10
Inception phase 10
Elaboration phase 11
Construction phase 11
Transition phase 11
Unified Process characteristics 12
Iterative and incremental 12
Architecture-centric 12
Risk-focused 13
Architecture
Any real-world system is used by different users. The users can be developers, testers,
business people, analysts, and many more. Hence, before designing a system, the
architecture is made with different perspectives in mind. The most important part is to
visualize the system from the perspective of different viewers. The better we understand the
better we can build the system.

UML Diagrams: Versions, Types, History, Tools,

Examples
What is UML?
UML stands for Unified Modeling Language. It is a standard which is mainly used for creating
object-oriented, meaningful documentation models for any software system present in the real
world. It provides us a way to develop rich models that describe the working of any
software/hardware systems.

UML serves a great way of creating professional documentation which is a necessary part of any
project development. UML is an essential part of creating an object-oriented design of systems. It
provides you means for creating powerful models and designs for rational systems which can be
understood without much difficulties.

Why use UML? Complete History

The 1990s was the era of development of object-oriented languages such as C++. These object-
oriented languages were used to create complex but compelling systems.

As the systems developed were complicated to understand, it led to the design and analysis
problems which were faced after the deployment of the system. It was difficult to explain the
system to others.

As soon as the UML was introduced, many game-changing experiments and approaches were
made for simplifying such difficult tasks of analyzing the system.

UML is an object-oriented unified modeling language. It was invented by brilliant software

engineers Grady Booch, Ivar Jacobson, and James Rumbaugh of Rational software during 1994
and 1995. It was under development until 1996.

Each of UML inventors, viz, Grady Booch, Ivar Jacobson, and James Rumbaugh had a fantastic
idea for designing a language which will reduce the complexity.

 Booch's method was very flexible to work with during the design and construction of
objects.
 Jacobson's method provided a great way to work around use-cases. It also has a powerful
approach for high-level design.
 Rumbaugh's method turned out to be very useful while handling sensitive systems.

2
 UNIT-II
Functional requiremental 13
Non functional requiremental 13
Functional and non functional requrimental 14

USE CASE MODELING 16

Use Case Modeling/Diagram 16
Basic model elements 16
Actor 16
Use Case 16
Associations 16
Advanced model elements 16
Subject 17
Use-Case Package 17
Generalizations 17
Dependencies 17
Example Use-Case Diagram 17
FINDING ACTORS AND USE CASES 18
Finding Actors 18
Finding likely use cases 18

USE CASE SCENARIO(...FLOW) 19

Properties of Use Cases 20

Name 20
Brief Description 21
Flow of Events -- Contents 21
Flow of Events -- Structure 21
Preconditions and Post-conditions 22
Level of detail necessary in use cases 24
Relationship Between Use Cases and Actors 24
USE CASE DIAGRAMS 24
Purpose of Use Case Diagrams 25
How to Draw a Use Case Diagram? 25
Where to Use a Use Case Diagram? 26
 UNIT-III
ANALYSIS 28
Finding Analysis Classes:- 29
Discovering domain classes
30
NOUN/VERB ANALYSIS 30
CRC ANALYSIS 34
Advantages of CRC Index Cards: 37
USING RUP STEREOTYPEPES 38
Boundary Class 38
Finding Boundary Classes 38
Control Class 39
Finding Control Classes 39
Determine whether a Control Class is Needed 40
Encapsulating the Main Flow of Events and Alternate/Exceptional
Flows of Events in separate Control Classes
4
1
Divide Control Classes where two Actors share the same Control Class 41
Entity Class 42
Finding Entity Classes 42
MODELING CLASSES 42
ASSOCIATION 43
ROLE NAME 43
MULTIPLICITY 44
NAVIGABILITY 44
ASSOCIATION CLASS 45
QUALIFIER ASSOCIATION 46
DEPENDENCIES 47
Usage 48
Create 48
Call 49
Send 49
Required Interface 49
ABSTRACTION 50
Notation 51
Derive 52
 «Refine» 52
TRACE 53

CLASS GENERALIZATION 53
INHERITENCE 54
MULTIPLE INHERITENCE 54
GENERALIZATION SETS 55
POWER TYPE 56
USE CASE RELIZATION 56
Class diagram 57
Sequence diagram 58
collaboration and communaction diagram 67
Class diagram 69
State machine diagram 76
State machine vs flow chart 79

UNIT-IV
design
well formed designed class
80

nested classes
80

inheritance
82
deployment diagram
82

artifact
83
 UML Activity Diagram: What is, Components,
Symbol, EXAMPLE

What is an Activity Diagram?

Activity diagram is defined as a UML diagram that focuses on the execution and flow
of the behavior of a system instead of implementation. It is also called object-
oriented flowchart. Activity diagrams consist of activities that are made up of actions
which apply to behavioral modeling technology.

In this, UML tutorial you will learn,

 What is an Activity Diagram?

 Components of Activity Diagram
 Why use Activity Diagrams?
 Activity Diagram Notations
 How to draw an activity diagram?
 Example of Activity Diagram
 When Use Activity Diagram

Components of Activity Diagram

Activities
It is a behavior that is divided into one or more actions. Activities are a network of
nodes connected by edges. There can be action nodes, control nodes, or object
nodes. Action nodes represent some action. Control nodes represent the control flow
of an activity. Object nodes are used to describe objects used inside an activity. Edges
are used to show a path or a flow of execution. Activities start at an initial node and
terminate at a final node.

Activity partition/swimlane
An activity partition or a swimlane is a high-level grouping of a set of related actions. A
single partition can refer to many things, such as classes, use cases, components, or
interfaces.

If a partition cannot be shown clearly, then the name of a partition is written on top of
the name of an activity.
 Fork and Join nodes
Using a fork and join nodes, concurrent flows within an activity can be generated. A
fork node has one incoming edge and numerous outgoing edges. It is similar to one
too many decision parameters. When data arrives at an incoming edge, it is
duplicated and split across numerous outgoing edges simultaneously. A single
incoming flow is divided into multiple parallel flows.

A join node is opposite of a fork node as It has many incoming edges and a single
outgoing edge. It performs logical AND operation on all the incoming edges. This
helps you to synchronize the input flow across a single output edge.

Pins

An activity diagram that has a lot of flows gets very complicated and messy.

Pins are used to clearing up the things. It provides a way to manage the execution
flow of activity by sorting all the flows and cleaning up messy thins. It is an object
node that represents one input to or an output from an action.

Both input and output pins have precisely one edge.

Why use Activity Diagrams?

Activity diagram allows you to create an event as an activity which contains a
collection of nodes joined by edges. An activity can be attached to any modeling
element to model its behavior. Activity diagrams are used to model,

 Use cases
 Classes
 Interfaces
 Components
 Collaborations

Activity diagrams are used to model processes and workflows. The essence of a useful
activity diagram is focused on communicating a specific aspect of a system's dynamic
behavior. Activity diagrams capture the dynamic elements of a system.

Activity diagram is similar to a flowchart that visualizes flow from one activity to
another activity. Activity diagram is identical to the flowchart, but it is not a flowchart.
The flow of activity can be controlled using various control elements in the UML
diagram. In simple words, an activity diagram is used to activity diagrams that
describe the flow of execution between multiple activities.

Activity Diagram Notations

Activity diagrams symbol can be generated by using the following notations:

 Initial states: The starting stage before an activity takes place is depicted as the
initial state
 Final states: The state which the system reaches when a specific process ends is
known as a Final State
 State or an activity box:
 Decision box: It is a diamond shape box which represents a decision with alternate
paths. It represents the flow of control.

Activity Digram Notation and Symbol

How to draw an activity diagram?
Activity diagram is a flowchart of activities. It represents the workflow between various
system activities. Activity diagrams are similar to the flowcharts, but they are not
flowcharts. Activity diagram is an advancement of a flowchart that contains some unique
capabilities.

Activity diagrams include swimlanes, branching, parallel flow, control nodes, expansion
nodes, and object nodes. Activity diagram also supports exception handling.
To draw an activity diagram, one must understand and explore the entire system. All the
elements and entities that are going to be used inside the diagram must be known by the
user. The central concept which is nothing but an activity must be clear to the user. After
analyzing all activities, these activities should be explored to find various constraints that
are applied to activities. If there is such a constraint, then it should be noted before
developing an activity diagram.

All the activities, conditions, and associations must be known. Once all the necessary
things are gathered, then an abstract or a prototype is generated, which is later
converted into the actual diagram.

Following rules must be followed while developing an activity diagram,

1. All activities in the system should be named.

2. Activity names should be meaningful.
3. Constraints must be identified.
4. Activity associations must be known.

Example of Activity Diagram

Let us consider mail processing activity as a sample for Activity Diagram. Following
diagram represents activity for processing e-mails.
 activity diagram

In the above activity diagram, three activities are specified. When the mail checking
process begins user checks if mail is important or junk. Two guard conditions [is
essential] and [is junk] decides the flow of execution of a process. After performing the
activity, finally, the process is terminated at termination node.

When Use Activity Diagram

Activity diagram is used to model business processes and workflows. These diagrams are
used in software modeling as well as business modeling.

Most commonly activity diagrams are used to,

1. Model the workflow in a graphical way, which is easily understandable.

2. Model the execution flow between various entities of a system.
3. Model the detailed information about any function or an algorithm which is used
inside the system.
 4. Model business processes and their workflows.
5. Capture the dynamic behavior of a system.
6. Generate high-level flowcharts to represent the workflow of any application.
7. Model high-level view of an object-oriented or a distributed system

The UML Meta-Model

The UML specification [UML-OMG] is insanely complex and filled with
inconsistencies. Basically, the specification uses UML to specify UML. Thus, the
specification is sometimes referred to as the UML Meta-Model. I'm not sure it's worth
studying the specification in too much detail unless one is building a commercial tool
for processing UML diagrams.
[UML-KF] has done a good job of summarizing the specification here:
http://www.uml-diagrams.org/uml-meta-models.html

Meta-models
The Object Management Group (OMG) is in the business of specifying standards for
object-oriented developers—modeling standards (like UML), middleware standards
(like CORBA), data warehousing standards (like SAS), etc.
Here's my simplified summary of the OMG specifications:
There are three levels of abstraction in the OMG specifications:
M1 = Models (i.e., models created by UML users)
M2 = Meta-Models, M1 models are instances of M2 models = {UML, CWM}
M3 = Meta-Meta-Models, M2 models are instances of M3 models = {MOF}

The Meta Object Facility (MOF) was originally a CORBA type system. It is used for
defining meta-models. MOF is to domain models what EBNF is to grammars. MOF
could be used to define web services as well as OO concepts.
UML and CWM are M2 meta-models that instantiate MOF.
Core + UML
All of the OMG specifications depend on a tiny core of modeling concepts. [UML-KF]
describes these here:
http://www.uml-diagrams.org/uml-core.html

Here's my simplified version:

Everything that appears in a UML diagram is an element. The two most important
types of elements are relationships (arrows) and classifiers (nodes).
A classifier represents a set of instances. Examples of classifiers include classes,
interfaces, packages, components, use cases, actors, data types (primitive types and
enumerations), associations, and collaborations. An instance of a class or interface is
an object, an instance of an association is a link. A classifier can have structural and
behavioral features. For a class these would correspond to attributes and operations.
A directed relationship has a source element and a target element. Dependencies,
generalizations, and realizations are types of directed relationships.
An (binary) association represents a semantic relationship between (two) classes. A
semantic relationship is a relationship is a domain-significant relationship. For
example, there could be many relationships between two people—teacher/student,
parent/child, employee/dependent, etc. But in a genealogy model, for example, we
are probably only interested in the parent/child relationship.
An instance of a parent/child association would be a link connecting an instance of
person representing a parent to an instance of person representing one of the
parent's children. For example:
Here are a few more examples:
A classifier can have many features. Features can be structural or behavioral.
Attributes are examples of structural features for a class (e.g., an account's balance).
Operations are examples of behavioral features for a class (e.g., deposit and
withdraw for accounts).
Behaviors
A behaviored classifier is one that can be associated with one or more behaviors. An
instance of the classifier (called the host) executes a behavior. A behavioral feature
such as an operation is associated with a behavior representing the operations
implementation. This behavior is executed when the operation is invoked.
There are four basic types of behaviors:

An opaque behavior is one with implementation-specific semantics, like a block of

C++ code.
State Machine Behaviors
Some objects have well defined lifecycles which can be described using a state
machine, For example, the lifecycle of a process:
Usually the behavior of an operation is opaque, given by some language-specific
block of code. In some cases the behavior could be specified by a state machine. As
an example, assume Interpreter is a class with a read-execute-print loop method that
perpetually prompts a user for a command, executes the command, then prints the
result.

The repl() operation could be associated with a state machine behavior:

In a state machine arrows represent transitions between states (and are a form of
directed relationship). States and transitions can also have behaviors. For example,
when a classifier instance is in a state it may execute behaviors upon entry, while in
the state, and upon exiting the state. These behaviors can be activities, state
machines, interactions, or opaque.
A transition is triggered by an event (signal, message, change, or time). A transition
may have a Boolean guard that must be satisfied before the transition occurs. In
addition, the transition may have execute several behaviors (called effects).

Activities
Activities can be composite or simple. A simple activity is called an action. A
composite activity consists of activity or action nodes connected by control flow
arrows (another type of directed relationship).
For example, the following ATM machine activity consists of four actions (not
counting the decision nodes):

Kinds of actions include: create, destroy, read, write, insert, delete, send signal,
receive signal, trigger event, accept event, timing event, and opaque. In the example
above display menu might be a write action while get selection might be a read
action.
Events
The execution of a behavior is triggered by an event.

A time even occurs at a specified time. A timeout is an example.

A message event means the classifier instance has received a message such as a
method call.
A change event means some object has changed state.
A signal even is the reception of an asynchronous broadcast signal.

The Five Workflows

Within the Unified Process, five workflows cut across the set of four phases:
Requirements, Analysis, Design, Implementation, and Test. Each workflow is a
set of activities that various project workers perform.

The following subsections provide brief overviews of these workflows.

Requirements
The primary activities of the Requirements workflow are aimed at building the
use case model, which captures the functional requirements of the system being
defined. This model helps the project stakeholders reach agreement on the
capabilities of the system and the conditions to which it must conform.
The use case model also serves as the foundation for all other development
work. Figure 1-2 shows how the use case model influences the other five models
discussed in the subsequent subsections.

Chapter 2 discusses the key aspects of the Requirements workflow. Chapters 7,

8, and 9 describe how this workflow cuts across the Inception, Elaboration, and
Construction phases, respectively.

Figure 1-2: The Six Basic Unified Process Models

Analysis
The primary activities of the Analysis workflow are aimed at building the
analysis model, which helps the developers refine and structure the functional
requirements captured within the use case model. This model contains
realizations of use cases that lend themselves to design and implementation
work better than the use cases.

Chapter 3 discusses the key aspects of the Analysis workflow. Chapters 7, 8,

and 9 describe how this workflow cuts across the Inception, Elaboration, and
Construction phases, respectively.

Design
The primary activities of the Design workflow are aimed at building the design
model, which describes the physical realizations of the use cases from the use
case model, and also the contents of the analysis model. The design model
serves as an abstraction of the implementation model (see the next subsection).

The Design workflow also focuses on the deployment model, which defines the
physical organization of the system in terms of computational nodes.

Requirement Attributes.
Good requirements have the following attributes. They are:

 Complete - they very thoroughly describe the criteria

 Correct - they are accurate and true

 Feasible - they can be accomplished and individual requirements do not
contradict each other.

 Necessary - they are truly needed for the system to function properly and
they are really what the client wants.

 Prioritized - in the case that not all parts of the system can be implemented at
the same time, it's important to be able to distinguish "absolutely necessary"
from "nice to have".

 Unambiguous - they are clear and cannot be misinterpreted

 Verifiable - once implemented, it can be confirmed that the system has met
the requirement through observation and testing

Finding Requirements
it's vital to make sure that the requirements are not too general, and that they are
comprehensive and completely clear. Keep in mind that the person collecting the requirements
might not always be the same person who will be writing the actual code.

So, where and how do we find out about the requirements for a system? The best places are
from:

 Domain Experts - people who are very knowledgeable and work in the area of the system
that is being built

 Users - people who will actually be the ones using the system once it's built

 Existing processes and programs - both manual processes and existing programs

 Find out the limitations of existing systems and software

 Find out where the users' time is spent

 Find out what they like and don't like

 Sit down with the users WHILE they are performing their tasks. Be sure to ask questions to
get a clear idea of what they are doing.
 Review similar software programs - if there is a similar or competing program, this can be a
great resource

Designing with Interfaces and Components

When modeling large object-oriented systems, it is necessary to break down the system
into manageable subsystems. UML component diagrams are used for modeling large
systems into smaller subsystems which can be easily managed.

A component is a replaceable and executable piece of a system whose implementation

details are hidden. A component provides the set of interfaces that a component realizes
or implements. Components also require interfaces to carry out a function.

UML Component diagrams are used to represent different components of a system.

Component diagram Notations

1. A component

component notation

2. A node
 node notation
What is a Component?
A component is a replaceable and executable piece of a system whose implementation
details are hidden. A component provides the set of interfaces that a component realizes
or implements. Components also require interfaces to carry out a function.

It is a modular part of a system that encapsulates its contents. They are the logical
elements of a system that plays an essential role during the execution of a system.

A component is similar to a black box whose external behavior is defined by a provided

interface and required interfaces.

Structure of a component
A component is represented with classifier rectangle stereotypes as

<< component >>. Component details are hidden for the outside world. The name of a
component is placed at the center of a rectangle. A component icon is displayed at the
upper right corner of a rectangle, which is optional.

A component in UML is represented as follows,

 Interface notation
Interfaces
The interface is a named set of public features. It separates the specification of
functionality from its implementation by a class diagram or a subsystem. An interface
symbol cannot be instantiated. It declares a contract that may be realized by zero or
more classifiers such as a class or a subsystem.

Anything that realizes an interface accepts the functionalities of the interface and agrees
to abide by the contract defined by the interface.

If the implementation language does not support interfaces the use abstract classes,
interfaces are named just like classes, in UpperCamelCase.

There are two types of interfaces,

1. Provided interfaces
2. Required interfaces

We can connect provided and required interfaces using assembly connector.

Advantages:

 It increases the flexibility and extensibility of a class.

 It decreases the implementation dependencies.

Disadvantages:

 Extra flexibility leads to complex classes.

 Too many interfaces make systems hard to understand.
 Subsystems
It is a component base that acts as a decomposition unit for larger systems. It is a logical
construct which is used to break down an extensive system into smaller systems which
are known as subsystems. This process makes it easy to manage each subsystem
efficiently.

A subsystem cannot be instantiated during runtime, but their contents can be initialized.
When subsystems are connected, it creates a single system.

Port
A port is an interaction point between a classifier and an external environment. It groups
semantically cohesive set of provided and required interfaces. A port can be used in UML
without specifying the name of the port. A port may have visibility. When a port is drawn
over the boundary of a classifier, then it means that the port is public. It also means that
all the interfaces used are made as public.

When a port is drawn inside the classifier, then it is either protected or private.

A port also has multiplicity that indicates the number of instances of the port classifier
will have. A port in UML diagram is denoted as given below,

port notation

Here the port1 is drawn over the boundary, which means it has visibility as public.

Why use Component Diagram?

UML component diagrams have significant importance. Component diagram variously
differs from other diagrams. While other diagrams are used to represent the system,
working of a system or the architecture of a system. Component diagrams are used to
describe the working and behavior of various components of a system.

It represents how each component acts during the execution of a system.

These are the static diagrams of the unified modeling language. A component diagram is
used to represent the structure and organization of components during any instance of
time.

Component diagrams are used for modeling the subsystems. These subsystems
collectively represent the entire working view of any system. A single component cannot
visualize the whole system, but the collection of multiple components can.

So, component diagrams are used for,

 To represent the components of any system at runtime.

 It helps during testing of a system.
 It visualizes the connection between various components.

When to use Component Diagram?

Component diagrams are different from any other diagrams in UML. Component
diagrams are used to display various components of a software system as well as
subsystems of a single system. They are used to represent physical things or components
of a system. It generally visualizes the structure and an organization of a system.

It describes how various components together make a single, fully functional system. We
can display each component individually or collectively as a single unit.

1. Component diagrams are used to model the component organization of a system.

2. They are used to divide a single system into various subsystems as per the
functionality.

How to draw a component diagram

A component is nothing but an executable piece of a system. Various components
together make a single system. Component diagrams are used widely during the
execution phase of any system.
Before modeling the component diagram, one must know all the components within the
system. The working of each component should be mentioned. Component diagrams are
used to analyze the execution of a system.

One should also explore each component in depth to understand the connection of a
component to other physical artifacts in the system.

The relationship amongst various artifacts, libraries, and files are the essential things
required during modeling of a component diagram.

Example of a component diagram

component diagram Example

Summary
 A component is a replaceable and executable piece of a system.
 A component provides the set of required interfaces that a component realizes or
implements.
 These are the static diagrams of the unified modeling language.
 It is a modular part of a system that encapsulates its contents
 Component diagrams are used to represent the working and behavior of various
components of a system.
 Various components together make a single system.

ports and interfaces in component diagrams