面向对象指导规范文档格式.docx

面向对象指导规范文档格式.docx

《面向对象指导规范文档格式.docx》由会员分享，可在线阅读，更多相关《面向对象指导规范文档格式.docx（66页珍藏版）》请在冰豆网上搜索。

公司实行董事长监管下的总经理负责制，总经理和办公室负责协调生产部门、销售部门、技术部门、质量部门、人事部门和财务部门之间相互合作。

整个ERP系统将上述部门连接成一体，共同协作完成整个公司的产品从进料到生产、到销售，最后和财务挂接整个过程。

系统实施由总经理牵头，各部门主管领导负责，部门业务员配合系统研发人员来完成。

图1-1公司组织机构图

Fig1-1DiagramoftheCompany'

sOrganizationalStructure

1.3系统业务流程（活动图）

经过前期调研分析和综合其它各方面相关理论知识，给出整个ERP系统的业务流程图如下图1-2所示：

整个ERP系统的开发主要围绕上述业务流程进行开发，开发过程采用面向对象的开发技术，具体开发过程见下面的章节。

1.4系统功能模块

根据上述业务流程，整个ERP系统抽象出以下几个功能模块，如图1-3所示。

下面模块划分只是抽象意义上的划分，各模块之间需要共享数据，相互协作，完成整个系统流程，单一事物功能模块间是相互独立的。

图1-2ERP系统流程

Fig1-2theWorkflowofERPSystem

图1-3系统功能模块

Fig1-3FunctionModelsofSystem

2系统需求分析

2.1需求陈述

通常，需求陈述的内容包括：

问题范围，功能需求，性能需求，应用环境及假设条件等。

总之，需求陈述应该阐明“做什么”而不是“怎样做”。

它应该描述用户的需求而不是提出解决问题的方法。

应该指出哪些是系统必要的性质，哪些是任选的性质。

应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活性。

对系统性能及系统与外界环境交互协议的描述，是合适的需求。

此外，对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求。

下面以北鑫星ERP系统中的销售管理模块为例说明如何进行系统需求陈述。

根据调研分析得知，北鑫星ERP系统销售管理模块共需要完成5项中心任务，即：

客户管理，订单管理，发货单管理，销售策略管理，销售计划管理和售后服务管理。

每项任务具体描述如下：

1．客户管理

客户管理主要提供客户信息的录入，修改和查询服务，同时为订单管理和售后服务管理提供信息依据。

2．订单管理

根据客户订购的产品生成产品订单合同，在发货之前可以修改订单合同，合同状态为未完成。

在发货之后，订单合同完成。

该模块需要提供订单的生成，修改和查询，以及订单状态的修改。

3．发货单管理

在收到货款之后，填写发货单，配货。

该模块需要提供发货单的生成，修改和查询，以及发货单状态的修改。

4．优惠策略制定

第一种优惠方式是客户如果购买的产品超过一定数量，客户再购买产品的时候，对产品的单价给出一定的优惠；

第二种优惠方式是年终对所有客户购买的产品进行统计，如果超过一定数量，将以现金的形式给客户以奖励。

5．销售计划管理

每年根据往年同期制定当前的销售计划。

该模块主要提供计划的制定，修改和查询服务。

6．售后服务管理

产品在使用过程中出现问题后，记录产品的相关信息包括使用的客户信息，产品自身信息以及处理方案。

系统任务确定之后，下面的工作就是进行系统分析。

面向对象的分析的主要任务是分析问题领域，找出问题解决方案，发现对象，分析对象的内部构成和外部关系，建立软件系统的对象模型。

分析问题领域是软件系统开发的一项基本工作，是项目开发之初必须首先进行的重要工作。

分析问题领域的结果是对问题领域的清晰，精确的定义，明确目标系统将做什么。

分析问题领域的主要任务是：

对问题领域进行抽象，提出解决方案；

对未来的系统进行需求分析，确定系统的职责范围，功能需求，性能需求，应用环境及假设条件等。

实施面向对象分析的一般步骤如下：

1．分析用户需求，建立UseCase并通过用例图来描述用户的需求。

2．通过建立域模型以识别类与对象，从而识别系统中的各种对象。

3．确定对象的内部特征，从而定义出各个属性与服务，以进一步细化类的结构。

4．识别对象之间的关系并使用设计模式对类的结构进行优化和改造。

