03.3 software design

1

بسم هللا الرحمن الرحيم

Software Design

Prepared By:

Eng.\ Tarig Ahmed Khalid, M.Sc., PMP, CEC, CBAP , MIEEE

General Manager, Financial & Banking Systems Co. (FBS)

2

Introduction

Design is defined as both “the process of defining the

architecture, components, interfaces, and other characteristics of

a system or component” and “the result of that process.”

[IEEE610.12-90]

Software design is the software engineering life cycle activity in

which software requirements are analyzed in order to produce a

description of the software’s internal structure that will serve as

the basis for its construction.

Software design (the result) must describe:

1. the software architecture—that is, how software is

decomposed and organized into components

2. the interfaces between those components. It must also describe

the components at a level of detail that enable their

construction.

3

Software design plays an important role in developing software:

1. It allows producing various models that form a kind of

blueprint of the solution to be implemented.

2. Analysis & evaluation of these models determine whether

or not various requirements could be fulfilled

3. It allows examining and evaluating various alternative

solutions and trade-offs.

4. Resulting models are used to plan the subsequent

development activities, in addition to using them as input and

the starting point of construction and testing.

4

Software design consists of two activities that fit between

software requirements analysis and software construction:

1. Software Architectural Design (Top-Level design):

describing software’s top-level structure & organization and

identifying the various components

2. Software Detailed Design: describing each component

sufficiently to allow for its construction.

5

1. Software Design Fundamentals

2. Key Issues in Software Design

3. Software Structure and Architecture

4. Quality Attributes

5. Software Design Notations

6. Software Design Strategies & Methods

6

1.1 General Design Concepts

In the general sense, design is a form of problem solving.

A number of other notions and concepts are also of interest in

understanding design in its general sense:

1. Goals

2. Constraints

3. Assumptions

4. Alternatives

7

1.2 Software Design Process

Software design is generally considered a two-step process:

1. Architectural Design:

• Describes how software is decomposed and organized into

components (the software architecture)

2. Detailed Design:

• Describes the specific behavior of these components.

• The output of this process is a set of models and artifacts

that record the major decisions that have been taken.

8







9

Introduction

A number of key issues must be dealt with when designing

software. Some are quality concerns that all software must

address—for example, performance.

Another important issue is how to decompose, organize, and

package software components.

In contrast, other issues “deal with some aspect of software’s

behavior that is not in the application domain, but which addresses

some of the supporting domains.”

Such issues, which often cross-cut the system’s functionality, have

been referred to as aspects.

10

Design Aspects

1. Concurrency:

a. How to decompose the software into processes, tasks, and

threads

b. How to deal with efficiency, synchronization, and scheduling

issues.

2. Control and Handling of Events:

a. How to organize data and control flow

b. How to handle events.

3. Distribution of Components:

a. How to distribute the software across the hardware

b. How the components communicate

c. How middleware can be used to deal with heterogeneous

software.

11

4. Error and Exception Handling and Fault Tolerance:

a. How to prevent and tolerate faults

b. How to deal with exceptional conditions.

5. Interaction and Presentation:

a. How to structure and organize the interactions with users

b. How to present information .

6. Data Persistence:

a. How long-lived data are to be handled

12







13

Introduction

A software architecture is “a description of the subsystems and

components of a software system and the relationships between

them.”

Architecture attempts to define the internal structure.

During the mid-1990s, software architecture started to emerge as a

broader discipline involving the study of software structures and

architectures in a more generic way.

14

3.1 Architectural Structures and Viewpoints

Different high-level facets of a software design can and should be

described and documented. These facets are often called views.

A view represents a partial aspect of a software architecture that

shows specific properties of a software system.

These distinct views are associated with software design. For

example:

– the logical view (satisfying the functional requirements)

– the process view (concurrency issues)

– the physical view (distribution issues)

– the development view (how the design is broken down into

implementation units).

15

3.2 Design Patterns

A pattern is “a common solution to a common problem in a

given context.”

A pattern is a recurring solution to a standard problem, in a

context.

Design reuse

Architectural styles can be viewed as patterns describing the

high-level organization of software macro-architecture

Design patterns can be used to describe details at a lower,

more local level micro-architecture.

16

Pattern Description:

1. Name and intent:

2. Problem and context:

– What is the problem and the context where we would use this

pattern?

3. Solution:

– A description of the elements that make up the design pattern

– Emphasizes their relationships, responsibilities, and

collaborations

– Not a concrete design or implementation; rather an abstract

description

4. Positive and negative consequences of use:

– The pros and cons of using the pattern

– Includes impacts on reusability, portability, and extensibility

17

Example

