软件工程

Software Engineering

主讲人：张敏灵

Email: zhangml@seu.edu.cn

URL: http://cse.seu.edu.cn/PersonalPage/zhangml/

教材

Bernd Bruegge, Allen H. Dutoit

Object-Oriented Software

Engineering: Using UML,

Patterns, and Java, 3rd edition

Prentice Hall, 2010

面向对象软件工程：使用

UML、模式与Java, 第3版

清华大学出版社, 2011

布吕格[美], 迪图瓦[美]

课程信息

学时/学分

1-16周（周二），3学分

讲授内容(红色标注部分)

Part I: 软件工程导论、UML等

Part II: 需求获取、分析、设计、测试等

Part III: 配置管理、项目管理、软件生命周期等

考核方式

平时成绩(出勤率+作业)：5%

课程Project：20%

期末考试：75%

http://cse.seu.edu.cn/PersonalPage/zhangml/

http://cse.seu.edu.cn/PersonalPage/zhangml/

Usi

ng U

ML

, P

atte

rns,

and J

ava

Ob

ject

-Ori

ente

d S

oft

wa

re E

ng

inee

rin

g

Requirements for this Class

You are proficient in a programming language, but you have no experience in analysis or design of a system

You want to learn more about the technical

aspects of analysis and design of complex

software systems

Objectives of the Class

Appreciate Software Engineering:

Build complex software systems in the context of

frequent change

Understand how to

Produce a high quality software system within time

While dealing with complexity and change

Acquire technical knowledge (main emphasis)

Acquire managerial knowledge

A Few Examples

Year 1900 bug

In 1992, Mary from Winona, Minnesota, received an invitation

to attend a kindergarten. Mary was 104 at the time.

Leap-year bug

A supermarket was fined $1000 for having meat around 1 day

too long, on February 1988. The computer program printing

the expiration date without considering 1988 was a leap year.

Late and over budget

In 1995, bugs in the automated luggage system of the new

Denver International Airport caused suitcases to be chewed

up. The airport opened 16 months later, $3.2 billion over

budget, with a mostly manual luggage system.

Cost: $10 Billion, millions of dollars more than planned

Time: 3 years late

Quality: First launch of Columbia was cancelled because of a

synchronization problem with the Shuttle's 5 onboard

computers.

Error was traced back to a change made 2 years earlier when a

programmer changed a delay factor in an interrupt handler from 50

to 80 milliseconds.

The likelihood of the error was small enough, that the error caused

no harm during thousands of hours of testing.

Substantial errors still exist.

Astronauts are supplied with a book of known software problems

"Program Notes and Waivers".

Another Example: Space Shuttle

Software

Characteristics of Software Systems

Software systems are complex creations

Perform many functions

Achieve many different, and often conflicting, objectives

Comprise many components

Many participants from different disciplines take part in

Development process and software life cycle often spans many years

……

Software systems are subject to constant changes

Clients/end-user’s requirements change

Errors are discovered

Developers have a better understanding

New technologies emerge, staff turn-around

……

20

Software Engineering: Definition

Software Engineering (SE) is a collection of techniques, methodologies and tools that help with the production of

a high quality software system

with a given budget

before a given deadline

while change occurs.

SE: A More Detailed Definition

Software engineering is a modeling, problem-solving,

knowledge acquisition, and rationale-driven activity.

Modeling

Software engineers deals with complexity through modeling

Problem-solving

Models are used to search for an acceptable solution within

budget and time constraints

Knowledge acquisition

Software engineers collect data, organize it into information,

and formalize it into knowledge

Rationale-driven

Software engineers need to capture the context in which

decisions were made and the rationale behind these decisions

Modeling

What is model?

An abstract representation of a system

Enables us to answer questions about the system; Allows us to

visualize and understand systems

Why modeling for software engineers

Understand the environment which the system operates

Train traffic control train signaling procedures; Stock trading system

trading rules

Build a model of the application/problem domain

Understand the system they could build

Evaluate different solutions and trade-offs

Build a model of the solution domain

Object-Oriented (OO) Combine application & solution

domains by modeling both with objects and relationships

Problem Solving

Engineering is a problem-solving activity So does SE

Five steps of engineering method

Formulate the problem Analyze the problem Search for solutions

Decide on the appropriate solution Specify the solution

Six steps of object-oriented software engineering (OOSE)

Requirement elicitation + Analysis

Formulate the problem with client and build the application domain model

System design

Analyze the problem, break it into smaller pieces, select general strategies for

designing the system

Object design

Select detail solutions for each piece and decide on the appropriate solution

Implementation

Realize the system by translating the solution domain model into executable codes

Testing

Evaluate the appropriateness of the respective models

