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

软件架构

2016-01-01 15:15 387 查看
总览:
架构作用:组成和决策
方法:物理 逻辑 数据 开发 运行
过程:需求分析 领域建模 确定关键需求 概念性架构设计(关键需求解决策略) 细化架构(5视图) 验证架构
个人技能:编码 设计 UML 工具 软件过程
比如 解耦合,依赖关系 角色理论 设计模式

架构思想 :组成+决策
领域模型 :概念抽象+关系抽象 | (业务)目标+用户(用例)+行为(流程)
模块划分 :水平+垂直 (EDD,功能模块+分层->细粒度->用例) | 自底向上 (用例驱动 ,内外对话—>内部协作 , 用例->鲁棒->时序->模块)
参与角色 :用户 客户 开发 管理
缘由(一下想清)—>思想(分治+迭代)—>方法(逻辑+物理)—>案例(拉出工程)

软件架构:3原则+6步骤

需求分析:三横是顺序的方法,两纵是持续的观念 | 需求就是不断交替,彼此印证的过程性的事情
领域建模: 原理=> 过程 =>内容 + 方法 + 实现

关键需求:预见->权衡->折衷

概念架构:目标->设计->选型

细化架构:5视图(组件+交互)
架构验证:验证内容+方法

概念思想:组件划分和交互 (组成)| 组件关系和依赖(决策)
架构=组件+交互(mvc)

架构设计,模块切分类决策 和 技术选型类决策
-------------------------------------------------------------------

架构细化(SOA),软件是由组件递归组合而成的
组件(交互)=原子组件+复合组件(框架 子系统 系统 ...)

领域建模,理顺概念关系,搞清业务规则,通过概念抽象和关系抽象建立模型
需求实践论,
需求工作项(业务目标 用例图 用例规约+流程建模)
提交的文档(目标列表 需求规格/用例模型+流程模型)
所处需求层次(业务 用户 行为)

概念架构:1个决定(划分顶级子系统),4个选型(架构风格 开发技术 集成技术 二次开发技术)
需求分析,
高层需求分析(系统目标 需求范围 特性 上下文图)
需求分析:流程 功能(用例) 非功能
概念性架构设计:切分顶级子系统,明确关键需求(架构风格,顶级子系统构成,3大选型)

细化架构设计,前端 后端 API 插件

模块划分方法,
水平,分层
垂直,功能模块,功能树
用例到类,再到模块(用例驱动,类分组,自底向上)

架构视图化,为用户设计
客户 不等于 最终用户
客户(理解难易度) 用户(使用难易度) 开发(开发难易度) 软件经理(管理难易度)

缘由,架构师不可能 一下子 想清楚
思想:分而治之(大->小)+迭代设计(已知->未知)
方法:逻辑(类 方法 接口)+物理(服务 数据 并发)

案例:邮件转发

用例图:客户系统(提交邮件 反馈结果) 管理员系统(设置规则 和 地址 ) 定时器(发邮件) 邮件转发器(发邮件)

逻辑架构:用户交互+系统交互 业务逻辑 数据访问
物理架构:客户系统+管理工作站 转发服务器 数据库服务器

迭代(软件单元和硬件机器映射关系)

逻辑--
用户交互(设置地址 设置规则) + 系统交互(代理模块 Mail Server)
业务逻辑:调度 设置地址 设置规则 发送 反馈
数据访问 设置信息读写 邮件信息读写 发送结果信息读写

3个工程(包含的程序单元)
客户系统代理 管理员web应用
服务器软件

物理--

客户系统 Api
转发服务器 Server 数据库服务器 DB
管理工作站 Web

说明,多视图 不等于 多阶段,避免对某个模块一下过于深入,逻辑和物理本身就是不断相互验证 和 促进设计优化的过程

3原则和6步骤:
1.看透需求:需求
需求(重大 特色 风险 | 全面 矛盾 追溯 | 功能 质量 约束)
两纵(功能 非功能)三横(目标—范围 feature 上下文 -用例模型)
+
领域模型(业务决定功能 功能决定模型)
写出业务目标 ==> 给出功能范围(现在的功能和未来的功能) 层级关系 和 用户交互逻辑 ==>建立用例模型

2.架构方向:高层架构
关键需求 功能+质量+约束==>关键功能+关键质量
+
概念架构 关键功能和质量==>鲁棒图+目标 场景 决策==>概念架构(划分子系统 | 架构风格 开发技术 集成技术 二次开发技术)

3.设计架构:架构设计
细化架构 不只是关键需求,而是所包括的需求,按照概念架构开始,逻辑的领域和数据的存储收在领域指导下进行
逻辑 模块 接口 领域
开发 技术 文件 编译
运行 技术 流程 同步
物理 硬件 部署 方案
数据 技术 存储 数据
+
架构原型 规避风险,尽早开发出来,尽早地验证它

需求分析:交替进行(问题->解决->衍生问题-> … ...)

+用例图,
需求捕获(用户需求:用例图+用例简述) 全面
需求分析(行为需求:用例规约) 细致,可推后细化,待用户需求明确了后(需求沟通 需求启发 需求验证)
系统分析(初步设计:鲁棒图)

+流程图,拿出单独的一项,判断粒度大小,粒度足够小了,判断全IT 半IIT 还是用户,如果需要IT系统协助,加入到用例图中,

