zoukankan      html  css  js  c++  java
  • Pre-architecture的需求

     

    架构设计分为三个阶段,包括Pre-Architecture阶段、Conceptual Architecture阶段、Refined Architecture阶段。

    1Pre-Architecture阶段

           Pre-Architecture是架构设计的最前期阶段,其工作目标是:理解需求、建立需求大局观、确定架构设计方向。通俗的来讲,就是在架构设计之初,来全盘考虑架构设计要重点支持的关键质量目标,并在第一时间就判断这些“关键质量”之间有没有冲突关系,并制定权衡取舍的策略,也就是说,通过在Pre-Architecture阶段,理解需求,来确定架构设计的目标。

           这个阶段关注对需求的把握和理解,可以采用需求结构化的方法,分析需求之间的关系。

    在这里,老师说了两句话:“关键质量属性决定技术架构、关键功能决定逻辑架构”。

    2Conceptual Architecture阶段

           Conceptual Architecture界定系统的高层组件,以及它们之间的关系。Conceptual Architecture意在对系统进行适当分解,而不陷入细节。借此,可以与管理人员、市场人员、用户等非技术人员交流架构。Conceptual Architecture规定了每个组件的非正式规约及架构图,但不涉及细节。

           在这个阶段,一般可以分为三个步骤:初步设计、高层分割、考虑非功能需求。

    2.1 初步设计

           基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计。这一步并不总是需要,但对于新系统而言,这是必须的。所谓鲁棒图分析是这样一种方法:通过分析用例规约中的事件流,识别出实现用例规定的功能所需的主要对象及其职责,形成以职责模型为主的初步设计。

        

    2.2 高层分割

           对系统这个黑盒子进行高层切分,例如切分复杂系统为多个二级系统,或者直接切分系统为具体子系统。

    2.3 考虑非功能性需求

           进行架构设计时,不仅要考虑功能,也必须考虑非功能,一般可以采用目标-场景-决策表的方法。

          

    3Refined Architecture阶段

           Refined Architecture是相对于Conceptual Architecture而言的,它们是Architecture Design的两个层次,分别对应于“概念级”和“规约级”解决方案。在Refined Architecture中,接口占据非常核心的地位,而Conceptual Architecture并不关心明确的接口定义,只有抽象的组件和抽象的交互机制;Refined Architecture重视通过子系统和模块来分割整个系统,并且子系统有明确的接口;Refined Architecture中的交互机制是“实在”的,而Conceptual Architecture中的交互机制是“概念”化的。(如下图所示)

           在这个阶段,一般采用多视图的方法。包括RUP 4+1视图,SEI 3视图。目前常用的是如下图所示的5视图方法,该方法是以4+1视图为基础,进行一定的改良而成的。

    Pre-Architecture:准备架构

    Pre-architecture就是架构设计的最前期阶段,其工作目标包括:理解需求、建立需求大局观、确定架构设计方向等。

      准备架构阶段,最最重要的是弄清楚要做什么东西,即掌握用户需求。应该来说,整个准备阶段都围绕着“需求”来转。

      我将它描述为如下过程:需求-->约束-->质量-->关键功能

      初学者根据上诉步骤,一步一步来,就能够完成准备架构阶段。

    1.需求

      可能有人会认为“需求应该来自市场人员”,这句话并不全面,需求不应该仅仅来自市场人员。

      记得本人接手的第一个项目时,市场人员告诉研发部门需要研发出一款产品,研发部门会成立一个项目小组,然后再指定一个研发人员做需求调研,写需求列表,这个做法现在觉得是非常不合理的。首先,研发人员没有市场经验,更不懂用户想要什么产品,就只能够照着别的公司的产品抄,最终肯定是抄个四不像。

      下面回到话题,需求应该来自哪里?应该是一拨人讨论出来的结果,这拨人就应该包括:市场人员+产品经理+架构师+项目经理。首先一款产品是否需要做,这是市场人员和产品经理所讨论的范畴,他们决定该如何定位此款产品,产品经理根据公司的技术实力,决定能否做。那么,接下来便是了解用户需求,前期的调研工作需要市场人员来做,并形成一个“初步需求列表”。有了“初步需求列表”,架构师和项目经理就应该考虑,并弄清楚每条需求,这里为什么需要项目经理的参与呢,就是为了保证该项目的负责人能够最清晰的明确做什么,接下来才能带领队伍把握关键指标。

      架构师在考虑需求的时候,如果只是笼统的来了解每个功能,这样各种需求混在一起就显得比较乱,最好可以参考ADMEMS矩阵法来进行划分:

    ADMEMS矩阵法

      广义功能 质量 约束

    业务级需求 业务目标 快、好、省 1.技术性约束

    2.法规级约束

    3.技术趋势

    4.竞争因素与竞争对手

    5.遗留系统集成

    6.标准性约束

    7.分批实施

    用户级需求 用户需求 运行期质量 1.用户群特点

    2.用户水平

    3.多国语言

    开发级需求 行为需求 开发期质量 1.开发团队技术水平

    2.开发团队磨合程度

    3.开发团队分布情况

    4.开发团队业务知识

    5.管理:保密要求

    6.管理:产品规划

    7.安装

    8.维护  

    从表中可以看出需求是分为层次的。

    业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件;

    用户级需求:用户使用系统来辅助完成哪些工作?对质量要求如何?用户群及所处的使用环境方面有何特殊要求?

    开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?

      对于此三类需求弄清楚之后,就可以形成一个初步的需求列表。

      基本上来说掌握ADMEMS矩阵表,前期的准备工作就算做完了。下面的小节是对其他概念做更加详细的解释。

    2.约束

      前面说了,整个阶段都是围绕“需求”来转,接下来的“约束”、“质量”都是对需求做限制的。那么何为“约束”?

      约束:制约项目发展的因素。

      首先,约束来自与需求又制约需求,比如“用户级需求”中提到了“用户群特点”的约束,就说明,本产品必须要考虑针对哪些用户群来做,要做一个儿童教育软件,就不应涉及成人的复杂理论和逻辑。这就是约束!

    3.质量

      质量,类似于“约束”,它更重视某一事物具备的属性。当然,有些时候可以把质量属性来当做约束,比如可移植性,可以把它看做是质量也可以当做一种约束来看。

      那么,作为一个架构师该考虑哪些质量属性呢?

      1.性能  2. 安全性 3.持续可用性 4.可靠性 5.鲁棒性 6.易用性 7.可测试性 8.可重用性 9.可维护性 10.可扩展性 11.可移植性 12 可互操作性。

      也不是说用户要把每一个指标都做上去。有些指标之间是相互影响的。其影响关系如下(+表示促进  -表示影响  空白表示无明显作用):

      性能 安全性 持续可用性 可互操作性 可靠性 鲁棒性 易用性 可测试性 可重用性 可维护性 可扩展性 可移植性

    性能       - - - - -   - - -

    安全性 -     -     - - -      

    持续可用行         + +            

    可互操作性 - -                 + +

    可靠性 -   +     + + +   + +  

    鲁棒性 -   +       +          

    易用性 -         +   -        

    可测试性 -   +       +     + +  

    可重用性 - -   +       +   + + +

    可维护性 -   +         +     +  

    可扩展性 - -           +   +   +

    可移植性 -     +       + + - +  

      架构师应该确定关键质量的优先级。并在《架构文档》中明确记录此要求。

    4.关键功能

       关键功能包含如下四个方面:1.核心功能;2.必做功能;3.高风险功能;4.独特功能。

      如何区别这四个方面,实际上是靠经验和感觉。它们之间实际上是有重叠部分的。

    核心功能:业务层接口所反映的功能。如,项目管理系统中,项目信息查看、添加任务等都属于核心功能;

    必做功能:必做功能实际上是以客户为背景的,简单来说就是愿景;

    高风险功能:顾名思义,哪些功能操作可能会涉及到安全和隐私等问题;

    独特功能:实际是上诉上个功能的补集,看看还有哪些没有覆盖到的,却又很关键的功能。

      架构师在设计阶段要考虑到“关键功能”所占有的比例,没有明确的标准,一般遵循:功能少的系统比例高一些,功能多的系统比例少一些。

    总结

      总得来说,准备阶段要做的最重要的一件事,就是弄懂需求,不管通过何种方式剖析和理解,只要弄懂架构的需求就算完事了!

    实际意义

    需求理解的大局观

    有效处理互相矛盾的需求目标;

    识别重大需求、特色需求、高风险需求;

    相对短的时间内设计架构;

    等等

    降低架构失败风险

    架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足。

    尽早开始架构设计

    Pre-architecture阶段的好处:能够在需求没有“全面完成”的情况下开始架构设计。

    为了尽早开始架构设计,需要做好:让架构师参与需求分析工作;不能被动地等待完善的《软件需求规则说明书》出现的那一刻。

    只要满足下面3个条件就可以开始架构设计工作:

    1.有了明确的业务需求:必须保证甲、乙双方就建设系统的目标达成共识,《愿景文档》经过正式评审,并且明确了投资、工期标准、整合等约束条件;

    2.了解全面的用户需求:系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术,表现为“用例图”比较完善,没明显遗漏;

    3.有了典型的行为需求;如果采用用例技术,表现为核心功能的《用例约束》已经定义;

    明确架构设计的“驱动力”

    除了需要关注《软件需求规格说明书》之外,必须关注其他很多因素,最终理性地确定真正的架构设计“驱动力”。

    实践要领

    不同需求影响架构的不同原理,才是架构设计思维的基础

    “需求决定架构”是对的,但不同需求影响架构的不同原理,才是架构设计思维的基础。

    不同需求是如何以不同原理影响架构设计:

    二维需求观与ADMEMS矩阵方法

    ADMEM方法提倡的“二维需求观:

    观念是行为的向导,有怎样的观念存在,就有怎样的行为方式产生。

    关键需求决定架构,其余需求验证架构

    关键需求决定架构:功能需求做减法;质量属性需求做加饭;约束性需求做加法;

    Pre-architecture阶段的4个步骤

    需求结构化

    需求结构化可以将复杂的需求集合梳理得井井有条,为进一步分析不同需求之间的联系、识别遗漏的重要需求打下坚实的基础。

    需求结构化要怎么做?

    1.超越《软件需求规则说明书》

    需求文档往往不够全面;

    需求经常变更,仅依赖需求文档往往使架构设计工作非常被动;

    架构师通过需求结构化真正全面地“鸟瞰”需求大局,就必须超越《软件需求规则说明书》;

    能够摆脱对《软件需求规则说明书》提交时间、文档质量、内容变更的“呆板依赖”;

    2.ADMEMS矩阵

    业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。

    用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?

    开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?

    需求还要从下面3个方面考虑:

    功能需求:更多体现各级直接目标要求。

    质量属性:运行期质量 + 开发期质量。

    约束需求:业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素

    分析约束影响

    约束性需求中隐藏了大量的风险因素。有经验的架构师都懂得主动分析约束影响,识别架构影响因素,以便在架构设计中引入响应决策予以应对(尽早识别风险)。

    分析约束影响的方法

    1.约束分类方式

    ADMEMS对约束分类方式进行革新,使它更符合实践的需要。不仅注意到约束对架构设计的重大影响,还强调约束分类理论应该直接体现“这些约束来自于哪些涉众”。

    如下图所示,4类约束在ADMEMS矩阵中表明:业务环境、使用环境、构建环境应分别考虑客户、用户、开发方这3类涉众,技术环境则与3类涉众都有关。

    2.使用Big Picture理解约束

    3.使用ADMEMS矩阵方法辅助约束分析

    从本质讲,分析约束影响就是分析各个需求项之前的关系,并发现被遗漏的需求。所以,将需求“化复杂为清晰”的ADMEMS矩阵方法可以作为分析约束影响的基础——即在需求项清晰定位的前提下,找到不同需求之间的关系、发现遗漏需求。

    ADMEMS矩阵方法应用法则:

    推导法则:从上到下,从右到左。

    查漏法则:重点是质量属性遗漏。

    确定关键质量

    确定关键质量目标意义

    指定错误的质量属性目标(包括遗漏重要的质量属性),将面临客户不满、项目返工、同事抱怨……

    确定关键质量主要完成

    1.根据系统所在领域的特点及系统规模等因素,确定架构设计重点支持哪些质量属性(例如高性能、可扩展性…)

    2.分析上述质量属性之间的制约关系,第一时间指定权衡折衷的具体策略(例如明确高性能是第一位,可扩展性和高性能相矛盾时应照顾高性能要求,是否引入支持可扩展性的涉及需经过架构组评审)

    确定关键质量的5大原则

    1.分类合适+必要扩充

    2.考虑多方涉众

    3.检查性思维

    4.识别矛盾+划定优先级

    5.严格程度符合领域和规模特点

    确定关键功能

    为什么不是“全部功能作为驱动因素”

    功能影响架构具体原理:职责协作链:

    不同功能的职责协作链之间可能有职责的重叠;在功能数量比较多的时候,职责重叠将是不可避免的。既然如此,没必要将所有功能都一视同仁地研究一遍。相反,在所有功能中筛选一个功能子集,研究功能子集中每个功能的职责协作链,从而识别出组成系统的所有职责单元。

    确定关键功能的4条规则

    1.核心功能

    2.必做功能

    3.高风险功能

    4.独特功能

    另外,确定关键功能子集时,必须注意:

    1.“关键功能子集”的确定并不存在“标准答案”;

    2.值得专门说明的还有“关键功能所占比例”的问题;

    1、架构设计开始的三个前提条件,明确的业务需求、全面的用户需求以及典型的行为需求,如下图所示:

     

     

    2、架构设计的“驱动力”:

     

     

     

    3、对于架构设计师而言,四大约束:业务环境约束、使用环境约束、构建环境约束、技术环境约束等;

     

    4、二维需求观

                       

    部分摘自:

    https://www.cnblogs.com/movezzzz/p/3328411.html

    https://blog.csdn.net/cui841923894/article/details/82973423

    https://www.cnblogs.com/BoiledWater/archive/2013/06/14/3135474.html

  • 相关阅读:
    最容易忽略的的前端面试基础题目
    关于浮动宽度不够掉盒子的问题解决方法
    最容易忽略的的前端面试基础题目
    构造字典
    Python数据类型---字典
    Python数据类型---列表
    Python数据类型---字符串
    我要学习Python
    [IT练习册]Python练习项目 思路
    【CTF】后续深入学习内容
  • 原文地址:https://www.cnblogs.com/muailiulan/p/12572061.html
Copyright © 2011-2022 走看看