UNIT-III

Modeling Techniques using

UML
The Unified Approach to Modeling
• The Unified Modeling Language (UML) is a modeling language that
can be used for a variety of purposes.
• The primary goal of UML is to establish a standard way to visualize
how a system has been constructed.
• UML is a pictorial language used to make software blue prints.
• UML can serve as a central notation for software development
process. Using UML helps project teams communicate, explore
potential designs, and validate the architectural designs of software.
• UML diagrams are made using notation of things and relationships.
History of UML
• Grady Booch, Ivar Jacobson, and James Rumbaugh created it in 1994-95 at
Rational Software, and it was further developed throughout 1996.

• The Object Management Group approved it as a standard in 1997.

• In 1997, the Object Management Group (OMG) approved Unified Modelling

Language as a standard. Since then, it has been administered by OMG.

• In 2005, the International Organization for Standardization (ISO) accepted UML

as a standard. UML has been changed throughout time and is reviewed on a
regular basis.
Definition
• The UML is a standard language for
• Visualizing
• Specifying
• Constructing
• Documenting
Visualizing: UML allows for the creation of visual models and diagrams that help
stakeholders understand and visualize various aspects of a system.
Specifying: UML provides a means to specify and define the characteristics and
requirements of a system.
Constructing: It helps in designing the architecture and components of a system, making it easier to
implement the actual software.
Documenting: UML is extensively used for documenting various aspects of a software system.
Conceptual Model of UML
• A conceptual model can be defined as a model which is made of concepts and
their relationships.
• As UML describes the real time systems it is very important to make a conceptual
model and the proceed gradually.
• Conceptual model of UML can be better understood by learning the following
three major elements:
• UML building blocks
• Rules to connect the building blocks
• Common mechanisms of UML
Building Blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:

1. Things

2. Relationships

3. Diagrams

Things are abstractions that are first-class citizens in a model;

Relationships tie these things together;

Diagrams group interesting collections of things.

Things
Things are the most important building blocks of UML. There are four kinds of
things in the UML.

1. Structural things

2. Behavioral things

3. Grouping things

4. Annotational things
Structural Things
• Structural things are the nouns of the UML models.
• These are static parts of the model, representing elements that are either conceptual or
physical.
• There are seven kinds of Structural things.
1. Class
2. Interface
3. Collaboration
4. Use case
5. Active class
6. Component
7. Node
Structural Things
Class:
• A class is a description of a set of objects
that shares the common attributes,
operations, relationships, and semantics.
A class implements one or more
interfaces.
• Graphically, a class is represented as a
rectangle, usually including its name,
attributes and operations, as shown
below.
• Class name
• Attributes
• Operations
Structural Things
Object:
• An individual that describes the behavior and the functions of a system. The
notation of the object is similar to that of the class; the only difference is that the
object name is always underlined and its notation is given below
• Operations
Structural Things
Interface:
• An interface is a collection of operations that specify a service of a class or
component. An interface describes the externally visible behavior of that element.
• Graphically the interface is rendered as a circle together with its name.

