软件架构设计的思想与模式

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

我们认为,一个设计如果必须高手云集才能生产出符合质量要求的产品,并不一定是好的架构。架构设计的目标1、是力争以较低、现实的成本生产出符合质量要求的产品;2、以较低、现实的成本设计更好的适应变更的架构。

架构设计绝不是某个神秘人物冥思苦想然后又自鸣得意的产物,架构设计应该是集体智慧的成果,软件设计与开发也应该是集体共通劳动的结果,重要的是各种相互矛盾的要求的合理平衡,这都需要有非常良好的方法,把团队的智慧集中起来,如何充分激发集体的智慧,也是一个架构设计师必须具备的能力。(架构师有时会疲于去解决这些矛盾)

好的架构设计必须以深入全面的需求分析作为基础,事实上架构设计是没有统一的模式的,任何模式只有针对问题才有意义。作为架构设计来说,必须对需求分析有足够的理解,这样才能有针对性地解决问题,才可能设计出真正优秀的产品来。但是,如果需求分析本身问题的信息就不足,那怎么可能设计出解决问题到位的架构来呢?

另一方面,任何架构思想的实现,都依赖于好的项目管理。项目管理必须与架构思想相匹配才能发挥作用。一个好的架构设计,必须关注成本,也必须关注时间,以期在约定的时间内、不超过规定的成本、生产出符合质量要求的软件产品来。因此,系统架构师应该仔细研究现代项目管理的思想和方法,吃透其中的精髓,根据自己的设计思想,提出项目管理的解决方案。

作为一个架构师来说,上述的讨论引发了三个核心思维,一个是架构设计的源泉来自于需求分析,第二个是架构设计重心和特点来自于质量需求(非功能性需求),第三个观点是,架构的实现依赖于好的项目管理。因此,软件架构设计是一个系统工程,它需要系统构架师有很宽的知识面,从需求分析、架构设计到类设计甚至代码实现一直到项目管理都需要有透彻的理解。

评审是一个很重要的环节。

其中主要包括:软件架构原理和风格(如设计模式),软件架构的描述和规范,特定领域软件架构(如第三方领域、金融、医药),构件如何向软件构架的集成机制等。

事实上架构设计是不可能独立存在的,架构设计提供的是用户需求的解决方案,所以一个架构师对需求分析的要点和关注点需要有深刻的理解,否则是不可能有好的架构设计的。

什么是需求呢?产品为用户在特定的背景中所必须满足的约束就是产品的需求,需求的表达

一般是抽象的而且与技术无关的,这样主要是避免对技术方案产生影响

软件的质量问题往往表现为缺陷(bug),软件缺陷的产生主要有两个原因:软件产品的

特点和开发过程。例如:

需求不够明确,开发人员不太了解需求,不知道应该“做什么”和“不做什么”,常常做不合需求的事情,这方面的问题最多。

由于竞争激烈,过早使用新技术也容易产生问题。

有的企业为了在时间上取胜,认为实现很新、很酷的功能比质量更重要,因此时间上安排很紧,分析和设计的投入远远不够,测试也不到位,这是产生软件错误的主要原因之一。 除此以外,设计文档不清楚,文档本身就存在错误,沟通上存在问题,项目管理水平差,都可能导致问题。

⏹概括起来可以有七项原因:

项目期限的压力。

产品的复杂度。

开发人员的疲劳、压力或者受到干扰。

缺乏足够的知识、技能和经验。

不可解客户的需求。

缺乏动力。

按出现问题的排位看,第二位是设计,第三位是编码。如果从软件开发各个阶段造成缺陷的分布来看,编码以后阶段的错误也要比前两个阶段少。正是对这个问题的理解,作为架构设计人员来说,有必要对需求分析的思想和方法有透彻的理解。

如果还不太清楚要构建什么产品就开始构建了,那项目出现问题几乎是确定无疑的事情,但是,这并不等于需要完全理解需求以后才可以构建,也不意味着所有的需求都要写成书面的形式,而是意味着只有注意需求,才可能向用户提交有用和可用的产品。

需求的表达常常是抽象的,以一种与技术无关的方式表达,这样做的目的是为了避免解决方案对技术产生影响,需求是对业务方面的说明,而不能有任何技术实现上的偏好,产品设计的角色是把需求翻译成一个计划,按这个计划就可以构建出一个实体。

相关文档
最新文档