架构师架构流程
2016-02-19 16:00
501 查看
首先是需求分析
需求分析从三个层次进行,客户,用户以及开发,客户级别就是公司的领导意图以及需求方投资人的意图,比较高层的需求,比如项目周期,资金,目的,以及其他需求;用户级别,就是真正的使用的需求,,第三个就是开发级别,比如项目的团队成员,需要哪方面的技能;接着是每个层次都从三个维度进行分析,功能性的,比如机务维修系统,这个系统的目的就是要算明白钱,深航领导就是想要知道钱都花在哪些地方,因为之前他们使用Orcal海波龙的财务系统,计算的维度和口径比较粗,而且和领导的想要看到的内容不太一样;质量
需求分析之后,作为架构师了解了项目情况开始对需求进行梳理,使用序列图对流程、职责、业务内容进行梳理;这种梳理不是全部需求的梳理,而是核心业务的梳理;核心业务的含义:必做的,共同的,特殊的;
接下来就是需求转设计,高层架构设计。
首先使用鲁棒图对业务进行时概念设计,鲁棒图用来识别终端,控制以及实体三种图例,比如中广核的调拨,通过画鲁棒图,识别出来,终端包括:仓库管理员输入页面,SAP;业务包括:输入业务,校验,入库,通知SAP,实体是调拨历史记录,仓库信息;接着是基于Layer以及tire进行分层,顶层是UI,中间是逻辑,逻辑划分为应用层,核心层以及基本信息层,其中最重要的就是核心层,就是将操作的原子操作进行识别,比如中广核项目,尽管流程比较负责,其实本质就是UP的添加修改,以及仓库的进出,订单操作,发货操作,检验、入库都是基于底层的本质的操作一种组合而已;基本信息就是字典表等,配置信息表的封装;
第三部就是落地架构设计
从逻辑视图,数据视图,物理视图以及开发视图四个视图分别进行设计,比如逻辑视图,上面基本划分出来职能块了,那接下来就是设计职能类;调拨系统,调拨分为同场调拨和跨场调拨,基本操作是一样的,但是有一个差别就是通知SAP,这里就抽象出调拨的基类,实现入库功能,通常和跨长分别继承基类;再比如海尔物联家电的架构,因为MINA系统本身就是事件驱动的架构,做的扩展也是基于事件驱动,架构出事件接收器(继承AdapterHandler,实现messagereceive,实现对上报协议的解析),事件分发器(dispatcher,类似于factory,基于解析的出来的协议内容,转发给相应的事件处理器)以及事件处理器(比如上报协议,下发协议,升级协议等);数据视图就是数据库设计;物理视图就是物理部署,需求转设计中也有一个基于分层分块的设计,但是那个是"可以达到"的设计,物理视图则是根据需要,设计到底部署几台服务器,每台服务器功能职责是什么(商用空调和家用空调,在部署上一定要分开部署,两个tomcat);最后一个是开发视图,就是基于质量需求,选择技术(缓存,数据库,代理服务器),项目树结构怎样,包来怎么设计,还包括管理机制,Maven+Jekins,还是ant等等;
需求分析从三个层次进行,客户,用户以及开发,客户级别就是公司的领导意图以及需求方投资人的意图,比较高层的需求,比如项目周期,资金,目的,以及其他需求;用户级别,就是真正的使用的需求,,第三个就是开发级别,比如项目的团队成员,需要哪方面的技能;接着是每个层次都从三个维度进行分析,功能性的,比如机务维修系统,这个系统的目的就是要算明白钱,深航领导就是想要知道钱都花在哪些地方,因为之前他们使用Orcal海波龙的财务系统,计算的维度和口径比较粗,而且和领导的想要看到的内容不太一样;质量
功能(系统的目标是什么) | 质量(对于系统在使用层面上达到那些标准)可用性,性能,伸缩,扩展等 | 约束(用户的水平,特殊的要求) | |
客户 | 机务维修系统,这个系统的目的就是要算明白钱,深航领导就是想要知道钱都花在哪些地方,因为之前他们使用Orcal海波龙的财务系统,计算的维度和口径比较粗,而且和领导的想要看到的内容不太一样 | 能够相对准确的计算出成本 | 历史遗留系统amicos,需要和它进行交互;需要和现有的财务系统进行交互;交互的方式只能是通过深航的数据交换中心; |
用户 | 预算,C检(机身,其他) | 使用人数上面100人左右,对于性能要求不高;海尔那个项目就需要考虑用户20万 | 机务维修用户水平比较高,可以在操作上有一些高要求;对于中广核项目,因为供应商接口使用者不可控,所以要求易用性要高; |
开发 | 海尔项目对于质量要求性能比较高,伸缩性要求比较高,设计需要考虑 | 海尔项目开发人员经验不多;技术要求基于Linux;开发语言Java;中广核项目要求基于windows2008,C#开发; |
接下来就是需求转设计,高层架构设计。
首先使用鲁棒图对业务进行时概念设计,鲁棒图用来识别终端,控制以及实体三种图例,比如中广核的调拨,通过画鲁棒图,识别出来,终端包括:仓库管理员输入页面,SAP;业务包括:输入业务,校验,入库,通知SAP,实体是调拨历史记录,仓库信息;接着是基于Layer以及tire进行分层,顶层是UI,中间是逻辑,逻辑划分为应用层,核心层以及基本信息层,其中最重要的就是核心层,就是将操作的原子操作进行识别,比如中广核项目,尽管流程比较负责,其实本质就是UP的添加修改,以及仓库的进出,订单操作,发货操作,检验、入库都是基于底层的本质的操作一种组合而已;基本信息就是字典表等,配置信息表的封装;
第三部就是落地架构设计
从逻辑视图,数据视图,物理视图以及开发视图四个视图分别进行设计,比如逻辑视图,上面基本划分出来职能块了,那接下来就是设计职能类;调拨系统,调拨分为同场调拨和跨场调拨,基本操作是一样的,但是有一个差别就是通知SAP,这里就抽象出调拨的基类,实现入库功能,通常和跨长分别继承基类;再比如海尔物联家电的架构,因为MINA系统本身就是事件驱动的架构,做的扩展也是基于事件驱动,架构出事件接收器(继承AdapterHandler,实现messagereceive,实现对上报协议的解析),事件分发器(dispatcher,类似于factory,基于解析的出来的协议内容,转发给相应的事件处理器)以及事件处理器(比如上报协议,下发协议,升级协议等);数据视图就是数据库设计;物理视图就是物理部署,需求转设计中也有一个基于分层分块的设计,但是那个是"可以达到"的设计,物理视图则是根据需要,设计到底部署几台服务器,每台服务器功能职责是什么(商用空调和家用空调,在部署上一定要分开部署,两个tomcat);最后一个是开发视图,就是基于质量需求,选择技术(缓存,数据库,代理服务器),项目树结构怎样,包来怎么设计,还包括管理机制,Maven+Jekins,还是ant等等;
相关文章推荐
- Android---学习网站大全
- 理解RESTful架构
- IM系统架构设计之浅见
- 小小商城的一次前端架构演变
- 端游、手游服务端常用的架构是什么样的
- 大型网站图片服务器架构的演进
- 每个架构师都应该研究下康威定律
- ios开发之判断framework支持架构及静态库合并
- 从技术细节看美团的架构
- 大型网站架构技术一览
- 来自Uber的12条架构重构经验
- 迁云架构实践
- 关于WEB三层架构的思考
- 关于大型网站技术演进的思考(二十一)--网站静态化处理―web前端优化―下【终篇】(13)
- 关于大型网站技术演进的思考(二十)--网站静态化处理―web前端优化―中(12)
- 关于大型网站技术演进的思考(十九)--网站静态化处理―web前端优化―上(11)
- 系统架构精选
- Android 开发的五大开源网站
- 关于大型网站技术演进的思考(十七)--网站静态化处理―满足静态化的前后端分离(9)
- 别学框架,学架构