qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

面向对象的软件分析设计过程备忘

面向对象的软件分析设计过程备忘

  一、业务分析与需求收集

  1、重点梳理主业务流程,逐步完善分支流程。整理和发现业务流程中的涉众以及他们的业务目标和系统目标,显式目标以及隐式目标;

  2、整理涉众们在系统中所承担的角色以及各自的职责;

  3、在流程的运转过程中,发现和查找业务实体、他们之间的关系以及关键实体的生命周期(由谁在什么场景下创建、中间状态的变化以致最后的消亡);

  4、在流程的运转过程中,有哪些业务规则以及各种隐式的规则;

  5、不断的提问和验证流程的正确性和完整性(即使是边界以外的流程也不要放过,最少要做到心中有数)。是否有遗漏的涉众?是否有遗漏的职责或者行为?是否有遗漏的实体?是否有遗漏或者未被发现的实体关系?实体的生命周期是否完整?收集的需求或者信息能否支撑整个流程的运转,需求与需求是否有相互矛盾之处?是否有履行同样职责的人或者物(需要合并或者抽象)?多退少补!

  6、划分业务边界与系统边界,哪些是需要由系统来完成的职责,哪些是由别的系统或者人工完成的职责。

  7、可借助UML的组件图或者时序图、活动图、状态图来完成High Level层面的流程整理和业务建模。

  二、概要设计(用例驱动功能需求,认真对待非功能性需求)

  1、整理系统用例以及他们的参与者与系统边界。系统用例与服务最为密切,通常会演变为最后的服务接口。可借助UML用例图来完成用例建模。

  用例的特征:

  用例具有相对独立性;用例的执行结果对于参与者来说是可观测的和有意义的;用例必须由一个参与者发起的;用例必然是以动宾短语的形式出现的;用例是一个需求单元、分析单元、设计单元、开发单元、测试单元甚至是一个部署单元。

  用例的粒度:

  在概念建模阶段:粒度以能描述一个完整的事件流为宜;

  在系统建模阶段:粒度以能描述操作者与计算机的一次完整交互为宜;

  用例不是功能,用例是参与者对系统的期望以及目标,功能则是达成这个目标的步骤而已。

  2、用活动图或者时序图描绘重点用例及其场景。

  设计目标:为了完成该用例,需要由哪些角色介入协作完成,他们各自的职责是什么?只关注做什么,当前阶段不需要关注怎么做(不同阶段不同视图所关注的问题是不一样的。不分阶段不分视图的天马行空式的混沌思维,不是科学的分析方法,只会把问题复杂化)。

  3、完成当前用例有哪些规则,以及需要建立哪些实体,之后需要明确实体与实体之间的关系(关联?聚合?一对一?一对多?)。

  4、只需要针对核心和关键的用例建模,循环迭代。

  5、划分高层职责、确立彼此之间的交互方式及其主要交互数据。


三、详细设计(在概要设计的基础上演进与精化,只需要针对核心和关键的用例建模)

  1、根据之前的用例设计,定义服务接口并确定接口参数与返回值。

  2、根据概要设计过程中的活动图和时序图,将完成相应职责的角色或者对象设计为相应职责的类或者接口,并将关键步骤定义为该类或接口的方法,并确定方法参数与返回值,可借助UML类图来完成接口、类的建模。

  3、分析模型的变化点,对于清晰明确的变化点,建立抽象模型以适应变化并设计已知实现。对于相对模糊不清的变化点,建立抽象模型,隔离变化,将问题集中到一个局部的点,可在之后变化点明朗化之后重构(只影响某个局部的点)。概要设计阶段我们思考“做什么?”,当前阶段我们需要思考“怎么做?”,或者是技术选型,或者是架构模式,需要做出决策。

  4、认真思考类或者接口中的每一个属性、方法以及方法参数。精炼、精炼、再精炼!

  取一个好名字;

  方法的设计应当具备原子性与职责单一性,方法参数列表也应当尽量精炼,越是简单的方法越容易被组合与重用。

  只暴露需要暴露的服务与接口方法,不多暴露一个不需要暴露的服务与接口方法。没暴露的方法可以随意重构与扩展,方法一旦暴露出去,就需要一直维护并保持其兼容性。

  5、不要考虑实体的储存形式,我们需要思考的是设计一个类,该类当中应该有哪些属性与方法,以及每个属性的适用场景与业务含义。

  任何形式的数据都应该能转换为OO设计中的类对象。可存储可配置的场景也应该可以通过API来实现,JAVA是程序语言,任何形式的数据表现形式,最后还是通过相应的类及其方法调用来完成相应的职责。

  6、只需要针对核心和关键的用例建模,循环迭代。

  7、划分高层职责、确立彼此之间的交互方式,建立高层接口以及通讯方式,确定通讯协议以及报文格式。

  注意:

  A、实体建模时,需要认真思考实体的每一个属性,明确其使用场景与业务含义。同一个人在不同的场景下可能扮演不同的角色,角色的不同决定了其属性也不同。Jack在家是父亲的角色,他同时也是一个教师,因此“课程”是教师的属性而不是父亲的属性,即使他们都属于Jack这个维度。请参考DCI的设计理论。

  B、实体建模时,即使需求方没有提出有关需求,但仍需要维护某些关系。实体与实体关系是在某个业务场景下客观存在的,如果因为需求方暂时没有提出相关需求,而放弃或者丢失客观存在的实体关系,一旦今后提出相关需求,可能会带来相当大的重构代价。

posted on 2012-06-15 11:03 顺其自然EVO 阅读(277) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2012年6月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