Chapter one

lecture one
Introduction to software design

Software Architecture and Design (SEng3132)

By Destaye A.

1 1
 Software architecture, definition
➢ Software architecture refers to the fundamental
structures of a software system or product that
developers use as an overarching visual guide
when planning for and building software,
➢ Software architecture is a conceptual framework
defining the system's high-level
structure, components and relationships
➢ It serves as a blueprint for both the system and
the project developing, it providing a foundation
for both technical and organizational decisions.
 Con…
➢The architecture of a software system defines the
system in terms of computational components
and interactions among those components.
(from Shaw and Garlan, Software Architecture,
Perspectives on an Emerging Discipline,
Prentice-Hall, 1996.)
➢Component-based architecture focuses on the
decomposition of the design into individual
functional or logical components that represent
well-defined,
 Con…
➢Software architecture is, simply the
organization of a system. This organization
includes all components, how they interact
with each other,
➢The behavior and structure of the software
impact significant decisions, so they need to
be appropriately built for the best possible
software results.
 Key Components of Software Architecture

➢ Components: The individual parts of the system, which can

be modules, classes, services etc. Each component
encapsulates specific functionality.
➢ Relationships: How components interact with each other
including data flow, control flow and communication
protocols.
➢ Patterns: Common architectural patterns (e.g. MVC, micro
services, layered architecture etc. ) that provide templates for
solving recurring design problems.
➢ Constraints: Rules and limitations that affect the architecture
such as regulatory compliance performance requirements or
technological restrictions.
➢ Quality Attributes: Non-functional requirements that define
how the system performs under certain conditions including
scalability, reliability, maintainability and security
 ARC…in SWE
➢ Software architecture in software engineering helps
to expose the structure of a system while hiding
some implementation details. Architecture focuses
on relationships and how the elements and
components interact with each other, as does
software engineering. Software Architecture has
role to reduce software project failure rate by:
✓ Tackling complexity of software development and
✓ Enabling achievement of quality requirements
 Con…
Architecture is a Set of Software Structures:
1.Modules – divides up system functionality assigned specific
computational responsibilities, are the basis of work
assignments for programming team

2. Component-and-connector (C&C)
➢ dynamic structures
➢ how elements interact with each other at runtime
➢ processes, objects, clients, servers, and data store
➢ pathways of interaction, such as communication links and
protocols, information
➢ flows, and access to shared storage.
 Con…
3. Allocation structures

➢ Allocation structures embody decisions as to how

the system will relate to non software structures in its
environment (such as CPUs, file systems, networks,
development teams, etc.)

➢ mapping from software structures to the system’s

organizational, developmental, installation, and
execution environments Deployment, Implementation
 Architecture vs. Design
• Software architecture: is a plan that gives enough
detail to produce a software design.
• Architecture constrains designs to achieve an
organization's business and technology strategy.
• Software architecture places big-picture constraints
on the design to ensure that it aligns with the
business and technology strategy of an
organization.
 Cont..
Software design: It is the process of determining
how a system will perform its intended functions,
• Software design is defined as a process of problem
solving and planning for a software solution. The
first step for software design is to define the aim
and characteristics of the software. This includes
specifications of services, components,
integrations, data models and algorithms.
 Con…
➢Software design is a process to transform user
requirements into some suitable form which
helps the programmer in software coding and
implementation,
➢ how the software system is decomposed and
organized into components and modules. It
defines the relationship between these
modules.
 Goals of Software Architecture
➢ Expose the structure of the system, but hide its implementation
details.
➢ Realize all the use-cases and scenarios.
➢ Try to address the requirements of various stakeholders.
➢ Handle both functional and quality requirements.
➢ Reduce the goal of ownership and improve the organization’s
market position.
➢ Improve quality and functionality offered by the system.
➢ Improve external confidence in either the organization or system.
Software Arc VS software Design
The Many Contexts of Software Architecture

Business Context
Architectures serve some business purposes
• Architects need to understand who the vested organizations are and
what their goals are
• Many of these goals will have a profound influence on the architecture.
• lowering costs might be realized by asking employees to work from home,
or turn the office thermostats down in the winter, or using less paper in
the printers.
• Professional Context
• You will perform many duties beyond directly producing an architecture.
• Architects need more than just technical skills.
• Explaining, diplomatic, negotiation, and communication skills.
• Architects need up-to-date knowledge: You will need to know about (for
example) patterns, or database platforms, or web services standards.
 Stakeholders

