软件概要设计说明书类图顺序图

UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。

UML的9种图上文我们介绍了，UML的视图，在每一种视图中都包含一个或多种图。

本文我们重点讲解UML每种图的细节问题：1、用例图（use case diagrams）【概念】描述用户需求，从用户的角度描述系统的功能【描述方式】椭圆表示某个用例；人形符号表示角色【目的】帮组开发团队以一种可视化的方式理解系统的功能需求【用例图】2、静态图(Static diagram)(1)类图（class diagrams）【概念】显示系统的静态结构，表示不同的实体是如何相关联的【描述方式】三个矩形【目的】表示一个逻辑类或实现类，逻辑类通常是用户的业务所涉及的事物；实现类是程序员处理的实体【类图】(2)对象图（object diagrams）【概念】类图的一个实例，描述系统在具体时间点上所包含的对象以及各个对象的关系【对象图】3、交互图(Interaction Diagram)用来描述对象之间的交互关系(1)序列图（顺序图）(Sequence Diagram)【概念】描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序【描述方式】横跨图的顶部，每个框表示每个类的实例或对象；类实例名称和类名称使用冒号分开【目的】显示流程中不同对象之间的调用关系，还可以显示不同对象的不同调用。

【序列图】(2)协作图（Collaboration diagrams）【概念】描述对象之间的合作关系，侧重对象之间的消息传递4、行为图：描述系统的动态模型和对象之间的交互关系(1).状态图（Statechart diagrams）【概念】描述对象的所有状态以及事件发生而引起的状态之间的转移【描述方式】起始点：实心圆1状态之间的转换：使用开箭头的线段2状态：圆角矩形3判断点：空心圆4一个或多个终止点：内部包含实心圆的圆【目的】表示某个类所处的不同状态以及该类在这些状态中的转换过程(2).活动图（Activity diagrams）【概念】描述满足用例要求所要进行的活动以及活动时间的约束关系【描述方式】2起始点：实心圆5活动：圆角矩形1终止点：内部包含实心圆的圆1泳道：实际执行活动的对象【目的】表示两个或多个对象之间在处理某个活动时的过程控制流程【活动图】活动图和状态图区别：5、实现图Implementation diagram (1)构件图（Component diagrams）【概念】描述代码构件的物理结构以及各构件之间的依赖关系【描述方式】构件【目的】提供系统的物理视图，根据系统的代码构件显示系统代码的整个物理结构【构架图】(2)部署图（Deployment diagrams）【概念】系统中硬件的物理体系结构【描述方式】1三维立方体表示部件2节点名称位于立方体上部【目的】显示系统的硬件和软件的物理结构【部署图】九种UML图详解到此为止，下篇文章专门给大家讲解UML中类间的关系，感谢您的访问。

××_软件项目概要设计说明书版本：编制：审核：批准：颁布日期：2017年4月18日受控状态：■受控□非受控分发范围：项目组、财务部、质量管理部修订记录传播优秀Word版文档，希望对您有帮助，可双击去除！目录1 引言 (1)1.1 概述 (1)1.2 目的 (1)1.3 范围 (1)1.4 缩略语 (1)1.5 术语 (2)2 参考资料 (2)3 交付需求列表 (2)4 系统物理架构 (2)4.1 系统运行的硬件环境 (2)4.2 系统运行的软件环境 (3)4.3 系统运行的网络环境 (3)4.4 系统部署图 (3)4.5 安装部署说明 (4)5 系统逻辑架构 (5)5.1 子系统一 (5)1.1.1子模块一 (5)1.1.2子模块二 (5)5.2 子系统二 (5)6 实现视图 (5)7 进程视图 (6)8 数据库设计 (6)9 设计约束 (6)10 内部接口定义 (6)11 外部接口 (6)12 开发环境说明 (7)13 技术难点 (7)14 附录 (8)14.1 模型文件 (8)14.2 XXXX (8)××_软件项目概要设计说明书1引言1.1概述{应包括：a. 项目的委托单位、开发单位和主管部门；b. 该软件系统与其他系统的关系。

}本项目交办方为，承办方为。

}1.2目的{阐明编写概要设计说明书的目的，指明读者对象。

}本文档是在用户和开发方对系统进行需求开发，形成软件需求规格说明书后，设计人员分析各个详细需求后，对软件的概要设计。

本文档作为软件概要设计和软件详细设计的重要依据。

软件概要设计人员和软件详细设计人员依此作为工作依据。

1.3读者对象本系统设计说明书的使用读者为：业务经理、软件设计、UI设计人员、测试人员。

1.4范围概要设计要考虑对架构有影响的需求，将系统划分为{子系统一，子系统二}，从物理架构，逻辑架构，实现视图，进程视图等四个方面对架构进行描述，定义子系统之间的接口，明确系统依赖的外部接口，说明系统开发准则，选取开发环境，对技术难点进行分析说明。

UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。

建模可以把在复杂世界的许多重要的细节给抽象出。

许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处。

UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。

而且每个部分都有一个小问题，测试一下你对这个部分的理解。

为什么UML很重要？为了回答这个问题，我们看看建筑行业。

