1908008- OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT I
ANSWER KEY
PART-A
1. Define OOAD.
Object-oriented analysis, emphasis on finding and describing the objects—or concepts—in the
problem domain.
Object-oriented design, emphasis on defining software objects and how they collaborate to
fulfill the requirements.

2. What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a
solution.
For example, if a new online trading system is desired, how will it be used? What are its
functions?
"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of
the requirements) or object-oriented analysis (an investigation of the domain objects).
Design emphasizes a conceptual solution (in software and hardware) that fulfills the
requirements, rather than its implementation. For example, a description of a database
schema and software objects.
3. Distinguish between method and messages in object.
Messages
 Specify what behavior objects have to perform
 Details are left to the receiver
Methods
 Specify how an operation is to be performed
 Must have access to data
 Need detailed knowledge of data
 Can manipulate data directly

4. What is the main advantage of Object Oriented Development?

 Faster Development: OOD has long been touted as leading to faster development.
Many of the claims of potentially reduced development time are correct in principle,
if a bit overstated.
 Reuse of Previous work: This is the benefit cited most commonly in literature,
particularly in business periodicals. OOD produces software modules that can be
plugged into one another, which allows creation of new programs. However, such
reuse does not come easily. It takes planning and investment.
 Increased Quality: Increases in quality are largely a by-product of this program reuse.
If 90% of a new application consists of proven, existing components, then only the
remaining 10% of the code has to be tested from scratch. That observation implies an
order-of-magnitude reduction in defects.
 Modular Architecture: Object-oriented systems have a natural structure for modular
design: objects, subsystems, framework, and so on. Thus, OOD systems are easier to
modify. OOD systems can be altered in fundamental ways without ever breaking up
since changes are neatly encapsulated. However, nothing in OOD guarantees or
requires that the code produced will be modular. The same level of care in design and
implementation is required to produce a modular structure in OOD, as it is for any
form of software development.
  Client/Server Applications: By their very nature, client/server applications involve
transmission of messages back and forth over a network, and the object-message
paradigm of OOD meshes well with the physical and conceptual architecture of
client/server applications.
 Better Mapping to the Problem Domain: This is a clear winner for OOD, particularly
when the project maps to the real world. Whether objects represent customers,
machinery, banks, sensors or pieces of paper, they can provide a clean, self-contained
implication which fits naturally into human thought processes.

5. Point out what test can help to find useful use cases?
Use cases are defined to satisfy the goals of the primary actors. Hence, the basic
procedure is:
1. Choose the system boundary. Is it just a software application, the hardware and
application
as a unit, that plus a person using it, or an entire organization?
2. Identify the primary actorsthose that have goals fulfilled through using services of the
system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually,
user- goal level use cases will be one-to-one with user goals, but there is at least one
exception, as will be examined.
6. Give the different formats of use cases.
Use cases can be written in different formats and levels of formality:
Brief Terse one-paragraph summary, usually of the main success scenario. The prior
Process Sale example was brief.
 When? During early requirements analysis, to get a quick sense of subject and scope.
May take only a few minutes to create.
Casual Informal paragraph format. Multiple paragraphs that cover various scenarios. The
prior Handle Returns example was casual.
When? As above.
Fully Dressed All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.

7. What is an object? Give an example

Objects are self-contained units of code that have both data and behavior. They can
interact with each other to perform tasks.
Think of a TV remote control. It has buttons like power, volume up, volume down, and
channel change.
  Buttons are like the functions or actions in a program, such as play, pause,
or stop.
 What the buttons do is like the behavior of objects or classes in OOP.
For example, when you press the volume up button, the volume goes up,,
8. What is UML?
The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
9. Classify the kinds of actors in use case.
Three Kinds of Actors
1. Primary Actor (to find user goals)- This kind of Actor satisfies the user goals through
SUD (System Under Discussion) services. Eg.Librarian
2. Supporting Actor (to provide clear picture of external interfaces and protocols)- These
actors provide a service information to SUD. Eg. Library assistant or computer system
providing library details (Book or Transaction Details)
3. Offstage Actor (to ensure all the goals are identified and satisfied).

10. Define Unified Process (UP).

The Unified Process has emerged as a popular iterative software development process for
building object oriented systems. The Unified Process (UP) combines commonly accepted
best practices, such as an iterative lifecycle and risk-driven development, into a cohesive
and well-documented description. The best-known and extensively documented refinement
of the Unified Process is the Rational Unified Process (RUP).
There are 4 phases in Unified Process,
1. Inception
2. Elaboration
3. Construction
4. Transition
11. Illustrate the concepts of Generalization Relationship.
In the generalization process, the common characteristics of classes are combined to form
a class in a higher level of hierarchy, i.e., subclasses are combined to form a generalized
super-class. It represents an “is – a – kind – of” relationship. For example, “car is a kind
of land vehicle”, or “ship is a kind of water vehicle”.
 -----------------------------------------------
Additional info:
Specialization
Specialization is the reverse process of generalization. Here, the distinguishing features of
groups of objects are used to form specialized classes from existing classes. It can be said that
the subclasses are the specialized versions of the super-class.
The above figure shows an example of generalization and specialization.

12. Compare Include and Extend use case relationships.

Include relationships should be used for common and mandatory behaviors that are relevant
to the main goal of your use cases. Extend relationships should be used for optional and
conditional behaviors that are not essential to the main goal of your use cases. Additionally,
it’s essential to use consistent and meaningful names for your use cases and relationships
that reflect the user's perspective and intention. Stereotypes and constraints can also be used
to clarify the conditions and assumptions of your include and extend relationships.
As the name implies it extends the base use case and adds more
functionality to the system. Here are a few things to consider when using
the <<extend>> relationship.

 The extending use case is dependent on the extended (base)

use case. In the below diagram the “Calculate Bonus” use case
doesn’t make much sense without the “Deposit Funds” use case.
 The extending use case is usually optional and can be triggered
conditionally. In the diagram, you can see that the extending use
case is triggered only for deposits over 10,000 or when the age is
over 55.
 The extended (base) use case must be meaningful on its own.
This means it should be independent and must not rely on the
behavior of the extending use case.

Lets expand our current example to show the <<extend>> relationship.

