使用UML进行系统分析设计

使用使用使用使用使用使用使用使用使用使用使用使用UMLUMLUMLUMLUMLUMLUMLUMLUMLUMLUMLUML进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计进行系统分析设计V1.0V1.0V1.0V1.0蔡晓东2009-022009-022009-022009-02中国通信服务福建邮科公司使用UML进行软件分析设计1111背景背景背景背景1.11.11.11.1项目研发团队假设项目研发团队假设项目研发团队假设项目研发团队假设本文所描述的系统分析设计方法，基于一定的项目团队进行。�项目的工作量不超过100人月。即大约8人工作1年时间完成。�项目组人数约8人，其中1名项目经理，1名架构师，1名需求人员、1名测试人员，其它为开发人员。�项目组多数成员具有1-4年工作经验，也有部分更有经验的人员。由于企业规模扩展，很难在一个项目中集中大量经验丰富的员工。项目组成员需要在项目中得到进一步成长。�项目组多数成员对所使用编程语言及工具能够熟练运用，但对于软件设计，还需要更多指导。�项目组多数成员对软件过程及自己所扮演的角色还不具有足够的工作经验，还不能熟练应用RUP、MSF等成熟软件过程。1.21.21.21.2软件生命周期的选择软件生命周期的选择软件生命周期的选择软件生命周期的选择基于上述假设，由于项目组成员自身技能的不完善，运用复杂的软件过程会导致更多问题。尽管一些人员认为RUP可以通过裁剪以适应不同的项目规模，但在实践上，多次迭代可能导致里程碑不清晰，而项目组成员对软件过程的模糊以及自身技能的不完善，将使这个问题放大。此外，项目管理要求成本可控，RUP的某一阶段迭代如果未达到预期目标而进入下一阶段，则很容易导致工期延误。因此，本文所描述的系统分析设计方法，基于最接近我们日常工作的软件过程——瀑布模型。软件过程分为几个阶段：需求、概要设计（或体系结构设计）、详细设计、编码及单元测试、集成测试、系统测试。1.31.31.31.3软件设计的风险及解决办法软件设计的风险及解决办法软件设计的风险及解决办法软件设计的风险及解决办法项目组完成一个阶段工作后，需发起评审，并有各领域技术专家、项目组主管人员等参与评审，确认阶段成果并决定是否进入下一个阶段。只有严格进行评审，中国通信服务福建邮科公司使用UML进行软件分析设计才可以避免将上一阶段的风险带入下一阶段，并导致更多的人员和资源投入、工期延误。软件设计阶段作为软件研发工作中最复杂的部分，更需要加强风险控制。由于项目组以外的评审人员对于项目细节了解不多，因此，需要在提交评审的材料中展示尽可能多的细节。对于软件设计尤其如此。设计思路经常由架构师个人把握，如果只展示了设计的结果，很有可能在评审中存在重大细节的遗漏，评审组跟随设计者的思路而评审通过。因此，稳健的做法是：提交的文档不但包括设计的结果，甚至涵盖设计过程，使评审组能够在半天的评审时间中，领略设计者思路的演进过程，从细节中发现风险。UML用于软件建模，可以涵盖需求模型、系统静态模型、动态模型等各个方面。复杂的分析设计工作，在UML的各个视图中，成为一个个小步骤。分析设计过程不再是一个黑箱，而是具有各个细节的里程碑。本文基于上述项目研发团队假设，选择UML几个主要视图，表述如何从需求文档作为起点，完成分析设计过程的一种方法。2222分析设计过程概述分析设计过程概述分析设计过程概述分析设计过程概述软件，是真实世界的模拟。面向对象的思想，更强调对真实世界的业务特性深刻理解，并迁移到软件中。因此，面向对象软件分析设计的过程，大致可以分为抽象化和具体化的2个步骤：�抽象化——建立抽象表述真实世界的概念模型。�具体化——通过软件技术手段表述概念模型，并得以实现。概念模型是一个重要里程碑，它是真实世界的最小表述，揭示了真实世界中的本质关系。如果概念模型错误，意味着后续所有工作对真实世界的理解出现错误，即将勉强实现了全部需求，软件仍然很可能出现难以维护等问题。概念模型是最抽象的集合，从概念模型开始，体系结构是一个不断补充信息的中国通信服务福建邮科公司使用UML进行软件分析设计过程，使得真实世界可以用软件实现。在本文中，我们将概念模型的建立过程称为系统分析，将概念模型转化为设计模型及以后的过程，称为系统设计。在将设计模型中的类分配到各个构件中，运用各种设计模式，建立实现视图，则接近于我们实践中的详细设计过程（注：以RUP等过程观点看，实现视图是体系结构的一部分）。后续各章节将逐步展现分析设计过程及UML在过程中的应用。3333用户需求的抽象化用户需求的抽象化用户需求的抽象化用户需求的抽象化3.13.13.13.1需求阶段的工作成果在进入分析设计阶段前，我们已经获得了《需求规格说明书》作为输入文档。由于项目进度等原因，可能《需求规格说明书》尚未完全定稿，但评审组已经认可它可以作为分析设计阶段的输入。特别的，对于个别非常简单的项目，也可能使用《用户需求说明书》作为输入，这种情况下，我们认为《用户需求说明书》已经涵盖来全部可见和隐含的需求。3.23.23.23.2用例视图用例视图用例视图用例视图用例视图是外部用户观察到的系统功能模型图。用例视图定义了系统边界。用例的集合为系统，而任何参与者都不属于系统。每个用例是参与者与系统之间的一次交互过程。需要注意的是，用例不是系统中的“对象”，也不表示对象的集合，而近似于表示功能的集合。用例直接与参与者交互，对于参与者不可见的功能，不能独立为一个用例，而应在后续的建模过程中揭示。在用例视图中，参与者可以包括系统操作者、外部系统等，即系统外与本系统交互的对象。在整个用例图中，遗漏参与者的情况并不多见。但是，对于其中一个用例中，遗漏与之联系的参与者的情况则非常常见。用例的名称只揭示了用例的一部分含义。一般的，需要使用文本说明对用例进行详细描述。由于在需求阶段已输出《需求规格说明书》，可以将需求标题、编号作为用例文本描述。这样也便于检查用例视图对需求的覆盖性。中国通信服务福建邮科公司使用UML进行软件分析设计3.33.33.33.3需求的各种表示法对比需求的各种表示法对比需求的各种表示法对比需求的各种表示法对比至此我们依次获得来3种需求表示法：《用户需求说明书》、《需求规格说明书》、《用例视图》。比较如下：3.3.13.3.13.3.13.3.1文档阅读者视角文档阅读者视角文档阅读者视角文档阅读者视角�用户需求说明书——通过走访用户搜集整理，并经过用户确认的文档，反映从用户视角看到的需求。�需求规格说明书——基于用户需求，经过需求人员分析提炼完成。是从需求人员视角看到的需求。�用例视图——设计人员对需求建模，作为后续分析设计工作的输入，是从架构师视角看到的需求。3.3.23.3.23.3.23.3.2文档覆盖性特点文档覆盖性特点文档覆盖性特点文档覆盖性特点�用户需求说明书——从业务模型角度描述需求，对需求的细节，以及需求在各个功能组中的展现或有遗漏。例如，在报表中提出来某个指标要求，但在中国通信服务福建邮科公司使用UML进行软件分析设计业务功能中从未提及。�需求规格说明书——对用户需求初步分析，发现隐含需求，补充需求细节。需求集合完整，并被初步分配到各个功能组合中，例如：在业务展现子系统上的某个信息字段，在采编子系统也被提及。�用例视图——基于规格化的需求，进行抽象归纳，提取用例，侧重描述用例与参与者、用例与用例的关系，而不再补充需求细节。从《需求规格说明书》到《用例视图》的过程中，进行了分析设计过程的第一次抽象，损失了部分非关键信息。3.43.43.43.4用例分析用例分析用例分析用例分析用例之间的关系有：关联、扩展、用例泛化、包含。对于一般的用例分析过程，可以只使用用例泛化、包含2个关系。包含：用例是功能集合，可以视为对应于SRS中的功能描述项。正如SRS中的功能项可以拆分成细项一样，用例也可以通过包含关系分解为颗粒度更小的用例，从而进行更为细致的分析。需求注意的是：拆分后的用例仍然应当是系统外部可见的功能集合。用例泛化：类似的多个用例可以有一个共同的父用例，这可以揭示用例之间的深层次关系，在后续分析设计过程中可能更侧重于对父用例的分析，再分别关注各个子用例的特性。相反的，对于一个用例的深入分析，也可能分解为多个子用例。将用例分解到适当的颗粒度，并揭示用例之间的关系，确保用例的参与者准确无误。这样，后续分析设计工作，将有一个清晰准确的需求视图作为输入。中国通信服务福建邮科公司使用UML进行软件分析设计4444用活动图描述用例用活动图描述用例用活动图描述用例用活动图描述用例4.14.14.14.1活动视图活动视图活动视图活动视图活动图用于对计算流程和工作流程建模。活动图有助于理解系统高层活动的执行行为，而不涉及建立协作图所必须的消息传送细节。活动状态表示过程中命令的执行或工作流程中活动的进行。活动状态等待计算处理工作的完成。当活动完成后，执行流程转入到活动图中的下一个活动状态。动作状态与活动状态相似，但它是是原子的，且不能被外部事件转换中断。并发线程表示能被系统中的不同对象和人并发执行的活动。在一个计算流程或工作流程中，各个活动通常由不同的参与者执行。如企业办公流程，则各部门作为参与者，分别控制一个阶段的活动。通过“泳道”，将模型中的活动按照职责组织起来。中国通信服务福建邮科公司使用UML进行软件分析设计4.24.24.24.2活动图应用场景活动图应用场景活动图应用场景活动图应用场景用例视图描述了系统边界，并将系统功能分配到各个用例中。用例是外界可见的交互过程。而对于交互过程的细节，通过文本进行一定程度的描述。当一个用例有较多参与者，且无法拆分为更简单的用例时，就需要其他的模型化技术描述。一个活动图可以用于表示一个复杂用例。其中1个活动，表示1个参与者对系统进行的1个阶段的交互。由于多个参与者可能在同一时间段与系统交互，因此，各个活动可以并发进行。用例视图中，参与者与系统的交互是在用例中的文本描述叙述的，还是比较模糊的。而在活动图中，对于1个用例，所有的参与者职责被明确分配，同一参与者中国通信服务福建邮科公司使用UML进行软件分析设计在各个阶段进行的操作也更为清晰，活动的并发性也被模型化表示出来。不推荐对所有用例建立活动图。一些用例比较简单，通过文本描述或需求规格说明书已经非常明确，可以直接用于后续分析设计工作。5555建立概念模型建立概念模型建立概念模型建立概念模型5.15.15.15.1概念模型定义概念模型定义概念模型定义概念模型定义模型就是抽象，就是有意识地忽略事物的某些特征。概念模型是抽象程度最高的模型，剥离了一切细节，只留下领域概念、核心属性及领域概念中的基本关系。从概念模型开始，到设计模型、实现模型，模型不断细化和演进，此过程应维持概念的一致完整，即概念完整性。5.25.25.25.2静态视图静态视图静态视图静态视图静态视图对应用领域中的概念以及与系统实现有关的内部概念建模。在概念模型中，只对应用领域中的概念建模；在设计模型中，对系统有关的内部概念建模。静态视图包括类图和对象图。一般使用类图表示静态视图。类图中主要元素为类元及它们的关系。类元包括：子系统、构件、接口、用例、参与者等。其中最主要是类。类表示被建模的应用领域中的离散概念物理实体（如飞机）、商业事物（如一份订单）、逻辑事物（如广播计划）、应用事物（如取消键）、计算机领域的事物（如哈希表）或行为事物（如一项任务）。关系包括关联、聚集和组成、泛化、实现等。5.2.1聚集和组成聚集表示部分与整体关系的关联。组成是更强形式的关联，整体有管理部分的特有的职责。中国通信服务福建邮科公司使用UML进行软件分析设计5.2.2泛化泛化关系是类元的一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并对其进行了扩展。5.2.3实现实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说