software design 3 dr. pedro meja alvarez departamento de computacion cinvestav-ipn

Software Design 3

Dr. Pedro Meja AlvarezDepartamento de Computacion

CINVESTAV-IPN

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


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


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


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.


• 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.


• 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.


• 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.


• 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



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


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



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.




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



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



Activities Associated with the RUP Analysis & Design Discipline



Artifacts Associated with the RUP Analysis & Design Discipline



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



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



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


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


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


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


B. Software Architecture - 2

Software architecture is also concerned with:• Usage• Functionality• Performance• Resilience• Reuse• Comprehensibility• Economic and technology constraints and tradeoffs• Aesthetics


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


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


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


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



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”



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



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


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



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



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



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



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



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



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



What is a Good Design?• Well Structured• Simple• Efficient• Adequate• Flexible• Practical• Implementable



Design Quality

Techniques to assess design quality include:• Design Verification• Design Analysis• Design Reviews• Design Audit• Informal Design Walkthrough• Formal Design Inspection



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



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



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


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


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


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



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.



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



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



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



Process

Data Store

Data Source/Sink

Data Flow

Data Flow Diagram Example



Call

Data

Module

Structure Chart Example



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



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


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



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



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


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



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



Dynamic Diagrams

Static Diagrams

ActivityDiagrams

Models

SequenceDiagrams

CollaborationDiagrams

StatechartDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagramsUse-Case

Diagrams

Courtesy IBM Rational Software



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..*



Object Diagram

Contains objects and links

Models objects structures and relationships



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>>



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



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)



Statechart Diagram

Contains simple states, composite states, transitions

Models reactive objects



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



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



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


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


E. Software Design Strategies and Methods

• Design methods guide the software designer• This section provides details on design

• Fundamentals• Models• Historical background


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



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



Historical Methods• Flow charts• Program Design Languages (PDL)• Forms• Data structures• Data flow



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



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



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



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



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



Fundamentals Defined• Stepwise Refinement• Abstraction• Software Architecture• Program Structure



Fundamentals Defined (cont.)• Data Structure• Modularity• Software Procedure• Information Hiding


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


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


F. Human Factors in Software Design - 2

User Interface Basics• What is the User Interface?

• Menus• Windows• Keyboard• Mouse• Sounds



UI Design Overview• Interface must be match to the task• Specific guidelines

• Menu design• Icon labels• Placement of screen elements



User Interface Design• Prototype User Interface

• Screen mock-ups• Screen navigation

• Intended to obtain feedback



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



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


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


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


G. Software and System Safety - 2

Types of Errors • Algorithmic faults• Computational faults• Documentation faults• Stress or overload faults• Capacity and boundary faults



More Types of Errors• Timing and coordination faults• Throughput and performance faults• Recovery faults• Hardware and system software faults• Standard and procedures faults



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



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



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



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


G. References

[PP92] Patrick R. Place and Xyo C. Kang, Safety-Critical Software: Status Report and Annotated Bibliography, CMU/SEI-92-TR-5, Carnegie Mellon, Pittsburgh, PA 1992

software design 3 dr. pedro meja alvarez departamento de computacion cinvestav-ipn

Documents

software design software

software design approachesto

software design processto

design problems

design activity

design situationsdesign

design results

software designmodule