软件建模与设计 复习

软件建模

类模型，状态模型，交互模型（用例，顺序，活动）

领域分析（主要是领域类），应用分析（应用交互，应用类，应用状态，这三个要按顺序建立）

第一章

控制复杂性的方法：分解，抽象，模块化，封装

面向对象=对象+类+继承+通信

面向对象系统的优点：系统更稳定，易理解，由更好的适应性，更高的可靠性（稳可适理）

面向对象系统的特性：标识（表示对象）、分类（类class）、继承、多态

UML特点：统一的标准、面向对象、可视化、独立于过程、概念明确（统面可独概）

第二章

类模型：描述系统内部对象的特征、对象之间的关系以及对象所属的每个类的属性和操作，捕获系统的静态特征。

UML类图：（类的名字首字母要大写，也可以使用中文，注意第三个是操作，不是方法，可以理解成是抽象的方法）

+，#，~或-表示public，protected，package或private

 

UML对象图：

 

区别是：类图的名称下方有下划线，并且对象的属性可以设置值：

 

依赖（调用方法，虚线）、关联（有关系，实线）、聚合（集体与个体，实线空心菱形）、组合（个体和组成部分，实线实心菱形）和泛化（子类，实线空心三角形） 强度依次增大 实现是虚线 空心三角形

依赖是偶然临时，关联是长期稳定

链接和关联：链接是对象之间的，关联是类之间的，也就是说链接是关联的实例

关联的多重性：

对应代码：

 关联端名：表示这个类在这个关联中扮演了什么角色，需要对应到代码中的属性名：

 

自关联：

 

 

 

关联类：

 

 

限定关联：

 

一个分发装置根据机器ID将信息传到多个机器上，这时是1:n的关系，但分发装置加上限定关联机器ID，此时就是1：1的关系了，注意限定关联是加在1的那一方的

泛化和继承：

继承是类的继承，在UML里叫泛化，用实线空心三角形表示

作用：支持多态，结构化描述对象，支持代码复用

正方形不能是矩型的子类，因为矩形有长宽，正方形只有边长

枚举

 

和泛化的区别：枚举的只是一系列的值，而泛化描述的是一系列结构化的对象，不能误用

多元关联

中间加一个菱形，把关联提升成类

 

抽象类：

 

多重继承的解决办法

 

委派：（一个对象将某个操作重定向给另一个对象，当要去完成某个任务的时候不是自己完成而是交给其他对象完成）

把继承的几个类按照某些东西进行划分，划分出几个共同的大类，让几个大类去组合原父类，然后原子类继承这个大类

 

委派加继承：

在上一个的基础上，找到几个重要的原子类，直接继承原父类

 

松耦合，高复用，程序更加灵活

第三章

状态模型：包括多个状态图

作用：描述对象响应外部激励而发生的操作序列（响应外部事件，发生一系列操作）

状态：对象生命周期中的一个条件或状态，在此期间对象将满足某些条件、执行某些活动或等待某些事件

迁移：从一个状态到另一个状态的瞬时变化

包括：

源状态 事件触发器 警戒条件：为了让迁移条件发生而必须为真的布尔表达式

效应（动作）

目标状态

事件：

某人在某个时刻发生的事情

状态图的画法

 

 

嵌套状态：同一迁移用于许多状态时要用嵌套

 

并发：类的聚合关系，到状态图中就有并发

 

类模型和状态模型的关系

状态模型详细描述了类模型中对象所允许的变化序列。（对象状态变化的序列） 状态图描述了某个给定类的对象的全部或部分行为。（对象的行为）

概要：包含类的对象的所有行为，以及他状态变换的序列

可以根据类模型来分解状态模型

第四章

交互模型：描述对象要如何交互才能产生有用的结果，描述多个对象的整体行为

类型：

用例模型 描述系统如何与外部参与者交互。 用于捕获功能性需求。 顺序模型 显示一组对象之间随时间变化所交换的信息。 用于描述系统用户观测到的行为序列。 活动模型 通过活动来描述系统的行为。 与流程图相似，可以用来表示控制流和数据流

和状态图的区别：状态图是单个对象中不同的状态，强调动作导致的状态的变换（结果），活动图是系统内部，强调了活动的顺序和条件控制（动作，动作的过程），是活动到活动的控制流

用例模型

用例：系统提供的功能，通过系统和参与者交互实现

参与者：与系统进行交互的外部实体

用例描述

用例

参与者

主事件流：（要写参与者干了什么，然后系统做出了什么反应）

三种用例关系

包含：类似必要的步骤

扩展：可选步骤

泛化：父子关系，类似于用例的种类

用例关系准则

不要过度使用用例关系。 不要将用例关系用到编程中

顺序模型

场景

系统在某个特定的执行期内所发生的一系列事件

 

顺序图：

显示对象之间交互的图，这些对象是按时间顺序排列的，强调交互以及消息的时间顺序

画法

把参与交互的对象或角色放在图的上方，延水平轴方向排列。 发起交互的对象或角色放在左边，较下级对象或角色依次放在右边。 把对象发送和接收的消息沿垂直轴方向按时间顺序从上到下放置。

 

准则

至少为每个用例编写一种场景。 把场景抽象成顺序图。 划分复杂的交互。 为每种错误条件绘制一张顺序图。

活动模型

活动图与顺序图的区别

顺序图强调的是从对象到对象之间的控制流。 活动图强调的是从步骤（活动）到步骤的控制流。

活动

表示某流程中的任务的执行，可以表示某算法过程中语句的执行。

动作状态

是原子的，不能被分解，没有内部转移，没有内部活动。 动作状态的工作所占用的时间是可忽略的。 目的是执行进入动作，然后转向另一个状态。 可被视作活动状态的特例。

活动状态

不是原子的，可分解。（例如下图的执行订单可以拆成买入卖出等等活动） 活动状态的工作的完成需要一定的时间。

 

泳道

活动图中的区域划分

根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。 一个泳道可能由一个或多个类来实现

 

准则

不要误用活动图 让图保持平衡 注意分支和条件 注意并发活动

第五章 软件系统分析

软件开发阶段：

系统构思：构思一项应用并系统地描述临时性需求。 分析：通过构造模型来更深入地理解需求。（领域分析，应用分析） 系统设计：设计系统架构。 类设计：设计系统的真实模型及相关操作的算法。

实现：将设计转换成编码及数据库结构。 测试：确保应用满足实际需求。 培训：帮助用户掌握应用程序。 部署：安装应用软件，替代或连接已有系统。 维护：保证应用程序的长期有效性。

软件开发生命周期：

瀑布式开发：

需求、分析、设计、编码、测试

迭代式开发：

项目开发被划分成无数次迭代，每次迭代都包括了定义、需求分析、设计、实现与测试，所以有许多的迭代版本

问题阐述（为谁？什么问题？什么地方？什么时候？为什么需要？怎么工作）

应用程序为谁而做？ 应用程序解决的问题？ 应用程序用在什么地方？ 什么时候需要用到？ 为什么需要用它？ 应用程序如何工作？

系统分析

分析描述对象的三个方面：类模型（分析对象的静态结构）。状态模型（分析对象的生命周期），交互模型（分析对象之间的交互）

分析的两个阶段：

领域分析：分析问题的真实本质。 应用分析：从应用的角度来分析系统。

领域模型

构建领域类模型：

描述真实世界的类以及他们之间的关系，优先级高于状态模型和类模型：

静态结构容易定义； 较少依赖应用程序的细节； 解决方案演化时更稳定；

1.寻找类

 

清除虚假的类：冗余类，无关类，定义模糊的类，对象的属性，操作（方法），角色，软件实现中用到的结构，派生类

2.数据字典

解释建模元素的名字

3.寻找关联

寻找类之间的关系（比如人需要钱，我写作业等等）

原则：

如果删除关联中的一个类，则应删除该关联； 删除问题领域之外或与系统实现有关的关联； 关联应描述问题的结构特性，而非临时事件； 将三元关联分解成二元关联； 忽略派生关联（可从其他关联推演得到的关联，关联名前加“/”表示派生关联）； 给关联适当的命名；

适当地增加关联终端名； 适当地使用限定关联（带有限定符的关联）； 指定关联端的多重性； 增加可能被遗漏的关联； 不必太严格地区分聚合、组合和普通关联。

4.寻找属性

首先获取最重要的属性，以后再考虑细节； 避免在分析阶段为实现阶段考虑属性； 忽略派生属性； 需要寻找关联属性。

原则：

一个元素可以是属性，也可以是独立的类，应视情况而定； 若属性值依赖于特定上下文，则应使用限定符； 若名称（Name）依赖于上下文，则可能应建模成限定符，反之则应建模成属性； 不要把对象的标识符建模成属性

注意某些属性是属于关联的，而不是属于类的； 若某属性描述的是外部不可见的对象内部状态，则在分析阶段不应考虑； 在分析阶段忽略次要属性； 不要把无关属性整合在一起； 布尔属性可能扩展为枚举更好。

5.使用继承组织和简化类

1.将现有类的公共部分泛化为类（自下而上） 如：将远程转帐和现金转帐泛化为转帐。 2.将现有类特化为多个子类（自上而下）

原则

