csdp preparation course module iii software design l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CSDP Preparation Course Module III: Software Design PowerPoint Presentation
Download Presentation
CSDP Preparation Course Module III: Software Design

Loading in 2 Seconds...

play fullscreen
1 / 143

CSDP Preparation Course Module III: Software Design - PowerPoint PPT Presentation


  • 251 Views
  • Uploaded on

CSDP Preparation Course Module III: Software Design. 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 Software Design Quality Analysis and Evaluation

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CSDP Preparation Course Module III: Software Design' - glain


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
specifications
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
  • Software Design Quality Analysis and Evaluation
  • Software Design Notations and Documentation
  • Software Design Strategies and Methods
  • Human Factors in Software Design
  • Software and System Safety

Module III. Software Design

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

Objectives

Module III. Software Design

organization
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

introduction
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

Module III. Software Design

a software design concepts
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

a software design concepts 2
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

a software design concepts 3
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

Module III. Software Design

a software design concepts 4
A. Software Design Concepts - 4

The Problem (cont.)

  • Ill-Defined Problems:
    • The problem it is not clear from the beginning on what the problem is and thus, what a solution is
    • Finding a solution requires in addition to find the real problem
    • Solving and specifying develop in parallel and drive each other
  • Solutions to Ill-Defined Problems:
    • Often such that they still could be improved
    • Up to the problem solver to decide when enough is enough

Module III. Software Design

a software design concepts 5
A. Software Design Concepts - 5

Key Definitions

  • Software Engineering: A discipline that encompasses the process associated with software development, the methods used to analyze, design and test computer software, the management techniques associated with the control and monitoring of software projects and the tools used to support process, methods, and techniques
  • Analysis: A set of activities that attempt to understand and model customer needs and constraints
  • Design: An activity that translates the requirements model into a more detailed model that is the guide to implementation of the software
  • Methodology: A codified set of procedures for some phase of software engineering, such as analysis and design.
  • Abstraction: The level of technical detail of some representation of a software system

Module III. Software Design

a software design concepts 6
A. Software Design Concepts - 6

Key Definitions (cont.)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

a software design concepts 7
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

a software design concepts 8
A. Software Design Concepts - 8

Activities Associated with the RUP Analysis & Design Discipline

Module III. Software Design

a software design concepts 9
A. Software Design Concepts - 9

Artifacts Associated with the RUP Analysis & Design Discipline

Module III. Software Design

a software design concepts 10
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

a software design concepts 11
A. Software Design Concepts - 11

Design Phases

Two Types of Design

  • Architecture
  • Detailed

Architecture Design

Specifycomponents, their interfaces, and their interactions with other components

Detailed Design

Specify the internal structure and behavior of each component

Module III. Software Design

a software design concepts 12
A. Software Design Concepts - 12

Software Engineering Approaches

Several General Approaches to Software Engineering

  • 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

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

a references cont
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

a quiz 1
Which is a true statement regarding software design?

a) It produces a description of the software’s internal construction

b) It describes the software’s architecture

c) It bridges the gap between software requirements and software code

1) a & c

2) b

3) a, b, & c

4) c

A. Quiz - 1

Module III. Software Design

a quiz 2
The purpose of a Software Design Description is used to document

a) requirements traceability

b) high-level design

c) low-level design

1) a & b

2) b & c

3) a, b, & c

4) b

A. Quiz - 2

Module III. Software Design

a quiz 3
Detailed design

a) is also known as low-level design

b) specifies internal component structure

c) specifies component behavior

1) a & b

2) b & c

3) a & c

4) a, b, & c

A. Quiz - 3

Module III. Software Design

a quiz 4
Which of the following is not a valid design approach?

a) inside out

b) top-down

c) bottom-up

d) opportunistic

1) a

2) a & d

3) b & d

4) d

A. Quiz - 4

Module III. Software Design

a quiz 5
A. Quiz - 5

Pseudocode is more appropriate for low-level design than architectural design.

a.) True

b.) False

Module III. Software Design

a quiz 6
A. Quiz - 6

Software design is most concerned with which of the following:

a.) synthesizing a domain analysis into an implementation

b.) defining components

c.) describing a solution to some problem

d.) the object-oriented architecture of the solution space

1.) a

2.) b

3.) c

4.) e

Module III. Software Design

b software architecture
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

b software architecture 2
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

b software architecture 3
B. Software Architecture - 3

Architecture-Based Process

An example of an architecture-first approach:

  • Create the business case for the system
  • Analyze the requirements
  • Decide on a software architecture
  • Specify the architecture
  • Communicate the architecture
  • Evaluate the architecture
  • Implement the system based on the architecture
  • Ensure the implementation conforms to the architecture

