软件工程高级开发技术读书报告

软件工程高级开发技术读书报告二

一．请阅读参考书1的第4-5章，围绕以下问题整理读书笔记，形成读书报告UML中定义了哪些主要类型的图？综述用例建模中如何对交互模型、结构模型、行为模型进行描述?

答：UML中主要定义了9种类型的图：用例图、活动图、时序图、类图、状态图、协作图、部署图、组件图、对象图。

●用例图

采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。参与者是系统的主体，表示提供或者接收系统信息的人或系统。下图是一个棋牌馆管理系统的用例图。

●活动图

活动图显示了系统的流程，可以是工作流，也可以是事件流。在活动图中定义了流程从哪里开始，到哪里结束，以及在这之中包括哪些活动。活动是工作流期间完成的任务。活动图描述了活动发生的顺序。

上图是一个ATM的活动图的例子。活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。此实例中这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。

●时序图

时序图表示了对象之间传送消息的时间顺序。每一个对象用一条生命线来表示—即用垂直线代表整个交互过程中对象的生命周期。生命线之间的箭头连线代表消息。时序图可以用来进行一个场景说明—即一个事务的历史过程。

上图为一个图书管理系统的时序图。

●类图

类图是以类为中心来组织的，类图中其他元素或属于某个类或类相关联。在类图中类用矩形框来表示，它的属性和操作分别列在分格中。关系用类框之间的连线来表示，不同的关系用连线上和连线端头处的修饰符来区别。下图为一个类图的例子。

●状态图

状态视图是一个类对象所经历的所有历程的模型图。状态由对象的各个状态和连接这些状态的变迁组成。每个状态对一个对象在其生命周期中满足某种条件的一个时间段建模。当一个事件发生时，它会触发状态间的变迁，导致对象从一种状态转化到另一种新的状态。与变迁相关的活动执行时，变迁也同时发生。

上图为一个图书管理系统的状态图。

●协作图

协作图对在一次交互中有意义的对象和对象间的链建模。对象和关系只有进行交互才有意义。在协作图中，直接相互通信的对象之间有一条直线，没有画线的对象之间不直接通信。附在直线上的箭头代表消息。消息的发生顺序用消息箭头处的编号来说明。协作图的一个用途是表示一个类操作的实现。协作图可以说明类操作中用到的参数和局部变量及操作中的永久链。当实现一个行为时，消息编号对应了程序中嵌套调用结构和信号传递过程。

上图为一个ATM取款机的协作图。

●部署图

部署图用来描述位于节点实例上的运行组件实例的安排，描述系统的实际物理结构。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配，图中表示了系统中的各组件和每个节点包含的组件，节点用立方体图形表示。下图为一个部署图的例子。

●组件图

组件图表示了系统中的各个组件。代码的物理结构用代码组件表示。组件可以是源代码、二进制文件或可执行文件。组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系。组件之间也存在着依赖关系，利用这种依赖关系可以方便地分析一个组件的变化会给其他组件带来怎样的影响。组件可以与公开的任何接口一起显示，也可以把它们组合起来形成一个包，在组件图中显示这种组合包。在C++组件图中，每个类有自己的体文件和头文件，因此框图中的每个类映射自己的组件。

上图为ATM客户机的C++组件图。显示类映射ATM显示组件，阴影组件称为包体，表示C++中显示类的体文件（.cpp）。无阴影组件称为包规范，表示C++类的头文件（.H）。组件ATM.EXE是个任务规范，表示处理线程。这里的处理线程是个可执行文件。组件用虚线连接，表示组件间的相关性。

●对象图

对象图是类图的一个实例，它描述了类图中类的特定实例以及某一时刻这些实例之间的特定连接。对象的图形符号使用了与类相同的图形符号，只是符号内部的表示内容不同。在短式对象图形符号中，矩形实线方框内的对象名下附加下划线，对象名后可接以冒号和类名，说明该对象所从属的类。

二．请阅读参考书2的第4-6章，围绕以下问题整理读书笔记，形成读书报告1.需求模型有哪些基本元素？需求建模有哪些方法？需求建模可以产生哪些模型类型？综述基于场景模型、基于数据模型和基于类的建模方法

2.综述面向流程的建模方法和工具，如何用相应的模型和方法来描述控制流、表达控制行为？

3.综述动态行为的模型构建，常用的行为建模工具有哪些？

答：1.（1）需求模型中的基本元素

●基于场景的元素

使用基于场景的方法可以从用户的视角描述系统。

●基于类的元素

每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类——具有相似属性和共同行为的事物集合。

●行为元素

基于计算机系统的行为能够对所选择的设计和所采用的实现方法产生深远的影响。状态图是一种表达系统行为的方法。

●面向数据流的元素

信息在基于计算机的系统中流动时会被转换，系统接受多种形式的输入；使用函数将其转换；生成多种形式的输出。

1.（2）需求建模方法

●结构化分析方法

一种考虑数据和处理的需求建模方法，其中处理将数据作为独立实体加以转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应标明当数据对象在系统内流动时处理如何转换数据。

●面向对象的分析

这种方法关注与定义类和影响客户需求的类之间的协作方式。

1.（3）（4)需求建模可以产生的模型类型，并综述它们的建模方法

●基于场景建模

基于计算机的系统或产品的成果可以用多种方式度量，但是用户的满意度是最重要的。如果软件工程师了解最终用户（和其他参与者）希望如何与系统交互，软件团队将能够更好的、更准确的刻画需求特征，完成更有针对性的分析和设计模型。因此，使用UML将从开发用例、活动图和泳道图形式的场景开始。

●基于数据建模

如果软件需求包括建立、扩展需求，或者具有数据库的接口，或者必须构建或操作比较复杂的数据结构，软件团队可以选择建立一个数据模型作为全部需求建模的一部分。

●基于类的建模

这种建模方式表示了系统操作的对象、应用于对象间能有效控制的操作（也称为方法或服务）、这些对象间（某种层次）的关系以及已定义类之间的协作。它的元素包括类和对象、属性、操作、类的职责协作者模型、协作图和包。

2、面向流程的建模方法和工具：面向流程的建模时当前应用最广泛的需求分析表达方法之一，数据流图及相关的图和信息可以补充UML图并提供对系统需求和流程的补充。工具有：SafeHome软件。

创建控制流模型、表达控制行为：有一类应用问题是事件驱动而不是数据驱动，这类问题产生控制信息而不是报告或显示信息，并且处理时非常注重时间和性能。这样的应用便需要控制流建模。它通过布尔值或条件的离散列表实现对事件或控制项的建模

3.动态行为的模型构建：动态建模的目标是生成每个类的状态图，与有穷状态机相类似的对目标产品进行描述。这种方式通过在可控项目标环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护。