慎用泛化； 某些时候枚举比泛化更合适； 慎用多重继承； 可以考虑泛化关联类； 适当的泛化层次。

第六章

应用分析

1.创建交互模型

步骤：（就是画用例图，活动图和顺序图）

确定系统边界：应用程序的准确范围，把系统看成内部细节被隐藏的，可与外界交互的黑盒

用例图：

寻找参与者 寻找用例

顺序图：

寻找初始和终止事件 准备普通场景 增加变化和异常场景 寻找外部事件

活动图：

编制复杂用例的活动图

组织参与者和用例（使用泛化、包含、扩展等关系对用例进行组织） 检查领域类模型

2.应用的类模型

应用类界定了应用程序本身，是面向计算机的，并且扩展了领域类模型

 

步骤：

1.确定用户界面 2.定义边界类

（边界类就是内外部进行交互的类，可以将传输信息在内部系统之间往来转换，（如表单，对话框，菜单等等））

主要作用是将系统和外部进行阻隔，并且传输操作内外部的信息

3.确定控制器

一种管理应用程序内部控制权的主动对象

4.检查交互模型

类是否能够满足交互的需要？ 是否有合适的控制器来控制交互行为？ 交互模型内的导航（流程流转）是否合理？

应用状态模型：

用多个状态来确定应用类。 使用交互模型来寻找类的事件。 用状态图为每个类组织许可的事件序列。 检查状态图，确保公共事件的匹配。 用类和交互模型检查状态图，确保一致。

第七章

系统设计（包括系统设计和类设计）

 

系统设计步骤

估算系统性能：大致的估算，确定软件系统是否可行 制定复用计划：主要包括使用现有事务和创造新事务进行复用，事务主要包括模型，类库，框架等等 将系统划分成子系统：是一组相关的类、关联、操作、事件和约束，和其他子系统之间存在接口交互，通过提供的服务进行识别

包括水平拆分和垂直拆分

确定问题内部的并发性：必须是并发活动的对象，使用状态模型进行识别：两个对象在不交互的情况下，可以在同一时刻接收事件，则该对象是并发的，不交互的情况下，可以同一时间发生。 配置子系统的硬件： 管理数据存储 处理全局资源：确定资源的访问控制机制

选择软件控制策略：外部，内部流程控制 处理边界条件：系统初始化，终止，失效 设置权衡优先级 选择架构风格：批处理，连续型转换，交互式，动态仿真，实时系统，事务管理器

类设计

 

填补高层需求和低层服务之间的鸿沟； 用操作实现用例； 设计对象和方法 定义操作的算法； 向下递归，设计支持更高层的操作； 重构模型以实现更清晰的设计；

优化数据访问路径； 实现具体的行为； 调整类结构以便实现继承； 组织类和关联。

类的抽象层次，概念层，说明层，实现层

 

抽象类和接口

实现接口使用虚线加空心三角

继承抽象类使用实线加空心三角

面向对象的基本设计原则：

开闭原则：

一个模块在扩展性方面应该是开放的，在更改性方面应该是封闭的。

使用接口进行封装； 采用抽象机制； 使用多态技术。

Liskov替换原则：子类必须能够替换掉它们的基（父）类型，否则继承关系就是不正确的。

依赖倒置原则：依赖关系应尽量依赖接口（或抽象类），而不是依赖具体类。即依赖抽象而不是具体。

最好的是，依赖一个接口，然后这个接口被一个抽象类实现，然后具体类再继承这个抽象类

 

接口分离原则：使用多个专门的接口比使用单一的通用接口要好。即一个类对另一个类的依赖应该表现成依赖尽可能小的接口。

不使用接口分离会导致接口污染：为接口增加了不必要的职责，被迫实现不必要的方法的维护

注意可以多重实现接口

第八章 系统实现

实现建模：

实质是翻译设计的工作。 应是简单、甚至是机械的。 会增加细节，但只影响程序的一小部分

目的：让分析和设计出来的模型变成现实

操作：

微调类：

拆分类 合并类 拆分/合并属性 提升属性/降低类

微调泛化关系：

编码前微调类之间的泛化关系

实现关联：

确定关联的单项双向，以及关联类，组合聚合

准备好测试：

准备单元，集成，系统

数据库建模：

实现类

把类映射乘表，属性映射成列

 

实现关联

多对多：两个类各做一张表，然后加个id属性，再做一张id映射的表

 

一对多：两个类各做一张表，然后再多的一方加上一的一方的主键作为外键

一对一：各做一张表，随便选一方加外键就可以了

 

实现泛化

父类子类每个都单独画一张表，每张表上的主键名字不相同，但是拥有同个含义

实现标识

对象标识：增加Id作为主键

值标识：值的组合标识