SOFTWARE SYSTEM DESIGN

UNIT I INTRODUCTION
Introduction to OOAD; typical activities / workflows / disciplines in OOAD, Introduction to
iterative development and the Unified Process, Introduction to UML; mapping disciplines to
UML artifacts, Introduction to Design Patterns – goals of a good design, Introducing a case
study & MVC architecture.

UNIT II INCEPTION
Artifacts in inception, Understanding requirements – the FURPS model, Understanding Use case
model – introduction, use case types and formats, Writing use cases – goals and scope of a use
case, elements / sections of a use case, Use case diagrams, Use cases in the UP context and UP
artifacts, Identifying additional requirements, Writing requirements for the case study in the use
case model.

UNIT III ELABORATION

System sequence diagrams for use case model, Domain model : identifying concepts, adding
associations, adding attributes, Interaction Diagrams, Introduction to GRASP design
Patterns
,Design Model: Use case realizations with GRASP patterns, Design Class diagrams in each
MVC layer Mapping Design to Code, Design class diagrams for case study and skeleton code

UNIT IV DESIGN PATTERNS

Fabrication, Indirection, Singleton, Factory, Facade, Publish-Subscribe

UNIT V UML DIAGRAMS

State-Chart diagrams, Activity diagrams, Component Diagrams, Deployment diagrams,
Object diagrams. Advanced concepts in OOAD : Use case relationships, Generalizations Domain
Model refinements, Architecture, Packaging model elements.

UNIT-1 refer pdf of 7 pages named as software system design

UNIT II INCEPTION
Artifacts in inception, Understanding requirements – the FURPS model, Understanding Use case
model – introduction, use case types and formats, Writing use cases – goals and scope of a use
case, elements / sections of a use case, Use case diagrams, Use cases in the UP context and UP
artifacts, Identifying additional requirements, Writing requirements for the case study in the use
case model.
Inception Phase
Typical artifacts that could be produced:

• A vision document: a general vision of the core project’s requirements, key features, and main constraints.

• A initial use-case model, 10% -20% complete.

• A business model, if necessary.

• An initial business case, which includes business context, success criteria (revenue projection, market
recognition, and so on), and financial forecast.

• An initial project glossary (may optionally be partially expressed as a domain model).

• An initial risk assessment.

• A project plan, showing phases and iterations.

• One or several prototypes.

The evaluation criteria for the inception phase are:

• Stakeholder concurrence on scope definition and cost/schedule estimates.

• Requirements understanding as evidenced by the fidelity of the primary use cases.

• Credibility of the cost/schedule estimates, priorities, risks, and development process.

• Actual expenditures versus planned expenditures.

• Depth and breadth of any architectural prototype that was developed.

FURPS+ Model
Requirements

Requirements are capabilities and conditions to which the system must conform. A prime challenge of
requirements work is to find, communicate, and record what is really needed, in a form that clearly speaks to
the client and development team members.

What are the types and categories of Requirements?

In UP requirements are categorized according to FURPS+ model. The FURPS is a technique to validate the
prioritized requirements after an understanding with client’s needs and necessities. The acronym FURPS
stands for Functionality, Usability, Reliability, Performance, and Supportability.

 Functionality – The F in the FURPS+ acronym represents the main product features that are familiar
within the business domain of the solution being developed. Functional requirements may include:
o Features
o Capabilities
o Security
 Usability – Usability includes looking at, capturing, and stating requirements based around user
interface issues.Usability requirements may include:
o Human factors
o Help and Documentation
o Interface aesthetics, and consistency within the user interface
 Reliability– Reliability includes aspects such as:
o Frequency of failure
o Availability
o Recoverability
o Predictability
For example, computations, or recoverability of the system from shut-down failure.
 Performance – Performance involves things such as:
o Throughputof information through the system
 o System response time.
o Recovery time.
o Start-up time.
o Accuracy
o Availability
o Resource usage
 Supportability – specify number of other requirements such as:
o Testability
o Adaptability
o Maintainability
o Compatibility
o Configurability
o Installability
o Scalability
o Localizability, and so on.

The “+” of the FURPS+ indicates ancillary and sub-factors to specify constraints, including design,
implementation, interface, and physical constraints.

 Design Constraints – A design constraint, as the name implies, limits the design — for example,
requiring a relational database stipulates the approach that we take in developing the system.
 Implementation Constraints – An implementation constraint puts limits on coding or construction –
standards, platform, or implementation language.
 Interface Constraints – An interface constraint is a requirement to interact with an external item.
When you develop within an enterprise, quite often you have to interact with external systems
 Physical constraints – Physical constraints affect the hardware used to house the system – for
example, shape, size, and weight.
Use-Case Model

The Use-case model is defined as a model which is used to show how users interact with the system in order
to solve a problem. As such, the use case model defines the user's objective, the interactions between the
system and the user, and the system's behavior required to meet these objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the association
between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the communication
simpler. There will regularly be a numerous use-case diagram which is related to the given model, each
demonstrating a subset of the model components related to a specific purpose. A similar model component
might be appearing on a few use-case diagrams; however, each use-case should be consistent. If, in order to
handle the use-case model, tools are used then this consistency restriction is automated so that any variations
to the component of the model (changing the name, for instance) will be reflected automatically on each use-
case diagram, which shows that component.

Components of Basic Model

There are various components of the basic model:

1. Actor
 2. Use Case
3. Associations

Actor

Usually, actors are people involved with the system defined on the basis of their roles. An actor can be
anything such as human or another external system.

Use Case

The use case defines how actors use a system to accomplish a specific objective. The use cases are generally
introduced by the user to meet the objectives of the activities and variants involved in the achievement of the
goal.

Associations

Associations are another component of the basic model. It is used to define the associations among actors
and use cases they contribute in. This association is called communicates-association.

Advanced Model Components

There are various components of the advanced model:

1. Subject
2. Use-Case Package
3. Generalizations
4. Generalizations
5. Dependencies

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system appropriately. We
need to find out every function which is offered by the system. When we find out all the system's
functionalities then we convert these functionalities into a number of use cases, and we use these use-cases
in the use case diagram.

A use case means essential functionality of any working system. When we organize the use cases, then next
we need to enlist the numerous actors or things that will collaborate with the system. These actors are used
to implement the functionality of a system. Actors can be someone or something. It can likewise be a private
system's entity. The actors should be pertinent to the functionality or a system in which the actors are
interacting.

We have to follow the following rules while drawing use-case for any framework:

o The use case name and actor name should be meaningful and related to the system.
o The actor's interaction with the use case should be well-described and in a comprehensible manner.
o Use annotations wherever they are essential.
o If the actor or use case has many relationships, then display only important interactions.
When to Use a Use-Case Diagram?

The use-case diagram is an extraordinary system's functionality that is accomplished by a client. The
objective of use-case diagram is to capture the system's key functionalities and visualize the interactions of
different thinkings known as actors with the use case. It is the basic use of use-case diagram.

With the help of the use-case diagram, we can characterize the system's main part and flow of work among
them. In the use-case, the implementation of details is hidden from external use, and only the flow of the
event is represented.

Using use-case diagrams, we can detect the pre-and post-conditions after communication with the actor. We
can determine these conditions using several test cases.

Generally, the use-cases diagram is used for:

o Examining the system's requirements.

