在开发过程中如何运用UML 整理

若转载请注明出处,谢谢,链接地址:http://write.blog.csdn.net/postedit/8542968

下面是我根据项目开发过程中,项目进行的一种GRAPPLE思想总结。请注意系统分析员是怎么将项目拆分成若干模块的

(我下面也会将所有参与到的角色特别标注出来。)

1、系统分析员分析项目需求,将项目拆分成若干模块,并对每个模块书写模块说明书。

2、程序员按照模块说明书的描述,书写具体代码。

3、最后将全部模块组装起来进行联调。


此处分界线下,避免文章内容混乱

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

Q:通常客户最关心的是什么?
A:通常客户最关心的有:
开发组理解了所要解决的问题吗?
开发组的成员理解了客户对如何解决问题的看法了吗?
能从开发组那里得到什么工作产品?
项目经理如何向客户做报告?
开发组的工作进度到了哪里?


开发过程中,应用GRAPPLE(Guidelines for Rapid Application Engineering)快速应用工程指导原则的思想,它是一组灵活的指导原则而不是写在刻在石头上一成不变的开发过程方法学,例如你可以改编GRAPPLE思想(如通过减少类和类模型)来适应你的系统。
GRAPPLE开发过程方法学由5个段组成。这里说“段”而不是“阶段”,为的是说明不是通常意义上的那种一个阶段完成后,下一个阶段才能开始。跟传统的开发过程方法学“瀑布”过程不一样。
每个段又由许多动作组成,每个动作能够产生一个工作成果,并且每个动作都是一个特定的执行者的职责。UML图就是许多这些动作的工作成果。


在许多情况下,项目经理都可以根据工作产品生产一个要提交给客户的报告。工作成果实际上就是项目开发过程中的各种纸质文件。


GRAPPLE主要使用于面向对象系统。因此,每个段中的动作主要是生成面向对象的工作产品。
GRAPPLE中有下列5个段:
1.需求收集;
2.分析;
3.设计;
4.开发;
5.部署;


这个5个段组成的过程,简称为RADDD或RAD3。在第3段以后,项目经理将所有工作产品转化为一个设计文档,将该设计文档交给客户和开发人员。当所有的RAD3段完成后,要结合所有的工作产品来生成系统的定义文档。
在所有这些段开始之前,客户必须已经为该系统制作了一个业务案例。还要求开发组的成员特别是系统分析员尽可能多的阅读相关文档资料。


1.需求收集
1.1发现业务过程
工作:
系统分析员客户或者客户指定的具有业务知识的人面谈,与他们一起一步一步地讨论相关过程。
工作成果:
系统分析员获得一套客户业务领域的词汇。一个或者一组能够捕获业务过程中的步骤和版定点的活动图。
1.2 领域分析
工作:
系统分析员与客户会谈的主要目标是理解客户领域中的主要实体。【旁边最好有组人做记录(用笔记本最好),对象建模新手听取名词和动词。对会谈过程也可以录音,方便检查模型的完整性】
工作成果:
一个高层的类图和会谈记录。
1.3 识别协作系统
工作:
开发组要找出新建的系统要依赖哪些老系统,哪些老系统要依赖新建的系统。
工作成果:
方便系统工程师为新建的系统建立部署图
1.4 发现系统需求
工作:
开发组开一次联合应用开发会议(简称JAD session),参加者是来自客户所在组织的决策者、可能的用户,以及开发组的成员。会议时间长短,看系统的复杂性。
工作成果:
得到一个包图。每个包代表一个系统功能的高层领域(如,“协助顾客”),每个包中包括了一组用例(如,“获取顾客历史信息”和“与顾客交互”)。




2.分析
2.1理解系统的用法
工作:
开发组用户一起开会进行一个高层用例分析。如找出发起每个用例的参与者以及从这些用例中获益的参与者(可能是系统,也可能是人)。
开发小组还要尝试开发出新用例。
工作成果:
产生一组用例图。
2.2充实用例
工作:
开发组继续喝用户一起开会,分析出每个用例中的步骤序列。
工作成果:
对每个用例步骤的文本描述。
2.3 细化类图
工作:
在之前的开会期间,对象建模者听取所有讨论并继续细化类图。(如应在类图中加入关联名、抽象类、多重性、泛化和聚集)
工作成果:
一个细化了类图。
2.4分析对象状态变化
工作:
对象建模者进一步细化模型,要展示出对象状态的变化。
工作成果:
一个状态图。
2.5定义对象之间的交互
工作:
开发组有了上面的一组用例图和细化了类图后,就该定义对象之间交互了。由对象建模者开发一组 顺序图和协作图来描绘对象之间的交互。状态变化应当被包括在内。
工作成果:
产生顺序图和协作图。
2.6分析与协作系统的集成
工作:
系统工程师要找出与协作系统集成的具体细节。如何种类型的通信,何种网络体系结构?如果系统要访问数据库,那么一个数据库分析员要决定这些数据库(物理的和逻辑的)的体系结构。
工作成果:
详细的系统部署图和(如果有必要的话)数据模型。




