软件设计

第一章复杂性 1.软件复杂性的原因： 问题域的复杂的性； 管理费用开发过程的困难性 软件中随处可能出现的灵活性 描述离散系统行为困难。 2.控制系统复杂性的方法： 分解方法（算法分析和面向对象分解）、抽象的方法 3.复杂系统一般具有如下属性： 层次结构：复杂系统的架构是它所有的组件以及这些组件之间的层次结构的函数。 相对本原（primitives）：组成系统的基础组件决定于观察者 分离关注：组件内与组件间的联系分离开来。 共同模式：复杂系统具有共同的模式，复用。 稳定的中间形式：随着时间的推移，系统变得稳定，同时为构建更为复杂系统而作为稳定的中间形式，复杂系统变得更加复杂。 第二章面向对象基础 1.面向对象技术的三个特征：（或基本机制） 封装，隐藏内部实现 继承，复用现有代码 多态，改写对象行为 2.面向对象技术的四个特征：（或基本机制） 抽象，分离变与不变 封装，隐藏内部实现 继承，复用现有代码 多态，改写对象行为 3.Java中抽象类与接口的联系与区别 相同点：1）都有未实现的方法；2）都不能用于创建对象（实例）；3）一个具体的类继承或实现它们时，需要对未实现的方法提供具体实现。 不同点：1）接口中的方法都是未实现的，而抽象类中可以有实现的方法；2）接口中没有构造函数和属性，但抽象类中有；3）一个类只能继承一个抽象类，但可以实现多个接口。 4

　　以使用为中心的软件设计是一种流线型但系统化的开发方法，用来设计能很好满足用户真正需求的软件，即不仅更加有用和易于使用，而且简单且易于建造。这种设计方法适应了当前软件开发面临巨大压力的现实。通过几个简单而功能强大的模型，它提供了一种快速理解用户的有关特征、用户执行任务时的工作意图及其所需系统支持的手段。其方法和模型几乎可以用于任何一种软件开发生命周期（SDLC）模型，可以被结合到任何一种现代开发实践中，包括像统一建模语言（UML）这样的各种面向对象（OO）的方法中。以使用为中心的设计方法并不局限于任何特定的语言平台，不论是在使用最新集成技术的可视化开发环境下进行快速迭代开发，还是对于运行在特殊硬件上基于字符显示的控制系统，这种方法都同样有效。 　　可用性并不能一蹴而就。这经常是一项艰苦的工作，需要对细节的关注，但通过使用几件基本的概念工具，设计开发人员也可以学会怎样发现可用性问题，怎样改进所开发系统的可用性。麻省理工学院的Woody Flowers教授曾经将摄像机交给一些中学生，让他们去发现和拍摄那些难以使用的产品及其现象，并对其原因加以解释。如果没有经过训练的中学生尚且可以学会可用性的基础知识，那就没有理由怀疑成年人能够掌握可用性的基本原理。 来源： https://www.cnblogs.com/dgb152/p/12250203.html

UML概述 什么是UML？ 1.UML(united modeling language)： 统一建模语言，是用来设计软件蓝图的可视化建模语言，是一种可视化的面向对象建模语言 2.它支持面向对象系统的分析、设计、实现和交付等各个环节，可以用于系统的理解、设计、浏览维护和信息控制 3.UML描述了一个系统的静态结构和动态行为。UML 用图形方式表现典型的面向对象系统的整个结构 4.UML不是一个程序设计语言 UML不是一个形式化语言 UML工具 主流UML工具： rational rose、together、Microsoft visio Rational rose： 是一种工具，它可以在rose建模中提供建立、视图、修改和操作组件的能力 Rose： 支持unified、booch、OMT标记法 UML构成 （1)UML的基本构造块 • UML 中的事务: 构成模型图的一些基本图示符号，表示一些面向对象的基本概念 • UML中的关系: 表示基本图示符号之间的关系 • UML 中的图: 特定的视角对系统所做的抽象描述 PS:事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。 （2)UML的规则 • 命名规则 • 范围 • 可见性 • 完整性 （3)UML的公共机制 • 规格说明 • 修饰 • 通用划分 • 扩展机制 下面逐个介绍上面所述的结构 事物的类型