Although extending use case is optional most of the time it is not a must.
An extending use case can have non-optional behavior as well. This mostly
happens when your modeling complex behaviors.

For example, in an accounting system, one use case might be “Add

Account Ledger Entry”. This might have extending use cases “Add Tax
Ledger Entry” and “Add Payment Ledger Entry”. These are not optional but
depend on the account ledger entry. Also, they have their own specific
behavior to be modeled as a separate use case.

Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part
of the including (base) use case. The main reason for this is to reuse
common actions across multiple use cases. In some situations, this is done
to simplify complex behaviors. Few things to consider when using the
<<include>> relationship.

 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.

Lest expand our banking system use case diagram to show include
relationships as well.
 Includes is usually used to model common behavior

13. Describe POS system and list the components of POS system.
POS system allows your business to accept payments from customers and keep track of
sales. It sounds simple enough, but the setup can work in different ways, depending on
whether you sell online, have a physical storefront, or both. A point-of-sale system used
to refer to the cash register at a store.
Components of POS system
POS computer. ...
POS keyboard & mouse. ...
Barcode scanner. ...
EMV-compliant external credit card reader. ...
Cash drawer. ...
Receipt printer. ...
One-box POS system.
14. Give the primary goals in the design of UML
The goal of UML is to provide a standard notation that can be used by all object-oriented
methods and to select and integrate the best elements of precursor notations. UML has
been designed for a broad range of applications.
15. Illustrate the relationship used in Use case.
The Relationship Types of Use Cases
Relationship Type Description

Association Indicates a general association between use cases.

Include Specifies that one use case includes another.

Extend Represents optional or conditional behavior.

Generalization Indicates inheritance between use cases.

<<<<<<<<< draw diagram in part A Q no 12>>>>>>>>>>>>

16. What are the three ways and perspectives to Apply UML?
UML may be used for three perspectives and types of models
1. Conceptual perspective the diagrams are interpreted as describing things in a situation
of the real world or domain of interest.
2. Specification (software) perspective the diagrams (using the same notation as in the
conceptual perspective) describe software abstractions or components with
specifications and interfaces, but no commitment to a particular implementation (for
example, not specifically a class in C# or Java).
3. Implementation (software) perspective the diagrams describe software implementations
in a particular technology (such as Java).

17. Generalize the concepts of use case modeling.

Use cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.

Use cases are text stories of some actor using a system to meet goals.

Here is an example brief format use case:

Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses
the POS system to record each purchased item. The system presents a running total and
line-item details. The customer enters payment information, which the system validates and
records. The system updates inventory. The customer receives a receipt from the system
and then leaves with the items.

First, some informal definitions: an actor is something with behavior, such as

a person (identified by role), computer system, or organization; for example,
a cashier.
A scenario is a specific sequence of actions and interactions between actors
and the system; it is also called a use case instance. It is one particular story
of using a system, or one path through the use case; for example, the scenario
of successfully purchasing items with cash, or the scenario of failing to
purchase items because of a credit payment denial.
 Informally then, a use case is a collection of related success and failure
scenarios that describe an actor using a system to support a goal. For example,
here is a casual format use case with alternate scenarios.

18. When to use Use cases? Evaluate it.

Use-case diagrams are helpful in the following situations: Before starting a project, you
can create use-case diagrams to model a business so that all participants in the project
share an understanding of the workers, customers, and activities of the business.

Use cases are text documents, not diagrams, and use-case modeling is primarily an act of
writing text, not drawing diagrams.

Use cases are text stories of some actor using a system to meet goals.

Here is an example brief format use case:

Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses
the POS system to record each purchased item. The system presents a running total and
line-item details. The customer enters payment information, which the system validates and
records. The system updates inventory. The customer receives a receipt from the system
and then leaves with the items.

19. Generalize your views about inception in Use case.

The purpose of the inception phase is not to define all the requirements, or generate a
believable estimate or project plan.

Inception is a short initial step in which the following kinds of questions are explored:
What is the vision and business case for this project?
Feasible?
Buy and/or build?
Rough unreliable range of cost: Is it $10K100K or in the millions?
Should we proceed or stop
Inception in one sentence:
Envision the product scope, vision, and business case.
The main problem solved in one sentence:
Do the stakeholders have basic agreement on the vision of the project, and is it worth
investing in serious investigation?
20. Evaluate and Name the UML diagrams used for the following:
a) Modeling Requirements
A requirement can be shown directly on block definition diagrams, package diagrams,
and use case diagrams, along with its relationships to other model elements on the
diagram.
Structure Diagrams. Class Diagram. Component Diagram. Deployment Diagram.
Object Diagram. Package Diagram. Profile Diagram. Composite Structure Diagram.
b) Modeling Workflows
The principle diagram for workflow modeling is the Activity Diagram. While the basic
notation looks similar to the traditional flow chart, it does contain many significant
differences, as well as numerous enhancements that make the Activity Diagram
preferable in practice.
other diagrams given below can also be used for modeling workflows.
Behavioral Diagrams. Use Case Diagram. Activity Diagram. State Machine Diagram.
Sequence Diagram. Communication Diagram. Interaction Overview Diagram.

21. What are the 4 phases in UP?

A UP project organizes the work and iterations across four major phases:
1. Inception: approximate vision, business case, scope, vague estimates.
2. Elaboration: refined vision, iterative implementation of the core architecture,
resolution of high risks, identification of most requirements and scope, more realistic
estimates.
3. Construction: iterative implementation of the remaining lower risk and easier
elements, and preparation for deployment.
4. Transition: beta tests, deployment.
22. Classify the UML Diagrams.
<<<<Draw Table given in class notes>>>>>>>>

23. Evaluate and Name the UML diagrams used for the following:
a) Modeling behavior of an object.
Behavioral Diagrams. Use Case Diagram. Activity Diagram. State Machine
Diagram. Sequence Diagram. Communication Diagram. Interaction Overview Diagram.
<<<<Draw diagram given in class notes>>>>>>>>

b) Interaction between groups of objects.

 Sequence Diagram
 Collaboration Diagram
