面向对象的Java与UML课件系统分析

面向对象的Java与UML课件系统分析域模型顺序图实体对象、边界对象与控制对象用户接口定义协同图使用域对象、协同图、活动图和状态图进行用例细化分析系统行为的时候了，将需求说明细化为计算机专有的行为说明书系统分析的输入和输出：尽管系统分析人可能参考前面所提供的任何一种文档，但是用例描述和原型还是主要的输入。系统分析的核心将被顺序图的构建所驱动。而顺序图也转而来生成合作图和类图。顺序图所使用的剧本是根据用例描述中的主要/替代/异常路线所推导出来的域对象模型模拟的世界之间，需要有紧密的对应关系。利用现实世界中事物相应的对象来构建系统，它的优势在于可能会更容易理解系统。比如订货系统中有订单、顾客和货物要构建一个可维护的系统，额外的对象是必要的一些UML符号构造型《》三种不同类型的对象构造型实体对象：为持续存在的对象建模边界对象：控制与外界交互的控制对象：将复杂行为组织起来，这些行为涉及了大量的实体对象和边界对象数据要存储在数据库中，数据库设计人员将这一阶段成为实体建模把活动者提供的信息翻译成控制对象和实体对象相应的事件用于在许多对象之间调解，持续时间不比用例长，一般情况下不用数据库表示这些对象顺序图用例图为分析提供了系统功能极为清晰的定义。现在，需要把这些功能翻译成计算机系统中的对象组与可能实现的交互。在分析中，顺序图是这样一种方法。它研究需求分析阶段中搜集到的用例，将用例定义中的顺序和在用例中相互作用的对象串在一起。我们要做的是使用顺序图，要么连接到已知对象上，要么创造对象来支持这个用例。使用用例剧本表示贯穿这个系统的旅程。要遵循的过程要遵循的过程是从用例中识别一系列代表性的剧本，并用顺序图将其细化。剧本集应包括用例中所有的替代路线和异常路线这些顺序图可以用来确定协同图，随后，协同图也转而用于生成类图电话订货用例为例电话订货用例为例以电话订货用例为例1售货员得到顾客号，并将其输入显示屏。2查询顾客的详细信息．并显示在屏幕上。3售货员核实顾客详细信息与顾客给出的信息一致，并勾选确认框。4售货员输人订单的详细信息。5售货员输人发货详细信息。6售货员请求生成订单。以订货用例为例以订货用例为例用例行为序列与对象之间的链接，找到域对象的最好方法顺序图的指导方针1为该用例标识有代表性的剧本集，包括所有的替代路线和异常路线2为每个剧本生成如下的顺序图3把活动者放在左边4标识边界对象（可能多于一个），如显示屏。5为剧本的每个步骤画出活动者与边界对象之间的交互。6对于与边界对象的每次交互，确定是否要和另一个对象交互7如果交互是与一个单独的实体对象进行的，则创建实体对象并直接为其请求服务8如果交互是与许多实体对象进行的，则考虑创建中间控制对象来监控通信顺序图绘制草图顺序图是进行用例细化