三横是顺序的方法,两纵是持续的观念
三横(顺序):方法==>愿景=业务目标 + 高层需求(范围 特性 上下文)
--按照系统目标
—给出功能范围和强调的特性,范围广,特性可强调某几个特性,也可非常细致,可大可小
--绘制上下文图,不关注内部的功能和结构,中心+四周的UML用例,明了待开发的系统 用户 和 交互系统
--绘制用例图,系统外部的使用者Actor 和内部的功能Case,并细化其功能指向
明确用例规约,用例名称 简要说明事件流(基本事件流+扩展事件流) 非功能需求前置条件后置条件
扩展点 优先级

两纵(持续):观念==>需求分析大局观,不拘泥于需求列表 1,2,3,二维需求观(功能 质量 约束 + 组织 用户 开发)

+功能(职责协作链条)—用户输入和系统动作交互, 业务规则 例外处理 特殊需求 相关功能 注释说明
+非功能:
+质量(性能:内部质量决定 外部质量)—运行(外部质量)(性能 安全 易用 可用 交互 容错) 开发(内部质量)(扩展 维护 移植 重用 测试 易理解)
+约束:各种环境限制(转化为功能+质量+环境)

领域建模: 原理=> 过程 =>内容 + 方法 + 实现

原理:松耦合,通过抽象接口隔离变化
过程:需求词语+界面内容==>设计+持久化数据+扩展性 (核心业务可视化-内,抽象成OO类-外)

内容:
UML图 模块的包含关系 顺序关系和映射关系
状态图 状态、转化原因和引起的动作,以及子状态
扩展性 就是潜在的UML功能+状态变化

方法:
理顺概念关系—领域词汇(达成共识)
搞清业务规则—领域模型 (次第展开)

实现:
领域==>扩展功能类, 增加数据类
功能==>领域模型修改,完善数据关系

明确关键需求(预见权重更大的目标)
= 关键质量(二维ADMEMS)+关键功能(核心 必须 高风险 独特)
关键需求决定架构,其他需求验证架构,
需求范围—>关键需求—>需求折衷

概念架构设计

目标—>设计思想—>选择

1.功能+质量
关键功能--
原理:用例到鲁棒图,每个用例多个场景,每个场景是一串职责链条
工具:鲁棒图( v-边界对象交互 m-业务逻辑 + c-应用逻辑(控制对象 行为) 数据(实体对象 信息))
方法:增量建模,职责 -> 职责关系 -> 发现新职责

关键质量-目标(功能)+场景 (用户动作,和数据处理效率)+决策 (对策)

2.架构设计:1个决定,4个选择,先明确顶级子系统和架构风格,再明确集成和开发技术选型

3.备选方案:
系统组成:前端 后端 API 插件
技术选型:架构风格 应用集成 UI集成 开发技术

需求+领域模型+概念架构==>细化架构设计(5视图 组件+交互)
(繁中带简)
逻辑(模块划分 接口定义)= 职责单元 + 协作关系
开发(技术选型 文件划分) = 程序单元 + 依赖关系
运行 = 控制流 + 同步关系
物理(硬件分布 软件部署) = 物理节点 + 拓扑关系
数据 (存储格式 数据分布)= 数据单元 + 数据关系

试试看 成本远低于 正式干 ==>架构验证
原型分类
抛弃 演进
水平 界面探索 定型
垂直 功能探索 迭代

验证内容:评审开发质量-扩展 重用 理解 和 测试运行质量-性能 伸缩 高可用 安全
验证方法:原型法(架构师最担心的 和 用户最关心的)+框架法(实现一个小的垂直原型)
==>重大技术风险是否已解决可否大规模开发

模块划分:
1.经验
功能树(隶属关系) 功能大类 功能组 功能项
用例图 鲁棒图 功能模块

功能分层:上下文图—>分层
EDD:功能模块 —> 粗粒度分层—>细粒度模块—>用例驱动
通用模块,高层有较高扇入,底层有较多扇出(该模块被更多上级模块共享)
框架化,没有提取机制的情况下,机制是一种隐式代码| 重用几率和重用带来的价值量成反比

2.推理
用例驱动: 需求—>设计 + 先大局后细节,而不是先详细后架构
用例—> 用例规约(内外对话,系统黑盒)—> 鲁棒图(哪些些类)—>时序图(内部协作(打开系统内部黑盒) 类之间的关系)—>类划归模块,模块间接口

实践使用:

架构 细节

图片 用法

运用 学习

梳理需求:功能+质量+约束

流程图(可拆分成用例图 |活动成败-->出售成败-->打款成败) 用例图(人和动作 |财务:报表+审核 编辑:发布+打款 管理员:权限)+用例规约(系统和人交互 |前置条件->购买成败+活动失败-->审核(呈现操作人和时间,活动信息和打款状态)-->后置条件->退款+分收益) 状态图(细化用例图 | 未申购 已申购(有结果 无结果) 退款中 已退款 分收益)

明确需求:关键功能+质量

鲁棒图(交互界面+控制逻辑+实体信息 | 字段信息 curd数据操作 人机交互 功能目的 内测代码 外测运行 上线方案)+目标场景选择(用户操作=>数据影响==>技术方案 | 导出全部excel ->数据量大 ==>1.提示不要这样操作 2.分批次生成多个excel,然后发送邮件) ==> 1个系统4个选择(前后端 测试+线上 pc+wap 线上线下 系统人工 新老功能 |lanmp)

实现需求:细化架构+架构验证

细化(组件+交互:职责协作->代码依赖 数据映射->物理拓扑 运行同步)+验证(原型:水平/垂直 + 抛弃/演进 =>开发质量(扩展性 重用性 可理解) 运行质量(性能 安全 高可用 伸缩))==>开始大规模开发

领域模型图(UML) 用户描述-->领域模型-->用例图-->用例规约(细化用户描述)
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: