1 前言
软件架构设计是软件设计的一部分,相当于总体设计,是软件设计过程中一个决定性的环节,架构确定了,软件基本也就定型了。而软件架构师则是软件项目的领军人物,是软件设计过程中最具挑战性的角色,从技术角度来讲,他承担了项目的成败责任。
EEEC给“架构师”的定义为“软件架构师是技术主管”,这就意味着他不仅要有高超的技术才能,还要有很好的领导才能,他的领导能力在团队中和软件质量控制中起着十分重要的作用。作为一个架构师,他要掌握整个软件项目的前景,调节各小组间关系,要让所有的项目组成成员了解大家共同的目的和目标,并发布标准和章程;要能正确理解软件过程,要在宏观上拥有专业知识,应该拥有很好的设计技巧;要是一个很好的沟通员和谈判代表,要能做出正确的决策等,除此,还有许多他要具备的其它素质。
2. 做好需求调研和分析
为保证软件的可用性,要从需求出发设计架构,即:做软件先做需求,这是软件业内人士的共识,但这项工作做得好的却很少。根据调查,属于需求分析和软件设计错误与缺陷的约占软件错误与缺陷的64%;而属于程序代码错误的仅占36%;而因软件错误积累与放大效应,造成整个软件项目拖延或失败情况的高达20%~60%。这些数据表明,搞好需求调研和分析是软件设计和开发的第一步。架构师必须要在需求调研的初期就介入,以保证需求获取的及时、可靠、准确,并对下步工作起指导作用。进行需求调研,不能就事论事,对用户的需求调研要全面、细致。需求要进行全局性的分析,需要有全局的观点,而不是分散地、根据具体的应用开发而进行的调研,这样才能系统地、本质地、概括地把握软件的功能结构。在调研过程中,自始至终都要有用户方的业务人员参加,尤其是强调高层管理人员的重视和亲自参与,架构师及其相应的工作小组要有足够的沟通和理解能力,要能使业务人员在需求调研阶段起主导作用,架构师仅起协助和引导作用,并提供需求调研的科学方法和过程。
2.1 熟悉建设单位,定义职能域
在需求调研阶段,架构师首先要全面了解用户中所有人员的需求,首先要了解建设单位的组织机构、业务关系,并根据建设单位中的一些主要业务活动领域,研究定义职能域,这是第一重要任务。职能域是用户功能规划的抽象,应符合建设单位内部各种业务的逻辑关系,而不是现行机构部门的翻版,一经识别,就要保持相对稳定。研制职能域模型时,需要特别注意,要自顶向下规划,并把握好设计职能域的数目;注意用户需求的主次关系,按照重要性、优先级进行权衡取舍。
2.2 详细调研各项业务过程及其功能分解
每个职能域都包括一定数目的业务过程,业务过程可以继续分解为业务活动(对应于未来的软件功能),每个功能再分解为更低层的功能,逐级向下分解,直到产生最基本的、不可再分的最小功能单元。
职能域和业务过程都要独立于当前的组织机构,因为组织机构可能变化,部门的分工也会变化,但整个单位的基本职能和业务相对稳定。职能域或业务过程可能横跨两个或多个业务部门。业务过程的确定可以对照组织机构中各部门负责人的职责来考虑,这样,也可能获得未来软件的操作权限、数据权限的分配和功能模块的划分,这些业务过程是一个单位运作的基本工作,不受报告层次和具体负责人变动的影响。
调研前,架构师要对调研的内容事先准备,针对不同管理层的用户询问不同的问题,列出问题清单,将操作层、管理层、决策层的需求既联系又区分开来,形成一个金字塔,使下层满足上层的需求。调研时,要收集用户工作中涉及的所有内容,如各种单据、报表、处理规则,再将其串成流程图,以流程图为主线,同时把握以下方面:
(1)该流程中是否存在不必要的环节;
(2)流程是否可以简化,是否可以省略一些环节;
(3)流程中的每个处理环节是否起到了增值提效的作用;
(4)哪些流程可以并行处理。
2.3 在调研具体业务时工作小组要把握的重点
(1)平均频度
业务发生的频繁程度称为频度,这个数字可以是一个平均值或统计值。频度越高,数据量越大,对响应时间、易操作性等要求就越高。在数据存储时,对大频度的业务或单据要进行充分的考虑。
(2)高峰期的频度
必须保证软件在高峰期的响应时间,对软件进行测试时,要模拟高峰期的业务频度。
(3)单据要求
单据上的内容也就是单据的属性,它是进行数据结构设计的最基本依据。数据的精度是定义数据库中字段长度的依据;计算生成方法是设计算法的依据;取值范围与计算生成方法是数据完整性检测的依据。
(4)利于减轻工作量
减轻人员的工作量是采用新软件的一个目的,花费时间最多、处理方法最复杂的地方往往是软件最关键的地方,也是用户将来验收时最关心的地方。实际上有很多报表由于工作量相当大,用户没有足够的人力与时间来进行处理,这时他便想到了计算机。
(5)单据报表流程
要了解单据或报表的来源、单据联数、每联用途、送交单位、送交时间,对来源与去向的追踪可以调查出各个业务、各个单据、各个报表及各个部门之间的联系。
(6)特殊情况的处理与纠错
对于特殊情况的处理,体现了软件灵活性,但这其中也隐含着安全危机。用户领域中有很多“合理但不合法,不合理也不合法”的特殊情况,它们出现的机会比较少,在调研时要将这些易遗漏的问题挖掘出来,这些特殊情况有时是软件必须要处理的。
当用户在某个作业环节出现失误时,手工软件有的采用正规的手续进行纠错,有的则相当随便,这些情况出现的概率也很小,在调研时,可采用穷举的方法,假定在每一个环节都出现失误,逐个环节询问用户的处理方法,防止遗漏。这些细节如果不调研清楚,往往会对软件产生深远的影响。
(7)考虑长远
将来用户需求的变化是很正常的现象,如果仅仅着眼于现在,而不对将来有所考虑,软件的寿命便不会长久,要将以后可能的变化考虑在内。需求获取后,务必要将调研的成果编制为文档,可视化需求调研,提供不同的图给不同层次的用户进行确认。对高层领导,可提供总体职能域图或业务流程图,对业务管理人员可提供业务流程图或业务活动图,甚至可以画出用户界面的草图。
3 需求分析与设计
架构师所带领的团队做出的关于软件体系结构的决策,将直接影响软件开发的难度和软件维护的难易度,最终决定软件开发的成败。
作为一个架构师,在进行架构设计时,必须具备以下基本能力:
(1)他要把整个团队组织在架构周围,并积极地投入到计划活动上,要把架构转化完成任务的先后顺序,这样才能及时地确定在什么位置用什么技术。
(2)架构师要在技术上做宏观决策,不必关心细节化的事情,由于技术的变化过于频繁,架构师要时与这些变化同步;架构师必须至少能对各种技术有一个整体上的了解,能够熟知每种技术特点及优缺点,只有这样,架构设计师才能在特定的应用场景下,正确地选择各种技术来设计软件架构。
(3)架构师要能预测最小化项目中可能出现的风险,因为这直接影响到软件架构的稳定性。
(4)架构师要能与开发人员保持良好的沟通,确保软件设计的实现。
[来源:万方数据,作者:孟莲蓉]出处:http://www.chinasa.info/article/sa001.html
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。
更多原创文章详见: http://chillyc.info