o Capturing the system's Functionalities.
o We use use-case diagram in order to modeling the general idea behind the system.
o System's Forward and reverse engineering using several test cases.
o Complex visual designing of software.

There are various tips for drawing a use-case diagram:

o It must be complete.
o It must be simple.
o The use-case diagram must show each and every interaction with the use case.
o It is must that the use-case should be generalized if it is large.
o At least one system module must be defined in the use case diagram.
o When there are number of actors or use-cases in the use-case diagram, only the significant use-cases
must be represented.
o The use-case diagrams must be clear and easy so that anyone can understand them easily.

Importance of Use-Case Diagram

Use Cases have been broadly used over the last few years. There are various benefits of the use-case
diagram:

o Use-case diagram provides an outline related to all components in the system. Use-case diagram
helps to define the role of administrators, users, etc.
o The use-Case diagram helps to provide solutions and answers to various questions that may pop up if
you begin a project unplanned.
o It helps us to define the needs of the users extensively and explore how it will work.

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System

With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We
need to put the actors outside the system's boundaries.

Use-Case

With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order to
represent the functions of the system.

Actors

Actors mean the system's users. If one system is the actor of the other system, then with the actor stereotype,
we have to tag the actor system.

Relationships

With the simple line we can represent relationships between an actor and use cases. For relationships
between use-case, we use arrows which are labeled either "extends" or "uses". The "extends" relationship
shows the alternative options under the specific use case. The "uses" relationship shows that single use-case
is required to accomplish a job.

Guidelines for Better Use-Cases

With regards to examine the system's requirements, use-case diagrams are another one to one. Use-cases are
simple to understand and visual. The following are some guidelines that help you to make better use cases
that are appreciated by your customers and peers the same.
Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and boundaries may
be included in the complex larger diagrams. We'll talk about the guidelines of the use-case diagram on the
basis of the objects.

Do not forget that these are the use case diagram's guidelines, not rules of the use-case diagram.

Actors
o The actor's name should be meaningful and relevant to the business
If the use-case interacting with the outside organization, then we have to give the actor's name with
the function instead of the organization name, such as Airline company is better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the actors more
readable and easily highlights the use-cases, which are exact for that actor.
o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email management
software, then in this case, the software is an actor to that specific user-case.

Use-Cases
o The name of the use-case begins with a verb
The use-case models action, so the name of the use-case must start with a verb.
o The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a diagram, such as
instead of "Print," "print Invoice is good.
o Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-cases to the right of
the invoking use-cases.
o Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting use-case below the
parent use-case.

Systems/Packages
o Give descriptive and meaningful names to these objects.
o Use them carefully and only if needed.

Relationships
o When we are using <<extend>> arrow, points to the base use-case.
o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.
Use-Case Examples
Use-Case Example-Association Link

In this use-case diagram, we show a group of use cases for a system which means the relationship among the
use-cases and the actor.

Use-Case Example-Include Relationship

In order to add additional functionality that is not specified in the base use-case, we use to include
relationship. We use it to comprise the general behavior from an included use case into a base case so that
we can support the reuse general behavior.

Use-Case Example-Extend Relationship

With the help of the extend relationship, we can show the system behavior or optional functionality. We use
<<extend>> relationship in order to comprise optional behavior from an extending use-case in an extended
use-case. For example, the below diagram of the use-case displays an extend connector and an extension
point "Search".

Use-Case Example-Generalization Relationship

In the generalization relationship, the child use-case can inherit the meaning and behavior of the parent use-
case. The child use-case is able to override and adds the parent's behavior. The below diagram is an example
of generalization relationship in which two generalization connector is connected among three use-cases.
Use-Case Diagram-Vehicle Sales Systems

The below diagram displays an instance of a use-case diagram for a vehicle system. As we can also see, a
system as much as one vehicle sales system contains not in excess of 10 use-cases, and it is the delicacy of
use-case modeling.

The use of include and extend is also displayed by the use-case model. In addition, there are associations
that link between the use-case and actors.

Use-Case Diagram-Student Management System

The below figure shows the working of the student management system:
In the above use-case diagram of the student management system, we have two actors and five use-cases.
The name of the actors is Student and Teacher. The use-cases represent the definite functionality of the
student management system. Every actor interacts with a specific use-case. The student actor is able to
check the test marks, time-table and attendance. These are only 3 interactions that can be performed by the
student actor; however various use-cases are also remaining in the system.

It is not must that every actor has to interact with each and every use-case, but it can happen.

In the diagram, the name of the second actor is a Teacher. Teacher is an actor that is able to interact with all
the system's functionalities. The teacher actor is also able to update the student's marks as well as
attendance. Theses interactions of student as well as teacher actors together summarize the whole student
management application.

Elements of a Use Case

Depending on how in depth and complex you want or need to get, use cases describe a combination of the
following elements:

 Actor – anyone or anything that performs a behavior (who is using the system)
 Stakeholder – someone or something with vested interests in the behavior of the system under
discussion (SUD)
 Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
 Preconditions – what must be true or happen before and after the use case runs.
 Triggers – this is the event that causes the use case to be initiated.
 Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
 Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These
exceptions are what happen when things go wrong at the system level.
How To Write a Use Case
Write the steps in a use case in an easy-to-understand narrative. Kenworthy (1997) outlines the following
steps:
1. Identify who is going to be using the website.
2. Pick one of those users.
3. Define what that user wants to do on the site. Each thing the use does on the site becomes a use
case.
4. For each use case, decide on the normal course of events when that user is using the site.
 5. Describe the basic course in the description for the use case. Describe it in terms of what the user
does and what the system does in response that the user should be aware of.
6. When the basic course is described, consider alternate courses of events and add those to
"extend" the use case.
7. Look for commonalities among the use cases. Extract these and note them as common course use
cases.
8. Repeat the steps 2 through 7 for all other users.
9. There are two different types of use cases: business use cases and system use cases.
10. A business use case is a more abstract description that's written in a technology-agnostic way,
referring only to the business process being described and the actors that are involved in the activity.
A business use case identifies the sequence of actions that need to be performed by the business to
provide a meaningful, observable result to the end user.
11. On the other hand, a system use case is written with more detail than a business use case, referring to
the specific processes that must happen in various parts of the system to reach the final user goal. A
system use case diagram will detail functional specifications, including dependencies, necessary
internal supporting features and optional internal features.

Benefits of use case

A single use case can benefit developers by revealing how a system should behave while also helping
identify any errors that could arise in the process.

Other benefits of use case development include:

 The list of goals created in the use case writing process can be used to establish the complexity
and cost of the system.

 By focusing both on the user and the system, real system needs can be identified earlier in the
design process.

 Since use cases are written primarily in a narrative language they are easily understood by
stakeholders, including customers, users and executives -- not just by developers and testers.

 The creation of extending use cases and the identification of exceptions to successful use case
scenarios saves developers time by making it easier to define subtle system requirements.

 By identifying system boundaries in the design scope of the use case, developers can avoid scope
creep.

 Premature design can be avoided by focusing on what the system should do rather than how it
should do it.
Scopes: Strategic and System
Strategic Scope:

The goal (Use Case) is a strategic goal with respect to the system. These goals are
goals of value to the organization. The use case shows how the system is used to
benefit the organization.
 These strategic use cases will eventually use some of the same lower level
(subordinate) use cases.

System Scope:

