前些天同事推荐一篇文章,说是不错,或许对我有用,我很感谢他,我读过后发现确实不错,在读的过程中,我随手写下了读书笔记,有一些天了,如果我再不整理,我想我会慢慢忘记,今天就抽时间写了出来,由于自己在工作之余在作一个小软件,所以在读文章的过程中很有体会,下面就简单地把体会写出来,希望对读者能有帮助。
需求分析
一般来讲,系统开始于需求分析,这个阶段的主要任务是系统的整个框架和功能等进行分析,体现在UML设计方面的就是设计用例模型,用例模型就是定义系统是什么,是用来获取需求分析的有效手段。我们在构建一个用例时,首先要做的就是识别角色,或者说参与者,然后识别系统为参与者提供的服务,或者说是参与者的行为,也就是用例,最后我们确定它们之间的关系。这里确定一个有效用例的关键是检查一个用例是否包含一个完整的功能,用例不能定的过细,不要把一个功能的一部分作为一个用例,也不能把多个功能作为一个用例。自己在实践的过程中没有体会到什么是真正的用例,也就是没有明确的定义用例,当然,这个过程需要经验。
分析模型
上面的用例模型的分析是站在最终用户的角度来看得,分析模型就是站在开发者的角度来看待问题,用例模型主要是描述现实世界的业务流程,分析则是从系统的角度看软件提供什么服务。当然这个阶段还停留在“做什么“的阶段,设计阶段则是说明“怎样做”。这个阶段不要考虑设计语言,这样可以最大提供复用,第一步是静态模型的建立,通常是识别对象,然后提取出类,就著名的MVC模式来说吧,我们需要识别实体,控制和边界山中对象,然后通常表现为类图,这里的类只是我们业务逻辑上的,不是绝对的,到深一步分析时,这个类可能要分解。或者和其他类合并。这个过程当中我们需要简单地设计出类的一些基本属性和方法,这里注意不要过早地陷入类的属性,方法设计的细节,随着慢慢地分析和开发,就会添加和修改他们,这里我很有体会,我这里就范了这个错误。
动态模型的建立
到了这个阶段,我们已经对系统有了一定的了解,我们需要通过顺序图,活动图或者状态图来建模,来分析模型的活动过程,就是分析系统具体执行过程,这个阶段我就不详细分析了,具体的一些图的建立和分析,请找相关资料。
系统设计------实现方案
设计是对系统的详细描述,这里需要提供详细的解决方案,这个过程,同样需要使用动态模型建立过程中使用的各种图来描述。
第一步,需要选择技术方案,这里我们要考虑什么样的客户端,什么样的语言,什么框架和通信技术等等。
第二步,设计包或者子系统,意思是说把系统划分成小的模块,比如服务器端,客户端,然而,每一层又可以分成好几块,这样分成各个部分,有利于团队开发,我同样有体会,本人正在开发一个几十个人参加不小的项目。呵呵,
最后就是实现模型,编码,这里我才真正认识到编码不是首先考虑的问题,以前只是听说,没有体会。
好了,结束了,有些地方我没有深入写,具体应用时还要读者找相关资料,这里只是我的读书笔记。
-------刘皓晨
posted on 2006-01-06 11:23
hclown 阅读(121)
评论(0) 编辑 收藏