Software Engineering (3150711)

Unit-3
Software Design concepts
& Architectural Design
What is Design?
A meaningful representation of something to be built
It's a process by which requirements are translated into blueprint for constructing a
software
Blueprint gives us the holistic view (entire view) of a software

Design Software
SR Process Design
S
Problem Solution
Domain Domain
Software Design Process? Software design is the most creative part of the development process

Requiremen Analysi Design Desig

t s Engineerin n
Engineering Model g Model

Blue Print for Process involves

Constructing Diversification &
Software Convergence
Software design work products Characteristics of good
For a design to be easily implemented in a Design
The design must implement all explicit
conventional programming language, the following requirements available in requirement
items must be designed during the design phase. model
Different modules required to implement the design The design must accommodate all
solution. implicit requirements given by
stakeholders
Control relationship among the identified
modules. The relationship is also known as the call
The design must be readable &
relationship or invocation relationship among understandable
modules. The good design should provide
Interface among different modules. The interface
complete picture of the software,
among different modules identifies the exact data
addressing the data, functional and
items exchanged among the modules.
behavioral domains.
Algorithms required to implement each individual
module.
Data structures of the individual modules.
Design Models It is creative activity. It is most critical activity during system development

Analysis Models Has great impact on testing and maintenance

Scenario-based elements Design document forms reference for later
• Use cases - text
• Use-case diagrams phases
• Activity diagrams
• Swimlane diagrams

Flow-oriented elements
• Data flow diagrams
• Control-flow diagrams Procedura
• Processing narratives l Procedural description of Software components
Behavioral elements Design
• State diagrams Interface Human computer
interaction
• Sequence diagrams Design
Architectural Relationship among structural elements
Class-based elements Design
• Class diagrams Data/Class Data
• Analysis packages Structure
Design
• CRC models
• Collabortion diagrams
Design Models Cont.
Data Design Architectural Interface Design Procedural
Design Design

It transforms
structural
It transforms class It defines the It defines how elements of
models into design relationship software software into
class realization between major communicates with procedural
and prepares data structural systems & with description of
structure (data elements of the humans. An software
design) required to software interface implies components
implement the flow of information
software. & behavior.
Gentle overview of – F U R P S
“Quality is not an act, it is a habit.”— Aristotle
Quality attributes of software design The FURPS quality
attributes

F Functionality U Usability
assessed by feature set and capabilities of the assessed by considering human factors,
program, generality of the functions & overall aesthetics, consistency &
security of overall system documentations

R Reliability P Performance
assessed by measuring frequency & severity measured by processing speed, response
of failures, accuracy of outputs, time, resource consumption, throughput
mean-time-of-failure (MTTF), ability to and efficiency
recover from errors
S Supportabilit
y to extend program, adaptability, serviceability, testability, compatibility
Ability
Design Concepts
The beginning of wisdom for a software engineer is to recognize the difference between
getting program to work and getting it right

Fundamental Each design concept helps to answer the following questions

software design
concepts provide 1. What criteria can be used to partition software into individual
the necessary components?
framework 2. How is function or data structure detail separated from a
for conceptual representation of the software?
“getting it right.” 3. What uniform criteria define the technical quality of a software
design?
Important Software Design Concepts
Abstraction Architecture Pattern
Separation of Concern Modularity Information Hiding
Refactoring Refinement Aspects
Functional Independence

Abstraction
At the highest level of abstraction, a solution is stated in broad terms using the language of
the problem environment. At lower levels of abstraction, a more detailed description of
the solution is provided. Finally, at the lowest level of abstraction, the solution is stated in
a manner that can be directly implemented.
Creation of procedural and data abstractions are done.
A procedural abstraction refers to a sequence of instructions that have a specific and
limited function. A data abstraction is a named collection of data that describes a data
object.
 Design Principles
Design process should not suffer from “tunnel vision” Design should be structured to degrade
gently, even when abnormal data, events,
Design should be traceable to the analysis model or operating conditions are encountered
Design should not reinvent the wheel Design is not coding, coding is not design
Design should “minimize the intellectual distance”
Design should be assessed for quality as it
between the software and the real world problem
is being created, not after the fact
Design should exhibit (present) uniformity and
integration Design should be reviewed to minimize
Design should be structured to accommodate change conceptual (semantic) errors

Reinvent the
Tunnel
Vision

Wheel
Coding Design
Design Process Rough View
Informal Design Informal Design More formal Finished Design
Outline Design

Design Process
Requirements
Specification Design Activities
Architectural Abstract Interface Component Data Structure Algorith
Design Specification Design Design Design m
Design

System Software Interface Component Data Structure Algorithm

Architecture Specification Specification Specification Specification Specification

