面向对象UML工程预算系统.docx
《面向对象UML工程预算系统.docx》由会员分享，可在线阅读，更多相关《面向对象UML工程预算系统.docx（21页珍藏版）》请在冰豆网上搜索。
面向对象UML工程预算系统
面向对象的系统分析与UML
------工程预算系统
摘要：
面向对象的系统分析是以面向对象的观点和方法描述系统或产品，以使它符合面向对象软件工程的特点。
通过面向对象的方法对工程预算系统进行系统的分析和理解，运用OOA及UML等方式对其中的事物和它们之间的关系产生进一步的认识，并且建立如用例图、类图等来可视化表现它们的关系。
关键字：
OOA对象建模UML可视化用例图类图活动图顺序图状态图
1引言
随着时代的发展和科技的进步，人们对软件的要求也越来越高，所以分析所面临的问题也越来越突出。
其中包括：
问题域和系统责任的复杂性、人与人之间的沟通和交流、需求的不断变化及软件复用对分析的要求。
通过使用OOA可以使对问题域和系统责任的理解得以加强。
从而改善与系统有关的人员之间的沟通同时又支持软件的复用。
工程预算系统是基于现在越来越多的有关建筑方面的工程却又由于各种各样的繁琐而又无法解决的预算问题而设计开发的一款桌面应用系统。
参与者包括了用户，管理员（工程承包商，以后统称管理员）及材料供应商等组成，其目的是为了方便用户可以提出需求的同时又可以清楚的知道自己的钱花在什么地方，同时管理员和供应商又通过系统可以代理很多的工程方便拓展业务。
通过工程预算系统实现三方的交流和沟通，是工程预算清晰合理化提高效率节约一些不必要的时间。
在工程预算系统的分析过程中，我们就是要运用OOA的方法并通过UML来实现系统中的用例和类，及各个对象之间的关系。
2面向对象的系统分析
2.1OOA的概念
Object-OrientedAnalysis（面向对象分析方法）是确定需求或者业务的角度，按照面向对象的思想来分析业务。
例如：
OOA只是对需求中描述的问题，进行模块化的处理，描述问题的本质，区别每个问题的不同点相同点，确定问题中的对象。
OOA与结构化分析有较大的区别。
OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
2.1.1分析
OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。
在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。
分类结构就是所谓的一般与特殊的关系。
组装结构则反映了对象之间的整体与部分的关系。
2.1.2OOA定义属性
OOA在定义属性的同时，要识别实例连接。
实例连接是一个实例与另一个实例的映射关系。
OOA在定义服务的同时要识别消息连接。
当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。
OOA中的5个层次和5个活动继续贯穿在OOD（面向对象的设计）过程中。
OOD模型由4个部分组成。
它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。
2.2OOA的任务
运用面向对象方法，对问题域和系统责任进行分析和理解，对其中的事物和它们的关系产生正确的认识，找出描述问题域和系统责任所需的类和对象，定义这些类和对象的属性与操作，以及它们之间所形成的各种关系。
最终目的是产生一个符合用户需求，并能够直接反映问题域和系统责任的OOA模型及其规约。
2.3OOA的主要原则
（1）抽象：
从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。
（2）封装：
就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。
（3）继承：
特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。
（4）分类：
就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。
分类原则实际上是抽象原则运用于对象描述时的一种表现形式。
（5）聚合：
又称组装，其原则是：
把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。
（6）关联：
是人类思考问题时经常运用的思想方法：
通过一个事物联想到另外的事物。
能使人发生联想的原因是事物之间确实存在着某些联系。
（7）消息通信：
这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。
通过消息进行通信是由于封装原则而引起的。
在OOA中要求用消息连接表示出对象之间的动态联系。
（8）粒度控制：
一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。
因此需要控制自己的视野：
考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其余的部分。
这就是粒度控制原则。
（9）行为分析：
现实世界中事物的行为是复杂的。
由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。
2.4OOA的主要优点
（1）加强了对问题域和系统责任的理解；
（2）改进与分析有关的各类人员之间的交流；
（3）对需求的变化具有较强的适应性；
（4）支持软件复用；
（5）贯穿软件生命周期全过程的一致性；
（6）实用性；
（7）有利于用户参与。
2.5OOA过程
1、建立需求模型—用例图
确定系统边界
发现参与者
确定用况
2、建立基本模型—类图
发现对象、定义它们的类
定义对象的内部特征—属性和操作
定义对象的外部关系--一般-特殊结构、整体-部分结构、关联和消息。
3、建立辅助模型—包图、顺序图、活动图等
4、建立模型规约
5、原型开发
3UML
3.1UML的概念
UnifiedModelingLanguage（UML）又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
面向对象的分析与设计（OOA&D，OOAD）方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。
它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。
GradyBooch的描述对象集合和它们之间的关系的方法。
JamesRumbaugh的对象建模技术（OMT）。
IvarJacobson的包括用例方法的方式。
还有其他一些想法也对UML起到了作用，UML是Booch,Rumbaugh,Jacobson。
UML已经被对象管理组织（OMG）接受为标准，这个组织还制定了通用对象请求代理体系结构（CORBA），是分布式对象编程行业的领头羊。
计算机辅助软件工程（CASE）产品的供应商也支持UML，并且它基本上已经被所有的软件开发产品制造商所认可，这其中包括IBM和微软（用于它的VB环境）。
UML规范用来描述建模的概念有，类（对象的）、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态。
3.2UML的特点
（1）UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。
它实际上是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。
（2）UML建模能力比其它面向对象建模方法更强。
它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。
（3）UML是一种建模语言，而不是一个开发过程。
3.3图
图聚集了相关的事物及其关系的组合，是软件系统在不同角度的投影。
图由代表事物的顶点和代表关系的连通图表示。
下面对常用的几类图[2-12]进行简单介绍。
（1）类图（ClassDiagram）。
展现了一组对象、接口、协作和它们之间的关系。
类图描述的是一种静态关系，在系统的整个生命周期都是有效的，是面向对象系统的建模中最常见的图。
（2）对象图（ObjectDiagram）。
展现了一组对象以及它们之间的关系。
对象图是类图的实例，几乎使用与类图完全相同的标示。
（3）用例图（UseCaseDiagram）。
展现了一组用例、参与者（actor）以及它们之间的关系。
用例图从用户角度描述系统的静态使用情况，用于建立需求模型。
（4）交互图。
用于描述对象间的交互关系，由一组对象和它们之间的关系组成，包含它们之间可能传递的消息。
交互图又分为序列图和协作图，其中序列图描述了以时间顺序组织的对象之间的交互活动；协作图强调收发消息的对象的结构组织。
（5）状态图（StateDiagram）。
由状态、转换、事件和活动组成，描述类的对象所有可能的状态以及事件发生时的转移条件。
通常状态图是对类图的补充，仅需为那些有多个状态的、行为随外界环境而改变的类画状态图。
（6）活动图（ActiveDiagram）。
一种特殊的状态图，展现了系统内一个活动到另一个活动的流程。
活动图有利于识别并行活动。
（7）组件图（ComponentDiagram）。
展现了一组组件的物理结构和组件之间的依赖关系。
部件图有助于分析和理解组件之间的相互影响程度。
（8）部署图（DeploymentDiagram）。
展现了运行处理节点以及其中的组件的配置。
部署图给出了系统的体系结构和静态实施视图。
它与组件图相关，通常一个节点包含一个或多个构建。
需要指出的是，UML并不限定仅使用这9种图，开发工具可以采用UML来提供其他种类的图，但到目前为止，这9种图在实际应用中最常用的。
3.4应用领域
UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。
其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。
总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。
在需求分析阶段，可以用用例来捕获用户需求。
通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。
分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。
为实现用例，类之间需要协作，这可以用UML动态模型来描述。
在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。
这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。
编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。
在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。
因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。
UML模型还可作为测试阶段的依据。
系统通常需要经过单元测试、集成测试、系统测试和验收测试。
不同的测试小组使用不同的UML图作为测试依据：
单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
总之，标准建模语言UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。
4工程管理系统需求分析及人员分工
4.1工程管理系统需求分析
工程预算系统需求
就目前的建筑工程行业，工程量越来越多，信息也越来越多。
继续遵循以前那种面对面的沟通方式与纸质资料的信息存储方式来工作的话。
工作的难度会越来越大，员工的压力也会越来越大。
所以建筑工程管理行业需要一种软件，这种软件能够帮建筑公司保存用户和材料供应商的信息，以及用户需要的工程信息和供应商提供的材料信息。
并且综合这些信息计算出工程需要的资金，并且反馈给用户。
这样就能大大减轻建筑工程公司员工的工作量，提高建筑公司的工作效率。
我们的“工程预算系统”就是这样一款软件，它的使用者有用户、管理员和供应商。
用户和供应商通过注册帐号，登陆的方式进入系统，向系统中输入工程信息和材料信息，系统通过这些信息计算出工程所需要的资金并且反馈给用户。
管理员登陆后可以修改系统中计算资金的算法，以及维护系统中的所有信息。
这满足了建筑工程行业的需求。
其次我们的系统软件预计可以实现对工程费用的详细计算，且对供应商及材料的明确化让用户可以不用担心材料的质量问题及价格问题；同时也可以针对自己的经济情况对自己想要的工程费用有一个清楚的计划。
功能模图如下：
用户
管理员
供应商
4.2人员分工
“工程预算系统”的使用者有用户、管理员和供应商。
用户和供应商通过注册帐号，登陆的方式进入系统，向系统中输入工程信息和材料信息，系统通过这些信息计算出工程所需要的资金并且反馈给用户。
管理员登陆后可以修改系统中计算资金的算法，以及维护系统中的所有信息。
我们的组员共三人，分工如下:
王沈斌：
负责和管理员相关的子模块的分析包括用例图、类图、状态图、顺序图、活动图等所有模块；
郭君华：
负责和供应商相关的子模块的分析包括用例图、类图、状态图、顺序图、活动图等所有模块；；
杨帆：
负责和用户相关的子模块的分析包括用例图、类图、状态图、顺序图、活动图等所有模块。
5需求模型的建立
需求模型即为用例图，用例图是指由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图。
用例图（UserCase）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
本系统主要有两层管理。
第一层为用户和供应商。
供应商通过注册帐号之后登陆到系统，有权限删除和修改用户自己的个人信息，并且能想系统中查看工程信息，接收订单、准备材料、送货、收费等详细功能。
供应商还有退出系统的权限。
用户与管理员的分析略，详见杨帆与王沈斌的文档。
5.1参与者分析
参与者系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
根据上述的系统分析我们可以看出，“工程预算系统”的参与者有：
（1）用户（Users）；
（2）管理员（Administrator）；
（3）供应商（Supplier）；
5.2用例
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，对我们初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
5.3供应商涉及的用例
供应商通过注册帐号之后登陆到系统，有权限删除和修改用户自己的个人信息，并且能想系统中查看工程信息，接收订单、准备材料、送货、收费等详细功能。
供应商还有退出系统的权限。
所以用户涉及的用例有：
1.注册帐号（Regist）
2.登陆系统（Login）
3.查看信息（Check）
4.接收订单（Receive）
5.材料准备（Perpare）
6.货物配送（Delivery）
7.费用收取（Change）
8.交易记录（Receord）
5．4用例分析
注册帐号（Regist）
供应商需要通过注册账号才可以访问该系统。
登陆系统（Login）
供应商通过登录该系统实现登陆并且可以拥有查看信息、接收订单、费用收取等功能的权限。
查看信息（Check）
供应商可以查看用户所需的材料的信息，也可以知道是否有用户想供应商下订单以及订单是否送到或者订单是否完成、费用是否收取等通知。
接收订单（Receive）
供应商登陆系统查看用户向供应商下的订单选择是否接受。
材料准备（Perpare）
供应商在接受订单后开始从库房准备材料，需要获取库房的材料订单及数目以及时准备好足够的材料。
货物配送（Delivery）
供应商在准备好材料后要及时向用户送去材料需要记录用什么工具运输材料以及一次运输多少材料都要记录在案。
费用收取（Change）
供应商在运送材料后查看信息看用户是否已接受材料并且付费。
交易记录（Receord）
订单完成后记录订单详细情况写入数据库留待以后用。
供应商在登陆之前要首先注册账号，登陆之后可以查看信息、接受订单；在接受订单后要准备材料、送货、收费；在这之后要查看信息完成订单并做记录。
其中用户，管理员用例分析有小组另外两人完成并附上用例图。
5.5用例关系分析
供应商要使用该系统首先要进行登陆，如果供应商没有账号则需要注册之后再登陆所以注册和登陆之间是扩展关系；供应商在登录系统后使用查看信息、接受订单、收费等功能时又必须是在登陆之后所以它们和登陆之间是包含关系；其次供应商在查看信息时可能是以邮件的形式所以查看信息和邮件提醒是扩展关系；预订订单和接受订单之间也是扩展关系，同理收取费用和付款之间也是扩展关系，关于供应商的用例分析其主要用例关系就是以上所述。
5．6
5.7用例规约
用例ID号
UC-1
用例名称
注册账号
创建者
郭君华
参与者
供应商
描述
供应商希望从工厂预算系统获取材料订单的信息，需首先从本系统注册一个供应商账号。
以达到注册供应商账号来实现访问该系统的目的
前置条件
供应商希望登陆本系统
后置条件
供应商账号在本系统中已经注册过
主干过程
1.0注册一个账号
1.填写供应商的详细个人信息
2.填写供应商的材料信息
分支过程
1.1注册多个账号（第2步之后分支出来的）
1.供应商要注册另一个账号
异常
1.0.E.1用户名已被使用（第1步）
1.供应商用户名已被注册使用
1.0.E.2用户名不合法（第1步）
1.供应商用户名不合法
1.1.E.1该用户已注册（第1步）
1.该用户已注册
优先级
高
使用频率
每个用户至少使用一次
业务规则
1.按提示在系统中输入供应商的个人信息
注释：
1.0.E.1是主干过程1.0的一个异常
1.0.E.2是主干过程1.0的另一个异常
1.1.E.1是分支过程1.1的一个异常
6基本模型的建立
类图（Classdiagram）是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
类图不显示暂时性信息。
类图（Classdiagram）由许多（静态）说明性的模型元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。
类图可以组织在（并且属于）包中，仅显示特定包中的相关内容。
类图（Classdiagram）是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。
类图（Classdiagram）最基本的元素是类或者接口。
6.1类
类是现实世界或思维世界中的实体在计算机中的反映，它将数据以及这些数据上的操作封装在一起。
对象是具有类类型的变量。
类和对象是面向对象编程技术中的最基本的概念。
类是对象的抽象，而对象是类的具体实例。
类是抽象的，不占用内存，而对象是具体的，占用存储空间。
类是用于创建对象的蓝图，它是一个定义包括在特定类型的对象中的方法和变量的软件模板。
6.2工程预算系统中供应商模块类的设计
该系统根据参与者用户、管理员、供应商分为三部分其中用户，管理员由小组其他两人完成在此着重分析供应商的类。
物料需求计划类：
该类是由用户向供应商提出的对物料的需求而创建的类，其中包括了用户对其正在实施的工程的物料需求。
物料信息类：
该类是一个公共类由供应商参与修改，发布物料信息用户可以通过查看其中的信息来决定自己的工程需求的物料。
采购订单类：
该类是由用户通过物料需求计划及查看物料信息而向供应商下的一个订单类其中有用户所需的物料信息。
订单项类：
该类是一个由采购订单类而延伸出来的类，由于供应商收到的订单可能不止一个所以具有一个订单项类来将订单中的物料信息具体化，数量化。
供应商类：
该类负责更新物料信息及选择是否接受订单以及接受订单后的物料配送等功能。
库存数量类：
该类是一个介于供应商与仓库之间的特殊类用于向供应商提供仓库物料的种类及数目等信息以及预警功能以便于供应商可以实时查看物料信息不至于发生接受订单而物料存储不足的情况。
仓库类：
该类是实时向供应商反应各个仓库物料的种类及数目以便于供应商的统筹调配。
6.3系统中类的操作和属性
物料需求计划类：
属性：
用户ID 用户的ID号
日期 用户物料需求计划的实施日期
物料名称用户所需物料的名称
物料ID 物料的ID号
数量 物料的数目
操作：
创建物料需求计划 创建一个用户所需的物料几乎表
修改物料需求计划 修改物料计划表
删除物料需求计划 删除计划表
物料信息类：
属性：
物料名称物料的名称
物料ID物料的ID号
型号规格无聊的型号及规格
物料价格物料的单价
操作：
查看查看物料信息
修改修改物料信息
删除删除过时的物料信息
采购订单类：
属性：
订单ID订单ID号
用户ID用户的ID号
订货日期订货的具体日期
到货日期到货的日期
数量物料的数量
付费方式可以选择的款方式
操作：
创建订单用户创建的订单
修改订单用户修改订单
删除订单用户或供应商删除订单
查看订单供应商查看订单
订单项类：
属性：
订单ID订单ID号
物料名称物料的名称
物料ID物料得ID号
数量物料的数量
操作：
修改修改物料的信息
删除删除物料的信息
供应商类：
属性：
供应商ID供应商注册的ID号
供应商名称供应商名称
供应商地址供应商的地址
供应商电话供应商的联系方式
供应商账号供应商收费的账号
操作：
注册创建供应商信息
修改修改供应商信息
删除删除供应商信息
库存数量类：
属性：
仓库ID仓库的ID号
物料ID物料的ID号
数量物料的数量
操作：
查看查看物料的信息
修改修改物料得信息
仓库类：
属性：
仓库ID仓库的ID号
物料ID物料ID号
数量该仓库物料的数量
6.4类之间的关系
物料需求计划类与采购订单类之间是一对多的关联关系，关联名是生成,因为一个用户的物料需求计划只有一个但是生成的订单可能有多个；物料需求计划类与物料信息类是一对多的关联关系，关联名是查看,因为一个用户的物料需求计划只有一个但是物料信息可能有多个；采购订单类与订单项类是多对多的关联关系，关联名是统计，因为采购订单有多个同时就有多个订单项类；采购订单类与供应商类是多对一的关联关系，关联名是接收，因为所有的订单最后都汇总在供应商类中；供应商类与物料信息类是一对多的关联关系，关联名是更新，因为一个供应商可以发布多个物料信息；供应商类与库存数量类是一对一的关联关系，关联名是查看，因为供应商只需通过一个表单就可以实现查看；库存数量类与仓库类是一对多的关联关系，关联名是更新，库存数量对应着多个仓库的物料信息。
6.5类图
7辅助模型的建立
7.1辅助模型的概念
对类图起到辅助作用，提供更详
升级会员 