1、第5章 需求建模软 件 工 程主要内容 需求分析 分析建模的方法 数据建模的方法 面向对象的分析 基于场景建模 面向流建模 基于类的建模软 件 工 程5.1 需求分析 需求分析产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。分析时回答“做什么”，设计时回答“怎么做”。软 件 工 程5.1.1 整体目标和原理 三个目标：（1）描述客户需要什么（2）为软件设计奠定基础（3）定义在软件完成后可以被确认的一组需求 系统描述 分析模型 设计模型图7-1 分析模型与其它过程的关系软 件 工 程5.1.2 分析的经验原则 模型的抽象度高于设计，不要太多细节 分析模型的细致度
2、要高于系统描述级 关于基础结构和其他非功能性的模型应推延到设计阶段再考虑 应尽量使模型的不同部分独立 确认模型充分考虑到了各方面的利益 尽量简洁软 件 工 程5.1.3 域分析 分析模型通常在特定领域内的很多应用重复发生 不同领域的要求和工作千差万别，软件实现起来各不相同。但是，往往还是能在其间找到一些共同的东西。域分析的目标：查找这些共同点，创造能复用的查找这些共同点，创造能复用的东西。东西。软 件 工 程5.1.3 域分析 域分析：软件域分析师识别、分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的面向对象的域分析是在某个特定的应用领域内，根据通用的
3、对象、类、部件和框架，识别、分析和详细说明公共的、可复用的能力软 件 工 程图 域分析过程的输入和输出软 件 工 程5.2 分析建模的方法1.结构化分析：着重考虑数据和处理。2.面向对象分析：对各种对象加以研究，包括其对应的数据和处理。关注于定义类和影响客户需求的类之间的协作方式软 件 工 程5.2 分析建模的方法（续）图：分析模型的元素分析模型将生成如下图所示元素的派生类：软 件 工 程5.3 数据建模概念 分析建模通常开始于数据建模 数据建模的基本要素：数据对象、数据属性，对象之间的关系。对象/关系对是数据对象的基石。可以使用实体/关系图图形化地表示这些对象/关系对软 件 工 程5.3 数
4、据建模概念（续）实体-联系图（Entity-Relationship Approach,ERD）是按照用户的观点对数据建立的模型 数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系 不涉及数据世界的数据结构、存取路径、存取效率等问题。它可以转换成数据库中的数据模型。软 件 工 程5.3 数据建模概念（续）数据对象：是对软件必须理解的复合信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。可以由一组属性来定义的实体都可以被认为是数据对象。如：外部实体(例如，产生或使用信息的任何事物)；事物(例如，报表)；行为(例
5、如，打电话)；事件(例如，响警报)；角色(例如，教师、学生)只封装数据，在数据对象在内没有作用于数据的操作的引用软 件 工 程5.3 数据建模概念（续）属性 属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。软 件 工 程5.3 数据建模概念（续）联系/关系 数据对象彼此之间相互连接的方式称为联系，也称为关系E-R图中表示实体联系的符号软 件 工 程举例 例:在教学管理中，一个教师可以教零门、一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象(实体）有学生、教师和课程
6、。软 件 工 程举例 解答:用E-R图描述它们之间的联系，得下图。其中，学生与课程是多对多的联系，而教师与课程的联系是零、一对多。软 件 工 程进一步，要确定属性。例如，1.学生具有学号、姓名、性别、年龄、专业（其它略）等属性；2.课程具有课程号、课程名、学分、学时数等属性；3.教师具有职工号、姓名、年龄、职称等属性;此外，学生通过学号、分数与课程发生联系。如此可得教学实体模型。E-R方法软 件 工 程教学E-R图软 件 工 程5.4 面向对象的分析 面向对象（Object-oriented,OO)的目的是定义与即将解决的问题相关的所有类（以及与其相关的 关系与行为），为实现这点，必须完成如下
7、工作:在客户和软件工程师之间必须对基本的用户需求进行交流。确定类（定义属性、方法）定义类的层次结构表现对象之间的关系为对象行为建模重复上述步骤，直至建模完成软 件 工 程5.4.1 面向对象分析的基本过程 面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。通常，面向对象分析过程从分析陈述用户需求的文件开始。但是，不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础。接下来，系统分析员应该深入理解用户需求，抽象出目标系统的本质属性，并用模型准确地表示出来软 件 工 程 面向对象建模得到的模型包含对象的三个要素：静态结构（对象模型）交互次序（动态模型）数据变换（功能
8、模型）三个子模型与五个层次软 件 工 程 三个子模型与五个层次 解决的问题不同，这三个子模型的重要程度也不同：几乎解决任何一个问题，都需要从客观世界实体及实体间相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序时（例如，用户界面及过程控制等），动态模型是重要的；解决运算量很大的问题（例如，高级语言编译、科学与工程计算等），则涉及重要的功能模型。动态模型和功能模型中都包含了对象模型中的操作（即服务或方法）。软 件 工 程复杂问题（大型系统）的对象模型由下述五个层次组成：三个子模型与五个层次在概念上，这5个层次是整张模型的5张水平切片软 件 工 程 面向对象分析大体上按照下列顺序进行：寻找
9、类一一对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。但是分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。三个子模型与五个层次软 件 工 程5.4.2 需求陈述 书写要点 通常，需求陈述的内容包括：问题范围 功能需求 性能需求 应用环境及假设条件等。总之，需求陈述应该阐明“做什么”而不是“怎样做”。软 件 工 程5.4.2 需求陈述（续）需求陈述注意事项：应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活
10、性 对系统性能及系统与外界环境交互协议的描述，是合适的需求 对采用的软件工程标准、模块构造准则，将来可能做的扩充以及可维护性要求等方面的描述，也是适当的需求。软 件 工 程 例子自动取款机（ATM）系统5.4.2 需求陈述（续）软 件 工 程下面陈述对ATM系统的需求：5.4.2 需求陈述（续）某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台 ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。银
11、行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。软 件 工 程拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金（即取款），或查询有关自己账户的信息（例如，某个指定账户上的余额）。将来可能还要求使用ATM办理转账、存款等事务。所谓现金兑换
12、卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。5.4.2 需求陈述（续）软 件 工 程当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计
13、算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等）。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。5.4.2 需求陈述（续）软 件 工 程5.4.3 建立对象摸型 面向对象分析的首要工作，是建立问题域的对象模型，因为静态数据结构相对比较稳定 对象模型通常有五个层次。典型的工作步骤是:首先确定对象类和关联（因为它们影响系统整体结构和解决问题的方法）对于大型复杂问题还要进一步划分出
14、若干个主题；然后给类和关联增添属性，以进一步描述它们；接下来利用适当的继承关系进一步合并和组织类。而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后。软 件 工 程1.确定类与对象（1）找出候选的类与对象找出候选的类与对象 具体地说，大多数客观事物可分为下述五类：可感知的物理实体，例如，飞机、汽车、书、房屋等等。人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。应该记忆的事件，例如，飞行、演出、访问、交通事故等等。两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。需要说明的概念，例如，政策、保险政策、版权法等等。5.4.3 建立对象摸型
15、（续）软 件 工 程 另一种更简单的找出候选的类与对象的方法：非正式分析 需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务（操作）的候选者。认真阅读上面给出的需求陈述，从陈述中找出下列名词，可以把它们作为类与对象的初步的候选者：银行，自动取款机（ATM），系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。5.4.3 建立对象摸型（续）软 件 工 程（2）筛选出正确的类与对象）筛选
16、出正确的类与对象 接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。5.4.3 建立对象摸型（续）软 件 工 程确定类与对象 筛选时主要依据下列标准，删除不正确或不必要的类与对象：冗余 如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。以ATM系统为例，应该去掉“用户”、“磁卡”、“副 本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。软 件 工 程无关 仅需要把与本问题密切相关的类与对象放进目标系统中。以ATM系统为例，因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。确定类与对象软
17、 件 工 程确定类与对象笼统 在需求陈述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类与对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。以ATM系统为例，应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。软 件 工 程属性 在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对
18、待。确定类与对象软 件 工 程确定类与对象操作 在需求陈述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。软 件 工 程实现 在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类与对象。在ATM系统的例子中，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们确定类与对象软 件 工 程2.确定关联 两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类与对象。5.4.3 建立对象摸型（续
19、）软 件 工 程（1）初步确定关联 在需求陈述中使用的描述性动词或动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过直接提取需求陈述中的动词词组而得出。通过分析需求陈述，还能发现一些在陈述中隐含的关联。确定关联软 件 工 程以ATM系统为例，经过分析初步确定出下列关联：确定关联ATM、中央计算机、分行计算机及柜员终端组成网络。总行拥有多台ATM。ATM设在主要街道上。分行提供分行计算机和柜员终端。柜员终端设在分行营业厅及储蓄所内。分行分摊软件开发成本。储户拥有账户。分行计算机处理针对账户的事务。分行计算机维护账户。柜员终端与分行计算机通信。柜员输入针对账户的事务。ATM与中
20、央计算机交换关于事务的信息。中央计算机确定事务与分行的对应关系。ATM读现金兑换卡。ATM与用户交互。ATM吐出现金。ATM打印账单。系统处理并发的访问。直接提取动词短语得出的关联：软 件 工 程 需求陈述中隐含的关联 总行由各个分行组成。分行保管账户。总行拥有中央计算机。系统维护事务日志。系统提供必要的安全性。储户拥有现金兑换卡。根据问题域知识得出的关联 现金兑换卡访问账户。分行雇用柜员。确定关联软 件 工 程（2）筛选 筛选时主要根据下述标准删除候选的关联：已删去的类之间的关联 如果在分析确定类与对象的过程中已经删除了某个候选类，则与这个类有关的关联也应该删去。确定关联软 件 工 程 以A
21、TM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列入个关联也应该删去：ATM、中央计算机、分行计算机及柜员终端组成网络。ATM设在主要街道上。分行分摊软件开发成本。系统提供必要的安全性。系统维护事务日志。ATM吐出现金。ATM打印账单。柜员终端设在分行营业厅及储蓄所内。确定关联软 件 工 程与问题无关的或应在实现阶段考虑的关联 例如，在ATM系统的例子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事
22、务。确定关联软 件 工 程瞬时事件 关联应该描述问题域的静态结构，而不应该是一个瞬时事件。以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。确定关联软 件 工 程三元关联 三个或三个以上对象之间的关联，大多可以分解为二元关联或用词组描述成限定的关联。在ATM系统的例子中，“柜员输入针对账户的事务”可以分解成“柜员输人事务”和“事务修改账户”这样两个二元关联。确定关联软 件 工 程确定关联派生关联 应该去掉那些可以用其他关联定义的冗余关联。例如，在ATM系统
23、的例子中，“总行拥有多台 ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”软 件 工 程（3）进一步完善 应该进一步完善经筛选后余下的关联，通常从下述几个方面进行改进：正名 好的名字是帮助读者理解的关键因素之一。因此，应该仔细选择含义更明确的名字作为关联名。分解 为了能够适用于不同的关联，必要时应该分解以前确定的类与对象。例如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。确定关联软 件 工 程确定关联 补充 发现了遗漏的关联就应该及时补上。例如，在ATM系统中把“
24、事务”分解成上述两类之后，需要补充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。标明重数 应该初步判定各个关联的类型，并粗略地确定关联的重数。软 件 工 程软 件 工 程3.划分主题 在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题内的对象相互间依赖和交互最少的原则来确定主题。5.4.3 建立对象摸型（续）软 件 工 程划分主题 以ATM系统为例，我们可以把它划分成“
25、总行”、“分行”和“ATM”等三个主题，这三个主题的编号分别是l、2和3。软 件 工 程软 件 工 程4.确定属性 属性是对象的性质，藉助于属性我们能对类与对象和结构有更深入更具体的认识。注意，在分析阶段不要用属性来表示对象间的关系，使用关联能够表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。一般说来，确定属性的过程包括分析和选择两个步骤。5.4.3 建立对象摸型（续）软 件 工 程（1）分析 属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析阶段不要考虑那些纯粹用于实现的属性。确定属性软 件 工 程
26、确定属性（2）选择 认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。通常有以下几种常见情况：误把对象当作属性 如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。把链属性误作为属性 如果某个性质依赖于某个关联链的存在，则该性质是链属性，在分析阶段不应该把它作为对象的属性。软 件 工 程把限定误当成属性 限定是一种特殊的链属性。在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。误把内部状态当成了属性 如果某个性质是对象的非公开的内部状态，则
27、应该从对象模型中删掉这个属性。确定属性软 件 工 程确定属性 过于细化 在分析阶段应该忽略那些对大多数操作都没有影响的属性。存在不一致的属性 类应该是简单而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。软 件 工 程经过筛选之后，得到ATM系统中各个类的属性软 件 工 程5.识别继承关系 可以使用两种方式建立继承（即归纳）关系：自底向上：抽象出现有类的共同性质泛化出父类。例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”；自顶向下：把现有类细化成更具体的子类；但是，分析阶段应该避免过度细化。确定属性软 件 工 程软 件
28、工 程6.反复修改 仅仅经过一次建模过程很难得到完全正确的对象模型。事实上，软件开发过程就是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改5.4.3 建立对象摸型（续）软 件 工 程 下面以ATM系统为例，讨论可能做的修改：1.分解“现金兑换卡”类 把“现金兑换卡”类分解为“卡权限”和“现金兑换卡两个类，将使每个类的功能更单一；2.“事务”由“更新”组成“更新”虽然代表一个动作，但是它有自己的属性（类型、金额等），应该独立存在，因此应该把它作为类与对象3.把“分行”与“分行计算机”合并 应该合并“分行”与“分行计算机”，“总行”和“
29、中央计算机”。反复修改软 件 工 程软 件 工 程5.4.4 建立动态模型 对于仅存储静态数据的系统（例如数据库）来说，动态模型并没有什么意义。然而在开发交互式系统时，动态模型却起着很重要的作用。如果收集输入信息是目标系统的一项主要工作，则在开发这类应用系统时建立正确的动态模型是至关重要的。软 件 工 程 建立动态模型的步骤：1.编写典型交互行为的脚本。2.从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象3.排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。4.比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。5.4.4 建立
30、动态模型（续）软 件 工 程1.编写脚本 在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。编写脚本的目的，是保证不遗漏重要的交互步骤，它有助于确保整个交互过程的正确性的和清晰性。脚本描写的范围并不是固定的，既可以包括系统中发生的全部事件，也可以只包括由某些特定对象触发的事件。脚本描写的范围主要由编写脚本的具体目的决定。5.4.4 建立动态模型（续）软 件 工 程 编写脚本时，首先编写正常情况的脚本。然后，考虑特殊情况，最后，考虑出错情况。对于每个事件，都应该指明触发该事件的动作对象（例如，系统、用户或其他外部事物）、接受事件的目标对象以及该事件的参数。编写脚本软 件 工
31、程表 系统的正常情况脚本软 件 工 程表 系统的异常情况脚本软 件 工 程2.设想用户界面 大多数交互行为都可以分为应用逻辑和用户界面两部分。动态模型着重表示应用系统的控制逻辑。但是，用户对系统的“第一印象”往往从界面得来，因此，在分析阶段也不能完全忽略用户界面。5.4.4 建立动态模型（续）软 件 工 程图系统的界面格式软 件 工 程3.画事件跟踪图 进一步明确事件及事件与对象的关系。确定事件 应该仔细分析每个脚本，以便从中提取出所有外部事件。事件包括系统与用户（或外部设备）交互的所有信号、输入、输出、中断、动作等等。传递信息的对象的动作也是事件。例如，储户插入现金兑换卡、储户输入密码、AT
32、M吐出现金等都是事件。大多数对象到对象的交互行为都对应着事件。应该把对控制流产生相同效果的那些事件组合在一起作为一类事件，并给它们取一个唯一的名字。例如，“吐出现金”是一个事件类。5.4.4 建立动态模型（续）软 件 工 程画出事件跟踪图 可以用事件跟踪图把事件序列以及事件与对象的关系，形象、清晰地表示出来。事件跟踪图实质上是扩充的脚本。在事件跟踪图中，一条竖线代表一个类与对象，每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。时间从上向下递增。画事件跟踪图软 件 工 程软 件 工 程4.画状态图 状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于
33、当前状态及所接受的事件。由事件引起的状态改变称为“转换”。如果一个事件并不引起当前状态发生转换，则可忽略这个事件。5.4.4 建立动态模型（续）软 件 工 程5.4.4 建立动态模型（续）通常，用一张状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。考虑完正常事件之后再考虑边界情况和特殊情况，其中包括在不适当时候发生的事件（例如，系统正在处理某个事务时，用户要求取消该事务）。软 件 工 程图类的状态图软 件 工 程图总行类的状态图软 件 工 程图分行类的状态图软 件 工 程5.审查动态模型 各个类的状态图通过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重要交互行为的类的状
34、态图之后，应该检查系统级的完整性和一致性。应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。5.4.4 建立动态模型（续）软 件 工 程5.4.5 建立功能摸型 功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。通常在建立了对象模型和动态模型之后再建立功能模型。软 件 工 程1.画出基本系统模型图 基本系统模型由若干个数据源点终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。5.4.5 建立功
35、能摸型（续）软 件 工 程图ATM系统的基本系统模型软 件 工 程2.画出功能级数据流图 把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，就得到功能级数据流图。3.描述处理框功能 把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。5.4.建立功能摸型（续）软 件 工 程图 ATM系统的功能级数据流图软 件 工 程5.4.6 定义服务“对象”是由描述其属性的数据，及可以对这些数据施加的操作（即服务），封装在一起构成的独立单元。因此，为建立完整的对象模型，既要确定类中应该定义的属性，又要确定类中应该定义的服务。前面已经指出，需要等到建立了动态模型
36、和功能模型之后，才能最终确定类中应有的服务，因为这两个子模型更明确地描述了每个类中应该提供哪些服务。软 件 工 程1.常规行为 在分析阶段可以认为，类中定义的每个属性都是可以访问的2.从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的消息，因此该对象必须有由消息选择符指定的操作，这个操作修改对象状态（即属性值）并启动相应的服务3.与数据流目中处理框对应的操作 数据流图中的每个处理框都与一个对象（也可能是若干个对象）上的操作相对应4.利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服务数目。定义服务软 件 工 程5.5 基于场景建模 使用UML分析建模，将从开发用例、活动图和
37、泳道图形式的场景开始软 件 工 程5.5.1 编写用例 用例从某个特定参与者的角度用最简单易懂的语言说明一个特定的使用场景 但是，考虑下面问题：编写什么？写多少？编写说明应该多详细？如何组织说明？软 件 工 程5.5.1 编写用例（续）编写什么？来自起始和导出阶段提供了开始编写用例所需的信息 如何写？P117用例描述 P119 用例描述软 件 工 程5.5.2 开发活动图 UML活动图通过提供特定场景内交互流的图形化表示来补充用例软 件 工 程软 件 工 程5.5.3 泳道图 活动图的一种有用的变形。可让建模人员标识用例所描述的活动流，同时指示哪个参与者（如果在某个特定功能中涉及了多个参与者）
38、或分析类对活动举行所描述的活动负责。软 件 工 程软 件 工 程5.6 面向流的建模 面向流的建模：数据流 控制流软 件 工 程5.6.1 数据流模型 一个简单有效的方法：语法分析：需求叙述中所有名词（和名词短语）与动词（和动词短语）分离开来 动词最终会表示为后来的处理 名词是外部实体、数据或控制对象（箭头）、数据存储。软 件 工 程5.6.1 数据流模型（续）软 件 工 程软 件 工 程软 件 工 程软 件 工 程数据流图举例商商店店业业务务处处理理系系统统软 件 工 程第一层数据流图软 件 工 程销售细化软 件 工 程采购细化软 件 工 程基本加工逻辑说明 对数据流图的每一个基本加工，必须
39、有一个基本加工逻辑说明 基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节 加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的软 件 工 程用于写加工逻辑说明的工具 结构化英语结构化英语 判定表判定表 判定树判定树软 件 工 程1.结构化英语(PDL)结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、CASE_OF、WHILE_DO、REPEAT_UNTIL等组成。软 件 工 程结构化英语其基本控制结构有三种：简单陈述句结构：避免复合语句 重复
40、结构：while_do 或repeat_until 结构 判定结构：if_then_else 或case_of 结构软 件 工 程商店业务处理系统中“检查发货单”if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else（欠款未超期）发批准书，发货单 else（发货单金额未超过$500）if 欠款超过60天 then 发批准书，发货单及赊欠报告 else（欠款未超期）发批准书，发货单 软 件 工 程2.判定表 如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适。还是以“检查发货单”为例。软 件 工 程判定表软 件 工 程3.判
41、定树 判定树也是用来表达加工逻辑的一种工具。有时侯它比判定表更直观。检查发货单金额$500金额$500 欠款60天不发出批准书 欠款60天发货单发出批准书、欠款60天发出批准书、欠款60天发出批准书、发货单软 件 工 程5.6.2 创建控制流模型 有一大堆应用问题是事件驱动的而不是数据驱动；这类问题产生控制信息而不是报告或者显示信息软 件 工 程软 件 工 程5.6.3 控制规格说明 状态图表示系统的行为软 件 工 程5.7 基于类的建模 属于面向对象分析。结合safehome实例读课本相关内容 注意CRC（Class-Responsibility-Collaborator，类-职责-协作者）
42、建模方法软 件 工 程举例 需求规格说明书模板 需求规格说明书样例1 需求规格说明书样例2 需求规格说明书样例3 需求规格说明书样例4 需求规格说明书样例5 需求规格说明书样例6软 件 工 程软件需求规格说明书要求 依据模板添加相应内容，建模结果至少要包括：功能性需求 用例图+用例文档 业务模型 静态模型类图 动态模型 活动图（至少二个）、数据流图（至少两层）、状态图（至少一个）、事件序列图（至少一个）软 件 工 程作业 某厂对部分职工重新分配工作的政策是：年龄有20岁以下者，初中文化程度脱产学习，高中文化程度当电工；年龄有20岁至40岁之间者，中学文化程度男性当钳工，女性当车工，大学文化程度者当技术员；年龄有40岁以上者，中学文化程度当材料员，大学文化程度当技术员。请用结构化英语、判定表和判定树分别描述上述问题的加工逻辑。
