UNIT-2

 Requirements Analysis and Software design:

 Requirements gathering and analysis
 software requirements specifications (SRS).
 Design Engineering:
 overview of design process
 Design Concepts
 Architectural Concepts
 Requirements Analysis and
Software design
 Requirements Analysis and Software design:
 Requirement analysis is significant and essential activity after elicitation.
 One can analyse, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements.
 This activity reviews all requirements and may provide a graphical view of the
entire system.
 After the completion of the analysis, it is expected that the understandability of
the project may improve significantly. Also use the interaction with the
customer to clarify points of confusion and to understand which requirements
are more important than others.
Steps in Requirements Analysis
 Steps in Requirements Analysis
We have 4 steps in the Requirements analysis:
They are
1. Draw the Context Diagram
2. Development of the Prototype
3. Model the requirements.
4. Finalise the requirements
Draw the context diagram: The context diagram is a simple model that defines the
boundaries and interfaces of the proposed systems with the external world. It
identifies the entities outside the proposed system that interact with the system.
For Example:
The context diagram of student result management system is given below.
The context diagram of student result
management system
 Steps in Requirements Analysis
2. The Development of Prototype (Preliminary version of a System)is Optional:
• One effective way to find out what the customer wants to construct a prototype.
• The prototype helps the client to visualize the proposed system and increase the
understanding of the requirements.
• When developers and users are not sure about some of the elements, a
prototype may help both the parties to take a final decision.
• The prototype should be built quickly and at a relatively low cost. Hence it will
always have limitations and would not be acceptable in the final system. This is
an optional activity.
 Steps in Requirements Analysis
3. Model the requirements: This process usually consists of various graphical
representations of the functions, data entities, external entities, and the relationships
between them.
The graphical view may help to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow diagram, Entity-Relationship diagram,
Data Dictionaries, State-transition diagrams, etc.

4. Finalise the requirements: After modelling the requirements, One can have a better
understanding of the system behaviour. The inconsistencies and ambiguities have been
identified and corrected. The flow of data amongst various modules has been analysed.
Elicitation and analyse activities have provided better insight into the system.
Now One can finalize the analysed requirements, and the next step is to document these
requirements in a prescribed format.
• A software requirements specification (SRS) is a document that describes that, what the
software will do and how it will be expected to perform.
• It also describes the functionality , the product needs to fulfil all stakeholders (business, users)
needs.
• Requirements come from stakeholders, including partners, customers, management, product
management, engineering, sales, support, and operations.
• Requirements gathering needs to include both functional and non-functional requirements.
• Functional requirements ensure that end product is what the customer wants.
• Non-functional requirements ensure to stay within limits.
Software Requirements Specifications(SRS)
• Clear, concise, and executable requirements help development teams
create a proper product.
• Requirements management involves gathering, understanding, refining,
• Prioritizing, and planning everything a product or project needs to succeed.
• It is a continuous process throughout the product lifecycle to make sure
end product meets the needs of customers and stakeholders.
• Successful requirements management means understanding various types
of requirements, ways in which to write them, and also strategies that will
help to manage them efficiently.
 SRS
Following are the features of a good SRS document:
1. Correctness: User review is used to provide the accuracy of requirements
stated in the SRS. SRS is said to be perfect if it covers all the needs that are
truly expected from the system.
2. Completeness: The SRS is complete if, and only if, it includes the following
elements:
(1). All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces.
(2). Definition of their responses , the software to all realizable classes of
input data in all available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS
and definitions of all terms and units of measure.
 SRS