5．获得对象之间的行为关系，绘制出各种动态图形（顺序图、协作图、状态图等）。

2.2UseCase建模

2.2.1定义活动者

根据销售管理模块的需求可以确定4个活动者，即销售业务员，企业管理者，生产管理模块和库存管理模块。

销售业务员使用销售管理模块记录客户信息，填写订单合同，填写发货单和记录售后信息，以及查询相应的信息。

企业管理者使用销售管理模块查询订单信息，发货信息和客户信息，制定销售优惠策略，制订销售计划。

生产管理模块是销售管理模块的外部系统活动者，从销售管理模块获得订单信息和销售计划。

库存管理模块是销售管理模块的外部系统活动者，从销售管理模块获得订单信息和发货信息。

工程管理模块是销售管理模块的外部系统活动者，为销售管理模块提供物料信息

2.2.2UseCase图（+用例描述）

根据系统需求分析，结合上节系统活动者的定义分析，得到系统销售管理模块的六个用例如下：

1．客户管理用例

2．订单管理用例

3．发货单管理用例

4．销售策略管理用例

5．销售计划管理用例

6．售后管理用例

结合活动者和用例得到销售管理模块的用例图如下图3-1所示。

图2-1销售管理UseCase图

Fig3-1UseCaseforSalesManagement

3系统架构设计

软件的系统架构是指通过某种特定的技术平台，完成软件系统整体功能的开发过程。

也可以通俗地理解为：

总体设计和总体结构布局。

一般而言，软件系统架构有两个要素：

1．它是一个软件系统从整体到部分的最高层次的划分。

2．建造一个系统所做出的最高层次的，以后难以更改的，商业和技术的决定。

3.1架构设计目标

软件架构设计要达到如下的目标：

1．可行性（Feasible）。

架构具有可行性是架构设计的基石。

2．可靠性（Reliable）。

软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

3．安全行（Secure）。

软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

4．可定制化（Customizable）。

同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

5．可扩展性（Extensible）。

在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

6．可维护性（Maintainable）。

软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。

一个易于维护的系统可以有效地降低技术支持的花费。

7．可升级性（Scalable）。

软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。

只有这样，才能适应用户的市场扩展得可能性。

8．客户体验（CustomerExperience）。

软件系统必须易于使用。

软件的最终用户很可能是不具有计算机专业技术的人员。

3.2系统架构设计

下面我们将根据架构设计原则和信息系统原理来建立系统的架构设计模型。

将信息系统中比较关心的对象分层，可分为三层：

用户界面层、业务层、数据访问层（如下图3-2所示），再把各层中的一些公共部分提出来：

权限管理、异常处理，这样得到包图如图3-2-1所示：

图3-2系统体系架构图

Fig3-2TheDiagramofSystemArchitecture

图3-2-1销售管理模块包图

Fig3-2-1PackageDiagramofSalesManagementModel

1.用户界面包

用户界面包的职责是：

（1）与用户的交互，接收用户的各种输入以及输出各种提示信息或处理结果。

（2）对于输入的数据进行数据校验，过滤非法数据。

（3）向业务处理对象发送处理请求。

用户界面包图展开如图3-3所示：

图3-3用户界面包展开图

Fig3-3PackageDiagramofUsersInterface

用户界面包包含的类见图2-4：

图3-4用户界面类图

Fig3-4ClassDiagramofUsersInterface

2.业务逻辑包

业务逻辑包的职责是：

（1）实现各种业务处理逻辑或处理算法。

（2）验证请求者的权限。

（3）向数据访问对象发送数据持久化操作的请求。

（4）向用户界面层返回处理结果。

业务逻辑包图展开如图3-5所示：

图3-5业务逻辑包图展开

Fig3-5PackageDiagramofBusiness

业务逻辑包包含的类见图3-6：

图3-6业务逻辑类图

Fig3-6ClassDiagramofBusiness

3.数据访问包

数据访问层的职责是：

（1）实现数据的持久化操作。

（2）实现事务处理。

数据访问包图展开如图2-7所示：

图3-7数据访问包图展开

Fig3-7PackageDiagramofDataAccess

数据访问包包含的类见图3-8：

图3-8数据访问类图

Fig3-8ClassDiagramofDataAccess

