Software Design Concepts

Yonglei Tao

Software Development Products

Working programs Relevant documents

Expectations Good quality On time Within budget

Software Failure Ariane 5 is a space launcher developed in Europe

One design decision was to reuse a key component that had performed successfully in Ariane 4

It failed after 37 seconds in the first launch Due to an unhandled exception from a numeric overflow

The fault occurred in code not required for Ariane 5 It was not a problem in Ariane 4 Validation tests for the reused component were based on

Ariane 5 requirements No requirements for the function that failed so no tests

were conducted

4

Software Process “In order to achieve high standards of

quality in design product, one needs to seek high standards of quality in the design process.”

- David Budgen

5

Software Design

Functional requirements

Non-functional requirements

Others

Architectural design

Detailed design Design

documentation

Types of Requirement Functional requirements

What the system shall do, not how to do An external view of the system

Non-functional requirements Performance requirements Quality requirements Safety requirements Security requirements Interface requirements

Others Operational environment and software standards, … Organizational or domain requirements, …

Examples of Functional Requirements For a car rental system

The system must allow a potential customer to inquire information and availability of rental cars using various combinations of search criteria including make, model, from date, to date, price range, and class (small size, medium size, large size, and luxury cars)

For a study abroad system The system must provide interactive as well as

batch-processing means for an OIE (Office of International Education) staff to enter the exchange programs into the database

Examples of Non-Functional Requirements Workload

The system must be capable of handling a typical workload of 10,000 (ten thousand) inquiries at the same time

Response time The system's response time must not exceed 3

(three) seconds under the typical workload Platform independence

The system must run on Windows 2000 and later, Unix, Linux, Mac and support popular relational database management systems including Oracle, SQL Server, Access, and MySQL

Examples (Cont.) User friendliness

The system must provide a user friendly interface that conforms to commonly used web-application user interface look-and-feel and man-machine interaction conventions.

User interface The system must support the following user

interfaces: web-based stand-alone voice cellular phone

Roles of Non-Functional Requirements Analysis of DNA sequences in genetic research

A DNA sequence is represented as a vector of N integer values, where N is very large

A typical problem is to discover whether any pattern of length M (a fixed and small constant) is ever repeated in the array of values

… a b c … … a b c …

Solution One Using an array to store the DNA sequence

for ( I = 0 ; i <= N - M ; i++ ) {for ( j = i+1 ; j <= N - M ; j++ ) {

found = false;k = 0;while ( k < M && s[ i + k ] == s[ j + k ] )

k++;if ( k == M )

found = true;}if ( found )

// report accordingly}

Running time O( MN2 )

Solution Two Using a two-dimensional array to store the DNA

data

Running time O( MNlog2N )

X1 X2 … XM

X2 X3 … XM+1

… … … …

XN-M … … XN-1

XN-M+1 … … XN

Solution Three Using a suffix trie to store the DNA data

Running time O(MN)

Challenges in Design Complexity

Numerous requirements A long development duration Multiple stakeholders and development teams

Uncertainty Inadequate and changing requirements New technologies

Conflicting goals Technical, economic, and political

Combinatorial Explosion

Number of possible positions (states of the board) 39 = 19,683

Number of possible games 9! = 362,880

12! and 20! are the largest factorials that can be stored in the 32-bit and 64-bit integers commonly used in personal computers, respectively.

Software Complexity Refers to the extent to which a system is

difficult to comprehend, create, modify, and test

Drives from four elements The complexity of the problem domain The difficulty of managing the development

process The flexibility possible through software The problem of characterizing the behavior of

discrete systems

Software Complexity “The complexity of software is an essential

property, not an accidental.” – Brooks

“The art of programming is the art of organizing complexity.”

– Dijkstra “The most fundamental problem in software

development is complexity. There is only one way of dealing with complexity: divide and conquer.”

– Stroustrup

18

Properties of a Tame Problem Can be completely specified. Its specification and solution can be

separated. There are stopping rules. A solution can be evaluated in terms of correct

or wrong. Each step of the problem-solving process has

a finite number of possible moves. These is a definite chain of cause-effect

reasoning. The solution can be tested immediately; once

tested, it remains correct forever. The solution can be adapted for solving

similar problems. The solution process is a scientific process. If the problem is not solved, simply try again.

19

Examples of Tame Problem

Chess playing Math problems

Operations

research

Query optimization

Compiler construction

Operating systems

Many computer science problems

AI problems

20

Properties of a “Wicked” Problem Cannot be definitively stated. Cannot separate the specification and solution. No stopping rules – you can always do it better. Has only good or bad solutions, not right or wrong –

the judgment is usually subjective. Each step in the problem solving process has many

choices – everything goes as a matter of principle. Cause-effect reasoning is premise-based, leading to

varying actions - hard to tell which one is the best. Every problem is unique. So is the solution. Every solution is an “one shot operation” – you have

no right to be wrong because of the consequence.

21

Examples of Wicked Problem

Urban planning National policy making

Economic reforms Application softwaredevelopment

Conceptual Tools - Separation of Concerns Separate different concerns so as to

address them separately Divide and conquer

Concerns are requirements, issues, views, and parts of the system

May result in separate responsibilities for a team to work on

Modularity & Decomposition A system is composed of separately named

and addressable components, called modules that are integrated to meet the system’s requirements

Decomposition refers to the process of dividing a large system into smaller, more manageable components with well-defined relationships to one another

Motivation - Managing Complexity C (P1 + P2) > C (P1) + C (P2) Where C is complexity and P is a problem The same is true for the effort

Num ber of M odules

Cost /Effort

Total Software Cost

Cost per M oduleCost to Interface

Desirable Properties for Modular Design Decomposability Composability Understandability Continuity Protection

- Meyer

Parnas’s Criteria for Modularity Change the implementation of one module

Without knowing the implementation of others Without affecting the behavior of others

Easy to understand what a module represents or is responsible for In isolation Without having to know its internal workings

Possible to make a major software change as a set of independent changes to individual modules

Conceptual Tools - Abstraction An abstraction is the purposely

suppression, or hiding, of some details of a process or artifact, in order to bring out more clearly other aspects, details, or structures.

We construct a model by means of abstraction

Abstraction and Instantiation

(1) a publication(2) a newspaper (3) the Grand Rapids Press (4) the May 18 edition of the Press (5) my copy of the May 18 edition of the

Press (6) my copy of the May 18 edition of the

Press as it is now (as contrasted with the copy as it was when it first came)

- Godel, Escher, Bash

Forms of Abstraction - Classification

How to Classify?

Forms of Abstraction - Partition

Forms of Abstraction - Multiple Views

Information Hiding A principle for modularity Each module hides its design decision

(such as data structure and algorithm) from others Similar to the “need to know” principle adopted

by military organizations Making the interface of a module

independent of its implementation Reduce coupling Increase modifiability

Software Abstraction

Procedural abstraction Sorting

Data abstraction Student list

Control abstraction Semaphore

36

Tools - Software Prototyping Deal with uncertainty and reduce risk Evaluate a solution to a problem Assess performance and resource needs Clarify requirements