Use cases at system scope are bounded by the system under development. The goals
represent specific functionality required of the system. The majority of the use cases
are at system scope. These use cases are often steps in strategic level use cases
Refer 31 page

UNIT III ELABORATION

System sequence diagrams for use case model, Domain model : identifying concepts, adding
associations, adding attributes, Interaction Diagrams, Introduction to GRASP design
Patterns
,Design Model: Use case realizations with GRASP patterns, Design Class diagrams in each
MVC layer Mapping Design to Code, Design class diagrams for case study and skeleton code
Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed as an event diagram.
It helps in envisioning several dynamic scenarios. It portrays the communication between any two lifelines
as a time-ordered sequence of events, such that these lifelines took part at the run time. In UML, the lifeline
is represented by a vertical bar, whereas the message flow is represented by a vertical dotted line that
extends across the bottom of the page. It incorporates the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.
2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is positioned at the top of
the diagram.
Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of the scope of the
system. It represents the role, which involves human users and external hardware or subjects. An actor may
or may not represent a physical entity, but it purely depicts the role of an entity. Several distinct roles can be
played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which an operation is
performed by an element, such that the top and the bottom of the rectangle is associated with the initiation
and the completion time, each respectively.

Messages

The messages depict the interaction between the objects and are represented by arrows. They are in the
sequential order on the lifeline. The core of the sequence diagram is formed by messages and lifelines.
Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an interaction, which
represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of interaction that
represent the flow of information from the receiver of the corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an interaction that
represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive message. In
other words, it can be said that the recursive message is a special case of the self message as it
represents the recursive calls.
 o Create Message: It describes a communication, particularly between the lifelines of an interaction
describing that the target (lifeline) has been instantiated.

Destroy Message: It describes a communication, particularly between the lifelines of an interaction

that depicts a request to destroy the lifecycle of the target.

Duration Message: It describes a communication particularly between the lifelines of an interaction,

which portrays the time passage of the message while modeling a system.

Sequence Fragments
1. Sequence fragments have been introduced by UML 2.0, which makes it quite easy for the creation
and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of interaction inside a
sequence diagram.
3. The type of fragment is shown by a fragment operator.
Types of fragments

Following are the types of fragments enlisted below;

Operato Fragment Type

r

alt Alternative multiple fragments: The only fragment for which the condition is true, will execute.

opt Optional: If the supplied condition is true, only then the fragments will execute. It is similar to alt
with only one trace.

par Parallel: Parallel executes fragments.

loop Loop: Fragments are run multiple times, and the basis of interaction is shown by the guard.

region Critical region: Only one thread can execute a fragment at once.

neg Negative: A worthless communication is shown by the fragment.

ref Reference: An interaction portrayed in another diagram. In this, a frame is drawn so as to cover the
lifelines involved in the communication. The parameter and return value can be explained.

sd Sequence Diagram: It is used to surround the whole sequence diagram.

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.

Any online customer can search for a book catalog, view a description of a particular book, add a book to its
shopping cart, and do checkout.
Benefits of a Sequence Diagram
1. It explores the real-time application.
2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
3. Since each sequence needs distinct notations for its representation, it may make the diagram more
complex.
4. The type of sequence is decided by the type of message.

UML - Interaction Diagrams

From the term Interaction, it is clear that the diagram is used to describe some type of interactions among the
different elements in the model. This interaction is a part of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the
structural organization of the objects that send and receive messages.
Purpose of Interaction Diagrams
The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing the
interaction is a difficult task. Hence, the solution is to use different types of models to capture the different
aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but from a different angle.
The purpose of interaction diagram is −
To capture the dynamic behaviour of a system.

To describe the message flow in the system.

To describe the structural organization of the objects.

To describe the interaction among objects.

How to Draw an Interaction Diagram?
As we have already discussed, the purpose of interaction diagrams is to capture the dynamic aspect of a
system. So to capture the dynamic aspect, we need to understand what a dynamic aspect is and how it is
visualized. Dynamic aspect can be defined as the snapshot of the running system at a particular moment
We have two types of interaction diagrams in UML. One is the sequence diagram and the other is the
collaboration diagram. The sequence diagram captures the time sequence of the message flow from one
object to another and the collaboration diagram describes the organization of objects in a system taking part
in the message flow.
Following things are to be identified clearly before drawing the interaction diagram
 Objects taking part in the interaction.
 Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.
Following are two interaction diagrams modeling the order management system. The first diagram is a
sequence diagram and the second is a collaboration diagram
The Sequence Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram shows the message sequence for SpecialOrder object and the same can be used in
case of NormalOrder object. It is important to understand the time sequence of message flows. The message
flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a
method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder object.
The following diagram mainly describes the method calls from one object to another, and this is also the
actual scenario when the system is running.
The Collaboration Diagram
The second interaction diagram is the collaboration diagram. It shows the object organization as seen in the
following diagram. In the collaboration diagram, the method call sequence is indicated by some numbering
technique. The number indicates how the methods are called one after another. We have taken the same
order management system to describe the collaboration diagram.
Method calls are similar to that of a sequence diagram. However, difference being the sequence diagram
does not describe the object organization, whereas the collaboration diagram shows the object organization.
To choose between these two diagrams, emphasis is placed on the type of requirement. If the time sequence
is important, then the sequence diagram is used. If organization is required, then collaboration diagram is
used.

Where to Use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe the dynamic nature of a system.
Now, we will look into the practical scenarios where these diagrams are used. To understand the practical
application, we need to understand the basic nature of sequence and collaboration diagram.
The main purpose of both the diagrams are similar as they are used to capture the dynamic behavior of a
system. However, the specific purpose is more important to clarify and understand.
Sequence diagrams are used to capture the order of messages flowing from one object to another.
Collaboration diagrams are used to describe the structural organization of the objects taking part in the
interaction. A single diagram is not sufficient to describe the dynamic aspect of an entire system, so a set of
diagrams are used to capture it as a whole.
Interaction diagrams are used when we want to understand the message flow and the structural organization.
Message flow means the sequence of control flow from one object to another. Structural organization means
the visual organization of the elements in a system.
Interaction diagrams can be used −
To model the flow of control by time sequence.

To model the flow of control by structural organizations.

For forward engineering.

For reverse engineering.

GRASP (object-oriented design)
General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, is a set of
"nine fundamental principles in object design and responsibility assignment"[1]: 6 first published by Craig
Larman in his 1997[citation needed] book Applying UML and Patterns.
The different patterns and principles used in GRASP are controller, creator, indirection, information expert,
low coupling, high cohesion, polymorphism, protected variations, and pure fabrication.[2] All these patterns
solve some software problem common to many software development projects. These techniques have not
been invented to create new ways of working, but to better document and standardize old, tried-and-
tested programming principles in object-oriented design.

Contents

 Patterns

o 1.1Information expert

o 1.2Creator

o 1.3Controller

o 1.4Indirection

o 1.5Low coupling

o 1.6High cohesion

o 1.7Polymorphism

o 1.8Protected variations

o 1.9Pure fabrication

