软件工程

1. 软件工程 Software Engineering Fall, 2012

2. 第四章 需求分析(Requirements Elicitation) • 面向对象需求分析

3. An overview of OOSE development activities and their products problem statement Requirements elicitation nonfunctionalrequirements functionalmodel usecase diagram Analysis class diagram analysis object model statechart diagram dynamic model sequence diagram System design

4. 面向对象软件工程(OOSE)开发的活动及产物 问题陈述 需求获取 非功能需求 功能需求 用例图 需求分析 类图 分析对象模型 状态图 动态模型 系统设计 序列图

5. Requirements Specification vs Analysis Model Both focus on the requirements from the user’s view of the system. The requirements specification uses natural language (derived from the problem statement) The analysis model uses a formal or semi-formal notation (we use UML)

6. 需求分析面临的困难 需求分析是一个项目的开端，也是项目建设的基石。在失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。 由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又面临着很多困难。

7. 需求分析失败案例 • 1999年NASA（ National Aeronautics and Space Administration，美国国家航空航天局）损失了一颗价值数亿美元的气象卫星，据调查是因为列在度量表中的控制数据出了问题。不巧的是这个缺陷在灾难发生几天之前才刚发现，如果在需求分析阶段就被识别出来就可避免损失了。

8. 面向对象需求分析 • 分析建模的目的是对来自客户的需求形式化。形式化可以导致新的洞察和发现需求错误。 • 避免需求错误或遗漏的第一道防线就是把所有的需求细化，建立分析模型。

9. 需求分析模型 • 分析模型由三个独立的模型构成： • 由用例和场景表示的功能模型； • 用类和对象表示的分析对象模型； • 由状态图和顺序图表示的动态模型。 • 在需求获取阶段得到的用例模型就是功能模型。据此可导出分析对象模型和动态模型。 • 需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件。如数据库、子系统、会话管理器、网络等，不应出现在分析模型中，因为这些概念仅与实现相关。 • 分析中的类可以看作是高层抽象，在后续阶段将使用更多的细节实现。

10. 用例图：视图 功能模型：模型 类图：视图 对象模型：模型 分析模型：模型 顺序图：视图 状态图：视图 动态模型：模型 活动图：视图 分析模型的构成

11. 分析对象模型 • 对象模型是三个模型中最关键的一个模型，它的作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，及它们之间的关系。

12. 图示 参与者 边界对象 控制对象 实体对象 Actor Boundary Entity Control 分析对象模型 • 在分析对象模型中有实体对象、边界对象和控制对象等三种类型。 • 实体对象表示系统将跟踪的持久信息； • 边界对象表示参与者与系统之间的交互（接口）； • 控制对象负责用例的实现。

13. 边界对象 控制对象 实体对象 在RUP的分析中，三类对象分别用下图表示：

14. (1) 实体对象(或实体类) • 负责保存长效且持久的信息。 • 实体类大多数是直接从业务模型或 领域模型中相应实体类得到的。 • 实体类一般表示为一种逻辑数据结构（通常映射为数据表格或文件），有助于开发人员理解系统所依赖的信息。 • 实体对象不一定都是被动的，有时可能具有与它所表示的信息有关的复杂行为。实体对象能够将变化与它们所表示的信息隔离开。

15. (2) 边界对象(或边界类) • 是参与者与系统交互的接口，这些对象位于系统与外部世界的边界上，代表如界面窗口、通信接口、打印机接口、传感器等的抽象，用于阐明和收集系统的边界需求， • 这样，可把用户界面或通信接口的变化隔离在一个或多个边界类中。 • 在分析问题域时，边界类仍保持较高的概念层次，说明通过交互所实现的目标就可以了。 • 在设计活动中（如用户界面设计）才根据参与者操作需求，添加具体的边界对象。

16. (3) 控制对象(或控制类) • 控制用例的流程，表示协调、顺序、事务处理以及对其他对象的控制（如分派任务给其他对象）。 • 主要用来体现应用程序的执行逻辑，可以使得变化不影响用户界面和数据库中的表。

17. UML提供的衍型机制 • 可用UML提供的衍型机制，区分不同类型对象。 • 衍型，UML建模术语。 • 衍型是对UML的词汇扩展，允许创建与已有的构造块相似但针对特定问题的新种类的构造块。 • 在图形上，把衍型表示为双尖括号（即：<<和>>）括起来的名字，放在其他元素名之上。作为一种选择，可以用一种与衍型相联系的新图标表示被衍型化的元素。

18. <<boundary>> LCDDisplayBoundary <<control>> ChangeDateControl <<entity>> Day <<entity>> Month <<entity>> Year <<boundary>> ButtonBoundary 实例：具有两个按钮的手表的分析类 • 使用实体对象、控制对象和边界对象和等概念对系统建模时，常常需要提供一些简单的启发式规则来指导开发人员使用这些概念，可以使用相应的类来跟踪。

19. 实例：具有两个按钮的手表的分析类 • 实体对象：Year、Month、Day • 控制对象：ChangeDateControl • 边界对象：ButtonBoundary、 LCDDisplayBoundary

20. 动态模型 • 动态模型由多个状态图组成。 • 对于每一个具有重要动态行为的类都有一个状态图，从而表明所有系统活动的模式。 • 各个状态图并发地执行，并可以独立地改变状态。 • 各种类的状态图可以通过共享事件组合到一个动态模型中。

21. 面向对象需求分析 - 步骤 • 标识类：通过查看相关资料并与用户广泛地接触，自己对问题域有一个大致的了解。在这个基础上，将问题域中与系统和问题有关的对象提取出来。 • 标识类的关联：将第一步中抽象出来的对象(类)的之间的关系考虑清楚；如整体与部分、从属关系等； • 标识类的属性和操作：为“类”提取与系统问题域有关的属性、服务等； • 由于要完成一项任务，肯定是有不同的对象互相协作完成的。同时一个对象的属性、服务也是在与相关对象的协作中体现出来的。将问题域中所有任务的对象的协作关系搞清楚，是面向对象需求分析的关键一环。即将问题域中的“剧情”搞清楚，是需求分析的主要工作之一。　

22. 面向对象需求分析 • 以上四步并不是单独的而是互有联系，可以同时进行的。通过，对以上4步工作的反复执行我们就可以建立一个基于对象的问题域的模型。 • 在该模型的基础上，可以比较容易地产生一个符合用户需求的软件需求规格说明书成为后续工作的基础。

23. 分析建模活动的实际步骤： • 标识实体对象 • 标识边界对象 • 标识控制对象 • 使用顺序图将用例映射为对象 • 使用CRC卡片对对象之间的交互建模 • 标识关系（结构） • 标识属性 • 对每一对象的与状态有关的行为建模 • 分析模型评审

24. 标识实体对象 • 自然语言分析法：利用Abbott启发式准则，将语言成分映射为模型成分。 • 自然语言分析法主要关注用户术语。但存在以下缺陷： • 识别质量高度依赖人们的书写风格； • 可能会出现许多无关词汇，或同义词。

25. 标识实体对象 • 检查每一个用例，标识所有候选对象 • 用例中的连续名词（如借阅事件）； • 系统需要跟踪的现实世界中的实体（如借阅记录、馆藏图书信息）； • 系统需要跟踪的现实世界中的活动（如紧急情况操作预案）； • 数据源或数据潭（如借阅者、管理员）。

26. 2) 标识边界对象 • 在用例图中，每一个参与者至少要与一个边界对象交互。边界对象收集来自参与者的信息，将它们转换为可用于实体对象和控制对象的表示形式。 • 边界对象对用户界面进行粗略的建模，不涉及如菜单项、滚动条等可视方面的细节。

27. 标识边界对象 • 标识边界对象的启发式准则如下： • 标识用户所需初始用例的用户界面控制; • 标识用户需要键入系统的数据表格; • 标识通知和系统用于响应用户的消息; • 当用例中有多个参与者时，根据构想的用户界面来标识参与者的行为; • 不要使用边界对象对接口的可视方面建模，应使用用户原型对可视用户界面建模; • 使用用户的术语来描述接口，不要使用来自设计和实现的术语。

28. 3) 标识控制对象 • 控制对象负责协调实体对象和边界对象。 • 控制对象在现实世界中没有具体的对应物，它通常从边界对象处收集信息，并把这些信息分配给实体对象。

29. 图书管理系统中的实体对象 • Borrower：借阅者。他们可以借阅、返还、预约和取消预约。因为名字可能重复，可用借阅证号码识别。 • Title：馆藏图书。它表明某一种书，通过馆藏号码识别。 • Book：流通图书。它表明某一种书的具体复本，通过馆藏号码识别。 • Loan：借阅记录。同一个人关于不同图书的借阅记录是不同的。 • Reservation：预约记录。

30. 图书管理系统中的边界对象 • mainWindow：主窗口。有借书、还书、预约、取消预约、添加书种、修改书种、删除书种、添加借阅者、修改借阅者、删除借阅者、添加图书复本、删除图书复本等操作。 • BorrowerDialog：借阅者对话框。有添加借阅者、修改借阅者、删除借阅者等操作。 • FindBwrDialog：弹出对话框。有根据借阅者ID号码查找借阅者的操作。 • TitleDialog：馆藏图书对话框。有添加书种、修改书种、删除书种等操作。

31. FindTDialog：弹出对话框。根据图书的馆藏号查找馆藏图书。FindTDialog：弹出对话框。根据图书的馆藏号查找馆藏图书。 • BorrowDialog：借书对话框。根据馆藏图书的馆藏号和借阅者信息，执行借阅动作，创建和保存借阅记录。 • ReturnDialog：还书对话框．根据流通图书的馆藏号和复本号，执行还书动作，删除借阅记录。 • ReserveDialog：预约对话框。根据馆藏图书的馆藏号和借阅者信息，执行预约、取消预约动作。 • MessageWindow：显示提示信息窗口。 • LoginDialog：输入用户名和密码的窗口。

32. 4) 使用顺序图将用例映射为对象 • 顺序图将用例与对象联系起来，直观地描述了用例（场景）行为在其参与对象之间是如何实施的。 • 顺序图对用例中各参与对象之间的交互序列进行建模。每一个消息从一个对象（或参与者）发送给另一个对象（或参与者）。消息的接受就触发了一个操作。 • 通过顺序图，将责任以操作集合的形式分配给每一个对象。如果一个对象参与到多个用例，则其操作应为这些用例共享。

33. 画顺序图的启发式准则如下： • 顺序图第一栏对应激活该用例的参与者; • 顺序图第二栏是边界对象; • 顺序图第三栏是管理用例中其他参与对象的控制对象; • 通过边界对象来初始化用例，并创建控制对象; • 通过控制对象可创建其他边界对象; • 实体对象允许边界对象和控制对象访问; • 实体对象不能访问边界对象和控制对象;

34. :mainWindow :BorrowDialog :Title :Book :Borrower :Loan :Librarian 1:borrow() 2:createDialog() 3:borrow() 4:findTitle(string) 5:getTitle() 6:getAvaliableBook() 7:findBorrower(string) 8:newLoan(OID, OID, Date) 9:store() 10:getBorrower(OID) 11:update() 12:addLoan(OID) 13:getObject(OID) 14:setLoan(OID) 15:update() 借书用例的顺序图

35. :mainWindow :ReturnDialog :Book :Borrower :Loan :Librarian 1:return() 2:createDialog() 3:return() 4:findBook(Integer) 5:getObject(OID) 6:getLoan() 7:getBorrower() 8:setLoan(null) 9:update() 10:delLoan(OID) 11:update() 12:delete() 还书用例的顺序图

36. 5) 使用CRC卡片对对象之间的交互建模 • CRC是类、职责和协作的缩写。 • CRC (Class, Responsibility, Collaboration) • Class：类，类名在CRC卡的顶端； • Responsibility：职责，该类需要履行的职责在CRC卡的左栏； • Collaboration：协助，该类为了完成其职责，所需要协作的其它类CRC卡的右栏。 • 每一个类可用一张CRC卡片表示。

37. 类名 读卡机 协作 职责 显示欢迎词 密码验证器 接收磁卡 菜单选择器 让密码验证器检验 启动菜单选择器 退出磁卡 类名 密码验证器 协作 职责 从账户中取出密码 账户 如无此账户返回假值 提示客户输入密码 读入密码 比较核实, 返回结果 类名 账户 职责 检查账户有效性 返回密码 检查取款/存款信息 类名 菜单选择器 协作 职责 显示菜单 存款管理器 等待客户选择 取款管理器 调用相应的 存款/取款管理器 类名 取款管理器 协作 职责 询问取款额 账户 要求验证账户 出银机 启动出银机发款