Interface name
Structural Things
Collaboration:
• Collaboration defines an interaction and is a society of roles and other elements
that work together to provide some cooperative behavior that’s bigger than the
sum of all the elements.
• Graphically, collaboration is rendered as an ellipse with dashed lines, usually
including only its name as shown be
Structural Things
Use Case:
• Use case is a description of a set of sequence of actions performed by a system for
a specific goal for the system.
• Graphically, Use Case is rendered as an ellipse with dashed lines, usually
including only its name as shown below.
Structural Things
Active Class:
• An active class is a class whose objects own one or more processes or threads and
therefore can initiate control activity.
• Graphically, an active class is rendered just like a class, but with heavy lines
usually including its name, attributes and operations as shown below.
Structural Things
Component:
• Component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces.
• Graphically, a component is rendered as a rectangle with tabs, usually including
only its name, as shown below.
Structural Things
Node:
• A Node is a physical element that exists at run time and represents a
computational resource, generally having at least some memory and often,
processing capability.
• Graphically, a node is rendered as a cube, usually including only its name, as
shown below.
Behavioral Things
• Behavioral things are the dynamic parts of UML models.
• These are the verbs of a model, representing behavior over time and space.
1.Interaction:
• An interaction is a behavior that consists of a set of messages exchanged among a
set of objects(elements) within a particular context to accomplish a specific task.
• Graphically, a message is rendered as a direct line, almost always including the
name if its operation, as shown below.
Behavioral Things
2. State Machine:
• A state machine is a behavior that specifies the sequence of states of an object in
its life cycle.
• It defines the sequence of states an object goes through in response to events.
• Graphically, a state is rendered as a rounded rectangle usually including its name
and its sub states, if any, as shown below.
Grouping Things
• Grouping things are the organizational parts of the UML models. These are the
boxes into which a model can be decomposed.
• There is one primary kind of grouping thing with “package”.
Package:
• A package is a general-purpose mechanism for organizing elements into groups.
• Package is the only one grouping thing available for gathering structural and
behavioral things.
Annotational Things
• Annotational things are the explanatory parts of the UML models.
• Annotational things can be defined as a mechanism to capture remarks,
descriptions, and comments of UML model elements.
Note:
• A note is simply a symbol for rendering constraints and comments attached to an
element or a collection of elements.
• Graphically a note is represented as a rectangle with dog-eared corner together,
with a textual or graphical comment, as shown below.
Relationships
• Relationship is another most important building block of UML. It shows how
elements are associated with each other and this association describes the
functionality of an application. There are four kinds of relationships in the UML:

1. Dependency

2. Association

3. Generalization

4. Realization
Dependency
• Dependency is a relationship between two things in which change in one element
also affects the other one.
Association
• Association is basically a set of links that connects elements of an UML model. It
also describes how many objects are taking part in that relationship.
Generalization
• Generalization can be defined as a relationship which connects a specialized
element with a generalized element. It basically describes inheritance relationship
in the world of objects.
Realization
• Realization can be defined as a relationship in which two elements are
connected. One element describes some responsibility which is not
implemented and the other one implements them. This relationship exists in
case of interfaces.
Diagrams
• All the elements, relationships are used to make a complete UML diagram
and the diagram represents a system.
• The visual effect of the UML diagram is the most important part of the
entire process.
• Each UML diagram is designed to let developers and customers view a
software system from a different perspective and in varying degrees of
abstraction.
• UML diagrams are the ultimate output of the entire system.
• A diagram is the graphical presentation of a set of elements ,most often
rendered as a connected graph of vertices(things) arcs (relationships).
Diagrams
• UML includes the following nine Behavioral Diagrams:
diagrams 5. Use case diagram
Structural Diagrams: 6. Sequence diagram

1. Class diagram 7. Collaboration diagram,

2. Object diagram 8. State diagram

3. Component diagram 9. Activity diagram

4. Deployment diagram
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.
Class Diagram

Purpose of Class Diagrams

• Following are the purpose of class diagrams given below:

• It analyses and designs a static view of an application.
• It describes the major responsibilities of a system.
• It is a base for component and deployment diagrams.
• It incorporates forward and reverse engineering.
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.
Object Diagram
Purpose of Object Diagram
• The object diagram is actually similar to the concrete (actual) system behavior.
The main purpose is to depict a static view of a system.
• Following are the purposes enlisted below:
• 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.
 Use Case Diagrams
• 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.
• Following are the purposes of a use case diagram given below:
• It gathers the system's needs.
• It depicts the external view of the system.
• It recognizes the internal as well as external factors that influence the system.
• It represents the interaction between the actors.
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.
Sequence Diagram

Purpose of a Sequence Diagram

• To model high-level interaction among active objects within a system.

• To model interaction among objects inside a collaboration realizing a use

case.

