第3章 需求分析d课件.ppt

3.8 典型应用分析;3.8.1　结构化分析示例;对于本案例，其运作难以把握，并且也不是一个开展分析的可靠的基础。所以，依我们的选择，或者对问题域建模（就像在“传统的”SA中），或者是对解系统建模（像在现代SA中）。首先尝试使用前者。对于本案例，其运作难以把握，并且也不是一个开展分析的可靠的基础。所以，依我们的选择，或者对问题域建模（就像在“传统的”SA中），或者是对解系统建模（像在现代SA中）。首先尝试使用前者。;标识出问题域中那些我们所感兴趣的不同的问题子域，即：用户调用按钮发送按钮指示器电机传感器电梯门控器;而我们的指定任务就是将这些问题子域合并成一个DFD，要做到这一点，首先必须将它们归类为端子、处理、数据存储以及数据流。由于它们中没有哪个问题子域是数据存储或数据流，因此，或许可以按图3-54所示的方法，用某种通过数据流互连的方框来表示它们。 ;即使是允许对其做“艺术的创意”（电机与电梯间的连接肯定是机械式的并且也几乎不会作为数据流的一部分），图的各部分却是不连通的，况且很明显地缺少了处理部分。 要应对上述难题，我们可以采用现代SA中的策略，引入解系统并生成一个如图3-55所示的上下文DFD。 ;已经标识出来的数据流能够而且也应该在DD中加以定义，而且如果一切顺利的话，前述的案例研究已经充分地说明了这一情况。现在我们该继续为解系统开发一个底层的DFD。某些处理（功能）就包含在外部数据流中，图3-56展示了这些处理如何被合并起来。;然而，在这中间仍有一处明显的不足，即我们没增加什么实质性的东西。如果我们希望继续描述解系统的行为，那么就必须引入一些假定的处理以作为容纳此类描述的“地方”。图 3-57展示了一个可能的“解决方案”。 ;几经周折，我们总算把需求中的一员合并到我们的模型中了！现代SA的另一项任务是数据分析并且导出如图3-58所示的ERD。 照例，这些实体可以根据它们的属性加以定义并且导出以下的DD的补充部分：建筑物 ::=楼层数，电梯数；楼层 ::=楼层标识；电梯 ::=电梯标识；方向 ::=“上”，“下”；;位置 ::=楼层标识；门控器 ::=电梯标识，门状态；门位置 ::=“已关闭”，“己开启”，“正开启”，“正关闭”；传感器 ::=电梯标识，楼层标识，传感器类型；传感器类型 ::=“上方”，“下方”，“所在”；调用按钮 ::=楼层标识，方向；发送按钮 ::=电梯标识，楼层标识；指示器 ::=电梯标识，楼层标识；;图3-58;3.8.2　面向对象分析示例;表3-9 ;随着分析的不断深入，自然会涉及更多的关于问题域类的内容，而对于一个控制系统，首要的问题则是它们的行为。面向对象分析提供了状态图作为行为建模的工具，图3-59所示的是一个电梯电机的例子。; 虽然该图用简练的方式把握住了电机的重要特征，但还有更多需要讨论的（例如关于加速与减速），也明确要求附随的解释说明（对于这点面向对象分析提供很少指导）。 描述完类的内在行为之后，不妨把注意焦点转向它们间的相互关系上。图3-61展示了该如何描述这些关联 ;然而，我们总是期望可以从面向对象获取更多，并且我们当然就能够表示出协作（也称作“使用”或服务）连接。为避免太多的混乱，我将在一个单独的协作图中展示它，见图3-62 ;3.8.3　面向问题域的分析示例;一旦将系统确定为一个控制问题，我们即可致力于研究相关的指导原则（见表3-10），以明确问题域的哪些方面是相关的，以及哪些建模技术（如果有的话）可能有利于问题的处理。以该表为指南，继续进行深入的需求获取工作。 ;控制问题――需求文档;在使用结构化方法所得到的模型中，数据模型是非常“普通”的一个，并且使用ERD即可很方便地予以记录。除了受控域的元素，它还包括实体，如建筑物、楼层以及电梯升降机井等。虽然这些实体从任何意义上说都无法予以控制，但系统却需要“了解”有关这些实体的一些情况（如，有多少个电梯升降机井）。;接下来就是集中精力关注问题子域的描述了。在本案例中，最棘手的问题域或许就是明确哪些信息应该记录，而对此问题的最佳答案就是，考虑清楚系统开发者需要了解些什么信息。电梯卷扬电机被认为是最复杂的子域之一，对它的描述如下：卷扬电机每台卷扬电机都有三条控制线：慢速、快速和极性――并根据决策表（表3-11）进行操作。在快速模式下，电机以1.2m/s(+/-10%)的速度移动电梯。在慢速模式下，电机以0.3m/s　(+/-10%)的速度移动电梯。电机机制本身确保了逐渐加速和减速，如表3-12。;表3-11 ;由此可见，使用决策表可以非常简洁地记录大多数必要的信息，当然对于每种情况选择适当的技术也是必不可少的。或许在开发对于问题子域的描述的同时，