Patterns[edit]
In object-oriented design, a pattern is a named description of a problem and solution that can be applied in
new contexts; ideally, a pattern advises us on how to apply its solution in varying circumstances and
considers the forces and trade-offs. Many patterns, given a specific category of problem, guide the
assignment of responsibilities to objects.
Information expert
Problem: What is a basic principle by which to assign responsibilities to objects?
Solution: Assign responsibility to the class that has the information needed to fulfill it.
Information expert (also expert or the expert principle) is a principle used to determine where to delegate
responsibilities such as methods, computed fields, and so on.
Using the principle of information expert, a general approach to assigning responsibilities is to look at a
given responsibility, determine the information needed to fulfill it, and then determine where that
information is stored.
Creator
The creation of objects is one of the most common activities in an object-oriented system. Which class is
responsible for creating objects is a fundamental property of the relationship between objects of particular
classes.
Problem: Who creates object A ?
Solution: In general, Assign class B the responsibility to create object A if one, or preferably more, of the
following apply:

 Instances of B contain or compositely aggregate instances of A

 Instances of B record instances of A
 Instances of B closely use instances of A
 Instances of B have the initializing information for instances of A and pass it on creation
Controller
The controller pattern assigns the responsibility of dealing with system events to a non-UI class that
represents the overall system or a use case scenario. A controller object is a non-user interface object
responsible for receiving or handling a system event.
Problem: Who should be responsible for handling an input system event?
Solution: A use case controller should be used to deal with all system events of a use case, and may be used
for more than one use case. For instance, for the use cases Create User and Delete User, one can have a
single class called UserController, instead of two separate use case controllers. Alternatively a facade
controller would be used; this applies when the object with responsibility for handling the event represents
the overall system or a root object.
Indirection
The indirection pattern supports low coupling and reuses potential between two elements by assigning the
responsibility of mediation between them to an intermediate object. An example of this is the introduction of
a controller component for mediation between data (model) and its representation (view) in the model-view-
controller pattern. This ensures that coupling between them remains low.
Problem: Where to assign responsibility, to avoid direct coupling between two (or more) things? How to de-
couple objects so that low coupling is supported and reuse potential remains higher?
Solution: Assign the responsibility to an intermediate object to mediate between other components or
services so that they are not directly coupled.
The intermediary creates an indirection between the other components.
Low coupling
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other
elements. Low coupling is an evaluative pattern that dictates how to assign responsibilities for the following
benefits:

 lower dependency between the classes,

  change in one class having a lower impact on other classes,
 higher reuse potential.
High cohesion
High cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and
understandable. High cohesion is generally used in support of low coupling. High cohesion means that the
responsibilities of a given set of elements are strongly related and highly focused on a rather specific topic.
Breaking programs into classes and subsystems, if correctly done, is an example of activities that increase
the cohesive properties of named classes and subsystems. Alternatively, low cohesion is a situation in which
a set of elements, of e.g., a subsystem, has too many unrelated responsibilities. Subsystems with low
cohesion between their constituent elements often suffer from being hard to comprehend, reuse, maintain
and change as a whole.
Polymorphism
According to the polymorphism principle, responsibility for defining the variation of behaviors based on
type is assigned to the type for which this variation happens. This is achieved using polymorphic operations.
The user of the type should use polymorphic operations instead of explicit branching based on type.
Problem: How to handle alternatives based on type? How to create pluggable software components?
Solution: When related alternatives or behaviors vary by type (class), assign responsibility for the behavior
—using polymorphic operations—to the types for which the behavior varies. (Polymorphism has several
related meanings. In this context, it means "giving the same name to services in different objects".)
Protected variations
The protected variations pattern protects elements from the variations on other elements (objects, systems,
subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various
implementations of this interface.
Pure fabrication
A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to
achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by
the information expert pattern does not). This kind of class is called a "service" in domain-driven design.

Use-Case Realizations To quote, “A use-case realization describes how a particular use case is realized
within the design model, in terms of collaborating objects” [RUP]. More precisely, a designer can describe
the design of one or more scenarios of a use case; each of these is called a use-case realization. Use-case
realization is a UP term or concept used to remind us of the connection between the requirements expressed
as use cases, and the object design that satisfies the requirements. UML interaction diagrams are a common
language to illustrate use-case realizations. And as was explored in the prior chapter, there are principles and
patterns of object design, such as Information Expert and Low Coupling, that can be applied during this
design work. To review, Figure 17.20 (near the end of this chapter) illustrates the relationship between some
UP artifacts: The use case suggests the system events that are explicitly shown in system sequence
diagrams. Details of the effect of the system events in terms of changes to domain objects may optionally be
described in system operation contracts. The system events represent messages that initiate interaction
diagrams, which illustrate how objects interact to fulfill the required tasks—the use case realization. The
interaction diagrams involve message interaction between software objects whose names are sometimes
inspired by the names of conceptual classes in the Domain Model, plus other classes of objects.

MVC Design Pattern

The Model View Controller (MVC) design pattern specifies that an application consist of a data model,
presentation information, and control information. The pattern requires that each of these be separated into
different objects.
MVC is more of an architectural pattern, but not for complete application. MVC mostly relates to the UI /
interaction layer of an application. You’re still going to need business logic layer, maybe some service layer
and data access layer.
 UML Diagram MVC Design Pattern

Design components
 The Model contains only the pure application data, it contains no logic describing how to present
the data to a user.
 The View presents the model’s data to the user. The view knows how to access the model’s data,
but it does not know what this data means or what the user can do to manipulate it.
 The Controller exists between the view and the model. It listens to events triggered by the view
(or another external source) and executes the appropriate reaction to these events. In most cases,
the reaction is to call a method on the model. Since the view and the model are connected
through a notification mechanism, the result of this action is then automatically reflected in the
view.
Let’s see an example of MVC Design Pattern.

class Student
{
private String rollNo;
private String name;

public String getRollNo()

{
return rollNo;
}

public void setRollNo(String rollNo)

{
this.rollNo = rollNo;
}

public String getName()

{
return name;
}

public void setName(String name)

{
this.name = name;
}
}

class StudentView
{
public void printStudentDetails(String studentName, String studentRollNo)
{
System.out.println("Student: ");
System.out.println("Name: " + studentName);
System.out.println("Roll No: " + studentRollNo);
}
}

class StudentController
{
private Student model;
private StudentView view;

public StudentController(Student model, StudentView view)

{
this.model = model;
this.view = view;
}

public void setStudentName(String name)

{
model.setName(name);
}

public String getStudentName()

{
return model.getName();
}

public void setStudentRollNo(String rollNo)

{
model.setRollNo(rollNo);
}

public String getStudentRollNo()

{
return model.getRollNo();
}

public void updateView()

{
view.printStudentDetails(model.getName(), model.getRollNo());
}
}

class MVCPattern
{
public static void main(String[] args)
{
Student model = retriveStudentFromDatabase();
 StudentView view = new StudentView();

StudentController controller = new StudentController(model, view);

controller.updateView();

controller.setStudentName("Vikram Sharma");

controller.updateView();
}

private static Student retriveStudentFromDatabase()

{
Student student = new Student();
student.setName("Lokesh Sharma");
student.setRollNo("15UCS157");
return student;
}

Output:
Student:
Name: Lokesh Sharma
Roll No: 15UCS157
Student:
Name: Vikram Sharma
Roll No: 15UCS157
Advantages
 Multiple developers can work simultaneously on the model, controller and views.
 MVC enables logical grouping of related actions on a controller together. The views for a
specific model are also grouped together.
 Models can have multiple views.
Disadvantages
 The framework navigation can be complex because it introduces new layers of abstraction and
requires users to adapt to the decomposition criteria of MVC.
 Knowledge on multiple technologies becomes the norm. Developers using MVC need to be
skilled in multiple technologies.
This article is contributed by Saket Kumar. If you like GeeksforGeeks and would like to contribute, you can
also write an article using contribute.geeksforgeeks.org or mail your article to
[email protected]. See your article appearing on the GeeksforGeeks main page and help other
Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic
discussed above.

Class diagrams refer it from the javatpoint websites

