软件体系结构4 1模型实例

《软件体系结构4 1模型实例》由会员分享，可在线阅读，更多相关《软件体系结构4 1模型实例（13页珍藏版）》请在金锄头文库上搜索。

1、 Safehome 智能家居系统 第七部分 设备管理1.功能描述：设备管理功能主要包括设备信息的编辑（增加、删除、修改） 。 1.1.设备信息包括设备的位置信息、名称、状态。 1.2.设备信息的编辑：支持对设备信息的编辑（增加、删除、修改） 。2.内容概述：运用 4+1 视图模型，从 5 种视图角度，进行分析设计。2.1 场景视图 （Use case）使用 user case 图设计系统的各个场景。 2.2 逻辑（功能）视图（Logical View） ，设计的对象模型（使用面向对象的设计 方法时） 。 2.3 开发（模块）视图（Development View） ，描述了在开发环境中软件的静

2、态 组织结构。 2.4 物理视图（Physical View） ，描述了软件到硬件的映射，反映了分布式特性。2.5 过程视图（Process View） ，捕捉设计的并发和同步特征。4+1 视图综述：3.设计详情：3.1 场景视图场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改， 删除，增加三方面驱动。如图 1：Safehome 智能家居系统 图 1 在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨， 刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大 概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时

3、候才可 能发生的非正常情况。 我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的 学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的 认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总 结经验。 在这部分，有同学提出了质疑，认为需要具体细分一下，如图 2：图 2 在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功 能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。在这部分， 我还需要更深入的了解，在实际应用过程中不断摸索。Safehome 智能家居系统 3.2 逻辑视图逻辑视图（Logic View）：逻辑试图主要是用来

4、描述系统的功能需求， 即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象、 功能分解与功能分析，这些主要来自问题领域（Problem Definition)。在面 向对 象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类 图（Class Diagram）来描述逻辑视图。 逻辑架构关注功能， 不仅包括用户可见的功能，还包括为实现用户功能而 必须提供的“辅助功 能模块” ；它们可能是逻辑层、功能模块、类等。如图 3：图 3 设备管理服务由 三种类服务构成，分别为增加、修改、删除，其中，设备 信息的属性包含位置，名称，状态，故分别存在于三种类中以备修改。在做这个

5、的时候，刚开始并不是做成了现在的样子，不过现在也忘了最初 做成什么样了，原因就在于并不能对逻辑视图有一个好的认识，一个星期以后， 和小组成员开会讨论的时候，大家才提出那个样子是不对滴，回去重新改。在 做类图的时候，深刻感觉到前几个学期没有好好的编程.对类的概念非常的模糊， 又学习了一下以前的支持，大概了解了类有函数和属性，类之间还有不同的联 系，有继承，友元等，这根据类内的函数关系等来定义，但是在做这部分的时 候，对程序的实现还是非常模糊，所以在听了别的小组的报告之后非常的惭愧！Safehome 智能家居系统 并没有像他们一样有清晰的认识，他们不但对于每个类中的函数有详细的解释， 并且对接口也

6、有明确的定义，不同的功能层层递进，调用接口实现功能。看来 对这部分的学习和理解还是非常必要的，我觉得我可以通过多阅读分析代码来 提高自己的这部分技能，因为编程真的让我非常的头大.相当的苦闷。 在经过同学的指正后，发现存在一些问题，有的功能不需要重复定义，比 如显示，所以，修改之后变成了把显示放在大的类中，只调用不同功能。这样 可以提高效率，减小代码，便于维护。如图 4：图 43.3 开发视图开发视图（Development/Module View)：开发视图主要用来描述软件模块的 组织与管理（通过程序库或子系统） 。服务于软件编 程人员，方便后续的设计 与实现。它通过系统输入输出关系的模型图和

7、子系统图来描述。要考虑软件的 内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图 的风格通常是层次结构，层次越低，通用性越好（底层库：Java SDK，图像处 理软件包） 。 开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三 方 SDK 和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。 开发架构和逻辑架构之间可能存在 一定的映射关系：比如逻辑架构中的逻辑层 一般会映射到开发架构中的多个程序包；再比如开发架构中的源码文件可以包 含逻辑架构中的一到多个类（在 C+里一个源码文件可以包含多个类，即使在 Java 里 一个源码文件也可以同时包含一个

8、类和几个内部类） 。如图 5：Safehome 智能家居系统 图 5 设备管理最底层文件由 C+编写，完成的 CPP 文件应用于设备设置，有需要时 调用数据库文件做修改或查看。 对开发视图的研究时间比较长，因为看了很多资料许多人给出的举例都大 不相同，而且在起名上都不能统一，有的人叫进程视图，有时又编程过程视图， 再加之我总和开发视图弄混所以非常的乱，看了别人的例子，感觉上这个视图 是给开发人员看的，所以它应该具体包含实现的语言，方法和集成，我认为这 需要对整个系统的有一个完整的认识，因为在实际开发的时候，我们有可能应 用以前的开发原型，这样就可以节约开发时间，提高效率，而且有一个非常明 确的

9、项目经理可以预估出不同开发模块的时长，根据开发人员的技能分配任务， 甚至外包部分组件。 但是在各种程序的集成过程中，必须明确它要怎么集成，从哪来到哪去， 所以我准备使用分层结构，问题又出现了，怎么分层，在并没有什么思路的情 况下，反复试验，最终决定使用现在的模型，集成方向是后台服务器，智能家 居框架，在这里具体提到的是设备管理，然后向功能组件，用户终端集成。用 户终端使用 MFC 框架。Safehome 智能家居系统 3.4 物理视图物理视图： 物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、 系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性 能、规模、可