<<<<Draw diagram given in class notes>>>>>>>>
24. List the relationships used in class diagram?
There are six main types of relationships between classes: inheritance , realization /
implementation , composition , aggregation , association, and dependency . The arrows for the
six relationships are as follows:

Then we come to understand the specific content of the class relationship.

 PART B

1 Discuss about UML.(13)

• The UML stands for Unified modeling language, is a standardized general-purpose
visual modeling language in the field of Software Engineering. It is used for specifying,
visualizing, constructing, and documenting the primary artifacts of the software system.
• The Unified Modeling Language (UML) was created to forge a common,
semantically and syntactically rich visual modeling language for the architecture, design,
and implementation of complex software systems both structurally and behaviorally.
UML has applications beyond software development, such as process flow in
manufacturing.
• It is analogous to the blueprints used in other fields, and consists of different types of
diagrams. In the aggregate, UML diagrams describe the boundary, structure, and the
behavior of the system and the objects within it.
• UML is not a programming language but there are tools that can be used to generate
code in various languages using UML diagrams. UML has a direct relation with object-
oriented analysis and design

2 Briefly explain about the different phases of Unified Process with a neat
diagram.(13)
A UP project organizes the work and iterations across four major phases:
1. Inception: approximate vision, business case, scope, vague estimates.
2. Elaboration: refined vision, iterative implementation of the core architecture,
resolution of high risks, identification of most requirements and scope, more realistic
estimates.
3. Construction: iterative implementation of the remaining lower risk and easier
elements, and preparation for deployment.
4. Transition: beta tests, deployment
3 Explain with an example, how UseCase Modeling is used to describe the
functional requirements. Identify the actors, scenario and UseCase for the
example.(13)

Use cases describe the functional requirements of a system from the end user's
perspective, creating a goal-focused sequence of events that is easy for users and
developers to follow. A complete use case will include one main or basic flow and
various alternate flows. The alternate flow -- also known as an extending use case --
describes normal variations to the basic flow as well as unusual situations.

A use case should:

Organize functional requirements.

Model the goals of system/actor interactions.

Record paths -- called scenarios-- from trigger events to goals.

Describe one main flow of events and various alternate flows.

Be multilevel, so that one use case can use the functionality of another one.
4 (i) Discuss the basic activities in OOA and explain how UseCase Modeling is
useful in analysis.(8)
(ii) Examinethe guidelines for writing and finding Use Cases.(5)
<<<<<<<<<<Refer Answer for Q.No. 10 (i) >>>>>>>>>>>>>>>
5 Write a problem statement for Library Management System. Perform the
Object Oriented System Development and give the Use Case model for the same(use
include,extend and generalization) and design the UML Use Case diagram for the
same.(13)

6 Prepare& analyze a suitable example showing the various relationships used in

Use Case and also give a short note on each relationship.(13)

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.

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

use case. In our first example, a Student communicates with Enroll in Course.

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

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

7 List the various UML diagram and explain about the UML diagrams in detail with
neat diagrams.(13)
8 Describe the following
(i) UP disciplines(5)
The UP describes work activities, such as writing a use case, within disciplines (originally
called workflows).Informally, a discipline is a set of activities (and related artifacts) in one subject
area, such as the activities within requirements analysis. In the UP, an artifact is the general term
for any work product: code, Web graphics, database schema, text documents, diagrams, models,
and so on.

(ii) OOA and OOD (4)

Object-Oriented Analysis (OOA) is the first technical activity performed as part of object-
oriented software engineering. OOA introduces new concepts to investigate a problem. It
is based on a set of basic principles, which are as follows-
1. The information domain is modeled.
2. Behavior is represented.
3. The function is described.
4. Data, functional, and behavioral models are divided to uncover greater detail.
5. Early models represent the essence of the problem, while later ones provide
implementation details.
The above notes principles form the foundation for the OOA approach.
 Object-Oriented Design (OOD): An analysis model created using object-oriented analysis
is transformed by object-oriented design into a design model that works as a plan for
software creation. OOD results in a design having several different levels of modularity
i.e., The major system components are partitioned into subsystems (a system-level
“modular”), and data manipulation operations are encapsulated into objects (a modular
form that is the building block of an OO system.). In addition, OOD must specify some
data organization of attributes and a procedural description of each operation. Shows a
design pyramid for object-oriented systems. It is having the following four layers.

(iii)Abstract and Base Use Case(4)

There is a distinction between concrete and abstract use cases. A concrete use case is initiated by
an actor and constitutes a complete flow of events. "Complete" means that an instance of the use
case performs the entire operation called for by the actor.

An abstract use case is never instantiated in itself. Abstract use cases are included, extend or
generalize other use cases. When a concrete use case is initiated, an instance of the use case is
created. This instance also exhibits the behavior specified by its associated abstract use cases.
Thus, no separate instances are created from abstract use cases.

The distinction between the two is important, because it is concrete use cases the actors will "see"
and initiate in the system.

You indicate that a use case is abstract by writing its name in italics.

In the example below, the abstract use case Create Task is included in the use case Register Order.
When Register Order is initiated, an instance of Register Order is created that, apart from
following Register Order's flow of events, also follows the flow of events described in the included
use case, Create Task. Create Task is never performed by itself, always as a part of Register Order
(or any other use cases in which it is included). Create Task is therefore an abstract use case.

A base use case may have multiple inclusions. One inclusion use case may be included in several
base use cases. This does not indicate any relationship between the base use cases. You may even
have multiple include-relationships between the same inclusion use case and base use case,
provided the inclusion is inserted at different locations of the base use case. The include-
relationship defines what the location is. All additions may be nested, which means that an
inclusion use case may serve as the base use case for another inclusion.

Since the inclusion use case is abstract, it does not need to have an actor associated with it. A
communication-association to an actor is only needed if the behavior in the inclusion explicitly
involves interaction with an actor.

9 What is a POS system? Summarize about Inception Phase.(13)

A POS system is a computerized application used (in part) to record sales and handle
payments; it is typically used in a retail store. It includes hardware components such as a
computer and bar code scanner, and software to run the system. It interfaces to various service
applications, such as a third-party tax calculator and inventory control. These systems must
be relatively faulttolerant; that is, even if remote services are temporarily unavailable (such
as the inventory system), they must still be capable of capturing sales and handling at least
cash payments (so that the business is not crippled).
A POS system increasingly must support multiple and varied client-side terminals and
interfaces.

