北京大学软件工程国家工程研究中心建设概要-read.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 设计时设计决策 将用户接口与应用的其余部分分离开来 在开发和部署中，预计用户接口会频繁发生变化，因此单独维护用户接口代码会把变更局部化 使用以下模式 模型-视图-控制器 表示-抽象-控制 。。。 四、多重视图模型 体系结构设计中的一个困难是：一个规模系统的体系结构通常非常复杂，不同的相关人员关注体系结构的不同方面，如何处理这种复杂性——多重视图模型 其中最著名是Rational公司提出的“4+1”模型 逻辑视图 开发视图 物理视图 进程视图 场景 终端用户 功能 集成人员 性能 可扩展性 系统工程师 拓扑 通讯 程序员 软件管理 逻辑视图 关注功能需求，即系统应该为用户提供什么服务。逻辑视图同应用领域紧密相关 在该视图中，系统功能映射到概念构件和连接件。例如，管道—过滤器风格中的构件和连接件 针对终端用户的关注，通常使用领域术语，并同软件和硬件细节无关 进程视图（或称执行视图） 重视一些非功能需求，例如性能、可扩展性等，定义了运行实体和它们的属性 它也有构件和连接件，构件是任务，连接件是消息、RPC、事件广播等 该视图的主要用户是系统设计人员和集成人员 开发视图 关注开发者和项目经理的兴趣 该视图的构件和连接件分别映射到子系统或模块，聚焦于在软件开发环境中，软件模块的组织。软件被打包为子系统，并按层次组织 物理视图 考虑可用性、可靠性和可扩展性等 把不同的元素，如网络、进程和任务等，映射到不同的节点上 场景视图 场景通常是最重要的需求。场景一方面作为设计中发现体系结构元素的驱动器，另一方面在设计完成后，充当确认和例证的角色 场景应当是明确的，诸如陈述“系统应当是可修改的”是没有意义的，相反，关于修改性的一个可能的场景是“应用容易增加以下类型的新特性……” 相对于其它方法，多重视图模型是最为成熟和获得广泛应用的。每种视图都有特定的符号体系和工具支持 逻辑视图：Rational Rose的类图 进程视图： Universal Network Architecture Service (UNAS)中的 Software Architects Lifecycle Environment (SALE) 开发视图：Apex or Rational Rose 物理视图：UNAS 场景视图：use case图 事实上，对一个体系结构而言，不是所有的视图都是必须的。该方法提供了一个框架，具体到一个项目，取决于设计人员决定哪些视图是有用的 例如，如果软件中只有一个进程，那么进程视图是可以省略的 该模型把一个复杂的体系结构分为若干松耦合的视图，这使得不同用户可以更易于从不同方面理解体系结构 设计工作变得简单和明确。基于有效的通讯和协调，设计人员可以并行地工作在不同的视图上 允许设计人员在每个单个的视图上应用不同的设计方法，例如不同的体系结构风格应用于不同的视图，而不会相互冲突 潜在的缺点 在体系结构设计和详细设计之间没有清晰的界限。所有的视图都可以用于两类设计中；一些表示法，如类图、use case图也可以用于详细设计中，这使得体系结构设计的输出缺乏良好的定义 另一个值得关注的是UML是一种通用建模语言，UML源自面向对象设计，并广泛用于详细设计中。尽管它能支持大多数的体系结构概念，它缺乏进行详尽分析所需要的语义支持 五、基于评估和转换的设计 类似于传统软件设计的原型方法，该范型倡导首先满足功能需求，然后通过迭代的评估和转换满足非功能需求 需求规约 应用系统 体系结构 非功能需求 优化解决方案 基于功能的 体系结构设计 体系结构转换 评估非功能 需求的价值 OK Not OK 体系结构评估 四种评估方法 场景 (scenarios)：基于场景的评估是目前研究和应用最为广泛的方法，适用于开发性非功能需求，例如可维护性、灵活性等。运用效果依赖于场景的质量 仿真 (simulation)：对基于场景方法的补充，特别是评估操作性非功能需求方面，例如性能、容错等。仿真方法要求体系结构的主要元素被实现，而其它元素被模拟为环境 数学建模 (mathematical modeling)：允许静态评估体系结构设计，利用现有的数学模型，例如高性能计算、可靠系统、实时系统等 客观推理 (objective reasoning)：有经验的软件工程师和设计人员具有有价值的洞察力，这种能力在体系结构设计中非常有用。该方法区别于其它方法之处在于，评估过程是非显式的，更多地依赖于直觉和经验等主观因素。这种分析经常始于某些东西是错的，然后客观论点被构