In the banking system where cheque's for clearing is approved by

the person but if the cheque amount is beyond certain limit, the

approving responsibility moves the person higher in authority in

the bank.

18

A software framework is a universal, reusable software platform

to develop applications, products and solutions.

Software frameworks include support programs, compilers, code

libraries, tool sets, and application programming interfaces (APIs)

that bring together all the different components to enable

development of a product

In OO programming, a key related notion is that of the framework:

a partially complete software subsystem that can be extended by

appropriately instantiating specific plug-ins.

Example: Cactus Framework

3.3 Software Frameworks

19

About Cactus:

Cactus is an open source problem solving environment designed

for scientists and engineers.

Its modular structure easily enables parallel computation across

different architectures and collaborative code development

between different groups.

The Cactus user community has created and is maintaining toolkits

for several research fields.

Ex: The Einstein Toolkit addresses computational relativistic

astrophysics, supporting simulations of black holes, neutron stars,

and related systems.

Ref: cactus.org

20







21

Various attributes are generally considered important for

obtaining a software design of good quality

Various “ilities” (maintainability, portability, testability,

traceability)

Various “nesses” (correctness, robustness, “fitness of purpose.”)

An interesting distinction is the one between:

– quality attributes discernible at run-time (performance,

security, availability, functionality, usability),

– quality attributes not discernible at run-time (modifiability,

portability, reusability, and testability),

– quality attributes related to the architecture’s intrinsic

qualities (conceptual integrity, correctness, and

completeness).

22







23

Many notations and languages exist to represent software design

artifacts.

Some are used mainly to describe a design’s structural

organization, others to represent software behavior.

Certain notations are used mostly during architectural design and

others mainly during detailed design, although some notations can

be used in both steps. In addition, some notations are used mostly

in the context of specific methods

Here, they are categorized into notations for describing the

structural (static) view vs. the behavioral (dynamic) view.

UML is a standard design notation language

24







25

Introduction

There exist various general strategies to help guide the design process.

In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using the method.

Such methods are useful as a means of transferring knowledge and as a common framework for teams of software engineers.

26

6.1 General Strategies

Some examples of general strategies useful in the design process

are:

1. Divide-and-conquer and stepwise refinement

2. Top-down vs. Bottom-up strategies

3. Data abstraction and information hiding

4. Use of patterns

5. Use of an iterative and incremental approach.

27

6.2 Function-Oriented (Structured) Design

This is one of the classical methods of software design, where

decomposition centers on identifying the major software functions

and then elaborating and refining them in a top-down manner.

Structured design is generally used after structured analysis, thus

producing, among other things, data flow diagrams and associated

process descriptions.

28

6.3 Object-Oriented Design

Numerous software design methods based on objects have been

proposed.

The field has evolved from the early object-based design of the

mid-1980s (noun = object; verb = method; adjective = attribute)

through OO design, where inheritance and polymorphism play a

key role, to the field of component-based design.

29

6.4 Component-Based Design (CBD)

A software component is an independent unit, having well-defined

interfaces and dependencies that can be composed and deployed

independently.

Component-based design addresses issues related to providing,

developing, and integrating such components in order to improve

reuse.

30

6.5 Service Oriented Architecture (SOA)

SOA is a software design and software architecture design pattern

based on discrete pieces of software providing application

functionality as services to other applications.

It is independent of any vendor, product or technology.

Service:

– is a self-contained unit of functionality, such as retrieving an

online bank statement.

– can be combined by other software applications to provide the

complete functionality of a large software application.

31

SOA makes it easy for computers connected over a network to

cooperate.

Every computer can run an arbitrary number of services, and each

service is built in a way that ensures that the service can exchange

information with any other service in the network without human

interaction and without the need to make changes to the underlying

program itself.

32

SOA Components

1. SOA Registry:

– It keeps information about each service functionality and

location.

2. SOA Service Manager:

– It ensures the quality of the services in the SOA architecture.

33

3. Service Broker:

– It is responsible for connecting the requester of the service to

the provider of the service with the help of the SOA Registry

and SOA Service Manager.

– Instead of hard coding the address of the service, the requester

will communicate with the broker, and then the broker will

make the connection between the requester and the provider

according to the settled rules.

4. Business Process Orchestration Manager:

– Set of tools to help the system to connect:

i. people to people

ii. people to processes

iii. processes to processes

34

5. Enterprise Service BUS (ESB):

– A set of software components that manage the message routing

and transmission from one software component to another.

– It is also responsible for translating the transfer protocol in case

of using different transfer protocols in the communicating

software components.

35

Example

Old Approach SOA Approach

03.3 software design

Documents