➢ a person or organization that has rights, shares, claims, or

interests concerning the system or its properties meeting
their needs and expectations.
➢ To put it more simply, the interests of stakeholders have some
influence on the software project
 Why Is Software Architecture Important?

Predicting system qualities

• Predicting system qualities is possible as we
know that certain kinds of architectural
decisions lead to certain QAs in a system,
• The earlier you can find a problem in your
design, the cheaper, easier, and less disruptive
it will be to fix ,
 Con …
Enhancing communication among stakeholders
Every stakeholder has different concerns;
• Architecture can be used as a basis for mutual
understanding, negotiation and
communication among stakeholders.
• Abstract Architecture can be understood by
most nontechnical people,
 Con..
Improving cost and schedule estimates
Architect helps to create cost and schedule
estimates early in the project life cycle
• Top-down estimates (created by the architect
and project manager) are useful for setting goals
and apportioning budgets.
• Bottom-up cost estimations are more accurate
than purely top-down system knowledge (created
by the developers).
 Con…
Basis for Training
• The architecture can serve as the first
introduction to the system for new project
members.
• Module views show the structure
• C&C - explaining how the system work .
 Software quality
• The notion of quality is central in software architecting: software
architecture is devised to gain insight in the qualities of a system at the
earliest possible stage. Qualities are two types.
Static quality attributes
• Reflect the structure of a system and organization, directly related
to architecture, design, and source code. They are invisible to end-
user, but affect the development and maintenance cost, e.g.:
modularity, testability, maintainability, portability, etc.
Dynamic Quality Attributes
• Reflect the behavior of the system during its execution. They are
directly related to system’s architecture, design, source code,
configuration, deployment parameters, environment, and platform.
• They are visible to the end-user and exist at runtime, e.g.
performance, security, functionality, throughput, robustness,
scalability, etc.
 Role of Software Architect

• Excellent software engineering skills

• Lead technical development team by example
• Solve the hard problems
• Understand impact of decisions
• Defend architectural design decisions
• Know and understand relevant technology
• Track technology development

21 21
 Design
• Definition:
– Design is a problem-solving process whose objective is to find
and describe a way:
• To implement the system’s functional requirements while
respecting the constraints imposed by the quality and
budget.”

22
 Design as a series of decisions
• A designer is faced with a series of design issues
– Each issue normally has several alternative solutions:
• design options.
– The designer makes a design decision to resolve each issue.
• This process involves choosing the best option from among the
alternatives.
• Making decisions-To make each design decision, the software
engineer uses: Knowledge of
• the requirements
• the design as created
• the technology available
• software design principles

23
 Objective of software design
• Software design is both a process and a model.
• The design process is a sequence of steps that enable the
designer to describe all aspects of the software to be
built. The objectives are to:
– Identify different types of software, based on the
usage.
– Show differences between design and coding.
– Illustrate some basic design concepts.
– See how to design for testability and maintainability.
– Introduce some formal design notations.
 Software Design Activities
• These activities can vary depending on the type of the
system/software needs to be developed.
• There are four main activities that may be part of the design
process, these are:
1. Architectural design: It defines the overall structure of the
system, the main components and their relationships.
2. Database design: The system data structures are designed and
their representation in a database is defined. This depends on
whether an existing database is to be reused or a new database to
be created.
 Cont..
2. Interface design: It defines the interfaces between these
components. The interface specification must be clear. Therefore,
a component can be used without having to know it’s
implemented.

Once the interface specification are agreed, the components can

be designed and developed concurrently.

4. Component design: Take each component and design how it

will operate, with the specific design left to the programmer, or a
list of changes to be made to a reusable component.
 Principles Leading to Good Design

• Overall goals of good design:

– Increasing profit by reducing cost
– Ensuring that we actually conform with the requirements
– Accelerating development
– Increasing qualities such as
• Changeability
• Extensibility
• Reusability

27
 Changeability

Existing requirements change and new ones are added.

• To reduce maintenance costs and the workload involved in

changing an application, it is important to prepare its architecture
for modification and evolution.

• Two reasons why software ages:

• Lack of movement-software ages if it is not frequently updated.

• Ignorant surgery-changes made by people who do not understand the

original design, gradually destroy the architecture.

28
 Extensibility

• This focuses on the extension of a software system with

new features, as well as the replacement of components
with improved versions and the removal of unwanted or
unnecessary features and components.

• To achieve extensibility a software system requires

loosely-coupled components.

29
 Reusability
• It promises a reduction of both cost and development time for
software systems, as well as better software quality.
• Reusability has two major aspects-software development with
reuse and software development for reuse:
• Software development with reuse means reusing existing
components and results from previous projects or
commercial libraries or code components.
• Software development for reuse focuses on producing
components that are potentially reusable in future projects as
part of the current software development.
30
 Design Principle 1: Divide and conquer
• Trying to deal with something big all at once is normally much
harder than dealing with a series of smaller things
– Separate people can work on each part.
– An individual software engineer can specialize.
– Each individual component is smaller, and therefore easier to
understand.
– Parts can be replaced or changed without having to replace or
extensively change other parts.

31
 dividing a software system
– A distributed system is divided up into clients and servers

– A system is divided up into subsystems

– A subsystem can be divided up into one or more packages

– A package is divided up into classes

– A class is divided up into methods

32
 Con…
• Coupling and Cohesion are two key concepts in
software engineering that are used to measure
the quality of a software system’s design.
• Both are important factors in determining the
maintainability, scalability, and reliability of a
software system.
• High coupling and low cohesion can make a
system difficult to change and test, while low
coupling and high cohesion make a system easier
to maintain and improve.
 Design Principle 2: Increase cohesion where
possible
• Cohesion:- is a measure of the degree to which the elements of
the module are functionally related.
• Measure of how well module fits together. A component should
implement a single logical function or single logical entity.
• A subsystem or module has high cohesion if it keeps together
things that are related to each other, and keeps out other things
– This makes the system as a whole easier to understand and change
– Type of cohesion:
• Functional, Layer, Communicational, Sequential Cohesion, Temporal
Cohesion, Procedural cohesion, Logical cohesion

34
 Functional cohesion
• This is achieved when all the code that computes a particular
result is kept together - and everything else is kept out
– i.e. when a module only performs a single computation, and returns a
result, without having side-effects.
– Benefits to the system:
• Easier to understand
• More reusable
• Easier to replace
– Modules that update a database, create a new file or interact with the
user are not functionally cohesive

35
 Layer (Sequential) cohesion
• All the facilities for providing or accessing a set of related services
are kept together, and everything else is kept out
– The layers should form a hierarchy
• Higher layers can access services of lower layers,
• Lower layers do not access higher layers
– The set of procedures through which a layer provides its services is the
application programming interface (API)
– You can replace a layer without having any impact on the other layers
• You just replicate the API

36
Example of the use of layers

37
 Communicational cohesion
• All the methods that access or manipulate certain data are kept
together (e.g. in the same class) - and everything else is kept out
– A class would have good communicational cohesion
• if all the system’s facilities for storing and manipulating its data are
contained in this class.
– Main advantage: When you need to make changes to the
data, you find all the code in one place
– Example- Student Manager class (insert, update, delete,
search etc.)

38
 Utility cohesion
• When related utilities which cannot be logically placed in other
cohesive units are kept together
– A utility is a procedure or class that has wide applicability to
many different subsystems and is designed to be reusable.
Procedural Cohesion
• Elements of procedural cohesion ensure the order of execution.
• Actions are still weakly connected and unlikely to be reusable.
Ex- calculate student GPA, print student record, calculate cumulative
GPA, print cumulative GPA.

39
 Design Principle 3: Reduce coupling where
possible
• Coupling:- The degree of dependence such as the amount of
interactions among components
• Coupling occurs when there are interdependencies between one
module and another
– When interdependencies exist, changes in one place will
require changes somewhere else.
– A network of interdependencies makes it hard to see at a
glance how some component works.
– Type of coupling:
• Common, Control, Data, Stamp,
External and content coupling

