软件开发是由系统构思、需求分析、系统设计、编码实现、系统测试、系统培训、系统部署和系统维护等一系列定义良好的阶段构成的,每个阶段都有不同的目标、输入和输出,整个过程应该是无缝的,在整个开发过程中,要使用相同的概念和表示方法。
UML(统一建模语言,Unified Modeling Language)是一种面向对象的建模语言,采用图形表示法来表示OO的概念。通过UML,可以构建一种应用模型,并在设计过程中增加细节。从分析到设计再到实现使用的是相同的无缝表示法,这样一个开发阶段增加的信息就不会在下一阶段中丢失了。
需求分析的过程是将企业业务模型到企业信息模型的映射的过程,实现从业务模式向信息模型的转变、业务需求向信息功能的映射、企业基础数据向企业信息的抽象,通过抽象和建模,将企业业务实体抽象成为信息对象、业务运作模式抽象成为信息对象的属性和方法,建立面向对象的企业信息模型。
UML通过构造模型来更加深入地理解需求,分析的目标就是指明必须实现什么的规格说明,它描述了系统的行为、特性或属性,是在开发过程中对系统的约束(而不是如何完成这些内容)。
需求是开发者和用户交互的一个过程,任何一方的不投入都会导致项目的失败。由于售前咨询的定位,必然存在着客户沟通和客户合作态度的问题(再者用户不是专业人士),因而开发者需要以积极的态度告诉客户需求开发的方法,以获取客户的支持。
3.1 软件需求层次
软件需求包括三个不同的层次——业务需求、用户需求和功能需求,也包括非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求,在项目视图与范围文档中予以说明。用户需求描述用户使用产品必须要完成的任务,可使用用例文档或场景脚本予以说明。功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。
无论哪个层次的需求,其目的都是为了说明系统要完成的内容,可采用不同的模型进行分析和展现:
• 业务需求,通过业务建模(即采用业务架构理解客户业务),对企业目前的业务流程进行描述和评估
• 用户需求,重心就是如何收集用户的需求上,即确定角色和角色的用例,通过用例和场景说明客户的工作内容和信息化需求
• 功能需求,依赖于用户需求,是用户需求在系统上的一个映射(Mapping)。在这个层次上,为用户做一个软件原型是一个不错的方法
3.2 UML与相关模型
UML是一种图形化的面向对象建模语言,通过不同的图形表示来捕捉系统静态结构和动态行为的信息,建立起对象模型。
考虑到售前咨询过程更多的是理解和阐述客户需求,因而可以将注意力聚焦在用例和活动图上,即通过层次化的用例(Use Case)模型和时序模型描述企业范围内各种应用的功能需求;通过逐级分解的活动模型(业务过程、子过程、活动)来细化描述业务。当然也可适当考虑类模型的分析,借此说明企业相关的实体和关系。
3.2.1 UML概述
UML的概念包括了UML语义(Semantics)和UML表示符(Notation)两个部分,UML语义定义了三种模型(类模型、状态模型和交互模型),UML表示符提供了完整的语义定义,UML的表示符包括了下面的几种主要的图:类图、用例图、顺序图、协作图、状态图、活动图和部署图。
三种模型从不同的视角来描述系统:
• 类模型。描述了系统内部对象及其关系的静态结构——它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。
• 状态模型。描述的是对象当中与时间相关的内容,如表明变化的事件,以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的,一个类有一张状态图,每张状态图都包含了一些重要的时序行为。
• 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上,用例描述的是系统如何与外部参与者交互(用例表示功能片段,有助于捕获非形式化的需求);顺序图提供更多的细节,显示交互的对象,以及对象交互的时间顺序;活动图提供最详尽的细节,以显示某次活动中处理步骤之间的控制流。
3.2.2 用例模型
用例是从用户的角度看待系统,用例标识系统的功能,并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成:
• 参与者(Actor)。系统的直接外部用户——直接与系统通信的一个对象或一级对象,但并不是系统的一部分。
• 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能,每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起,包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。
• 用例图。UML用一套图形表示法来总结用例,如下图。其中矩形包含了系统的用例,参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者,参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。
<此节也需要重新编写>3.2 UML与相关模型
UML是一种图形化的面向对象建模语言,通过不同的图形表示来捕捉系统静态结构和动态行为的信息,建立起对象模型。
考虑到售前咨询过程更多的是理解和阐述客户需求,因而可以将注意力聚焦在用例和活动图上,即通过层次化的用例(Use Case)模型和时序模型描述企业范围内各种应用的功能需求;通过逐级分解的活动模型(业务过程、子过程、活动)来细化描述业务。当然也可适当考虑类模型的分析,借此说明企业相关的实体和关系。
3.2.1 UML概述
UML的概念包括了UML语义(Semantics)和UML表示符(Notation)两个部分,UML语义定义了三种模型(类模型、状态模型和交互模型),UML表示符提供了完整的语义定义,UML的表示符包括了下面的几种主要的图:类图、用例图、顺序图、协作图、状态图、活动图和部署图。
三种模型从不同的视角来描述系统:
• 类模型。描述了系统内部对象及其关系的静态结构——它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。
• 状态模型。描述的是对象当中与时间相关的内容,如表明变化的事件,以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的,一个类有一张状态图,每张状态图都包含了一些重要的时序行为。
• 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上,用例描述的是系统如何与外部参与者交互(用例表示功能片段,有助于捕获非形式化的需求);顺序图提供更多的细节,显示交互的对象,以及对象交互的时间顺序;活动图提供最详尽的细节,以显示某次活动中处理步骤之间的控制流。
3.2.2 用例模型
用例是从用户的角度看待系统,用例标识系统的功能,并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成:
• 参与者(Actor)。系统的直接外部用户——直接与系统通信的一个对象或一级对象,但并不是系统的一部分。
• 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能,每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起,包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。
• 用例图。UML用一套图形表示法来总结用例,如下图。其中矩形包含了系统的用例,参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者,参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。