软件工程 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/
Using UML, Patterns, and Java Object-Oriented Software Engineering
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 a high 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 Management Activities Communication Rationale Management 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