您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 管理学资料 > 第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仓储系统业务用例建模制作用例图的步骤:①分析确定系统的执行者(角色):项目管理员、资源管理员、系统管理员、备份数据系统。②确定用例:项目管理,资源管理和系统管理。③对用例进行分解
本文标题:第10章基于UML的仓储管理系统的分析设计
链接地址:https://www.777doc.com/doc-1248690 .html