• It either models generic interactions or some certain instances of interaction.

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.
State chart Diagram
• It used to describe various states of a single component throughout the software
development life cycle. Their are 4 type of state in state machine :-
• Initial state :-The initial state symbol is used to indicate the beginning of a state
machine diagram.
• Final state :- This symbol is used to indicate the end of a state machine diagram.
• Decision box :- It contains a condition. Depending upon the result of an evaluated
guard condition, a new path is taken for program execution.
• Transition :- A transition is a change in one state into another state which is occurred
because of some event.
Activity diagram
• Activity diagram is used to represent various activities carried out by different
components of a system.
• Initial states: The starting stage before an activity takes place is depicted as
the initial state
• Final states: The state which the system reaches when a specific process ends
is known as a Final State
• Decision box: It is a diamond shape box which represents a decision with
alternate paths. It represents the flow of control.
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 describes all the individual components that are used to make the
functionalities, but not the functionalities of the system.
• It visualizes the physical components inside the system. The components can
be a library, packages, files, etc.
• The component diagram also describes the static view of a system, which
includes the organization of components at a particular instant.
• The collection of component diagrams represents a whole system.
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.
• 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.
Deployment diagram
• Symbol and notation of Deployment
diagram
• The deployment diagram consist of
the following notations:
• A component
• An artifact
• An interface
• A node
Difference between structure and behavior
diagrams
• Structure diagrams provide a static view of a system, emphasizing its
components, relationships, and organization, while behavior diagrams
offer a dynamic view, focusing on the runtime behavior, interactions,
and processes within the system.
Structure Diagrams (Static Modeling)
Diagram Type Description Example
Class Diagram Represents static class structure Modeling a library system with
and relationships. classes like Book, Author, and
Library.
Shows instances and their Displaying
Object Diagram relationships at a specific specific Book and Member objects in
moment. a library system.
Depicts physical or logical Illustrating software components like
Component Diagram system components and their databases, web servers, and client
connections. applications in a web system.
Representing how web server
Displays physical deployment of
Deployment Diagram software components are deployed on
components on nodes or servers.
physical servers.
Behavior Diagrams (Dynamic Modeling)
Diagram Type Description Example
Defines actors and their interactions Modeling how a customer interacts
Use Case Diagram
with the system through use cases. with an ATM system to withdraw cash.
Depicts workflows, processes, and
Illustrating the steps involved in
Activity Diagram actions in a system, including
processing an online order.
branching and parallelism.
Represents the behavior of an object
State Machine Modeling the states and transitions of a
or system as a finite state machine
Diagram traffic signal system.
with states and transitions.
Displays interactions between objects Showing the sequence of messages
Sequence Diagram or components over time through between a user and a database system
messages. during a login process.
 Chapter - 2

Design Engineering
Outline

Design Engineering
• Data Flow Diagrams

• Design process and Design quality

• Design concepts

• The design model

• Pattern-based software design

Data Flow Diagrams
• A data flow diagram (DFD) graphically describes business processes and
the flow of information that passes among them. DFD also describes inputs
and outputs of the process; and where the data will be stored.

• It is used by the analysts, customers, and developers to understand the

requirements more clearly mainly during the requirements gathering and
analysis phase of the SDLC.

• The DFD is also called as a data flow graph or bubble chart.

The Elements of a DFD
• Different people use different notations to represent processes, data stores, data flow
and external entities of the DFD. The most commonly used two different types of
notations are by Yourdon & Coad or Gane & Sarson.

• DFD uses 4 basic symbols to represent the flow of the diagram. They are

• Process

• Data Store

• External Entity

• Data Flow (Arrow)

The Elements of a DFD
• Entities - Entities are source and destination of information data. Entities are
represented by a rectangles with their respective names. The labels should be
noun phrases.
• Process - Activities and action taken on the data are represented by Circle or
Round-edged rectangles and it describes what happens to the data as it moves
through the system. Process labels should be verb phrases.
• Data Storage - There are two variants of data storage - it can either be
represented as a rectangle with absence of both smaller sides or as an open-
sided rectangle with only one side missing. NO VERBS.
• Data Flow - Movement of data is shown by pointed arrows. Data movement is
shown from the base of arrow as its source towards head of the arrow as
destination. NO VERBS.
DFD rules and tips

• Each process should have at least one input and an output.

• Each data store should have at least one data flow in and one data flow
out.

• Data stored in a system must go through a process.

• All processes in a DFD go to another process or a data store.

Levels of DFDs
Levels or layers are used in DFDs to represent progressive degrees of detail about
the system or process. These levels include:
• Level 0: Also known as a "context diagram," this is the highest level DFD and
provides an overview of the entire system. It typically shows the major processes
and external entities.
• Level 1: Level 1 DFDs break down the processes from the Level 0 DFD into more
detailed processes. Each major process is decomposed into sub-processes.
• Level 2: Further decomposition of Level 1 DFDs into even more detailed sub-
processes can be represented in Level 2 DFDs.
Types of DFD
Data Flow Diagrams are either Logical or Physical.