 UNIT IV DESIGN PATTERNS
Fabrication, Indirection, Singleton, Factory, Facade, Publish-Subscribe

Design Pattern - Overview

Design patterns represent the best practices used by experienced object-oriented software developers.
Design patterns are solutions to general problems that software developers faced during software
development. These solutions were obtained by trial and error by numerous software developers over quite a
substantial period of time.
What is Gang of Four (GOF)?
In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book
titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of
Design Pattern in Software development.
These authors are collectively known as Gang of Four (GOF). According to these authors design patterns
are primarily based on the following principles of object orientated design.
 Program to an interface not an implementation
 Favor object composition over inheritance
Usage of Design Pattern
Design Patterns have two main usages in software development.
Common platform for developers
Design patterns provide a standard terminology and are specific to particular scenario. For example, a
singleton design pattern signifies use of single object so all developers familiar with single design pattern
will make use of single object and they can tell each other that program is following a singleton pattern.
Best Practices
Design patterns have been evolved over a long period of time and they provide best solutions to certain
problems faced during software development. Learning these patterns helps unexperienced developers to
learn software design in an easy and faster way.
Types of Design Patterns
As per the design pattern reference book Design Patterns - Elements of Reusable Object-Oriented
Software , there are 23 design patterns which can be classified in three categories: Creational, Structural and
Behavioral patterns. We'll also discuss another category of design pattern: J2EE design patterns.

S.N. Pattern & Description

1 Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic,
rather than instantiating objects directly using new operator. This gives program more
flexibility in deciding which objects need to be created for a given use case.

2 Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is
used to compose interfaces and define ways to compose objects to obtain new
functionalities.
 3 Behavioral Patterns
These design patterns are specifically concerned with communication between objects.

4 J2EE Patterns
These design patterns are specifically concerned with the presentation tier. These patterns
are identified by Sun Java Center.

NDIRECTION

A key design principle in a software engineer’s arsenal

 “All problems in computer science can be solved by another level of indirection.” [David
Wheeler]
 “Most performance problems in computer science can be solved by removing a layer of
indirection” [unknown]

Indirection is one of the most useful (and simple) techniques in a software engineer’s arsenal. It is a powerful

technique for decoupling software units by introducing a layer between two existing units/layers, enabling the

introduction of new behaviour, without directly impairing the existing units. See the figure below.

Indirection removes direct coupling between units and promotes:

 Extensibility. Facilitates functional extension that belongs neither in the client or target. Logging,
metrics, transaction management, and remote method invocations are examples of cross domain
responsibilities, seen as “plumbing” logic that should not pollute (or be tightly-coupled to)
business logic. Aspect oriented programming is a popular solution for this problem.
 Modifying a target interface to meet client interface needs. This is useful when the target’s
interface cannot change, possibly because others are already tightly coupled to it, or the target is
not under your control (Control).
  Encapsulate technology specifics. Ensures client and target communicate embedding a
technological coupling in them. This promotes the use of different technologies without affecting
either party, and promotes Evolvability.
 Encapsulation of code or design complexity. You don’t always want clients/consumers to know
of complex interactions of design choices. By ensuring clients remain decoupled from
the how (or even the order that) something is done, we facilitate change.

Indirection can, under the right circumstances improve Reuse (high

cohesion), Flexibility, Maintainability, Extensibility, and Evolvability.

Indirection can be categorised into the following main groups (discussed next):

 Behavioural Extension.
 Interface Modification.
 Technology Encapsulation.
 Complexity Encapsulation.

BEHAVIOURAL EXTENSION

Indirection is commonly used to add behaviours not necessarily belonging to the client or target. These

behaviours are typically added without direct awareness of either party. This solution

promotes Reuse and Flexibility by reducing coupling (e.g. Assumptions); making each unit available in more

contexts. See the figure below.

The Proxy and Decorator design patterns are canonical examples of the approach. Proxy uses indirection to

add logic to determine whether to call a target. Whilst Decorator attaches behaviour(s) to the target

behaviour, increasing its level of functionality without polluting it.

INTERFACE MODIFICATION
Indirection is also useful for changing a target interface. This is often called “wrapping”. See below.

Wrapping enables the wrapped target to be utilised even when its interface does not match one expected of

the client.

The Adapter and Mediator design patterns use Indirection to modify how an interface looks. Clients utilise a

target service (by applying Adapter or Mediator), even if the target does not match what is expected.

Whilst Adapter modifies the target interface to match one expected by the client, Mediator modifies both

client and target interfaces, enabling a two-way, “mediated” communication between them (Hub-and-

Spoke is a form of Mediator).

TECHNOLOGY ENCAPSULATION

Indirection is also useful for technology encapsulation. See below.

Flexibility is a key architectural concern for many enterprises (it can promote Sellability, for instance), and

technology independence often drives it. Indirection promotes loose coupling; enabling technologies to be

more easily interchanged. The end result? Better Evolvability, an extended product lifetime, and thus

increased ROI.

The Business Delegate and Service Adapter design patterns are examples of Technology Indirection,

encapsulating EJB and Web Service technologies respectively. And whilst I’m not a huge advocate of this

approach, I’ve also seen solutions that wrap legacy SOAP APIs with a REST equivalent to satisfy external
consumers, which is a form of Technology Indirection (I’ll let you figure out why wrapping SOAP with

REST, devoid of any deep thinking, might not be a good practice).

Technology Indirection also promotes target reuse by reducing assumptions in the target; see below.

The target is currently only available to clients through Technology A. Yet the target remains technologically

agnostic, enabling us to wrap it with other technologies, without pollution. See below.

COMPLEXITY ENCAPSULATION

Some implementations may be so complex that understanding is almost impossible (e.g. it’s too complex to

be read in isolation). Indirection can be useful here — by moving the complexity into another layer, we can

reduce code complexity and promote maintainability. See below.

There’s a secondary reason that you might consider this solution. It can also be used to hide embarrassing

design decisions that would hurt your Reputation if they were exposed to external consumers.
Design Pattern - Singleton Pattern

Singleton pattern is one of the simplest design patterns in Java. This type of design pattern comes under
creational pattern as this pattern provides one of the best ways to create an object.
This pattern involves a single class which is responsible to create an object while making sure that only
single object gets created. This class provides a way to access its only object which can be accessed directly
without need to instantiate the object of the class.
Implementation
We're going to create a SingleObject class. SingleObject class have its constructor as private and have a
static instance of itself.
SingleObject class provides a static method to get its static instance to outside world. SingletonPatternDemo,
our demo class will use SingleObject class to get a SingleObject object.

Step 1
Create a Singleton Class.
SingleObject.java
public class SingleObject {

//create an object of SingleObject

