搜索
––––内容提纲•概述–面向对象分析与面向对象设计–OOAD模型Youarehere!你在这儿！•面向对象分析的概念–分析类：边界类、控制类、实体类–用例实现•基于用例的分析建模识别分析类定义交互行为建立分析类图检查分析模型2面向对象分析•面向对象分析–注重分析业务领域和系统责任，忽略与实现有关的问题。–发现和描述对象（或概念），分析对象的内部构成和外部关系，建立面向对象的分析模型。3面向对象分析•面向对象分析的制品–分析类•分析类是概念层次上的内容，粒度可能比类大，往往很少有操作和特征标记，使用责任定义其行为，有概念性的属性和关系。–用例实现（从分析角度）•分析类图：描述分析类及其之间的静态关系•交互图：描述分析类之间的交互关系•事件流分析•补充需求：使用文本描述持久性、分布性、并发性、安全性、容错性等方面的非功能需求4面向对象分析•面向对象分析的制品（续）–分析包•建立包图时，应将概念上或语义上相近的模型元素纳入一个包。•一般地，把支持一个特定的业务过程或参与者的一些用例或类组织在一个包中，或把具有泛化或扩展关系的用例或类组织在一个包中。–体系结构描述（从分析角度）•从分析模型的角度，描述系统的体系结构；•通常包括由分析包以及它们之间的依赖、关键分析类、实现重要或关键功能的用例实现。5面向对象分析的过程理解用例模型识别实体类识别分析类识别边界类识别控制类定义交互行为定义属性建立分析类图定义行为定义关系评审分析模型6––––内容提纲•概述–面向对象分析与面向对象设计–OOAD模型•面向对象分析的概念–分析类：边界类、控制类、实体类–用例实现Youarehere!你在这儿！•基于用例的分析建模识别分析类定义交互行为建立分析类图检查分析模型16分析类•分析类的概念–在分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。–分析类直接与应用逻辑相关，而不关注于技术实现的问题。•分析类的类型–实体类：表示系统存储和管理的永久信息–边界类：表示参与者与系统之间的交互–控制类：表示系统在运行过程中的业务控制逻辑17实体类•实体类–描述必须存贮的信息及其相关行为–通常对应现实世界中的“事物”•实体类的UML表示entityName18边界类•边界类–描述外部的参与者与系统之间的交互–类型：用户界面、系统接口、设备接口•边界类的UML表示boundaryName19控制类•控制类–描述一个用例所具有的事件流控制行为–实现对用例行为的封装，将用例的执行逻辑与边界和实体进行隔离•控制类的UML表示controlName20用例实现•用例实现（UseCaseRealizations）–用例实现使用设计模型中的元素描述一个用例是如何实现和执行的，它是从分析和设计追溯到需求的一种方法。–从设计的视角表示用例的内容•动态的：直接对应用例事件序列的交互图•静态的：反映参与用例事件序列的类及其关系的类图•用例实现的UML表示用例用例实现21––––内容提纲•概述–面向对象分析与面向对象设计–OOAD模型•面向对象分析的概念–分析类：边界类、控制类、实体类–用例实现•基于用例的分析建模识别分析类定义交互行为建立分析类图Youarehere!你在这儿！检查分析模型22分析建模过程•理解用例模型–理解用例模型和词汇表，适当补充系统内部情况的描述•识别分析类–找出可能的能够执行用例行为的分析类•定义交互行为–将用例行为分配到分析类中•建立分析类图–确定分析类的关键属性和责任，定义分析类之间的关系•检查分析模型23示例：MiniLibrary注册用户管理读者登录普通读者查询浏览预订图书管理图书资料管理书目图书管理员登记借书取消预订登记还书邮件系统24补充用例描述•补充用例描述–为了发现分析类，有必要补充说明系统的内部行为，即系统内部必须做什么才能响应外部的要求。–可能的情况•用例描述的内容足够充分，不用补充直接可用；•现有事件流中没有明确定义系统内部应该执行的行为，直接在现有用例描述中作出补充行为；•独立于原始用例描述系统的内部行为。25MiniLibrary：补充用例描述•举例：“登记还书”用例图书管理员确认后，系统登记读者的还书记录，并向现有的预订者发出通知。图书管理员确认后，系统登记读者的还书记录，并通过邮件系统向现有的预订者发出通知。26识别分析类•识别边界类–通常，一个参与者与一个用例之间的交互或通信关联对应一个边界类。用户用户界面用例外部系统接口外部系统27识别分析类•识别边界类应当注意的问题–边界类应关注于参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素；–在分析阶段，力求使用用户的术语描述界面；–边界类实例的生命周期并不仅限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。•思考：如何识别MiniLibrary的边界类？28MiniLibrary：识别边界类边界类LoginFormBrowseFormMakeReservationFormRemoveReservationFormManageBorrowersFormManageTitlesFormManageItemsFormLendItemFormReturnItemFormMailSystem说明注册用户进行登录的操作界面注册用户进行查询浏览的操作界面普通读者预订图书的操作界面普通读者取消预订的操作界面图书管理员管理读者的操作界面图书管理员管理图书资料的操作界面图书管理员管理书目的操作界面图书管理员登记借书的操作界面图书管理员登记还书的操作界面与邮件系统的接口29识别分析类•识别控制类–控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物。–一般来说，一个用例对应一个控制类。用户用例外部系统控制逻辑30识别分析类•识别控制类应当注意的问题–当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。–在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为。•举例：MiniLibrary系统中的用例“登录”–如果不同用例包含的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以便降低复杂性。•通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，再分析这些控制类找出它们之间的共同之处。31MiniLibrary：识别控制类控制类BrowseControlMakeReservationControlRemoveReservationControlManageBorrowersControlManageTitlesControlManageItemsControlLendItemControlReturnItemControl说明负责执行注册用户的查询浏览负责执行普通读者的预订图书负责执行普通读者的取消预订负责执行图书管理员对读者的管理负责执行图书管理员对图书资料的管理负责执行图书管理员对书目的管理负责执行图书管理员登记借书负责执行图书管理员登记还书32识别分析类•识别实体类–实体类通常是用例中的参与对象，对应着现实世界中的“事物”事物实实在在事物飞机书交通工具文件工作表充当角色雇员顾客医生病人最终用户组织部门管区部门工段任务组工作组设备传感器定时器打印机键盘显示器突发事件、事件或交互行为航班服务电话登录退出合同地点位置仓库办公室工厂零售店桌面系统管理员鼠标菜单购买订单33识别分析类•识别实体类应当注意的问题–实体类的识别质量在很大程度上取决于分析人员书写文档的风格和质量；–自然语言是不精确的，因此在分析自然语言描述时应该规范化描述文档中的一些措辞，尽量弥补这种不足；–在自然语言描述中，名词可以对应类、属性或同义词等多种类型，开发人员需要花费大量的时间进行筛选。34MiniLibrary：识别实体类实体类BorrowerInfoLoanReservationTitleItem说明普通读者的基本信息普通读者的借书记录普通读者的预订信息图书资料的基本信息书目（由于图书资料中包括书籍和杂志等类型，因此可以进一步划分子类）BookItemMagazineItem书籍的基本信息杂志的基本信息35定义交互行为•交互图可以将用例和分析对象联系在一起，实现将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。用例顺序图用例实现协作图36MiniLibrary：“登记借书”基本流37MiniLibrary：“登记借书”基本流1:specifyCriteria()2:search()8:selectItem()9:lend()5:selectTitle():ReturnItemForm:Librarian4:match(criteria)7:getItems():Title3:search(criteria)6:getItem(title)10:lend(item):ReturnItemControl12:create(borrower,item)11:isAllowed(item):BorrowerInfo:Item13:setStatus():Loan38MiniLibrary：分析类•将“登记还书”用例行为分配到相应的分析类之后，系统的一些分析类具有相应的职责boundaryReturnItemFormspecifyCriteria()search()selectTitle()selectItem()lend()controlReturnItemControlsearch(criteria)getItem(title)lend(item)entityTitlematch(criteria)getItems()entityBorrowerInfoisAllowed(item)entityItemsetStatus()entityLoancreate(borrower,item)39建立分析类图•定义关系–找出分析类之间的关联关系，并通过泛化实现复用。•定义属性1MiniLibrary：分析类图entityBorrowerInfoID:Stringname:StringentityReservation0..ndate:Dateaddress:String0..n110..nentityLoandate:Date111entityTitleISBN:Stringtitle:Stringauthor:StringentityItemID:Integer0..nentityBookTitleloanDays:IntegerentityMagazineTitleloanDays:Integer411应用分析模式•分析模式是描述在系统业务领域发现的通用部分，提高复用性和一致性。•“联系点”分析模式BussinessEntity0..n{ordered}ContactPointPhoneEmailAddress42检查分析模型•检查“正确性”–用户是否可以理解实体对象的术语表？–抽象类与用户层次上的概念对应吗？–所有的描述都与用户定义一致吗？–所有的实体类和边界类都使用具有实际含义的名词短语吗？–所有的用例和控制类都使用具有实际含义的动词短语吗？–所有的异常情况都被描述和处理了吗？–是否描述了系统的启动和关闭？–是否描述了系统功能的管理？43检查分析模型•检查“完整性”–每一个分析类都是用例需要的吗？它在什么用例中被创建、修改和删除？是否存在边界类可以访问它？–每一个属性是在什么时候设置的？其类型是什么？它是限定词吗？–每一个关系是在什么时候被遍历？为什么选定指定的重数？一对多和多对多的关系能被限定吗？–每一个控制类对象是否有必要访问参与用例的对象？44检查分析模型•检查“一致性”–类或用例有重名吗？–具有相同名字的实体表示相同的现象吗？–所有的实体都以同样的细节进