• Logical DFD - This type of DFD concentrates on the system process, and
flow of data in the system. For example in a Banking software system, how
data is moved between different entities.

• Physical DFD - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the
implementation.
Pros and Cons of DFD
Advantages of DFDs:
• DFDs provide a clear and visual representation of how data flows through a
system.
• They help in identifying data sources, destinations, and processes.
• DFDs aid in the communication of system requirements and design to
stakeholders.
Disadvantages of DFDs:
• DFDs can become complex for large and intricate systems.
• They do not provide a detailed internal view of processes.
• DFDs may not capture all aspects of modern software systems, such as object-
oriented concepts.
Design Engineering
• It covers the set of principles, concepts, and practices that lead to the
development of a high quality system or product.
• Goal of design engineering is to produce a model or representation that
depict:
• Firmness: A program should not have any bugs that inhibit its function.
• Commodity: A program should be suitable for the purposes for which it
was intended.
• Delight: The experience of using the program should be a pleasurable
one.
• The design model provides details that are necessary to implement the
system.
Design process and Design quality
• Encompasses the set of principles, concepts and practices that lead to the
development of high quality system or product.
• Design creates a representation or model of the software.
• Design model provides details about S/W architecture, interfaces and
components that are necessary to implement the system.
• Quality is established during Design.
• Design should exhibit firmness, commodity and design.
• Design sits at the kernel of S/W Engineering.
• Design sets the stage for construction.
Fig: Translating the requirements model into the design model
Software Quality Guidelines and Attributes
• McGlaughlin suggests three characteristics that serve as a guide for the
evaluation of a good design:
• The design must implement all of the explicit requirements contained in the
requirements model, and it must accommodate all of the implicit
requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
• The design should provide a complete picture of the software, addressing
the data, functional, and behavioral domains from an implementation
perspective.
Quality Guidelines
In order to evaluate the quality of a design representation, consider the following
guidelines:
1. A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics and
(3) can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned
into elements or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces,
and components.
Quality Guidelines
4. A design should lead to data structures that are appropriate for the classes to
be implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional
characteristics.
6. A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment.
7. A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis.
8. A design should be represented using a notation that effectively communicates
its meaning.
Quality Attributes
The attributes of design name as 'FURPS' are as follows:
• Functionality is assessed by evaluating the feature set and capabilities of
the program, the generality of the functions that are delivered, and the
security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics,
consistency, and documentation.
• Reliability is evaluated by measuring the frequency and severity of failure,
the accuracy of output results, the mean-time-to-failure (MTTF), the ability
to recover from failure, and the predictability of the program.
Quality Attributes
• Performance is measured by considering processing speed, response time,
resource consumption, throughput and efficiency.
• Supportability:
• It combines the ability to extend the program, adaptability,
serviceability.
• Testability, compatibility and configurability are the terms using which a
system can be easily installed and found the problem easily.
• Supportability also consists of more attributes such as compatibility,
extensibility, fault tolerance, modularity, reusability, robustness, security,
portability, scalability.
Design Concepts
A set of fundamental software design concepts has evolved over the
history of software engineering. Each helps you answer the following
questions:
• What criteria can be used to partition software into individual
components?
• How function or data is structure detail separated from a conceptual
representation of the software?
• What uniform criteria define the technical quality of a software
design?
Design Concepts
Abstraction
• Abstraction allows designers to focus on solving a problem without being concerned
about irrelevant lower level details.
• When we consider a modular solution to any problem, many levels of abstraction can
be posed.
• At the highest level of abstraction, a solution is stated in board terms using the
language of the problem environment.
• At the lower levels of abstraction, a more procedural orientation is taken.
• There are two types of abstraction available,
• Procedural abstraction a sequence of instructions that have a specific and limited
function.
• Data abstraction is a named collection of data that describes a data object.
Design Concepts
Architecture
• The overall structure of the software and the ways in which the structure provides
conceptual integrity for a system.
• Consists of components, connectors, and the relationship between them.
• Some of the Architecture models are described below,
• Structural models - architecture as organized collection of components
• Framework models - attempt to identify repeatable architectural patterns
• Dynamic models - indicate how program structure changes as a function of
external events
• Process models - focus on the design of the business or technical process that
system must accommodate
• Functional models - used to represent system functional hierarchy.
Design Concepts
Patterns
• A design pattern describes a design structure that solves a particular design
problem within a specific context and amid “forces” that may have an impact
on the manner in which the pattern is applied and used.
• The intent of each design pattern is to provide a description that enables a
designer to determine
• whether the pattern is applicable to the current work,
• whether the pattern can be reused (hence, saving design time), and
• whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
Design Concepts
Modularity
A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the problem
requirements.
This leads to a "divide and conquer" conclusion-it's easier to solve a complex
problem when you break it into manageable pieces.
Modularity is the single attribute of a software that permits a program to be
managed easily.
The effort (cost) to develop an individual software module does decrease as the
total number of modules increases.
Design Concepts
These characteristics lead to a • Figure: Modularity &
total cost or effort curve shown Software cost information
in the figure. There is a hiding
number, M, of modules that
would result in minimum
development cost, but we do
not have the necessary
sophistication to predict M
with assurance.
Design Concepts
Information hiding
• The principle of information hiding suggests that modules be
“characterized by design decisions that hides from all others”.
• In other words, modules should be specified and designed so that
information contained within a module is inaccessible to other modules that
have no need for such information.
Design Concepts
Functional Independence
The functional independence is the concept of separation and related to the
concept of modularity, abstraction and information hiding.
The functional independence is accessed using two criteria i.e Cohesion and
coupling.
• Cohesion: Cohesion is an extension of the information hiding concept.
A cohesive module performs a single task and it requires a small
interaction with the other components in other parts of the program.
• Coupling: Coupling is an indication of interconnection between
modules in a structure of software.
Design Concepts
Refinement
• Refinement is actually a process of elaboration from high level abstraction to the
lower level abstraction.
• In each step (of the refinement), one or several instructions of the given program are
decomposed into more detailed instructions.
• Abstraction and refinement are complementary concepts.
• Abstraction enables a designer to specify procedure and data and yet suppress low-
level details.
• Refinement helps the designer to reveal low-level details as design progresses.
Design Concepts
Refactoring

