8/13/2019 Lec ture#3

1/25

Goals of Software Design

Design faces many challenges to produce agood product, e.g. shifting requirements.

But what do we mean by good ?

We need some clear goals here

8/13/2019 Lec ture#3

2/25

Good design leads to software that is:

1. Correctdoes what it should

2. Robusttolerant of misuse, e.g. faulty data

3. Flexibleadaptable to shifting requirements

4. Reusablecut production costs for code

5. Efficientgood use of processor and memory

Also should be Reliableand Usable

8/13/2019 Lec ture#3

3/25

Correctness

Software is correct, if it satisfies its requirements. A primary goal, incorrect software may look good, but will b

worse.

Requirements are divided into functional

(what it does) and non-functional(how it does it, etc.)

8/13/2019 Lec ture#3

4/25

Robustness

A design or system is robustif it toleratesmisuse without catastrophic failure.

fault-tolerant.

Includes bad data, bad use, bad environment,

bad programming.

8/13/2019 Lec ture#3

5/25

Robustness achieved in many ways:

Use data abstraction and encapsulation Create ADTs and simple interfaces

Shield from data corruption Initialize variables

Qualify all inputs (e.g. range check) Same as precondition checking

Qualify all formal parameters to a method

Qualify invariants (e.g. non-null pointer, not end_of_file )

Qualify postconditions

8/13/2019 Lec ture#3

6/25

Flexibility

Requirements may changeduring or after

the project.

Obtaining more of whats present

e.g. more kinds of different bank accounts

Adding new kinds of functionality

e.g. add internet banking to tellerfunctionality

Changing functionality

e.g. allow withdrawals to create an overdraft

8/13/2019 Lec ture#3

7/25

Reusability

Aim: cut cost of code production over 1 or

more projects.

Reuse object code (see later discussion ofcomponent technologies)

Reuse source codesee next slides Reuse assemblies of related classes, e.g.

software frameworks

Reuse patterns of designssee previous!

8/13/2019 Lec ture#3

8/25

Efficiency

Aim: Make greatest use of the processing

power, memory size, network speed, etc.

But all these things are getting cheaper!

But applications are getting bigger!

Efficiency is often against the first 4 goals!

8/13/2019 Lec ture#3

9/25

What Is A Model ?

A Representation of an object, a system, oidea in some form other than that of the eitself.

(Sh

Introduction

8/13/2019 Lec ture#3

10/25

Introduction

Types of Models:

Physical(Scale models, prototype plants,)

Mathematical

(Analytical queueing models, linear programs,

simulation)

8/13/2019 Lec ture#3

11/25

Introduction

MODELLING GENERAL PURPOSLANGUAGESAdvantages:

Little or no additional software cost

Universally available (portable)

No additional training

Disadvantages:

Every model starts from scratch

Very little reusable code

Long development cycle for each model

Difficult verification phase

8/13/2019 Lec ture#3

12/25

What is software requirementsSpecification

A software requirements specification (SRS) describes the requirement

software product -- what it must do in order to function as expected. R

despite using the term "requirements," an SRS really is high-level desig

product whose expected functioning is a presumed way to satisfy the R

business requirements deliverable whatsthat provide value when satis

software can work as expected but won't provide value unless it actuathe REAL business requirements

8/13/2019 Lec ture#3

13/25

The Software Requirements Specificati

After review of the customers System Spec.

After educated analysis

Preliminary design

A technical, software approach

Results in permission to detail-design and code

8/13/2019 Lec ture#3

14/25

From the customers perspective

How smart people are going to solve the problem that was sthe System Spec.

A contract, more or less

Is it doable? Technically

On time Under budget

8/13/2019 Lec ture#3

15/25

8/13/2019 Lec ture#3

16/25

Risk Assessment

Technical Risks hardware software

interfaces

build vs. buy

Schedule Risks budget

calendar

personnellevel of expertise required

8/13/2019 Lec ture#3

17/25

Major Module Descriptions

Supervisory / Executive

Classes, Major Objects, and Libraries

Build vs. Buy

Interfaces Module to Module

SW to HW

Control to Data

Low Level Utilities Drivers

8/13/2019 Lec ture#3

18/25

What is Class Diagram?

Class diagrams are aspects that describe design of the objects, and their relationseach other, in an application. During aclass diagrams may just be the names of and how they interact, but as the develops the details of each class, inattributes and methods, are displayed diagram.

8/13/2019 Lec ture#3

19/25

Classes

ClassName

attributes

operations

A classis a description of a set of

objects that share the same attributes,

operations, relationships, and semantics

Graphically, a class is rendered as a

rectangle, usually including its name,

attributes, and operations in separate,

designated compartments.

8/13/2019 Lec ture#3

20/25

Class Names

ClassName

attributes

operations

The name of the class is the only requir

tag in the graphical representation of aclass. It always appears in the top-mos

compartment.

8/13/2019 Lec ture#3

21/25

Class Attributes

Person

name : String

address : Address

birthdate : Date

ssn : Id

An attributeis a named property of a

class that describes the object being mo

In the class diagram, attributes appear i

the second compartment just below the

name-compartment.

8/13/2019 Lec ture#3

22/25

Class Attributes (Contd)

Person

name : String

address : Address

birthdate : Date

/ age : Date

ssn : Id

Attributes are usually listed in the fo

attributeName : Type

A derivedattribute is one that can be

computed from other attributes, but

doesnt actually exist. For example,

a Persons age can be computed from

his birth date. A derived attribute isdesignated by a preceding / as in:

/ age : Date

8/13/2019 Lec ture#3

23/25

Class Attributes (Contd)

Person

+ name : String

# address : Address

# birthdate : Date

/ age : Date

- ssn : Id

Attributes can be:

+ public

# protected

- private

/ derived

8/13/2019 Lec ture#3

24/25

Software Design (UML)

Class Operations

Person

name : String

address : Address

birthdate : Date

ssn : Id

eatsleep

work

play

Operations describe the class behaviorand appear in the third compartment.

8/13/2019 Lec ture#3

25/25

Depicting Classes

Person

name : Strin

birthdate : Date

ssn : Id

eat()sleep()

work()

play()

When drawing a class, you neednt show attributes and operatio

in every diagram.

Person

Person

nameaddress

birthdate

Person

eat

play

Person