Module III. Software Design

b software architecture 4
B. Software Architecture - 4

Introducing Model Driven Architecture

  • Relatively new approach to building software
  • Sponsored by the Object Management Group (OMG)
  • Based on a platform-independent model (PIM)
  • Described with Unified Modeling Language (UML)

Module III. Software Design

b software architecture 5
B. Software Architecture - 5

Model Driven Architecture (MDA)

Primary goals of MDA

  • Portability
  • Interoperability
  • Reusability

Using these technologies:

Unified Modeling Language (UML)

Meta-Object Facility (MOF)

XML Meta-Data Interchange (XMI)

Common Warehouse Meta-model (CWM)

Module III. Software Design

b software architecture 6
B. Software Architecture - 6

MDA Overview

Model-Driven Architecture separates the specification of the operation of a system from the details of the way that system uses the capabilities of its platform.

MDA provides an approach for

  • Specifying a system independently of the platform that supports it
  • Specifying platforms
  • Choosing a particular platform for the system
  • Transforming the system specification into one for a particular platform

Module III. Software Design

b software architecture 7
System

Model

Model-Driven

Architecture

Viewpoint

View

Platform

Application

Platform Independence

Viewpoints

Computation Independent Model (CIM)

Platform Independent Model (PIM)

Platform Specific Model (PSM)

Platform Model

Model Transformation

Pervasive Services

Implementation

B. Software Architecture - 7

Key Model Driven Architecture Concepts

Module III. Software Design

b software architecture 8
B. Software Architecture - 8

Definition of System:

A collection of elements that are organized to work together to accomplish some goal

Module III. Software Design

b software architecture 9
B. Software Architecture - 9

Model

  • A model is a representation of a system
  • Often a combination of drawings and text
  • The text may be in terms of
    • A modeling language
    • Natural language
  • Another Definition of model:

A collection of views where each view describes a system from a particular perspective

Module III. Software Design

b software architecture 10
B. Software Architecture - 10

Model Driven

An approach to system and software specification that focuses on the evolution of one or more models, where each model describes some relevant aspect of the system

Benefits:

  • Facilitates communication
  • Reduces complexity

Module III. Software Design

b software architecture 11
B. Software Architecture - 11

Viewpoints & Views

Viewpoint

Technique for abstraction using a selected set of architectural concepts and structuring rules

View

A perspective of a system from a point of view of a viewpoint

MDA prescribes 3 types of viewpoints

  • Computation independent
  • Platform independent
  • Platform specific

Module III. Software Design

b software architecture 12
B. Software Architecture - 12

Platform

A platform is a set of subsystems and technologies

Provides a coherent set of functionality through

  • Interfaces
  • Usage patterns

Any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented

Examples:

  • J2EE
  • Microsoft Windows
  • Linux

Module III. Software Design

b software architecture 13
B. Software Architecture - 13

Platform Independence

  • Quality of a model
  • Not specific for a particular platform
  • Able to be implemented on any number of platforms, as appropriate

CORBA

J2EE

A platform independent distributed messaging model could be implemented, for example, on either CORBA or J2EE

Module III. Software Design

b software architecture 14
B. Software Architecture - 14

Computation Independent Model (CIM)

  • View of the system independent of the system structure
  • Also known as a domain model
    • Terminology familiar to those in the application’s domain
  • Bridges the gap between domain experts and design experts
  • Facilitates clear specification of the problem domain

VS.

Module III. Software Design

b software architecture 15
B. Software Architecture - 15

Platform Independent Model (PIM)

  • More specific than a Computational Independent Model
  • Less specific that a Platform Dependent Model
  • Details of the implementation on a particular platform are omitted
  • Could be implemented on multiple platforms

VS.

Module III. Software Design

b software architecture 16
B. Software Architecture - 16
  • Platform Specific Model (PSM)
  • More specific than a Platform Independent Model
  • Details of the implementation on a particular platform are provided
  • An implementation on a specific platform

VS.

Module III. Software Design

b software architecture 17
B. Software Architecture - 17

Model Transformation

Process by which one model is converted to another model in the same system

Software examples:

Computation Independent Model to a Platform Independent Model

Platform Independent Model to a Platform Specific Model

Analysis model to a design model

An implementation model to a deployment model

Module III. Software Design

b software architecture 18
B. Software Architecture - 18

MDA prescribes a series of model transformations

CIM to PIM to PSM

CIM

PIM

PSM

Use Cases

Analysis Classes

Enterprise Java Beans

Module III. Software Design

b software architecture 19
B. Software Architecture - 19

