Module 4

Software Analysis and design

4.1 Introduction of Analysis elements, Scenario based, Flow based, behavior and class based Design
Concepts
4.2 Classification of UML
4.3 Developing UML Diagrams
4.4 Requirement Model – Scenario-based model, Class-based model, Behavioral model.
4.5 Principles, Architecture Design, Coupling vs. Cohesion
4.6 Post Development models- Component Level Design, System Level Design,
4.7 Types of User Interface Design & develop an UI Design

DESIGN CONCEPTS
● A set of fundamental software design concepts has evolved over the history of software engineering.
● Although the degree of interest in each concept has varied over the years, each has stood the test of
time.
● Each provides the software designer with a foundation from which more sophisticated design
methods can be applied.
● Each helps you answer the following questions:
• What criteria can be used to partition software into individual components?
• How is function or data structure detail separated from a conceptual representation of the software?
• What uniform criteria define the technical quality of a software design?
● The beginning of wisdom for a [software engineer] is to recognize the difference between getting a
program to work, and getting it right.
● Fundamental software design concepts provide the necessary framework for “getting it right.”

4.1 Introduction of Analysis elements, Scenario based, Flow based, behavior and class based Design
Concepts
● Requirements for a computer-based system can be seen in many different ways.
● Some software people argue that it’s worth using a number of different modes of representation
while others believe that it’s best to select one mode of representation.
● The specific elements of the requirements model are dedicated to the analysis modeling method that
is to be used.
● Analysis model operates as a link between the 'system description' and the 'design model
● In the analysis model, information, functions and the behavior of the system is defined and these are
translated into the architecture, interface and component level design in the 'design modeling'.
● There are four levels of elaboration.

Scenario-based elements :
● This type of element represents the system user point of view.
● Scenario based elements are use case diagrams, user stories.
● Using a scenario-based approach, the system is described from the user's point of view.
● For example, basic use cases and their corresponding use-case diagrams evolve into more elaborate
template-based use cases.
● Figure 1(a) depicts a UML activity diagram for eliciting requirements and representing them using
use cases.

1
 Figure 1: UML activity diagrams for eliciting requirements

Class-based elements :
● A collection of things that have similar attributes and common behaviors i.e., objects are categorized
into classes.
● The object of this type of element is manipulated by the system.
● It defines the object, attributes and relationship.
● The collaboration is occurring between the classes.
● Class based elements are the class diagram, collaboration diagram.
● For example, a UML class diagram can be used to depict a Sensor class for the SafeHome security
function (Figure 2)

Figure 2: Class diagram for sensor

● Note that the diagram lists attributes of sensors and operations that can be applied to modify these
attributes.
● In addition to class diagrams, other analysis modeling elements depict the manner in which classes
collaborate with one another and relationships and interactions between classes.

Behavioral elements :
● Effect of behavior of computer-based systems can be seen on design that is chosen and
implementation approach that is applied.
● Modeling elements that depict behavior must be provided by the requirements model.
● Method for representing behavior of a system by depicting its states and events that cause the system
to change state is a state diagram.
● Behavioral elements represent the state of the system and how it is changed by the external events.
● The behavioral elements are sequence diagrams, state diagrams.

2
 ● A state is an externally observable mode of behavior. In addition, a state diagram indicates actions
taken as a consequence of a particular event.
● To illustrate use of a state diagram, consider software embedded within safeHome control panel that
is responsible for reading user input. A simplified UML state diagram is shown in Figure 3.

Figure 3: UML state diagram notation

Flow-oriented elements :
● As it flows through a computer-based system information is transformed.
● System accepts input, applies functions to transform it, and produces output in various forms.
● Input may be a control signal transmitted by a transducer, a series of numbers typed by a human
operator, a packet of information transmitted on a network link, or a voluminous data file retrieved
from secondary storage.
● Information flows through a computer-based system and it gets transformed.
● It shows how the data objects are transformed while they flow between the various system functions.
● The flow elements are data flow diagram, control flow diagram.
● Transform may compromise a single logical comparison, a complex numerical algorithm, or a
rule-inference approach of an expert system. Output produces a 200-page report or may light a single
LED.
● In effect, we can create a flow model for any computer-based system, regardless of size and
complexity.