对于每一个业务处理中需要持久化操作的对象都可以对应为一个数据库访问对象，在很多业务处理中需要请求多个数据库访问对象来进行数据的读写操作，而这些操作又必须在同一个事务中，这时需要用同一个数据库连接对象来进行统一的事务处理。

这里的数据库连接类的创建用到了单件（Singleton）模式，保证一个类仅有一个实例，一个客户在同一时刻只能用一个数据库连接对象。

4.权限管理包

权限管理的主要职责是：

（1）验证请求者的请求权限。

（2）提供请求者的权限列表。

权限管理包图展开如图3-9所示：

图3-9权限管理包图展开

Fig3-9PackageDiagramofAccessAuthorization

权限管理包包含的类见图3-10：

图3-10权限管理类图

Fig3-10ClassDiagramofAccessAuthorization

5.异常处理包

异常处理的职责：

（1）汇报运行时的详细异常信息。

（2）记录异常处理日志。

异常处理包图展开如图3-11所示：

图3-11异常处理包图展开

Fig3-11PackageDiagramofExceptionProcessing

异常处理包包含的类见图3-12：

图3-12异常处理类图

Fig3-12ClassDiagramofExceptionProcessing

因为异常处理类型比较多，如：

系统异常、数据库异常、业务逻辑异常等，针对不同类型的异常处理方式也容易变，如：

显示错误，记录文本日志，记录数据库日志等，所以这里使用了桥接（Bridge）模式来实现，使各部分的变化比较独立。

3.3系统架构类图

将包图展开，得到类图，它是架构的静态结构图，表达了各个类之间的静态联系。

北鑫星ERP系统中的销售管理模块系统架构类图如下图3-13所示。

图3-13系统架构类图

Fig3-13ClassDiagramofSystemArchitecture

4系统详细设计

本部分设计主要涉及软件系统的动态建模和系统类图的详细设计。

软件系统的动态模型分为交互模型和活动状态模型，其中的交互模型主要由顺序图和协作图构成，活动状态模型主要包括活动图和状态图。

通过为软件系统项目建立动态模型，从而产生体现系统动态行为的可视化分析结果——包括对象的时间特性和对象为完成目标任务而相互进行通信的机制、对象行为的改变和状态变化情况，以及对象可能出现的各种活动状况等信息。

4.1系统交互图

4.1.1系统架构类交互图

系统架构类的工作流程：

1.用户界面对象在接收了用户的输入请求后，向业务代理对象发送处理请求。

2.业务代理对象接收到请求后，向权限管理对象发送验证权限请求。

3.权限管理对象验证权限后将验证结果返回给业务代理对象。

4.业务代理对象根据验证结果进行以下处理：

对于不符合权限的请求则返回提示信息；

对于符合权限的请求，则将请求转发给业务对象。

5.业务对象进行业务处理。

对于业务处理中的数据持久化操作，通过访问数据库访问对象进行操作，期间的任何异常都交给异常处理对象处理。

最后返回处理结果信息给业务代理对象。

6.业务代理对象将处理结果信息返回给用户界面。

系统架构类的交互图如图4-1所示：

4.1.2活动者与模块间的交互

与销售管理模块进行交互的活动者（角色）主要包括销售业务员和企业管理者。

销售业务员和企业管理者与销售管理模块的交互图如下图4-2和图4-3所示：

图4-1系统架构类的交互图

Fig4-1InteractiveDiagramofSystemArchitectureClass

图4-2销售业务员与销售管理交互图

Fig4-2InteractiveDiagrambetweenSalesmanandSalesManagement

图4-3企业管理者与销售管理交互图

Fig4-3InteractiveDiagrambetweenBusinessAdministrationandSalesManagement

下面对销售业务员、企业管理者参与销售管理活动的情况进行动态建模，由于篇幅限制，在此仅以销售业务员与销售管理模块中的订单管理进行时序图、协作图、状态图和活动图的建模。

定单管理主要涉及：

1．根据客户订购的产品生成产品订单合同，在发货之前可以修改订单合同，合同状态为未完成。

2．提供订单的查询功能（按订单编号、订单生成时间、客户名称、操作员编号等查询）。

销售业务员创建订单合同的时序图如下图4-4所示。

图4-4销售业务员创建订单合同的时序图

Fig4-4TimingDiagramforSalesmanMakingOrder

4.1.3系统协作图

