Software Design and

Architecture

Lecture 2
Topics

 Architecture Styles
 Architectural Design Decisions
 Quality Attributes
 Design Guidelines
Architecture Styles
Basic Architectural representations
 Simple, informal block diagrams showing entities and relationships are
the most frequently used method for documenting software
architectures.

 But these have been criticized because they lack semantics, do not
show the types of relationships between entities nor the visible
properties of entities in the architecture.
Box and Line Diagrams
 Shows what an architecture design typically looks like

 Very abstract - they do not show the nature of component relationships

nor the externally visible properties of the sub-systems.

 However, useful for communication with stakeholders and for project

planning.
Box and Line Diagrams
 This division of elements is based on their functionality, location, and
runtime images.

 The topology of the static structure focuses on the system composition

configuration such as layered, flattened, star-typed, centralized, or
distributed.
Use of architectural models
 A complete software architecture specification must describe not only
the elements and connectors between elements, but also the constraints
and runtime behaviors so that developers know what and how the
design should be implemented.
The following lists a software architect's tasks:
 Perform static partition and decomposition of a system into
subsystems and communications among subsystems.
 A software element can be configured, delivered, developed, and
deployed, and is replaceable in the future.
 Each element's interface captures details and provides coupling with
other elements or subsystems.
 Establish dynamic control relationships among different subsystems in
terms of data flow, control flow, or message dispatching.
 Consider and evaluate alternative architecture styles that suit the
problem domain at hand.
Architectural Design Decisions
Architectural Design Decisions
 Architectural design is a creative process so the process differs
depending on the type of system being developed.
 However, a number of common decisions span all design processes
and these decisions affect the non-functional characteristics of the
system.
Architectural Design Decisions

 Is there a generic application architecture that can be used?

 How will the system be distributed?
 What architectural styles / models are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?
Architectural Design Decisions

Architecture Reuse
 Systems in the same domain often have similar architectures that
reflect domain concepts.
 Application product lines are built around a core architecture with
variants that satisfy particular customer requirements.
Architectural Views
 Each architectural model only shows one view or perspective of the
system.
 It might show how a system is decomposed into modules, or how the
run-time processes interact or the different ways in which system
components are distributed across a network.
 For both design and documentation, you usually need to present
multiple views of the software architecture.
Architectural Design Decisions

1+4 view model

 A logical view, which shows the key abstractions in the system as
objects or object classes.
 A process view, which shows how, at run-time, the system is
composed of interacting processes.
 A development view, which shows how the software is decomposed
for development.
 A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.
Quality Attributes
Good Design

What can be achieved with a good design?

Efficiency
 Efficiency refers to the responsiveness of the system,

 i.e. the time required to respond to stimuli (events),

 or the number of events processed in some interval of time.

 The time to process a sequence of events can be divided into three

parts.
 First, time is needed to communicate between different software
components that collaborate to process an event.
 Second, the computation times that components executed may
have overlaps or gaps between them.
 Third, the times are needed for each component to complete its
computation.
Good Design

Correctness
 Correctness is the property that software implements the specified
users’ requirements.

 It is impossible that a design at any level that does not correctly

implement the specified requirements would lead to a correct
implementation.

Reliability
 Reliability can be defined as the probability that a system performs
user required functionality correctly
 at a specified environment in a given period of time.
Good Design

Portability
 Portability is the property of a software system that can be easily
transported from one hardware/software platform to another,

Maintainability
 Maintainability refers to the easiness of maintaining a software
system.
 There are two types of software maintenance operations.

 corrective maintenance.

 adaptive maintenance.

 Well-structured design helps software engineers to understand the

system.
Good Design

Reusability
 Reusability is the property of a software system that its components
can be easily reused in the development of other software systems.
 Reusability depends on the generality of the components in a given
application domain and the extent to which the components are
parameterized and configurable.
Interoperability
 Interoperability is the property of how easy a software system can be
used with other software systems.
 Interoperability mostly depends on the interface between a software
system and its environment.
Quality Attributes of SW Design

Quality Attributes – Design Objectives

 Modularity:

 The design should be composed of replaceable, self-contained

assemblies of elementary parts,
 thereby aiding both the initial development and the later
maintenance.

 Portability:
 The designed product should be able to be moved unchanged

 from test environments to operational environments and

 from one operational environment to another.

Quality Attributes of SW Design

 Flexibility:
 The design should facilitate adaptation to changing end-user
requirements,
 changes based on new problems in the end users’ world

 Conceptual integrity:
 The design should exhibit harmony, symmetry and predictability.

 Well structured:
 The design should be consistent with chosen design principles,
such as information hiding, to organize the structure of the design.
Quality Attributes of SW Design

 Simple:
 The design should be ‘as simple as possible, but no simpler’.

 Efficient:
 The functions provided by the design should be computable by
using the available resources.

 Adequate:
 The design should meet the stated requirements.
Quality Attributes of SW Design
 Implementable:
 The functions offered by the design should be theoretically
computable with the information available and achievable using
currently available software and hardware technology.

 Standardized:
 The design should be represented using standard or well defined
and familiar notation for any documentation.

 Reliability:
 The designed development process should with high probability be
successful rather than fail to achieve its goal.
Design Guidelines
Software Design Principles

 Always consider alternative approaches

 The design should be traceable to the analysis model

 The design should not reinvent the wheel

 The design should minimise intellectual distance between the software

and the problem as it exists in the real world.
Software Design Principles
 The design should exhibit uniformity and integration
 A design is uniform if it appears that one person developed the
whole thing.
 A design is integrated if care is taken in defining interfaces
between design components.

 The design should be reviewed to minimize conceptual (semantic)

errors

 Design is not coding, coding is not design

 Even when detailed designs are created for program components,
the level of abstraction of the design model is higher than source
code.

 The design should be structured to accommodate change

 The design should be assessed for quality as it is being created

Design Guidelines
Think of what to do before thinking of how to do it.
 Functional and nonfunctional requirements should be identified,
verified, and validated before architecture and detailed design work is
done.

Think of abstract design before thinking of concrete design.

 Always start with an abstract design that specifies interfaces of
components.
 Use multiple levels of abstraction if necessary.
 Make implementation decisions based on the abstract interfaces
instead of the concrete ones because those are more stable—they are
the contracts between service providers and service requesters, so they
are defined at the early stages of the software development cycle.
Design Guidelines
Think of nonfunctional requirements early in the design process.
 When you map functional requirements to an architecture design, you
should consider nonfunctional requirements as well.
 Communicate with stakeholders and document their preferences for
quality attributes.
 If it is not possible to find a design that meets all quality attributes, try
to find the right balance of quality attributes and consider
heterogeneous architecture styles when necessary.

Think of software reusability and extensibility as much as possible.

 For most software systems, it is likely that new functionalities will be
added after the systems are deployed.

Try to promote high cohesion within each element and loose coupling
between elements.
 A highly coherent subsystem, component, or module performs one
sole function. You must consider cohesion factors during the very
early stages of the design process. Low cohesion of a system implies
that functional composition is not designed well.
Design Guidelines

Tolerate refinement of design.

 Never expect to have software design completely perfect in one step.
You may need to use prototyping and iteration to refine the design.

Avoid ambiguous design and over-detailed design.

 Ambiguous design lacks constraints and over-detailed design restricts
implementation