??xml version="1.0" encoding="utf-8" standalone="yes"?>
定pȝ需求即定pȝ用例。方法以Ҏ业务用例实现场景分析入,分析每个pȝActor的系l用例。每个系l用例一定是一个完整的事g,注意业务用例和系l用例的区别Q业务用例是一个完整的业务目标Q而系l用例是一个完整的事g,是业务目标中的一个环节,如客户代表申请开h一个完整的pȝ用例Q但不是一个完整的业务目标Q其包括多个面操作?/p>
3.11 用例实现分析
Ҏ个系l用例,识别其可能的实现路径Q每个实现\径就是一个用例实玎ͼ然后针对每个用例实现Q分析hZ互,使用zd囄制用例实现场景?/p>
3.12 分析模型
使用分析对象Q实现所有的用例实现场景Q识别出三种分析对象。在q个q程中,也可以徏立界面原型,和客戯一步达成需求的一致理解。分析模型是需求到设计的桥梁,分析cȝ层次高于设计实现Q需求通过分析c{成计机语言。后l做pȝ设计的时候,可直接将分析模型转换成设计模型?/p>
在考虑分析模型的过E中Q有可能识别Z些公共模块,比如开戗销戯E中都会有一些业务规则校验,需要引入规则引擎的支持Q那么类D则引擎这L公共模块需要添加到逻辑架构中去?/p>
3.13 非功能性需求设?/strong>
以性能Z讲一下对非功能性需求设计的q程?/p>
1、确定性能目标Q要支持多少用户、多在U用戗多ƈ发操作、操作响应时间要求等Q?/p>
2、以一个简单的三层架构v点,Ҏ性能目标Q识别瓶颈。比如,如果数据库撑不住Q那么需要考虑最佳的分库设计Q如果是逻辑层撑不住Q则要考虑负荷分担Q状态同步的逻辑层方案设计,如果操作响应旉要求很高Q则可根据不同场景,分析其操作的数据的读写特点,采用合适的~存Ҏ。如要支撑高q发低时延的大数据量查询QTwitter采用了垂直~存Qraw~存的设计方案?/p>
3、验证性能设计。抽取典型场景,实现一个prototype来验证性能设计是否满性能目标?/p>
在质量属性设计中Q如果需要新增模块,则需要修攚w辑架构?/p>
有一些约束类需求也是非帔R要的Q不能遗漏分析?/p>
l过q一个阶D,我们能够得到一个比较完整的逻辑架构Q运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作是~档的工作了?/p>
3.14 架构~档
有了上面的工作作为铺垫,~档非常容易了Q这个就不细讲了?/p>
分别针对上节中业务用例视图中的每一个用例,分析该业务用例在实际工作中是如何做的Q一般用业务活动图来表qC务场景。在q个阶段Q有几点需要特别注意的地方Q?/p>
1、关注参与业务用例的各个参与者是如何协同的,如一个简化的用户开L程是填写营业员提交开戯?》主审批订?》施工h员行订单;
2、对一个业务用例,如果有不同的实现路径Q需要做不同的场景分析。例如,用户订购产品Q分|上订购和营业厅订购q两U场景,两个场景大不相同Q?/p>
3、场景的步骤_度Q用L一个完整操作目的,如用户开P则用户填写订单是一个步骤,而不用细化到用户取单、拿W填单等Q?/p>
3.5 产生业务对象模型
针对每个业务用例Q根据业务用例场景,分析该用例中涉及的业务实体,q绘制业务对象模型图?/p>
3.6 产生业务用例实现视图
业务用例实现指业务用例的一U实现\径,一个业务用例实现对应着一个业务用例场景。业务用例实现视图是表述业务用例实现的视图?/p>
3.7 分析业务用例实现场景
业务用例实现场景着重描q如何通过人机交互来完成业务,是业务用例场景的具体化。一般用zd图来表述人机交互程。这里每个步骤的_度是h与系l或pȝ与h的一ơ交互?/p>
3.8 领域建模
领域模型是描q特定问题域的对象及其相互关pR领域模型对业务对象做了q一步的_。领域徏模的步骤如下Q?/p>
1、确定问题域Q如CRM中的客户模型比较关键Q我们决定对其进行领域徏模,则需要将设计客户业务实体的用例全部识别出来;
2、领域徏模:逐一分析涉及到操作客h型的业务用例场景Q识别领域对象以及对象之间的关系Q?/p>
3、验证领域模型:使用序列图作为工PZ领域模型来编排实现各业务场景Q如果能实现Q证明领域模型ok?/p>
领域对象跟业务对象有区别Q我认ؓQ业务对象不是领域对象。业务对象来自于业务用例Q是业务中客观存在的Q而领域对象是对业务对象做q一步抽象、精化后的结果,是h对业务的主观认识Q这是Z么不同厂商的产品模型会不一L原因Q而且q不是所有的领域对象都是Ҏ业务对象分析而来的。比如,某CRM产品面向全球市场Q可定制能力是关键,为提升可定制性,需要构Z个快速开发框Ӟq个快速开发框架也是Y件系l的一部分Q也是有领域模型的,但是它的领域模型跟业务对象没半点关系?/p>
3.9 产生逻辑架构草稿
通过上述步骤Q我们已l有了部分领域模型,针对每一个可直接映射C务对象一U的领域对象Q可规划相应的业务模块,如有开戯单,那么可以有订单管理,有客L理等。业务模块的划分_度可依据大概的工作量而定Q保证最低别的业务模块的工作量是大致均匀的。这仅仅是一个徏议,可以Ҏ目的实际情况决定?/p>
Z上述的成果,我们q只能Z个逻辑架构的草E,因ؓ我们q没有分析质量属性,后箋对质量属性做设计的时候,q有可能会引入新的模块。比如要让业务流E可快速编排、定Ӟ我们希望引入工作,那么逻辑架构中也要引入一个工作流模块?/p>
待箋。。?/p>
本hl历q不项目,一些项目的架构设计负责力很强,接到zM后,马上一头扎q设计,抽象Z堆玄玄乎乎的概念Q讲得h晕头转向的,让h觉得高深莫测Q但是,在会议上却被涉众提的一些简单的问题问得很仓促,I其ҎQ还是漏考虑了涉众的需求,被h提问而又~Z准备Q是不是很多人有cM的经验?Q)
我们q经帔R到的场景是设计h员通常Z些模型、概念争Z休,公说公的׃Q婆说婆的漂亮,其实模型概念q东西就像h的h生观和世界观Q是人对世界和h生的主观认识Q可能随着q龄阶段的变化而变化,而且有时候没有绝对的对与错,像有些人喜Ƣ金戈铁马,有些人喜Ƣ与世无争,我们很难说谁一定是对的一定是错的Q遇到这U清醒时Q我停下争论Q争论方各自拿出实际的业务场景来验模型,哪个模型对场景的满度更好,实现成本更低则更好,如果两个都挑不出刺儿Q随侉K一个即可?/p>
q有一些架构设计h员喜Ƣ创造一些与众不同的概念Q让人看上去昑־高深莫测。我觉得如果一个架构师能够用最的语言、文字把问题和方案讲清楚Q那才是真正的有水^Q你让h晕头转向的时间既是项目的成本Q因此,我们创造概念词汇的时候,需要从涉众的角度出发,我这里的意思不是盲从涉众语a词汇Q而是说出发点从涉众角度出发,如果涉众原本使用的语a不够准确Q我们可以跟他们一h讨,定义更合适的概念词汇?/p>
q有一个就是对软g竞争力的认识。有人通过包装一堆玄玄乎乎的概念来显得很高深莫测Q试N过q种方式让h觉得有竞争力Q我认ؓQ竞争力首先是要跟对手比Q其ơ一定是涉众能感知的Q能够涉众带来正向h值的Q比如省多少成本Q端到端业务程节约多少旉?/p>
我认为遵循一个科学的架构设计q程跟上提到的软g架构4+1视图法是架构设计的两个法宝,一个指导思维、定义输出,另一个指导如何来做,相辅相成Q确保架构设计h员全面而正的理解需求,做好需求^衡、设计^衡,设计出实用的、能落地的架构?/p>
下面我会按顺序讲解架构设计的q程Q以及每个步骤具体要做的事情?/p>
3.1 定涉众
一般来Ԍ涉众包括客户Q资方)、承接方Q劳方)、用戗我们通常扑ֈ代表某一cd的涉众群体的代表人:客户代表、劳方代表、用户代表等。访谈的时候直接找代表q行?/p>
3.2 定pȝ边界
对于要明实现某U标准的软gpȝQ通常定边界非常ҎQ直接按标准圈定的scope分析卛_Q比如像SIPServlet容器Q是要求遵从JSR168规范的,那么软gpȝ的Scope是JSR168规定的ScopeQ但是也有例外,比如客户或者劳Ҏ指定要复用一个现有的实现了部分功能的pȝ或组Ӟ那么Scope׃同了。对于没有标准的软gpȝQ就需要分别访谈客户代表、承接方代表定pȝ边界。ؓ什么要访谈承接方代表呢Q因为承接方代表往往是劳斚w|领导肩负企业战略达成的命,很有可能对系l提出比客户更多的要求。D个例子,某客户需要一个SIP通信协议栈,以实C斚w话的业务,但是x领导认ؓQ后lICT融合是趋势,我们构徏的系l要支持ICT融合应用部v和运行,支持业务标准JSR168规范?/p>
3.3 软g需求收?/strong>
软g需求可分ؓ二类Q?/p>
功能需求(即业务用例)Q描qActorQ用hpȝQ可Z软gpȝ做什么事Q要W合什么业务规则;
非功能性需求又可分Zc:
质量属性:质量属性指软gpȝ的品质,可分行期质量属性与开发期质量属性?/p>
q行期质量属性包?/p>
Q?Q性能Q性能是指软gpȝ及时提供相应服务的能力。具体而言Q性能包括速度、吞吐量和持l高速性这三方面的要求?br> Q?Q安全性:指Y件系l同时兼合法用户提供服务Q又L非授权用功能的能力?br> Q?Q易用性:指Y件系l易于用的E度?br> Q?Q可用性:可用性与易用性不相同。可用性指pȝ长时间无故障q行的能力?br> Q?Q可伸羃性:指当用户增加Ӟ软gpȝl持高服务质量的能力?br> Q?Q互操作性:指本软gpȝ与其他系l交换数据和怺调用服务的难易程度?br> Q?Q可靠性:软gpȝ在一定时间内无故障运行的能力?br> Q?Q健壮性:也称定w性。是指Y件系l在异常情况仍能够正常运行的能力?/p>
开发期质量属性包括:
Q?Q易理解性:是指pȝ设计能被开发h员理解的难易E度?br> Q?Q可扩展性:为适应新需求或者需求变化,Y件增加功能的能力。有些时候,UC为灵zL?br> Q?Q可重用性:重用软gpȝ或其中一部分的能力的难易E度?br> Q?Q可试性:对Y件测试以证明其满需求规U的难易E度。在实际的项目中Q主要指q行单元试{难易程度?br> Q?Q可l护性:修改BugQ增加功能,提高质量属性?br> Q?Q可UL性:Y件系l从一个运行环境{Ud另一个不同的q行环境的难易程度?/p>
U束Q规定开发Y件系l时必须遵@的限制条Ӟ如要Z什么操作系l,要基于什么开发语a{等?/p>
对于功能需求,可找pȝ的直接用用户代表,对其q行访谈Q收集其要基于系l做的事情,可按照标准的用例模板Q在访谈的过E中引导用户代表。之后,l制业务用例视图Qƈ针对每个业务用例Q用标准的用例模板功能需求编档,通常叫用例规U?/p>
对于非功能性需求,可找软gpȝ的涉众,依据下面的模板,引导涉众Q收集其对相应质量属性的要求Q?/p>
ȝQ本阶段需要输Z务用例视图,业务用例规约Q非功能性需求?/strong>
待箋。。?/strong>
软g架构设计的主题狠q难,本文打算从架构的概念Q架构的表述ҎQ架构设计的q程三个斚w来讲一下我的理解?/p>
一、什么是软g架构Q?/strong>
温昱在《Y件架构设计》一书中Q给了下面的定义Q?/p>
l合z:软gpȝ的架构将pȝ描述组件及lg之间的交互?br> 决策z:架构是一pd重要决策的集合,q些决策与以下内Ҏ养I软g的组l,构成pȝ的结构元素及其接口的选择Q这些元素在怺协作中明表现出的行为,q些l构元素和行为元素进一步组合所构成的更大规模的子系l,以及指导q一l织--包括q些元素及其接口、它们的协作和它们的l合--架构风格?/p>
在我看来Q决{派的定义更为具体和准确Q注意决{派用了元素q一词而没有用lgQ组件是有具体含义的Q指一个可独立替换的物理单元,而架构需要能够指导涉众,如开发h员、用戗部|h员等{,对开发h员来Ԍ开发过E中如何分包、如何将包打包ؓlgQ架构师需不需要提供指导呢Q答案是肯定的。因此,如果架构限定在lg和组件的交互上,是不完整的?/p>
二、架构的表述Ҏ
q个现在都有pQ就?+1视图表述法:逻辑视图Q实现视图,q程视图Q部|视图,用例视图?参见下图RUP 4+1视图Q?
用例视图xpȝ的h、事、物、规则,人是指系l的ActorQ包括业务主角和业务工hQ事是指pȝ用例Q物是指业务实体Q规则指做事情的前置条g、后|条Ӟ做事情过E中的规则。下面这个图很精辟:
用例视图?+1视图中的+1Q它定义需求标准,跟其它视图描q系l某一斚w的结构有很大的不同?
逻辑视图xpȝ的逻辑功能模块和领域模型,不仅包括用户可见的功能模块,q包括实现用户功能而必L供的“辅助功能模块”;它们可能是逻辑层、功能模块、类{?
实现视图xE序包,不仅包括要编写的源程序,q包括可以直接用的W三方SDK和现成框架、类库,以及开发的pȝ运行于其上的系lY件或中间件。开发架构和逻辑架构之间可能存在一定的映射关系Q比如逻辑架构中的逻辑层一般会映射到实现架构中的多个程序包Q再比如实现架构中的源码文g可以包含逻辑架构中的一到多个类Q在C++里一个源码文件可以包含多个类Q即使在Java里一个源码文件也可以同时包含一个类和几个内部类Q?
q程视图xq程、线E、对象等q行时概念,以及相关的ƈ发、同步、通信{问题?
q程视图和实现视囄关系Q实现视图一般偏重程序包在编译时期的静态依赖关p,而这些程序运行v来之后会表现为对象、线E、进E,q程视图比较x的是q些q行时单元的交互问题?
物理视图x“目标程序及其依赖的q行库和pȝ软g”最l如何安装或部v到物理机器,以及如何部v机器和网l来配合软gpȝ的可靠性、可伸羃性等要求。物理架构和q行架构的关p:q行架构特别x目标E序的动态执行情况,而物理架构重视目标程序的静态位|问题;物理架构q要考虑软gpȝ和包括硬件在内的整个ITpȝ之间是如何相互媄响的?
上面几个视图是最典型的视图,不管你是通信中间Ӟq是依赖于数据库的企业应用都需要的。对于依赖数据库的企业应用,通常q需?strong>数据视图Q数据视?/strong>x对象如何存储Q如数据库表{?strong>?/strong>
4+1视图不仅仅是软g架构的表q方法,它们各自从不同的视角d现架构,因此Q还是一U比较好的思维方式Q引导我们从不同的视角去思考,从而做出比较系l的架构设计?/p>
I竟什么是订单?
订单作ؓ一个业务Actor皆可感知的重要业务实体,其是qITpȝ而存在的QITpȝ所做的仅是其在Y件系l中以对象的形式表现出来Q不能依据系l实玎ͼ改变订单的定义。要正确的给订单下定义,d掉ITpȝQ从业务的角度给出定义?/p>
企业一般会有售前,售后Q销售,服务{部门,而订单是产生在销售活动中的,表示客户对企业品或服务的一ơ订购。依此理解,退换货是服务,不是订单Q而充值是订单。走不走程Q仅仅是订单实施的方式?/p>
q个案例告诉我们Q系l的业务模型Q要从业务的视角来徏QITpȝ是将业务模型用Y件概忉|表述Q不能改变业务概c?/p>