These include a thin-client Web browser terminal, a regular personal computer with
something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and
so forth.
Furthermore, we are creating a commercial POS system that we will sell to different clients
with disparate needs in terms of business rule processing. Each client will desire a unique set
of logic to execute at certain predictable points in scenarios of using the system, such as when
a new sale is initiated or when a new line item is added. Therefore, we will need a mechanism
to provide this flexibility and customization.
Using an iterative development strategy, we are going to proceed through requirements,
objectoriented analysis, design, and implementation.
Inception
Inception is the initial short step to establish a common vision and basic scope for the project.
It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional
requirement, creation of a business case, and preparation of the development environment so
that programming can start in the following elaboration phase.

Most projects require a short initial step in which the following kinds of questions are
explored:
 What is the vision and business case for this project?
 Feasible?
 Buy and/or build?
 Rough unreliable range of cost: Is it $10K100K or in the millions?
 Should we proceed or stop?
Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires doing
some requirements exploration. However, the purpose of the inception phase is not to
define all the requirements, or generate a believable estimate or project plan.
Definition
This is a critical point, and repeatedly misunderstood on UP projects when people
superimpose old "waterfall" thinking. The UP is not the waterfall, and the first phase,
inception, is not the time do all requirements or create believable estimates or plans.
That happens during elaboration.
At the risk of over-simplification, the idea is to do just enough investigation to form a rational,
justifiable opinion of the overall purpose and feasibility of the potential new system, and
decide if it is worthwhile to invest in deeper exploration (the purpose of the elaboration
phase).
Most requirements analysis occurs during the elaboration phase, in parallel with early
production-quality programming and testing.
Thus, the inception phase should be relatively short for most projects, such as one or a few
weeks long. Indeed, on many projects, if it is more than a week long, then the point of
inception has been missed: It is to decide if the project is worth a serious investigation (during
elaboration), not to do that investigation.
Inception in one sentence:
Envision the product scope, vision, and business case.
The main problem solved in one sentence:
Do the stakeholders have basic agreement on the vision of the project, and is it worth
investing in serious investigation?

10 (i) Illustrate the steps and explain how to find Use cases with an example.(8)
Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure
is:
 1. Choose the system boundary. Is it just a software application, the hardware and application
as a unit, that plus a person using it, or an entire organization?
2. Identify the primary actorsthose that have goals fulfilled through using services of the
system.
3. Identify the goals for each primary actor.
4. Define use cases that satisfy user goals; name them according to their goal. Usually,
usergoal level use cases will be one-to-one with user goals, but there is at least one exception,
as will be examined.
Of course, in iterative and evolutionary development, not all goals or use cases will be
fully or
correctly identified near the start. It's an evolving discovery.
Step 1: Choose the System Boundary
For this case study, the POS system itself is the system under design; everything outside of
it is outside the system boundary, including the cashier, payment authorization service, and
so on.
If the definition of the boundary of the system under design is not clear, it can be clarified by
further definition of what is outsidethe external primary and supporting actors.
Once the external actors are identified, the boundary becomes clearer. For example, is the
complete responsibility for payment authorization within the system boundary? No, there is
an external payment authorization service actor.
Steps 2 and 3: Find Primary Actors and Goals
It is artificial to strictly linearize the identification of primary actors before user goals; in a
requirements workshop, people brainstorm and generate a mixture of both. Sometimes,
goals reveal the actors, or vice versa.
Guideline: Brainstorm the primary actors first, as this sets up the framework for further
investigation.
Are There Questions to Help Find Actors and Goals?
In addition to obvious primary actors and goals, the following questions help identify others
that may be missed:
Who starts and stops the system? Who does system administration?
Who does user and security management? Is "time" an actor because the system does
something in response to a time event?
 Is there a monitoring process that restarts the system if it fails?
 Who evaluates system activity or performance?
 How are software updates handled? Push or pull update?
 Who evaluates logs? Are they remotely retrieved?
 In addition to human primary actors, are there any external software or robotic
systems that call upon services of the system?
 Who gets notified when there are errors or failures?

How to Organize the Actors and Goals?

There are at least two approaches:
1. As you discover the results, draw them in a use case diagram, naming the goals as use
cases.
2. Write an actor-goal list first, review and refine it, and then draw the use case diagram.
If you create an actor-goal list, then in terms of UP artifacts it may be a section in the
Vision artifact.
For example:
The Sales Activity System is a remote application that will frequently request sales data
from each POS node in the network.
Why Ask About Actor Goals Rather Than Use Cases?
Actors have goals and use applications to help satisfy them. The viewpoint of use case
modeling is to find these actors and their goals, and create solutions that produce a result of
value. This is slight shift in emphasis for the use case modeler. Rather than asking "What are
the tasks?", one starts by asking: "Who uses the system and what are their goals?" In fact, the
name of a use case for a user goal should reflect its name, to emphasize this viewpointGoal:
capture or process a sale; use case: Process Sale.
Thus, here is a key idea regarding investigating requirements and use cases:
Imagine we are together in a requirements workshop. We could ask either:
 "What do you do?" (roughly a task-oriented question) or,
 "What are your goals whose results have measurable value?"
