软件系统设计讲稿.pptVIP

* * * * 领域逻辑中，人们总是搞不清楚什么事领域逻辑，什么是其它逻辑。例如，一个销售系统中有这样一个逻辑：如果本月销售量比上个月增长10％，就要用红色标记。要实现这个功能，你可能会把逻辑放在表示层中，比较两个月的数字，如果超出10％，就标记为红色。????这样做，你就把领域逻辑放到了表示层中了。要分离这两个层，你应该现在领域层中提供一个方法，用来比较销售数字的增长。这个方法比较两个月的数字，并返回boolean类型。表示层则简单的调用该方法，如果返回true，则标记为红色。 * * * 比如在快速开发windows界面的应用时，往往会用到一些对数据库敏感的控件，这种处理方法跨越了三个层次，但是却很实用，成本也比较低 * * * * * * * * * * * * * * * * * * * * * * * * * 不管是人还是系统，所有和系统有交互的东西都认为是参与者 一个用例代表使用系统的一种方法，是系统对参与者所引发的事件的一系列的反映 一个用例可以有多个参与者，一个参与者通常会使用多个用例 * * * * * * * * * * * * * * * * * * * * * * 这是因为软件架构规划与设计主要就是以巨观(Macro View)的角度切入系统架构，一般所谓的设计(Design)则是以微观(Micro View)的角度切入。比如一般设计师通常考虑的层次是一个使用者按下按钮时所发生的状况，而架构设计师考虑的则是成千上万个使用者按下按钮时所发生的状况。架构设计师规划系统的角度主要都是从Top-Down方式着手，而一般设计师则是多半从Bottom-Up的方式着手。另外，就以大家耳熟能详的设计模式(Design Pattern)为例，其实它也被称为微架构模式(Micro Architecture Pattern)，而诸如Model-Control-View (MVC)等涉及架构层次的Pattern则被称为架构模式(Architecture Pattern)。这种巨观/微观的角度分野，在其它学科也常看见，如总体经济学与个体经济学，大历史观与微历史观等等。这种巨观角度的本质，就是架构设计师专业领域与其它软件开发人员最根本的不同之处。 * 我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复杂度。 * * * * 抽象是扩展性和重用的基础 举例：分成和桌球游戏 用一个简单的动词短语来命名类或方法的，那就会是比较好的分类方法。 归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类（例如Beans）。我们可以借用Java中的一句话来概括降低耦合度的思想：针对接口编程，而不是针对实现编程。  们仔细的观察GOF的23种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的。同样，我们去观察Java源码的时候，我们也可以发现，Java源码中存在着大量的抽象层次，初看之下，它们什么都不干，但是它们对系统的设计起着重大的作用。 * * 我们在进行架构设计的时候，往往主要考虑的都是平台、语言、开发环境、数据库等一些基本问题，可是对于和客户的具体情况密切相关的一些问题却很少系统的考虑。甚至还存在一种误区，认为架构设计无非就是写一些空话，套话。这样子做出来架构设计，如何用于指导软件的实现呢？ IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术？ 每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益的架构？ * 常见的两种方法：“Code 按的Fix”以及“Planned Design”。 好比如果方向错了，交通工具再快，反而导致错误的快速扩大 * 业务与技术分离的框架设计 在不稳定的环境中寻求稳定因素 坚持面向接口编程的设计方法 实现完全面向对象的业务实现 业务分析和设计与技术实现无关 便于业务的扩展 便于业务的维护 技术实现参考Sun的JDO和Apache Hibernate，进行了折衷 业务与技术分离的框架设计 数据库设计 活动数据库 依据业务的分析，建立一致的，无冗余的基本数据模型。这也是实现一致的、灵活的、易于维护的业务功能的基础 运作数据库 在活动数据库基础上，将应用系统中的数据经过统一加工和格式转换后的汇总 业务分析库 在运作数据库的基础上，依据不同的统计分析需要，按照不同指标，生成统计分析的基础数据 统一报表 报表数据、显示分离 多种报表格式支持 高效的数据抽取 报表灵活配置 服