Design Product
Architectural Design
Software Architecture & Design
Large systems are decomposed into subsystems
Sub-systems provide related services
Initial design process includes
Identifying sub-systems
Establishing a framework for sub-system control and communication

Why to document the

Architecture?
Stakeholder Communication: High-level presentation of system
System Analysis: Big effect on performance, reliability,
maintainability and other –ilities (Usability, Maintainability,
Scalability, Reliability, Extensibility, Security, Portability)
Large-scale Reuse: Similar requirements similar architecture
Software Architecture & Design
Architectural design represents the structure of data and
program components

It
Architectural style that theconsiders
system will take
Structure and properties of the components that constitute the
system
Interrelationships that occur among all architectural components of a system

Representations of software architecture are an enabler

for communication between all parties (stakeholders).
Architecture “constitutes a relatively small, intellectually
graspable model of how the system is structured and
how its components work together”
Architectural Styles
Each style describes a system category that encompasses
Data-centered architecture style
Data-flow architectures A set of components (Ex., a database, computational
modules) that perform a function required by a
Call and return architecture system.
Object-oriented architecture A set of connectors that enable “communication,
coordination and cooperation” among components.
Layered architecture
Constraints that define how components can be
integrated to form the system.

Semantic models that enable a designer to

understand the overall properties of a system.
Data-centered architecture style
A data store (Ex., a file or database)
resides at the center of this
architecture and is accessed frequently
by other components.
Client software accesses a central
repository.
In some cases the data repository is
passive
That is, client software accesses the data
independent of any changes to the data or the
actions of other client software.
Data-flow architectures
This architecture is applied when
input data are to be transformed.
A set of components (called filters)
connected by pipes that transmit
data from one component to the
next.
Each filter works independently of
those components upstream and
downstream, is designed to
expect data input of a certain form, and
produces data output (to the next filter)
of a specified form.
Call and return architecture
This architectural style enables a
software designer (system architect)
to achieve a program structure that
is relatively easy to modify and scale.
A number of sub styles exist within
this category as below.
1. Main program/subprogram
architectures
▪ This classic program structure
decomposes function into a control
hierarchy where a “main” program
invokes a number of program
components, which in turn may invoke
still other components.
2. Remote procedure call architectures
▪ The components of a main
program/subprogram architecture are
distributed across multiple computers
on a network.
Object-oriented architecture
The components of a system encapsulate data and the operations that must be applied to
manipulate the data.
Communication and coordination between components is accomplished via message
passing.
Message Passing
Sending and receiving information among objects through function parameters is known as
Message Passing.
Object communicates through invoking methods and sending data to them.
Objects in a system communicates with each other by using message passing.
Layered architecture
A number of different layers
are defined, each
accomplishing operations that
progressively become closer to
the machine instruction set.
At the outer layer, components
service user interface
operations.
At the inner layer, components
perform operating system
interfacing.
Intermediate layers provide
utility services and application
software functions.
Architectural Design
Representing the System in Context
At the architectural design level, a software architect uses an architectural context diagram
(ACD) to model the manner in which software interacts with entities external to its
boundaries.
Architectural Design
Representing the System in Context
Referring to the figure, systems that interoperate with the target system (the system for which
an architectural design is to be developed) are represented as
Superordinate systems—those systems that use the target system as part of some higher-level processing
scheme.
Subordinate systems—those systems that are used by the target system and provide data or processing that are
necessary to complete target system functionality.
Peer-level systems—those systems that interact on a peer-to-peer basis (i.e., information is either produced or
consumed by the peers and the target system.
Actors—entities (people, devices) that interact with the target system by producing or consuming information
that is necessary for requisite processing.
Each of these external entities communicates with the target system through an interface (the
small shaded rectangles)
Interfaces must be defined : Each of these external entities communicates with the target
system through an interface
Architectural Design
consider the home security function of the SafeHome product. The overall SafeHome product
controller and the Internet-based system are both superordinate to the security function and
The surveillance function is a peer system and uses (is used by) the home security function in
later versions of the product.
The homeowner and control
panels are actors that are both
producers and consumers of
information used/produced by
the security software.
Finally, sensors are used by the
security software and are shown
as subordinate to it.
Architectural Design
Defining Archetypes
An archetype is a class or pattern that represents a core abstraction that is critical to the design
of an architecture for the target system.
In general, a relatively small set of archetypes is required to design even relatively complex
systems.
The target system architecture is composed of these archetypes, which represent stable
elements of the architecture but may be instantiated many different ways based on the
behavior of the system
In many cases, archetypes can be derived by examining the analysis classes defined as part of
the requirements model.
Architectural Design
Defining Archetypes
Continuing the discussion of the SafeHome home security function, you might define the
following archetypes:
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 have the ability to communicate with one another.
Architectural Design
Refining the Architecture into Components
The architecture must accommodate many infrastructure components that enable application
components but have no business connection to the application domain
Continuing the SafeHome home security function example, you might define the 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.
Each of these top-level components would have to be elaborated iteratively and then
positioned within the overall SafeHome architecture
Architectural Design
Architectural Design
Describing Instantiations of the System
the architecture is applied to a specific problem with the intent of demonstrating that the
structure and components are appropriate
Components shown in Figure 9.8 are elaborated to show additional detail.
For example, the detector management component interacts with a scheduler infrastructure
component that implements polling of each sensor object used by the security system. Similar
elaboration is performed for each of the components
Architectural Design
Assessing alternative Architectural Design
The first method uses an iterative method to assess design trade-offs.
The second approach applies a pseudo-quantitative technique for assessing design quality.
An Architecture Trade-Off Analysis Method
The Software Engineering Institute (SEI) has developed an architecture trade-off analysis
method (ATAM) [Kaz98] that establishes an iterative evaluation process for software architectures.
The design analysis activities that follow are performed iteratively:
1. Collect scenarios. A set of use cases is developed to represent the system from the user’s
point of view.
2. Elicit requirements, constraints, and environment description. This information is
determined as part of requirements engineering and is used to be certain that all stakeholder
concerns have been addressed.
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:
Assessing alternative Architectural Design
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.
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.
5. Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style.
This can be accomplished by making small changes in the architecture and determining how sensitive a quality
attribute, say performance, is to the change.
Any attributes that are significantly affected by variation in the architecture are termed sensitivity points.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis
conducted in step 5.
Architectural Design
Once the architectural sensitivity points have been determined, finding trade-off points is
simply the identification of architectural elements to which multiple attributes are sensitive.
For example, the performance of a client-server architecture might be highly sensitive to the
number of servers (performance increases, within some range, by increasing the number of
servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.
Based on the results of steps 5 and 6, some architecture alternatives may be eliminated, one or
more of the remaining architectures may be modified and represented in more detail, and then
the ATAM steps are reapplied.
Architectural Design
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.
There are three types of dependencies:
Sharing dependencies represent dependence relationships among consumers who use the same
resource or producers who produce for the same consumers.
For example, for two components u and v, if u and v refer to the same global data, then there exists a
shared dependence relationship between u and v.
Flow dependencies represent dependence relationships between producers and consumers of
resources.
For example, for two components u and v, if u must complete before control flows into v (prerequisite),
or if u communicates with v by parameters, then there exists a flow dependence relationship between u and
v.
Architectural Design
Constrained dependencies represent constraints on the relative flow of control among a set of
activities.
For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion),
then there exists a constrained dependence relationship between u and v.
Architectural Description Languages
The architect of a house has a set of standardized tools and notation that allow the design to
be represented in an unambiguous, understandable fashion.
Although the software architect can draw on UML notation, other diagrammatic forms, and a
few related tools, there is a need for a more formal approach to the specification of an
architectural design.
Architectural description language (ADL) provides a semantics and syntax for describing a software
architecture.
Architectural Design
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.
Once descriptive, languagebased techniques for architectural design have been established, it
is more likely that effective assessment methods for architectures will be established as the
design evolves
Architectural Design
ARCHITECTURAL MAPPING USING DATA FLOW
To illustrate one approach to architectural mapping, consider the call and return
architecture—an extremely common structure for many types of systems.
A mapping technique, called structured design , is often characterized as a data flow-oriented
design method because it provides a convenient transition from a data flow diagram to
software architecture.
The transition from information
flow (represented as a DFD) to program structure is accomplished as part of a sixstep
process: (1) the type of information flow is established, (2) flow boundaries are
indicated, (3) the DFD is mapped into the program structure, (4) control hierarchy is
defined, (5) the resultant structure is refined using design measures and heuristics, and
(6) the architectural description is refined and elaborated.
Transform Mapping
Step 1. Review the fundamental system model.
Transform Mapping
Step 1. Review the fundamental system model.
Transform Mapping
Step 2. Review and refine data flow diagrams for the software.
Transform Mapping
Transform Mapping
Step 3. Determine whether the DFD has transform or transaction flow characteristics.
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries.
Step 5. Perform “first-level factoring.”
The program architecture derived using this mapping results in a top-down distribution of control.
Factoring leads to a program structure in which top-level components perform decision-making and
lowlevel components perform most input, computation, and output work. Middle-level components
perform some control and do moderate amounts of work.
Transform Mapping
Step 6. Perform “second-level factoring.”
A completed first-iteration architecture is shown in Figure 9.16
Transform Mapping
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality.

The refined program structure breaks the

system into more detailed, manageable
components, improving modularity and
clarity. This modular design makes it easier
to manage each function separately,
improving maintainability, scalability, and
quality of the software.
Transform Mapping
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality.