3软件设计基础

第3章软件设计基础 结构化开发方法 面向对象开发方法 基于构件的软件开发方法形成各种系统化的软件设计过程和技术 软件设计是一个精化的过程 其中也包含多活动 并需要灵活运用抽象 模块化 求精等多种技术 本章主要内容重要概念软件设计的过程模型对其中的重要活动进行描述 高质量设计的要素的原则 高可信领域的软件的设计软件体系结构的设计软件设计的文档和设计的评审 3 1软件设计的基本概念 软件设计主要针对需求分析过程中得到的软件需求规格说明 综合考虑各种制约因素 探求切实可行的软件解决方案并最终给出方案的逻辑表示 包括文档 模型制约因素 资源 时间 人力 财力 开发工具技术 方法 技术 平台最终目标 满足需求的解决方案明确 设计模型易于理解可行 在可用的技术平台和软件项目的可用资源条件下 须用预定的开发语言可构造技术可以完整地实现设计模型高质量 设计模型给出需求的实现方案 非功能需求的约束 设计模型优化 一 抽象与求精 二 模块化与信息隐藏 模块划分的准则可分解性可组装性可理解性连续性保护模块独立性 Moduleindependence 好设计的关键 每个模块完成一个相对独立的子功能 并且与其它模块间的接口简单 信息隐蔽 Informationhiding Theclientsofamoduleknowaboutitsservicesonlythroughitsinterface theimplementationishiddenfromthem hencemaychangewithoutaffectingtheclients 支持模块的并行开发减少测试和维护的工作量提高了系统的灵活性和可扩展性 三 内聚与耦合 内聚性 模块内部各成分之间关联程度的度量偶然性内聚 一个模块内各成分为完成一组功能而组合在一起 它们相互之间即使用关系 也很松散逻辑性内聚 模块完成的诸任务逻辑上相关时序内聚 一个模块包含的任务必须在同一时间内执行过程性内聚 模块内成分彼此相关 并且必须按特定的次序执行通信内聚 模块中各成分都将对数据结构的同一区域进行操作顺序性内聚 各成分均与同一功能相关 且处理按序执行功能性内聚 所有成分形成一个整体 完成单个功能 耦合 Coupling 独立性的度量 耦合 Coupling 内聚 Cohesion Yourdon Constantine 1978 例1 A访问C的内部数据或不通过正常入口而转入C的内部 独立性由弱到强排列为 内容耦合 ContentCoupling Onemodulemodifiesanother 例2 部分代码重叠 常出现在汇编程序中 例3 一个模块有多个入口 功能 Theleastdesirable 公共耦合 Commoncoupling Dataareaccessiblefromacommondatastore 问题 公共部分的改动将影响所有调用它的模块 公共部分的数据存取无法控制 复杂程度随耦合模块的个数增加而增加 控制耦合 Controlcoupling Onemodulepassesparameterstocontroltheactivityofanothermodule 接口单一 但仍然影响被控模块的内部逻辑 数据耦合 Datacoupling Onlydataarepassed Itiseasytotracedataandmakechanges Themostdesirable 原则 尽量使用数据耦合 少用控制耦合 限制公共耦合的范围 完全不用内容耦合 模块间的耦合 模块内聚 低内聚 巧合内聚 Coincidentalcohesion Unrelatedfunctions processes ordataarefoundinthesamemodule forconvenience 逻辑内聚 Logicalcohesion Logicallyrelatedfunctionsordataareplacedinthesamemodule 例如 内聚 Cohesion Theelementsofamodulearedirectedtoperformthesametask Goal ascohesiveaspossible 时间内聚 Temporalcohesion Thefunctionsarerelatedonlybythetiminginvolved 例如 系统的初始化问题 不同功能混在一个模块中 有时共用部分编码 使局部功能的修改牵动全局 通信内聚 Communicationalcohesion Allthefunctionsinamoduleoperateonorproducethesamedataset 例如 从同一磁带上读取不相干的数据 可能破坏独立性 中内聚 过程内聚 Proceduralcohesion Functionsaregroupedtogetherinamoduletoensureacertainorderofperformance 例如 高内聚 顺序内聚 Sequentialcohesion Theoutputfromonepartofamoduleistheinputtothenextpart 功能内聚 Functionalcohesion Everyprocessingelementisessentialtotheperformanceofasinglefunction c 模块内聚 启发性规则 1 争取低耦合 高内聚 增加内聚 减少耦合 2 模块规模适中 过大不易理解 太小则接口开销过大 注意分解后不应降低模块的独立性 3 适当控制 深度 分层的层数 过大表示分工过细 宽度 同一层上模块数的最大值 过大表示系统复杂度大 启发性规则 系统结构 启发性规则 扇出 一个模块直接调用 控制的模块数 3 fan out 9 扇入 直接调用该模块的模块数在不破坏独立性的前提下 fan in大的比较好 启发性规则 尽可能减少高扇出结构 随着深度增大扇入 如果一个模块的扇出数过大 就意味着该模块过分复杂 需要协调和控制过多的下属模块 应当适当增加中间层次的控制模块 启发性规则 4 作用域在控制域内 控制域 M的控制域为 M A B C 作用域 M中的一个判定所影响的模块 例如 上例中A的作用超出了控制域 改进方法之一 可以把A中的if移到M中 方法之二 可以把C移到A下面 启发性规则 5 降低接口的复杂程度 接口复杂可能表明模块的独立性差 6 单出单入 避免内容耦合 7 模块功能可预测 相同输入必产生相同输出 反例 模块中使用全局变量或静态变量 则可能导致不可预测 耦合 模块间依赖程度的度量非直接耦合 两模块中任一个都不依赖对方能独立工作数据耦合 通过参数交换信息 而信息公限于数据内容耦合 一个模块使用另一模块内部的数据或控制信息 一个模块直接转移到另一模块内部量化指标 类耦合度 一个类的耦合度定义为与它耦合的其他类的数目 包括调用其他类的一个方法 使用其他类的一个实例变量 方法内聚缺乏程度 定义为不访问相同成员变量的方法对 即两个方法 的数目减去访问相同成员变量的方法对的数目 相似方法的数量越大 类的内聚度就越高 3 2软件设计过程 软件设计的一般过程迭代 第一层迭代 第二层迭代设计过程 软件体系结构设计 界面设计 模块 子系统设计 数据模型设计 过程算法设计数据库设计 类设计 接口设计 构件设计界面设计 数据模型设计 体系结构设计 模块设计形成设计规格说明 评审 软件设计的主要活动软件设计计划 确定设计的目标和验收准则 明确标准和规范 风险管理 制订工作计划 对计划进行评审体系结构设计 适用性 结构稳定性 可扩展性 可复用性界面设计 适用 易理解性 一致性 灵敏性 容错性 人性化 国际化 个性化 合理的布局 和谐的色彩模块或子系统设计 子系统独立构成系统 不依赖其他子系统提供的服务 子系统由模块组成一个模块通常是一个能够提供一个或多个服务的系统部件 它能得用其他模块的服务 一般不被看成一个独立的系统 模块由更简单的模块组马 模块也需要定义接口 过程 算法设计 过程 算法设计对模块内部的工作和执行过程进行描述 给出有关处理的精确说明事件的顺序 确切的决策位置 循环操作 数据的组成使用UML活动图进行描述数据模型设计 数据结构设计 数据库设计 数据文件设计的总称数据结构描述各数据分量之间的逻辑关系 持久数据操作 包括写入 查询 更新和删除四类基本操作及及由它们复合而成的业务数据操作数据库设计 确定设计模型中需要持久保存的数据条目数据 数据元素的格式 结构 访存 表示等机制进行良好的建模和优化 是提高软件设计质量和系统性能的基础 对软件系统的应用具有重要意义 3 3软件设计的质量 软件设计的质量要素 结构良好 软件设计的结构合理 模块满足功能独立 信息隐藏和高内聚 低耦合的要求 子系统和模块之间接口定义明确 清晰 一致充分性 可行性 简单性 实用性灵活性 可移植性 可复用性标准化 正确性 目标 每个项目都要满足指定的需求 然后一起满足所有应用程序的需求实现正确性的途径 达到正确性的非正式方法完全理解 模块化达到正确性的正式方法 达到正确性的非正式方法 充分设计 一个设计足以实现需求 一个正确的设计 有时称为 设计必须完全可理解 接下来 设计非常模块化 达到这个目标的方法是 最小目标 达到正确性的正式方法 基于在严密的控制下跟踪变量的变化 一般会指定一个不变式 不变式在变量值之间表示的是一种不变关系 例如 length 0length breadth areaoverdraft 02 mileage 300 300是一辆报费汽车的处理价格5 originalPrice 06 type REGULAR value originalPrice 考虑不变式 将变量设为私有 只能通过公有的存取方法才能改变他们的值 可以对存取方法进行编码来保持不变式 如通过setter方法来设置类不变式精心设计的类通常拥有可理解的不变式集 withvariablesmileage VehicleID value originalPrice andtype mileage 0mileage 300 300是一辆报废汽车的处理价格 originalPrice 0 type REGULAR value originalPrice 类的不变式 模块接口 模块化是获得设计正确的方法模块化设计的要点首先要理解客户代码是如何使用模块模块可以是类或类的包接口是函数形式 或原型 的集合 模块的接口定义了它的用途 类的接口 ShipmentsetVehicle perishable getWidth printRoute describeType getLength getDuration setType Shipment DimensionsgetWidth getLength getWeight TransportationMeansgetDuration setVehicle printRoute GoodsTypedescribeType setType perishable Shipment Dimensions TransportationMeans GoodsType 原始形式 使用接口的形式 包的接口 Pricing purchases Furniture Clothing Appliance Selection ClothingTryout singleton PurchasesIF 包的接口和类的接口不同 因为包不能像类那样被实例化 通过包来使用接口 一种方法是 利用包中类的指定对象来提供相应的接口 PurchasesIF类通过一个对象来支持接口 Singleton类型的类就是那些只有一个实例的类 另一种方法是让PruchasesIF拥有绝对静态的方法 Participant services Conversation services 包的接口举例 聊天程序 Conversation chatServer chatClient Display ConversationManager ClientComm ServerComm billing Accounting Bill Financial Message reception 模块化 在高层需要创包 在低层需要创建类选择类领域类 设计中的特有类非领域类 用于概括领域类选择包任务是将应用程序分组 通常分为3 4个包 领域类和非领域类 领域类 针对特定应用的类Examples BankCustomer BankTransaction Teller通常不包含GUI类足以让所有需求清晰化非领域类 一般类Examples 抽象类 实用类用于补充设计和实现24 重整 mechanics position groundcontrol onBoardNavigation control trajectory weather 跟踪运送卫星进入预定轨道的运载火箭轨迹的应用程序 Alternative1 Alternative2 为正确性和充分性而重整 首先为给定的需求进行设计 然后在额外的需求变得透明时对设计和实现进行修改 这个过程称为重整重整 为类提升一个原始属性为了适应范围的增长 我们常常需要引入一个新类来进行重整重整 引入抽象基类可接口面向对象提供抽象 但是什么样时候应该使用抽象呢 一个关键的标志就是每当应用程序包含几个具有广泛通用性的类时 抽象类可以包含类的所有特性 除了当类的对象自己不能被创建之外 应该是一个接口而不是一个类 1 防止错误输入用户输入不是用户的输入数据通信其他应用方法调用2 防止开发错误错误的设计错误的实现 提高健壮性 错误原因 健壮性 检查输入在继续进行处理之前 可以检查应用程序的所有输入的方法 检查类型 例如 整形 检查与前置条件和不变式的输入为提高健壮性而初始化提供静态方法 用来为类产生标准的默认值提高健壮性的参数传递技术保证方法正确调用引入一个捕获参数的类并将约束条件合并强化意图通过防止设计和实现中的错误来提高健壮性强化计划 按计划使用相应功能 Example intcomputeArea intaLength intaBreadth 如果可行 捕获在类中的参数约束intcomputeArea RectangleDimensionaRectangleDimension 在方法中说明所有的参数约束aLength 0andaBreadth 0andaLength aBreadth调用者遵循参数的显示要求问题是方法的设计者没有控制调用者在方法代码中首先检查约束if aLength 0 如果预计这种情况将会出现 则抛出异常否则 如果可能就中止程序否则如果返回的默认值在上下文之间有意义 就将其返回并且产生警告或日志 参数的约束 健壮性 在使用数据之前进行检查 可以提高健壮性 包装参数 ReplaceintcomputeArea intaLength intaBreadth withintcomputeArea RectangleaRectangle whereclassRectangle Rectangle intaLength intaBreadth if aLength 0 this length aLength else 只在一个地方进行错误处理 改进了设计与维护性 不足是产生了类的激增 KeyConcept Robustness 通过强化我们的意图来提高健壮性 灵活性的表现 灵活性的预期目标 用于增加更多类型功能的设计例如 银行应用 处理更多类型的账号而不需要修改已存在的代码用于增加不同类型功能的设计例如 在存款功能的基础上增加提款功能修改功能例如 可透支 应用中增加同类型功能的设计 WebSiteregister Member 0 n members classWebsite Member members ormaybe vectormembers voidregister MemberaMember 怎样才能使设计更灵活以注册新类型的成员 举例 网站成员注册 注册网站的灵活性 WebSite Member 0 n StandardMember XMember YMember members 解决方案 引入一个基类 将基类抽象化 根据需要产生继承类 用于增加不同类型功能的设计 在以下范围内 一系列相关的函数Example 航空旅行 travelitinerary 函数中增加Pint功能一个已存在的基类Example 增加 打印航空路线 的功能两者都不是Example 增加 同时打印航空路线和航海路线 TripprintItinerary StandardTripprintItinerary SomeApplicationClass Method s callprintItinerary 向一个基类中增加功能 通过继承基本类的方法来增加功能 TripprintItinerary SeaTripprintItinerary SomeApplicationClass LandTripprintItinerary StandardTripprintItinerary 解决方案 通过继承基类的方法来增加功能每个子类都可以拥有各自版本的printItinerary 方法 依赖和继承的结合可以形成委托形式 附加的灵活性的类型 灵活性概念 我们之所以进行灵活的设计 因为变化和重用是经常出现的 可重用性 尽可能的降低成本重用原有的工作可以获得最大生产率重用 函数重用 类重用 重用类组合可重用设计 可重用组件函数设计的可重用性基于重用的类选择用于重用的类组合 使一个方法具有可重用性 完全指定前置条件等避免不必要的封装类耦合如果可行 让方法成为静态的参数化让方法功能化但要限制参数的个数让名字更具表达性可理解性促进可重用性解释算法重用者要知道算法如何工作 重用的方法必须给出完整的定义 以便使重用者知道这些方法的功能及使用条件一个方法相关对于上下文越独立 其可重用性的性能就越高 静态方法就属于这种类型 使一个类成为可重用的 完整的描述类使类名与功能与实际情况相符定义一个有用的抽象类以获得更广泛的应用于性减少对其他类的依赖性通过继承获得 减少类间的依赖性 Customer Replace Piano 如果类A依赖于类B 没有类B就不可以使用类A 这就减少了类A的重用性 Piano类依赖Custumer类 因为钢琴是卖给用户的 限制了Piano类的使用 一个库存应用程序可能需要Piano类 但却不需要Customer类 重用Piano类 能否让Custumer类依赖Piano类 因为用户只有购买钢琴时才成为用户 有没有更好的解决方案呢 降低依赖性 减少类间的依赖性 with Customer Piano PianoOrder 引入第三个类PianoOrder将其关联起来 这个设计具有一定的作用 但在现实情况中可能是不行的 例如 可能需要访问某一给定用户的订单 而不必检查每个PianoOrder订单对象 中介者设计模式解决问题减少类之间的依赖关系 抽象级的依赖关系是可以接受的 通过减少类的依赖性来增加其可重用性 类组合的重用 利用继承 组合和相关技术来实现 CustomercomputeBill RegularCustomercomputeBill CustomercomputeBill Billcompute CustomercomputeBill Orders Ordersvalue 1 利用继承 3 利用依赖性 2 利用聚合 CustomercomputeBill 高效性 应用程序必须在指导定的时间内完成特定的功能执行效率处理循环问题消除远程调用消除或制定函数调用存储效率RAM的大小 运行时 代码本身的规模辅助存储器的大小 先按其它原则设计 再考虑效率以灵活性 可重用性等原则进行设计找出效率低的部分有针对性的修改一开始就按效率原则进行设计确认当前关键的效率需求在整个阶段都按需求进行设计以上两种方法的结合在设计时为效率需求做出折中在初始设计之后 也要继续考虑效率问题 针对时间效率的基本方法 时空折中 Space 处理一个项目的时间 通常的目标 时间 空间 开发的折中 空间 时间 开发的设备 限制可接受的值 不可接受的值 好于可接受的值 执行效率 影响执行效率的一些因素循环while for do远程调用 消除远程调用Requiringanetwork需要网络LANTheInternet函数调用 消除函数调用如果函数调用导致以上情况发生对象创建高效的设计并不要求简单 甚至会比较凌乱高效原则会减少函数调用 会导致产生大量的方法和类 难于扩展和重用 远程调用的次数 远程调用的次数 每次访问取得的信息 典型的目标 存储效率 应用程序需要存储数据 以务将来在执行时提取 这需要对存储数据的空间进行有效的利用 有三种存储问题 RAM的大小 运行时 代码本身规模辅助存储器 磁盘驱动 的大小提高存储效率往往要消耗一定的时间 获得存储效率 只需存储的数据在存储效率和数据提取以及重整时间之间获得折中压缩数据在存储效率与数据压缩和解压缩之间获得折中按相关访问频率存储数据在存储效率与决定存储位置的时间之间获得折中 StorageLocations Codebase RuntimeRAM Diskstoragerequiredatruntime Diskstoragerequiredbetweenruntimes 健壮性 灵活性 高效性和可重用之间的折中 1A 极限编程法或完全为效率而设计1B 灵活性驱动法着眼于将来的需求附带考虑可重用性2 确保健壮性3 提供足够高的效率如果为了获得效率那么会在可重用性方面做出折中 极限编程vs 非极限编程 工作完成快 通常 范围清晰 可能更有效 未来可能较少用到 扩展需求代价很大 示来应用可能较多用到 需求可变 范围划分不清晰 可能会比较费力 需要更多的关注效率 一个更灵活的计算器应用程序的设计 CommandLineCalculatormain executeAdditions solicitNumberAccounts getAnInputFromUser interactWithUser 已存在的设计 新设计 CalculatorsolicitNumAccounts CalcDisplaydisplay CalcOperationexecute Add Multiply Divide SummaryofThisChapter 灵活性 好修改可重用性在其它程序中应用高效性时间空间 软件体系结构设计 软件体系结构设计方法概述软件体系结构的多视图建模基于评估与转换的软件体系结构设计模式驱动的软件体系结构设计领域特定的软件体系结构设计软件产品线方法其他软件体系结构设计方法软件结构设计的步聚开发软件顶层架构搜索并选取可用设计资产设计术支撑确定设计元素设计并发机制构建软件体系结构模型评审软件体系结构模型 3 4软件体系结构设计方法概述 软件体系结构的多视图建模进程视图逻辑视图开发视图物理视图场景基于评估与转换的软件体系结构设计使用合适的体系结构风格的模式把非功能需求转化为功能性解决方案采用 分而治之 策略模式驱动的软件体系结构设计领域特定的软件体系结构设计类模型参考模型软件产品线方法其他软件体系结构设计方法基于目标图推理的体系结构设计方法基于属性的体系结构设计方法 体系结构 4 1 多视图建模 进程视图 物理视图 逻辑视图 开发视图 场景 集成人员性能可扩展性 系统工程师拓扑通信 软件体系结构的多视图建模 逻辑视图 关注功能需求 系统为用户提供的服务 与应用领域相关系统功能映射到概念构件和连接件与软件和硬件的细节没关若是面向对象设计 则将是一种对象模型进程视图 捕获设计中关于并发和同步的内容 重视非功能需求 性能 可扩展性等 定义运行实体和他们的属性 构件 连接件 构件可以是任务 连接件可以是消息 远程过程调用 RPC 事件广播等开发视图 描述软件在开发环境中的静态结构构件和连接件分别映射到子系统或模块关注于软件开发环境中软件模块的组织 软件可被打包 并按层次进行组织 物理视图 描述软件到硬件的映射关系 反映了软件的分布特征把不同的软件元素 例如进程和任务等 映射到不同的物理节点上 并关注物理环境的拓扑结构以及节点间的通信场景 使用一组重要场景 也就是用例的实例 把上述四种视图紧密地联系起来设计中发现体系结构元素的驱动器 设计完成后充当确认和验证的依据 基于评估与转换的软件体系结构设计 质量优化方案 体系结构转换 质量属性评价 基于功能的体系结构设计 体系结构制品 需求规格说明 满足 不满足 针对功能特性 它基于一种人们最常见的开发思路 针对功能要求设计体系结构 对设计结果进行评审 如果不满足要求则进行改进 一直迭代到满足要求为止 体系结构的评估方式基于场景的评估仿真数学建模基本经验的推理对体系结构转换的方式使用合适的体系结构风格和模式 或者设计模式来改进体系结构设计把非功能需求转化为功能性解决方案 可以与问题域没关 但可以满足质量属性的要求 采用 分而治之 的方式 可以把系统级的质量需求分配到子系统或模块中 或者把质量需求分解为多个与功能相关的质量需求 分解后的质量需求能够较易得到满足 模式驱动的软件体系结构设计 体系结构风格是描述某一特定应用方式中系统组织方式的惯用模式 为设计人员的交流提供了公共的模型 符号和术语表示 促进了设计复用甚至最终的代码复用 体系结构模式是对设计模式的扩展 描述了软件软件系统基本的结构化组织方案 可以作为具体体系结构的模板 软件开发中常用的设计模式也是对设计经验的一种总结和描述 以便于复用 但设计模式则是针对单一问题提供的解决方案 设计模式更接近于提供通用的实现方案 尽管实现可以不依赖于具体语言 而体系结构则需要综合考虑整个系统各方面的需求 一个体系结构设计在继续精化过程中可能会用到多种设计模式来解决其包含的子问题 常用体系结构风格管道和过滤器风格 层次风格 黑板模式等 模式驱动的软件体系结构设计方法 需求规格说明 系统特征初步分析 搜索可用的体系结构风格 选择合适的体系结构风格 对体系结构风格进行改造 以体系结构风格为基础进行设计 自行设计体系结构 扩展软件体系结构风格库 软件体系结构设计模型 不存在 体系结构风格分类 独立体系结构 数据流体系结构 以数据为中心的体系结构 虚拟机体系结构 调用与返回体系结构 领域特定的软件体系结构设计 特定领域的软件复用更易成功领域特定的软件体系结构 DSSA 是领域工程的核心部分 领域工程分析应用分析应用的共同特征和可变特征 对刻划这些特征的对象和操作进行选择和抽象 形成领域模型 并进一步生成DSSA 领域特定的软件体系结构借鉴领域中已经成熟的软件体系结构 实现解决方案在某个领域内的复用 虽然这些系统实例的细节会有不同 但共同的体系结构在开发新系统时是能够复用的 DSSA和软件体系结构风格都是对软件体系结构的重用 但它们的目标 构造和应用过程存在以下不同之处 1 DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果 前者从问题哉出发 而后者从解决哉出发 2 DSSA只在某个特定领域中进行经验知识的提取 总结与组织 但可以同时使用多种软件体系结构风格 而一种软件体系结构风格所呈现的公共结构和设计方法可以扩展到多个应用领域 3 DSSA的体系结构表示和工具一般只适用于一个较小的范围 在其他领域中是不适用并难以复用的 DSSA应该包括多种组成要素 例如领域模型 参考需求 参考体系结构 相应的支持环境或设施 实例 精化和评估的方法与过程等 以促进DSSA在领域中复用 领域相关的软件体系结构可分为两种类型类模型 类模型是从许多实际系统抽象出来的一般模型 它们封装这些系统的主要特征 参考模型 是更抽象且是描述一大类系统的模型 它是对设计者有关某类系统的一般结构指导 代表了一个理想化的体系结构 包含了系统所有应该具有的特征 OSI七层参考模型 软件产品线方法 软件产品线指一组具有公共的 可管理特征的软件系统 这些系统满足特定的市场需求或者任务领域需求 并且按照预定义的方式基于公共的核心资产集合开发得到软件产品线 SoftwareProductLine 是软件复用发展的一个更高阶段 它并不仅仅局限于函数 模块 类 体系结构甚至子系统的重用可以有效地提高生产率 缩短产品上市时间 提高质量和客户满意度软件产品线主要由两部分组成 核心资产库和产品集合核心资产库 是领域工程所有成果的集合 对支持产品开发的可复用资源进行管理 核心资产库包括产品线中所有产品共享的体系结构 可复用的软件构件 与软件构件相关的测试计划 测试用例 以及领域模型 领域范围定义和所有的需求描述 设计文档 各种性能模型和度量准则 日程安排 预算 工作计划 过程描述 通信协议描述 用户界面描述等 产品线方法的基本活动包括核心资产开发 产品开发和管理 核心资产开发指如何获得核心资产 可能通过自己构那家 直接购买 委托加工等各种方式 产品开发活动是产品线的目标 核心资产开发只是达到目标的一种手段 管理 各个活动合理分配资源 协调监督 设置适当的组织机构特征 循环重复 新产品形在的步骤从公共资产库中选取合适的构件使用预定义的变化机制进行裁剪 如参数化 继承等必要时增加新的构件在整个产品线范围内共同的体系结构指导下 进行构件组装 形成系统 其他软件体系结构设计方法 基于目标图推理的体系结构设计方法 功能需求和非功能需求皆被表达为要达到的目标 特别是把非功能需求表过为通常没有清晰的评价标准的 软 目标 基于属性的体系结构设计方法 软件结构设计的步聚 开发软件顶层架构选取合适的体系结构风格明确架构中每个部件的职责 特征 各部件之间的通信及协作关系 可用UML包图表示顶层架构组成 以及体系结构中子系统 构件之间的通信及协作关系搜索并选取可用设计资产设计术支撑设计资产包括相同或相关业务领域中的模块 子系统 构件 框架 类库 应用软件系统 设计模式等 可用 的设计资产是指在娄前项目中直接可供复用或借鉴的设计资产设计技术支撑方案技术支撑方案应该为软件多个用例的实现提供技术服务 所以它应该成为整个目标软件系统中全局性的公共技术平台 良好稳定性 确定设计元素子系统 构件 设计类确定设计元素的主要过程 确定子系统及其接口确定构件及其接口确定关键设计类整合设计元素开发软件部署模型软件部署模型软件部署模型负责展示软件中各子系统 构件在哪些计算结点上运行 以及这些结点之间的网络连接方式反映了软件系统的网络运行环境和物理分布状况设计并发机制针对目标软件系统的性能需求 包括界面的灵敏性需求 将一些可以并行执行的序列划分成不同的任务 明确这些任务在并发执行过程中可能的同步点 并研究并发任务在目标软件系统所基于的计算平台上的实现方法 构建软件体系结构模型整理 改进前述工作成果 以正式文档形式完整地描述系统的体系结构模型 文档内容引言体系结构概述需求视图逻辑视图进程视图实施视图部署视较长应用指南评审软件体系结构模型发现可能存在的缺陷 使相关人员能够达成一致关注点是否能够满足需求 以及怎样满足需求当异常或者临界条件出现时 体系结构是否以令人满意的方式动作详略程度是否恰当是否存在可行性方面的危险 软件体系结构设计的步骤 需求规图说明 软件设计计划 开发软件项层架构 选取设计资产 设计技术支撑方案 确定设计元素 开发软件部署模型 设计并发机制 构建体系结构模型 评审体系结构模型 软件体系结构文档 网上购物系统的顶层架构 HTTP请求 业务服务请求 数据服务请求 数据服务应答 业务服务应答 HTTP应答 数据持久存储机制的技术支撑方案 安全控制服务的技术支撑方案 体系结构部署图 3 5高可信软件设计 可信软件特点容错设计软件失效模式和影响分析软件故障树分析形式化方法净室方法嵌入式和实时软件设计 可信软件特点 可靠性 Reliability 在规定的环境在下规定的时间内 软件无失效运行的概率 可靠安全性 Safefy 软件运行不引起危险 灾难的能力保密安全性 Security 软件系统对数据和信息提供保密性 完整性 可用性 真实性保障的能力可生存性 Survivability 软件在受到攻击或失效出现时连续提供服务并在规定时间内恢复所有服务的能力实时性 RealTime 软件在指定的时间内完成反应或提交输出的能力 容错设计 软件容错技术 使得软件能发现失效危险并从临失效状态恢复的软件设计技术恢复块技术 检测到错误后将执行软件模块的另一个不同版本 在执行模块的一个版本前 首先要创建检查点 因为这有助于在该版本执行失效后恢复状态 并为检测到错误后执行下一个版本提供一个有效的起始点 N 版本编程 N 版本编程是一种多版本技术 关键模块的不同版本被设计成满足同样的基本需求 每个版本完成同样的任务 但却使用不同的方式 这些版本同时执行 它们的输出结果提交给一个表决系统以决定正确的结果 并把该结果返回给模块 对输出正确性的判定基于对所有输出的比较 出现不一致的情况下 利用多数表决来决定一个最优先的结果 基于设计多样性 通过以下方式可以达到设计多样性 使用不同的设计方法来实现需求使用不同的程序设计语言来完成实现使用不同的开发工具 且在不同的开发环境中完成 明确要求在实现某些关键过程时使用不同的算法 软件失效模式和影响分析 软件失效模式和影响分析 主要是在软件开发阶段的早期 通过识别软件失效模式 研究分析各种答失效模式产生的原因及其造成的后果 寻找消除和减少其有害后果的方法 以尽早发现潜在的问题 并采取相应的措施 从而提高软件的可靠性和安全性 软件失效 程序在中丧失了全部或部分功能 出现偏离预期的正常状态的事件 软件失效模式 软件失效的不同类型 通常用于描述软件失效发生的方式以及对设备运行可能产生的影响软件失效的影响 指软件失效模式对软件系统的运行 功能或状态等造成的后果 软件故