系分 - 案例分析 - 架构设计（基本）
个人总结，仅供参考，欢迎加好友一起讨论
文章目录
- 案例分析 - 架构设计（基本）
- Zachman架构框架
-
- 典型例题
-
- 题目描述
- 参考答案
- 面向服务的架构SOA
- 微服务
-
- 典型例题
-
- 题目描述
- 参考答案
- 多层架构
- 轻量级架构
- MVC
- MVP与MVVM
- MDA模型驱动架构
案例分析 - 架构设计（基本）
Zachman架构框架
Zachman框架综合考虑企业业务架构中不同角色的不同观点，提出了一个多视角、多维度的企业架构，是许多大公司用来理解、表述企业信息基础设施的一种可以理解的信息表述，为企业现在以及未来的信息基础设施建设提供蓝图和架构。
其纵向的功能视图包括目标范围、业务模型、系统模型、技术模型、详细展现和功能系统，横向的关注点包括数据、功能、网络、人员、时间和动机。
Zachman架构框架的相关经验贴，自行搜索网络。
典型例题
题目描述
阅读以下关于系统开发的叙述，在答题纸上回答问题1至问题3。
某集团下属煤矿企业委托软件公司开发―套煤炭运销管理系统，该系统属于整个集团企业信息化架构中的业务层，系统针对煤矿企业开发，包括合同管理、磅房管理、质检化验、运费结算等功能。部分业务详细描述如下：
（1）合同管理：合同签订、合同查询、合同跟踪等。
（2）磅房管理：系统可以从所有类型的电子磅自动读数；可以自动从电子磅上读取车辆皮重、毛重，计算出净重；可根据合同内容自动减少相应提货单剩余数量，如果实际发货量超过合同额则拒绝发货。
（3）质检化验：根据过磅单、车号，生成化验分析委托单，而后生成化验分析报告。
（4）运费结算:依据过磅单上的净重、化验单、合同规定，自动计算出原料结算单、运费结算单。
煤矿企业根据集团的工作计划制订本企业的业务计划，煤矿企业根据集团划拨指标和提供的原料生产煤炭，所生产的煤炭交由集团统一管理并销售给客5卢。软件公司采用Zachman框架对企业业务架构和业务过程进行分析，结果如下表所示。
【问题1】
Zachman框架是什么：请在上表中（a）~（e）位置补充企业业务架构中的信息类别。
【问题2】
项目组在该煤炭企业业务架构分析中完成了四项主要工作：数据流图、实体联系图、网络拓扑结构和计划时间表。这四项工作在上表中处于什么位置？请用表的位置编号表示。
【问题3】
据题目所述业务描述，请分别给出表中A11和A23位置应该填入的内容。(物流关系用“→”表示)。
参考答案
【问题1】
1）
Zachman框架综合考虑企业业务架构中不同角色的不同观点，提出了一个多视角、多维度的企业架构，是许多大公司用来理解、表述企业信息基础设施的一种可以理解的信息表述，为企业现在以及未来的信息基础设施建设提供蓝图和架构。
2）
（a）What/数据（b）How/功能/行为（c）Where/位置/网络（d）Who/人员/组织（e）Why/动机
【问题2】
（1）数据流图：A32
（2）实体联系图：A31
（3）网络拓扑结构：A53
（4）计划时间表:A25
【问题3】
（1）A11项目关键元素：合同/合同管理、过磅/磅房管理、质检/质检化验、结算/运费结算
（2）A23业务物流网络：煤矿企业←→集团→客户。
面向服务的架构SOA
SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。关于服务，一些常见的设计原则有:明确定义的接口、自包含和模块化、粗粒度、松耦合、互操作性。
SOA紧密相关的技术主要有UDDI、WSDL、SOAP和REST等，而这些技术都是以XML为基础而发展起来的。
微服务
微服务有以下优势：
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变。
- 让每个服务能够独立开发，开发者能够自由选择可行的技术，提供API服务。
- 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。
- 微服务使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。
微服务架构带来的挑战如下：
- 并非所有的系统都能转成微服务。
- 部署较以往架构更加复杂，系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
- 性能问题，由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。
- 数据一致性问题，作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。
在微服务中，应用网关API的作用：
- 提供统一入口
- 可以进行权限身份认证等安全管理
- 可以根据流量进行限流
- 数据缓存
- 性能监控等
- 异常重试
- 服务降级
典型例题
题目描述
阅读以下关于Web应用设计开发的描述，在答题纸上回答问题1至问题3。
某公司拟开发一个自由，可定制性强、用户界面友好的在线调查系统，以获取员工在课程学习、对公司重人事件的看法、对办公室环境的建议等相关反馈。因需要调查的内容各异，可选择的调查方式多样，故本在线调查系统应满足以下需求：
1）支持编辑和视图两种模式，编辑模式只对调查发起者可见，视图模式对接受调查者可见。
2）调查问卷具有可定制性，因调查的内容各异，需要多样的信息采集方式，可设置的调查问题类型包括单选、多选、矩阵类单选、矩阵类多选和开放性问题。
3）操作简单，调查者可以方便地新建和编辑各种问题类型，接受调查者可对每个问题和每个调查问卷给出评论。
4）系统支持显示调查统计结果，以及导出统计结果。 针对以上需求，经项目经讨论，拟采用REST架构风格设计实现该在线调查系统。
【问题1】
分析该在线调查系统的业务流程，填写下图中（1）~（5）的内容。
【问题2】
REST 架构风格的核心是资源抽象。在系统设计中，项目组拟将系统中的每一个实体抽象 成一种资源。皆列举出该系统中的5种资源。
【问题3】
基于REST架构风格对系统进行设计，请简要叙述REST风格的5条关键原则。
参考答案
【问题1】
（1）编辑模式//调查发起者
（2）视图模式/接受调查者
（3）是否保存调查问卷
（4）已保存的调查问卷
（5）显示（查看）调查问卷
【问题2】
（1）调查发起者
（2）接受调查者
（3）调查问卷
（4）调查问卷类型
（5）调查问卷评论
【问题3】
（1）网络上所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识；
（3）对资源的各种操作不会改变资源的标识；
（4）通过通用的连接件接口对资源进行操作；
（5）无状态通信
多层架构
二层C/S结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；软、硬件的组合及集成能力有限；它的缺点主要有：
- 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
- 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。
在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机。三层C/S架构将应用系统分成表示层、功能层和数据层三个部分。
与传统的二层架构相比，三层C/S架构具有以下优点：
- 允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
- 允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
- 系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
- 利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础。
BS浏览器/服务器（Browser/Server，B/S）架构是三层C/S架构的一种实现方式，其具体结构为“浏览器/Web服务器/数据库服务器”。B/S架构利用WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。
轻量级架构
持久层的设计，使得业务逻辑层只需要负责业务逻辑的实现，而把对数据的操作交给了持久层。持久层对数据及对数据操作的封装有以下几个优点：
- 屏蔽数据库平台的变化对业务逻辑层的影响。当数据库变化时，只需修改持久层操作数据库的代码，而持久层提供给业务逻辑的对象模型没有变化，从而避免了业务逻辑的修改。
- 通过持久层的封装处理，可以在持久层实现支持多种数据库平台，而对业务逻辑层提供统一的接口。
- 代码可重用性高，能够完成所有的数据库访问操作。
- 通过持久层的设计，将复杂的业务逻辑和数据逻辑分离，降低系统的耦合程度，从而在开发时更明确地进行分工，维护工作也更容易进行，系统的体系结构也变得更加清晰。
Hibernate与Mybatis区别：
- 开发方面，Hibernate开发中，sql语句已经被封装，直接可以使用；Mybatis属于半自动化，sql需要手工完成。
- sql优化方面，对复杂查询的sql语句进行人工调优的时候，Mybatis更方便。
- 可移植性方面，Hibernate使用时自动生成相应的sql语句，因此具备良好的数据库移植性，而Mybatis中手动编写的sql语句需要针对不同厂商的数据库进行修改。
现阶段未必能考以上观点。
MVC
模型：执行业务流程（不包括输入输出），存储业务数据。模型不依赖于视图和控制器，提高了架构的灵活性。
视图：展示模型中的数据，用户的同一份数据可以通过不同的视图以不同的方式展示。视图必须了解模型中的数据结构，对模型有很强的依赖性，但是模型对于视图则没有依赖性。
控制器：把模型接收的事件和用户输入的数据转化为对模型方法的调用。控制器对用户的行为作出解释，并决定调用模型的哪个方法。
使用MVC模式来设计表现层，可以有以下的优点：
- 允许多种用户界面的扩展。在MVC模式中，视图与模型没有必然的联系，都是通过控制器发生关系，这样如果要增加新类型的用户界面，只需要改动相应的视图和控制器即可，而模型则不需发生改动。
- 易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展，只要保持—种公共的接口，控制器和视图的旧版本也可以继续使用。
- 功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使5思界清晰，可将友好的界面发布给用户。
MVP与MVVM
MVP的优点包括：
- 低耦合。模型与视图完全分离，可以修改视图而不影响模型。
- 可以更高效地使用模型，因为所有的交互都发生在一个地方一Presenter内部。
- 复用性好。可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
- 可测试性好。如果把逻辑放在Presenter中，就可以脱离用户接口来测试这些逻辑(单元测试)。
MVVM是由MVP进化而来，MVVM模式基本上与MVP相同，只是把MVP中的P变成了VM，即ViewModel，MVM中的数据可以实现双向绑定，当Model变化时，View-Model会自动更新，View也会自动变化。很好做到数据的一致性，不用担心，在模块的这一块数据是这个值，在另一块就是另一个值了。所以MVM模式有些时候又被称作：model-view-binder模式。因此MVVM框架比较适合逻辑复杂的前端项目，比如一些管理系统等。
MDA模型驱动架构
MDA（Model Driven Architecture）是模型驱动架构，它是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。
基于MDA的软件开发方法的主要过程是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（Platform Independent Model，PIM），然后针对不同实现技术制定多个转换规则，通过这些转换规则及辅助工具将PIM转换成与具体实现技术相关的平台相关模型（Platform Specific Model，PSM），最后将经过充实的PSM转换成代码。
MDA的优点：
- 使用平台无关的建模语言来搭建平台无关的模型PIM，然后根据特定平台和实现语言的映射规则，将PIM转换以生成平台相关的模型PSM，最终生成应用程序代码和测试框架。因此MDA方法可移植性比较好。
- MDA方法中提供了模型转换标准，以及对象约束语言，工具厂商可以开发自动化的工具，开发人员只需关注于业务建模，开发PIM。从PIM到最后面向具体技术平台的可执行的应用程序，都由自动化的MDA工具来解决，很好地实现了平台互操作性。(3)在MDA中代码是由模型生成的，可以保证文档和代码的一致性。
示例：
解：（1）平台无关模型（PIM）（2）UML建模（3）模型变换（映射）（4）模型生成源码