第7章面向对象分析精选文档.ppt

第7章 面向对象分析本讲稿第一页，共七十二页面向对象分析面向对象分析（OOA，Object-Oriented Analysis）是一种半形式化的规格说明技术。目前，最流行的技术是OMT和Booch开发技术面向对象的最大特点是面向用例在用例的描述中引入了外部角色的概念本讲稿第二页，共七十二页面向对象建模面向对象建模面向对象模型对象模型：定义了“做什么”的实体动态模型：规定在何种状态下，接受什么事件的触发而“做什么”功能模型：指明了系统应该“做什么”本讲稿第三页，共七十二页对象模型对象模型对象模型可以看成是数据流和语义数据模型的结合对象模型表示静态的、结构化系统的“数据”性质。它是对模拟客观世界实体的对象，以及对象彼此间的关系的映射，描述了系统的静态结构。对象模型是一个类（包括其属性和行为）、对象（类的实例）、类和（或）对象之间关系的定义集。类名是一类对象的抽象命名，其命名是否恰当对系统的可理解性影响相当大。对象模型还必须表示类/对象之间的结构关系。类/对象之间的关系一般可概括为关联、归纳（泛化）、组合（聚集）三类。本讲稿第四页，共七十二页动态模型动态模型动态模型表示瞬间的、行为化的系统“控制”性质，它规定了对象模型中对象的合法变化序列。对象运行周期中的阶段就是对象的状态。对象状态是对对象属性的一种抽象。对象之间相互触发/作用的行为（称为事件），引起了一系列的状态变化。事件是某个特定时刻所发生的一个系统行为，它是对引起对象从一种状态转换到另一个状态的现实世界事件的抽象。对象对事件的响应，取决于接受该触发的对象当时所处的状态，其响应包括改变自己的状态，或者是形成一个新的触发行为（事件）。动态模型描绘了对象的状态，触发状态转换的事件，以及对象行为（对事件的响应）。本讲稿第五页，共七十二页功能模型功能模型功能模型表示变化的系统的“功能”性质，指明了系统应该“做什么”。它更直接地反映了用户对目标系统的需求。面向对象是以用例驱动的。用例站在用户的角度描述用户的交互过程，有助于软件开发人员更深入地理解问题域，改进和完善自己的分析和设计。对象模型、动态模型和功能模型相辅相承，使得对系统的需求分析和设计描述更加直观、全面。对象模型是最基本、最重要的，它为其他两种模型奠定了基础。本讲稿第六页，共七十二页统一建模语言统一建模语言UML统一建模语言（UML，Unified Modeling Language）是一种基于面向对象的可视化建模语言。UML用丰富的图形符号隐含表示了模型元素的语法，而用这些图形符号组成元模型表达语义，组成模型描述系统结构（或称为静态特征）以及行为（或称为动态特征）。UML的模型元素：一类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等；另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖、聚集（表示整体与部分的关系）等。本讲稿第七页，共七十二页UML模型元素聚集依赖泛化关联状态对象属性操作类属性操作角色用例结点构件包接口注解本讲稿第八页，共七十二页UML模型结构四个抽象层次：元元模型：定义了描述元模型的语言元模型：定义了元类、元属性、元操作等一些概念模型：定义了描述信息领域的语言用户模型：模型的实例，用于表达一个模型的特定情况用户模型模型元模型元元模型事物n 相关 1.n链接对象n 相关 1.n关联类n实例1n实例1.n本讲稿第九页，共七十二页UML模型视图模型视图UML主要是用来描述模型的。它可以从不同视角为系统建模，形成不同的视图（View）。每个视图是系统完整描述中的一个抽象，代表该系统一个特定的方面；每个视图又由一组图（Diagram）构成，图包含了强调系统某一方面的信息。两类图：静态图：包括用例图、类图、对象图、构件图和部署图动态图：包括状态图、时序图、协作图和活动图五种视图：用例视图从用户角度表达系统功能；结构视图主要使用类图和对象图描述系统静态结构；行为视图展示系统动态行为及其并发性；实现视图展示系统实现的结构和行为特征；部署视图展示系统的实现环境和构件是如何在物理结构中部署的本讲稿第十页，共七十二页用例建模用例建模需求捕获的目标：发现真正的需求以适用于用户、客户和开发人员的方式加以表示系统用户表示为一个参与者参与者在与用例进行交互时使用系统用例向参与者提供某些有价值结果而执行一些动作序列本讲稿第十一页，共七十二页编写用例编写用例用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。要开始开发用例，应列出特定参与者执行的功能或者活动。用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。用例图描述部分用例模型，显示带有联系的用例和参与者的集合本讲稿第十二页，共七十二页POS机系统部分用例图本讲稿第十三页，共七十二页用例图用例图包括：参与者、用例、关联和边界四个要素。参与者：用小人形表示用例：用椭圆表示关联：用直线表示说明参与者驱动某个用例边界：用矩形框表示，说明系统关注点。本讲稿第十四页，共七十二页开发用例用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，有些格式更强调描述的直观性。用例不同部分用例不同部分说明说明用例名称以动词开始描述用例名称范围要设计的系统级别“用户目标”或者是“子功能”主要参与者调用系统，使之交付服务渋众及其关注点关注该用例的人，及其需要前置条件开始前必须为真的条件成功保证成功完成必须满足的条件主成功场景典型的、无条件的、理想方式的成功场景扩展成功或失败的替代场景特殊需求相关的非功能性需求技术和数据变元素不同的I/O方法和数据格式发生频率影响对实现的调查、测试和时间安排杂项未决问题等本讲稿第十五页，共七十二页POS机系统中处理销售的场景用例名称：用例名称：处理销售范围范围：POS机应用级别级别：用户目标主要参与者主要参与者：收银员涉众及其关注点涉众及其关注点：收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。售货员：希望自动更新销售提成顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。前置条件前置条件：收银员必须经过确认和认证。成功保证（或后置条件）成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。本讲稿第十六页，共七十二页主成功场景主成功场景1.顾客携带所购商品或服务到收银台通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入商品条码。4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5.系统显示总额和计算折扣。6.收银员告知顾客总额，并请顾客付款。7.顾客付款，系统处理支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。9.系统打印票据。10.顾客携带商品和票据离开。本讲稿第十七页，共七十二页开发活动图开发活动图UML活动图通过提供特定的场景内交流的图形化表示来补充用例。活动图符号：两端为半圆形的矩形表示一个特定的系统功能箭头表示通过系统的流判定菱形表示判定分支水平线、分叉点和连接表示并发活动对象节点表示活动对象活动图通常能够既表示控制流又表示数据流。UML活动图代替传统的数据流图（Data Flow Diagram）表示法本讲稿第十八页，共七十二页处理销售用例中的UML活动图本讲稿第十九页，共七十二页泳道图泳道图UML泳道图（swimlane）是活动图的一种有用的变形可以让建模人员表示用例所描述的活动图，同时看哪个参与者或分析类对活动矩形所描述的活动负责。泳道用纵向分割图的并列条形部分表示，就像游泳池中的泳道，也称特定分区。UML泳道图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。本讲稿第二十页，共七十二页泳道图举例泳道图举例本讲稿第二十一页，共七十二页建立领域模型建立领域模型领域模型能捕获语境中最重要的对象模型，领域对象代表系统工作的环境中存在的事情或发生的事件。领域有三种典型的形式：业务对象，表示业务中可操作的东西，例如订单、帐户和合同等。系统需要处理的现实世界中的对象和概念，如导弹、轮船等。将要发生或已经发生的事件，例如飞机起飞或午餐休息等。领域建模的目的是理解和描述在领域语境中最重要的类本讲稿第二十二页，共七十二页识别分析类识别分析类领域模型实际上是更为完整的业务模型的一个特例有两种类型的UML模型支持业务建模：用例模型对象模型对系统开发的用例或处理叙述进行“语法分析”，可以开始分析类的识别。本讲稿第二十三页，共七十二页分析类识别方式外部实体：使用基于计算机的系统的信息。事物：问题信息域的一部分。发生或事件：在系统操作环境内发生。角色：由和系统交互的人员扮演。组织单元：和某个应用相关。场地：建立问题的环境和系统的整体功能。结构：定义了对象的类或与对象相关的类。本讲稿第二十四页，共七十二页分析类分析类侧重于处理功能性需求通过较高的、非形式化层次的职责类定义某行为分析类三种基本构造型：边界类：边界类用于建立系统与其参与者之间交互的模型，经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端以及API等的抽象。每个边界类至少应该与一个参与者有关，反之亦然。控制类：控制类代表协调、排序、事务处理以及其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可以用来表示复杂的派生与演算，如业务逻辑。实体类：实体类用于对长效持久的信息建模。大多数情况下，实体类是直接从业务对象模型中相应的业务实体类得到的。本讲稿第二十五页，共七十二页分析类举例本讲稿第二十六页，共七十二页控制类控制类类似于设计模型中的控制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。把职务分配给能代表以下选择之一的类：代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观控制器的所有变体。代表用例场景，在该场景中发生系统事件，通常命名为UsecaseName+Handler、UsecaseName+Coordinator或UsecaseName+Session。本讲稿第二十七页，共七十二页控制类举例本讲稿第二十八页，共七十二页用例实现分析用例实现分析用例实现分析是分析模型内部的一种协作，主要描述了如何根据分析类及其交互的分析对象来实现和执行一个具体的用例。用例实现包括事件流的文本描述、反映参与者用例实现的分析的类图以及按照分析对象的交互作用描述特定流实现或用例脚本的交互图。用例实现侧重于功能性需求。本讲稿第二十九页，共七十二页处理销售类图本讲稿第三十页，共七十二页交互图当参与者向系统发送某种形式的消息而激活用例时，开始执行该用例中的动作序列。边界类对象将接收来自参与者的消息。边界对象向其他对象发送一个消息，并使有关对象与之交互从而实现该用例。在分析阶段，通常使用协作图类描述用例的实现。协作图又称为通信图，是以图或网络格式描述对象交互，其中对象可以置于图中任何位置。本讲稿第三十一页，共七十二页本讲稿第三十二页，共七十二页处理销售协作流的事件-分析流收银员通过处理销售商品界面发起一次销售，控制类创建一个销售类，收银员逐个输入商品，销售类创建商品，并放入销售列表中。控制类要求计算商品总价，收银员请求顾客付款，控制类委派销售类创建一个支付。本讲稿第三十三页，共七十二页分析包分析包描述了对分析模型的制品进行组织的方式，它可以包括分析类、用例实现及其他分析。分析包应是有强内聚性与低耦合性，具有以下特点：分析包可以表示对分析内容的分割。在统一过程中，服务的概念是由服务包支持的。服务包在按照系统提供的服务而组织的分析包层次结构中处于较低层。服务包包含了一组活动相关的类，服务包不可分割。在实现用例时，可能会有一个或多个服务包参与其实现。服务包相对独立，可以复用。UML包图用于描述系统的逻辑架构层、子系统、包等。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内，否则，可以标在包内。本讲稿第三十四页，共七十二页UML包图本讲稿第三十五页，共七十二页逻辑架构逻辑架构是类的宏观组织结构，它将类组织为包、子系统和层等。层是对类、包或子系统的甚为粗粒度的分组，是有对系统主要方面加以内聚的职责。本讲稿第三十六页，共七十二页分层逻辑架构本讲稿第三十七页，共七十二页关联与依赖关联与依赖两个分析类以某种方式相互联系，这些联系被称作关联。关联可进一步指出多样性，也称为基数。两个分析类之间存在客户服务器联系，客户类在某些方面依赖于服务器类并且建立了依赖关系。本讲稿第三十八页，共七十二页识别属性和操作识别属性和操作属性描述类的性质，可以通过分析该类存在的一些信息类构建。操作定义了某个对象的行为。操作可以分为四种类型：以某种方式操纵数据，例如：添加、删除、选择、更新等。执行计算的操纵，例如：销售中的计算总价。请求某个对象状态的操作。监视某个对象发生某个控制事件的操作。操作的构造需要交互图和场景描述等手段多次反复分析才能获取。在研究语法分析并分离动词作为候选的操作。推荐的一个方法是使用CRC技术。本讲稿第三十九页，共七十二页CRC技术CRC(Class-Responsibility-Collaborator,类-职责-协作者)建模提供识别和组织与产品相关的类。一旦系统的基本使用场景（用例）确定后，则要标识侯选类，指明它们的责任和协作，即类-责任-协作者建模：责任是与类相关的属性和操作，即责任是类知道要做的事情。协作者是为某类提供完成责任所需要的信息的类，即协作类。CRC建模方法提供了一种简单标识和组织与系统或产品需求相关的类的手段。CRC模型是一组表示类标准的索引卡CRC卡的集合。CRC卡的内容分成三个部分：类的名字类的责任协作类本讲稿第四十页，共七十二页销售类CRC卡Class：销售类说明：完成一次销售职责职责：协作类协作类：创建商品商品类计算总价商品列表类创建支付支付类计算找零无本讲稿第四十一页，共七十二页行为建模行为建模行为模型显示了软件如何对外部事件或激励做出响应。要生成行为模型，分析师必须按如下步骤进行：评估所有的用例，以使得完成理解系统内的交互序列。识别驱动交互序列的事件，并理解这些事件如何和具体的类相互关联。为每个用例生产序列。创建系统状态图。评估行为模型以验证准确性和一致性。本讲稿第四十二页，共七十二页系统顺序图系统顺序图（System Sequence Diagram,SSD）是为了阐述与讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和重要对象设计的输入。用例文本及其所示的系统事件是创建SSD的输入。SSD展示了直接与系统交互的外部参与者，系统以及由参与者发起的系统事件。SSD可以用UML顺序图的形式表示，用以阐述外部参与者到系统的事件。系统事件就是将系统看作黑盒，参与者为完成功能而向系统发出的事件。本讲稿第四十三页，共七十二页处理销售用例的系统SSD本讲稿第四十四页，共七十二页操作契约操作契约使用前置条件和后置条件的形式，详细和精确描述领域模型中的对象的变化，并作为系统操作的结果。操作契约的主要输入是SSD中确定的系统操作、领域模型和领域专家的见解。操作契约四部分：操作是指操作的名称和参数交叉引用是指会发生此操作的用例前置条件是指执行操作之前对系统领域模型对象状态的假设后置条件是指完成操作后，领域模型对象的状态本讲稿第四十五页，共七十二页后置条件后置条件（Post Condition）描述了领域模型内对象状态的变化。领域模型状态变化包括创建用例、形成或消除关联以及改变属性。后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果。后置条件可以分为三种类型：创建或删除实例属性值的变化形成或消除关联本讲稿第四十六页，共七十二页操作enterItem的契约操作名称操作名称：enterItem(id,quantity)交叉引用交叉引用：处理销售用例前置条件前置条件：正在进行的销售后置条件后置条件：（1）创建了SaleLineItem的实例（创建关联）（2）SaleLineItem与当前Sale关联（形成关联）（3）SaleLineItem.quantity赋值为quantity(修改属性)（4）基于id匹配，将SaleLineItem关联到Product Description(形成关联)本讲稿第四十七页，共七十二页顺序图与协作图顺序图与协作图表现系统行为方式的一种方式是UML的顺序图和协作图。顺序图和协作图的作用相同，但顺序图强调事件的时间关系。顺序图表现了导致行为从一个类流动到另一个类的关键类和事件。顺序图的主要元素有：对象：参与交互的类的实例，对象之间可以发送事件和接收事件。参与者：描述本次交互的发起者，即用例的驱动者。用小人形状表示。生命线：表示一个类的实例，用虚线表示。消息：表示对象间的每个事件，用带箭头的实线表示。执行规格条：表示控制焦点的控制期，也称为激活条。消息标签：指明消息的名称。消息可以有两种方式返回结果：使用消息语法return var=message（parameter）；在执行规格条末端使用应答消息线（带箭头虚线）。本讲稿第四十八页，共七十二页处理支付用例的顺序图本讲稿第四十九页，共七十二页本讲稿第五十页，共七十二页状态图状态图两种不同的状态描述：系统执行其功能时每个类的状态，类状态动两种特征：被动状态较简单，是某个对象所有属性的当前状态；主动状态表示的是对象进行持续变换和处理时的当前状态。系统执行其功能时从外部观察到的系统状态。UML状态图描述系统的动态行为。UML状态图描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为。UML状态图的元素有：状态：指对象在事件发生之间某时刻所处的情形，用圆角矩形表示。转移：指两个状态之间的关系，它表明当某事件发生时，对象从先前状态转换到后来的状态，用带有标记事件的箭头表示。事件：某个事情的发生。初始状态：当实例创建时，对象所处的状态。本讲稿第五十一页，共七十二页POS机的一个简单的状态图本讲稿第五十二页，共七十二页实例分析：实例分析：POS机系统机系统本讲稿第五十三页，共七十二页实例分析：实例分析：POS机系统机系统本讲稿第五十四页，共七十二页本讲稿第五十五页，共七十二页添加商品项的顺序图本讲稿第五十六页，共七十二页计算总价本讲稿第五十七页，共七十二页处理支付顺序图本讲稿第五十八页，共七十二页ATM系统：用例图系统：用例图本讲稿第五十九页，共七十二页ATM系统：类图系统：类图本讲稿第六十页，共七十二页ATM系统：协作图系统：协作图本讲稿第六十一页，共七十二页ATM系统：顺序图系统：顺序图本讲稿第六十二页，共七十二页短信系统：用例图短信系统：用例图本讲稿第六十三页，共七十二页短信系统：类图短信系统：类图本讲稿第六十四页，共七十二页短信系统：协作图短信系统：协作图本讲稿第六十五页，共七十二页短信系统：顺序图短信系统：顺序图本讲稿第六十六页，共七十二页小结小结分析建模的目标是创建各种表现形式，以描绘软件信息、功能和行为需求。面向对象分析就是检查一组用例的问题域，尽量提取定义问题的类及其类之间的关系、并使用UML图建模和编写用例场景，以及开发活动图和泳道图来加以刻画。基于类的建模使用从基于场景的描述中提取分析类，可以使用语法分析从文本叙述中提取候选类、属性和操作。CRC卡可以用于定义类之间的关系和获取类的职责以及协作类，并用逐步分析类聚合和继承关系及依赖。本讲稿第六十七页，共七十二页小结UML包图可用于描述系统的逻辑架构，使用层的方式类划分系统，定义包之间的关联和依赖，便于开发人员分工和并发工作。类建模和包图的描述为分析建模提供了软件的静态视图，而行为建模描述了动态行为。行为模型使用SSD、操作契约、顺序图和状态图来分析系统的动态行为。本讲稿第六十八页，共七十二页第二部分实验软件分析与建模工具：实验3 MS的Visio使用实验4 Sybase的PowerDesigner分析建模实验6 IBM的Rational Rose工具基本使用本讲稿第六十九页，共七十二页实验3 MS的Visio使用实验目的：学习使用Visio绘制软件工程各种模型视图的方法实验内容：使用Microsoft Visio绘制提交一个与项目有关的程序流程图使用Microsoft Visio绘制提交一个与项目有关的数据流图使用Microsoft Visio绘制提交一个与项目有关的状态图使用Microsoft Visio绘制提交一个与项目有关的实体关系图提交一个与项目有关的网络结构图本讲稿第七十页，共七十二页实验4 PowerDesigner分析建模实验目的：学习使用PowerDesigner构建数据模型的方法实验内容：使用PowerDesigner绘制一个概念数据模型视图使用PowerDesigner绘制一个业务处理模型视图使用PowerDesigner绘制一个物理数据模型视图本讲稿第七十一页，共七十二页实验6 Rational Rose工具基本使用实验目的：实验目的：了解Rational Rose工具软件的特点、用途、功能、安装。掌握Rational Rose工具基本操作与建模过程。使用Rational Rose绘制软件工程应用。实验内容：实验内容：使用Rational Rose完成一个系统的业务分析模型。使用Rational Rose完成一个系统的设计模型的详细视图，包括用况视图、逻辑视图、开发视图、展开视图和物理视图。本讲稿第七十二页，共七十二页