38. 5) 使用CRC卡片对对象之间的交互建模 • 建立CRC卡片有以下几个步骤： • 识别类和职责： 首先识别类或对象，然后从客户需求说明中寻找有关行为的描述，以发现职责。 • 将职责分配到类 ：记录在相应的卡片上。 • 找寻协作者：依次检查每一类承担的责任，看是否需要其他类的帮助，找寻与每个类协作的伙伴，并记录在相应卡片上。 • 细化：模拟在执行每个基本功能时系统内部出现的场景，以此推动细化工作的进行。

39. 5) 使用CRC卡片对对象之间的交互建模 • 在模拟一个场景的过程中，每当一个类开始“执行”时，它的CRC卡片就被拿出来讨论，当“控制”传送到另一个类时，注意力就从前一张卡片转移到另一张上去了。不同的场景，包括例外和出错状况，都应逐一加以模拟。 • 在这个过程中可以验证已有的定义，不断发现新的类、职责以及伙伴。 • 在模拟不同的场景中会发现某些职责需要重新加以分配。这些都导致进一步的开发工作。

40. 6) 标识关联 • 使用类图，能够表示对象之间的关系。 • 关联表示了两个或多个类之间的关系。 • 关联 • 聚集：组成聚集和共享聚集 • 泛化和继承

41. 0..1 雇员 Person Company Country Employment 雇主 0..* 居民 0..* 0..* Residence Site 1..1 1..* 类的关联

42. 聚集 • 支持复用。如“发动机类”可以是一个可复用构件，用于其他系统定义中。 • 能表示动态变化的对象特征。不需要经常变化的属性与操作放在整体类，需要动态变化的特征放在部分类。

43. 滑翔机 机翼 机尾 机身 1 1 1 tail 1 rightWing fuselage leftWing 组成聚集

44. * 1 订单 客户 DateReceived isPrepaid number:String prce:Money Name address CreditRating():String Dispatch() close() 1 团体客户 个人客户 ContactName creditRating creditLimit CreditCard# {creditRating() =“poor”} 项 * Remind() billforMonth(Intrger) 订单项 * Quantity:Integer price:Money isSatisfied:Boolean * 1 产品 销售代表 0..1 雇员 继承：客户、团体客户、个人客户、雇员

45. 标识关联的启发式准则如下： • 检查指示状态的动词或动词短语； • 准确地命名关联和角色； • 尽量使用常用的修饰词标识出名字空间和关键属性； • 消除可导出其他关联的关联； • 在关联集合稳定之前不必关心重复性； • 过多的关联使得一个模型不可读；

46. “主题”的概念 • 主题是把一组具有较强联系的类组织在一起而得到的类的集合。 • 一个主题内部的对象类应具有某种意义上的内在联系 • 描述系统中相对独立的组成部分（如一个子系统） • 描述系统中某一方面的事物（如人员、设备） • 解决系统中某一方面的问题（如输入输出） • 主题的划分有一定的灵活性和随意性

47. 标识关联的操作步骤： a) 基于“主题”建立系统的包图 • 建立边界类的类图 • 建立实体类的类图 • 建立边界类与实体类之间关系的类图 • 实例：图书馆图书借阅管理系统

48. Library GUI DataBase • 基于“主题”建立系统的包图 • 建立包图是为了降低复杂性，目的是控制可见度及指引读者的思路。 • 对于面向对象分析模型，主题表示此模型的整体框架。可以是一个层次结构。 • 通过对主题的识别，可以让人们能够比较清晰地了解大而复杂的模型。

49. messageWindow loginDialog borrowerDialog returnDialog reserveDialog mainWindow findBwrDialog borrowDialog findTDialog TitleDialog • 建立边界类的类图 • 标明类之间的关系，包括关联、泛化等。

50. 1 * Book Title Borrower Loan Persistent (from DataBase) 1 0..1 * * * * 0.. 0.. 0.. 0.. Reservation 1 1 • 建立实体类的类图 • 这些类与数据库相关，为了操作方便，以它们为子类，建立一个持久类(Persistent)作为它们的父类，共享与数据库相关的操作。