3.设计
3.1 开发和细化对象图
工作:
程序员根据类图产生一些必要的对象图。他们检查每个操作并开发对应操作的活动图去充实对象图。【活动图将是开发段中编码的基础】
工作成果:
细化的对象图和活动图
3.2开发构件图
工作:
程序员去可视化的描绘出构件和构件之间的关系。
工作成果:
构件图。
3.3制定部署计划
工作:
当构件图完成后,系统工程师就开始编制系统的部署以及系统与其他协作系统集成的计划。
工作成果:
系统的部署图。
3.4 设计和开发用户界面原型
GUI分析员与用户一起开会,开发纸面上的用户界面原构件原型(按钮,检查框、下拉列表、菜单等等),注意,用户界面应当考虑到所有用例的完成。
当用户对界面构件满意后,开发人员就开发显示器上的用户界面原型,拿给用户让他们认可。
工作成果:
屏幕界面原型的快照。
3.5 测试设计
工作:
评价所开发出的软件是否能够做所期望的事,也就是说,它能够实现用例所描述的事情。(用例是进行测试设计的依据。)
工作结果:
测试专家为自动测试工具开发出测试脚本。
3.6 开始编制文档
工作:
编制文档的专业人员开发人员一起共同编制文档,制定出每个文档的结构。【建议:系统最终用户和系统管理员使用的文档不要太早就开始编制】
工作成果:
文档的结构。





4.开发
4.1 编制代码
工作:
根据掌握的类图、对象图、活动图和构件图,程序员编制实现系统的代码。
工作成果:
编制出的代码。
4.2 测试代码
工作:
测试专家(即QA,不是开发人员)运行测试脚本,评价代码是否做了预期的工作。【测试产生的信息要反馈到开发人员,直到】
工作成果:
测试的结果。
4.3 构建用户界面和用户界面到代码的连接及测试
工作:
GUI专家构建用户界面并将界面连接到代码。要进一步的测试,确保用户界面工作正确。
工作成果:
带有用户界面的功能更系统。
4.4 完成文档
工作:
在开发段中,文档专家与程序员并行工作,确保文档及时完成和交付。
工作成果:
完成文档。






5. 部署
当开发完成后,系统就要被部署到适当的硬件上运行并要与协同系统集成起来。尽管如此,5.1这个工作在开发段开始以前就可以开始了。
5.1 编制备份和恢复计划
工作:
由系统工程师编制计划,以防系统崩溃。
工作成果:
有备份和恢复计划。计划中要详细说明如何备份系统以及系统崩溃后如何恢复。
5.2 在硬件上安装最终系统
工作:
系统工程师在必要的开发人员协助下,将最终开发好的系统部署到合适的计算机上运行。
工作成果:
完全部署好的计算机系统。
5.3 测试安装后的系统
工作:
开发组要对安装好的系统测试。如它是否能执行预期的事?备份和恢复机制起作用了吗?测试的结果将决定系统是否需要进一步精华。
工作成果:
测试的结果。
5.4 庆祝
开发组庆祝一个新系统的诞生,热烈祝贺。


备注:
GRAPPLE只是一个简单的开发过程骨架。我们并没有涉及一些重要问题的细节,例如测试的层次;中间工作成果存放在哪里,如何存放?如何处理在任何时候都非常
重要的配置管理问题等。
一个简单的回答:将工作成果(已经完成的后者正在进行的)可以被存储在位于组织局域网中的一个数据仓库中。建议方案是安装一个集中控制的数据仓库软件包来控制各个用户对于每个工作产品的读出和写入。【这也是配置管理问题的基本解决方案

由上面可以看出,在实际开发中,编码只是系统开发过程的一小部分。分析的越充分,就越能接近目标。在前期的分析和设计上多花点时间,为的是能使编码平稳地进行。
开发过程方法学将一个系统开发项目的开发过程分为阶段和活动。

没有开发过程方法学的指导,开发过程就会产生混乱,开发者无法理解到底他要解决的是什么问题。像早期的开发过程方法学采用”瀑布“顺序,机械的分割了开发过程,还将主要的开发工作量分配给了编码,浪费了分析和设计阶段的宝贵时间。


传统的软件工程模型(瀑布模型),缺点是传统的模型通常会将过多的项目开发时间用于编码。

现代的软件工程模型,强调开发阶段的无缝集成。例如,系统分析员和设计人员,通常要往返进行分析和设计,为程序设计人员提供坚实的基础。程序设计人员反过来也要与分析人员和设计人员交互,共享重要的见解,修改设计,充实代码。


Q:“瀑布”方法还有适用的情况吗?

A:如果所要开发的系统是很小的系统,那么可以用“瀑布”过程。但对于现代面向对象系统开发来说,过程方法学仍然鼓励开发段之间的各个活动持续进行、相互作用,这样能产生较好的结果。

Q:非面向对象系统采取何种开发过程呢?

A:即使是非面向对象系统(例如许多基于大型主机的项目),GRAPPLE思想也还是适用的。

转载请注明出处:http://write.blog.csdn.net/postedit/8542968

你可能感兴趣的:(在开发过程中如何运用UML 整理)