软件开发出来后，无非就两大团体来接触他。一个是用户，一个是开发者。所以在设计软件的时候这两个团体要同时考虑，从各个角度来权衡每个设计点的偏重点。 开发的软件是给用户操作的，用户每天都要与之打交道，所以界面的美观性，功能的实用性，操作的简易性，数据传递的速度以及比较贴近的业务逻辑对于用户来讲都是很重要的。 而对于开发者来说，软件开发完成后并不是就不用管了，软件的后期维护也是一项很重要，很繁琐的事情。用户会随着时间的推移，不断的改变着他的需求，要你对软件进行改进。当然，你会把一些需求挡回去，把一些需求通过现有的条件变种方式来实现，但总有一些你需要增加或修改。这时，你的软件在开始设计的时候是不是够灵活，在你修改的时候便知道了。 如果维护的软件让你头疼，宁愿重新开发也不愿意去修改，那就说明这个软件设计的很不成功。 要想让软件不发生腐化，使以后的维护工作更加容易，那么设计软件的时候应该尽量避免以下几个问题：  1. 僵化性（ Rigidity ）：设计难以改变 当用户提出一个新的需求时，需要对程序的一些地方进行改动，可当你打开代码，发现虽然是添加一个很小的功能，却牵涉到了很多地方。这样单一的改动导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。没人愿意为了一小块玉石而去移掉整座山，愚公移山的精神在这里不值得发扬。 2. 脆弱性（ Fragility ）：设计易于遭到破坏

补充： 继承： 父类和子类之间 共享数据和方法 的机制，一个父类可以有多个子类，父类描述了这些子类的公共属性和方法，一个子类可以继承它的父类中的属性和方法，这些属性和操作在子类中不必定义，子类中还可以定义自己的属性和方法。 多态： 在收到消息时，对象要给予响应，不同的对象收到同一消息可以产生完全不同的结果 参数多态： 一个类型是另一个类型的子类型 过载多态： 同一个名字在不同的上下文中所代表的含义不同 静态绑定： 在编译时进行的 动态绑定： 在运行时进行的，当一个对象发送消息请求服务时，要根据接收对象的具体情况将请求的操作与实现的方法进行连接 重置/覆盖： 在子类中重新定义父类中已经定义的方法，其基本思想是通过一种动态绑定机制的支持，使得子类在继承父类接口定义的前提下用适合自己要求的实现去置换父类中的相应实现 重载： 一个类可以具有多个同名而参数类型列表不同的方法，每个方法实现自己的特定行为 创建型设计模式： 抽象工厂（Abstract Factory）： ① 意图： 提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类 ②模式适应于： 一个系统要独立于它的产品的创建、组合和表示时。 一个系统要由多个产品系列中的一个配置时。 当要强调一系列相关的产品对象的设计以便进行联合使用时。 当提供一个产品类库，只想显示它们的接口而不是现实时。 例： 使用一个汽车生产来做例子

设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？ 最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功， 软件 开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。 一个在简历中轻描淡写的“ 10 年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象 编程 、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括： · 面向对象 （ Object-Oriented ），关于面向对象没有必要重复嚼舌了，本书的第 1 章“ OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层 技术 上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。 · 面向服务 （ Service Oriented ）， SO 至少是个时髦的话题， WCF 伴着 .NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世

引用声明：电子工业出版社《面向对象分析与设计》第三版：修订版 Grady Booch等著的书籍内容，仅供学习使用。 复杂性 一. 为什么软件在本质上是复杂的？ 软件固有的复杂性有四个原因： 问题域的复杂性 比如公共交通购票系统需求（经常出问题的12306，不仅要处理正常用户购票，还要抗住第三方软件的频繁抢票）。 比如航天电子系统需求，从功能上就很难理解，还要加上所有的非功能需求，如可用性、性能、成本、健壮性和可靠性，不能遇到突发问题直接宕机吧，那就不是航天了，而是拿人命开玩笑。 有的客户只是对想要的软件系统有一个模糊的想法，和开发者之间存在沟通上的分歧。 软件系统在开发过程中经常发生需求改变；产品经理和开发程序员之间大打出手也不是一次两次了，“小明，其他同类型的产品做得挺好，今晚加班搞下，明早上线。”，“这种坑爹需求谁爱做谁做，老子不伺候了”。 管理开发过程中的困难性 人员协调困难，怎么合理安排人手，投入多少骨干和萌新，不同的开发者能承受多少工作量？ 风险管控困难，怎么控制需求管道，不超出团队承受能力范围。怎么控制交付时间点，保证合理的开发和测试时间？ 质量维护困难，怎么维持设计的一致性和完整性？怎样沉淀团队经验和解决方案？假如前期开发管理不到位，测试阶段问题爆炸怎么处理？线上问题多影响开发进度怎么办？如何复盘和回溯问题不再重蹈覆辙？ 软件中随处可能出现的灵活性