.
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict.
There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts.
For example,
(a) The format of an output report may be described in one requirement as
tabular but in another as textual.
(b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
 SRS
4. Modifiability: SRS should be made as modifiable as likely and should be
capable of quickly obtain changes to the system to some extent. Modifications
should be perfectly indexed and cross-referenced.
5. Verifiability: SRS is correct when the specified requirements can be verified
with a cost-effective system to check whether the final software meets those
requirements. The requirements are verified with the help of reviews.
6. Traceability: The SRS is traceable if the origin of each of the requirements is
clear and if it facilitates the referencing of each condition in future
development or enhancement documentation.
 SRS
7. Design Independence: There should be an option to select from multiple
design alternatives for the final system. More specifically, the SRS should not
contain any implementation details.
8. Testability: An SRS should be written in such a method that it is simple to
generate test cases and test plans from the report
9. Understandable by the customer: An end user may be an expert in his/her
explicit domain but might not be trained in computer science.
Hence, the purpose of formal notations and symbols should be avoided too as
much extent as possible. The language should be kept simple and clear.
10. The right level of abstraction:
The level of abstraction modifies according to the objective of the SRS.
 SRS
The essential properties of a good SRS document are the following:
1. Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
decrease readability and also increase error possibilities.
2. Structured: It should be well-structured. A well-structured document is
simple to understand and modify. In practice, the SRS document undergoes
several revisions to cope up with the user requirements. Often, user
requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-
structured.
 SRS
Properties of a good SRS document
3. Black-box view:
The SRS document should define the external behaviour of the system and
not discuss the implementation issues. The SRS report should view the system
to be developed as a black box and should define the externally visible
behaviour of the system. For this reason, the SRS report is also known as the
black-box specification of a system.
4. Conceptual integrity:
It should show conceptual integrity so that the reader can understand it.
Response to undesired events: It should characterize acceptable responses to
unwanted events. These are called system response to exceptional conditions.
5. Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to decide
whether or not requirements have been met in an implementation.
 Design Engineering
Design Engineering:
Software design is a mechanism to transform user requirements into some
suitable form, which helps the programmer in software coding and
implementation.
It deals with representing the client's requirement, as described in SRS
(Software Requirement Specification) document, into a form, i.e., easily
implementable using programming language.
The software design phase is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from the problem domain to the
solution domain.
In software design, we consider the system to be a set of components or
modules with clearly defined behaviours and boundaries.
 Design Engineering
Design Engineering:
Software design process have two levels.
1. External Design
2. Internal Design
External Design:
External design focus on deciding which modules are needed, their
specifications, relationship and interface among them.
Internal Design:
Internal Design focus on planning and specifying the internal structure and
Processing details.
 Design Engineering
Objectives of Software Design
1. Correctness: Software design should be correct as per requirement.
2. Completeness: The design should have all components like data structures,
modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.
 Design Engineering
Software Design Principles
Software design principles are concerned with providing means to handle the
complexity of the design process effectively.
Effectively managing the complexity will not only reduce the effort needed for
design but can also reduce the scope of introducing errors during design.
Here we have 4 Software Design Principles.
1. Problem Partitioning
2. Abstraction
3. Modularity
4. Top down and Bottom up Strategy.
 Software Design Principles
Software Design Principles
1. Problem Partitioning:
For small problem, one can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the
problem into smaller pieces so that each piece can be captured separately.
For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning.
• Software is easy to understand
• Software becomes simple
• Software is easy to test
• Software is easy to modify
• Software is easy to maintain
• Software is easy to expand
 Software Design Principles
2. Abstraction
An abstraction is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the
implementation. Abstraction can be used for existing element as well as the
component being designed. Here we have
Two common abstraction mechanisms
 Functional Abstraction
 Data Abstraction
Functional Abstraction
A module is specified by the method it performs.
The details of the algorithm to accomplish the functions are not visible to the
user of the function.
Functional abstraction forms the basis for Function oriented design
approaches.
 Software Design Principles
Two common abstraction mechanisms
 Functional Abstraction
 Data Abstraction
Data Abstraction:
Details of the data elements are not visible to the users of data. Data
Abstraction forms the basis for Object Oriented design approaches.
 Modularity
Modularity
Modularization is a technique to divide a software system into multiple discrete and
independent modules, which are expected to be capable of carrying out task(s)
independently. These modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed and/or compiled
separately and independently.
Modular design follows the rules of ‘divide and conquer’ problem-solving strategy
this is because there are many other benefits attached with the modular design of a
software.
Advantage of modularity:
• Smaller components are easier to maintain
• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible
• Desired from security aspect.
 Modularity
Disadvantage of modularity
• There are several disadvantages of Modularity
• Execution time maybe, but not certainly, longer
• Storage size perhaps, but is not certainly, increased
• Compilation and loading time may be longer
• Inter-module communication problems may be increased
• More linkage required, run-time may be longer, more source lines must be
written, and more documentation has to be done
 Strategy of Design
Top-down Approach and Bottom-up Approach
Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-
components.
 Strategy of Design
Top-down Approach and Bottom-up Approach
Bottom-up Approach: A bottom-up approach begins with the lower details
and moves towards up the hierarchy, as shown in fig. This approach is suitable
in case of an existing system.
 Design Engineering
Software Design Levels
Software design yields three levels of results:
Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into less-abstracted view of sub-systems
and modules and depicts their interaction with each other. High-level design focuses
on how the system along with all of its components can be implemented in forms of
modules. It recognizes modular structure of each sub-system and their relation and
interaction among each other.
Detailed Design- Detailed design deals with the implementation part of what is seen
as a system and its sub-systems in the previous two designs. It is more detailed
towards modules and their implementations. It defines logical structure of each
module and their interfaces to communicate with other modules.
 Concurrency
Concurrency
Software are meant to be executed sequentially.
By sequential execution the coded instruction will be executed one after
another implying only one portion of program being activated at any given
time. software has multiple modules, then only one of all the modules can be
found active at any time of execution.
In software design, concurrency is implemented by splitting the software into
multiple independent units of execution, like modules and executing them in
parallel. In other words, concurrency provides capability to the software to
execute more than one part of code in parallel to each other.
It is necessary for the programmers and designers to recognize those
modules, which can be made parallel execution.
 Coupling and Cohesion
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules based on
some characteristics. Modules are set of instructions put together in order to achieve some
tasks. They are though, considered as single entity but may refer to each other to work
together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements of a
module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely –
Co-incidental cohesion - It is unplanned and random cohesion, which might be the result of
breaking the program into smaller modules for the sake of modularization. Because it is
unplanned, it may serve confusion to the programmers and is generally not-accepted.
Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.
Temporal Cohesion - When elements of module are organized such that they are processed
at a similar point in time, it is called temporal cohesion.
 Coupling and Cohesion
Procedural cohesion - When elements of module are grouped together, which
are executed sequentially in order to perform a task, it is called procedural
cohesion.
Communicational cohesion - When elements of module are grouped
together, which are executed sequentially and work on same data
(information), it is called communicational cohesion.
Sequential cohesion - When elements of module are grouped because the
output of one element serves as input to another and so on, it is called
sequential cohesion.
Functional cohesion - It is considered to be the highest degree of cohesion,
and it is highly expected. Elements of module in functional cohesion are
grouped because they all contribute to a single well-defined function. It can
also be reused.
 Coupling
Coupling is a measure that defines the level of inter-dependability among modules of
a program. It tells at what level the modules interfere and interact with each other.
The lower the coupling, the better the program.
There are five levels of coupling, namely -
Content coupling - When a module can directly access or modify or refer to the
content of another module, it is called content level coupling.
Common coupling- When multiple modules have read and write access to some
global data, it is called common or global coupling.
Control coupling- Two modules are called control-coupled if one of them decides the
function of the other module or changes its flow of execution.
Stamp coupling- When multiple modules share common data structure and work on
different part of it, it is called stamp coupling.
Data coupling- Data coupling is when two modules interact with each other by
means of passing data (as parameter). If a module passes data structure as
parameter, then the receiving module should use all its components.
Ideally, no coupling is considered to be the best.
 Design Verification
The output of software design process is design documentation, pseudo
codes, detailed logic diagrams, process diagrams, and detailed description of
all functional or non-functional requirements.
The next phase, which is the implementation of software, depends on all
outputs mentioned above.
It is then becomes necessary to verify the output before proceeding to the
next phase. In The early stage any mistake is detected, the better it is or it
might not be detected until testing of the product. If the outputs of design
phase are in formal notation form, then their associated tools for verification
should be used otherwise a thorough design review can be used for
verification and validation.
By structured verification approach, reviewers can detect defects that might
be caused by overlooking some conditions. A good design review is important
for good software design, accuracy and quality.
 Data Flow Diagrams
Data Flow Diagrams
• A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system. A neat and clear DFD can depict the
right amount of the system requirement graphically.
• Data Flow Diagram can be manual, automated, or a combination of both.
• Data Flow Diagram shows how data enters and leaves the system, what
changes the information, and where data is stored.
• The objective of a DFD is to show the scope and boundaries of a system as
a whole.
• Data Flow Diagram may be used as a communication tool between a
system analyst and any person who plays a part in the order that acts as a
starting point for redesigning a system. The DFD is also called as a data flow
graph or bubble chart.
 Data Flow Diagrams
The following points are important:
• All names should be unique. This makes it easier to refer elements in the
DFD.
• Remember that DFD is not a flow chart. Arrows is a flow chart that
represents the order of events; arrows in DFD represents flowing data. A
DFD does not involve any order of events.
• Suppress logical decisions. If we ever have the urge to draw a diamond-
shaped box in a DFD, suppress that urge! A diamond-shaped box is used in
flow charts to represents decision points with multiple exists paths of
which the only one is taken. This implies an ordering of events, which
makes no sense in a DFD.
• Do not become bogged down with details. Defer error conditions and error
handling until the end of the analysis.
 Data Flow Diagrams
Symbols used for DFD
 Data Flow Diagrams
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.
 Data Flow Diagrams
DFD Components
DFD can represent Source, destination, storage and flow of data using the
following set of components.
Entities - Entities are source and destination of information data. Entities are
represented by a rectangles with their respective names.
Process - Activities and action taken on the data are represented by Circle or
Round-edged rectangles.
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.
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.
 Levels of DFD
Levels of DFD
Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts
the entire information system as one diagram concealing all the underlying
details. Level 0 DFDs are also known as context level DFDs.
 Levels of DFD
Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level
1 DFD depicts basic modules in the system and flow of data among various
modules. Level 1 DFD also mentions basic processes and sources of
information.
 Levels of DFD
Level 2 - At this level, DFD shows how data flows inside the modules
mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with
deeper level of understanding unless the desired level of specification is
achieved.
 Structure Charts
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the
system in more detail than DFD. It breaks down the entire system into lowest
functional modules, describes functions and sub-functions of each module of
the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a
specific task is performed.
Here are the symbols used in construction of structure charts -
Module - It represents process or subroutine or task. A control module
branches to more than one sub-module. Library Modules are re-usable and
invokable from any module.
Structure Charts
Structure Charts
 Structure Charts
Structure Charts
Condition - It is represented by small diamond at the base of module. It
depicts that control module can select any of sub-routine based on some
condition
 Structure Charts
Jump - An arrow is shown pointing inside the module to depict that the
control will jump in the middle of the sub-module.
 Structure Charts
Loop - A curved arrow represents loop in the module. All sub-modules
covered by loop repeat execution of module.
 Structure Charts
Data flow - A directed arrow with empty circle at the end represents data
flow.

Control flow - A directed arrow with filled circle at the end represents control
flow.
 Entity-Relationship Model
Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of
real world entities and relationship among them. We can map real world
scenario onto ER database model. ER Model creates a set of entities with their
attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be
represented as follows.
 Entity-Relationship Model
Entity-Relationship Model
Entity - An entity in ER Model is a real world being, which has some properties
called attributes. Every attribute is defined by its corresponding set of values,
called domain.
For example, Consider a school database. Here, a student is an entity. Student
has various attributes like name, id, age and class etc.
Relationship - The logical association among entities is called relationship.
Relationships are mapped with entities in various ways. Mapping cardinalities
define the number of associations between two entities.
Mapping cardinalities:
• one to one
• one to many
• many to one
• many to many
 Data Dictionary
Data dictionary is the centralized collection of information about data. It
stores meaning and origin of data, its relationship with other data, data
format for usage etc. Data dictionary has rigorous definitions of all names in
order to facilitate user and software designers.
Data dictionary is often referenced as meta-data (data about data) repository.
It is created along with DFD (Data Flow Diagram) model of software program
and is expected to be updated whenever DFD is changed or updated
Data dictionary should contain information about the following
Data Flow
Data Structure
Data Elements
Data Stores
Data Processing
 Decision Tables
A Decision table represents conditions and the respective actions to be taken
to address them, in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar
information into a single table and then by combining tables it delivers easy
and convenient decision-making.
Creating Decision Table
To create the decision table, the developer must follow basic four steps:
Identify all possible conditions to be addressed,
Determine actions for all identified conditions,
Create Maximum possible rules,
Define action for each rule.
 Software Design Approaches
There are two generic approaches for software designing:
Top Down Design
We know that a system is composed of more than one sub-systems and it contains a
number of components. Further, these sub-systems and components may have their
on set of sub-system and components and creates hierarchical structure in the
system.
Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based on some
characteristics. Each sub-system or component is then treated as a system and
decomposed further. This process keeps on running until the lowest level of system in
the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the
more specific part of it. When all components are composed the whole system
comes into existence.
Top-down design is more suitable when the software solution needs to be designed
from scratch and specific details are unknown.
 Software Design Approaches
Bottom-up Design
The bottom up design model starts with most specific and basic components.
It proceeds with composing higher level of components by using basic or
lower level components. It keeps creating higher level components until the
desired system is not evolved as one single component. With each higher
level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from
some existing system, where the basic primitives can be used in the newer
system.
Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination of both is used.
 Principles for software design:
• The design process should not suffer from "tunnel vision." A good designer should
consider alternative approaches, judging each based on the requirements of the problem,
the resources available to do the job.
• The design should be traceable to the analysis model. Because a single element of the
design model can often be traced back to multiple requirements, it is necessary to have a
means for tracking how requirements have been satisfied by the design model.
• The design should not reinvent the wheel. Systems are constructed using a set of design
patterns, many of which have likely been encountered before. These patterns should
always be chosen as an alternative to reinvention. Time is short and resources are limited;
design time should be invested in representing (truly new) ideas by integrating patterns
that already exist (when applicable).
• The design should "minimize the intellectual distance" between the software and the
problem as it exists in the real world. That is, the structure of the software design should,
whenever possible, mimic the structure of the problem domain.
• The design should be structured to accommodate change. The design concepts discussed
in the next section enable a design to achieve this principle.
 Principles for software design:
• The design should exhibit uniformity and integration. A design is uniform if it appears
fully coherent. In order to achieve this outcome, rules of style and format should be
defined for a design team before design work begins. A design is integrated if care is taken
in defining interfaces between design components.
• The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. Well-designed software should never "bomb"; it
should be designed to accommodate unusual circumstances, and if it must terminate
processing, it should do so in a graceful manner.
• Design is not coding, coding is not design. Even when detailed procedural designs are
created for program components, the level of abstraction of the design model is higher
than the source code. The only design decisions made at the coding level should address
the small implementation details that enable the procedural design to be coded.
• The design should be assessed for quality as it is being created, not after the fact. A
variety of design concepts and design measures are available to assist the designer in
assessing quality throughout the development process.
• The design should be reviewed to minimize conceptual (semantic) errors. There is
sometimes a tendency to focus on minutiae when the design is reviewed, missing the
forest for the trees. A design team should ensure that major conceptual elements of the
design (omissions, ambiguity, and inconsistency) have been addressed before worrying
about the syntax of the design model.
 Architectural Concepts
The architecture of a system describes its major components, their
relationships (structures), and how they interact with each other. Software
architecture and design includes several contributory factors such as Business
strategy, quality attributes, human dynamics, design, and IT environment.
 Architectural Concepts
Software Architecture
Architecture serves as a blueprint for a system. It provides an abstraction to manage
the system complexity and establish a communication and coordination mechanism
among components.
Defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance and
security.
It involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the final product. These
decisions comprise of −
Selection of structural elements and their interfaces by which the system is
composed.
Behavior as specified in collaborations among those elements.
Composition of these structural and behavioral elements into a large subsystem.
 Software Architecture
• Architectural decisions align with business objectives.
• Architectural styles guide the organization.
• A software architecture must describe its group of components, their connections,
interactions among them and deployment configuration of all components.
• A software architecture can be defined in many ways −
 UML (Unified Modeling Language) − UML is one of object-oriented solutions used
in software modeling and design.
 Architecture View Model (4+1 view model) − Architecture view model represents
the functional and non-functional requirements of software application.
 ADL (Architecture Description Language) − ADL defines the software architecture
formally and semantically.
 Software Architecture
UML
UML stands for Unified Modelling Language. It is a pictorial language used to make
software blueprints. UML was created by the Object Management Group (OMG). The
UML 1.0 specification draft was proposed to the OMG in January 1997. It serves as a
standard for software requirement analysis and design documents which are the
basis for developing a software.
UML can be described as a general purpose visual modelling language to visualize,
specify, construct, and document a software system. Although UML is generally used
to model software systems, it is not limited within this boundary. It is also used to
model non software systems such as process flows in a manufacturing unit.
The elements are like components which can be associated in different ways to make
a complete UML picture, which is known as a diagram. So, it is very important to
understand the different diagrams to implement the knowledge in real-life systems
 Software Architecture
UML
Structural Diagrams
• Structural diagrams represent the static aspects of a system. These static aspects
represent those parts of a diagram which forms the main structure and is
therefore stable.
• These static parts are represented by classes, interfaces, objects, components and
nodes. Structural diagrams can be sub-divided as follows −
• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
• Package diagram
• Composite structure
 Software Architecture
The following table provides a brief description of these diagrams −
 Software Architecture
Behavioral Diagrams:
• Behavioral diagrams basically capture the dynamic aspect of a system.
Dynamic aspects are basically the changing/moving parts of a system. UML
has the following types of behavioral diagrams −
• Use case diagram
• Sequence diagram
• Communication diagram
• State chart diagram
• Activity diagram
• Interaction overview
• Time sequence diagram
 Software Architecture
Diagram and Description
 4+1 View Model

• The 4+1 View Model was designed by Philippe Kruchten to describe

the architecture of a software–intensive system based on the use of
multiple and concurrent views. It is a multiple view model that
addresses different features and concerns of the system. It
standardizes the software design documents and makes the design
easy to understand by all stakeholders.
• It is an architecture verification method for studying and
documenting software architecture design and covers all the aspects
of software architecture for all stakeholders. It provides four essential
views
 4+1 View Model

• The logical view or conceptual view − It describes the object model

of the design.
• The process view − It describes the activities of the system, captures
the concurrency and synchronization aspects of the design.
• The physical view − It describes the mapping of software onto
hardware and reflects its distributed aspect.
• The development view − It describes the static organization or
structure of the software in its development of environment.
4+1 View Model