software design 3 dr. pedro meja alvarez departamento de computacion cinvestav-ipn
DESCRIPTION
Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN. Specifications. The exam specific topics covered in this module are listed below, and are the basis for the outline of its content Software Design Concepts Software Architecture - PowerPoint PPT PresentationTRANSCRIPT
Module III. Software Design 2
Specifications
The exam specific topics covered in this module are listed below, and are the basis for the outline of its contentA. Software Design ConceptsB. Software ArchitectureC. Software Design Quality Analysis and EvaluationD. Software Design Notations and Documentation E. Software Design Strategies and MethodsF. Human Factors in Software Design G. Software and System Safety
Module III. Software Design 3
Objectives
After completing this module, you should be able to…• To describe the efforts and thoughts behind software design• To develop an understanding of the software design process• To describe software design approaches• To describe several software design techniques• To contrast architectural design with detailed design
Module III. Software Design 4
Organization
The organization of information for each specification topic is as follows:
• Topic Content Slides - detail the important issues concerning each topic and support the module objectives
• Topic Reference Slides - detail the sources for the topical content and provides additional references for review
• Topic Quiz Slides - allow students to prepare for the exam
Module III. Software Design 5
Introduction
• The main goal of the software engineering process is the production of software that:• Functions properly• On time• Within budget• Meets end-users’ needs
• Software Design is a key piece of of this process
Characteristics of design (1)
• Design situations start with a need and require intention• A need so identified acts as the initial motivational
force that provides the basis for starting design work.
• Design situations involve transformation• Design is the restructuring of a current situation to
achieve some preferred situation• Generation of new ideas is fundamental to
design situations• Design occurs whenever there is an “imaginative
jump from present facts to future possibilities.”• The precise manner in which new ideas are
generated cannot be codified.
Characteristics of design (2)
• Constraint satisfaction• An initial need determines the most basic constraints and
requirements on a design situation. • In general, more constraints are eventually discovered
during the design work itself.• The constraints that apply both to the designed artifact
and to the processes and participants involved during the design activity.
• Problem solving or decision making• The solution space for design problems is very large and
its sheer size eliminates exhaustive search as a possible problem solving technique
• “design” is characterized by a series of decisions between various design alternatives
• Each divergent perspective may influence the progress of the design in different and unpredictable ways.
Characteristics of design (3)
• Design results in a scheme for implementing an artifact• “Design” is essentially “the formulation of a
prescription or model for a finished work in advance of its embodiment”
• Design representation serves as the basis to conceptualize and compare various design decisions.
• Sometimes, a design does not result in a distinct “plan-then-implement” situation.
• Often the design output occurs incrementally while the design and the artifact evolve together.
Characteristics of design (4)
• Diversity and evolution• Any particular design situation could be drawn in many
different directions.• The designer’s act of making decisions among the
various identified design alternatives ties together this evolution of the design.
• The evolution of a design is often closely linked to the consolidation of the constraints and requirements applied in a particular design situation.
Characteristics of design (5)
• Design situations start with a need and require intention• RE is needed before software design
• Finding the problems, defining the requirements
• Design situations involve transformation• Software changes the world
• Designing base on limited objects (shared phenomenon) and fixed rules (domain characteristics)
So, Requirements, Shared Phenomenon and Domain Characteristics comprising the basis of software design, that is Analysis Model
Analysis Model
use-cases - text use-case diagrams activity diagrams swim lane diagrams
data flow diagrams control-flow diagrams processing narratives
f low-oriented elements
behavioralelements
class-basedelements
scenario-basedelements
class diagrams analysis packages CRC models collaboration diagrams
state diagrams sequence diagrams
Data/ Class Design
Architec tural Design
Interface Design
Component - Level Design
Design Model
Analysis Model -> Design Model
Characteristics of design (6)
Module III. Software Design 12
A. Software Design Concepts
Definition of Software Design:A problem solving process in which the designer applies
knowledge and experience to produce a conceptualization that defines and describes a solution to a problem
Software Design:• Produces a description of the software’s internal
construction• Describes the software’s architecture• Bridges the gap between software requirements and
software code
Module III. Software Design 13
A. Software Design Concepts - 2
Software Design Description (SDD)
A Software Design Description (SDD) is a representation of software created to facilitate analysis, planning, implementation, and decision-making
An SDD is:• Used as a medium for communicating software design
information• Like a blueprint or model of the system
Module III. Software Design 14
A. Software Design Concepts - 3
The Problem with Software Design
• Software requirements are frequently incomplete, incorrect, and inconsistent
• Requirements change over time during development
• Is a "Wicked Problem”:• Cannot be easily defined so that all stakeholders agree on the
problem to solve• Require complex judgements about the level of abstraction at
which to define the problem• Have no clear stopping rules• Have better or worse solutions, not right and wrong ones• Have no objective measure of success• Require iteration-every trial counts• Have no given alternative solutions-these must be discovered• Often have strong moral, political or professional dimensions
• Software Design• Functional and nonfunctional• Visible and invisible
• Software Design Guidelines• A design should exhibit an architecture • A design should be modular• A design should contain distinct representations • A design should lead to data structures that are
appropriate.• A design should lead to components that exhibit
independent functional characteristics.• A design should lead to interfaces that reduce the
complexity.• A design should be derived using a repeatable method.• A design should be represented using a notation that
effectively communicates its meaning.
A. Software Design Concepts - 4
Module III. Software Design 16
A. Software Design Concepts - 5
Preliminary Design: Creates representation of the data and architecture
• Detailed Design: A design activity that focuses on the creation of an algorithm
• Object-Oriented: An approach to software development that makes use of a classification approach and packages data and processing together
• Prototyping: The creation of a model and the simulation of all aspects of a product.
• Formal Methods: A software engineering approach in which specification and design are described using mathematically-based formal notation
Module III. Software Design 17
A. Software Design Concepts - 7
The Design Process
Review - Definition of Design:
A problem solving process in which the designer applies knowledge and experience to produce a conceptualization that defines and describes a solution to a problem
Rational Unified Process (RUP)
Analysis & Design Workflow
Module III. Software Design 18
A. Software Design Concepts - 8
Activities Associated with the RUP Analysis & Design Discipline
Module III. Software Design 19
A. Software Design Concepts - 9
Artifacts Associated with the RUP Analysis & Design Discipline
Module III. Software Design 20
A. Software Design Concepts - 10
Software Design can be represented in many ways
Examples:• Flow Charts• Use-Case Realizations• Data Flow Diagrams• Pseudocode• State Diagrams• Activity Diagrams• Subsystem Diagrams• Text Documents• Any combination of these
Module III. Software Design 21
A. Software Design Concepts - 11
Design Phases
Two Types of Design
1. Architecture
2. Detailed
Architecture Design
Specify components, their interfaces, and their interactions with other components
Detailed Design
Specify the internal structure and behavior of each component
Module III. Software Design 22
A. Software Design Concepts - 12
Several Approaches to Architectural Design• Top-Down
• Starts with the highest level of abstraction and recursively fills in details of the subparts
• Bottom-Up• Start with the lowest-level components and describe how
these work together to accomplish the system’s goals• Opportunistic
• Some combination of the above two approaches
Module III. Software Design 23
A. References
[CD04] The Computer Dictionary http://www.computerdictionary.info, 2004
[CE96] CERN, “STING Software Engineering Glossary”, http://www.apl.jhu.edu/Classes/Notes/Hausler/web/glossary.html, 1996
[DD88] Department of Defense, MIL-STD-2167A, 1998 [HR84] Rittel, H. J., and M. M. Webber (1984). "Planning problems are
wicked problems", In N. Cross (Ed.), Developments in Design Methodology, Wiley, pp. 135-144.
[HR84] Rittel, H. J., and M. M. Webber (1984). Planning problems are wicked problems, Wiley, 1984
[LB98] Bass, Len et al, p. 298, Software Architecture in Practice, Addison-Wesley, Boston, 1998.
[RH97] Hubscher, Roland, “LBD Conceptual Design Problems”, http://www.cc.gatech.edu/edutech/LBD/ill-defined-problems.html, June 11, 1997
[RP03] Pressman, R.S. 2003, “Software Engineering Resources”, http://www.rspa.com/spi/glossary.html
Module III. Software Design 24
A. References (cont.)
[RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004
[SB97] Buckingham Shum, S., "Representing Hard-to-Formalise, Contextualised, Multidisciplinary, Organisational Knowledge“, 1997
[SD04] SmartDraw.com, http://www.smartdraw.com/tutorials, 2004
[SF03] SourceForge.net, http://cweb.sourceforge.net/cgi-bin/moin.cgi/ObjectFlow, 2003
Module III. Software Design 25
B. Software Architecture
• Software architecture encompasses:• Overall organization of the software system• Selection of the structural elements and specification of
their• Interfaces• Behavior
• Composition of these elements into progressively larger subsystems
• The architectural style
Module III. Software Design 26
B. Software Architecture - 2
Software architecture is also concerned with:• Usage• Functionality• Performance• Resilience• Reuse• Comprehensibility• Economic and technology constraints and tradeoffs• Aesthetics
Module III. Software Design 27
B. Software Architecture - 3
Architecture-Based Process
An example of an architecture-first approach:
1. Create the business case for the system
2. Analyze the requirements
3. Decide on a software architecture
4. Specify the architecture
5. Communicate the architecture
6. Evaluate the architecture
7. Implement the system based on the architecture
8. Ensure the implementation conforms to the architecture
Module III. Software Design 28
B. References
[LB98] Bass, Len et al, p. 298, Software Architecture in Practice, Addison-Wesley, Boston, 1998.
[OG03] Object Management Group, Model Driven Architecture Guide, v1.0.1, http://www.omg.org/mda, July 12, 2003
[RS04] IBM Corporation, 2004, The Rational Unified Process v2003.06.13
Module III. Software Design 29
C. Software Design Quality Analysis & Evaluation
• Many methods to analyze design quality• No single method, by itself, is sufficient
This module looks at quality programs in general and quality design attributes in particular
Module III. Software Design 30
C. Software Design Quality Analysis & Evaluation - 2
What is Quality?• A measure of how good something is• Very natural concept in traditional manufacturing
• Tolerance• Capacity• Strength• Size• Color• Weight
• Not quite as natural for software
Module III. Software Design 31
C. Software Design Quality Analysis & Evaluation - 3
Quality Concept• Meaning of “quality” has evolved over time:
• Conforming to the specification• Fitness for use• 2 dimensional model
• “must have” vs.• “nice to have”
Module III. Software Design 32
C. Software Design Quality Analysis & Evaluation - 4
Total Quality Management• Management strategy to embed quality awareness in all
processes• Employs statistical methods• Goal to do things right the first time instead of fixing later
• Metrics regarding failures are collected and analyzed• Then the process that caused the failure is fixed
• Has roots in manufacturing• But applicable to software development also
Module III. Software Design 33
C. Software Design Quality Analysis & Evaluation - 5
Quality Management System• Quality Management System (QMS) fathered by William
Deming• Can be implemented with one of any number of quality
management programs• Six Sigma• ISO 9000 Series• Total Quality Management (TQM)
• Malcolm Baldrige National Quality Award• Recognizes high-quality U.S. companies
Module III. Software Design 34
C. Software Design Quality Analysis & Evaluation – 6
Six Sigma• Quality management program
• “Six Sigma” quality level goal• Pioneered by Motorola• Roughly fewer than 3.4 defects in one million
• Very difficult to achieve in practice• Some market leaders have obtained six sigma
Module III. Software Design 35
C. Software Design Quality Analysis & Evaluation - 7
ISO 9000 Series• Another instance of a Quality Management System
• Guides the production of a product or service• A series of standards:
• ISO 9000: Basic language for the entire ISO 9000 family• ISO 9001: For organizations who design, develop, test,
install, and service their product• ISO 9002: For organizations who test, install and service
a product• ISO 9003: For organizations who test final products• ISO 9004: Guidance for compliance and customer
satisfaction
Module III. Software Design 36
C. Software Design Quality Analysis & Evaluation - 8
ISO 9000-3• Software related, specifically for companies that
• Develop• Supply• Install• Maintain
• End-to-end procedures to track products• Guidelines for the application of ISO 9001 to the
development, supply, and maintenance of software
Module III. Software Design 37
C. Software Design Quality Analysis & Evaluation - 9
Three Classifications of Quality
System quality attributes categories:• Discernable by observing system execution
• E.g. performance, functionality, reliability• Not discernable at runtime
• E.g. modifiability, portability, reusability• Business qualities
• E.g. Time to market, marketability
Module III. Software Design 38
C. Software Design Quality Analysis & Evaluation - 10
Quality attributes that are discernable at system runtime
PerformanceTwo Aspects of Performance:
1. Response time
2. Number of transactions per some time interval
SecurityMeasure of the system’s ability to resist unauthorized usage
AvailabilityMeasure of the proportion of time a system is up and running
FunctionalityAbility of the system to do the work for which it was intended
UsabilityExtent to which a system is easy learn and use on an ongoing
basis
Module III. Software Design 39
C. Software Design Quality Analysis & Evaluation - 11
Quality attributes that are not discernable at system runtime
ModifiabilityAbility of the system to be enhanced and maintained over time
PortabilityAbility of the system to run in different operating environments
ReusabilityAbility of the system, or parts thereof, to be used to construct other
systems
IntegrabilityAbility of the various components of a system to be made to work
together
TestabilityAbility to objectively measure the system against its requirements
Module III. Software Design 40
C. Software Design Quality Analysis & Evaluation - 12
Business Qualities
Qualities that are related to business aspects• Time to Market
• Release before competition• Release while demand for product exists
• Marketability• Cost• Competition• Target Market
Module III. Software Design 41
C. Software Design Quality Analysis & Evaluation - 13
What is a Good Design?• Well Structured• Simple• Efficient• Adequate• Flexible• Practical• Implementable
Module III. Software Design 42
C. Software Design Quality Analysis & Evaluation - 14
Design Quality
Techniques to assess design quality include:• Design Verification• Design Analysis• Design Reviews• Design Audit• Informal Design Walkthrough• Formal Design Inspection
Module III. Software Design 43
C. Software Design Quality Analysis & Evaluation - 15
Design Inspections• Step-by-step review• Roles involved:
• Moderator• Reviewer• Author• Scribe
• Each step checked against a list of criteria such as• Historical errors• Programming standards• Adherence to specifications
• The developer is responsible for narrating the design• Design inspections should occur for
• Preliminary Design• Detailed Design• Implementation
Module III. Software Design 44
C. Software Design Quality Analysis & Evaluation - 16
Design Walkthroughs• Similar to inspections but:
• Developer does not narrate the design• Team lead or architect leads the walkthrough• Manual simulation of the system• Intermediate results are recorded
• Good for simulating discussion• Many errors are caught by the developer
Module III. Software Design 45
C. Software Design Quality Analysis & Evaluation - 17
Quality Design Aspects• Fan-Out
• The number of routines a given routine calls• Information Hiding
• Abstraction technique that hides details behind and interface
• Cohesion• Cohesion refers to the degree to which a module’s
instructions are functionally related• Coupling
• Level of dependency that exists between modules
Module III. Software Design 46
C. References
• [LB98] Bass, Len et al., Software Architecture in Practice, Addison-Wesley, 1998
• [DP87] Parnas, D.L, and D. M. Weiss, Activity Design Reviews: Principles and Practices, Journal of Systems and Software, Vol. 7, 1987, pp. 259-265
• [IS96] IEEE Software, Keep It Simple, Vol. 13, No. 6, December, 1996
• [PR04] Praxiom Research Group Limited, http://praxiom.com/iso-9000-3b.htm
• [RP05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, 6th Edition, McGraw-Hill, 2005
• [WA82] Adrion, W. Richards., Validation, Verification, and Testing of Computer Software, ACM Computing Surveys, Vol 14, No. 2, June, 1982
Module III. Software Design 47
D. Software Design Notations and Documentation
• Structural Description Examples• Class and object diagrams and their relationships• CRC cards• Entity-Relationship Diagrams (ERD) used to define
conceptual models of data• Interface description language to deine the interfaces of
software components• Structure charts to describe the calling structure of
programs• Use case diagrams to model functional requirements
form the perspective of the user
Module III. Software Design 48
D. Software Design Notations and Documentation - 2
Why We Model
• Top reasons for modeling software• Provide the “blueprint” for our system• Facilitate communication among project team members• Assures architectural soundness
• Attributes of an appropriate modeling language• Model elements• Notation• Guidelines
ModelElements
Notation
Guidelines
Module III. Software Design 49
D. Software Design Notations and Documentation - 3
Functional vs. Object Oriented
Two fundamental approaches to software design• Functional• Object-Oriented
Functional (a.k.a “Structured”) takes the approach that high level functionality can be repeatedly broken down into smaller and smaller functions in order to reduce complexity.
Object-Oriented takes the approach that functionality belongs with “objects”, which are software elements that have identity and whose state and behavior is self-contained.
Module III. Software Design 50
D. Software Design Notations and Documentation - 4
Five Aspects of Structured Design
1. Form of the problem guides the form of the solution
2. Reduces complexity by organizing the system into a hierarchy of “black boxes”
3. Uses graphical tools to render systems readily understandable
4. Provides solution strategies based on a well-defined problem statement
5. Provides criteria for evaluating the quality of the design
Module III. Software Design 51
D. Software Design Notations and Documentation - 5
Four goals of Structured Design
1. Each black box should solve well-defined piece of the problem
2. The system should be partitioned so that the function of each black box is easy to understand
3. Partitioning should be done so that any connection between black boxes is introduces only because of a connection between pieces of the problem
4. Partitioning should assure that the connections between black boxes are made as simple as possible
Module III. Software Design 52
D. Software Design Notations and Documentation - 6
Key Structured Diagrams
Like any approach to software design, a structured approach prescribes certain diagrams:
• Data Flow Diagram• Shows the partitioning of the system into processes, data
sources, data sinks, and data stores• Shows how data flows between these elements
• Structure Chart• Shows the partitioning of a system into modules (black
boxes)• Shows how modules communicate with each other
Module III. Software Design 53
D. Software Design Notations and Documentation - 7
Process
Data Store
Data Source/Sink
Data Flow
Data Flow Diagram Example
Module III. Software Design 54
D. Software Design Notations and Documentation - 8
Call
Data
Module
Structure Chart Example
Module III. Software Design 55
D. Software Design Notations and Documentation - 9
Structured Transform: Process by which Data Flow Diagrams (DFDs) are converted (transformed) into structure charts• DFDs are considered the analysis artifact• The resulting structure chart is the design artifact
Module III. Software Design 56
D. Software Design Notations and Documentation - 10
Unified Modeling Language
What is it?
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.
-- OMG Unified Modeling Language Specification v1.5
Module III. Software Design 57
D. Software Design Notations and Documentation – 11
History of the UML• In 1994 approximately 50 distinct, identifiable, object-
oriented methods• Three popular methods:
• OOSE (Ivar Jacoboson)• OMT-2 (James Rumbaugh)• Booch 93 (Grady Booch)
• Rational Software hires Rumbaugh to join Booch in 1994• Booch 93 and OMT-2 melded to create “Unified Method” 0.8• Jacobson joins Rational Software in 1995• Use cases merged into Unified Method to create UML 0.9• Rational partners with industry leaders in 1996 to respond to
OMG RFP• UML 1.0 accepted by OMG in 1996
Module III. Software Design 58
D. Software Design Notations and Documentation - 12
The primary design goals of the UML:• Provide users with a ready-to-use, expressive visual
modeling language to develop and exchange meaningful models
• Furnish extensibility and specialization mechanisms to extend the core concepts
• Support specifications that are independent of particular programming languages and development processes
• Provide a formal basis for understanding the modeling language
• Encourage the growth of the object tools market• Support higher-level development concepts such as
components, collaborations, frameworks and patterns• Integrate best practices
Module III. Software Design 59
D. Software Design Notations and Documentation - 13
Scope of the UML• In scope
• Model notation and semantics specification• Extensibility mechanisms• Model interchange mechanisms• Common repository interface specification
• Out of scope• Programming languages• Tools• Process
Module III. Software Design 60
D. Software Design Notations and Documentation - 14Primary Artifacts of the UML
• Use the ones appropriate for the task at hand• Don’t have to use all artifacts• No single view is sufficient• Models can be expressed at different levels of detail• The best models reflect reality
• Three categories of diagrams:• Structure Diagrams• Behavior Diagrams• Implementation Diagrams
Module III. Software Design 61
D. Software Design Notations and Documentation - 15
Diagrams in the UML
A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships) – Grady Booch
Static Diagrams
•Use Case
•Class
•Object
•Component
•Deployment
Dynamic Diagrams
•Statechart
•Activity
•Sequence
•Collaboration
Module III. Software Design 62
D. Software Design Notations and Documentation - 16
Dynamic Diagrams
Static Diagrams
ActivityDiagrams
Models
SequenceDiagrams
CollaborationDiagrams
StatechartDiagrams
DeploymentDiagrams
ComponentDiagrams
ObjectDiagrams
ClassDiagramsUse-Case
Diagrams
Courtesy IBM Rational Software
Module III. Software Design 63
D. Software Design Notations and Documentation - 17
Class Diagram
Contains classes, interfaces, collaborations, and relationships
Models system vocabulary, collaborations, database schema
Shippingshipping street address 2 : Stringshipping date : Dateshipping street address 1 : Stringshipping city : Stringshipping name : Stringshipping state : Stringshipping mail code : Integershipping country : String
Customercustomer street address 2 : Stringcustomer mail code : Stringcustomer street address 1 : Stringcustomer country : Stringcustomer state : Stringcustomer city : Integercustomer name : Stringcustomer email : String
Productproduct name : Stringproduct description : Stringproduct price : Byte
Ordercustomer name : Integer
1 0..11 0..1
1
0..1
1
0..1
0..*
0..*
0..*
0..*
Module III. Software Design 64
D. Software Design Notations and Documentation - 18
Object Diagram
Contains objects and links
Models objects structures and relationships
Module III. Software Design 65
D. Software Design Notations and Documentation - 19
Use Case Diagram
Contains use cases, actors, and relationships
Models the context and requirements of a system
Process Sale
Store Clerk
User Maintenance
Inventory Maintenance
Administrator
Inventory Reports
User Verification
Manager
<<include>><<include>>
Module III. Software Design 66
D. Software Design Notations and Documentation - 20
Sequence Diagram
Contains objects, links, and messages
Models flows of control by time ordering
: frmMain : frmMain : SalesTransaction : SalesTransaction : LineItem : LineItem : frmPayment : frmPayment : Product : ProductRelated Product : Product
Related Product : Product : Store Clerk : Store Clerk
steps 3 - 6 repeated for each item
1: NewTransaction( )
3: NewLineItem( )
2: create
4: create
5: addLineItem(LineItem)
7: FinishTransaction( )
8: create
9: enter payment info
10: completeTransaction( )
11: Product( )
12: adjustInventory(Integer)
repeated for each item
6: f ind related product
Module III. Software Design 67
D. Software Design Notations and Documentation - 21
Collaboration Diagrams
Contains objects, links, and messages
Models flows of control by logical organization
: frmMain
: SalesTransaction
: LineItem
: Store Clerk
: frmPayment :
Product
Related Product : Product
1: NewTransaction( )
2: create
3: NewLineItem( )
4: create
5: addLineItem(LineItem)
6: find related product
7: FinishTransaction( )
8: create
9: enter payment info
10: completeTransaction( )
11: Product( )
12: adjustInventory(Integer)
Module III. Software Design 68
D. Software Design Notations and Documentation - 22
Statechart Diagram
Contains simple states, composite states, transitions
Models reactive objects
Module III. Software Design 69
D. Software Design Notations and Documentation - 23
Activity Diagram
Contains action and activity states, transitions, and objects
Models a workflow or operation
...
Product[Selected]
...
...
...
...
Product[Ordered]
...
Prov ide conf irmation number
not v alid
Ship product
...
...
In stock?
...
Product[Shipped]
y es
y es
WarehouseBilling SystemSales Clerk : Cler kCustomer : Customer
Module III. Software Design 70
D. Software Design Notations and Documentation - 24
Component Diagram
Contains components, interfaces, and relationships
Models source code, executables, and physical databases
OS Services
LDAP
Customer Validation
Shipping Service
Customer Database
Register New Customer
Module III. Software Design 71
D. Software Design Notations and Documentation - 25
Deployment Diagram
Contains nodes and relationships
Models details of various types of systems such as embedded, client/server, distributed
Application Server
Windows Client
Browser
Database Server
LAN / WAN
Firewall
Internet
LAN
Module III. Software Design 72
D. References
• [GB99] Grady Booch. The Unified Modeling Language User Guide, Addison Wesley, Reading, MA, 1999
• [IE01] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001
• [MP80] Page-Jones, Meilir. The Practical Guide to Structured Systems Design, Yourdon Press, NY, NY, 1980
• [OG03] Object Management Group (OMG), OMG Unified Modeling Language Specification, v1.5, March 2003
Module III. Software Design 73
E. Software Design Strategies and Methods
• Design methods guide the software designer• This section provides details on design
• Fundamentals• Models• Historical background
Module III. Software Design 74
E. Software Design Strategies and Methods - 2
Historical Perspective• Software design methodologies continue to evolve• Still a young, relatively immature science• Demands for new applications and major enhancements to
existing ones have grown dramatically• Successful projects have been the exception, not the norm• Problems due to inability to sufficiently:
• Translate complex problems to workable software solutions
• Take end-user opinions and practical needs into account• Take into account the organizational environment• Accurately estimate the development time and cost, and
the operational costs• Review the project progress with the customers in a
regular and consistent manner• Anticipate performance/technology tradeoffs
Module III. Software Design 75
E. Software Design Strategies and Methods - 3
Historical Perspective (cont.)• Late 60’s to early 70’s many important software engineering
concepts were introduced, including:• Top-down design• Stepwise refinement• Modularity• Structure programming
• These helped, but there was still a need for methodologies that:• Were more complete• Were faster to use• Were suitable for fourth-generation languages and
application generators• Solved maintenance issues• Were suitable for graphically-intensive applications
Module III. Software Design 76
E. Software Design Strategies and Methods - 4
Historical Methods• Flow charts• Program Design Languages (PDL)• Forms• Data structures• Data flow
Module III. Software Design 77
E. Software Design Strategies and Methods - 5
Object-Oriented Trend• Object-oriented is a proven approach to the analysis and
design of large, complex computer systems• Focuses on objects, their state and behavior
• As opposed to a functional decomposition approach• CASE tools, 4th Generation Languages (4GLs), and design
languages supplement object-orientation, examples:• Powerbuilder• Visual Basic• Unified Modeling Language
Module III. Software Design 78
E. Software Design Strategies and Methods - 6
More on Object-Oriented• Origins in Smalltalk
• By Xerox Palo Alto Research Center (PARC)• GUI-based IDE for O-O programming
• Why Object Oriented has caught on:• Higher level focus (analysis/design vs. programming)• Underlying support platforms are capable• Proven for large, complex applications• Domain-oriented trends of modern applications well
suited to object-orientation
Module III. Software Design 79
E. Software Design Strategies and Methods - 7
Beyond Waterfall• The waterfall approaching to software development is not
appropriate for most projects• Project on the road to failure frequently exhibit these
symptoms:• Extended integration periods• Late design breakage• Late risk resolution• Focus on documents and reviews
Requirements
Design
Implementation
Test
Module III. Software Design 80
E. Software Design Strategies and Methods - 8
Design Fundamentals• Three aspects of all information systems:
• Data, structure, procedures• Each of these are addressed during software design
• Data Design• Architectural Design
• a.k.a. high-level or preliminary• Procedural
• a.k.a low-level or detailed
Module III. Software Design 81
E. Software Design Strategies and Methods - 9
Design Fundamentals (cont.)• Proven methods help designers by providing:
• A mechanism translating the physical problem to its design representation
• A notation for representing functional components and their interfaces
• Heuristics for refinement and partitioning• Guidelines for quality assessment
• Fundamental concepts of software engineering:• Stepwise refinement• Architecture• Program structure• Data structure• Modularity• Abstraction• Information hiding
Module III. Software Design 82
E. Software Design Strategies and Methods - 10
Fundamentals Defined• Stepwise Refinement• Abstraction• Software Architecture• Program Structure
Module III. Software Design 83
E. Software Design Strategies and Methods - 11
Fundamentals Defined (cont.)• Data Structure• Modularity• Software Procedure• Information Hiding
Module III. Software Design 84
E. References
• [RV95] Robert L. Vienneau and Roy Senn, A State of the Art Report: Software Design Methods, Data & Analysis Center for Software (DACS), March 1995
• [WR01] Walker Royce, Software Project Management, A Unified Framework, Addison-Wesley, Boston, MA, 2001
Module III. Software Design 85
F. Human Factors in Software Design
What is Human Factors Design?• Specification of how users use a system• Considers
• Working environment• Background• Ergonomics• Cognitive capabilities
Module III. Software Design 86
F. Human Factors in Software Design - 2
User Interface Basics• What is the User Interface?
• Menus• Windows• Keyboard• Mouse• Sounds
Module III. Software Design 87
F. Human Factors in Software Design - 3
UI Design Overview• Interface must be match to the task• Specific guidelines
• Menu design• Icon labels• Placement of screen elements
Module III. Software Design 88
F. Human Factors in Software Design - 4
User Interface Design• Prototype User Interface
• Screen mock-ups• Screen navigation
• Intended to obtain feedback
Module III. Software Design 89
F. Human Factors in Software Design - 5
Steps in defining the User Interface• Describe the characteristics of users• Define the navigation map • Detail the design of the user-interface elements • Design the user actions of the primary windows
Module III. Software Design 90
F. Human Factors in Software Design - 6
DoD Mil Std 1472
This standard establishes general human engineering criteria for design and development of military systems, equipment and facilities. Its purpose is to present human engineering design criteria, principles and practices to be applied in the design of systems, equipment and facilities so as to:
Achieve required performance by operator, control and maintenance personnel
Minimize skill and personnel requirements and training time
Achieve required reliability of personnel-equipment combinations
Foster design standardization within and among systems
Module III. Software Design 91
F. References
[CL94] Clayton Lewis and John Rieman, Task-Centered User Interface Design: A Practical Introduction, ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-Design-Book, 1994
[DD89] DoD Military Standard 1472D Human Engineering Design Criteria for Military Systems Equipment and Facilities, March 14, 1989
[RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004
Module III. Software Design 92
G. Software and System Safety
• Computers are pervasive• Automobiles• Consumer electronics• Medical devices• Avionics systems• Weapon systems
• Virtually nothing manufactured in the U.S. today is not impacted by computers
• Complexities are ever increasing• Safety has been and will continue to be a very important
issue in software engineering
Module III. Software Design 93
G. Software and System Safety - 2
Types of Errors • Algorithmic faults• Computational faults• Documentation faults• Stress or overload faults• Capacity and boundary faults
Module III. Software Design 94
G. Software and System Safety - 3
More Types of Errors• Timing and coordination faults• Throughput and performance faults• Recovery faults• Hardware and system software faults• Standard and procedures faults
Module III. Software Design 95
G. Software and System Safety - 4
Hazard Identification• Easiest way to identify hazards is after the occurrence• Obviously the hazard should be avoided• The only valid method therefore is to develop a list of
potential hazards before the system is produced• Three techniques:
• Delphi• Joint Application Design (JAD)• Hazard and Operability Analysis
Module III. Software Design 96
G. Software and System Safety - 5
Analyzing Hazards • The purpose of hazard analysis is to examin the system and
determine which components of the system may lead to a mishap
• Two basic strategies:• Inductive techniques, e.g. an event tree analysis and
failure modes and effects analysis• Deductive techniques, e.g. fault tree analysis
Module III. Software Design 97
G. Software and System Safety - 6
Fault Tree Analysis• Starts with a particular undesirable event and provides an
approach for analyzing the causes of this event• Once the undesirable event has been chosen, it is used as
the top event of a fault tree diagram• The fault tree is a graphical representation of the various
combinations of events that lead to the undesired event• The system is then analyzed to determine all the likely ways
in which that undesired event could occur• The faults may be caused by component failures, human
failures, or any other events that could lead to the undesired events
Module III. Software Design 98
G. Software and System Safety - 7
Event Tree Analysis• Event tree analysis is to consider an initiating event in the
system and consider all the consequences of the occurrence of that event, particularly those that lead to a mishap
• Fault tree analysis is backward looking and considers knowledge of past problems
• Event tree analysis is forward looking and considers potential future mishaps