 private static SingleObject instance = new SingleObject();

//make the constructor private so that this class cannot be

//instantiated
private SingleObject(){}

//Get the only object available

public static SingleObject getInstance(){
return instance;
}

public void showMessage(){

System.out.println("Hello World!");
}
}
Step 2
Get the only object from the singleton class.
SingletonPatternDemo.java
public class SingletonPatternDemo {
public static void main(String[] args) {

//illegal construct
//Compile Time Error: The constructor SingleObject() is not visible
//SingleObject object = new SingleObject();

//Get the only object available

SingleObject object = SingleObject.getInstance();

//show the message

object.showMessage();
}
}
Step 3
Verify the output.
Hello World!

Factory Method Pattern

A Factory Pattern or Factory Method Pattern says that just define an interface or abstract class for
creating an object but let the subclasses decide which class to instantiate. In other words, subclasses are
responsible to create the instance of the class.

The Factory Method Pattern is also known as Virtual Constructor.

Advantage of Factory Design Pattern

o Factory Method Pattern allows the sub-classes to choose the type of objects to create.
o It promotes the loose-coupling by eliminating the need to bind application-specific classes into the
code. That means the code interacts solely with the resultant interface or abstract class, so that it will
work with any classes that implement that interface or that extends that abstract class.
Usage of Factory Design Pattern
o When a class doesn't know what sub-classes will be required to create
o When a class wants that its sub-classes specify the objects to be created.
o When the parent classes choose the creation of objects to its sub-classes.

UML for Factory Method Pattern

o We are going to create a Plan abstract class and concrete classes that extends the Plan abstract class.
A factory class GetPlanFactory is defined as a next step.
o GenerateBill class will use GetPlanFactory to get a Plan object. It will pass information
(DOMESTICPLAN / COMMERCIALPLAN / INSTITUTIONALPLAN) to GetPalnFactory to get
the type of object it needs.

Calculate Electricity Bill : A Real World Example of Factory Method

Step 1: Create a Plan abstract class.

1. import java.io.*;
2. abstract class Plan{
3. protected double rate;
4. abstract void getRate();
5.
6. public void calculateBill(int units){
7. System.out.println(units*rate);
8. }
 9. }//end of Plan class.

Step 2: Create the concrete classes that extends Plan abstract class.

1. class DomesticPlan extends Plan{

2. //@override
3. public void getRate(){
4. rate=3.50;
5. }
6. }//end of DomesticPlan class.
1. class CommercialPlan extends Plan{
2. //@override
3. public void getRate(){
4. rate=7.50;
5. }
6. /end of CommercialPlan class.
1. class InstitutionalPlan extends Plan{
2. //@override
3. public void getRate(){
4. rate=5.50;
5. }
6. /end of InstitutionalPlan class.

Step 3: Create a GetPlanFactory to generate object of concrete classes based on given information..

1. class GetPlanFactory{
2.
3. //use getPlan method to get object of type Plan
4. public Plan getPlan(String planType){
5. if(planType == null){
6. return null;
7. }
8. if(planType.equalsIgnoreCase("DOMESTICPLAN")) {
9. return new DomesticPlan();
10. }
11. else if(planType.equalsIgnoreCase("COMMERCIALPLAN")){
12. return new CommercialPlan();
13. }
14. else if(planType.equalsIgnoreCase("INSTITUTIONALPLAN")) {
15. return new InstitutionalPlan();
16. }
17. return null;
 18. }
19. }//end of GetPlanFactory class.

Step 4: Generate Bill by using the GetPlanFactory to get the object of concrete classes by passing an
information such as type of plan DOMESTICPLAN or COMMERCIALPLAN or INSTITUTIONALPLAN.

1. import java.io.*;
2. class GenerateBill{
3. public static void main(String args[])throws IOException{
4. GetPlanFactory planFactory = new GetPlanFactory();
5.
6. System.out.print("Enter the name of plan for which the bill will be generated: ");
7. BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
8.
9. String planName=br.readLine();
10. System.out.print("Enter the number of units for bill will be calculated: ");
11. int units=Integer.parseInt(br.readLine());
12.
13. Plan p = planFactory.getPlan(planName);
14. //call getRate() method and calculateBill()method of DomesticPaln.
15.
16. System.out.print("Bill amount for "+planName+" of "+units+" units is: ");
17. p.getRate();
18. p.calculateBill(units);
19. }
20. }//end of GenerateBill class.
Output

Design Patterns - Facade Pattern

Facade pattern hides the complexities of the system and provides an interface to the client using which the
client can access the system. This type of design pattern comes under structural pattern as this pattern adds
an interface to existing system to hide its complexities.
This pattern involves a single class which provides simplified methods required by client and delegates calls
to methods of existing system classes.
Implementation
We are going to create a Shape interface and concrete classes implementing the Shape interface. A facade
class ShapeMaker is defined as a next step.
ShapeMaker class uses the concrete classes to delegate user calls to these classes. FacadePatternDemo, our
demo class, will use ShapeMaker class to show the results.
Step 1
Create an interface.
Shape.java
public interface Shape {
void draw();
}
Step 2
Create concrete classes implementing the same interface.
Rectangle.java
public class Rectangle implements Shape {

@Override
public void draw() {
System.out.println("Rectangle::draw()");
}
}
Square.java
public class Square implements Shape {

@Override
public void draw() {
System.out.println("Square::draw()");
}
}
Circle.java
public class Circle implements Shape {

@Override
public void draw() {
System.out.println("Circle::draw()");
}
}
Step 3
Create a facade class.
ShapeMaker.java
public class ShapeMaker {
private Shape circle;
private Shape rectangle;
private Shape square;

public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
 public void drawCircle(){
circle.draw();
}
public void drawRectangle(){
rectangle.draw();
}
public void drawSquare(){
square.draw();
}
}
Step 4
Use the facade to draw various types of shapes.
FacadePatternDemo.java
public class FacadePatternDemo {
public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();

shapeMaker.drawCircle();
shapeMaker.drawRectangle();
shapeMaker.drawSquare();
}
}
Step 5
Verify the output.
Circle::draw()
Rectangle::draw()
Square::draw()

PUB-SUB DESIGN PATTERNS

https://www.enjoyalgorithms.com/blog/publisher-subscriber-pattern

UNIT V UML DIAGRAMS

State-Chart diagrams, Activity diagrams, Component Diagrams, Deployment
diagrams, Object diagrams. Advanced concepts in OOAD : Use case relationships,
Generalizations Domain Model refinements, Architecture, Packaging model elements.

UML State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which shows the order
of states underwent by an object within the system. It captures the software system's behavior. It models the
behavior of a class, a subsystem, a package, and a complete system.

It tends out to be an efficient way of modeling the interactions and collaborations in the external entities and
the system. It models event-based systems to handle the state of an object. It also defines several distinct
states of a component within the system. Each object/component has a specific state.

Following are the types of a state machine diagram that are given below:
 1. Behavioral state machine
The behavioral state machine diagram records the behavior of an object within the system. It depicts
an implementation of a particular entity. It models the behavior of the system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change in the state of
the protocol and parallel changes within the system. But it does not portray the implementation of a
particular component.

Why State Machine Diagram?

Since it records the dynamic view of a system, it portrays the behavior of a software application. During a
lifespan, an object underwent several states, such that the lifespan exist until the program is executing. Each
state depicts some useful information about the object.

It blueprints an interactive system that response back to either the internal events or the external ones. The
execution flow from one state to another is represented by a state machine diagram. It visualizes an object
state from its creation to its termination.

The main purpose is to depict each state of an individual object. It represents an interactive system and the
entities inside the system. It records the dynamic behavior of the system.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

a. Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled
circle.
b. Final state: It represents the final state (end) of a system. It is denoted by a filled circle present
within a circle.
 c. Decision box: It is of diamond shape that represents the decisions to be made on the basis of an
evaluated guard.
d. Transition: A change of control from one state to another due to the occurrence of some event is
termed as a transition. It is represented by an arrow labeled with an event due to which the change
has ensued.
e. State box: It depicts the conditions or circumstances of a particular object of a class at a specific
point of time. A rectangle with round corners is used to represent the state box.

Types of State

The UML consist of three states:

1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it does not contain more than one
initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state, but it can
be reused.

How to Draw a State Machine Diagram?

The state machine diagram is used to portray various states underwent by an object. The change in one state
to another is due to the occurrence of some event. All of the possible states of a particular component must
be identified before drawing a state machine diagram.

The primary focus of the state machine diagram is to depict the states of a system. These states are essential
while drawing a state transition diagram. The objects, states, and events due to which the state transition
occurs must be acknowledged before the implementation of a state machine diagram.

Following are the steps that are to be incorporated while drawing a state machine diagram:

1. A unique and understandable name should be assigned to the state transition that describes the
behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.

When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as the object-oriented systems. It
records the dynamic behavior of the system, which is used to differentiate between the dynamic and static
behavior of a system.

It portrays the changes underwent by an object from the start to the end. It basically envisions how
triggering an event can cause a change within the system.

State machine diagram is used for:

1. For modeling the object states of a system.

 2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.

Example of a State Machine Diagram

An example of a top-level state machine diagram showing Bank Automated Teller Machine (ATM) is given
below.

Initially, the ATM is turned off. After the power supply is turned on, the ATM starts performing the startup
action and enters into the Self Test state. If the test fails, the ATM will enter into the Out Of Service state,
or it will undergo a triggerless transition to the Idle state. This is the state where the customer waits for the
interaction.

Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM state changes
from Idle to Serving Customer, the entry action readCard is performed after entering into Serving
Customer state. Since the customer can cancel the transaction at any instant, so the transition from Serving
Customer state back to the Idle state could be triggered by cancel event.

Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.

Customer Authentication and Transaction are the composite states itself is displayed by a hidden
decomposition indication icon. After the transaction is finished, the Serving Customer encompasses a
triggerless transition back to the Idle state. On leaving the state, it undergoes the exit action ejectCard that
discharges the customer card.

State Machine vs. Flowchart

State Machine Flowchart

It portrays several states of a system. It demonstrates the execution flow of

a program.

It encompasses the concept of WAIT, i.e., wait for an event or an action. It does not constitute the concept of
WAIT.

It is for real-world modeling systems. It envisions the branching sequence

of a system.

It is a modeling diagram. It is a data flow diagram (DFD)

It is concerned with several states of a system. It focuses on control flow and path.

UML Activity Diagram

In UML, the activity diagram is used to demonstrate the flow of control within the system rather than the
implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis on the
condition of flow and the order in which it occurs. The flow can be sequential, branched, or concurrent, and
to deal with such kinds of flows, the activity diagram has come up with a fork, join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of actions or

operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

The categorization of behavior into one or more actions is termed as an activity. In other words, it can be
said that an activity is a network of nodes that are connected by edges. The edges depict the flow of
execution. It may contain action nodes, control nodes, or object nodes.

The control flow of activity is represented by control nodes and object nodes that illustrates the objects used
within an activity. The activities are initiated at the initial node and are terminated at the final node.
Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can be either vertical or
horizontal. It used to add modularity to the activity diagram. It is not necessary to incorporate swimlane in
the activity diagram. But it is used to add more transparency to the activity diagram.

Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one inward
edge and several outward edges. It is the same as that of various decision parameters. Whenever a data is
received at an inward edge, it gets copied and split crossways various outward edges. It split a single inward
flow into multiple parallel flows.

Join Nodes

Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the inward edges
as it synchronizes the flow of input across one single output (outward) edge.

Pins

It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and complicated
thing to manage the execution flow of activities. It is an object node that precisely represents one input to or
output from the action.
Notation of an Activity diagram

Activity diagram constitutes following notations:

Initial State: It depicts the initial stage or beginning of the set of actions.

Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one path.

Action Box: It represents the set of actions that are to be performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of nodes associated with edges. To model
the behavior of activities, they can be attached to any modeling element. It can model use cases, classes,
interfaces, components, and collaborations.

It mainly models processes and workflows. It envisions the dynamic behavior of the system as well as
constructs a runnable system that incorporates forward and reverse engineering. It does not include the
message part, which means message flow is not represented in an activity diagram.

It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict the flow between
several activities.

How to draw an Activity Diagram?

An activity diagram is a flowchart of activities, as it represents the workflow among various activities. They
are identical to the flowcharts, but they themself are not exactly the flowchart. In other words, it can be said
that an activity diagram is an enhancement of the flowchart, which encompasses several unique skills.

Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and forks, it supports
exception handling. A system must be explored as a whole before drawing an activity diagram to provide a
clearer view of the user. All of the activities are explored after they are properly analyzed for finding out the
constraints applied to the activities. Each and every activity, condition, and association must be recognized.

After gathering all the essential information, an abstract or a prototype is built, which is then transformed
into the actual diagram.

Following are the rules that are to be followed for drawing an activity diagram:
 1. A meaningful name should be given to each and every activity.
2. Identify all of the constraints.
3. Acknowledge the activity associations.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order processing is given below.

Here the input parameter is the Requested order, and once the order is accepted, all of the required
information is then filled, payment is also accepted, and then the order is shipped. It permits order shipment
before an invoice is sent or payment is completed.

When to use an Activity Diagram?

An activity diagram can be used to portray business processes and workflows. Also, it used for modeling
business as well as the software. An activity diagram is utilized for the followings:

1. To graphically model the workflow in an easier and understandable way.

2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed within the system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.

UML Component Diagram

A component diagram is used to break down a large object-oriented system into the smaller components, so
as to make them more manageable. It models the physical view of a system such as executables, files,
libraries, etc. that resides within the node.
It visualizes the relationships as well as the organization between the components present in the system. It
helps in forming an executable system. A component is a single unit of the system, which is replaceable and
executable. The implementation details of a component are hidden, and it necessitates an interface to
execute a function. It is like a black box whose behavior is explained by the provided and required
interfaces.

Notation of a Component Diagram

a) A component

b) A node