Manual vs. Automatic Transformations

  • Manual transformations are the traditional approach
    • Design decisions are made
    • Design is implemented
    • Low automation in most cases
  • Component-based development is an improvement
    • Canned, off-the-shelf middleware is common today
      • IBM Websphere
      • Microsoft .NET
    • Application frameworks are also available
      • Struts
      • Java Server Faces
  • Some tools available today can automate transformations
    • Generate executable applications via the PIM
    • E.g. Rational Rose Technical Developer, Telelogic TAU

Module III. Software Design

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

b quiz 1
B. Quiz - 1

Architecture design deals with components and

a) their interfaces

b) class structures

c) their relationships

1) a

2) a & b

3) a & c

4) b & c

Module III. Software Design

b quiz 2
B. Quiz - 2

Model Driven Architecture is an approach to specifying architecture that uses:

a) Platform independent models

b) Platform specific models

c) Computation independent viewpoints

d) Model transformations

  • a & b
  • a, b, & d
  • d
  • all of the above

Module III. Software Design

b quiz 3
B. Quiz – 3

A use case model is an example of a:

  • Computational independent model
  • Platform independent model
  • Platform specific model
  • a
  • b
  • c

Module III. Software Design

b quiz 4
B. Quiz – 4

An architect is concerned about the system’s:

a.) quality

b.) usability

c.) performance

d.) maintainability

1.) all of the above

2.) a & d

3.) b, c & d

4.) c & d

Module III. Software Design

b quiz 5
B. Quiz - 5

It is the responsibility of the architect to ensure the component interfaces are used in the manner intended.

1.) True

2.) False

Module III. Software Design

c software design quality analysis evaluation
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

c software design quality analysis evaluation 2
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

c software design quality analysis evaluation 3
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”

VS.

Module III. Software Design

c software design quality analysis evaluation 4
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

c software design quality analysis evaluation 5
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

c software design quality analysis evaluation 6
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

c software design quality analysis evaluation 7
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

c software design quality analysis evaluation 8
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

c software design quality analysis evaluation 9
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

c software design quality analysis evaluation 10
C. Software Design Quality Analysis & Evaluation - 10

Quality attributes that are discernable at system runtime

Performance

Two Aspects of Performance:

  • Response time
  • Number of transactions per some time interval

SecurityMeasure of the system’s ability to resist unauthorized usage

Availability

Measure of the proportion of time a system is up and running

Functionality

Ability of the system to do the work for which it was intended

Usability

Extent to which a system is easy learn and use on an ongoing basis

Module III. Software Design

c software design quality analysis evaluation 11
C. Software Design Quality Analysis & Evaluation - 11

Quality attributes that are not discernable at system runtime

Modifiability

Ability of the system to be enhanced and maintained over time

Portability

Ability of the system to run in different operating environments

Reusability

Ability of the system, or parts thereof, to be used to construct other systems

Integrability

Ability of the various components of a system to be made to work together

Testability

Ability to objectively measure the system against its requirements

Module III. Software Design

c software design quality analysis evaluation 12
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

c software design quality analysis evaluation 13
C. Software Design Quality Analysis & Evaluation - 13

What is a Good Design?

  • Well Structured
  • Simple
  • Efficient
  • Adequate
  • Flexible
  • Practical
  • Implementable

Module III. Software Design

c software design quality analysis evaluation 14
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

c software design quality analysis evaluation 15
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

c software design quality analysis evaluation 16
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

c software design quality analysis evaluation 17
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

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

c quiz 1
C. Quiz - 1

System performance attributes include the following:

  • Volume of transactions
  • Response time
  • Reliability of results
  • a
  • b
  • c
  • a & b
  • all of the above

Module III. Software Design

c quiz 2
C. Quiz - 2

A practical design should:

  • anticipate all future component uses
  • anticipate current and future requirements
  • provide the most cost-effective solution
  • specify the minimum number of components
  • a
  • a & b
  • c
  • all of the above
  • none of the above

Module III. Software Design

c quiz 3
C. Quiz - 3

Whether or not the software application is attractive to the target audience is a valid quality attribute.

1.) True

2.) False

Module III. Software Design

c quiz 4
C. Quiz - 4

Which of the following, if taken literally, is extremely difficult to achieve:

a.) Total Design Independence (TDI)

b.) Six Sigma

c.) Formal design inspection

d.) Security

1.) a

2.) b

3.) c

4.) d

Module III. Software Design

c quiz 5
C. Quiz - 5

Which can most readily be determined via a call tree?

a.) Cyclomatic complexity

b.) Cohesion

c.) Coupling

d.) Fan-Out

