系统分析与设计

1、系统分析与设计Parti:系统分析与设计概述系统：相互交互或相互依赖的组件集合所构成的一个整体分析：将复杂系统分解成小的、可以理解和可以的组成部分的过程设计：用一组模型元素描述满足系统需求和约束条件的模型的过程Part2： UML 和 RUP软件建模工具通常包括结构化建模工具和面向对象建模工具；结构 化建模工具包括数据流图DFD、软件结构图SSD和程序流程图PFD面向对象的建模工具为UML建模：用建模工具构建模型的过程系统模型包括结构模型（静态模型）和行为模型（动态模型）常用的uml建模工具包括rationalroe和tarumlUML为unifiedmodellanguage简写，是一种符合

2、工业标准的图形 化建模语言uml包括构造块，规则和公共机制构造块包括建模元素、关系和图规则包括命名，范围和可见性公共机制包括规格描述、修饰、公共分类和扩展机制建模元素包括结构元素、行为元素、分组元素和注解元素关系包括关联关系、依赖关系、泛化关系和实现关系图包括静态图和动态图，其中静态图包括类图、组件图和部署图。 动态图包括顺序图、协作图、状态图和活动图规则包括命名、范围和可见性公共机制包括规格描述、修饰、公共分类和扩展机制。其中用斜 体字体表示的类为抽象类就是一种修饰。扩展机制包括版型、标记值和约束RUP是一个迭代和递增的开发过程RUP的四个阶段:初始（先启）阶段、精化阶段、构建阶段和移交 （

3、产品化）阶段；对应四个阶段结束的里程碑分别是生命周期目标里程碑、生命周期架构 里程碑、初始可运行能力里程碑和产品发布里程碑；RUP的每个阶段包含一到多次迭代; 每次迭代包括业务建模、需求、分析设计、实现、测试和部署5个工作流。RUP工作流由角色、角色所参与的活动和活动所输出的工件组成， 工件包括文档、模型元素和软件模型依赖关系是单向的和临时的20.依赖关系的四种表现：A) ClaA中 某个方法的参数类型是ClaB；B)ClaA中某个方法的参数类型是ClaB的一个属性；C)ClaA中某个方法的实现实 例化 ClaB； D)ClaA中某个方法的返回值的类型是ClaB；泛化关系是由派生类指向基类的；

4、泛化关系是i-a的关系关联关系是一种结构关系，关联关系的可导航性和重复度(阶 元)，关联类的表达方式关联关系在设计阶段可以进一步精化成聚合关系和组合关系，聚 合关系的整体和部分不具有一致的生命周期，而组合关系中整体和部分之间有一致的生命周 期实现关系用于表达接口和实现该接口的类之间的关系，也可以表 示成接口和实现接口的组件之间的关系结构型元素中类由类名、属性和操作三个框组成，第一框不能省 略，第二框第三框都可省略，属性和操作不能放错位置或者交叉可见性由公有+、私有-和保护#三种符号表达类的属性的类型表达方式，类的操作的类型和参数列表表达方式对象通常由对象名：对象所属的类和属性值构成，而且对象名

5、要 加下划线三种重要的类：实体类、边界类、控制类接口可以用一个圆来表达，也可以用类的版型来表 达接口和抽象类都是不能实例化的，但是抽象类可包含部分实现， 接口可多重继承或扩展，但是有些面向对象的程序设计语言不支持抽象类的多重继承32 .参与者（actor）是一个与组织（或系统）外部的，与组织（或系统） 交互的角色用例描述了一系列活动，通过该系列活动，用例为参与者提供可 见的价值参与者和用例是关联关系活动图中的分支和合并；表示并发的分叉和联结，分叉和联结都 用同步条来表示活动图中的泳道用于表达责任区域；一个泳道通常用来代表一个 角色状态图用于表示一个系统或一个对象整个生命周期所经历的状态 和状态