• It is a reorganization technique which simplifies the design of

components without changing its function behavior.

• Refactoring is the process of changing the software system in a way

that it does not change the external behavior of the code still improves
its internal structure.
 Design Concepts
• A set of design classes refined the analysis class by providing design details.
• There are five different types of design classes and each type represents the layer of the design
architecture these are as follows:
1. User interface classes These classes are designed for Human Computer
Interaction(HCI).These interface classes define all abstraction which is required for
Human Computer Interaction(HCI).
2. Business domain classes These classes are commonly refinements of the analysis classes.
These classes are recognized as attributes and methods which are required to implement
the elements of the business domain.
3. Process classes It implement the lower level business abstraction which is needed to
completely manage the business domain class.
4. Persistence classes It shows data stores that will persist behind the execution of the
software.
5. System Classes System classes implement software management and control functions
that allow to operate and communicate in computing environment and outside world.
The Design Model
• The design model can be viewed in two different dimensions.
• The process dimension indicates the evolution of the design model as design tasks
are executed as part of the software process.
• The abstraction dimension represents the level of detail as each element of the
analysis model is transformed into a design equivalent and then refined iteratively.
• The design model has four major elements:
• data,
• architecture,
• components, and
• interface.
The Design Model

Data design elements

• The data design element produced a model of data that represent a high
level of abstraction.

• This model is then more refined into more implementation specific

representation which is processed by the computer based system.

