您的位置:首页 > 运维架构 > 网站架构

什么是软件架构

2016-05-24 17:47 344 查看
一、概述

二、目的

三、项目背景

四、系统建设目标

五、参考资料

六、架构设计

六.1 架构分析

六.2 设计思想

六.3 架构体系

六.4 系统视图

六.5 模块划分

六.5.1 模块描述

六.5.2 模块接口

我们在做架构设计文档一般分为两个层面:

1 技术架构设计。

从技术的解决上来讨论,着重点是讨论采用什么样的技术,如何分层,采用了那些好的技术特性。采用这些技术特性会为我们的工作带来哪些好处。为什么要这么做。

2 体系结构设计。

从业务需求的角度来出发,理清物理结构图和逻辑结构图。

划分每个子模块,为什么要这么划分,以及各个只模块之间的交互关系,每个子模块具有哪些接口。

这个是要求对需求的把握十分到位,是用设计对需求的映射,重点是要理清整个系统的脉络。

其次需要明白到底何谓架构,其实我觉得一个形象的说法就是骨架,每个人、每栋房子都需要有骨架,基于这个骨架可实现用户的功能需求以及非功能需求,

那么就可以说这是个成功的架构,我觉得在架构设计文档中最重要的是体现出对于系统需求的共性的分析,抽象形成系统的底层支撑子系统(注意,这个子系统是系统业务的共性,而不是具体的功能模块,具体的功能模块是基于此支撑子系统进行搭建的),同时列出系统的非功能性需求,提出在架构级别的应对策略,在经过这个架构分析过程后,根据系统结构是C/S、B/S可提出一个底层架构体系,如B/S采用MVC思想搭建的架构体系,在M进行划分形成N层体系,在做出了底层架构体系设计后将之上架构分析中产生的支撑子系统与之进行融合,同时结合非功能性需求的应对策略,在这个情况下系统的架构图就产生了。

经过这样的过程你系统的架构图就不会是无缘无故产生出来的,在架构图产生后此时就需要做技术的映射,因为在架构图的底层架构体系中列出来的是layer,那么每个layer其设计模型是怎么样的、每个layer的依赖是怎么解决的,在解决完了这个部分后需要对之上的支撑子系统进行设计模型、接口的描述,在完成了这些后即可绘制系统的部署视图、逻辑视图以及物理视图,重要的是需体现出整个系统的需求是如何基于这个架构体系来实现的,在完成了之上的过程后整个架构设计过程可以算是完成了大半部分,

在这之后进行支撑子系统的模块划分以及系统功能模块的划分,划分原则依据功能内聚来进行,同时也需考虑架构体系的设计约束,在划分完毕后即产生了系统的模块视图,同时需标明模块的接口关系,

在此图绘制完毕后按模块对模块的职责进行描述,同时对其接口做出规范,至此整个架构设计文档才算是比较完整的完成了。

这样写下来我想这份架构设计文档想薄都难呀,架构设计文档作为整个系统后续的设计约束以及方向指导而存在。

这是在这次写架构设计文档后的一些感想,总体来说我觉得最重要的仍然是需要明确的知道架构设计文档的目的,

何谓架构?架构设计的过程,架构对于需求的满足,在这之后可进行模块的概要设计,模块的概要设计其实同样是一个由繁化简的过程,产生出关键类以及类的接口设计,详细设计则是具体的对象设计以及接口实现。

然后问一问自己如下问题:

1、工作目标是什么?

2、职能是什么?

3、具体办法是什么?

4、所存在的主要问题和困难是什么?

5、改革发展方向是什么?

6、关注的焦点是哪些?

7、业务定位是什么?

回答了上述问题后,你就能够清楚的就业务目标、业务范围、业务功能、业务流程做出规划与回答。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: