Chapter 5: Introduction to Software Design

Tadele M.
1
 Architecture vs Design
What comes first design or architecture?
 Consider the architecture of an office building as
compared with its interior design:
 The architecture provides structures such as rooms, stair
cases and basic services such as water and heating,
ventilation and air conditioning.
 A plan for the structure of something
 The interior design provides the interior materials,
decorations & art, flooring, furniture and additional
services such as coffee stations and kitchens.
 A plan to create something

 Design uses and aligns with architecture

2
 Introduction
 Software Requirements:
 state ‘what’ the software should do, but not ‘how
 can be functional and non functional
 Software Architecture:
 what, where and why but not the how
 High level view that documents the main software components
and their interaction with each other
 Is very abstract, deliberately hiding any details
 Software Design:
 is the how of a software development process
 Generally, design is about how to build a system (answers
“HOW?”)- Specifying different parts of the software, and how
they will fit together.
3
 Cont…
 From a project management point of view, software design can be
conducted in two main steps:
 Preliminary Design: Concerned with the transformation of
requirements into data and software architecture which
serve as the basis for the final design.
 Detailed Design: Focuses on refining the architectural
representation, and lead to detailed data structure and
algorithmic representations of software.

4
 Cont…
 To develop a complete specification of design (design model), four design models
are needed:
 Architectural/System Design: identify the overall structure of the system, the principal
components (sometimes called sub-systems or modules), their relationships and how
they are distributed.

5
Architecture described using a package diagram
 Cont…

 Interface design: depicts how the software communicates

with the system that interoperates with it and with the end-
users

Interfaces
6
 Cont…
 Procedural/Component Design:
transforms structural components into
a procedural/component description of
the software.
 It provides the detailed description
of how structural elements of
software will actually be
implemented using programming
language or intermediate design
notation such as graphical (DFD,
flowchart), tabular (decision
table).

Components

7
 Cont…
 Data Design /Class Design: is the first design activity, which results in less complex, modular and
efficient program structure. Eg: Entity Relationship diagrams, data dictionary, abstract data types
and data structures.
 The information domain model developed during analysis phase is transformed into data
structures needed for implementing the software.

8
ER diagram
 Software Design Activities
Design phase is the most important phase in software engineering to develop an
application or any system. Phases in the Design Process includes:
 Architectural design-used to identify the sub systems from the main
system or software application.
 Abstract specification -Specify sub-systems
 Interface design -describe sub-system interfaces
 Component design -decompose sub-systems into components
 Data structure design -design data structures to hold problem data
 Algorithm design -design algorithms for problem functions

9
 Cont.…
 Design activities and product

10
 Design strategies
 Functional Design: The system is designed from
a functional viewpoint.
 The system state is centralized and shared
between the functions operating on that state.
 Produces a hierarchy of tasks.
 Object-Oriented Design: The system is viewed as Vs
a collection of interacting objects.
 The system state is decentralized and each
object manages its own state.
 Objects may be instances of a class and
communicate by exchanging messages.
11
 Produces a hierarchy of objects.
 Software Design Approaches
 Here are two generic approaches for software designing:
 Top-down design
Takes the whole software system as one entity and then decomposes
it to achieve more than one sub-system or component
Each sub-system or component is then treated as a system and
decomposed further.
Keep on running until the lowest level of system is achieved.
 Bottom-up design
Make decisions about reusable low-level utilities.
Then decide how these will be put together to create high-level
constructs

12
 Software Design Approaches…

top-down
bottom-up

 Hybrid Design: Both, top-down and bottom-up approaches are not practical individually.
Instead, a good combination of both is used.
 Top-down design is almost always needed to give the system a good structure.
 Bottom-up design is normally useful so that reusable components can be created.
13
 Principles Leading to Good Design
 A design is said to be good design if
 Increasing profit by reducing cost: Reusability
 Ensuring that we actually conform with the requirements
 Accelerating development: Modularity
 Increasing qualities such as: Scalability, Efficiency, Reliability, Maintainability, Reusability, …
 In order to achieve the design goals (especially for object oriented systems) we
need to follow the following design principles:
 Divide and conquer  Reuse existing designs and code
 Increase cohesion where possible where possible
 Decrease coupling where possible  Design for flexibility
 Keep the level of abstraction as  Anticipate obsolesce
high as possible  Design for Portability
 Increase reusability where  Design for Testability
possible  Design defensively
14
 1: Divide and conquer (Modularity)
 Trying to deal with something big all at once is normally much harder than dealing
with a series of smaller things.
 A system could be subdivided in the following way
 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.

 Some of the advantages of dividing and tackling a problem are:-

 Separate people can work on each part.
 An individual software engineer can specialize in his or her component, becoming expert at it.
 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.
 Opportunities arise for making the component reusable