• The structure of data is the most important part of the software design.
The Design Model
Architectural design elements
• The architecture design elements provides us overall view of the system.
• The architectural design element is generally represented as a set of
interconnected subsystem that are derived from analysis packages in the
requirement model.
The architecture model is derived from following sources:
• The information about the application domain to built the software.
• Requirement model elements like data flow diagram or analysis classes,
relationship and collaboration between them.
• The architectural style and pattern as per availability.
The Design Model
Interface design elements
• The interface design elements for software represents the information flow
within it and out of the system.
• They communicate between the components defined as part of architecture.
Following are the important elements of the interface design:
• The user interface
• The external interface to the other systems, networks etc.
• The internal interface between various components.
The Design Model
Component level diagram elements • In a context of object-oriented software
• The component level design for software is engineering, a component shown in a
similar to the set of detailed specification UML diagram.
of each room in a house. • The UML diagram is used to represent the
• The component level design for the processing logic.
software completely describes the internal
details of the each software component.
• The processing of data structure occurs in
a component and an interface which allows
all the component operations.
The Design Model
Deployment level diagram elements
• The deployment level design element
shows the software functionality and
subsystem that allocated in the physical
computing environment which support the
software.
• Following figure shows three computing
environment as shown. These are the
personal computer, the CPI server and the
Control panel.
 Chapter - 3

Creating an Architectural
Design
 What Is Architecture?

“The software architecture of a program or computing system is the

structure or structures of the system, which comprise software
components, the externally visible properties of those components,
and the relationships among them.”
The architecture is not the operational software. Rather, it is a
representation that enables you to
1) analyze the effectiveness of the design in meeting its stated
requirements,
2) consider architectural alternatives at a stage when making
design changes is still relatively easy, and
3) reduce the risks associated with the construction of the
software.
 Why Is Architecture Important?

Following are the reasons for the importance of software

architecture.
– The representation of software architecture allows the
communication between all stakeholder and the developer.
– The architecture focuses on the early design decisions that
impact on all software engineering work and it is the
ultimate success of the system.
– The software architecture composes a small and
intellectually graspable model.
– This model helps the system for integrating the
components using which the components are work
together.
 Architectural Descriptions

The IEEE Computer Society has proposed, Recommended Practice for

Architectural Description of Software-Intensive Systems, with the
following objectives:
1) to establish a conceptual framework and vocabulary for use
during the design of software architecture,
2) to provide detailed guidelines for representing an architectural
description, and
3) to encourage sound architectural design practices.
The IEEE standard defines an architectural description (AD) as “a
collection of products to document an architecture”.
The description itself is represented using multiple views, where each
view is “a representation of a whole system from the perspective of a
related set of concerns”.
 Architectural Decisions

• Each view developed as part of an architectural description

addresses a specific stakeholder concern.
• To develop each view (and the architectural description as a
whole) the system architect considers a variety of alternatives
and ultimately decides on the specific architectural features
that best meet the concern.
• Therefore, architectural decisions themselves can be one view
of the architecture.
• The reasons that decisions were made provide insight into
the structure of a system and its conformance to stakeholder
concerns.
 Architectural styles

• The architectural style is a transformation, and it is applied to

the design of an entire system.
• The main aim of architectural style is to build a structure for
all components of the system.
• An architecture of the system is redefined by using the
architectural style.
• An architectural pattern such as architectural style introduces
a transformation on the design of an architecture.
• The software is constructed for computer-based system, and
it shows one of the architectural style from many of style.
 Architectural styles

The design categories of architectural styles includes:

1. A set of components such as database, computational

modules which perform the function required by the
system.
2. A set of connectors that allows the communication,
coordination and cooperation between the components.
3. The constraints which define the integration of
components to form the system.
4. Semantic model allows a designer to understand the
overall properties of a system by using analysis of
elements.
 Architectural styles

The architectural styles that are used while designing the

software as follows:
– Data-centered architectures
– Data-flow architectures
– Call and return architectures
– Object-oriented architectures
– Layered architectures
 Data-centered architecture
• A data store will reside at the center of this architecture and is
accessed frequently by the other components that update, add, delete
or modify the data present within the store.
• The figure illustrates a typical data centered style. The client
software access a central repository. Variation of this approach are
used to transform the repository into a blackboard when data related
to client or data of interest for the client change the notifications to
client software.
• This data-centered architecture will promote integrability. This
means that the existing components can be changed and new client
components can be added to the architecture without the permission
or concern of other clients.
• Data can be passed among clients using blackboard mechanism.
Data-centered architecture
 Data-centered architecture

Advantage of Data centered architecture

• Repository of data is independent of clients

• Client work independent of each other
• It may be simple to add additional clients.
• Modification can be very easy
 Data-flow architecture