Knowledge Acquisition A common mistake

The acquisition of knowledge needed to build a system is linear

Both for software engineers and managers

Knowledge acquisition is a nonlinear process

The addition of a new piece of information may invalidate all the

knowledge we have acquired for understanding

Implications: We must be prepared to start from scratch

Software life cycle

Waterfall model: assume linear dependencies in software development

Risk-based development: anticipate surprises at late in a project by

identifying the high-risk components

Issue-based development: Any development activity in OOSE can influence

any other activity

All activities are executed in parallel

Difficult to manage than linear development process

Rationale-Driven

Difficult life of a software engineer

Assumptions that developers make about a system change constantly

The solution domain models are in constant flux

Design and implementation faults discovered during testing

Usability problems discovered during user evaluation

The emergence of a new technology

……

A typical task of software engineers

Change a currently operational software system Capturing and accessing the

rationale of a system is necessary

A non-trivial task

For every decision made, several alternatives may have been made, considered

and argued

Rationale information (context in which decision being made) is often inexplicit

SE Concepts

Project

Whose purpose is to develop a software system

Composed of a number Activities

Activity

Composed of a number Tasks

Task

Consumes resources and produces WorkProduct

Resources

Participants, Time, or Equipment

WorkProduct

System, Model or Document

UML Diagram for SE Concepts

Participants and Roles

Participants: All the persons involved in the project

The client orders and pays for the system

The developers construct the system

The project manager plans and budgets the project and coordinates the

developers and the client

The end users are supported by the system

Role: A set of responsibilities in the project

A role is associated with a set of tasks

It is assigned to a participant

The same participant can fill multiple roles

A TicketDistributor system

Roles for the TicketDistributor Project

Systems and Models

System

A collection of interconnected parts

E.g.: A TicketDistributor for underground trains

Model

Any abstraction of the system

Blueprints for TicketDistributor , schematics of its electrical

wiring, objects models of its software, etc.

A project itself is a system that can be modeled

Project schedule

Budget

Planned deadline

……

Work Products

Work Product: An artifact produced during development

A document, a piece of software, a system, a model, etc.

Internal work product: for the project’s internal consumption

Deliverable: must be delivered to a client (Defined prior to the start of the

project and specified by a contract)

Activities, Tasks, and Resources

Activity: A set of tasks performed towards a specific purpose

Requirement elicitation: An activity with purpose to define what the system

will do for the client

Delivery: An activity with purpose to install the system at an operational

location

Management: An activity with purpose to monitor and control the project

such that it meets the goal (e.g., deadline, quality, budget)

Activities may comprise other activities (DeliveryInstallation+Training)

A.k.a. phase

Task: An atomic unit of work that can be managed

E.g.: A manager assigns it to a developer, the developer carries it out, and

the manager monitors the progress and completion of the task

Consumes resources, result in work products, and depend on work products

produced by other tasks

Resources: Assets that are used to accomplish work

Time, equipment, and labor

Activities, Tasks, and Resources for

the TicketDistributor Project

Functional and Nonfunctional Requirements

Requirements: Features that the system must have

Functional requirement: A specification of a function that the

system must support

The user must be able to purchase tickets

The user must be able to access tariff information

……

Nonfunctional requirement: A constraint on the operation of

the system that is not related directly to a function of the system

The user must be provided feedback in less than one second

The colors used in interface should be consistent with the company colors

Using specific hardware platform

Security requirements

How to provide backward compatibility

……

Notations, Methods and Methodologies Notations: Graphical or textual set of rules for representing a model

Roman alphabet representing words

Data flow diagram [De Marco, 1978] representing data sources, sinks,

transformations; Z [Spivey, 1989] representing systems based on set theory

Unified Modeling Language (UML) representing OO models

Method: A repeatable technique specifying the steps involved in solving a

specific problem

Recipe cooking a specific dish

Sorting algorithm ordering elements of a list; Rationale management

justifying change

Methodology: A collection of methods for 1) solving a class of problems; 2)

specifying how and when each method should be used

Seafood cookbook a collection of recipes

OO methodologies: Royce’s methodology [Royce, 1998], Object Modeling

Technique (OMT, [Rumbaugh et al., 1991]), Catalysis [D’Souza, 1994]

Methodologies Used in This Book

No golden methodologies

OMT: Provide methods for three activities

Analysis, System Design, Object Design

RUP: Provide methods for three activities

Analysis, Design, Requirement Capture

Catalysis: Same as RUP

Focus more on reuse of design and code using patterns and frameworks

Methodology in this book

Requirement elicitation and analysis: methods similar to OOSE [Jacobson et

al. 1992]

System design and object design: similar to those of OMT