Prefer the second question.
Answers to the first question are more likely to reflect current solutions and procedures, and
the complications associated with them.
Answers to the second question, especially combined with an investigation to move higher
up the goal hierarchy ("what is the root goal?") open up the vision for new and improved
solutions, focus on adding business value, and get to the heart of what the stakeholders
want from the system.
Is the Cashier or Customer the Primary Actor?
Why is the cashier, and not the customer, a primary actor in the use case Process Sale?
The answer depends on the system boundary of the system under design, and who we are
primarily designing the system for, as illustrated in Figure 6.2. If the enterprise or checkout
service is viewed as an aggregate system, the customer is a primary actor, with the goal of
getting goods or services and leaving. However, from the viewpoint of just the POS system
(which is the choice of system boundary for this case study), the system services the goal of
a trained cashier (and the store) to process the customer's sale. This assumes a traditional
checkout environment with a cashier, although there are an increasing number of self-
checkout POS systems in operation for direct use by customers.
The customer is an actor, but in the context of the NextGen POS, not a primary actor;
rather, the cashier is the primary actor because the system is being designed to primarily
serve the trained cashier's "power user" goals (to quickly process a sale, look up prices,
etc.). The system does not have a UI and functionality that could equally be used by the
customer or cashier. Rather, it is optimized to meet the needs and training of a cashier. A
customer in front of the POS terminal wouldn't know how to use it effectively. In other
words, it was designed for the cashier, not the customer, and so the cashier is not just a
proxy for the customer.
On the other hand, consider a ticket-buying website that is identical for a customer to use
directly or a phone agent to use, when a customer calls in. In this case, the agent is simply a
proxy for the customerthe system is not designed to especially meet the unique goals of the
agent. Then, showing the customer rather than the phone agent as the primary actor is
correct.
Other Ways to Find Actors and Goals? Event Analysis
Another approach to aid in finding actors, goals, and use cases is to identify external events.
What are they, where from, and why? Often, a group of events belong to the same use case.
For example:

Step 4: Define Use Cases

In general, define one use case for each user goal. Name the use case similar to the user
goal for example, Goal: process a sale; Use Case: Process Sale.
Start the name of use cases with a verb.
A common exception to one use case per goal is to collapse CRUD (create, retrieve, update,
delete) separate goals into one CRUD use case, idiomatically called Manage <X>. For
example, the goals "edit user," "delete user," and so forth are all satisfied by the Manage
Users use case.

(ii) Rank the 3 kinds of actors and explain the 3 commonUse Case formats.(5)
Three Kinds of Actors
1. Primary Actor (to find user goals)- This kind of Actor satisfies the user goals through
SUD (System Under Discussion) services. Eg.Librarian
2. Supporting Actor (to provide clear picture of external interfaces and protocols)- These
actors provide a service information to SUD. Eg. Library assistant or computer system
providing library details (Book or Transaction Details)
3. Offstage Actor (to ensure all the goals are identified and satisfied).

Use cases can be written in different formats and levels of formality:

Brief Terse one-paragraph summary, usually of the main success scenario. The prior
Process Sale example was brief.
When? During early requirements analysis, to get a quick sense of subject and scope.
May take only a few minutes to create.
Casual Informal paragraph format. Multiple paragraphs that cover various scenarios. The
prior Handle Returns example was casual.
When? As above.
Fully Dressed All steps and variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.

11 (i) Recall the various sections in the Use Case template with example. (8)
Scope The scope bounds the system (or systems) under design. Typically, a use case
describes use of one software (or hardware plus software) system; in this case it is known as
a system use case. At a broader scope, use cases can also describe how a business is used by
its customers and partners. Such an enterprise-level process description is called a business
use case and is a good example of the wide applicability of use cases, but they aren't covered
in this introductory book.

Level In Cockburn's system, use cases are classified as at the user-goal level or the
subfunction level, among others. A user-goal level use case is the common kind that describe
the scenarios to fulfill the goals of a primary actor to get work done; it roughly corresponds
to an elementary business process (EBP) in business process engineering. A subfunction-
level use case describes substeps required to support a user goal, and is usually created to
factor out duplicate substeps shared by several regular use cases (to avoid duplicating
common text); an example is the subfunction use case Pay by Credit, which could be shared
by many regular use cases.

Primary Actor
The principal actor that calls upon system services to fulfill a goal.
Stakeholders and Interests ListImportant!
This list is more important and practical than may appear at first glance. It suggests and
bounds
what the system must do. To quote:
The [system] operates a contract between stakeholders, with the use cases detailing the
behavioral parts of that contract…The use case, as the contract for behavior, captures all and
only the behaviors related to satisfying the stakeholders' interests [Cockburn01].
This answers the question: What should be in the use case? The answer is: That which
satisfies all the stakeholders' interests. In addition, by starting with the stakeholders and their
interests before writing the remainder of the use case, we have a method to remind us what
the more detailed responsibilities of the system should be. For example, would I have
identified a responsibility for salesperson commission handling if I had not first listed the
salesperson
stakeholder and their interests? Hopefully eventually, but perhaps I would have missed it
during the first analysis session. The stakeholder interest viewpoint provides a thorough and
methodical procedure for discovering and recording all the required behaviors.
Stakeholders and Interests:
- Cashier: Wants accurate, fast entry and no payment errors, as cash drawer shortages are
deducted from his/her salary.
- Salesperson: Wants sales commissions updated.
-…
Preconditions and Success Guarantees (Postconditions)
First, don't bother with a precondition or success guarantee unless you are stating something
non-obvious and noteworthy, to help the reader gain insight. Don't add useless noise to
requirements documents.
Preconditions state what must always be true before a scenario is begun in the use case.
Preconditions are not tested within the use case; rather, they are conditions that are assumed
to be true. Typically, a precondition implies a scenario of another use case, such as logging
in, that has successfully completed. Note that there are conditions that must be true, but are
not worth writing, such as "the system has power." Preconditions communicate noteworthy
assumptions that the writer thinks readers should be alerted to.
Success guarantees (or postconditions) state what must be true on successful completion of
the use caseeither the main success scenario or some alternate path. The guarantee should
meet the needs of all stakeholders.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting
and Inventory are updated. Commissions recorded. Receipt is generated.
Main Success Scenario and Steps (or Basic Flow)
This has also been called the "happy path" scenario, or the more prosaic "Basic Flow" or
"Typical Flow." It describes a typical success path that satisfies the interests of the
stakeholders. Note that it often does not include any conditions or branching. Although not
wrong or illegal, it is arguably more comprehensible and extendible to be very consistent and
defer all conditional handling to the Extensions section.
Guideline
Defer all conditional and branching statements to the Extensions section.