1.) a

2.) b

3.) c

4.) d

Module III. Software Design

d software design notations and documentation
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

d software design notations and documentation 2
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

Guidelines

Model

Elements

Notation

Module III. Software Design

d software design notations and documentation 3
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

d software design notations and documentation 4
D. Software Design Notations and Documentation - 4

Five Aspects of Structured Design

  • Form of the problem guides the form of the solution
  • Reduces complexity by organizing the system into a hierarchy of “black boxes”
  • Uses graphical tools to render systems readily understandable
  • Provides solution strategies based on a well-defined problem statement
  • Provides criteria for evaluating the quality of the design

Module III. Software Design

d software design notations and documentation 5
D. Software Design Notations and Documentation - 5

Four goals of Structured Design

  • Each black box should solve well-defined piece of the problem
  • The system should be partitioned so that the function of each black box is easy to understand
  • Partitioning should be done so that any connection between black boxes is introduces only because of a connection between pieces of the problem
  • Partitioning should assure that the connections between black boxes are made as simple as possible

Module III. Software Design

d software design notations and documentation 6
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

d software design notations and documentation 7

Data Source/Sink

Process

Data Flow

Data Store

D. Software Design Notations and Documentation - 7

Data Flow Diagram Example

Module III. Software Design

d software design notations and documentation 8

Module

Data

Call

D. Software Design Notations and Documentation - 8

Structure Chart Example

Module III. Software Design

d software design notations and documentation 9
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

d software design notations and documentation 10
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

d software design notations and documentation 11
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

d software design notations and documentation 12
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

d software design notations and documentation 13
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

d software design notations and documentation 14
D. Software Design Notations and Documentation - 14

Primary 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

d software design notations and documentation 15
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

d software design notations and documentation 16

Static Diagrams

Class

Diagrams

Use-Case

Diagrams

Object

Diagrams

Sequence

Diagrams

Component

Diagrams

Collaboration

Diagrams

Models

Deployment

Diagrams

Statechart

Diagrams

Activity

Diagrams

Dynamic Diagrams

D. Software Design Notations and Documentation - 16

Courtesy IBM Rational Software

Module III. Software Design

d software design notations and documentation 17
D. Software Design Notations and Documentation - 17

Class Diagram

Contains classes, interfaces, collaborations, and relationships

Models system vocabulary, collaborations, database schema

Module III. Software Design

d software design notations and documentation 18
D. Software Design Notations and Documentation - 18

Object Diagram

Contains objects and links

Models objects structures and relationships

Module III. Software Design

d software design notations and documentation 19
D. Software Design Notations and Documentation - 19

Use Case Diagram

Contains use cases, actors, and relationships

Models the context and requirements of a system

Module III. Software Design

d software design notations and documentation 20
D. Software Design Notations and Documentation - 20

Sequence Diagram

Contains objects, links, and messages

Models flows of control by time ordering

Module III. Software Design

d software design notations and documentation 21
D. Software Design Notations and Documentation - 21

Collaboration Diagrams

Contains objects, links, and messages

Models flows of control by logical organization

Module III. Software Design

d software design notations and documentation 22
D. Software Design Notations and Documentation - 22

Statechart Diagram

Contains simple states, composite states, transitions

Models reactive objects

Module III. Software Design

d software design notations and documentation 23
D. Software Design Notations and Documentation - 23

Activity Diagram

Contains action and activity states, transitions, and objects

Models a workflow or operation

Module III. Software Design

d software design notations and documentation 24
D. Software Design Notations and Documentation - 24

Component Diagram

Contains components, interfaces, and relationships

Models source code, executables, and physical databases

Module III. Software Design

d software design notations and documentation 25
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

Module III. Software Design

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

d quiz 1
D. Quiz - 1

Which of these is not a stated reason for creating models:

a) Facilitate communication

b) Provide a blueprint for our system

c) Assures architectural soundness

d) Demonstrate progress

1. a

2. b

3. c

4. d

5. a & c

Module III. Software Design

d quiz 2
D. Quiz - 2

A structured approach to software design is also known as:

a) Object-Oriented

b) Data-centric

c) Functional

d) Model-based

1. a

2. c

3. b & d

4. a & d

Module III. Software Design

d quiz 3
D. Quiz - 3

A module is considered to be a(n):

a) Object

b) Program

c) Black-box

d) Component

1. a

2. b

3. c

4. c & d

Module III. Software Design

d quiz 4
D. Quiz - 4

In a structured approach, a data flow diagram is transformed into a:

a) Requirements

b) Design

c) Structure Chart

1. a

2. b

3. c

4. b & c

Module III. Software Design

