ENGR2720U

ENGR2720 Software Design II

Software and Software Engineering Slides modified from: Introduction to Software Engineering Design (C. Fox) and Software Engineering (R.S. Pressman)

Page 1

ENGR2720U

Course Objective

To become familiar with the design of software. This framework encompasses A process A set of methods (notation) An array of tools This framework is called Software Engineering.

Page 2

ENGR2720U

Why Study Software Engineering?

Software is important because it has an impact of virtually every aspect of our lives. Software engineers have a moral and ethical responsibility to ensure that the software they build does no serious harm and meets the needs of the people who request it and those who use it. This is part of the P. Eng. Code of ethics. Software engineers tend to be concerned with the technical elegance of their software products. Customers tend to be concerned only with whether or not a software product meets their needs and is easy to use.

Page 3

ENGR2720U

SE Triangle for Success

Notation

Process

Tool
Page 4

ENGR2720U

SE Triangle for Success

You can learn a Notation, but if you dont know how to use it (process), you will probably fail. You may have a great process, but if you cannot communicate the process (notation), you will probably fail. If you cannot document the artifacts of your work (tool), you will probably fail.

Page 5

ENGR2720U

Softwares Dual Role as (Product and Vehicle)

Software is a product Delivers computing potential Produces, manages, acquires, modifies, displays, or
transmits information

Software is a vehicle for delivering a product Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software tools)

Page 6

ENGR2720U

Software Challenges

The days of the lone programmer are gone. Modern software is developed by teams of software specialists. Yet, the software developer's concerns have remained the same. Why does software take so long to complete? Why does it cost so much to produce? Why can't all errors be found and removed before
software is delivered to the customer?

A clear answer is not readily available what are your views on this?
Page 7

ENGR2720U

What is Software?
Software is a set of items or objects that form a configuration that includes programs documents data ...

Page 8

ENGR2720U

Why is Software Different?

Software is engineered, not manufactured: Therefore software is developed. For both quality is
achieved through good design but the manufacturing phase for hardware can introduce quality problems that are either non-existent (or easily corrected) in software. Software costs are concentrated in Engineering

Software doesnt wear out but it deteriorates!: The failure rate in hardware is like a cup shaped

curve, high in the beginning and end of its lifetime. Software failure rate is ideally L shaped.

Page 9

ENGR2720U

Wear vs. Deterioration

Page 10

ENGR2720U

Why is Software Different?

Software is complex: Most software is custom built. Component reuse is in

its infancy compared to hardware components.

Page 11

ENGR2720U

Software Applications
System software:

Heavy interaction with computer hardware, heavy usage by multiple

persons, concurrent operations that require scheduling, resource sharing, complex data structures, and external interfaces.

Application software:

Standalone programs that solve a specific business need. number crunching algorithms. Resides within a product and is meant to implement control features
and functions for end users.

Engineering/scientific software:
Embedded software:

Product-line software:

Provides a specific capability for use by many different customers. Strongly distributed and highly independent. Utilize non-numeric algorithms.
Page 12

WebApps (Web applications): A.I. software:

ENGR2720U

SoftwareNew Categories
Ubiquitous computingwireless networks Netsourcingthe Web as a computing engine Open sourcefree source code open to the computing community (a blessing, but also a potential curse!) Also Data mining Grid computing Cognitive machines Software for nanotechnologies
Page 13

ENGR2720U

Legacy Software

Why must it change?

software must be adapted to meet the needs of
new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment.

Page 14

ENGR2720U

Software Myths
Affect managers, customers (and other nontechnical stakeholders) and practitioners Are believable because they often have elements of truth, but Invariably lead to bad decisions, therefore Insist on reality as you navigate your way through
software engineering

Page 15

ENGR2720U

Management Myths

Myth: We already have a book thats full of standards and procedures for building software. Wont that provide my people with everything they need to know? Reality: Is it used? Is it complete? Is it streamlined to improve time to delivery and still maintain good quality? More likely Not Myth: Mongolian horde Look at this one in the text book. Have you heard of it
before?
Page 16

ENGR2720U

Customer Myths

Myth: A general statement of objectives is sufficient to begin writing programs we can fill in the details later Reality: An ambiguous statement of objectives is a recipe for disaster. Myth: Is software flexible?

Page 17

ENGR2720U

Practitioners Myth

Myth: The only deliverable work product for a successful project is the working program Reality: Documentation provides a foundation for successful engineering and guidance for software support. Is Software Engineering about creating documents?

Page 18

ENGR2720U

A Discipline of Software Design

Page 19

ENGR2720U

Objectives

To explain what design is and how various types of design deal with different aspects of a product To present design as problem solving and outline the roles of abstraction and modeling in design To place design in the software life cycle To survey software engineering design methods

Page 20

ENGR2720U

Topics

Software products and software design Abstraction and modeling Varieties of design Software design in the life cycle Software engineering design methods

Page 21

ENGR2720U

Importance of Software Design We live in a designed world. Design is economically important and effects our quality of life. Software is becoming ubiquitous. The quality of software design has important consequences that software designers should be aware of and take seriously.

Page 22

ENGR2720U

Software Products