交互图用来说明系统如何实现一个用例或用例中的一个特殊场景。

UML提供两类交互图：

时序图和协作图。

时序图按时间顺序描述系统元素之间的交互；

协作图则按照时间和空间顺序来描述系统元素之间的交互。

根据上节描述的销售业务员创建订单合同的时序图，给出销售业务员创建订单合同的协作图如下图4-5所示。

4.1.4系统状态图

状态图是通过类对对象的生命周期建立模型来描述对象随时间变化的动态行为。

状态图显示了一个状态机，它基本上是一个状态机中的元素的一个投影，也就意味着状态图包括状态机的所有特性。

在订单管理模块中，主要有创建订单合同、修改订单合同状态、查询订单合同3种状态，这三种状态完成过程非常相似，所以下面仅给出销售业务员创建订单合同的状态图如下图4-6所示。

图4-5销售业务员创建订单合同的协作图

Fig4-5CollaborationDiagramforSalesmanMakingOrder

图4-6销售业务员创建订单合同的状态图

Fig4-6StateDiagramforSalesmanMakingOrder

4.1.5系统活动图

活动图是描述活动是如何协同工作的。

当一个操作必须完成一系列事情，而又无法确定以什么样的顺序来完成这些事情时，活动图可以更清晰地描述这些事情。

在订单合同管理模块中，主要涉及销售业务员的活动。

销售业务员首先登录系统，然后查看客户订购信息，根据需要生成订单合同；

还可以对未发货的订单合同进行修改；

同时可以查询订单合同相关信息等活动。

完成活动后退出系统，下面给出销售业务员的活动图，如下图4-7所示。

图4-7销售业务员在订单管理模块的活动图

Fig4-7ActivityDiagramforSalesmanMakingOrder

4.2业务逻辑对象类设计

4.2.1发现业务逻辑类

本小节的主要任务是对系统架构类图中的业务逻辑类进行设计，由系统分析中的UseCase交互图我们可以发现业务逻辑类包括客户类，订单类，发货单类，销售策略类，销售计划类和售后类。

根据UseCase交互图中的消息找到对象类相应的方法。

4.2.2业务逻辑对象类图

系统业务逻辑对象类图如下图4-8所示。

图4-8销售管理对象类图

Fig4-8ObjectClassDiagramforSalesManagement

从上面的对象类图中我们发现，这些对象类中都有创建，维护和查询三个类似的方法，尽管返回值不同，这样我们就可以把这些方法抽象出来做成接口。

优化后的对象类图见图4-9。

图4-9优化的销售管理对象类图

Fig4-9OptimalObjectClassDiagramforSalesManagement

4.3数据库设计

关系型数据库是目前应用最广泛的数据库。

既然是面向对象系统设计，数据库设计当然也要是面向对象的。

现在要考虑如何对类进行持久化操作，即如何将对象类映射到关系数据库的二维表。

目前可以采用数据库建模工具来实现，象PowerDesigner、Rose等。

4.3.1ER图

客户类，订单类，售后类，销售单类，销售计划类和销售策略类都是基础类，可以直接映射为一个表。

架构设计中的操作员类是一个用于管理系统操作角色的类，也要直接映射为一个表。

销售管理模块的ER模型图见图4-10。

图4-10销售管理模块ER图

Fig4-10E-RDiagramofSalesManagement

4.3.2物理表结构图

将销售管理ER模型中的实体转换为物理表，得到物理表结构如下：

Customer（客户信息表）

表4-1（Table4-1）

主键

字段名称

数据类型

长度

字段说明

1

CustomerID

varchar

20

客户编号

CustomerName

30

客户名称

CustomerType

客户类别

SalesmanID

10

业务员编号

Country

国家

Province

省份

City

城市

Address

50

地址

Contract

联络人

Tel

电话

Fax

25

传真

ShippingID

送货地代号

ShippingCountry

送货地国家

ShippingProvince

送货地省份

ShippingCity

送货地城市

ShippingAddress

送货地地址

ShippingContract

送货地联络人

ShippingTel

送货地电话

ShippingFax

送货地传真

CO（订单表）

表4-2（Table4-2）

COID

订单编号

CODate

datetime

订单日期

nvarchar

DelveryDate

送货日期

Item

物料编号

COQty

decimal（14,2）

订货数量

Currency

币种

Price

decimal（18,4）

单价