软件工程教学课件chapter08.ppt

1 第8章 设计概念2设计nMitch Kapor，Lotus 1-2-3的创始人,在 Dr.Dobbs杂志上发表了“软件设计宣言”，他说：n良好的软件设计应该展示：n坚固：程序应该展示不含任何妨碍其功能的缺陷。n适用：程序应该符合开发的目标。n愉悦：使用程序的体验应是愉快的。3分析模型-设计模型Anal ysi s M odeluse-cases-t ext use-case di agr am s act i vi t y di agr am s swi m l ane di agr am sdat a f l ow di agr am s cont r ol-f l ow di agr am s pr ocessi ng nar r at i vesf fl lo ow w-o or ri ie en nt te ed d e el le em m e en nt ts sb be eh ha av vi io or ra al le el le em m e en nt ts sc cl la as ss s-b ba as se ed de el le em m e en nt ts ss sc ce en na ar ri io o-b ba as se ed de el le em m e en nt ts scl ass di agr am s anal ysi s packages CRC m odel s col l abor at i on di agr am s st at e di agr am s sequence di agr am sD D a at ta a/C Cl la as ss s D D e es si ig gn nA A r rc ch hi it te ec ct tu ur ra al l D D e es si ig gn nI In nt te er rf fa ac ce e D D e es si ig gn nC Co om m p po on ne en nt t-L Le ev ve el l D D e es si ig gn nDesi gn Model基于场景的元素用例文本用例图活动图泳道图基于类的元素类图分析包CRC模型协作图行为元素状态图顺序图面向流的元素数据流图控制流图处理叙述设计模型数据/类设计体系结构设计接口设计构件级设计分析模型4设计和质量n设计必须实现所有包含在需求模型中的明确需求，而且必须满足利益相关者期望的所有隐含需求。n对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解的指南。n设计必须提软件的全貌，从实现的角度说明数据域、功能域和行为域。5质量指导原则n设计应该展示出这样一种结构：（a）已经使用可识别的体系结构风格或模式创建；（b）由展示良好设计特征的构建构成；（c）能够以演化的方式实现。n对于更小的系统，设计有时可以线性开发。n设计应该模块化；也就是说，应将软件逻辑地划分为元素或子系统。n设计应该包含数据、体系结构、接口和构件的清晰表示。n设计应导出数据结构，这些数据结构适用于要实现的类，并从可识别的数据模式提取。n设计应导出显示独立功能特征的构件。n设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性。n设计的导出应根据软件需求分析过程中获取的信息采用可重复的方法进行。n应该用能够有效传达其意义的表示法来表达设计。质量属性（FURPS）n功能性通过评估程序的特征集和能，所提交功能的通用性以及整个系统的安全性来评估n易用性通过考虑人员因素、整体美感、一致性和文档来评估。n可靠性通过测量故障的频率和严重性、输出结果的精确性、平均故障事件、故障恢复能力和程序的可预见性来评估。n性能通过考虑处理速度、响应时间、资源消耗、吞吐量和效率来度量n可支持性综合了扩展程序的能力、适应性和耐用性3方面的能力。67设计原则n设计过程中不要有“井蛙之见”。n设计应起源于分析模型。n设计不要白费力气做重复工作。n在软件和真实世界的问题之间，设计应能“最小化知识距离”DAV95。n设计应表现出一致性和集成性。n设计结构应适应变化。n即使遇到数据、事件或操作条件异常时，设计结构应能温和处理。n设计不是编码，编码不是设计。n创建设计时就应对其质量进行评估，而不是创建之后。n评审设计以最小化概念上的（语义的）错误。来自来自 Davis DAV958基本概念n抽象数据、过程、控制n体系结构软件的整个结构n模式已证实的解决方案的“精髓”n关注点分离任何复杂问题如果被分解为若干块，该复杂问题更容易地被处理。n模块化数据和功能的划分n信息隐蔽控制接口n功能独立专一的功能和低耦合n求精所有抽象精化的细节n方面一种理解全部需求如何影响设计的机制n重构一种简化设计的重新组织的技术n设计类提供设计细节，使分析类得以实现9过程抽象实现为一个“知识”对象，与进门有关implemented with a knowledge of the object that is associated with enter10数据抽象实现为一个数据结构制造商模块数类型转动方向插入灯数量类型重量打开机制implemented as a data structure11体系结构结构特性。结构特性。外部功能特性。外部功能特性。相关系统族。相关系统族。12模式13关注点分离n任何复杂问题如果被分解为可以独立解决和（或）优化的若干块，该复杂问题能够容易地被处理。n一个关注点是一个特征或行为，被指定为软件需求模型的一部分。n通过将关注点分割为更小的关注点，使得解决一个问题需要付出更少的工作量和时间。14模块化n软件工程师难以掌握单块软件（即由一个单独模块构成的大程序）。n其控制路径的数量、引用的跨度、变量的数量和整体的复杂度使得理解这样的软件几乎是不可能的。n几乎所有的情况下，为了理解更容易，都应当将设计划分成许多模块，这样做的结果，构建软件所需要的成本将会随之降低。15模块化：权衡16信息隐藏17为什么要信息隐藏？n减少“负效应”的可能性n限制全局影响局部的设计决策n强调通过控制接口通信n不提倡使用全局数据n导致封装高质量设计的属性n导致高质量软件18功能独立n通过开发具有“专一”功能和“避免”与其他模块过多的交互的模块，可以实现功能独立。n内聚性显示了某个模块相关功能的强度。n一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。简单地说，一个内聚的模块应该（理想情况下）只完成一件事情。n耦合性显示了模块间的相互依赖性。n耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。19测量模型：两种视角MODULEWhats inside?How big is it?里面是什么？它多大？模块20逐步求精开门走向门伸向把手打开门；走进门关门一直重复直至门打开顺时针转动把手；If 把手不能转动，拿出钥匙；找到正确的钥匙；插进锁孔；endif推/拉门移动脚步end 重复turn knob clockwise;find correct key;endifpull/push doormove out of way;end repeatrepeat until door opensif knob doesnt turn,then insert in lock;take key out;openwalk to door;reach for knob;walk through;close door.open door;21方面n考虑两个需求，A和B。“如果已经选择了一种软件分解 精化，在这种分解中，如果不考虑需求A的话，需求B就不能得到满足”Ros04，那么需求A横切需求B。n方面是一个横切关注点的表示。22方面举例n考虑SafeHomeA 网站应用中的两个需求。通过用例“通过互联网访问摄像头”描述需求A，设计求精将集中于那些能够使注册用户通过放置在空间中的摄相机访问视频的规模。需求B是一个通用的安全需求，要求注册用户在使用SafeHomeA 之前必须先进行验证，该需求用于Safehome注册用户可使用的所有功能中。当设计求精开始的时候，A*是需求A的一个设计表示，B*是需求B的一个设计表示。因此，A*和B*是关注点的表示，且B*横切A*。n方面是一个横切关注点的表示，因此，需求“注册用户在使用SafehomeA之前必须先进行验证”的设计表示B*是Safehome网站应用的一个方面。23重构nFowler FOW99 用下面的方式定义重构：n“重构是使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改进其内部结构。”n当重构软件时，检查现有设计：n冗余性n没有使用的设计元素n低效的或不必要的算法n拙劣的或不恰当的数据结构n其他设计不足，修改这些不足以获取更好的设计。24OO 设计概念n设计类n实体类n边界类n控制类n继承超类的所有特点立即被所有子类继承。n消息刺激接收对象产生某种行为n多态一种可以显著减少扩展已存在的设计的特性25设计类n在设计时，分析类被精化变为实体类n边界类是在设计中创建接口被开发的（例如：交互式屏幕或打印报表），用户看到并与使用的软件交互。n边界类的设计，其职责管理将实体对象呈现给用户的方式。n控制类被设计用来管理n实体对象的创建和更新；n边界对象的实例化，因为它们获得来自实体对象的信息；n对象集之间的复杂通信；n验证对象之间或用户与应用程序之间的数据通信。26设计模型p pr ro oc ce es ss s d di i m m e en ns si i o on narchi tecture el em entsi nterface el em entscom ponent-l evel el em entsdepl oym ent-l evel el em entsl owhi ghcl ass di agram s anal ysi s packages CRC m odel s col l aborati on di agram s use-cases-text use-case di agram s acti vi ty di agram s sw i m l ane di agram s col l aborati on di agram sdata fl ow di agram s control-fl ow di agram s processi ng narrati vesdata fl ow di agram s control-fl ow di agram s processi ng narrati vesstate di agram s sequence di agram sstate di agram s sequence di agram sdesi gn cl ass real i zati ons subsystem s col l aborati on di agram s desi gn cl ass real i zati ons subsystem s col l aborati on di agram s refi nem ents to:depl oym ent di agram scl ass di agram s anal ysi s packages CRC m odel s col l aborati on di agram s com ponent di agram s desi gn cl asses acti vi ty di agram s sequence di agram srefi nem ents to:com ponent di agram s desi gn cl asses acti vi ty di agram s sequence di agram sdesi gn cl ass real i zat