40
 Data Coupling

• If the dependency between the modules is based on

the fact that they communicate by passing only data,
then the modules are said to be data coupled.

• In data coupling, the components are independent to

each other and communicating through data.
 Common coupling
• The modules have shared data such as global data structures.
Occurs whenever you use a global variable
– All the components using the global variable become coupled
to each other
– can be acceptable for creating global variables that represent
system-wide default values
– The best way is declare all the global variables in an interface
and use them through interface
– The Singleton pattern provides encapsulated global access to
an object

42
 Control coupling
• If the modules communicate by passing control information, then
they are said to be control coupled.
• It can be bad if parameters indicate completely different
behavior, and good if parameters allow factoring and reuse of
functionality. Example- sort function that takes comparison
function as an argument
• Occurs when one procedure calls another that explicitly controls
what the second procedure does
– To make a change you have to change both the calling and
called method
– The use of polymorphic operations is normally the best way
to avoid control coupling
– One way to reduce the control coupling could be to have a
look-up table
43
 Routine call coupling
• Occurs when one routine (or method in an object
oriented system) calls another
– The routines are coupled because they depend on each
other’s behaviour
– Routine call coupling is always present in any system.
– If you repetitively use a sequence of two or more methods to
compute something

44
 External Coupling

• In external coupling, the modules depend on

other modules, external to the software being
developed or to a particular type of hardware.
• Ex- protocol, external file, device format, etc.
Design Principle 4: Keep the level of abstraction as high
as possible

• Ensure that your designs allow you to hide or defer consideration

of details, thus reducing complexity

– A good abstraction is said to provide information hiding

– Abstractions allow you to understand the essence of a

subsystem without having to know unnecessary details

46
 Abstraction and classes

• Classes are data abstractions that contain procedural

abstractions
– Abstraction is increased by defining all variables as private.
– The fewer public methods in a class, the better the
abstraction
– abstract classes and interfaces increase the level of
abstraction

47
 Design Principle 5: Increase reusability where
possible (for reuse)
• Design the various aspects of your system so that they can be
used again in other contexts
– Generalize your design as much as possible

48
Design Principle 6: Reuse existing designs and code where
possible(with reuse)
• Design with reuse is complementary to design for reusability
– Actively reusing designs or code allows you to take advantage
of the investment you or others have made in reusable
components.

49
 Design Principle 7: Design for flexibility
• Actively anticipate changes that a design may have to undergo in
the future, and prepare for them
– Reduce coupling and increase cohesion
– Create abstractions
– Do not hard-code anything
– Use reusable code and make code reusable

50
 Design Principle 8: Anticipate obsolescence
• Plan for changes in the technology or environment so the
software will continue to run or can be easily changed
– Avoid using early releases of technology
– Avoid using software libraries that are specific to particular
environments
– Use standard languages and technologies that are supported
by multiple vendors

51
 Design Principle 9: Design for Portability
• Have the software run on as many platforms as possible
– Avoid the use of facilities that are specific to one particular
environment
– E.g. a library only available in Microsoft Windows

52
 Design Principle 10: Design for Testability
• Take steps to make testing easier
– Design a program to automatically test the software
• Ensure that all the functionality of the code can be driven by an
external program, bypassing a graphical user interface.

53
 User Interface Design
• User Interface Design is the discipline of designing
software interfaces for devices, ideally with a focus on
maximizing efficiency, responsiveness to foster a good
user experience.
• UI design is typically employed for products or services
that require interaction for the user to get what they
need from the experience.
• The interface should allow a user to perform any required
tasks to complete the function of the product or service.
• An interface is a point of interaction between the user
and the hardware and/or software they are using.
• UI design is the skill employed to visualize the interface
used to complete the task it is designed for.
• Good UI design facilitates making the completion of tasks
as frictionless as possible and increasing usability.
 Cont..
• UI can be graphical, text-based, audio-video
based, depending upon the underlying
hardware and software combination. UI can
be hardware or software or a combination of
both.
• The software becomes more popular if its user
interface is:
– Attractive
– Simple to use
– Responsive in short time
– Clear to understand
– Consistent on all interfacing screens