CAB与OOAD(上)续一

 1.1           需求

我们要求所记录的需求是准确的、清晰的、合理的。在此基础上,系统的需求制品主要包括:

GUI快速原型可以在白板或者草纸上进行绘制,如果是白板的话在大致定稿的情况下需要数码照片的留存,以便参考。也可以在Visio或者UIStudio上进行绘制。但是请注意这里的GUI快速原型并不构成最终制品的一部分,它只作为获取需求以及验证需求的手段。

关于用例,我们需要注明组成系统的主要用例简图。其中每一个用例都需要文本描述,这种描述可以是概述,也可以是基于Cockburn的用例格式。但是请注意,每一段用例文本一定要包含的三要素是:参与者对系统的操作、系统的操作、系统对参与者的返回信息。

 

术语表需要记录系统中存在的领域模型。它的主要目的是帮助涉众对所在的领域达成共识。术语表整理可以参照分类列表结合名词识别的方法完成。

补充规约主要用来记录系统中存在的非功能性需求。也可以在用例文本的尾部注明所属的补充规约文本。

对于需求我们需要注意,不要在一开始就想着完整的定义所有的需求。需求是变更的,因此我们需要在一开始尽可能的宽泛(宽泛的意思并非大概、也许,它是严谨的)的记录下我们当时可以发现的需求,寻找出它们中对于系统中最重要的部分,划分出需求的优先级来。根据优先级制作第一个迭代的产品,然后不断的反馈和改进,事实上这是避免浪费的最好方法。

1.2           分析

在分析这个部分我们的主要目的是将需求转化为分析类的方式:边界类、控制类和实体类。

边界类的主要来源是需求制品中的GUI快速原型。

实体类的主要来源则出自需求制品中的术语表。

控制类主要用来连接边界类和实体类,帮助它们进行沟通。

借助健壮性分析图,我们可以获取这些内容:

主动边界类是主动参与者与系统沟通交互的部分,多指系统的界面部分。

被动边界类则是系统与被动参与者沟通交互的部分,多指与第三方系统的接口。

实体类是往往是系统中用来记录系统状态信息的部分。

控制类要承载的主要工作有两个小部分,一个是处理与边界类沟通的部分,另一个是与实体类沟通的部分。

1.3           简单设计

我们需要将分析类依据MVC或者是MVP模式的方式分配到系统的架构体系中。

 


多数情况下,主动边界类直接对应着
View。而Model的部分主要由两个部分组成,一个部分是由实体类组成的领域模型包,另一部分则是将控制类切分,将与实体类相关的操作提取出来放置在Model模块中。剩下的另一个部分控制类则形成了Controller的部分。

1.4           初识架构

系统由客户端和服务器端两端组成。而两端都被设计成为了容器的方式,它们之间通过Web Service进行通信。在没有任何模块的情况,骨架可以独立运行。在需要构建新的模块时,只需要将模块的DLL放置在系统的指定目录下,同时在配置文件中指明DLL信息,骨架会自动识别该模块。

posted on 2006-11-29 21:28  姜志辉  阅读(2148)  评论(4编辑  收藏  举报

导航