最有效的方式之一让做出用例定义的业务分析人员和熟悉对象建模的人，甚至可能是设计人员来接触业务。使用粘在一起的的笔记，而不是计算机化的工具来生成顺序图。结果看起来有点像上页图。活动顺序写在左边，候选对象写在上边，用叉号表示交互。这种方式很不正规，但允许极快速地重新整理。计算机化工具的问题在于，它们有时候看上去过于正规了。一旦顺序图得到认可，就可以整洁地画出来。协同图协同图是另一种使对象相互关联的方式，是顺序图的补充，面向对象的系统通过对象协作来提供其行为，单独的对象只能提供部分行为。当对象协作时，它们能提供复杂而功能强大的行为。为此，对象交换信息与请求，这些请求的路线就可以用协同图来描述。事实上，这些路线已经在顺序图中定义过了，但是，用另一种不同的方式把它们描述出来也是有用的。这样做的好处在于通信线路看上去更清楚直观。协同图可以翻译成类图，我们随后可以看到。以订货用例为例类图与协同图的关系协同图表现了系统的一次特定执行中类的关，类图表示的所有潜在执行中类的关系协同图可以记录对象间交换的信息，但类图不能类图记录了在对象及其属性上进行的操作，但协同图不能合作图与类图的关系综合了大量表示各种各样用例执行的协同图后，便形成了具有已定义关系的类图结构。考虑协同图中对象间的通信，就能开始标识支持关系的对象所需要的操作；研究通信中交换的信息，会发现对象需要记录的属性；设计会带我们沿着这条路走下去，并检查类的结构。本阶段构造类图的主要目的可以在这里开始为对象指定操作但是，我们有很多理由不建议这样做。在顺序图中捕获了交互细节，对于这是否足够使得设计人员理解系统，仍然存在争议其次，设计人员有可能要对类图进行重构，并对顺序图进行相应的细化。构架上的考虑将会给类的结构带来相当大的影响。例如，将要决定一些操作是应当在控制类中，还是在实休类中实现。这些决定最好留给负责设计和实现的开发人员在这一阶段中，要从类图中捕获的首要信息是需要以属性的形式保存下来的数据。用户接口使潜在用户参与并阐明问题的最有效方法之一是提供原型界面。下图是我们详细讨论的订单输入屏幕的一个原型屏幕。开始构造这种原型时，许多事情显露了出来。需要收集的数据成为了用户接口的一个讨论点：我们可能用它来返回到顾客对象，并把地址属性细化到该对象的组件中。我们也看到有某一产品的概念，这一概念会提醒我们考虑是否在什么地方需要一个产品对象。顾客知道产品代码，如果不知道，能否期望系统为订单输入提供产品号码列表？顾客希望获得订单价格的反馈吗？接口的组织用户接口图也同样是有用的：显示屏是边界对象，所以，类图可以用来表现屏幕组织。下图展示了一个简单的屏幕组织。没有显示属性和操作，类中显示属性和操作的框也省略了，关联显示为单向的，用来表示屏幕之间的导航路线。从一个屏墓指向另一个屏幕的箭头表示前者可以调用后者。状态图状态图需要引入两点：状态间的转换可以使用更多的语法Event-name(parameters)[guard-condition]/actionEvent-name触发从前一状态退出的事件名称guard-condition激发转换必须为真的条件Parameters提供给事件的用逗号分隔的值序列Action当激发转换时必须发生的一些特定活动带事件、保安条件和活动的顾客帐户状态图可以存在嵌套状态存货可能高于或者低于建议的库存水平子状态开始时，通常始于一个起始点由于活动图是状态图的变体，上述符号都适用于两者“棕地”分析上文描述了“绿地”开发中的系统分析，也就意味着系统是新的，并且，在实现方面很少有约束。实际上这很少见，即使是所谓的绿地开发，最初的开发发生了，就可以认为是“棕地”了。通常，系统需要有数据库，数据库模式实际上是削减了的对象模型：数据表主要存储现实世界实体的信息，实际上是实体类的实现。因此，系统分析的进行可以通过使用顺序图来把现有的数据库表联系在一起，用新的边界对象和控制对象来实现一个用例。ICANDO化学制品订货“验证用户”实例实现验证用户用例的实现需要更细致地理解用例。在有关对象的一章中，我们将标识名词作为一种确定对象的方法：现在，我们应当用一种更为结构化的方法来实现对象识别，走完贯穿用例的不同路线，并且构适出顺序图。应当使用实体、边界和控制对象的符号，来赋予对象模型某些结构。验证用户用例的实现主要路线的第一步顾客提供顾客号，职员将其输人屏幕，这给出了顺序图的起始点．如图所示。这表明有一个职员（一个活动者）使用欢迎窗口（Welcomesceen)一个边界对象）输入数据。主要路线的第一步在这里不大可能涉及到其他任何对象，直到职员提交（submit）为止。提交可能通过输入顾客号之后点击返回，或是通过按按钮来实现。无论是哪一种方式，我们都可以扩展顺序图来合并提交，从而得到如图所示的顺序图。主要路线的第二步系统响应，返回顾客姓名和地址，以及该顾客的唯一密码。这暗示着需要某个对象来存储姓名、地址和密码，明智的做法是将这些信息组合到一个叫做顾客的单独对象中由于顾客对象是需要持续存在的．并与现实世界的实体，即顾客是严格对应的，因此，它是一个实体对象。由此，我们能够画出图控制对象的引入这一顺序图是合适的。但是，当我们来到主要路线的第三个步骤时，出现了一个问题：就是如果给出的回答与屏幕上查询出的一致，职员就点击单选框。现在，在操作员进行这个用例处理的时候，经过验证的顾客的情况需要被记住。虽然顾客对象，可能会用来保存这一信息，但是，感觉上有点不对。屏幕也可能保存信息，但随着查询的进行，会生成新的屏幕并毁掉确认屏幕。回过头来着，确实有个在任何用例中都推荐考虑的构造，也就是该用例的控制对象。如果向控制对象发送所有请求，则控制对象，可以接受确认。可以根据呼叫持续时间来保持控制对象处于可用状态。最后，我们构造出如图所示的顺序图。主要路线的第三步主要路线的第三步我们现在有了非常细化的顺序图．也已经为系统的操作设计了合理的结构。并且有了一个新的对象类（验证控制对象，如上图所示），它需要存储至少一条信息作为属性，来确定顾客是否已被认证。可是，仍然有很多问题需要回答，比如顾客对象如何定位，但是，其中的很多问题都可以留给设计人员来解答。协同图替代路线3.1研究完主要路线后，我们需要研究替代路线。以第三条替代路线为例，当顾客无法提供密码／姓名和地址。系统必须记录这次尝试，这暗指某种呼叫日志。需要存储的是一个实体对象，这一对象由用例生成，如图所示。附加对象的设计附加对象的设计附加对象很可能需要存储客户号、时间、日期和一些记载发生了什么的记录。由于不管是否采取行动，呼叫中心通常都要记录每次呼叫。因此，该对象可能出现在众多场合。类图分析现在，我们有了类图的基础——协同图。尽管表示出控制与边界对象是合理的。但是，由于这些对象会倾向于拥有静态的行为。因此，通常大部分实体对象都用类图来表示。ICANDO零售汽油促销案例ICANDO零售汽油促销零

售

汽

油

促

销

用例ICANDO零售汽油促销“加入订单”用例的实现主要路线1．顾客点击目录页面，选择物品旁边的定购键2．系统确认该产品有库存3．系统从顾客账户中扣除点数4．系统弹出