d quiz 5
D. Quiz - 5

Which of the follow is not true of the Unified Modeling Language?

a) Defines a process for software specification

b) Facilitates the interchange of models

c) Specifies the interface to model repositories

1. a

2. a & c

3. b

4. all of the above are not true

Module III. Software Design

d quiz 6
D. Quiz - 6

Identify which of the UML diagrams are static ("S") vs. dynamic ("D")

___ Activity

___ Class

___ Collaboration

___ Component

___ Deployment

___ Object

___ Sequence

___ Statechart

___ Use Case

Module III. Software Design

e software design strategies and methods
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

e software design strategies and methods 2
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

e software design strategies and methods 3
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

e software design strategies and methods 4
E. Software Design Strategies and Methods - 4

Historical Methods

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

Module III. Software Design

e software design strategies and methods 5
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

e software design strategies and methods 6
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

e software design strategies and methods 7

Requirements

Design

Implementation

Test

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

Module III. Software Design

e software design strategies and methods 8
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

e software design strategies and methods 9
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

e software design strategies and methods 10
E. Software Design Strategies and Methods - 10

Fundamentals Defined

  • Stepwise Refinement
  • Abstraction
  • Software Architecture
  • Program Structure

Module III. Software Design

e software design strategies and methods 11
E. Software Design Strategies and Methods - 11

Fundamentals Defined (cont.)

  • Data Structure
  • Modularity
  • Software Procedure
  • Information Hiding

Module III. Software Design

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

e quiz 1
E. Quiz - 1

A functional decomposition approach to software design is compatible with object-oriented techniques.

1) True

2) False

Module III. Software Design

e quiz 2
E. Quiz - 2

Which lifecycle approach better handles requirements change?

a) Waterfall

b) Iterative

1) a

2) b

3) Not much difference

Module III. Software Design

e quiz 3
E. Quiz - 3

The structure of a software system is addressed during

a) Data design

b) Architecture design

c) Detailed design

1) a

2) b

3) c

4) All, provided an iterative approach

Module III. Software Design

e quiz 4
E. Quiz - 4

Stepwise refinement is a ________ approach.

a) Bottom-up

b) Top-down

c) Procedural

1) a & c

2) b & c

3) b

4) c

Module III. Software Design

e quiz 5
E. Quiz - 5

Software procecure pertains to

a) the lifecycle model

b) the development process

c) software processing

d) subcontractor management

1) a

2) b

3) c

4) d

Module III. Software Design

f human factors in software design
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

f human factors in software design 2
F. Human Factors in Software Design - 2

User Interface Basics

  • What is the User Interface?
    • Menus
    • Windows
    • Keyboard
    • Mouse
    • Sounds

Module III. Software Design

f human factors in software design 3
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

f human factors in software design 4
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

f human factors in software design 5
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

f human factors in software design 6
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

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

f quiz 1
F. Quiz - 1

Human factors engineering is a subtopic of software engineering.

a.) True

b.) False

Module III. Software Design

f quiz 2
F. Quiz - 2

The user interface model traces to which other model?

a.) Use case model

b.) Business model

c.) Implementation model

d.) Deployment model

Module III. Software Design

f quiz 3
F. Quiz - 3

The purpose of DoD Mil Std 1472 is to facilitate the development of systems that:

a.) minimize the need for maintenance personnel

b.) minimize skill requirements for system usage

c.) achieve sufficient reliability of human-equipment combinations

d.) standardize the approach to human factors implementation

1.) all of the above

2.) none of the above

3.) b & c

4.) b, c, & d

Module III. Software Design

f quiz 4
F. Quiz - 4

Which type of system is has the least concern for human factors:

a.) a computer operating system

b.) a batch process

c.) a car radio

d.) a voice activated dictation machine

1.) a

2.) b

3.) c

4.) d

Module III. Software Design

g software and system safety
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

g software and system safety 2
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

g software and system safety 3
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

g software and system safety 4
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

g software and system safety 5
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

g software and system safety 6
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

g software and system safety 7
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

Module III. Software Design

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

Module III. Software Design

g quiz 1
G. Quiz - 1

It is easiest to identify hazards:

a.) during the analysis phase

b.) during design phase

c.) during the construction phase

d.) during the testing phase

e.) post-deployment

1.) a

2.) b

3.) c

4.) d

5.) e

Module III. Software Design

g quiz 2
G. Quiz - 2

It is best to identify hazards:

a.) during the analysis phase

b.) during design phase

c.) during the construction phase

d.) during the testing phase

e.) post-deployment

1.) a

2.) b

3.) c

4.) d

5.) e

Module III. Software Design