• This kind of architecture is used when input data is transformed into
output data through a series of computational manipulative
components.
• The figure represents pipe-and-filter architecture since it uses both
pipe and filter and it has a set of components called filters connected
by lines.
• Pipes are used to transmitting data from one component to the next.
• Each filter will work independently and is designed to take data
input of a certain form and produces data output to the next filter of
a specified form. The filters don’t require any knowledge of the
working of neighboring filters.
• If the data flow degenerates into a single line of transforms, then it is
termed as batch sequential. This structure accepts the batch of data
and then applies a series of sequential components to transform it.
Data-flow architecture
 Data-flow architecture
Advantages of Data Flow architecture
• It encourages upkeep, repurposing, and modification.
• With this design, concurrent execution is supported.

Disadvantage of Data Flow architecture

• It frequently degenerates to batch sequential system
• Data flow architecture does not allow applications that require
greater user engagement.
• It is not easy to coordinate two different but related streams
 Call and return architectures

This architecture style allows to achieve a program structure which is

easy to modify.
Following are the sub styles exist in this category:
1. Main program or subprogram architecture
– The program is divided into smaller pieces hierarchically.
– The main program invokes many of program components in the
hierarchy that program components are divided into
subprogram.
2. Remote procedure call architecture
– The main program or subprogram components are distributed in
network of multiple computers.
– The main aim is to increase the performance.
Call and return architectures
 Object-oriented architectures

• This architecture is the latest version of call-and-return architecture.

• It consist of the bundling of data and methods.
• The components of a system encapsulate data and the operations
that must be applied to manipulate the data.
• Communication and coordination between components are
accomplished via message passing.
Advantage of Object Oriented architecture
• It enables the designer to separate a challenge into a collection of
autonomous objects.
• Other objects are aware of the implementation details of the object,
allowing changes to be made without having an impact on other
objects.
 Layered architectures

• The different layers are defined in the architecture. It consists

of outer and inner layer.
• The components of outer layer manage the user interface
operations.
• Components execute the operating system interfacing at the
inner layer.
• The inner layers are application layer, utility layer and the
core layer.
• In many cases, It is possible that more than one pattern is
suitable, and the alternate architectural style can be designed
and evaluated.
Layered architectures
 Architectural Patterns

• Architectural patterns address an application-specific

problem within a specific context and under a set of
limitations and constraints.
• The pattern proposes an architectural solution that can serve
as the basis for architectural design.

Organization and Refinement

The following questions provide insight into an architectural
style:
– Control
– Data
 Architectural Patterns

Control:
• How is control managed within the architecture?
• Does a distinct control hierarchy exist, and if so, what is the
role of components within this control hierarchy?
• How do components transfer control within the system?
• How is control shared among components?
• What is the control topology?
• Is control synchronized or do components operate
asynchronously?
 Architectural Patterns

Data:
• How are data communicated between components?
• Is the flow of data continuous, or are data objects passed to
the system sporadically?
• What is the mode of data transfer?
• Do data components exist, and if so, what is their role?
• How do functional components interact with data
components?
• Are data components passive or active?
• How do data and control interact within the system?
 Architectural design

• The software must be placed into context

– the design should define the external entities (other
systems, devices, people) that the software interacts with
and the nature of the interaction
• A set of architectural archetypes should be identified
– An archetype is an abstraction (similar to a class) that
represents one element of system behavior
• The designer specifies the structure of the system by defining
and refining software components that implement each
archetype
Representing the System in Context
• At the architectural design level, a software architect uses an architectural
context diagram (ACD) to model the way software interacts with entities
external to its boundaries.
 Representing the System in Context

All the following entities communicates with the target system

through the interface that is small rectangles shown in above figure.
• Superordinate system: These system use the target system like a
part of some higher-level processing scheme.
• Subordinate system: This systems is used by the target system
and provide the data mandatory to complete target system
functionality.
• Peer-level system: These system interact on peer-to-peer basis
means the information is consumed by the target system and the
peers.
• Actors: These are the entities like people, device which interact
with the target system by consuming information that is
mandatory for requisite processing.
Representing the System in Context
 Defining Archetype

• An archetype is a class or pattern which represents a core