15
 2: Increase cohesion where possible
 Cohesion is a measure of the degree to which the elements of a module are
functionally related.
 It is the degree to which all elements directed towards performing a single task are
contained in the component.
 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

16
 3:Reduce Coupling where possible
 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.

17
 4: Keep the level of abstraction as high as possible
 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.
 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.
 Superclasses and interfaces increase the level of abstraction

18
 Design Principles 5 & 6
 Increase reusability where possible
 Design the various aspects of your system so that they can be used again in other contexts
 Generalize your design as much as possible
 Design for reuse
 Reuse existing designs and code where possible
 Design with reuse
 Actively reusing designs or code allows you to take advantage of the investment you
or others have made in reusable components

19
 Design Principles 7 & 8
 Design for flexibility: actively anticipate changes that a design may have to
undergo in the future, and prepare for them.
 Open/Closed Principle: Classes should be open for extension but closed for
modification.
 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

20
 9: 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
 Avoid using undocumented features or little-used features of software libraries
 Avoid using software or special hardware from companies that are less likely to
provide long-term support
 Use standard languages and technologies that are supported by multiple vendors

21
 Design principle 10 and 11
 Design for Testability: Take steps to make testing easier
 Design a program to automatically test the software

 Design defensively: Never trust how others will try to use a component you are designing
 The purpose of defensive design is to ensure that a program runs correctly and continues to run
no matter what actions a user takes.
 Handle all cases where other code might attempt to use your component inappropriately
 Check that all of the inputs to your component are valid: the preconditions
 Unfortunately, over-zealous defensive design can result in unnecessarily repetitive checking

22
 Software Architecture
 The software architecture of a program or computing system is the set of structures
of the system, which comprise software elements, the externally visible properties
of those elements, and the relationships between them.
 Elements can be: objects, classes, functions, processes, programs, libraries,
databases, etc.
 Relationships between elements: part of, synchronization, function call, etc.
 Externally Visible Properties: its provided services, performance
characteristics, fault handling, shared resource usage,…

23
 Groups of Architectural Structures
Architectural structures can by and large be divided into three groups, depending on
the broad nature of the elements they show.
1. Module structures: are static structures, in that
they focus on the way the system's functionality is
divided up
2. Component-and-connector structures
runtime components (principal units of
computation) and connectors (communication
vehicles among components)

3. Allocation structures: show relationships between

software elements & external environments (system's
organizational, developmental, installation, and execution)

24
 Software Architecture…
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.
 Structural Diagrams and Behavioral Diagrams (will be covered in lab sessions)
 Architecture View Model (4+1 view model) − logical view + process view +
physical view + development view + scenario/use case view
 ADL (Architecture Description Language) − ADL defines the software
architecture formally and semantically.
o It includes components, connectors, and abstractions

25
 Architecture View Model (4+1 view model)

26
 Some architectures
 Component based architecture
 Service oriented architecture (Reading Assignment)
 Aspect Oriented Software Architecture (Reading Assignment)

27
 Component Based Software Engineering (CBSE)…
 A software component is an independently deployable implementation of some
functionality, to be reused as it is in a broad spectrum of applications.
 CBSE is a process for developing computer systems using reusable software
components.
 It is concerned with assembling of pre-existing software components into
larger pieces of software.

28
Component Based Software Engineering (CBSE)…
 There are a number of advantages gained with CBSE
 Advantage 1: Software construction: Building a system by composing “entities”

Application

Software construction vs. creation: application is

29 developed as an assembly of “integrated circuits”
 Component Based Software Engineering (CBSE)…
 Advantage 2: Reuse
Application 1
C1

C1

Application 2
C1
Software “integrated circuits”
are reusable entities
It pays off to have as many applications
that reuse an entity

30
 Component Based Software Engineering (CBSE)…
 Advantage 3: Maintenance & Evolution: Maintaining a system by
adding/removing/replacing “entities”

C1new

Application
C1
update

Maintenance and upgrading can

be done by replacing parts, maybe
even at runtime

31
 Component Based Software Engineering (CBSE)…
 The services offered by a component are made available through an interface.

 At the highest level, there are two types of CBSE processes:

 Development for reuse
 This process is concerned with developing components or services that will be
reused in other applications.
 It usually involves generalizing existing components.
 Development with reuse
 This process is the process of developing new applications using existing
32 components and services.
 Service Oriented Software Architecture(SOA)
 Service oriented development is a means of developing distributed systems where the
components are stand-alone services.
 Services do not have a ‘requires’ interface.
 There are two major roles within SOA:
 Service provider
 Service consumer
 Service-Oriented Software Engineering contains
 Service Engineering
 The development of dependable, reusable services - Software development for
reuse
 Software Development with Services
 The development of dependable software where services are the fundamental
33 components - Software development with reuse
 Service Oriented Software Architecture(SOA)

34