The scenario records the steps, of which there are three kinds:
1. An interaction between actors.
Note that the system under discussion itself should be considered an actor when it plays an
actor role collaborating with other systems.
2. A validation (usually by the system).
3. A state change by the system (for example, recording or modifying something).
Step one of a use case does not always fall into this classification, but indicates the trigger
event
that starts the scenario.
It is a common idiom to always capitalize the actors' names for ease of identification.
Observe
also the idiom that is used to indicate repetition.
Main Success Scenario:
1. Customer arrives at a POS checkout with items to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. …
Cashier repeats steps 3-4 until indicates done.
5.
…
Extensions (or Alternate Flows)
Extensions are important and normally comprise the majority of the text. They indicate all
the other scenarios or branches, both success and failure. Observe in the fully dressed
example that the Extensions section was considerably longer and more complex than the
Main Success Scenario section; this is common.
In thorough use case writing, the combination of the happy path and extension scenarios
should satisfy "nearly" all the interests of the stakeholders. This point is qualified, because
some interests may best be captured as non-functional requirements expressed in the
Supplementary
Specification rather than the use cases. For example, the customer's interest for a visible
display of descriptions and prices is a usability requirement.
Extension scenarios are branches from the main success scenario, and so can be notated with
respect to its steps 1…N. For example, at Step 3 of the main success scenario there may be
an invalid item identifier, either because it was incorrectly entered or unknown to the system.
An extension is labeled "3a"; it first identifies the condition and then the response. Alternate
extensions at Step 3 are labeled "3b" and so forth.
Extensions:
3a. Invalid identifier:
1. System signals error and rejects entry.
3b. There are multiple of same item category and tracking unique item identity not important
(e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity. 1.
An extension has two parts: the condition and the handling.
Guideline: When possible, write the condition as something that can be detected by the
system or an actor. To contrast:
5a. System detects failure to communicate with external tax calculation system service:
5a. External tax calculation system not working:
 The former style is preferred because this is something the system can detect; the latter is an
inference.
Extension handling can be summarized in one step, or include a sequence, as in this example,
which also illustrates notation to indicate that a condition can arise within a range of steps:
3-6a: Customer asks Cashier to remove an item from the purchase:
1. Cashier enters the item identifier for removal from the sale.
 System displays updated running total.
At the end of extension handling, by default the scenario merges back with the main success
scenario, unless the extension indicates otherwise (such as by halting the system).
Sometimes, a particular extension point is quite complex, as in the "paying by credit"
extension.
This can be a motivation to express the extension as a separate use case.
This extension example also demonstrates the notation to express failures within extensions.
7b. Paying by credit:
1. Customer enters their credit account information.
System sends payment authorization request to an external Payment Authorization
Service System, and requests payment approval.
2a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
Cashier asks Customer for alternate payment.
If it is desirable to describe an extension condition as possible during any (or at least most)
steps, the labels *a, *b, …, can be used.
*a. At any time, System crashes:
In order to support recovery and correct accounting, ensure all transaction sensitive state and
events can be recovered at any step in the scenario.
1. Cashier restarts the System, logs in, and requests recovery of prior state.
System reconstructs prior state

(ii) List the guidelines to be followed when writing Use Case. (5)
Guideline: Write Terse Use Cases
Do you like to read lots of requirements? I didn't think so. So, write terse use cases. Delete
"noise" words. Even small changes add up, such as "System authenticates…" rather than
"The System authenticates…"

Guideline: Write Black-Box Use Cases

Black-box use cases are the most common and recommended kind; they do not describe the
internal workings of the system, its components, or design. Rather, the system is described
as having responsibilities, which is a common unifying metaphorical theme in object-
oriented thinkingsoftware elements have responsibilities and collaborate with other elements
that have responsibilities.
By defining system responsibilities with black-box use cases, one can specify what the
system must do (the behavior or functional requirements) without deciding how it will do it
(the design).
Indeed, the definition of "analysis" versus "design" is sometimes summarized as "what"
versus "how." This is an important theme in good software development: During
requirements analysis avoid making "how" decisions, and specify the external behavior for
the system, as a black box.
Later, during design, create a solution that meets the specification.
 Black-box style Not
The system records the sale. The system writes the sale to a database.
…or (even worse):
The system generates a SQL INSERT
statement for the sale…

12 Explain the benefits and concepts of Use Case and Use Case model and evaluate
the ATM system by relating Use Cases.(13)
A use case is a concept used in software development, product design, and other fields to
describe how a system can be used to achieve specific goals or tasks. It outlines the
interactions between users or actors and the system to achieve a specific outcome.

In a traditional Software Requirements Specification (SRS), features are presented without

context. For example:

The system shall log credit payments to the accounts receivable system.

The lack of context makes room for ambiguity. When does this event happen? Is the order
relative to other events significant? Who triggers the event? What happens when the accounts
receivable system is unavailable?

In addition, a traditional SRS tends to devolve into a numbered list of detail that drones on
page after page - very difficult for the system's stakeholders to absorb. Use cases break
requirements down into shorter scenarios that readers can more easily understand.

Benefits of use case modeling

Use cases focus on the users of the system, not the system itself, thus the real system needs
are brought to light early on. Since a use case consists mainly of narrative text, it is easily
understandable by all stakeholders, including customers, users and executives, not just
developers and testers. By including all the stakeholders during the early planning stages of
a project, you bring in people who best understand the problems at hand, promote a sense of
buy-in from end users, and eliminate surprises when the system is deployed.

Each use case describes one way the system is used, but one of the big benefits of use case
modeling is that it also describes all of the things that might go wrong. Identifying exceptions
to a successful scenario early in the project saves a lot of time by finding subtle requirements.

Finally, once a use case model has been developed, it can be used to drive many other aspects
of software development, including project planning (cost, complexity and timing estimates),
object models, test case definitions, and user documentation.
Use Case Diagram for Bank ATM System

Automated Teller Machine (ATM) also known as ABM (Automated Banking Machine) is a banking
system. This banking system allows customers or users to have access to financial transactions.
These transactions can be done in public space without any need for a clerk, cashier, or bank teller.
Working and description of the ATM can be explained with the help of the Use Case Diagram.

We will understand about designing the use case diagram for the ATM system. Some scenarios of
the system are as follows.

Step-1:
The user is authenticated when enters the plastic ATM card in a Bank ATM. Then enters the user
name and PIN (Personal Identification Number). For every ATM transaction, a Customer
Authentication use case is required and essential. So, it is shown as include relationship.
Example of use case diagram for Customer Authentication is shown below:

Step-2:
User checks the bank balance as well as also demands the mini statement about the bank balance if
they want. Then the user withdraws the money as per their need. If they want to deposit some
money, they can do it. After complete action, the user closes the session.
Example of the use case diagram for Bank ATM system is shown below:
Step-3:
If there is any error or repair needed in Bank ATM, it is done by an ATM technician. ATM technician
is responsible for the maintenance of the Bank ATM, upgrades for hardware, firmware or software,
and on-site diagnosis.
Example of use case diagram for working of ATM technician is shown below:

13 Discuss about the Use Case modeling with example.(13)

<<<<<<<<<<<Refer Answer for Part B Q No 12>>>>>>>>>>>>>>
 14 Apply Use Case modeling for Payroll system in UML.(13)
Employee Payroll System – Use Case Diagram

The use case diagram are usually referred to as behavior diagram used to
describe the actions of all user in a system. All user describe in use case are
actors and the functionality as action of system. The Use case diagram is a
collection of diagram and text together that make action on goal of a process.
In this Employee Payroll Management system website project there are two
actors can do all the activities to run the system. Admin, and Employee.

Use Case Diagram for

Employee Payroll System
 15 Illustrate UML State Machine Diagrams and Modeling with an example.(13)

16 Explain about Interaction Diagram Notation?(13)

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.

17 Discuss about Use-Case Model and its Writing Requirements in Context.(13)

Use case modelling is a useful tool for requirements elicitation. It provides a graphical representation of
the software system's requirements.

The key elements in a use case model are actors (external entities), and the use cases themselves. In
outline, a use case is a unit of functionality (a requirement), or a service, in the system. A use case is not
a process, or program, or function.

Because use case models are simple both in concept and appearance, it is relatively easy to discuss the
correctness of a use case model with a non-technical person (such as a customer).

Use case modeling effectively became a practicable analysis technique with the publication of Ivar
Jacobson's (1991) book “Object-oriented software engineering: a use case driven approach”. Jacobson
has continued to promote this approach to system analysis to the present day, and it has now been
formalised as part of the UML. However, use case modeling is not very different in its purpose and
strategy from earlier techniques, such as structured viewpoint analysis.

PART C
1 (i) What is the Unified process? Is the UP iterative and incremental?Explain. (7)
(ii)Design the use case diagram for the following specification:
A coffee Vending machine dispenses coffee to customer’s .Customers orders coffee
by selecting a recipe from a set of recipe. Customer pay for the coffee using coin.
Change is given back. The “Service staff “ loads ingredients (coffee powder, milk,
sugar,water and chocolate)into the coffee machine. The service staff can also add a
recipe by indicating the name of the coffee,the units of coffee powder milk,
sugar,water and chocolate to be added as well as the cost of the coffee. (8)
2 .A Library lends books and magazines to member, who is registered in the system.
It also maintains the purchase of new books and magazines for the Library. A member
 can reserve a book or magazine that is not currently available in the library, so that
when it is returned or purchased by the library, that person is notified. The library
can easily create, replace and delete information about the books, members, and
reservation in the system. The books transactions are stored in the database. The fine
list while the member returns the book after the due date must be generated. Design
the use case diagram and discover the users and actors of this system, and the
interactions between them must be depicted.(15)

Use case diagrams referred as a Behavior model or diagram. It simply describes and displays the
relation or interaction between the users or customers and providers of application service or the
system. It describes different actions that a system performs in collaboration to achieve something
with one or more users of the system. Use case diagram is used a lot nowadays to manage the
system.

Here, we will understand the designing use case diagram for the library management system. Some
scenarios of the system are as follows :

 User who registers himself as a new user initially is regarded as staff or student for the
library system.
  For the user to get registered as a new user, registration forms are available that is
needed to be fulfilled by the user.
 After registration, a library card is issued to the user by the librarian. On the library card,
an ID is assigned to cardholder or user.
 After getting the library card, a new book is requested by the user as per there
requirement.
 After, requesting, the desired book or the requested book is reserved by the user that
means no other user can request for that book.
 Now, the user can renew a book that means the user can get a new due date for the
desired book if the user has renewed them.
 If the user somehow forgets to return the book before the due date, then the user pays
fine. Or if the user forgets to renew the book till the due date, then the book will be
overdue and the user pays fine.
 User can fill the feedback form available if they want to.
 Librarian has a key role in this system. Librarian adds the records in the library database
about each student or user every time issuing the book or returning the book, or paying
fine.
 Librarian also deletes the record of a particular student if the student leaves the college
or passed out from the college. If the book no longer exists in the library, then the record
of the particular book is also deleted.
 Updating database is the important role of Librarian.

3 Design and illustrate the use case model for activities involved in ordering food in
a restaurant from the point when the customer enters a restaurant to the point when
he leaves the restaurant. (15)

Restaurant ordering use case diagram

The Restaurant Ordering use case diagram provides a comprehensive visualization of the key
functionalities and interactions within a restaurant's ordering process. The diagram presents
a clear representation of the actions performed by the Chef, Waiter, and the overall flow of the
order fulfillment process, ensuring smooth and efficient operations.
The use case diagram encompasses a range of essential actions that occur during the restaurant
ordering process. It illustrates the Waiter taking orders from customers, capturing their
preferences, and ensuring accurate communication of the order details. The Waiter then passes
the order to the Chef, who is responsible for preparing the requested dishes with precision and
attention to detail. The Chef follows the recipes and cooking techniques to ensure the quality
and taste of the food.
Once the order is prepared, the Chef communicates with the Waiter to indicate that the order
is ready for serving. The Waiter then takes the prepared order and serves it to the respective
customer, ensuring prompt and attentive service. This step involves delivering the correct
dishes to the right table and providing any necessary accompaniments or condiments requested
by the customer.
The Restaurant Ordering use case diagram showcases the seamless interaction and
coordination between the Chef and the Waiter, highlighting the importance of effective
communication and collaboration in delivering a satisfying dining experience to customers.
To create this comprehensive and visually appealing diagram, the template has been designed
using Visual Paradigm Online. Visual Paradigm Online is a powerful and user-friendly
diagramming tool that offers a wide range of features and capabilities. With its intuitive
interface, collaborative features, and robust functionality, Visual Paradigm Online is an
excellent choice for designing and visualizing complex systems such as a Restaurant Ordering
system.
4 Explain the benefits and concepts of use case and use case model and analyze the
relating use cases for ATM system. (15)
<<<<<<<<<<Refer Answer for Part B Question No 12>>>>>>>>>>>>
5 What is operation of UML Deployment and Component Diagram? Draw the
diagram for a banking application.
\
 Name: Banking System Deployment Diagram

The Banking System Deployment Diagram represents the physical

Abstract: structure of the project. It reveals the software and hardware
included for the banking system to work properly.

UML
Deployment Diagram
Diagram:

Users: Bank Admin, Bank Owner, and Clients

Tools Used: Diagraming Tools that have UML Deployment Diagram Symbols

Designer: ITSourceCode

Deployment Diagram for Banking System: Project Details

Banking System Deployment
Diagram Description
Deployment diagrams demonstrate how software and hardware
communicate to ensure appropriate banking system operation.
It properly explains how software interacts with hardware. They
also help figure out which certain type of hardware uses software
parts.

the main aim of deployment diagrams is to describe how

software is delivered into the har dware system. It depicts how
software interacts with hardware to perform all of the functions.
It’s a term that describes how software interacts with hardware
and vice versa.

UML Deployment Diagram for Banking

System
UML deployment diagram for banking mana gement system is
used to illustrate its’ physical architecture. In UML, deployment
diagrams can show you how the software and hardware of the
system work together and where the processing takes place.

The banking system uses a UML deployment diagram to sho w

how should the developed software be deployed. It clarifies the
communications between links(nodes) which helps the project to
work according to the design given to it. Deployment diagrams
depict the setup of run-time processing nodes and the
components that reside on them.

Deployment Diagram for Banking System

Here’s the Deployment Diagram for Banking System showing
the detailed illustration of the system’s software and hardware
specification. Additionally, it gives the complete physical
structure of the banking system that is needed in its deployment
for its users.
Deployment Diagram of Banking System in UML

It is important to create the deployment diagram to clarify the

needs of the project before it will put into operation. This will
help you avoid unnecessary difficulties that may encounter
because of specification deficiency.

Banking System UML Deployment Diagram (Explanation)

The banking system UML deployment diagram explains the
sketch of the relationship between software and hardware. These
hardware and software are labeled to clarify their part in the
system’s operation. They were represented by nodes and the
connections were represented by labeled arrows.

The deployment diagram shows the scenario when the system is

deployed. It has 4 nodes represented with boxes and relationship
connections. The nodes are the banking system, the client’s PC,
the bank application, and the bank database. The system node
contains developed software that will hold the banking materials
needed online.

For the connection, the system is connected to the application

and database using a private network which enables it to pass a
connection to the devices and enable clients to access the
system. The database and the application then can communicate
using a TCP/IP connection.

Deployment Diagram for Banking

System (PDF)
You may download the Deployment Diagram for Banking
System PDF by clicking the button below. It has the full details
and discussion on System’s Deployment Diagram. You can also
modify its content to complete your project requirements and
needs.

Deployment Diagram for Banking System (Pdf)

Elements used in Creating your

Deployment Diagram
Here are some elements used in creating your deployment
diagram by Lucidchart . Deployment diagrams come in several
shapes. Most of these things are shown in the graphic below,
and this list gives you a general idea of what you might see.

 Artifact: A rectangle with the name and term “artifact”

enclosed by two arrows represents a software-created
product.
 Association: A message or other sort of communication
between nodes is indicated by a line.
 Component: A rectangle with two tabs that indicate a
software part is called a component.
 Dependency: A dashed line that ends in an arrow
denotes the dependency of one node or component on
another.
  Interface: A contract relationship is indicated by a
circle. Those items that realize the interface are
required to fulfill some sort of task.
 Node: A three-dimensional box represents a hardware
or software object.
 Node as Container: This is a node that has another node
within it, such as the nodes that contain components.
 Stereotype: A device housed within the node, displayed at
the top of the node and flanked by two arrows.

Steps in creating Deployment

Diagram for Banking System
Time needed: 5 minutes

Here are the steps in creating the deployment diagram for the
banking system. In creating this deployment diagram, we
used lucidchart.com

 Step 1: Open your Diagramming tool.

When you open the tool, you may see a blank page. It has
several buttons at the top of the page and on the bottom.
You can use any tool which will make you comfortable. It is
up to you what diagram you want to use. You can draw it
manually if you like.

You can use any diagramming tool as long as it provides

the deployment diagram symbols or elements. These are
the artifacts, association, component, dependency,
interface, node, etc. This is to make your diagram complete
and detailed.

You just have to search for the UML Deployment on the

search bar of your tool which looks like this.

After that, pin the Deployment Diagram Shapes and

Symbols to make it viewable in your workspace.

 Step 2: Finalize the Nodes (Software and Hardware)

The second step in creating your deployment diagram is
finalizing the projects’ hardware and software
specifications. Then you will plot them wisely, giving space
for the arrows that will determine their connections. This
 step will look like this.

The nodes presented here simply show the possible

hardware and software needed for the banking system to
operate. These nodes are composed of users’ devices
(hardware) and system (software).

The system (software) is only accessible for devices when

connected to the internet. The users that can access the
system have their information uploaded to the server. It will
serve as their qualifications to login into the system. The
devices of the users are also considered nodes.

 Step 3: Map the Connections between Nodes

Finally, you will map the arrows that will emphasize the
connections of nodes. These connections should be labeled
 to know the forms of the relationship used between nodes.
The common connections are forms of Networking
connections and others.

Benefits of UML Deployment Diagram

They visualize a system’s hardware processors/nodes/devices,

communication linkages between them, and software file layout on that
hardware.

 It aids in the visualization of the various aspects involved.

 Aids in a more accurate description of all the hardware elements
used by software components.
 It clarifies the description of the runtime involved in processing
nodes.

 Provides hardware specified details for a distributed application.

 Helps in modeling the system’s hardware topology.
 It aids in the modeling of inserted or included software.

 Provides more information on the hardware system.

 Reverse engineering is made easier using the UML deployment
diagram.