Change-related activities: design rationale research [Moran & Carroll, 1996]

Configuration management: maintenance of large systems [Babich, 1986]

SE Development Activities

Requirements

Elicitation

Analysis

System Design

Object Design

Implementation

Testing

Requirement Elicitation Activity: Client and developers define the purpose of the system

Result: Description of the system in terms of actors and use cases

Actors: end users, other computers to be dealt with, environment, etc.

Use cases: sequence of events that describe all the possible actions between an

actor and the system for a given piece of functionality

Analysis Activity: Produce a model of the system that is correct, complete, consistent,

and unambiguous

Result: A system model in terms of structure and dynamic interoperation

Structure: UML class diagram

Dynamic interoperation: UML state machine diagram, UML sequence diagram

System Design Activity: 1) Define the design goals of the project; 2) Decompose the system

into smaller subsystems that can be realized by individual teams

Hardware/software platform used, persistent data management strategy, global

control flow, access control policy, ……

Result: A system model (similar as analysis) including strategies for building

the system, the subsystem decomposition, etc.

Analysis deals with entities that the client can understand

System design deals with a much more refined model that includes many entities

that are beyond the comprehension (interest) of the client

Object Design, Implementation, and Testing

Activity: Define solution domain objects to bridge the gap between the analysis

model and the hardware/software platform defined during system design

Precisely describing object and subsystem interfaces, selecting off-the-shelf

components, attain goals such as extensibility, comprehensibility, high-performance

Result: A detailed object model annotated with constraints and precise

description for each element

Object Design

Activity: Translate the solution domain model into source codes

Result: Implementations of the attributes and methods of each object

Implementation

Activity: Find differences between the system and its models

Result: Faults discovered in various steps of the SE process

Testing

SE Management Activities

SE is not only about development, but also

about management Planning and monitoring the status of project

Tracking changes

Coordinating resources to ensure high-quality, on time delivery

within budget

……

Communication

Rationale Management

Software Configuration Management

Project Management

Software Life Cycle

Management

Activities

Communication The most critical and time-consuming activity in software engineering

Exchange of models and documents about the system and its application domain

Reporting the status of work products, providing feedback on its quality

Raising and negotiating issues

Communicating decisions

Misunderstanding and omissions faults and delays expensive to be

corrected later in the development

The most effective way Conventions

On notations: representing information

UML diagrams, templates for document writing and meeting minutes

On tools: manipulating information

CASE (Computer Aided Software Engineering) for maintaining models, word

processors for generating documents

On procedures: raising and resolving issues

Meeting procedures, review procedures, inspection procedures

Rationale Management

Rationale (justification of decision) is the most important

information developers need when changing the system

Given a decision, its rationale include

The problem that it addresses

The alternatives that developers considered

The criteria that developers used to evaluate the alternatives

The debate developers went through to achieve consensus

The decision

With rationale management, we can

A new alternative arrives compared with all other evaluated alternatives

A decision being questioned recover its rationale to justify it

Complex, difficult to update and maintain

Issue models

Software Configuration Management

Monitors and controls changes in work products

Change pervades software development

Requirements change as client requests new features and as developers

improve their understanding of the application domain

Hardware/software platforms change as new technology emerges

System changes as faults are discovered during testing and then repaired

Software configuration management can

Deal with changes during all stages of development

Enable developers to track changes: roll back to a well-defined state of the

system when a change fails

Enable developers to control changes: any change needs to be assessed and

approved before being implemented

Project Management & Software Life

Cycle

Include the oversight activities ensuring the delivery of a high-quality system

on time and within budget does not produce any artifact of its own

Planning and budgeting the project, hiring developers and organizing them into

teams, monitoring the status of the project, intervening when deviations occur

Project Management

A general model of the software development process

The process of developing software can be viewed as a complex system with

Inputs

Outputs

Activities

Resources

Software Life Cycle

Summary

Why do we need software engineering

Characteristics of software systems

Software systems are complex creations

Software systems are subject to constant changes

What is software engineering

A collection of techniques, methodologies and tools that help with the

production of a high quality software system on time and within budget,

while change occurs

Software engineering is a modeling, problem-solving, knowledge

acquisition, and rationale-driven activity

Modeling: An abstract representation of a system

Problem-solving: Six steps of OOSE

Knowledge acquisition: A nonlinear process

Rationale-driven: Handling changes

Summary

SE Concepts: Project, activity, task, resources, work products

Participants and roles

Systems and models

Work products

Internal work product, deliverable

Functional and nonfunctional requirements

Notations, methods, and methodologies

SE Development Activities

Requirement elicitation, analysis, system design, object design,

implementation, testing

SE Management Activities

Communications, rationale management, software configuration

management, project management, software life cycle