Purpose of a Component Diagram

Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the individual
components that are used to make the functionalities, but not the functionalities of the system. It visualizes
the physical components inside the system. The components can be a library, packages, files, etc.

The component diagram also describes the static view of a system, which includes the organization of
components at a particular instant. The collection of component diagrams represents a whole system.

The main purpose of the component diagram are enlisted below:

1. It envisions each component of a system.

2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.

Why use Component Diagram?

The component diagrams have remarkable importance. It is used to depict the functionality and behavior of
all the components present in the system, unlike other diagrams that are used to represent the architecture of
the system, working of a system, or simply the system itself.
In UML, the component diagram portrays the behavior and organization of components at any instant of
time. The system cannot be visualized by any individual component, but it can be by the collection of
components.

Following are some reasons for the requirement of the component diagram:

1. It portrays the components of a system at the runtime.

2. It is helpful in testing a system.
3. It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing the structure and
the organization of a system. It describes how individual components can together form a single system.
Following are some reasons, which tells when to use component diagram:

1. To divide a single system into multiple components according to the functionality.

2. To represent the component organization of the system.

How to Draw a Component Diagram?

The component diagram is helpful in representing the physical aspects of a system, which are files,
executables, libraries, etc. The main purpose of a component diagram is different from that of other
diagrams. It is utilized in the implementation phase of any application.