目录 1.活动图 2.组件图 3.部署图 4.包图 5.数据流图 6.E-R图 一、活动图 　　描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。是一种特殊的状态图，强调对象间的控制流程。 　　元素：活动状态、动作流（转移）、分支与合并、分叉与汇合、泳道、对象流。 　　 　　1、活动状态：使用圆角矩形表示活动状态。与动作状态的图标是一样的。 　　2、动作流（转换）：使用带箭头的直线表示。是活动图中活动状态的转换。 　　3、开始节点和终止节点：分别是： 开始节点： 终止节点： 　　4、分支和合并：其实就是选择分支，使用菱形进行一个条件的判断。每一个离开的转换都会有一个监护条件。满足对应的条件就会执行对应的转换。 　　 　　5、分叉与汇合：分叉是将一个源活动和多个目标活动的转换。汇合多个源活动汇合到一个目标活动的转换中。 　　 　　6、泳道：将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的对象。泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。如第一幅图中的四条竖直的直线就是泳道。 　　7、对象流：是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。 返回顶部 二、组件图 　　是描述组件和组件之间的关系，是系统在物理上的一种图的体系。 　　三种元素：组件、接口、关系。 　　 　　1

以汽车ABS系统的软件系统进行案例分析： 一、强实时功能需求有：1.汽车车轮转速的实时监测，实时计算出轮速、参考车速、车轮加速度、滑移率等参数； 2.系统故障诊断，故障诊断分为两部分，分别是启动时故障诊断和行驶状态下故障诊断。 实时事件实时响应：1.制动压力调节，当车轮处于抱死的临界状态时，调节制动压力； 2.系统故障处理，如果发现故障，则应及时警示。 二、ABS的软件系统需要设计2个实时任务，分别是汽车车轮状态监测和行驶状态下故障诊断。 三、以上两个实时任务均为时间触发：1.为保证ABS的实时性，系统完成信号采集、计算、控制等一系列动作的周期为10ms； 2.为保证安全性，要求当系统出现重大故障时在100ms内发出警报信号，所以故障诊断的周期为100ms。 四、以上两个实时任务之间存在依赖关系，故障诊断包括汽车车轮状态监测。 行驶状态下的故障诊断包括：传感器信号采集的故障、中央处理单元故障、控制执行器的故障等整个系统的故障。 五、两个实时任务之间存在共享的硬件资源。 汽车车轮实时监测使用的硬件资源主要有:轮速传感器、信号处理单元、中央处理计算单元； 故障诊断使用的硬件资源主要有：轮速传感器电压检测器、电磁阀状态监测器、中央处理单元； 轮速传感器电压检测器的信号来自轮速传感器，两者都依赖中央处理单元实时处理。 来源： https://www.cnblogs.com/syth/p

从此重构 设计是如此重要，那么开发者的基本设计能力与素质又从何下手来培养呢？ 最好的办法，就是请个老师。从框架中了解，从系统中实现，从书文中汲取。然而，设计能力的提升绝非一朝一夕之功，软件开发中的设计大师，往往必须具备多年的修行方可称之为“架构师”。 一个在简历中轻描淡写的“ 10 年软件设计经验”，并非是所有软件人都能修炼成的真功夫，这里没有任何虚情假意可言。在一个项目的实现过程中，逐渐了解什么是对象、什么是对抽象编程、设计模式是如何应用在实际的系统架构、设计原则到底是什么秘密武器，而重要的是完成一个软件项目，对于更多人来说是认识一种软件开发的科学流程。这种体验，才是难能可贵的经验。在设计的广义概念里，几个必需的概念是应该首先被了解和认知的，以排名不分先后的原则罗列，它们大概包括： · 面向对象 （ Object-Oriented ），关于面向对象没有必要重复嚼舌了，本书的第 1 章“ OO 大智慧”中对 .NET 的面向对象进行了有别于其他专著的介绍，除了以实例突出面向对象之思想大成，还以浓墨铺陈了 .NET 是如何在底层技术上来实现继承、多态和接口映射等机制，从而使读者可以更加有效和深刻地把握面向对象之精髓。 · 面向服务 （ Service Oriented ）， SO 至少是个时髦的话题， WCF 伴着 .NET 3.5 的发布，一个一统江湖的面向服务的基础架构横空出世