software design overview

8/3/2019 Software Design Overview

1/27

Slide 1.1Overview

OBJECT-ORIENTED

SOFTWAREDESIGN

Overview


2/27

Slide 1.2Typical Classical Phases

Requirements phaseExplore the concept

Elicit the clients requirements

Analyze the clients requirements

Draw up the specification document

Draw up the software project management plan

What the product is supposed to do


3/27

Slide 1.3Typical Classical Phases (contd)

Design phaseArchitectural design, followed by

Detailed design

How the product does it

Implementation phase

Coding

Unit testingIntegration

Acceptance testing


4/27

Slide 1.4In More Detail

Objects enter here

Figure 1.9


5/27

Slide 1.5Object-Oriented Paradigm

Modules (objects) are introduced as early as theobject-oriented analysis workflow

This ensures a smooth transition from the analysis

workflow to the design workflow

The objects are then coded during the

implementation workflow

Again, the transition is smooth


6/27

Slide 1.6Strengths of the Object-Oriented Paradigm

With information hiding, post-delivery maintenanceis safer

The chances of a regression fault are reduced

Development is easier

Objects generally have physical counterparts

This simplifies modeling (a key aspect of the object-

oriented paradigm)


7/27

Slide 1.7Strengths of the Object-Oriented Paradigm (contd)

Well-designed objects are independent unitsEverything that relates to the real-world object being

modeled is in the object encapsulation

Communication is by sending messages

This independence is enhanced by responsibility-drivendesign (see later)


8/27

Slide 1.8Strengths of the Object-Oriented Paradigm (contd)

A classical product conceptually consists of asingle unit (although it is implemented as a set of

modules)

The object-oriented paradigm reduces complexity

because the product generally consists of independentunits

The object-oriented paradigm promotes reuse

Objects are independent entities


9/27

Slide 1.9The Object-Oriented Paradigm in Perspective

The object-oriented paradigm has to be usedcorrectly

All paradigms are easy to misuse

When used correctly, the object-oriented paradigm

can solve some (but not all) of the problems of the

classical paradigm


10/27

Slide 1.10What is software design?

Software design is the process of planning how tosolve a problem through software.

A software design contains enough information for a

development team to implement the solution. It isthe embodiment of the plan (the blueprint for the

software solution).


11/27

Slide 1.11The Design Workflow

The aim of the design workflow is to refine theanalysis workflow until the material is in a form

that can be implemented by the programmers

Many nonfunctional requirements need to be finalized at

this time, including Choice of programming language

Reuse issues

Portability issues

Retain design decisions

For when a dead-end is reached, and

To prevent the maintenance team reinventing the wheel


12/27

Slide 1.12Classical Design

Architectural designDecompose the product into modules

Detailed design

Design each module:

Data structures

Algorithms


13/27

Slide 1.13Data and Actions

Two aspects of a productActions that operate on data

Data on which actions operate

The two basic ways of designing a product

Operation-oriented design

Data-oriented design

Third way

Hybrid methods

For example, object-oriented design


14/27

Slide 1.14Object-Oriented Design (OOD)

AimDesign the product in terms of the classes extracted

during OOA

OOD consists of two steps:

Step 1. Complete the class diagram

Determine the formats of the attributes

Assign each method, either to a class or to a client that

sends a message to an object of that class

Step 2. Perform the detailed design


15/27

Slide 1.15The Design Workflow

Summary of the design workflow:The analysis workflow artifacts are iterated and

integrated until the programmers can utilize them

Decisions to be made include:Implementation language

Reuse

Portability


16/27

Slide 1.16The Design Workflow (contd)

The idea of decomposing a large workflow intoindependent smaller workflows (packages) is

carried forward to the design workflow

The objective is to break up the upcomingimplementation workflow into manageable pieces

Subsystems


17/27


Why the product is broken into subsystems:

It is easier to implement a number of smaller

subsystems than one large system

If the subsystems are independent, they can be

implemented by programming teams working in parallel

The software product as a whole can then be delivered sooner


18/27


The architecture of a software product includesThe various components

How they fit together

The allocation of components to subsystems

The task of designing the architecture is

specialized

It is performed by a software architect


19/27


The architect needs to make trade-offsEvery software product must satisfy its functional

requirements (the use cases)

It also must satisfy its nonfunctional requirements,

including Portability, reliability, robustness, maintainability, and security

It must do all these things within budget and time

constraints

The architect must assist the client by laying out

the trade-offs


20/27


It is usually impossible to satisfy all therequirements, functional and nonfunctional, within

the cost and time constraints

Some sort of compromises have to be made

The client has to

Relax some of the requirements;

Increase the budget; and/or

Move the delivery deadline


21/27


The architecture of a software product is criticalThe requirements workflow can be fixed during the

analysis workflow

The analysis workflow can be fixed during the design

workflowThe design workflow can be fixed during the

implementation workflow

But there is no way to recover from a suboptimalarchitecture

The architecture must immediately be redesigned


22/27

Slide 1.22OOA & OOD Activities

1. Identify the information systems purpose2. Identify the information systems actors and features

3. Identify Use Cases and create a Use Case Diagram

4. Identify Objects and their Classes and create a Class

Diagram5. Create Interaction/Scenario Diagrams

6. Create Detail Logic for Operations

7. Repeat activities 1-6 as required to refine the blueprints


23/27

Slide 1.23Objects

Objects have three responsibilities:1. What they know about themselves (e.g.,

Attributes)

2. What they do (e.g., Operations)

3. What they know about other objects (e.g.,

Relationships


24/27

Slide 1.24Relationships

A RELATIONSHIP is what a class or an object knows about another class or

object.

Generalization (Class-to-Class) (Superclass/Subclass)

Inheritance

Ex: Person - FacultyPerson, StudentPerson, Staff... Ex: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat...

Associations

FacultyInformation - CourseInformation

StudentInformation - CourseInformation

Aggregations & Composition (Whole-Part)

Assembly - Parts

Group - Members

Container - Contents


25/27

Slide 1.25Composition

Composition is often used in place ofGeneralization (inheritance) to avoid tran

(adding, copying, and deleting of objects)


26/27

Slide 1.26Identify candidate entities

For each use case, and other requirement documents- Underline each noun and noun phrase

Some will be class, some will be a class attribute

Some will have no significance


27/27

Slide 1.27Challenge the candidate entities

1. Is this candidate inside our system boundary?2. Does this candidate have indentifiable behaviour

for our problem domain?

3. Does this candidate have indentifiable structure?

4. Does this candidate have relationship with other

candidates?

software design overview

Documents