软件开发生命周期与统一建模语言UML06
UML 统一建模语言
UML中文名称：统一建模语言英文名称：unified modeling language;UML定义：是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。
作用域：1、支持面向对象的分析设计2、支持从需求分析开始的软件开发的全过程（1）关系：UML用关系把事物结合在一起1、依赖2、关联3、泛化4、实现两个用例之间的关系：1.包含关系 2.扩展关系 3.泛化关系（2）图形：UML2.0包括14种图五大类分法：1、静态图类图对象图包图2、用例图用例图3、行为图状态图活动图顺序图协作图4、交互图顺序图协作图5、实现图静态动态分法：1、表示系统静态结构的静态模型：类图：给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
对象图：是类图的实例。
从真实案例或原型案例的角度建立，给出系统的静态设计视图或系统的静态进程视图。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
包图：由包或类组成，表示包与包之间的关系。
包图用于描述系统的分层结构。
构件图：表示系统的静态设计实现视图。
描述代码构件的物理结构以及各种构建之间的依赖关系。
部署图：给出了架构的静态部署视图，静态实施视图。
用来建模系统的物理部署。
例如计算接和设备。
以及他们之间是如何连接的。
制品图组合结构图2、表示系统动态结构的动态模型：用例图：从用户角度描述系统功能，并指出各功能的操作者。
说明的是谁要使用系统，以及他们使用系统可以做些什么。
顺序图：展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。
强调对象之间消息发送的顺序，同时显示对象之间的交互。
强调时间和顺序。
协作图（或通信图）：描述对象间的协作关系，显示对象间的动态合作关系。
强调上下级关系。
定时图状态图：描述类的对象所有可能的状态以及事件发生时状态的转移条件。
活动图：描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
[计算机软件及应用]软件开发生命周期-PPT课件
![[计算机软件及应用]软件开发生命周期-PPT课件](https://img.taocdn.com/s3/m/e7828fca6aec0975f46527d3240c844768eaa071.png)
*
案例分析
“School项目”应该采用什么生存期模型？
*
学生成绩管理主要包括数据维护、成绩查询和成绩统计等三大功能模块。其中数据维护应实现班级、学生、课程和课程成绩等信息的录入、修改和删除等功能；成绩查询包括按学生查询其所有课程的成绩、按课程查询所有学生的成绩、按课程和班级查询所有学生的成绩；成绩统计包括按学生统计学分、平均成绩、班级名次和不及格课程门数，按课程统计学生平均成绩、及格率、优良率（80及以上为优良）。
*
本章要点
一、生存期模型定义 二、常用生存期模型 瀑布 V模型 原型 增量 螺旋式 快速应用开发 渐近式阶段 三、案例分析
*
V模型
接收测试
集成测试
系统测试
项目规化
需求分析
总体设计
详细设计
编码和调试
集成测试
单元测试
*
V模型模型适合的项目
项目的需求在项目开始前很明确 解决方案在项目开始前也很明确 对系统的性能安全很严格的项目 类似的项目如： 航天飞机等 公司的财务系统
项目规划
项目规划
*
产品阶段1设计
阶段目标： 设计公共控制系统功能模块 输入： 系统设计文件 数据库结构定义 过程： 详细设计 输出： 详细设计文件 时间计划： 2001/1/15-2001/2/15（暂定）
*
其它模型
其他 例如:Code and fix 自定义
*
常用生存期模型
瀑布Waterfall V模型V-shaped 原型Prototyping 增量Incremental 螺旋式Spiral 快速应用开发RAD 渐近式阶段
*
本章要点
一、生存期模型定义 二、常用生存期模型 瀑布 V模型 原型 增量 螺旋式 快速应用开发 渐近式阶段 三、案例分析
软件开发生命周期
软件开发生命周期软件开发是一个复杂而漫长的过程，而软件开发生命周期是指从软件需求分析、设计、编码、测试，到最后的部署、维护和更新的整个过程。
软件开发生命周期的合理管理对于保证软件的质量和项目的进度具有重要意义。
一、需求分析阶段在软件开发生命周期中，需求分析是最初阶段，以明确项目的目标和功能需求。
通过与客户的沟通和研究，开发团队可以准确理解客户所需的软件功能以及用户对软件的期望。
需求分析阶段的主要任务包括需求收集、需求分析和需求确认。
需求收集阶段可以通过面谈、问卷调查、用户访谈等方式获取用户需求。
然后对收集到的需求进行分析和整理，以形成详细的需求文档。
最后，与客户进行确认，确保开发团队准确理解并符合客户的需求。
二、设计阶段设计阶段是在需求分析完成之后进行的，目的是制定软件的整体架构和详细设计。
在设计阶段，开发团队将会制定软件的结构、模块划分、数据库设计等。
在设计阶段中，开发团队可以使用统一建模语言（UML）等工具进行系统建模，以便更好地描述软件的结构和功能。
设计阶段的输出通常是软件设计文档，其中包含了软件的架构图、模块图、数据库设计等详细信息。
三、编码阶段在软件设计完成后，开发团队将按照设计文档进行编码工作。
编码阶段是将设计转化为实际可执行软件的过程，开发团队需要根据设计要求编写代码，并进行必要的单元测试。
编码阶段中的编程语言和开发工具的选择取决于具体的项目需求和开发团队的技术特长。
无论使用哪种编程语言，良好的编码风格和规范是非常重要的，能够提高代码的可读性和可维护性。
四、测试阶段软件开发的测试阶段是为了验证软件的功能和性能是否符合设计和需求要求。
测试阶段可以分为单元测试、集成测试和系统测试等不同层次和类型的测试。
单元测试是对软件中的各个单元模块进行独立测试，以确保每个模块的功能正常。
集成测试是测试各个模块的集成是否协调一致，各个模块之间的接口是否正确。
系统测试是对整个软件系统进行全面测试，包括功能测试、性能测试、安全测试等。
软件开发生命周期与统一建模语言UML08
第八章 新闻发布系统的实例
新闻发布系统的实例
教学要求
掌握：UML建模过程。 理解：面向对象方法与结构化分析方法的综合运用。
软件开发生命周期与统一建模语言
8.1 系统概述
新闻发布系统的实例
新闻发布系统
一个基于新闻和内容管理的全站管理系统。它将网站上需 要经常变动的信息，类似公司动态、企业新闻、新产品发 布、促销活动和行业动态等更新信息集中管理，并通过信 息的某些共性进行分类，最后系统化、标准化发布到网站 上的一种网站应用程序。
第8章 新闻发布系统的实例
新闻发布系统的实例
8.1 系统概述
8.2 需求分析
8.2.1 系统的功能与要求 8.2.2 技术方案的选择 8.2.3 系统的系统结构
8.3 UML用例建模
8.3.1 初始用例模型
8.3.2 用例文档 8.3.3 完成的用例图
软件开发生命周期与统一建模语言
软件开发生命周期与统一建模语言
8.2 需求分析
新闻发布系统的实例
系统的功能与要求
对功能方面的规定
• 新闻管理
• 用户管理 • 系统管理
对性能方面的规定
数据管理能力要求
软件开发生命周期与统一建模语言
8.2 需求分析
新闻发布系统的实例
技术方案选择
本系统采用JSP作为开发环境，MySQL 作为数据库服务 器，Tomcat作为测试服务器，实现对新闻类别分类设置、 动态新闻的发布修改删除，以及后台管理等功能。
• JSP介绍
• MySQL介绍
• Tomcat介绍
软件开发生命周期与统一建模语言
8.2 需求分析
什么是统一建模语言（UML）？
什么是统一建模语言（UML）？UML是统一建模语言的缩写，是一种标准化建模语言，由一组集成的图表组成，它开发来帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件，以及业务建模和其他非软件系统。
UML代表了在大型和复杂系统建模中已被证明是成功的最佳工程实践的集合。
UML是开发面向对象软件和软件开发过程中非常重要的一部分。
UML 主要使用图形符号来表示软件项目的设计。
使用UML帮助项目团队沟通，探索潜在的设计，并验证软件的体系结构设计。
在本文中，我们将向您详细介绍UML是什么、UML的历史以及每个UML图类型的描述，以及UML示例。
What is Unified Modeling Language (UML)?UML, short for Unified Modeling Langung of an integrated set of diagrams, developed to help system and software developers 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 best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. In this article we will give you detailed ideas about what is UML, the history of UML and a description of each UML diagram type, along with UML examples.The Origin of UMLThe goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment).UML is a notation that resulted from the unification of OMT from1.Object Modeling T echnique OMT [James Rumbaugh 1991] - was best for analysis and data-intensive information systems.2.Booch [Grady Booch 1994] - was excellent for design and implementation. Grady Booch had worked extensively with the Ada language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less well received (lots of cloud shapes dominated his models - not very tidy)3.OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) - featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behaviour of an entire system (an area where OO has traditionally been weak).In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the "Unified Method").By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (particularly the concept of "Use Cases")were fed into the new Unified Method - now called the Unified Modelling Language1. The team of Rumbaugh, Booch and Jacobson are affectionately known as the "Three Amigos"UML has also been influenced by other object-oriented notations:•Mellor and Shlaer [1998]•Coad and Yourdon [1995]•Wirfs-Brock [1990]•Martin and Odell [1992]UML also includes new concepts that were not present in other major methods at the time, such as extension mechanisms and a constraint language.History of UML1.During 1996, the first Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response.2.Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included:o Digital Equipment Corpo HPo i-Logixo IntelliCorpo IBMo ICON Computingo MCI Systemhouseo Microsofto Oracleo Rational Softwareo TIo Unisys3.This collaboration produced UML 1.0, a modeling language that was well-defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response.14.In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997.1 and enhanced 1.1 to 1.5, and subsequently to UML 2.1 from 01 to 06 (now the UML current version is 2.5)Why UMLAs the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include componenttechnology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs. The primary goals in the design of the UML summarize by Page-Jones in Fundamental Object-Oriented Design in UML as follows:1.Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.2.Provide extensibility and specialization mechanisms to extend the core concepts.3.Be independent of particular programming languages and development processes.4.Provide a formal basis for understanding the modeling language.5.Encourage the growth of the OO tools market.6.Support higher-level development concepts such as collaborations, frameworks, patterns and components.7.Integrate best practices.UML - An OverviewBefore we begin to look at the theory of the UML, we are going to take a very brief run through some of the major concepts of the UML.The first thing to notice about the UML is that there are a lot of different diagrams (models) to get used to. The reason for thisis that it is possible to look at a system from many different viewpoints. A software development will have many stakeholders playing a part.For Example:•Analysts•Designers•Coders•Testers•QA•The Customer•Technical AuthorsAll of these people are interested in different aspects of the system, and each of them require a different level of detail. For example, a coder needs to understand the design of the system and be able to convert the design to a low level code. By contrast, a technical writer is interested in the behavior of the system as a whole, and needs to understand how the product functions. The UML attempts to provide a language so expressive that all stakeholders can benefit from at least one UML diagram.Here's a quick look at each one of these 13 diagrams in as shown in the UML 2 Diagram Structure below:Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts, there are seven types of structure diagram as follows:•Class Diagram•Component Diagram•Deployment Diagram•Object Diagram•Package Diagram•Composite Structure Diagram•Profile DiagramBehavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time, there are seven types of behavior diagrams as follows:•Use Case Diagram•Activity Diagram•State Machine Diagram•Sequence Diagram•Communication Diagram•Interaction Overview Diagram•Timing DiagramWhat is a Class Diagram?The class diagram is a central modeling technique that runs through nearly all object-oriented methods. This diagram describes the types of objects in the system and various kinds of static relationships which exist between them.RelationshipsThere are three principal kinds of relationships which areimportant:1.Association - represent relationships between instances of types (a person works for a company, a company has a number of offices.2.Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate correspondence to inheritance in OO design.3.Aggregation - Aggregation, a form of object composition in object-oriented design.Class Diagram ExampleWhat is Component Diagram?In the Unified Modeling Language, a component diagram depicts how components are wired together to form larger components or software systems. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components.Component Diagram ExampleWhat is a Deployment Diagram?The Deployment Diagram helps to model the physical aspect of an Object-Oriented software system. It is a structure diagram which shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. Artifacts represent concrete elements in the physical world that are the result of a development process. It models the run-time configuration in a static view and visualizes the distribution of artifacts in an application. In most cases, it involves modeling the hardware configurations together with the software components that lived on.Deployment Diagram ExampleWhat is an Object Diagram?An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The difference is that a class diagram represents an abstract model consisting of classes and their relationships. However, an object diagram represents an instance at a particular moment, which is concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data structure.Class Diagram vs Object Diagram - An ExampleSome people may find it difficult to understand the difference between a UML Class Diagram and a UML Object Diagram as they both comprise of named "rectangle blocks", with attributes in them, and with linkages in between, which make the two UML diagrams look similar. Some people may even think they are the same because in the UML tool they use both the notations for Class Diagram and Object Diagram are put inside the same diagram editor - Class Diagram.But in fact, Class Diagram and Object Diagram represent two different aspects of a code base. In this article, we will provide you with some ideas about these two UML diagrams, what they are, what are their differences and when to use each of them.Relationship between Class Diagram and Object Diagram You create "classes" when you are programming. For example, in an online banking system you may create classes like 'User', 'Account', 'Transaction', etc. In a classroom management system you may create classes like 'Teacher', 'Student', 'Assignment', etc. In each class, there are attributes and operations that represent the characteristic and behavior of the class. Class Diagram is a UML diagram where you can visualize those classes, along with their attributes, operations and theinter-relationship.UML Object Diagram shows how object instances in your system are interacting with each other at a particular state. It also represents the data values of those objects at that state. In other words, a UML Object Diagram can be seen as a representation of how classes (drawn in UML Class Diagram) are utilized at a particular state.If you are not a fan of those definition stuff, take a look at the following UML diagram examples. I believe that you will understand their differences in seconds.Class Diagram ExampleThe following Class Diagram example represents two classes - User and Attachment. A user can upload multiple attachment so the two classes are connected with an association, with 0..* as multiplicity on the Attachment side.Object Diagram ExampleThe following Object Diagram example shows you how the object instances of User and Attachment class "look like" at the moment Peter (i.e. the user) is trying to upload two attachments. So there are two Instance Specification for the two attachment objects to be uploaded.What is a Package Diagram?Package diagram is UML structure diagram which shows packages and dependencies between the packages. Modeldiagrams allow to show different views of a system, for example, as multi-layered (aka multi-tiered) application - multi-layered application model.Package Diagram ExampleWhat is a Composite Structure Diagram?Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite structure diagram is similar to a class diagram and is a kind of component diagram mainly used in modeling a system at micro point-of-view, but it depicts individual parts instead of whole classes. It is a type of static structure diagram that shows the internal structure of a class and the collaborations that this structure makes possible.This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.Composite Structure Diagram ExampleWhat is a Profile Diagram?A profile diagram enables you to create domain and platform specific stereotypes and define the relationships between them. You can create stereotypes by drawing stereotype shapes and relate them with composition or generalization through the resource-centric interface. You can also define and visualize tagged values of stereotypes.Profile Diagram ExampleWhat is a Use Case Diagram?A use-case model describes a system's functional requirements in terms of use cases. It is a model of the system's intended functionality (use cases) and its environment (actors). Use cases enable you to relate what you need from a system to how the system delivers on those needs.Think of a use-case model as a menu, much like the menu you'd find in a restaurant. By looking at the menu, you knowwhat's available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior.Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle by all team members.Use Case Diagram ExampleWhat is an Activity Diagram?Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. It describes the flow of control of the target system, such as the exploring complex business rules and operations, describing the use case also the business process. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).Activity Diagram ExampleWhat is a State Machine Diagram?A state diagram is a type of diagram used in UML to describe the behavior of systems which is based on the concept of state diagrams by David Harel. State diagrams depict the permitted states and transitions as well as the events that effect these transitions. It helps to visualize the entire lifecycle of objects and thus help to provide a better understanding of state-based systems.State Machine Diagram ExampleWhat is a Sequence Diagram?The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case. With the advanced visual modeling capability, you can create complex sequence diagram in few clicks. Besides, some modeling tool such as Visual Paradigm can generate sequence diagram from the flow of events which you have defined in the use case description.Sequence Diagram ExampleWhat is a Communication Diagram?Similar to Sequence Diagram, the Communication Diagram is also used to model the dynamic behavior of the use case. When compare to Sequence Diagram, the Communication Diagram is more focused on showing the collaboration of objects rather than the time sequence. They are actually semantically equivalent, so some of the modeling tool such as, Visual Paradigm allowsyou to generate it from one to the other.Communication Diagram ExampleWhat is Interaction Overview Diagram?The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the "real" diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.Interaction Overview Diagram ExampleWhat is Timing Diagram?Timing Diagram shows the behavior of the object(s) in a given period of time. Timing diagram is a special form of a sequence diagram. The differences between timing diagram and sequence diagram are the axes are reversed so that the time are increase from left to right and the lifelines are shown in separate compartments arranged vertically.Timing Diagram ExampleUML Glossary and Terms•Abstract Class - A class that will never be instantiated. An instance of this class will never exist.•Actor - An object or person that initiates events the system is involved with.•Activity: A step or action within an Activity Diagram. Represents an action taken by the system or by an Actor.•Activity Diagram: A glorified flowchart that shows the steps and decisions and parallel operations within a process, such as an algorithm or a business process.•Aggregation - Is a part of another class. Shown with a hollow diamond next to the containing class in diagrams.•Artifacts - Documents describing the output of a step in the design process. The description is graphic, textual, or some combination.•Association - A connection between two elements of a Model. This might represent a member variable in code, or theassociation between a personnel record and the person it represents, or a relation between two categories of workers, or any similar relationship. By default, both elements in an Association are equal, and are aware of each other through the Association. An Association can also be a Navigable Association, meaning that the source end of the association is aware of the target end, but not vice versa.•Association Class: A Class that represents and adds information to the Association between two other Classes.•Attributes - Characteristics of an object which may be used to reference other objects or save object state information.•Base Class: A Class which defines Attributes and Operations that are inherited by a Subclass via a Generalization relationship.•Branch: A decision point in an Activity Diagram. Multiple Transitions emerge from the Branch, each with a Guard Condition. When control reaches the Branch, exactly one Guard Condition must be true; and control follows the corresponding Transition.•Class: A category of similar Objects, all described by the same Attributes and Operations and all assignment-compatible.•Class Diagram - Shows the system classes and relationships between them.•Classifier: A UML element that has Attributes and Operations. Specifically, Actors, Classes, and Interfaces.•Collaboration: A relation between two Objects in a Communication Diagram, indicating that Messages can pass back and forth between the Objects.•Communication Diagram - A diagram that shows how operations are done while emphasizing the roles of objects.•Component: A deployable unit of code within the system.•Component Diagram: A diagram that shows relations between various Components and Interfaces.•Concept - A noun or abstract idea to be included in a domain model.•Construction Phase - The third phase of the Rational Unified Process during which several iterations of functionality are built into the system under construction. This is where the main work is done.•Dependence: A relationship that indicates one Classifier knows the Attributes and Operations of another Classifier, but isn't directly connected to any instance of the second Classifier.•Deployment Diagram: A diagram that shows relations between various Processors.•Domain -The part of the universe that the system is involved with.•Elaboration Phase - The second phase of the Rational Unified Process that allows for additional project planning including the iterations of the construction phase.•Element: Any item that appears in a Model.•Encapsulation - Data in objects is private.•Generalization - Indicates that one class is a subclass on another class (superclass). A hollow arrow points to the superclass.•Event: In a State Diagram, this represents a signal or event or input that causes the system to take an action or switch States.•Final State: In a State Diagram or an Activity Diagram, this indicates a point at which the diagram completes.•Fork: A point in an Activity Diagram where multiple parallel control threads begin.•Generalization: An inheritance relationship, in which aSubclass inherits and adds to the Attributes and Operations of a Base Class.•GoF - Gang of Four set of design patterns.•High Cohesion - A GRASP evaluative pattern which makes sure the class is not too complex, doing unrelated functions.•Low Coupling - A GRASP evaluative pattern which measures how much one class relies on another class or is connected to another class.•Inception Phase - The first phase of the Rational Unified Process that deals with the original conceptualization and beginning of the project.•Inheritance - Subclasses inherit the attributes or characterics of their parent (superclass) class. These attributes can be overridden in the subclass.•Initial State: In a State Diagram or an Activity Diagram, this indicates the point at which the diagram begins.•Instance - A class is used like a template to create an object. This object is called an instance of the class. Any number of instances of the class may be created.•Interface: A Classifier that defines Attributes and Operations that form a contract for behavior. A provider Class or Component may elect to Realize an Interface (i.e., implement its Attributes and Operations). A client Class or Component may then Depend upon the Interface and thus use the provider without any details of the true Class of the provider.•Iteration - A mini project section during which some small piece of functionality is added to the project. Includes the development loop of analysis, design and coding.•Join: A point in an Activity Diagram where multiple parallel control threads synchronize and rejoin.•Member: An Attribute or an Operation within a Classifier.•Merge: A point in an Activity Diagram where different control paths come together.•Message - A request from one object to another asking the object receiving the message to do something. This is basically a call to a method in the receiving object.•Method - A function or procedure in an object.•Model - The central UML artifact. Consists of various elements arranged in a hierarchy by Packages, with relations between elements as well.•Multiplicity - Shown in a domain model and indicated outside concept boxes, it indicates object quantity relationship to quantiles of other objects.•Navigability: Indicates which end of a relationship is aware of the other end. Relationships can have bidirectional Navigability (each end is aware of the other) or single directional Navigability (one end is aware of the other, but not vice versa).•Notation - Graphical document with rules for creating analysis and design methods.•Note: A text note added to a diagram to explain the diagram in more detail.•Object - Object: In an Activity Diagram, an object that receives information from Activities or provides information to Activities. In a Collaboration Diagram or a Sequence Diagram, an object that participates in the scenario depicted in the diagram. In general: one instance or example of a given Classifier (Actor, Class, or Interface).•Package - A group of UML elements that logically should be grouped together.•Package Diagram: A Class Diagram in which all of theelements are Packages and Dependencies.•Pattern - Solutions used to determine responsibility assignment for objects to interact. It is a name for a successful solution to a well-known common problem.•Parameter: An argument to an Operation.•Polymorphism - Same message, different method. Also used as a pattern.•Private: A Visibility level applied to an Attribute or an Operation, indicating that only code for the Classifier that contains the member can access the member.•Processor: In a Deployment Diagram, this represents a computer or other programmable device where code may be deployed.•Protected: A Visibility level applied to an Attribute or an Operation, indicating that only code for the Classifier that contains the member or for its Subclasses can access the member.•Public: A Visibility level applied to an Attribute or an Operation, indicating that any code can access the member.•Reading Direction Arrow - Indicates the direction of a relationship in a domain model.•Realization: Indicates that a Component or a Class provides a given Interface.•Role - Used in a domain model, it is an optional description about the role of an actor.•Sequence Diagram: A diagram that shows the existence of Objects over time, and the Messages that pass between those Objects over time to carry out some behavior. State chart diagram - A diagram that shows all possible object states.•State: In a State Diagram, this represents one state of a system or subsystem: what it is doing at a point in time, as wellas the values of its data.•State Diagram: A diagram that shows States of a system or subsystem, Transitions between States, and the Events that cause the Transitions.•Static: A modifier to an Attribute to indicate that there's only one copy of the Attribute shared among all instances of the Classifier. A modifier to an Operation to indicate that the Operation stands on its own and doesn't operate on one specific instance of the Classifier.•Stereotype: A modifier applied to a Model element indicating something about it which can't normally be expressed in UML. In essence, Stereotypes allow you to define your own "dialect" of UML.•Subclass: A Class which inherits Attributes and Operations that are defined by a Subclass via a Generalization relationship.•Swimlane: An element of an Activity Diagram that indicates what parts of a system or a domain perform particular Activities. All Activities within a Swimlane are the responsibility of the Object, Component, or Actor represented by the Swimlane.•Time Boxing - Each iteration will have a time limit with specific goals.•Transition: In an Activity Diagram, represents a flow of control from one Activity or Branch or Merge or Fork or Join to another. In a State Diagram, represents a change from one State to another.•Transition Phase - The last phase of the Rational Unified Process during which users are trained on using the new system and the system is made available to users.•UML - Unified Modeling Language utilizes text and graphic documents to enhance the analysis and design of software。
系统分析与设计——统一建模语言UML
北京理工珠海学院
6.1.2统一建模语言特点
（1）面向对象:支持面向对象技术的主要概念,提供 了一批基本的模型元素表示图形和方法,简明表 达面向对象的各种概念. （2）可视化:通过UML的模型图清晰表示系统的逻辑 模型和实现模型,还用于各种复杂系统的建模. （3）独立于过程:独立于开发过程. （4）独立于程序设计语言:建好的系统模型可用任何 面向对象的语言来实现. （5）易于掌握和使用:结构清晰,建模简明易于掌握
五类图
第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者 .
第二类是静态图 ，包括类图、对象图和包图 .
第三类是行为图,描述系统的动态模型和组成对象间的交互关系。行为图 包括：状态图、活动图、顺序图和协作图 第四类是交互图,描述对象间的交互关系。(顺序图显示对象之间的动态 合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互 ；合作图描述对象间的协作关系，显示对象间的动态合作关系和对象以 及它们之间的关系)。如果强调(时间和顺序，则使用顺序图)；如果强 调(上下级关系，则选择合作图)。这两种图合称为交互图. 第五类是实现图 ,其中构件图描述代码部件的物理结构及各部件之间的 依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个 可执行部件。它包含逻辑类或实现类的有关信息。构件图有助于分析和 理解部件之间的相互影响程度。
《include》 打印查询结果
(From Use Case View)
(From Use Case View)
北京理工珠海学院
案例：泛化、扩展关系
下面左图给出了一个扩展关系的例子，在还书的过程中， 只有在例外条件（读者遗失书籍）的情况下，才会执行赔 偿遗失书籍的分支流。 泛化关系：用例可以被特别列举为一个或多个子用例，这 被称做用例泛化。当父用例能够被使用时，任何子用例也 可以被使用。如在右图中，订票是电话订票和网上订票的 抽象。
软考软件设计师题库
选择题1. 在软件开发生命周期中，哪个阶段主要负责确定软件系统的功能、性能及运行环境等？A. 需求分析（正确答案）B. 系统设计C. 编码实现D. 测试与维护2. 下列关于模块化设计的说法中，不正确的是：A. 模块化有助于提高软件的可维护性B. 模块之间的耦合度越低越好C. 模块的内聚度越高，模块独立性越强（正确答案）D. 模块化设计不利于软件的复用3. 在数据库设计中，ER图（实体-关系图）主要用于表示：A. 数据流图B. 数据结构C. 实体、属性及实体间的关系（正确答案）D. 程序控制流程4. 下列哪种算法常用于解决图中的最短路径问题？A. 冒泡排序B. Dijkstra算法（正确答案）C. 快速排序D. 二分查找5. 关于面向对象编程（OOP），下列哪项不是其基本特征？A. 封装B. 继承C. 多态D. 过程化编程（正确答案）6. 在软件质量管理中，CMMI（Capability Maturity Model Integration）主要用于评估：A. 软件过程成熟度（正确答案）B. 软件代码质量C. 软件测试覆盖率D. 软件开发成本7. 下列关于UML（统一建模语言）的说法中，正确的是：A. UML只用于面向对象编程B. UML不能为数据库建模C. UML提供了一套标准的建模符号和工具，用于软件开发各阶段的可视化建模（正确答案）D. UML仅适用于大型软件项目8. 在软件测试中，黑盒测试主要关注：A. 程序内部结构B. 程序外部行为和功能（正确答案）C. 代码覆盖率D. 性能测试指标9. 关于敏捷开发，以下哪项不是其核心原则？A. 以人为本，团队协作B. 快速响应变化，拥抱需求变更C. 强调详细的前期规划和文档编写（正确答案）D. 持续交付，持续改进。
软件开发生命周期与统一建模语言UML (2)
❖ 总的说来，在面向对象的程序设计中可以应用结构化分析的 好的方法和思路，目的在于既体现面向对象方法从问题域出 发、易理解、易实现、易维护等特点，又发挥结构化方法从 整体上把握系统、逐层细分、强调良好的软件结构、进行合 理的数据库设计等优势。一条根本的原则是：注意保持结构 化的分析设计结果（如模块划分）与面向对象的分析设计结 果在核心内容上的一致性。
2.2 面向对象方法与结构化方法比较
❖ （2）结构化方法。
获取完整的需求。 自顶向下、逐层分解，画出数据流图。 书写数据字典。 映射出系统的层次结构，进行系统结构（模块及其接口）
设计。 逐层细分，细化出每个处理。 设计界面，设计数据库。
软件开发生命周期与统一建模语言UML
2.2 面向对象方法与结构化方法比较
程序或者程序的一个模块 ▪ 平行横线代表数据存储。数据存储并不等同于一个文件，
它可以表示一个文件、文件的一部分、数据库的元素或记 录的一部分等 ▪ 数据存储和数据流都是数据，仅仅所处的状态不同。数据 存储是处于静止状态的数据，数据流是处于运动中的数据
系统必须做什 么
概括地说，应 该怎样做
工具手段
交付成果
数据流图、数据字典、数据 可行性分析报告、多种解决方
流程图、成本/效益分析
案、系统高层逻辑模型
数据流图、数据字典、算法 需求规格说明书、系统逻辑模
描述
型
数据流图、系统流程图、成 本/效益分析、系统结构 图、层次方框图
几种可能的解法
详细设计 具体怎样做
软件开发生命周期与统一建模语言UML
2.2 面向对象方法与结构化方法比较
（续）
▪ 面向对象的程序设计方法的特点是根据现实问题直接抽象出 对象，分析对象的行为和与行为相关的数据，对象间通过传 递消息进行通信，协作完成相应的功能，从问题出发，模拟 现实问题建立系统模型，易于理解和实现。
统一建模语言UML
第六章 统一建模语言UML
面向对象建模 用面向对象方法开发软件，通常需要建立三种形式 的模型，它们分别是： （1）对象模型：描述系统的数据结构； （2）动态模型：描述系统的控制结构； （3）功能模型：描述系统的功能。 3种模型必不可少，其重要程度不同，对象模型是最 基本、最重要的。
1.1.1建模
1.3.3 UML图
图是一组元素的图形表示。为了对系统进行可视化，可以从不 同的角度画图。在理论上，图可以包含任何事物及其关系的 组合。 在UML中包含9类图： 1．类图(class diagram) 2．对象图(object diagram) 3．用例图(use case diagram) 4．顺序图(sequence diagram) 5．协作图(collaboration diagram) 6．状态图(statechart diagram) 7．活动图(activity diagram) 8．组件图(component diagram) 9．部署图(deployment diagram)
类名可以是由数字、字母和下划线等符号组成，类名的长度 没有限制。 例如顾客类可以用Customer作为类名。
属性
属性（attribute）是已被命名的类的特性，它描述了该特性 的实例可以取值的范围。 属性描述了正被建模的事件的一些特性，这些特性是类的所 有对象所共有。
例如，所有的CPU都有主频率、指令集类型、运算的位算和 外观尺寸。
• 1995年10月：第一个公开版本UM 0.8（Unified Method）。 • 1996年6月：UM改名为UML（Unified Modeling Language）， 发布 UML 0.9。 • 1996年底：UML占面向对象技术市场的85％，成为可视化 建模语言事实上的工业标准。 •1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术 的标准建模语言。 UML 2.0 major revision that was adopted by the OMG in 2005. versions 2.1.1 and 2.1.2 appeared in 2007, UML 2.2 in February 2009. UML 2.3 was formally released in May 2010 UML 2.4 is in the beta stage as on March 2011
统一建模语言
UML统一建模语言（UML是Unified Modeling Language的缩写）是用来对软件密集系统进行可视化建模的一种语言。
UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
目录1 简要介绍2 语言出现3 语言内容4 主要特点5 应用领域统一建模语言(UML)是非专利的第三代建模和规约语言。
UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。
UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面,特别是在软件架构层次已经被验证有效UMLUML可以贯穿软件开发周期中的每一个阶段。
被OMG采纳作为业界的标准。
UML最适于数据建模，业务建模，对象建模，组件建模。
UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。
当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。
回顾20世纪晚期--准确地说是1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。
UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。
UML提出了一套IT专业人员期待多年的统一的标准建模符号。
通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。
到了21世纪--准确地说是2003年，UML已经获得了业界的认同。
在所见过的专业人员的简历中，75%都声称具备UML的知识。
然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。
通常地，他们将UML用作一个术语，或对UML一知半解。
大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 1.4的快速入门文章。
当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。
软件开发生命周期与统一建模语言UML07
Interface
组件与接口（实现关系） 组件与接口（依赖关系）
软件开发生命周期与统一建模语言
7.2 组件图
UML实现与部署
组件图与类图、包图的关系
组件在很多方面与类相同：二者都有名称和依赖关系、可以 被嵌套、可以参与交互、同样可以实现一组接口。但是组件 和类之间也存在着区别：
• 组件可以是一个或几个类在文件中的存在。 • 组件表示物理上的模块。 • 类是逻辑上的抽象，组件是客观上存在的物理抽象，所以组件 可以存在于节点上，而类不能。 • 类可以直接拥有属性和操作，而组件通常只拥有必须通过接口 访问的操作。
Router
某种硬件的特定的实例
软件开发生命周期与统一建模语言
7.3 部署图
UML实现与部署
通信关联
部署图用关联关系表示各节点之间的通信路径。在UML中， 部署图中的关联关系为一条实线。另外，在连接硬件时通常 都会关心节点之间的连接方式，如红外、蓝牙、以太网、令 牌、并行、USB、TCP等。因此，关联关系一般不使用名称， 而是使用构造型，如<<TCP>>、<<USB>>等表示。
用程序框架之间的关系。
软件开发生命周期与统一建模语言
第七章 UML实现与部署
UML实现与部署
教学要求
掌握：组件图、部署图定义，组件图、部署图的 标记符以及如何建立模型。 理解：组件图与部署图之间的关系，组件图与应
用程序框架之间的关系。
软件开发生命周期与统一建模语言
7.1 建模实现方式图的目的
软件开发生命周期与统一建模语言
7.2 组件图
UML实现与部署
购物车的组件图实现
order Item.java Catalog.java
(精品文档)统一建模语言UML课件
用例描述了系统的功能需求，是系统执行的一系列动 作。 从本质上讲，一个用例是执行者与计算机之间的一次 典型交互。
用例名
用例
27
UML用例图
28 .
如何识别用例？
执行者的需求
28
UML用例图
o
用例之间存在着一定的关系，这些关系包括泛化关系、 包含关系和扩展关系。
29 .
泛化关系：用例可以被特殊列举为一个或多个子用例， 这被称为用例泛化。
.
实现图（Implementation diagram）定义系统中软硬件的 物理体系结构，包括组件图和配置图： 组件图描述代码部件的物理结构及各部件之间的依赖关 系。
配置图描述了系统中软硬件的物理体系结构，即显示了 系统的软件配置和硬件（计算机和设备，用节点表示） 配置以及它们之间的关系。
21
U M L
元素是模 型的抽象
分组元素 注释元素
类 接口 协作 用例 活动类 组件 节点 交互 状态机 包 注解 依赖 关联 泛化 聚集 实现
8
.
图将元素的集合进行分组
关系
元素之间的 连接纽带是 关系 用例图 静态图 行为图 交互图 实现图
图
UML简介
Part1.UML元素－结构元素
.
UML中共有7种结构元素：类、接口、协作、用例、活 动类、组件和节点。
34
UML类图
在面向对象的方法中，系统中的任何事物 都被看成是对象，通过对象间的交互实现 系统的功能。
35 .
类是创建对象的模板，找出系统中的 类是系统运行的重要前提。
35
UML类图
类图（Class Diagram）
软件设计过程中的统一建模语言UML
软件设计过程中的统一建模语言UML一、UML的概念和发展统一建模语言，英文缩写UML，是软件开发中常用的一种建模语言。
自1997年推出以来，UML 以其简明的表达和强大的组织能力逐渐成为软件开发领域的标准和事实上的应用范式。
UML 的前身是Booch方法、OOSE方法和OMT方法。
在20世纪80年代中期，这些方法都有自己独特的建模方式和框架，难以让不同方法之间进行有效的交互。
为了解决这个问题，OMG开始了一个称为“UML”（即“共同建模语言”）的倡议。
UML 的实现促使OMG摒弃自己之前的建模语言DA（即“OMT、Booch和OOSE的综合”）。
在几次重大的更新中，UML 以一种形式化规范形式定义了一组符号和图形，以实现在开发、文档化和维护软件时进行可视化建模的目标。
二、UML的优点及特点UML是具有很强的建模性和逻辑性的，为软件开发工程师和设计师提供了简单、规范、美观的可视化构图方式。
在具体应用中，UML的优点主要体现在以下几个方面。
1. 统一的建模语言：UML可以作为一种通用的建模语言，为不同的软件开发者提供了的一种共同基础，从而促进了软件开发的有效性和互操作性。
2. 开放性和标准性：UML是由OMG组织推广的一种标准化建模语言，开放式的接口和标准的语法形式使得UML应用于许多事实应用的实现中。
3. 图形表达力：UML是一种具有较高可视化操作性的可视化建模语言，通过其精美实用的图形，开发人员可以快速理解系统结构和动作流程的设计，为软件开发的快速实现提供了便利条件。
4. 易于扩展性和可维护性：UML是有流程性、属性性和行为性三个方面构成的、具有极高扩展性的建模语言，因而可以方便的与其他开发工具及软件结合，也预示着其易于维护的特性。
5. 面向对象的特点：UML以对象的视角来看待系统，这使得建模结果具有面向对象的特点，更贴近于实际的软件开发实践。
三、UML的主要元素1. 用例图：是一个描述系统功能的图形化工具，可以显示对象、行为和组织结构组成。
《软件开发生命周期与统一建模语言UML》-曹静-电子教案05
• 操作：按照“可见性 方法名称( [参数列表]) [:返回类型]”的书写顺序。
软件开发生命周期与统一建模语言
5.2 类图
静态模型
类的表示方法
软件开发生命周期与统一建模语言
5.2 类图
静态模型
隐藏属性部分或操作部分，或者两者都隐藏
软件开发生命周期与统一建模语言
5.2 类图
静态模型
通过在属性名称和数据类型之后添加等号来为属性指定默认值
BoxWeight -weight : double +getWeight() : double +volume() : double
BoxColor -color : object +getColor() : object +volume() : double
软件开发生命周期与统一建模语言
5.2 类图
静态模型
接口对应的Java代码映射
interface Callback { void callback(int param); } class Client implements Callback { public void callback(int p) {……} public void nonIfaceMeth( ) {……} } class TestIface { public static void main(String args[]) { Callback c = new Client( ); c.callback(42); } }
软件开发生命周期与统一建模语言
5.2 类图
静态模型
关联关系的不同重数与代码的映射
（3）单向关联（1..*）
public class Manager { private Vector theAccounts; public void addAccount (Account acc) {theAccount.addElement ( acc ) ;} public void removeAccount (Account acc){theAccount.removeElement(acc); } }
第6章UML统一建模语言报告
1 UML的特点
(1)统一标准.成为对象组织OMG的正式标准，并提供了标 准的面向对象的模型元素的定义和表示
(2)面向对象。UML还吸取了面向对象技术领域中其他流派 的长处
(3)可视化、表示能力强。系统的逻辑模型或实现模型都能 用UML的可视化模型清晰地表示，
(4)独立于过程。UML是系统建模语言，独立于开发过程。 (5)易掌握、易用。
2 UML形成过程
3 UML的图形表示
1．UML的构成 UML建模语言的描述方式以标准的图形表示为主，是由 视图（Views）、图（Diagrams）、模型元素（Model Elements）和通用机制（General Mechanism）构成的 层次关系。 （1）视图
视图就是从不同的视角观察和建立的系统模型图。一个视图 由多个图构成。每个视图表示系统的一个特殊的方面或者系 统的某个特性，多个（用例视图）视图才能建立一个完整的 系统模型图。
构件图（Component Diagram。） 配置图（Deployment Diagram）
• 类图
• 类图描述类和类与类之间的静态关系，它是从静态角 度表示系统的，因此类图属于一种静态模型。类图是 构建其他图的基础，没有类图就没有状态图、协作图 等其他图，也就无法表示系统其他方面的特性。
• 用例
• 一个用例实质上是用户与计算机系统之间的一次 典型的交互作用，它代表的是系统的一个完整的 功能。在UML中把用例定义成系统执行的一系列 动作，动作的结果能被外部执行者察觉到。
• 在UML用例图中，用例表示为一个椭圆。图1是 自动售货机系统的用例图，其中“售货”、“供 货”和“取货款”都是典型的用例。概括地说， 用例有以下特点：
•
活动图描述为满足用例要求而进行的动作以及
软件开发生命周期与统一建模语言UML06解析
6.3.3 对象的创建和销毁
动态模型
教师试图修改学生的成绩，但该学生的成绩信息在系统中不存在
软件开发生命周期与统一建模语言UML
6.3.4 顺序图的主要用途
动态模型
顺序图的主要用途之一是表示用例中的行为顺序
在系统开发的早期阶段，顺序图可以应用在高层场景
的表达上；后续阶段，则可以确切地表示对象间的消
状态图通常作为对类图的补充
软件开发生命周期与统一建模语言UML
状态图映射成代码
动态模型
将不同状态作为常数枚举，把当前状态存储在适
当的数据成员中。
依赖于状态的操作可以用开关语句对每个状态分
别设一个case实现。每个case表示来自特定状
态，用相应的消息表示转换。
需求用专门的数据成员存储对象的历史状态
软件开发生命周期与统一建模语言UML
6.2 活动图
动态模型
本节教学要求
• 理解：活动图的作用 • 掌握：活动图建模的方法
软件开发生命周期与统一建模语言UML
6.2.1 定义活动图
动态模型
活动图用于描述系统、子系统、用例、程序模块 中的工作流，帮助理解系统高层活动的执行过程
软件开发生命周期与统一建模语言UML
软件开发生命周期与统一建模语言UML
6.3.3 对象的创建和销毁
动态模型
将create消息发送给对象实例，从而即时创建 对象，对象创建之后才具有生命线 destroys消息用于销毁对象，给需要销毁的对 象发送这个消息，同时在该对象的生命线上放一 个“×”符号，表示对象的生命终止
软件开发生命周期与统一建模语言UML
6.1 动态模型概述
动态模型
一个完整的模型必然描述系统的静态和动态两个方面
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件开发生命周期与统一建模语言UML
银行账户对象的状态图
动态模型
对应的代码参见教材
软件开发生命周期与统一建模语言UML
练习
动态模型
1．对用户使用手机拨打电话的过程建立状态模 型。手机开机时，处于空闲状态，当用户开始使 用电话呼叫某人时，手机进入拨号状态。如果呼 叫成功，即电话接通，手机就处于通话状态；如 果呼叫不成功，如对方线路问题、关机、拒接等， 这时手机停止呼叫，重新进入空闲状态。手机在 空闲状态被呼叫。如果用户接听电话，用户处于 通话状态；如果用户未做出任何反应，可能他没 有听见铃声，手机一直处于空闲状态。
软件开发生命周期与统一建模语言UML
6.3 顺序图
动态模型
本节教学要求
理解：顺序图如何表达对象间的交互关系，顺序图与类图 的关系。
掌握：顺序图建模的方法，顺序图和类图之间的映射，顺
序图与代码的映射。
软件开发生命周期与统一建模语言UML
6.3.1 定义顺序图
动态模型
软件系统中的任务是通过对象之间的合作来完成 的，这种合作称为交互。交互模型可以用来描述 软件系统中的类、接口、组件、节点的实例的动 态行为。交互模型包括顺序图和协作图。 顺序图用来建模对象间的交互，强调按时间顺序 展开的信息的传递。它与活动图的相似之处是可 以表示流程，但顺序图能进一步地将活动分配给 对象。通常，一个顺序图只显示一个控制流
活动图的符号
动态模型
一个活动图必然有一个开 始状态 至少有一个结束状态 转移用来表示活动或状态 间的控制流 有分支时要在分支路径中 注明分支条件
分岔用来开始并行处理 联结用于把并行处理转 换为单个处理
软件开发生命周期与统一建模语言UML
动态模型
ATM机“登录”用例的活动 图
软件开发生命周期与统一建模语言UML
6.5 状态图
动态模型
本节教学要求
理解：状态图的作用。 掌握：状态图的建模方法，状态图到代码的映射。
软件开发生命周期与统一建模语言UML
6.5 状态图
动态模型
地铁十字转 门的状态图
当前处于Locked状态，若发生coin事件，则变迁到Unlocked状态， 调用Unlock方法。 当前处于Unlocked状态，若发生pass事件，则变迁到Locked状态， 调用Lock方法。 当前处于Unlocked状态，若发生coin事件，则变迁到Unlocked状态， 调用Thankyou方法。 当前处于Locked状态，若发生pass事件，则继续停留在Locked状态， 调用Alarm方法
软件开发生命周期与统一建模语言UML
6.3.3 对象的创建和销毁
动态模型
将create消息发送给对象实例，从而即时创建 对象，对象创建之后才具有生命线 destroys消息用于销毁对象，给需要销毁的对 象发送这个消息，同时在该对象的生命线上放一 个“×”符号，表示对象的生命终止
软件开发生命周期与统一建模语言UML
软件开发生命周期与统一建模语言UML
ATM机“登录成功”的顺序图
动态模型
软件开发生命周期与统一建模语言UML
6.3.2 关于消息
动态模型
1．消息的类型
同步消息 返回消息 异步消息 简单消息
（1）同步消息（Synchronous）：表示该消息完成之前， 同一个对象不能再发送下一条消息。 （2）返回消息（Return）：表示控制流返回到调用的活 动对象。 （3）异步消息（Asychronous）：表示不必等待来自该 消息的响应，同一个对象即可发出下一条消息。 （4）简单消息（Flat）：表示不区分同步或异步。
软件开发生命周期与统一建模语言UML
建模主事件流
动态模型
软件开发生命周期与统一建模语言UML
建模扩展事件流
动态模型
软件开发生命周期与统一建模语言UML
划分游泳道后的活动图
动态模型
软件开发生命周期与统一建模语言UML
练习：
动态模型
1．画活动图表示如下“自动售货机”的工作过程：顾客向机器 投币；系统检查钱币的数量；系统显示可购买的饮料种类； 顾客选择想买的饮料；如果机器无法送出饮料，则系统提示 顾客想购买的饮料缺货，要求顾客重新选择饮料，否则系统 送出饮料；最后，顾客得到饮料。 2．试画出ATM自动取款机“取款”用例的活动图（参见4.5节 的用例文档）。 3．画出春游的活动图，确定开始、结束状态，考虑天气、费用 等因素，设计出分支、分岔。 4．对选课系统中的Add Course（添加课程）设计和制作活动 图，将管理员输入课程信息作为起始的活动，内容如下： （1）管理员输入信息。 （2）系统验证是否和已有课程冲突。 （3）如果没有冲突，则系统添加新课程，提示课程添加成功。 （4）系统重新进入管理主界面，显示所有课程。 （5）结束。
6.3.3 对象的创建和销毁
ห้องสมุดไป่ตู้动态模型
教师试图修改学生的成绩，但该学生的成绩信息在系统中不存在
软件开发生命周期与统一建模语言UML
6.3.4 顺序图的主要用途
动态模型
顺序图的主要用途之一是表示用例中的行为顺序
在系统开发的早期阶段，顺序图可以应用在高层场景
的表达上；后续阶段，则可以确切地表示对象间的消
（2）添加活动，建模主路径。
（3）寻找分支和并行的情况，建模扩展路径。
（4）根据需要划分游泳道。
软件开发生命周期与统一建模语言UML
“餐馆订餐”系统的用例图
动态模型
软件开发生命周期与统一建模语言UML
“记录预约”用例的事件路径如下：
动态模型
1．接待员输入要预约的日期 2．系统显示该日的预约 3．有一张合适的餐桌可以使用，接待员输入顾客的姓名和 电话号码、预约的时间、用餐人数和餐桌号 3a 没有合适的餐桌可以使用 3a1 用例终止 4．系统记录并显示该预约 4a 输入的预约人数多于餐桌能容纳的人数 4a1 系统发出一个警告信息，询问用户是否想要继 续预约 4a1a 如果回答“否”，用例将不进行预约而终止 4a1b 如果回答“是”，预约将被输入，并附有一 个警告标志
状态图通常作为对类图的补充
软件开发生命周期与统一建模语言UML
状态图映射成代码
动态模型
将不同状态作为常数枚举，把当前状态存储在适
当的数据成员中。
依赖于状态的操作可以用开关语句对每个状态分
别设一个case实现。每个case表示来自特定状
态，用相应的消息表示转换。
需求用专门的数据成员存储对象的历史状态
6.1 动态模型概述
动态模型
一个完整的模型必然描述系统的静态和动态两个方面
静态模型重在描绘系统的组成结构
动态模型描述系统的行为
UML提供如下动态模型：交互图（顺序图和协作图）、状态图、活动图
状态图用来描述某一特定对象所有可能的状态及状态间的转移，是对类 图的补充 顺序图用来描述对象间的动态交互关系，着重体现对象间消息传递的时 间顺序 协作图用来描述相互协作的对象的交互关系和关联关系，着重体现对象 间的静态关联关系 活动图主要用于描述用例内部的工作流程
软件开发生命周期与统一建模语言UML
第 6章
动态模型
动态模型
6.4 协作图
6.4.1 定义协作图
6.4.2 综合实例
6.5 状态图
6.5.1 定义状态图 6.5.2 为什么要建模状态图
6.5.3 状态图映射成代码
6.5.4 状态图实例
软件开发生命周期与统一建模语言UML
第 6章
动态模型
动态模型
6.1 动态模型概述 6.2 活动图
6.2.1 定义活动图 6.2.2 如何建模活动图
6.2.3 实例——活动图在用例模型中的作用
6.2.4 活动图与其它模型
6.3 顺序图
6.3.1 定义顺序图
6.3.2 关于消息 6.3.3 对象的创建和销毁 6.3.4 顺序图的主要用途 6.3.5 顺序图实例
软件开发生命周期与统一建模语言UML
练习：
动态模型
3．假设学生已经成功登录选课系统，“成功选课（ Select Course）” 的顺序图如下，请写出其含义，并画出相关的类图。
软件开发生命周期与统一建模语言UML
6.4 协作图
动态模型
本节教学要求
理解：协作图和顺序图的区别与联系。 掌握：协作图和顺序图之间的转换。
息传递过程。
软件开发生命周期与统一建模语言UML
6.3.5 顺序图实例
动态模型
一家民营企业希望开发一套网上报销系统，在系 统设计要求中规定：员工出差时必须填写出差申 请，每张出差申请上标注了报销限额。因而填写 报销时需填写出差申请编号，以便检查是否超过 限额。
软件开发生命周期与统一建模语言UML
软件开发生命周期与统一建模语言UML
6.4.1 定义协作图
动态模型
协作图可以看做是对象图和顺序图的结合，它能表达对 象间的交互过程及对象间的关联关系
教师修改学生成绩的协作图
软件开发生命周期与统一建模语言UML
6.4.1 定义协作图
动态模型
协作图和顺序图是一对孪生兄弟，它们都能表示 对象间的交互过程。但是它们的侧重点不同 顺序图清楚地表示了交互作用中的时间顺序，但 没有明确表示对象间的关系 协作图清楚地表示了对象间的关联关系，但时间 顺序必须从顺序号获得
软件开发生命周期与统一建模语言UML
状态图的基本符号
动态模型
软件开发生命周期与统一建模语言UML
为什么要建模状态图
动态模型
对象可能会有不同的状态，某些行为依赖于这些状
态。例如，按下开关按钮时，电灯将改变当前的状