Once the system is designed employing different UML diagrams, and the artifacts are prepared, the
component diagram is used to get an idea of implementation. It plays an essential role in implementing
applications efficiently.

Following are some artifacts that are needed to be identified before drawing a component diagram:

1. What files are used inside the system?

2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?

Following are some points that are needed to be kept in mind after the artifacts are identified:

1. Using a meaningful name to ascertain the component for which the diagram is about to be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.

Example of a Component Diagram

A component diagram for an online shopping system is given below:

Where to use Component Diagrams?

The component diagram is a special purpose diagram, which is used to visualize the static implementation
view of a system. It represents the physical components of a system, or we can say it portrays the
organization of the components inside a system. The components, such as libraries, files, executables, etc.
are first needed to be organized before the implementation.

The component diagram can be used for the followings:

1. To model the components of the system.

2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.

UML Deployment Diagram

The deployment diagram visualizes the physical hardware on which the software will be deployed. It
portrays the static deployment view of a system. It involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software architecture created in design
to the physical system architecture, where the software will be executed as a node. Since it involves many
nodes, the relationship is shown by utilizing communication paths.

Purpose of Deployment Diagram

The main purpose of the deployment diagram is to represent how software is installed on the hardware
component. It depicts in what manner a software interacts with hardware to perform its execution.
Both the deployment diagram and the component diagram are closely interrelated to each other as they focus
on software and hardware components. The component diagram represents the components of a system,
whereas the deployment diagram describes how they are actually deployed on the hardware.

The deployment diagram does not focus on the logical components of the system, but it put its attention on
the hardware topology.

Following are the purposes of deployment diagram enlisted below:

1. To envision the hardware topology of the system.

2. To represent the hardware components on which the software components are installed.
3. To describe the processing of nodes at the runtime.

Symbol and notation of Deployment diagram

The deployment diagram consist of the following notations:

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

How to draw a Deployment Diagram?

The deployment diagram portrays the deployment view of the system. It helps in visualizing the topological
view of a system. It incorporates nodes, which are physical hardware. The nodes are used to execute the
artifacts. The instances of artifacts can be deployed on the instances of nodes.

Since it plays a critical role during the administrative process, it involves the following parameters:
 1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable

One of the essential elements of the deployment diagram is the nodes and artifacts. So it is necessary to
identify all of the nodes and the relationship between them. It becomes easier to develop a deployment
diagram if all of the nodes, artifacts, and their relationship is already known.

Example of a Deployment diagram

A deployment diagram for the Apple iTunes application is given below.

The iTunes setup can be downloaded from the iTunes website, and also it can be installed on the home
computer. Once the installation and the registration are done, iTunes application can easily interconnect with
the Apple iTunes store. Users can purchase and download music, video, TV serials, etc. and cache it in the
media library.

Devices like Apple iPod Touch and Apple iPhone can update its own media library from the computer with
iTunes with the help of USB or simply by downloading media directly from the Apple iTunes store using
wireless protocols, for example; Wi-Fi, 3G, or EDGE.

When to use a Deployment Diagram?

The deployment diagram is mostly employed by network engineers, system administrators, etc. with the
purpose of representing the deployment of software on the hardware system. It envisions the interaction of
the software with the hardware to accomplish the execution. The selected hardware must be of good quality
so that the software can work more efficiently at a faster rate by producing accurate results in no time.

The software applications are quite complex these days, as they are standalone, distributed, web-based, etc.
So, it is very necessary to design efficient software.

Deployment diagrams can be used for the followings:

1. To model the network and hardware topology of a system.

2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It represents
an instance of a class diagram. The objects help in portraying a static view of an object-oriented system at a
specific instant.

Both the object and class diagram are similar to some extent; the only difference is that the class diagram
provides an abstract view of a system. It helps in visualizing a particular functionality of a system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides an
abstract view which comprises of classes and their relationships, whereas the object diagram represents an
instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The main purpose is to
depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.

o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.
 Example of Object Diagram

How to draw an Object Diagram?

1. All the objects present in the system should be examined before start drawing the object diagram.
2. Before creating the object diagram, the relation between the objects must be acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.

Applications of Object diagrams

The following are the application areas where the object diagrams can be used.

1. To build a prototype of a system.

2. To model complex data structures.
3. To perceive the system from a practical perspective.
4. Reverse engineering.

Class vs. Object diagram

Serial No. Class Object Diagram
Diagram

1. It depicts the static view of a system. It portrays the real-time behavior of a system.

2. Dynamic changes are not included in the class Dynamic changes are captured in the object diagram.
diagram.

3. The data values and attributes of an instance are not It incorporates data values and attributes of an entity.
involved here.

4. The object behavior is manipulated in the class Objects are the instances of a class.
diagram.

Use Case Relationships

Active relationships are referred to as behavioral relationships and are used primarily in use case
diagrams. There are four basic types of behavioral relationships: communicates, includes, extends,
and generalizes. Notice that all these terms are action verbs. Table below illustrates the arrows and
lines used to diagram each of the four types of behavioral relationships. The four relationships are
described next.

Relationship Symbol Meaning

Communicates An actor is connected to a use case

using a line with no arrowheads.

Includes A use case contains a behavior that

is common to more than one other
use case. The arrow points to the
common use case.

Extends A different use case handles

exceptions from the basic use case.
The arrow points from the extended
to the basic use case.

Generalizes One UML "thing" is more general

than another "thing." The arrow
points to the general "thing."

COMMUNICATES. The behavioral relationship communicates is used to connect an actor to a use

case. Remember that the task of the use case is to give some sort of result that is beneficial to the actor
in the system. Therefore, it is important to document these relationships between actors and use cases.
In our first example, a Student communicates with Enroll in Course. Examples of some components of
a student enrollment example are shown in the use case diagrams in the figure below.

INCLUDES. The includes relationship (also called uses relationship) describes the situation in which a
use case contains behavior that is common to more than one use case. In other words, the common use
case is included in the other use cases. A dotted arrow that points to the common use case indicates
the includes relationship. An example would be a use case Pay Student Fees that is included in Enroll
in Course and Arrange Housing, because in both cases students must pay their fees. This may be used
by several use cases. The arrow points toward the common use case.

EXTENDS. The extends relationship describes the situation in which one use case possesses the
behavior that allows the new use case to handle a variation or exception from the basic use case. For
example, the extended use case Student Health Insurance extends the basic use case Pay Student Fees.
The arrow goes from the extended to the basic use case.
GENERALIZES. The generalizes relationship implies that one thing is more typical than the other
thing. This relationship may exist between two actors or two use cases. For example, a Part-Time
Student generalizes a Student. Similarly, some of the university employees are professors. The arrow
points to the general thing.

Examples
of use cases and behavioral relationships for student enrollment.

Package
A package is an organized group of elements. A package may contain structural
things like classes, components, and other packages in it.
Notation − Graphically, a package is represented by a tabbed folder. A package is
generally drawn with only its name. However it may have additional details about the
contents of the package. See the following figures.