6、迁移一个状态通常包括状态名、进入/退出条件和内部迁移状态迁移包括引起状态迁移的事件名、护卫条件和动作组成，动 作包括入口动作（Entry）、出口动作（E某it）和处于该状态所要执行的动作（Do）。描述对象之间交互的交互图包括顺序图和协作图（通信图）顺序图包括对象、生命线、控制焦点和消息四种元素包是把元素组织成组的机制组件是系统中物理的、可替代的部件，组件是逻辑元素的容器节点是系统运行时存在的物理元素，通常包括存储能力和处理能 力，节点是组件的容器，节点可以是处理器也可以是设备。组件分部署组件、工作组件和执行组件三种组件与接口之间可以是实现和依赖两种关系部署图中的连接指的是两个物理设备之间的耦合

7、，包括物理介质 和软硬件传输协议。Part3业务建模业务（buine）:一个组织通过组织内部为实现其价值通过资源的协作 而完成的事务业务模型是以组织之外视角来观察组织内部要素和过程的模型业务模型包含业务用例模型（业务用例图）和业务对象模型（活动 图、顺序图和状态图）业务用例图包含业务主角、组织边界和业务用例等模型元素Part4需求建模从业务建模到需求建模是从组织视角向系统视角转换，从组织提供 价值到计算机系统提供价值转换系统需求是系统必须满足的条件或具备的能力系统需求包含功能需求和非功能需求，功能需求用用例模型来建模， 非功能需求在需求的补充规约里载明将基用例中一段相对独立并且可选的动作，用扩

8、展（E某tenion） 用例加以封装，再让它从基用例中声明的扩展点（E某tenionPoint）上进行扩展，从而使 基用例行为更简练和目标更集中使用包含（Incluion）用例来封装一组跨越多个用例的相似动作 （行为片断），以便多个基（Bae）用例复用。用例的扩展关系与包含关系的本质区别是扩展用例可不被基用例执 行，而包含关系中，基用例必须执行包含用例才是完整的7.用例的泛化关系，子用例与父 用例的行为相似，子用例继承父用例的所有行为、结构和关系且子用例可以重载父用例的部分行为用例分包方式包括，按参与者、按主题、按开发团队和按发布情况 分包适合使用用例模型描述系统需求等场景：功能多，参与者多和

9、接口 多选择迭代用例的依据是用例的优先级，优先级高的用例在精化阶段 的早期进行分析和设计，优先级低的用例在精化阶段的后期迭代中进行分析和设计分析和设计所生成的模型应放置在逻辑视图中用例模型表达系统所应具备的功能，分析和设计模型表达了功能是 如何实现的4.分析机制是一种模式，这种模式包含了解决通用问题的通 用解决方案分析机制主要包括持久化、进程间通讯、进程控制和同步、事务管 理等用例分析的基本过程包括：寻找候选对象、描述对象间的交互和描 述类。候选对象可以用对象清单描述，对象间交互用交互图描述，分析类用类图描述寻找对象的步骤：找实体对象、边界对象、控制对象和生命周期对 象候选对象可能来自于业务对

10、象模型、原始需求的非规范描述和系统 用例描述面向对象设计的5个基本原则：LSP、OCP、SRP、ISP和DIP10.OCP的核心思想就是依赖接口而不要依赖与具体的类，LSP的思想 是子类可以替换父类11.ISP的核心思想就是避免定义功能众多的大接口，而是要定义小 的内聚性强的接口设计模式分为创建型模式、结构型模式和行为型模式单件模式(Singleton)保证一个类仅有一个实例，并提供一个访问 它的全局访问点；抽象工厂模式适用于创建多个产品族中的产品对象的场景。适配器模式(Adapr)是将一个类的接口转换成客户希望的另外一个 接口，Adapter模式使得原本由于接口不兼容而不能一起工作的类可以一起工作；代理模式为其 他对象提供一种代理以控制对这个对象的访问的机制。观察者模式(Oberver)定义对象间的一种一对多的依赖关系，当一 个对象的状态改变时，所有依赖他的对象都得到通知并被自动更新；职责链模式是使多个对 象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系的一种模式。软件体系结构通常用体系结构包图来表达子系统可以实现接口也可以依赖与其他接口子系统设计