软件工程

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/
Object-Oriented Software Engineering
Using UML, Patterns, and Java
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.
Another Example: Space Shuttle
Software
 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".
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
 ……
Software Engineering: Definition
Software Engineering (SE) is a collection of
techniques, methodologies and tools that help
with the production of

ahigh quality software system

with a given budget

before a given deadline

while change occurs.

20
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 (DeliveryInstallation+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
Object Design
 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

Implementation
 Activity: Translate the solution domain model into source codes
 Result: Implementations of the attributes and methods of each object

Testing
 Activity: Find differences between the system and its models
 Result: Faults discovered in various steps of the SE process
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
Management  Rationale Management
Activities  Software Configuration Management
 Project Management
 Software Life Cycle
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
Project Management
 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

Software Life Cycle

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