第7章-系统设计概述报告.ppt

第7章 系统设计概述 本章主要内容 7.1 系统设计的任务要求 7.2 系统设计的内容 7.3 系统设计说明书 什么是设计？ 比如服装 通过分析获得某个人或某个群体的需要（根据职业、场合、身材、气质风格、个人要求等进行分析，确定需求） 设计则是根据需求完成具体服装式样的裁剪设计图，以及材料选择、配饰设计等 以下是设计图： 设计 信息系统的设计 现实领域的各种需求 系统的逻辑模型 可使用的实际系统 针对需求，进行计算机信息系统的物理模型设计 实现 设计模型 7.1 系统设计的任务要求 通俗地说，设计就是要回答“怎么做” 完成技术实现方案的制定，即信息系统的物理模型 一个逻辑模型，可以提出多个物理模型 根据物理模型进行实施，得到最终的物理系统 7.1.1 系统设计的目标 设计系统之前，先看看评价信息系统的标准，这些标准对任何设计方法都适用： 信息系统的功能：是否满足用户的需求 系统的效率：响应时间、操作的方便性 系统的可靠性：抗干扰能力、故障恢复 系统的工作质量：准确性、使用效果 系统的可变更性：修改和维护的难易程度 系统的经济性：系统收益与支出比 与需求相同，设计的重点也在于软件，因为相对软件，硬件方案的复杂度和多样性较小。 信息系统的可变更性 变化是不变的真理。 统计表示：在信息系统的整个生命周期中，系统维护成本占总成本的80%左右。 因此，可变更性是衡量信息系统设计的重要指标。 7.1.2 良好的结构设计 结构简单 系统各组成元素分工明确，易于理解 元素之间的关系清晰简洁 变动灵活 谨防软件维护中的“水波效应” 使系统各组成元素内部的改变容易实现，改动对其它部分的影响尽量减少 提前考虑将来最易出现的扩展和变更 1. 低劣设计带来的问题 糟糕的软件设计可能包含一下症状： 僵化性（rigidity）：系统很难改变，即使一个简单的改动也会导致大量有耦合关联的其它部分的连锁反应。 脆弱性（fragility）：改变系统的某个部分，会破坏许多无关的其它部分。 固化性（immobility）：系统各部分紧密联结无法分开，很难将系统分解成可供其它系统重用的部件。 粘滞性（viscosity）：当软件需要改动时，设计不容易保持稳定，逐渐脱离最初的设计思路而走样，造成软件不同版本之间存在较大差异。 不必要的复杂性(needless complexity)：过度设计，很多非常聪明的超前的结构目前还不需要，什么时候需要不得而知。 不必要的重复性（needless repetition）：因为忽视抽象而使很多代码看上去是重复的，将来修改一处时，导致多处修改。 晦涩性（opacity）：很难阅读、理解，不能很好地表现出设计者的意图，难以与需求规格描述进行对照。 一个低劣的建筑设计方案，技艺高超的工匠也无法造出精品。 2. 基本设计方法 为了设计出结构良好的系统，方法如下： (1) 把系统划分为一些部分，其中每一部分的功能简单明确，内容简明易懂，易于修改。这样的组成单元可以是模块、类、组件、服务和子系统。 (2) 系统功能单元的划分按层次进行。整个系统分解成若干子系统，然后每个子系统按功能再分解为更小的功能单元（如菜单项、人机窗口界面、业务功能组件等），依次下去。最底层的基本单元可以设计成一个函数、子过程、或类的一个方法。 (3) 每一个功能单元应尽可能封装为独立的元素，对外提供必要的使用接口，隐藏内部的数据、算法等实现细节，并尽可能减少各单元间的控制关系和数据交换，使得系统各部分之间是松耦合的状态。“独立而不孤立” (4) 各功能单元对外的接口、以及相互间的控制和依赖等关系要阐明。这样，在修改时可以追踪和控制。 3. 系统设计师的素质要求 创造性设计思维； 丰富的编程经验和很强的逻辑思维能力； 具备将复杂的问题分解成简单问题的能力，设计易于使用和维护的软件结构，并保证较好的重用性； 应对系统结构尤其是软件结构具有较强美感，善于运用巧妙优美的设计模式； 应有大局观，懂得平衡各种开发局限的制约，权衡时间、进度成本与系统质量、性能等因素提出最佳方案。 软件设计师职位描述 架构设计师（系统架构师）、软件设计师 其他设计相关职位 UI设计师、数据库设计师、高级网络工程师 7.1.3 从分析过渡到设计 分析的目标是做正确的事（do the right thing） 设计工作就是正确地做事（do the thing right） 分析与设计任务和目标不同，但在一些软件开发过程方法（如敏捷方法）中，分析和设计没有严格的阶段划分。 因为工作内容或模型有较强关联，分析到设计的建模过程某种程度上是一个从粗到精、从抽象到具体的过程。 例如分析阶段建立了领域对象模型，完成了对领域对象最本质和核心的分析和抽象，设计阶段还会基于该模型进一步完善和扩充。 7.2