A software product is an entity comprised of one or more programs, data, and supporting materials and services that satisfies client needs and desires either as an independent artifact or as essential ingredient in some other artifact.

Page 23

ENGR2720U

Software Design Defined

Software designers do what designers in other disciplines do, except they do it for software products.
Software design is the activity of specifying the mature and composition of software products that satisfy client needs and desire, subject to constraints.

Page 24

ENGR2720U

Design as Problem Solving An especially fruitful way to think about design is as problem solving. Advantages Suggests partitioning information between problem
and solution Emphasizes that there may be more than one good solution (design) Suggests techniques such as changing the problem, trial and error, brainstorming, etc.

Page 25

ENGR2720U

Abstraction

Abstraction is an important problem-solving technique, especially in software design.

Abstraction is suppressing or ignoring some properties of objects, events, or situations in favor of others.

Page 26

ENGR2720U

Importance of Abstraction

Problem simplification Abstracting allows us to focus on the most

important aspects of a problem in (partially) solving it.

Structuring problem solving

Top-down strategy: Solve an abstract version of the problem, then add details (refinement) Bottom-up strategy: Solve parts of a problem and connect them for a complete solution

Page 27

ENGR2720U

Modeling
A model represents a target by having model parts corresponding to target parts, with relationships between model parts corresponding to relationships between target parts.
Target Model

Page 28

ENGR2720U

Modeling in Design

Modeling is used for the following purposes: Problem understanding Design creation Design investigation Documentation Modeling work because models abstract details of the target. Models can fail if important and relevant details are left out.

Page 29

ENGR2720U

Static and Dynamic Models

A static model represents aspects of programs that do not change during program execution.
A dynamic model represents what happens during program execution.

Static model examples include class and object models. Dynamic model examples include state diagrams and sequence diagrams.
Page 30

ENGR2720U

Product vs. Engineering Design

Product designers are concerned with styling

and aesthetics, function and usability, manufacturability and manageability. Industrial designers, (building) architects, interior
designers, graphic designers, etc. Engineering designers are concerned with

technical mechanisms and workings. Structural, mechanical, chemical, and electrical

engineers

Design teams often include both product and engineering designers.

Page 31

ENGR2720U

Software Product Design

Software product design is the activity of specifying software product features, capabilities, and interfaces to satisfy client needs and desires.

Requires skills in user interface and interaction design, communications, industrial design, and marketing

Page 32

ENGR2720U

Software Engineering Design

Software engineering design is the activity of specifying programs and sub-systems, and their constituent parts and workings, to meet software product specifications.

Requires skills in programming, algorithms, data structures, software design principles, practices, processes, techniques, architectures, and patterns
Page 33

ENGR2720U

Waterfall Life Cycle Model

Software Product Life Cycle

Requirements Specification

Design

Implementation

Testing

The waterfall model captures the logical, but not the temporal, relationships between software development activities.

Maintenance

Page 34

ENGR2720U

Design Across the Life Cycle

Software Product Life Cycle

Requirements Specification

Product Design

Design

Engineering Design

Implementation

Testing

Maintenance

Product Redesign and Engineering Redesign

Page 35

ENGR2720U

What Versus How

Traditional way to make the distinction between requirements and design activities Not adequate because Many how specifications turn out to be design

decisions Many what specifications turn out to be client or customer needs or desires

Distinguish requirements from design based on problem solving: requirements activity formulates a problem solved in design
Page 36

ENGR2720U

Design Problems and Solutions

Software Design
Problem: Needs, Desires, Constraints Solution: Features and Capabilities Solution: Interactions Solution: SRS Create High-Level Design

Design Features and Capabilities

Product Design
Design Interactions

Solution: HighLevel Design Solution: LowLevel Design Solution: Design Document

Engineering Design Create Low-Level

Design

Write Code

Solution: Code

Page 37

ENGR2720U

Software Design Method

A software design method is an orderly procedure for generating a precise and complete software design solution that meets clients needs and constraints.

Page 38

ENGR2720U

Design Method Components

Design ProcessA collection of related tasks that transforms a set of inputs into a set of outputs Design NotationsA symbolic representational system Design HeuristicsRules providing guidance, but no guarantee, for achieving some end Design methods also use design principles stating characteristics of design that make them better or worse.
Page 39

ENGR2720U

Design Method Timeline

1971 Niklaus Wirth introduces stepwise refinement. 1974 Stevens, Myers, Constantine introduce structured design. Late 1970s to early 1980s Structured analysis and design methods are dominant. Late 1980s Object-oriented analysis and design methods rise to prominence. 1995 UML 0.8 is released. 2004 UML 2.0 is released.
Page 40

ENGR2720U

In class / tutorial activities

I will use a number of activities in class that: The first of these is an introduction to the formation of teams. The first activity is in the learning modules Activities
section.

Steps: Create a group of 4 persons. Sign your group up in WebCT. Do the activity Submit the deliverables
Page 41

ENGR2720U

Summary
Software design is important. Software design is best thought of as problem solving. Abstraction is a fundamental design technique. Modeling (which relies on abstraction) is a basic design tool. Software design comprises both product and engineering design. Product design occurs mainly in the requirements specification phase; engineering design mainly in the design and implementation phases. OO analysis and design methods are now dominant.
Page 42