abstraction i.e., critical to implement or design for the target
system.
• A small set of archetype is needed to design even the
systems are relatively complex.
• The target system consists of archetype that represent the
stable elements of the architecture.
• Archetype is instantiated in many different forms based on
the behavior of the system.
• In many cases, the archetype is obtained by examining the
analysis of classes defined as a part of the requirement
model.
 Defining Archetype

The following archetypes can be used:

• Node. Represents a cohesive collection of input and output
elements of the home security function. For example, a node might
be comprised of (1) various sensors and (2) a variety of alarm
(output)indicators.
• Detector. An abstraction that encompasses all sensing equipment
that feeds information into the target system.
• Indicator. An abstraction that represents all mechanisms (e.g.,
alarm siren, flashing lights, bell) for indicating that an alarm
condition is occurring.
• Controller. An abstraction that depicts the mechanism that allows
the arming or disarming of a node. If controllers reside on a
network, they can communicate with one another.
Defining Archetype
 Refining the Architecture into Components

• As the software architecture is refined into components, the structure of

the system begins to emerge.
• The architecture must accommodate many infrastructure components that
enable application components but have no business connection to the
application domain.
• Set of top-level components that address the following functionality:
– External communication management—coordinates communication
of the security function with external entities such as other Internet-
based systems and external alarm notification.
– Control panel processing—manages all control panel functionality.
– Detector management—coordinates access to all detectors attached
to the system.
– Alarm processing—verifies and acts on all alarm conditions.
 Describing Instantiations of the System

• The architectural design that has been modeled to this point

is still relatively high level.
• The context of the system has been represented, archetypes
that indicate the important abstractions within the problem
domain have been defined, the overall structure of the
system is apparent, and the major software components
have been identified.
• However, further refinement (recall that all design is
iterative) is still necessary.
 Assessing alternative architectural
designs
An Architecture Trade-off Analysis Method (ATAM)
• ATAM was developed by the Software Engineering Institute (SEI)
which started an iterative evaluation process for software
architecture.
The design analysis activities which are executed iteratively that are
as follows:
– Collect framework
– Elicit requirements, constraints, and environment description
– Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements
– Evaluate quality attributes by considering each attribute in
isolation
– Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
 Assessing alternative architectural
designs
1. Collect framework
• Collect framework developed a set of use cases that represent the
system according to user point of view.

2. Obtained requirement, Constraints, description of the

environment
• These types of information are found as a part of requirement
engineering and is used to verify all the stakeholders are addressed
properly.
 Assessing alternative architectural
designs
3. Describe the architectural styles/patterns that have been chosen to
address the scenarios and requirements.
The architectural style(s) should be described using one of the
following architectural views:

– Module view for analysis of work assignments with

components and the degree to which information hiding has
been achieved.
– Process view for analysis of system performance.
– Data flow view for analysis of the degree to which the
architecture meets functional requirements.
 Assessing alternative architectural
designs
4. Evaluate quality attributes by considering each attribute in
isolation
• The number of quality attributes chosen for analysis is a
function of the time available for review and the degree to
which quality attributes are relevant to the system at hand.
• Quality attributes for architectural design assessment include
reliability, performance, security, maintainability, flexibility,
testability, portability, reusability, and interoperability.
 Assessing alternative architectural
designs
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style

• The sensitivity of quality attributes achieved by making the

small changes in the architecture and find the sensitivity of
the quality attribute which affects the performance.
• The attributes affected by the variation in the architecture are
known as sensitivity points.
 Architectural Complexity

A useful technique for assessing the overall complexity of a proposed

architecture is to consider dependencies between components within
the architecture.
These dependencies are driven by information/control flow within the
system.
Zhao suggests three types of dependencies:
– Sharing dependencies represent dependence relationships
among consumers who use the same resource or producers who
produce for the same consumers
– Flow dependencies represent dependence relationships
between producers and consumers of resources.
– Constrained dependencies represent constraints on the relative
flow of control among a set of activities.
 Architectural Description Languages

• Architectural description language (ADL) provides a

semantics and syntax for describing a software architecture.
• Hofmann and his colleagues suggest that an ADL should
provide the designer with the ability to
• decompose architectural components,
• compose individual components into larger architectural
blocks, and
• represent interfaces (connection mechanisms) between
components.