第10章基于UML的仓储管理系统的分析设计

10基于UML的仓储管理系统的分析设计10.1概述10.2仓储系统业务用例建模10.3仓储系统需求用例建模10.4业务领域分析与设计10.5系统实现测试与配置10.基于UML的仓储管理系统的分析设计10.1概述10.1.1系统开发背景与开发思想(1)问题背景某公司面对过程的仓储管理系统已不能满足企业新业务、新环境以及客户对信息查询的要求，迫切需要开发一套新系统实现第三方物流和电子商务的接轨。(2)系统开发的主要思想首先对公司的业务与用户的需求进行分析，然后对系统的功能进行详细的设计，并在分析与设计的同时用UML建模语言对其建模，采用工具ROSE绘制描述各种模型的图形。RationalRose是美国Rational软件公司研制的图形化的OOCASE工具，是目前最为流行的先进的可视化软件开发工具之一。它具有可视化建模功能，能帮助系统开发人员和用户获得规范的OOAD结论，进行结论交流，以及对这些结论的一致性检查；支持RUP过程。10.1.2系统基本功能需求系统的功能是系统能够完成的操作和任务，本系统的功能有：（1）系统能完成入库操作过程中的表与码单的录入；（2）系统能完成入库过程中货物的审核，记费；（3）系统能进行有效的库存管理，例如盘点，移库等；（4）系统能对出库过程中的表与帐单进行管理；（5）系统能对出库后的平帐，记录储存等进行管理；（6）系统用户能有效的进行权限，日志的管理；（7）系统用户可以查询报表，客户，货物等基本信息；（8）系统能记录下系统的使用日志；（9）任何人员要使用本系统必须拥有相应的权限。10.1概述10.1.3系统开发过程结合仓储系统的特点和RUP分析过程，基于UML和RUP的仓储系统的开发过程：10.1概述10.2.1通用模型元素、用例建模和活动图(1)通用模型元素模型元素是UML构造系统的各种元素，是UML构建模型的基本单位。模型元素代表面向对象中的类，对象，关系和消息等概念，是构成图的最基本的常用的概念。分为以下两类：基元素：是已由UML定义的模型元素。如：类、结点、构件、注释、关联、依赖和泛化等。构造型元素：在基元素的基础上构造的新的模型元素，是由基元素增加了新的定义而构成的，如扩展基元素的语义（不能扩展语法结构）,也允许用户自定义。构造型用括在双尖括号《》中的字符串表示。目前UML提供了40多个预定义的构造型元素。如使用《Use》、扩展《Extend》。10.2仓储系统业务用例建模①模型元素可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等。属性用例包结点状态组件类操作对象属性操作接口注释10.2仓储系统业务用例建模关联：连接（connect）模型元素及链接(link)实例。依赖：表示一个元素以某种方式依赖于另一种元素。泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。聚合：表示整体与部分的关系。除了上述的模型元素外，模型元素还包括消息，动作和版类（stereotype）等。关联聚合组合依赖细化泛化（继承）模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、泛化（generalization）、依赖(dependency)和聚合(aggregation)，其中聚合是关联的一种特殊形式。这些关系的图示符号如下图所示。10.2仓储系统业务用例建模(2)关联和链关联（association）是两个或多个类之间的一个关系。链（link)是关联的具体体现。关联的表示：如下图所示，关联有二元关联(binary)、三元关联(ternary)、多元关联(higherorder)。（a）二元关联人员公司雇用二元关联的例子（人员）张涛（公司）通大雇用链的例子（b）三元关联项目语言◆人三元关联的例子(项目)CAD系统(语言)C++◆(人)李波链的例子10.2仓储系统业务用例建模关联的重数重数(multiplicity)表示多少个对象与对方对象相连接(如左图)，常用的重数符号有：“0..1”表示零或1“0..*”或“*”表示零或多个“1..*”表示1或多个“1,3,7”表示1或3或7（枚举型）重数的默认值为1。PersonHobby1*带有多重性关联图有序关联与导航（导引）在关联的多端标注{ordered}指明这些对象是有序的(左图）。关联可以用箭头，表示该关联使用的方向(单向或双向)，称为导引或导航(navigation)。(a)指定链接之间有明确的顺序0..*1..*{ordered}保险合同个人PolygonPoint14..*{ordered}(b)单向关联10.2仓储系统业务用例建模(3)约束UML中提供了一种简便、统一和一致的约束（constraint），是各种模型元素的一种语义条件或限制。一条约束只能应用于同一类的元素。约束的表示：如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。通常一个约束由一对花括号括起来（{constraint}），花括号中为约束内容（如下图所示）。如果一条约束涉及同一种类的多个元素，则要用虚线把所有受约束的元素框起来，并把该约束显示在旁边（如：或约束）。0..*1..*{ordered}保险合同个人PolygonPoint14..*{ordered}10.2仓储系统业务用例建模对泛化的约束的两种表示方法约束可分为对泛化的约束和关联的约束。①对泛化的约束：应用于泛化的约束，显示在大括号里，若有多个约束，用逗号隔开。如果没有共享，则用一条虚线通过所有继承线，并在虚线的旁边显示约束，如下图所示。{constraint1,constraint2}ClassAClassBClassCClassD{constraint1,constraint2}ClassAClassCClassBClassD常用的对泛化的约束有：complete:说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。disjoint:父类对象不能有多于一个型的子对象。10.2仓储系统业务用例建模incomplete:说明不是泛化中所有子元素都已说明，允许再增加其它子元素。overlapping:给定父类对象可有多于一个型的子对象，表示重载。②关联的约束：对消息，链接角色和对象的约束；自定义约束。常用的关联的约束有：implicit:该关联只是概念性的，在对模型进行精化时不再用。ordered:具有多重性的关联一端的对象是有序的。changeable:关联对象之间的链(Link)是可变的（添加、修改、删除）。addonly:可在任意时刻增加新的链接。frozen:冻结已创建的对象，不能再添加、删除和修改它的链接。10.2仓储系统业务用例建模xor:“或约束”，某时刻只有一个当前的关联实例。(4)依赖依赖关系描述的是两个模型元素（类，组合，用例等）之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。如下图表示类A依赖于类B的一个友元依赖关系。帐号人单位{xor}对象类的xor关联类A类B《友元》10.2仓储系统业务用例建模依赖的形式可能是多样的，针对不同的依赖的形式，依赖关系有不同的变体(varieties)：抽象(abstraction)：从一个对象中提取一些特性，并用类方法表示。绑定(binding)：为模板参数指定值，以定义一个新的模板元素。组合(combination)：对不同类或包进行性质相似融合。许可(permission)：允许另一个对象对本对象的访问。使用(usage)：声明使用一个模型元素需要用到已存在的另一个模型元素，这样才能正确实现使用者的功能(包括调用、实例化、参数、发送)。跟踪(trace)：声明不同模型中元素的之间的存在一些连接。访问或连接(access)：允许一个包访问另一个包的内容。10.2仓储系统业务用例建模调用(call)：声明一个类调用其他类的操作的方法。导出(derive)：声明一个实例可从另一个实例导出。友元(friend)：允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。引入(import)：允许一个包访问另一个包的内容，并为被访问组成部分增加别名。实例(instantiation)：关于一个类的方法创建了另一个类的实例声明。参数(parameter)：一个操作和它参数之间的关系。实现(realize)：说明和其实之间的关系。精化(refine)：声明具有两个不同语义层次上的元素之间的映射。发送(send)：信号发送者和信号接收者之间的关系。10.2仓储系统业务用例建模(5)细化有两个元素A和B，若B元素是A元素的详细描述，则称B,A元素之间的关系为B元素细化A元素。细化与类的抽象层次有密切的关系，在构造模型时要经过逐步细化,逐步求精的过程。如左图所示，类B是类A细化的结果。AB(6)注释注释用于对UML语言的元素或实体进行说明，解释和描述。通常用自然语言进行注释。这是一个类人员10.2仓储系统业务用例建模2.用例建模(Usecasemodel)用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。贸易经理风险分析设置边界进行交易交易估价更新帐目《使用》《使用》《扩展》营销人员超越边界评价记帐系统销售人员图6.1410.2仓储系统业务用例建模用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。用例模型驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中，构成用例图的主要元素是用例和执行者及其它们之间的联系。创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。10.2仓储系统业务用例建模(1)执行者(Actor)执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示,但执行者可以是人，也可以是一个外界系统。注意：用例总是由执行者启动的。如何确定执行者：谁使用系统的主要功能(主执行者)?谁需要从系统获得对日常工作的支持和服务？需要谁维护管理系统的日常运行（副执行者）？系统需要控制哪些硬件设备？系统需要与其它哪些系统交互？谁需要使用系统产生的结果（值）？供货买饮料取货款客户供货人收银员自动售货系统10.2仓储系统业务用例建模(2)用例(usecase)从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。用例有以下特点:用例捕获某些用户可见的需求,实现一个具体的用户目标。用例由执行者激活,并将结果值反馈给执行者。用例必须具有功能上的完整描述。如何确定用例：与系统实现有关的主要问题是什么？系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？执行者需要系统提供哪些功能？执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？10.2仓储系统业务用例建模用例图的元素(3)用例图用例图描述了系统的功能需求，它是从执行者的角度来理解系统，由“执行者”、“用例”和“用例之间的关系”3类模型元素构成。下图中还有另外两种类型的连接,即《Use》和《Extend》关系，是两种不同形式的泛化关系。《Use》表示一个用例使用另一个用例。《Extend》通过向被扩展的用例添加动作来扩展用例。用例2用例A用例执行者用例1用例3用例B《Use》《Use》《Extend》(a)(b)(c)10.2仓储系统业务用例建模制作用例图的步骤：①分析确定系统的执行者(角色)：项目管理员、资源管理员、系统管理员、备份数据系统。②确定用例：项目管理，资源管理和系统管理。③对用例进行分解