10、靠性等。可以与进程视图一起映射。 物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或 部署到物理机器，以 及如何部署机器和网络来配合软件系统的可靠性、可伸缩 性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执 行情况，而物理架构重视目标 程序的静态位置问题；物理架构还要考虑软件系 统和包括硬件在内的整个 IT 系统 之间是如何相互影响的。如图 6：图 6 物理视图设计的部分主要考虑的是与物理设备的静态位置对应，所以用到了 5 大处理器，其中，我们可根据用户具体的需要以及提供的设备支持来明确的表 达目标模块及其通讯结构。3.5 进程视图进程视图：进程试图侧重系统的

11、运行特性，关注非功能性的需求（性能，可 用性） 。服务于系 统集成人员，方便后续性能测试。强调并发性、分布性、集 成性、鲁棒性（容错） 、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体 操作是在哪一个线程（Thread）中被执行。如图 7：图 7Safehome 智能家居系统 第八部分 系统管理1.功能描述：系统设置功能主要包括通讯参数设置；系统管理；个性化设置；系统时间设置；系统帮助。2.内容概述：运用 4+1 视图模型，从 5 种视图角度，进行分析设计。2.1 场景视图 （Use case）使用 user case 图设计系统的各个场景。 2.2 逻辑（功能）视图（Logical Vie

12、w） ，设计的对象模型（使用面向对象的设计 方法时） 。 2.3 开发（模块）视图（Development View） ，描述了在开发环境中软件的静态 组织结构。 2.4 物理视图（Physical View） ，描述了软件到硬件的映射，反映了分布式特性。2.5 过程视图（Process View） ，捕捉设计的并发和同步特征。3.设计详情：3.1 场景视图场景视图(Scenarios)：参与者与用例构成场景视图，如图 1.1，1.2：参与者： 用例：Safehome 智能家居系统 图 1.1图 1.2在这里面，和其他同学不一样的一点就是我的参与者有 3 个，分别是普通 用户，管理员和超级管理

13、员。因为在系统设置方面，不同的权限有不同的功能， 但是基础功能都可以在普通用户中实现，所以，在这里，权限高的用户涵盖较 低权限的功能，自身又包含特定功能，就得到了这个用例图，有点继承的概念 在其中。3.2 逻辑视图逻辑视图（Logic View）：因为通过需求分析需要考虑到的具体功能如下：1.通讯参数设置：支持串口通讯参数的设置，如波特率、数据位等参数的设置。2.系统管理：系统的用户优先级由高到低为超级管理员、管理员、普通用户。他们的操作权限是：超级管理员和管理员具有全部权限；普通用户仅具有查看Safehome 智能家居系统 的权限，没有修改系统设置的权限。超级管理员和管理员的区别在于超级管理

14、员是系统的默认管理员，不可删除，而且仅可以使用超级管理员来创建、删除管理员，可以使用超级管理员或管理员来创建、删除普通用户；较高优先级用户可以为较低优先级用户设定操作权限，操作权限分为全部权限（超级管理员和管理员） 、仅能查看系统信息（普通用户） ；系统的用户可以修改自己的用户信息。系统初始化时有且仅有一个默认的超级管理员。4.个性化设置：可以设置系统的背景图片；可以设置界面的风格。5.系统时间设置：可以设置系统时间。6.系统帮助：介绍系统的使用方法，以及一些注意事项。所以设计的类图与用例图有异曲同工之处，就是高级别的权限涵盖低级别的功能，用管理员服务来说，在系统管理方面，需求分析得到的具体要

15、求是：“系统的用户优先级由高到低为超级管理员、管理员、普通用户。他们的操作权限是：超级管理员和管理员具有全部权限；普通用户仅具有查看的权限，没有修改系统设置的权限。较高优先级用户可以为较低优先级用户设定操作权限，操作权限分为全部权限（超级管理员和管理员） 、仅能查看系统信息（普通用户）；系统的用户可以修改自己的用户信息。系统初始化时有且仅有一个默认的超级管理员。 ”所以管理员服务继承与用户服务，再加上它特定的功能，另外有一点不同的是，并非在进入系统的时候就进行了身份识别，而是一旦想进入某一种权限的时候再进行识别，这样设计的初衷是为了方便普通用户，因为管理员和超级管理员毕竟是少数部分，应为大部分

16、使用者着想。如图 2：Safehome 智能家居系统 图 2设计方案：系统管理划分为三大服务对象，根据权限不同分别为用户服务，管 理员服务，超级管理员服务。用户的全部权限包含于管理员服务，同时，管理 员服务增设管理员特定功能。此外，管理员及用户服务包含于超级管理员服务， 同时，超级管理员服务增设超级管理员特定功能。3.3 开发视图开发视图（Development/Module View) 软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设 计决策都应由架构设计来完成，这些决策如果“漏”到了后边，最终到了大规 模并行开发阶段才发现，可能造成“程序员碰头儿临时决定”的情况大量出现， 软件质量必然将下降甚至导致项目失败。其中，采用哪些现成框架、哪些第三 方 SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下 来。如图 3：Safehome 智能家居系统 图 3