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