设计师设计出房子。

施工人员使用这个设计来建造房子。

建筑越复杂，设计师和施工人员之间的交流就越重要。

蓝图就成为了这个行业中的设计师和施工人员的必修课。

写软件就好像建造建筑物一样。

系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。

在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。

现在它已经成为了软件行业的一部分了。

UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。

UML被应用到面向对象的问题的解决上。

想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。

一个模型model就是根本问题的抽象。

域domain就是问题所处的真实世界。

模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。

记住把一个对象想象成“活着的”。

对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。

对象的属性的值决定了它的状态state。

类Classes是对象的“蓝图”。

一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。

对象是类的实例instances。

用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。

UP是软件开发过程，描述了构造，部署以及维护软件的方式。

统一过程是一种流行的构造面向对象系统的迭代软件开发过程。

Rational（RUP）统一过程是对统一过程的详细精化，并且已经被广泛采纳。

UP以构架为中心，用例驱动，迭代和增量式开发。

迭代和增量式开发分为，初始、细化、构造、交付四个过程，在初始阶段并不需要去分析全部的需求，在了解了整个业务之后找到最核心的需求，将最核心的需求分析并实现，展示给客户看，然后再客户给出新的需求后在分析需求，并将需求在初始系统的基础上扩展。

XP极限编程，是指在开发过程中不断的沟通，与客户沟通产生反馈信息，项目组内部沟通产生反馈信息，不断的修正系统，让系统朝着正确的方向发展，所以在系统交付之前，系统是变化的，不稳定的。

XP中的测试驱动开发(tdd)，是指在编程之前写测试单元，即编写系统不能通过的情况，直到系统能完全通过测试单元，则系统完成；重构，在实现系统的时候修改代码；持续集成，在开始的时候存在一个核心的可用系统，然后在其上不断扩展，不断集成，每天都要存在一个可运行的系统。

UML包括：事务，关系，图，扩展机制事务：结构：类，接口，构件，节点等行为：交互（消息），状态等分组：包，子系统等注释：注释关系：依赖，关联（聚合，组合），泛化，实现图：用例图，交互图（顺序图，协作图），类图，活动图，状态图等扩展机制：Stereotype(版型)，TaggedValue（标签值），ConstraintRational Rose是一种建模工具用例视图：需求分析阶段的利器逻辑视图：设计阶段，用例的实现组件视图：构件表示封装了其内容的系统模块，构件是相对独立的模块部署视图：表示软件元素在物理架构上的部署，以及物理元素之间的通信UML基本图示类图顶端“ClassName”表示类名中间部分为该类的属性，其中分别表示为可访问性，属性名，以及属性的数据类型。

第三部分为该类的方法，包括方法的可访问性，方法名，方法的参数以及方法的返回值。

UML建模风格之顺序图和合作图、活动图一样，UML顺序图( Rumbaugh、Jacobson、和booch, 1999)是一种动态建模方法。

UML顺序图一般用于：1.确认和丰富一个使用情境的逻辑。

一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。

一个使用情境的逻辑可能是一个用例的一部分，或是一条备选线路；一个贯穿单个用例的完整流程，例如动作基本过程的逻辑描述，或是动作的基本过程的一部分再加上一个或多个的备用情境的逻辑描述。

或是包含在几个用例中的流程，例如一个学生注册入学之后，立即就要在三个班级注册。

2.研究你的设计，因为它们为你提供了一种方式，你可以使用这种方式来可视化的调用类定义的操作。

3.检测面向对象的设计中的瓶颈。

通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，你很快就能了解那里的设计需要变化，以达到在系统内部平衡负荷的目的。

实际上某些CASE工具甚至能够让你模拟软件这些特征。

4.使你能够感觉到你的应用程序的那个类将会变得复杂的，这是个信号，意味着你需要为那些类画状态图了。

指南∶通用准则尽力保持消息的顺序从左到右排列将分类器分层用和你的用例图一致的名称命名角色用和你的类图一致的名称命名类一个角色的名称可以和类的名称相同包含一个逻辑的叙述性描述在图的最左边放置初始的角色在图的最左边放置人和组织角色在图的最右边放置系统角色只在合适的时候才建模对象的Destruction分类器的原则当你在消息上引用对象时要命名他们当存在部分相同的类型时需要命名对象一致地应用文本版型少量地应用可视化的版型集中在关键的交互消息的原则把消息名放在箭头旁边直接创建对象为软件消息使用操作符号为涉及人和组织角色的消息使用叙述性文字推荐使用参数名称，而不是参数类型为参数占位符注明类型类的消息实现为静态操作为用例调用使用<<include>>版型返回值的原则当返回值非常明显时就不要对返回值建模只有当你需要在别处引用返回值时才对返回值建模在箭头旁边调整返回值返回值建模为方法调用的一部分为返回值占位符注明类型明确的为简单值标明实际值一、通用准则1.尽力保持消息的顺序是从左到右排列的一个顺序图的消息流开始于左上方，消息乙的位置比消息甲低，这意味着消息乙的顺序比消息乙要迟。