一步一步做项目（13）managePublicNotice用例的分析模型

有了软件需求（请参考一步一步做项目（1）软件需求），就需要对项目进行分析，从开发者的角度来理解问题领域，建立其分析模型。

BCE模式

下面，就来看看BCE模式的分析方法。
统一过程是用例驱动的。在分析工作流中，用类来描述用例。统一过程包含三种类型的类：实体类、边界类和控制类。
**实体类(entity class)**用来对持久信息进行建模。就银行软件产品来说，类Account是实体类，因为账户信息必须保留在软件产品中。
**边界类(boundary class)**用来对软件产品和参与者之间的交互进行建模。通常边界类与输入和输出相关联，例如，在银行软件产品中，需要打印用户账单。
**控制类(control class)**用来对复杂的计算和算法进行建模。在银行软件产品中，计算利息的算法就是一个控制类。
三种类的UML符号如图所示，这些符号是构造型(stereotype)，属于UML的扩展。

分析类总能符合三种基本构造型中的一种，这样就可以得到一种有效、一致的方法来确定和描述分析类，有助于创建健壮的对象模型和构架。

managePublicNotice示例

要分析managePublicNotice用例的类，就可以找到实体类PublicNotice，要对PublicNotice类进行处理，就需要用户界面，就可以提取出边界类PublicNoticeUI，要控制PublicNotice处理的流程，就可以提取出控制类PublicNoticeController，为了处理对实体类PublicNotice的操作，可以提供一个统一的接口来对实体类进行存取处理，例如PublicNoticeLocator类，这样，对于managePublicNotice用例的相关的类就分析出来了。至于对于的操作，无外乎是对PublicNotice信息的增删改查，可以将相应的方法，添加到对应的边界类、控制类和定位器类上。
由于，我们将使用SSH技术来实现该系统，因此，对应的类，我们就可以使用SSH的规范来命名，这样，模型也就可以自然演化。
这里，将边界类命名为-Action，控制类命名我-Service，定位器类命名为-Dao，这样，后面在创建设计模式时就不需要为了和技术相匹配而重新命名了。
这样，managePublicNotice用例中的实体类是PublicNotice，边界类是PublicNoticeAction，控制类是PublicNoticeService，定位器类是PublicNoticeDao，其关系如图所示：

有了，类及类之间的关系，就需要使用这些类来实现用例，完成用例的功能，下面就来看看其顺序图来表现其用例实现（分析）。如图所示：

注意： UML图中组合片段
选项（opt）　　包含一个可能发生或不发生的序列。
抉择（alt）　　抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if…else…。抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。else 的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else，则不执行任何片段。
引用（ref)　　引用另外一个序列图。
要对PublicNotice数据进行相应的增删改查操作，在managePublicNotice用例中引入了创建、修改、查询和删除等用例，下面就看看createPublicNotice顺序图，如下所示：

类似的，retrievePublicNotice顺序图，如下所示：

类似的，updatePublicNotice顺序图，如下所示：

类似的，deletePublicNotice顺序图，如下所示：

至此，就完成了managePublicNotice用例的顺序图的创建。