系统建模

        当接手了一个项目,第一部是进行可行性分析,第二步是进行需求分析(可参考本人另一篇博客),完成需求分析后,可以画出系统业务功能需求框图.接着便可以进行用例建模了.

        用例建模是客户需求分析的重要组成部分,它从最终用户的角度来理解软件系统的需求,强调谁在使用系统,系统可以完成哪些功能.

        用例建模一般有以下几个步骤:

             (1) 业务需求分析.这在个过程中分析系统的业务需求,有时业务需求会很庞大,这个时候需要将一些子系统合并.

             (2) 确定系统边界.这是在业务需求分析结束后,整理规划出整个系统的分割,以及确定每部分的范围.

             (3) 确定执行者.通过对业务需求的分析可以得到在系统外的执行者.一般分为若干执行者以及若干系统执行者.执行者主要是操作用例.

             (4) 确定用例.划分了系统边界,那就可以得出系统边界内有多少个用例,系统边界外有多少个执行者.并对用例之间的关系加以适当的描述.

             (5) 绘制用例图.用图的形式表现出用例与用例之间的关系,让人更容易理解.

             (6) 描述用例.对每个用例进行描述,一般包括用例名,执行者,目的,过程描述,异常事件处理流.这部分要尽可能的详细地对用例进行描述.因为这是后面对象类建模的信息来源.

             (7) 对每个子系统进行从(1)开始的过程,直到把系统描述完毕.

       

       对象类建模的主要工作就是从客户需求和系统分析阶段抽象出对象类,类有三种主要的版型:实体类,边界类,控制类.

        实体类可以创建持久对象,持久对象可以存放进持久存储体.对于关系数据库而言,通常每个实体类映射数据库中相应的一个二维表,实体类中的属性对应该表中的字段,而每个对象就是该表中的一条记录.

         边界类位于系统与外界的交界处,包括所有窗体,报表,以及表示通信协议的类,直接与外部设备交互的类,直接与外部系统交互的类等都是边界类.通过用例图可以确定需要的边界类,每个执行者/用例对至少要有一个边界类,但并非每个执行者/用例对要有唯一的边界类.

         控制类是控制其他类工作的类.每个用例通常有一个控制类,用来控制用例中事件发生的顺序,控制类也可以在多个用例间共用.其他类一般不向控制类发送消息,而是由控制类向其他类发出消息.

       以下主要以CRC技术进行说明对象类建模的流程.

       类--责任--协作者(Class-Responsibility-Collaborator,CRC)技术是一种简单有效的面向对象的分析技术,它实际上是一组描述类的索引卡片,每张卡片分成3部分:类名描述,类的责 任描述和类的协作者描述其是开发一个有组织的类的表示法.CRC卡片的格式如下:

----------------------------------------------------------------

|   类名:                                                                       |

----------------------------------------------------------------

|   类的类型:(如:设备,角色,场所等)                         |

----------------------------------------------------------------

|   类的特征:(如:有形的,原子的,并发的等)              |

----------------------------------------------------------------

|   责任:                          |   协作者:                            |

----------------------------------------------------------------

           CRC卡片的格式

        对象类建模(采用CRC技术)一般有以下几个步骤:

             (1) 确定类对象.

                       (a) 发现潜在对象

                       一组具有相同属性和操作的对象可以定义成一个类,因此标识类和标识对象是一致的.通常陈述中的名词或者是名词短语是可能的对象.例如:

                        * 与系统交互的角色.如管理者,管理员.

                        * 系统的工作环境场所.如车间,办公室.

                        * 概念实体,发生的事件或者事件.如报告,显示,信函.

                        * 部门.如学校.

                        * 设备.如汽车,计算机.

                        * 与系统有关的外部实体.如其他系统,设备,人员等,他们生产或消费计算机使用的信息.

                      (b) 标识对象名的原则

                        * 使用单个名词或名词短语.

                        * 对象名称必须简洁是明了.

                        *尽量使用用户熟悉的行业标准术语.

                     (c) 筛选对象

                        * 可以根据关键性,可操作性,信息含量,公共属性,公共操作和关键外部信息等来选择和确定最终的对象.

                     (d)对象分类

                        * 对象还可以根据有形性,包含性,顺序性,持久性,完整性等特征来进行分类.

             (2) 标识对象类的属性,属性描述对象类的静态特征.

                      (a) 可以从以下角度来发现和确定对象潜在的属性

                        * 常识性: 按一般常识,该对象应具有的属性

                        * 专业性: 在当前问题论域中,该对象应具有的属性.

                        * 功能性: 根据系统功能的要求,该对象应有的属性.

                        * 管理性: 建立该对象是为了保存和管理哪些属性.

                        * 操作性: 为了实现对象的操作功能,需要增设哪些属性.

                        * 标志性: 是否需要增设属性来区别对象的不同状态.

                        * 外联性: 用属性来表示对象的整体-部分联系和实例连接.

                      (b) 在确定了对象的属性后,应对各属性命名以示区别.还 应该对每个属性加以详细说明,包括以下信息:

                        * 属性的解释.

                        * 属性的数据类型.

                        * 属性的取值范围以及对象所体现的关系.

                        * 属性的实现要求和其他.

             (3) 标识对象类的操作.对象的操作可以理解为对象应该展现的外部服务的总和.操作定义了对象的行为并以某种方式修改对象的属性值或系统的状态.通常描述中的动词可以作为候选的操作.类所选择的每个操作都展示了某种行为.

                      (a) 命名操作的标识名

                        * 一般按约定命名.

                      (b) 对每个操作应加以详细说明,包括以下信息:

                        * 操作解释: 作用与功能.

                        * 消息协议: 入口消息格式.

                        * 消息发送: 执行期间,需要请求哪些其它对象的操作.

                        * 约束条件: 执行的前置,后置条件及执行事件等说明事项.

                        * 操作流程: 对复杂的操作应画出操作过程流程图.