Chapter 5: Introduction to Software Design

(Part I)

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

3
 Cont…
 Generally, design is about how to build a system (answers “HOW?”)- Specifying different
parts of the software, and how they will fit together.
 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.
 To develop a complete specification of design (design model), four design models are needed:
 Data design,
 Architectural design
 Procedural design and
 Interface design

4
 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.
 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.
 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).
5
 Interface design: depicts how the software communicates with the system
that interoperates with it and with the end-users
 Cont…

Design Model

6 Architecture described using a package diagram

ER diagram
 Cont.…

Interfaces

Components

7
 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

8
 Cont.…
 Design activities and product

9
 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.
10
 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

11
 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.
12
 Principles Leading to Good Design
 A design is said to be good design if
 Increasing profit by reducing cost
 Ensuring that we actually conform with the requirements
 Accelerating development
 Increasing qualities such as: Usability, 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
13
 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

14
 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
 Type of cohesion:
 Functional, Layer, Communicational, Sequential, Procedural, Temporal, Utility

15
 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.
 Type of coupling: Content, Common, Control, Stamp, Data, Routine Call, Type use,
Inclusion/Import, External

16
 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

17
 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
 Cloning should not be seen as a form of reuse.

18
 Design Principles 7 & 8
 Design for flexibility: actively anticipate changes that a design may have to
undergo in the future, and prepare for them

 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

19
 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

20
 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
 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

21
Chapter 4: Software Architecture
(Part II)
 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
 Architecture Evaluation
 Technical: Evaluation against system quality attributes, e.g. performance, security
and modifiability, Suitability of design decisions, E.g. Architecture Tradeoff Analysis
Method (ATAM).

 Economic: Biggest tradeoffs in large complex systems usually have to do with

economics, cost and benefits associated with architectural design decisions, E.g. Cost
Benefit Analysis Method (CBAM)

27
 Some architectures
 Component based architecture
 Service oriented architecture

28
 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.

29
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

30 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

31
 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

32
 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
33 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
34 components - Software development with reuse