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

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.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。2.5过程视图（Process View），捕捉设计的并发和同步特征。4+1视图综述：3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，对设备的设置从修改，删除，增加三方面驱动。如图1：图1在设计场景视图时，对包含（include）和扩展(extend)的应用需要仔细琢磨，刚开始并不知道每种的应用范围，看了网上的例子，和以前软件工程的书，大概了解包含的概念是一些必然发生的用例，然而扩展是在特殊情况的时候才可能发生的非正常情况。我觉得一个小小的箭头也许在现在的项目作业中并不重要，但是在今后的学习工作中它会从某种程度上决定项目的成败，并体现出个人对工作和生活的认真态度，所以，大学课程的好处就是允许我们在实践和失败中汲取教训，总结经验。在这部分，有同学提出了质疑，认为需要具体细分一下，如图2：图2在这里，也是得到其他同学的启发，场景视图必须要具体细分，它注重功能的概念，细分的过程可以放在逻辑视图中，通过函数来具体实现。在这部分，我还需要更深入的了解，在实际应用过程中不断摸索。3.2逻辑视图（Logic View）：逻辑试图主要是用来描述系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象、功能分解与功能分析，这些主要来自问题领域（Problem Definition)。在面 向对象技术中，通过抽象、封装、继承,可以用对象模型来代表逻辑视图，可以用类图（Class Diagram）来描述逻辑视图。逻辑架构关注功能， 不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功 能模块”；它们可能是逻辑层、功能模块、类等。如图3：图3设备管理服务由 三种类服务构成，分别为增加、修改、删除，其中，设备信息的属性包含位置，名称，状态，故分别存在于三种类中以备修改。在做这个的时候，刚开始并不是做成了现在的样子，不过现在也忘了最初做成什么样了，原因就在于并不能对逻辑视图有一个好的认识，一个星期以后，和小组成员开会讨论的时候，大家才提出那个样子是不对滴，回去重新改。在做类图的时候，深刻感觉到前几个学期没有好好的编程.对类的概念非常的模糊，又学习了一下以前的支持，大概了解了类有函数和属性，类之间还有不同的联系，有继承，友元等，这根据类内的函数关系等来定义，但是在做这部分的时候，对程序的实现还是非常模糊，所以在听了别的小组的报告之后非常的惭愧！并没有像他们一样有清晰的认识，他们不但对于每个类中的函数有详细的解释，并且对接口也有明确的定义，不同的功能层层递进，调用接口实现功能。看来对这部分的学习和理解还是非常必要的，我觉得我可以通过多阅读分析代码来提高自己的这部分技能，因为编程真的让我非常的头大.相当的苦闷。在经过同学的指正后，发现存在一些问题，有的功能不需要重复定义，比如显示，所以，修改之后变成了把显示放在大的类中，只调用不同功能。这样可以提高效率，减小代码，便于维护。如图4：图43.3开发视图（Development/Module View)：开发视图主要用来描述软件模块的组织与管理（通过程序库或子系统）。服务于软件编 程人员，方便后续的设计与实现。它通过系统输入输出关系的模型图和子系统图来描述。要考虑软件的内部需求：开发的难易程度、重用的可能性，通用性，局限性等等。开发视图的风格通常是层次结构，层次越低，通用性越好（底层库：Java SDK，图像处理软件包）。开发架构关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发架构和逻辑架构之间可能存在 一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发架构中的多个程序包；再比如开发架构中的源码文件可以包含逻辑架构中的一到多个类（在C+里一个源码文件可以包含多个类，即使在Java里 一个源码文件也可以同时包含一个类和几个内部类）。如图5： 图5设备管理最底层文件由C+编写，完成的CPP文件应用于设备设置，有需要时调用数据库文件做修改或查看。对开发视图的研究时间比较长，因为看了很多资料许多人给出的举例都大不相同，而且在起名上都不能统一，有的人叫进程视图，有时又编程过程视图，再加之我总和开发视图弄混所以非常的乱，看了别人的例子，感觉上这个视图是给开发人员看的，所以它应该具体包含实现的语言，方法和集成，我认为这需要对整个系统的有一个完整的认识，因为在实际开发的时候，我们有可能应用以前的开发原型，这样就可以节约开发时间，提高效率，而且有一个非常明确的项目经理可以预估出不同开发模块的时长，根据开发人员的技能分配任务，甚至外包部分组件。但是在各种程序的集成过程中，必须明确它要怎么集成，从哪来到哪去，所以我准备使用分层结构，问题又出现了，怎么分层，在并没有什么思路的情况下，反复试验，最终决定使用现在的模型，集成方向是后台服务器，智能家居框架，在这里具体提到的是设备管理，然后向功能组件，用户终端集成。用户终端使用MFC框架。3.4物理视图：物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以 及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标 程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统 之间是如何相互影响的。如图6：图6物理视图设计的部分主要考虑的是与物理设备的静态位置对应，所以用到了5大处理器，其中，我们可根据用户具体的需要以及提供的设备支持来明确的表达目标模块及其通讯结构。3.5进程视图：进程试图侧重系统的运行特性，关注非功能性的需求（性能，可用性）。服务于系 统集成人员，方便后续性能测试。强调并发性、分布性、集成性、鲁棒性（容错）、可扩充性、吞吐量等。定义逻辑视图中的各个类的具体操作是在哪一个线程（Thread）中被执行。如图7：图7第八部分 系统管理1.功能描述：系统设置功能主要包括通讯参数设置；系统管理；个性化设置；系统时间设置；系统帮助。2.内容概述：运用4+1视图模型，从5种视图角度，进行分析设计。2.1场景视图 （Use case）使用user case图设计系统的各个场景。2.2逻辑（功能）视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。2.3开发（模块）视图（Development View），描述了在开发环境中软件的静态组织结构。2.4物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。2.5过程视图（Process View），捕捉设计的并发和同步特征。3.设计详情：3.1场景视图(Scenarios)：参与者与用例构成场景视图，如图1.1，1.2：参与者： 用例：图1.1图1.2 在这里面，和其他同学不一样的一点就是我的参与者有3个，分别是普通用户，管理员和超级管理员。因为在系统设置方面，不同的权限有不同的功能，但是基础功能都可以在普通用户中实现，所以，在这里，权限高的用户涵盖较低权限的功能，自身又包含特定功能，就得到了这个用例图，有点继承的概念在其中。3.2逻辑视图（Logic View）：因为通过需求分析需要考虑到的具体功能如下：1.通讯参数设置：支持串口通讯参数的设置，如波特率、数据位等参数的设置。2.系统管理：系统的用户优先级由高到低为超级管理员、管理员、普通用户。他们的操作权限是：超级管理员和管理员具有全部权限；普通用户仅具有查看的权限，没有修改系统设置的权限。超级管理员和管理员的区别在于超级管理员是系统的默认管理员，不可删除，而且仅可以使用超级管理员来创建、删除管理员，可以使用超级管理员或管理员来创建、删除普通用户；较高优先级用户可以为较低优先级用户设定操作权限，操作权限分为全部权限（超级管理员和管理员）、仅能查看系统信息（普通用户）；系统的用户可以修改自己的用户信息。系统初始化时有且仅有一个默认的超级管理员。4.个性化设置：可以设置系统的背景图片；可以设置界面的风格。5.系统时间设置：可以设置系统时间。6.系统帮助：介绍系统的使用方法，以及一些注意事项。所以设计的类图与用例图有异曲同工之处，就是高级别的权限涵盖低级别的功能，用管理员服务来说，在系统管理方面，需求分析得到的具体要求是：“系统的用户优先级由高到低为超级管理员、管理员、普通用户。他们的操作权限是：超级管理员和管理员具有全部权限；普通用户仅具有查看的权限，没有修改系统设置的权限。较高优先级用户可以为较低优先级用户设定操作权限，操作权限分为全部权限（超级管理员和管理员）、仅能查看系统信息（普通用户）；系统的用户可以修改自己的用户信息。系统初始化时有且仅有一个默认的超级管理员。”所以管理员服务继承与用户服务，再加上它特定的功能，另外有一点不同的是，并非在进入系统的时候就进行了身份识别，而是一旦想进入某一种权限的时候再进行识别，这样设计的初衷是为了方便普通用户，因为管理员和超级管理员毕竟是少数部分，应为大部分使用者着想。如图2：图2设计方案：系统管理划分为三大服务对象，根据权限不同分别为用户服务，管理员服务，超级管理员服务。用户的全部权限包含于管理员服务，同时，管理员服务增设管理员特定功能。此外，管理员及用户服务包含于超级管理员服务，同时，超级管理员服务增设超级管理员特定功能。3.3开发视图（Development/Module View)软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果“漏”到了后边，最终到了大规模并行开发阶段才发现，可能造成“程序员碰头儿临时决定”的情况大量出现，软件质量必然将下降甚至导致项目失败。其中，采用哪些现成框架、哪些第三方SDK、乃至哪些中间件平台，都应该考虑是否由软件架构的开发视图确定下来。如图3：图3设备管理最底层文件由C+编写，完成的CPP文件应用于设备设置，有需要时调用数据库文件做修改或查看。图3展示了系统设置的软件架构开发视图：用户终端将基于MFC设计实现，而后台服务器采用了某串口通讯SDK。系统设置包含了不同用户的权限管理，所以需要有一个身份识别来控制，其余的在开发过程中可以由底向上开始集成。3.4物理视图： 物理试图主要描述硬件配置。服务于系统工程人员，解决系统的拓扑结构、系统安装、通信等问题。主要考虑如何把软件映射到硬件上，也要考虑系统性能、规模、可靠性等。可以与进程视图一起映射。物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以 及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理架构和运行架构的关系：运行架构特别关注目标程序的动态执行情况，而物理架构重视目标 程序的静态位置问题；物理架构还要考虑软件系统和包括硬件在内的整个IT系统 之间是如何相互影响的。如图4：图43.5进程视图： 性能是软件系统运行期间所表现出的一种质量水平，一般用系统响应时间和系统吞吐量来衡量。为了达到高性能的要求，软件架构师应当针对软件的运行时情况进行分析与设计，这就是我们所谓的软件架构的处理视图的目标。进程视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。如图5：可以看出，架构师为了满足高性能需求，采用了多线程的设计：l 用户终端中的线程代表主程序的运行，配合开发视图它直接利用了MFC的主窗口线程。无论是用户交互，还是串口的数据到达，均采取异步事件的方式处理，杜绝了任何“忙等待”无谓的耗时，也缩短了系统响应时间。l 功能组件有独立的线程控制着“上上下下”的数据，定义权限机制使数据的接收和数据的处理相对独立，简便用户的使用空间占用率，增加了系统吞吐量。l 在底层的设计中，通过接口间