4.2 Classification of UML

● The Unified Modeling Language (UML) is “a standard language for writing software blueprints.
● UML may be used to visualize, specify, construct, and document the artifacts of a software-intensive
system”.
● In other words, just as building architects create blueprints to be used by a construction company,
software architects create UML diagrams to help software developers build the software.
● If you understand the vocabulary of UML (the diagrams’ pictorial elements and their meanings), you
can much more easily understand and specify a system and explain the design of that system to others.
● Grady Booch, Jim Rumbaugh, and Ivar Jacobson developed UML in the mid-1990s with much
feedback from the software development community.

3
UML-Diagrams

The UML diagrams are categorized into structural diagrams, behavioral diagrams, and also interaction
overview diagrams. The diagrams are hierarchically classified in the following figure:

1. Structural Diagrams
Structural diagrams depict a static view or structure of a system. It is widely used in the documentation of
software architecture. It embraces class diagrams, composite structure diagrams, component diagrams,
deployment diagrams, object diagrams, and package diagrams. It presents an outline for the system. It
stresses the elements to be present that are to be modeled.

● Class Diagram: Class diagrams are one of the most widely used diagrams. It is the backbone of all the
object-oriented software systems. It depicts the static structure of the system. It displays the system's
class, attributes, and methods. It is helpful in recognizing the relation between different objects as well
as classes.
● Object Diagram: It describes the static structure of a system at a particular point in time. It can be used
to test the accuracy of class diagrams. It represents distinct instances of classes and the relationship
between them at a time.
● Component Diagram: It portrays the organization of the physical components within the system. The
components can be a software component such as a database or user interface; or a hardware
component such as a circuit, microchip or device; or a business unit such as supplier, payroll or
shipping. It is used for modeling execution details. It determines whether the desired functional
requirements have been considered by the planned development or not, as it depicts the structural
relationships between the elements of a software system.
● Deployment Diagram: It presents the system's software and its hardware by telling what the existing
physical components are and what software components are running on them. It produces information
about system software. It is incorporated whenever software is used, distributed, or deployed across
multiple machines with dissimilar configurations.

2. Behavioral Diagrams:
4
 Behavioral diagrams portray a dynamic view of a system or the behavior of a system, which describes the
functioning of the system. It includes use case diagrams, state diagrams, and activity diagrams. It
defines the interaction within the system.

● State Machine Diagram: It is a behavioral diagram. it portrays the system's behavior utilizing finite
state transitions. It is also known as the State-charts diagram. It models the dynamic behavior of a
class in response to external stimuli.
● Activity Diagram: It models the flow of control from one activity to the other. With the help of an
activity diagram, we can model sequential and concurrent activities. It visually depicts the workflow as
well as what causes an event to occur.
● Use Case Diagram: It represents the functionality of a system by utilizing actors and use cases. It
encapsulates the functional requirement of a system and its association with actors. It portrays the use
case view of a system.

3. Interaction Diagrams
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object interactions and
also depicts the flow between various use case elements of a system. In simple words, it shows how
objects interact with each other and how the data flows within them. It consists of communication,
interaction overview, sequence, and timing diagrams.
● Sequence Diagram: It shows the interactions between the objects in terms of messages exchanged over
time. It delineates in what order and how the object functions are in a system.

● Communication Diagram: It shows the interchange of sequence messages between the objects. It
focuses on objects and their relations. It describes the static and dynamic behavior of a system.

1. UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects residing in the
system and the relationships between them. A class consists of its objects, and also it may inherit from
other classes. A class diagram is used to visualize, describe, document various different aspects of the
system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the software system. It
constitutes class names, attributes, and functions in a separate compartment that helps in software
development. Since it is a collection of classes, interfaces, associations, collaborations, and constraints,
it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only diagram that is
widely used for construction, and it can be mapped with object-oriented languages. It is one of the most
popular UML diagrams. Following are the purpose of class diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.

5
2. It reduces the maintenance time by providing an overview of how an application is structured before
coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be programmed.
5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:

● Upper Section: The upper section encompasses the name of the class. A class is a representation of
similar objects that share the same relationships, attributes, operations, and semantics. Some of the
following rules that should be taken into account while representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
● Middle Section: The middle section constitutes the attributes, which describe the quality of the class.
The attributes have the following characteristics:
a. The attributes are written along with its visibility factors, which are public (+), private (-), protected (#),
and package (~).
b. The accessibility of an attribute class is illustrated by the visibility factors.
c. A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
● Lower Section: The lower section contain methods or operations. The methods are represented in the
form of a list, where each method is written in a single line. It demonstrates how a class interacts with
data.

Relationships

In UML, relationships are of three types:

● Dependency: A dependency is a semantic relationship between two or more classes where a change in
one class causes changes in another class. It forms a weaker relationship.
In an e-commerce application, a Cart class depends on a Product class because the Cart class uses the
Product class as a parameter for an add operation. In a class diagram, a dependency relationship points
from the Cart class to the Product class

6
● Generalization: A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form of
Bank Account.

● Association: It describes a static or physical connection between two or more objects. It depicts how
many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is not
specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more

specific then association. It defines a part-whole or part-of relationship. In this kind of relationship, the
child class can exist independently of its parent class.

The company encompasses a number of employees, and even if one employee resigns, the company still
exists.

Composition: The composition is a subset of aggregation. It portrays the dependency between the parent
and its child, which means if one part is deleted, then the other part also gets discarded. It represents a
whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the contacts will be lost.

How to draw a Class Diagram?

7
The class diagram is used most widely to construct software applications. It not only represents a static
view of the system but also all the major aspects of an application. A collection of class diagrams as a
whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are given below:

1. To describe a complete aspect of the system, it is suggested to give a meaningful name to the class
diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of the unwanted property
will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct before producing its
final version.

Class Diagram Example

A class diagram describing the sales order system is given below.

8
A class diagram describing the bank system is given below.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in the
establishment of the component and deployment diagrams. It helps to construct an executable code to
perform forward and backward engineering for any system, or we can say it is mainly used for
construction. It represents the mapping with object-oriented languages that are C++, Java, etc. Class
diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

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

9
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 listed below:

● It is used to perform forward and reverse engineering.

● It is used to understand object behavior and their relationships practically.
● It is used to get a static view of a system.
● 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 starting 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

Class Diagram Object Diagram

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

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

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

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

3. UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the system's
functionality by incorporating use cases, actors, and their relationships. It models the tasks, services, and
functions required by a system/subsystem of an application. It depicts the high-level functionality of a
system and also tells how the user handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It accumulates the
system's requirement, which includes both internal as well as external influences. It invokes persons, use
cases, and several things that invoke the actors and elements accountable for the implementation of use
case diagrams. It represents how an entity from the external environment can interact with a part of the
system.

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case diagram, and then the
system's functionalities are found. And once every single functionality is identified, they are then
transformed into the use cases to be used in the use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the person or a thing
that invokes the functionality of a system. It may be a system or a private entity, such that it requires an
entity to be pertinent to the functionalities of the system to which it is going to interact.

Once both the actors and use cases are enlisted, the relation between the actor and use case/ system is
inspected. It identifies the no of times an actor communicates with the system. Basically, an actor can
interact multiple times with a use case or system at a particular instance of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case of a system.

11
2. The communication of an actor with a use case must be defined in an understandable way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of interactions
between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online. The top-level
uses are as follows; View Items, Make Purchase, Checkout, Client Register. The View Items use case is
utilized by the customer who searches and view products. The Client Register use case allows the
customer to register itself with the website for availing gift vouchers, coupons, or getting a private sale
invitation. It is to be noted that the Checkout is an included use case, which is part of Making Purchase,
and it is not available by itself.

The View Items is further extended by several use cases such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use cases provide
some functions to customers, which allows them to search for an item. The View Items is further extended
by several use cases such as; Search Items, Browse Items, View Recommended Items, Add to Shopping
Cart, Add to Wish list. All of these extended use cases provide some functions to customers, which allows
them to search for an item.

Both View Recommended Item and Add to Wish List include the Customer Authentication use case, as
they necessitate authenticated customers, and simultaneously item can be added to the shopping cart
without any user authentication.

12
 Similarly, the Checkout use case also includes the following use cases, as shown below. It requires an
authenticated Web Customer, which can be done by login page, user authentication cookie ("Remember
me"), or Single Sign-On (SSO). SSO needs an external identity provider's participation, while Web site
authentication service is utilized in all these use cases.

The Checkout use case involves Payment use case that can be done either by the credit card and external
credit payment services or with PayPal.

Important tips for drawing a Use Case diagram

Following are some important tips that are to be kept in mind while drawing a use case diagram:

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among the multiple
interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn more generalized.

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

13
 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 illustrate 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 swimlanes 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 data is
received at an inward edge, it gets copied and split across 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.

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

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

5. UML State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which shows the order
of states undergone 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.

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 undergoes several states, such that the lifespan exists until the program is executing. Each
state depicts some useful information about the object.

It blueprints an interactive system that responds 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.

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

17
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, the transition from Serving Customer
state back to the Idle state could be triggered by the cancel event.

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

6. UML 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 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 the 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, respectively.

19
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:

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

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

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

● Destroy Message: It describes a communication, particularly between the lifelines of an interaction that
depicts a request to destroy the lifecycle of the target.

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

Note

A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.

Sequence Diagram for Sales Order System

The sequence diagram example shows three participating objects: Customer, Order, and the Stock. Without
even knowing the notation formally, you can probably get a pretty good idea of what is going on.

● Step 1 and 2: Customer creates an order.

● Step 3: Customers add items to the order.
● Step 4, 5: Each item is checked for availability in inventory.
● Step 6, 7, 8 : If the product is available, it is added to the order.
● Step 9 return
● Step 10, 11: save and destroy order

21
7. UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both the
sequence and the collaboration diagrams represent the same information but differently. Instead of showing
the flow of messages, it depicts the architecture of the object residing in the system as it is based on
object-oriented programming. An object consists of several features. Multiple objects present in the system
are connected to each other. The collaboration diagram, which is also known as a communication diagram, is
used to portray the object's architecture in the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
○ The object is represented by specifying their name and class.
○ It is not mandatory for every class to appear.
○ A class may constitute more than one object.
○ In the collaboration diagram, firstly, the object is created, and then its class is specified.
○ To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each
actor has its respective role and name. In this, one actor initiates the use case.
3. Links: The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a solid line.
The link helps an object to connect with or navigate to another object, such that the message flows are
attached to links.
4. Messages: It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labeled arrow, which is placed near a
link. The messages are sent from the sender to the receiver, and the direction must be navigable in that
particular direction. The receiver must understand the message

22
Difference between sequence and collaboration diagram

Sequence Diagrams Collaboration Diagrams

The sequence diagram represents the The collaboration diagram also comes
UML, which is used to visualize the under the UML representation which is
sequence of calls in a system that is used used to visualize the organization of the
to perform a specific functionality. objects and their interaction.

The collaboration diagrams are used to

The sequence diagrams are used to
represent the structural organization of the
represent the sequence of messages that
system and the messages that are sent and
are flowing from one object to another.
received.

The sequence diagram is used when the The collaboration diagram is used when
time sequence is the main focus. object organization is the main focus.

The collaboration diagrams are better

The sequence diagrams are better suited
suited for depicting simpler interactions of
for analysis activities.
the smaller number of objects.

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

23
Notation of a Component Diagram

Components are represented as a rectangular classifier with the keyword «component»; optionally the
component may be displayed as a rectangle with a component icon in the right-hand upper corner.

Assembly Connector

The assembly connector bridges a component’s required interface (Component1) with the provided interface
of another component (Component2); this allows one component to provide the services that another
component requires.

Components with Ports

Using Ports with component diagrams allows for a service or behavior to be specified to its environment as
well as a service or behavior that a component requires. Ports may specify inputs and outputs as they can
operate bi-directionally. The following diagram details a component with a port for online services along
with two provided interfaces order entry and tracking as well as a required interface payment.

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.

24
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?

25
 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 system's source code.

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

26
 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

27
 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

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.

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

4.7 Types of User Interface Design & develop an UI Design

● User Interface Design is a process of designing or fabricating the interfaces through which the user can
communicate with the computer.
● The software engineer accomplishes the task of designing the user interface, and they ensure that the user
interface is easy to understand, achieves goals, and is suitable, encouraging, and forgiving.
● The user interface is a device or a program (application program) that facilitates the user to communicate
with the computer to convey what they want to do or what they want from the computer.
● The user interface is what the users see when they use the computer.
● The user interface can be categorized into three types those are:
Command-line Interface
Menu-Based Interface
Graphical User Interface

● 1. Command Line Interface

● The command-line interface was the only mode of interaction with the computer in the starting days of
computing. Here, the user communicates with the computer using textual instructions or commands. For
example, if one needs to delete a file from the system, the command would be: del c:\file.txt
● But, this kind of user interface is not user-friendly as it is hard to learn such commands.
● The commands can even be error-prone and unforgiving.
● Such interfaces may be irritating. So, the command line interface is not for the casual user, but the
experienced users generally prefer the command-line interface.
● Example: Unix operating system

● 2. Menu Based Interface

● It is somewhat easier than the command line interface as users interacting with the menu-based interface
‘do not have to learn the command name’, nor do they have to put effort into writing the commands.
● Here, the user does not have to type the commands; thus, the syntax error is automatically avoided.
● A very popular example of a menu-based interface is ATM. A user uses menu buttons to select the options
from the menu.

● 3. Graphical User Interface (GUI)

● Over a period of time, there has been a tremendous evolution in the computer’s user interface.
● Today’s computer has a high-resolution screen with pointing devices (mouse).
● The modern-day computer’s interface has windows, scroll bars, text boxes, buttons, icons, and menus.
● To pick and point out the elements of GUI, we have a mouse.
● Graphical user interfaces are easy to learn as compared to the command-line interface. GUI provides
multiple windows to the user simultaneously to interact with the system, and it even allows the user to
switch between the windows.

29
● THE GOLDEN RULES
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
● These golden rules actually form the basis for a set of user interface design principles that guide this
important aspect of software design.

● Place the User in Control

● Define interaction modes in a way that does not force a user into unnecessary or undesired actions.
● Provide for flexible interaction. Allow user interaction to be interruptible and undoable.
● Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical
internals from the casual user.
● Design for direct interaction with objects that appear on the screen.

● Reduce the User’s Memory Load

● Reduce demand on short-term memory
● Establish meaningful defaults.
● Define shortcuts that are intuitive
● The visual layout of the interface should be based on a real-world metaphor
● Disclose information in a progressive fashion.

● Make the Interface Consistent

● Allow the user to put the current task into a meaningful context.
● Maintain consistency across a family of applications.
● If past interactive models have created user expectations, do not make changes unless there is a compelling
reason to do so.

30