|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
判断模式取得成功的一个重要准则是它们在多大程度上达到了软件工程的目标。模式必须支持复杂的、大规模系统的开发、维护以及演化。
|
|
|
|
|
|
我们已经知道，在开发软件时，模式是处理受限的特定设计方面的有用构造块。因此，对软件架构而言，模式的一个重要目标就是用已定义属性进行特定的软件架构的构造。例如，MVC模式提供了一个结构，用于交互应用程序的用户界面的裁剪。
|
|
|
|
软件架构的一般技术，例如使用面向对象特征（如继承和多态性），并没有针对特定问题的解决方案。绝大多数现有的分析和设计方法在这一层次也是失败的。它们仅仅提供构建软件的一般技术，特定架构的创建仍然基于直觉和经验。模式使用特定的面向问题的技术来有效补充这些通用的与问题无关的架构技术。注意，模式不会舍弃软件架构的现有解决方案，相反，它们填补了一个没有被现有技术覆盖的缺口。
|
|
|
|
|
|
单个模式不能完成一个完整的软件架构的详细构造，它仅仅帮助设计师设计应用程序的某个方面，即使正确设计了这个方面，整个架构仍然可能达不到期望的所有属性。为整体上达到软件架构的需求，我们需要一套丰富的涵盖许多不同设计问题的模式。可获得的模式越多，能够被适当解决的设计问题也会越多，并且可以更有力地支持构造带有已定义属性的软件架构。
|
|
|
|
为了有效使用模式，我们需要将它们组织成模式系统。模式系统统一描述模式，对它们分类，更重要的是，说明它们之间如何交互。模式系统也有助于设计师找到正确的模式来解决一个问题或确认一个可选解决方案。这和模式目录相反，在模式目录中每个模式描述的多少与别的模式无关。
|
|
|
|
|
|
好的模式描述也包含它的实现指南，可将其看成是一种微方法，用来创建解决一个特定问题的方案。通过提供方法的步骤来解决软件开发中的具体再现问题，这些微方法补充了通用的但与问题无关的分析和设计方法。
|
|
|
|
|
|
从模式与软件架构的集成中产生的另一个方面是用来实现这些模式的一个范例。目前的许多软件模式具有独特的面向对象风格。所以，人们往往认为，能够有效实现模式的唯一方式是使用面向对象编程语言，其实不然。
|
|
|
|
一方面，许多模式确实使用了诸如多态性和继承性等面向对象技术。策略模式和代理模式是这种模式的例子；另一方面，面向对象特征对实现这些模式并不是最重要的。例如，在C语言中实现策略模式可以通过采用函数指针来代替多态性和继承性。
|
|
|
|
在设计层次，大多数模式只需要适当的编程语言的抽象机制，如模块或数据抽象。因此，可以用几乎所有的编程范例并在几乎所有的编程语言中来实现模式。另外，每种编程语言都有它自己特定的模式，即语言的惯用法。这些惯用法捕获了现有的有关该语言的编程经验并为它定义了一个编程风格。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。
|
|
|
|
|
|
|
|
嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
|
|
|
|
嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。
|
|
|
|
嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
软件架构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把架构的不同部分组合连接起来。软件架构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。架构问题包括总体组织和全局控制、通信协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件架构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通信、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等。
|
|
|
|
软件架构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，“软件外部的可见特性”是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。对于复杂系统和大型系统的开发而言，设计好软件架构是保证软件质量的根本措施。具体来说，软件架构具有以下作用：
|
|
|
|
（1）软件架构是项目干系人进行交流的手段。架构代表了系统的公共的高层次的抽象。这样，系统的大部分有关人员（即使不是全部）能把它作为建立一个互相理解的基础，形成统一认识，互相交流。
|
|
|
|
（2）软件架构是早期设计决策的体现。架构体现了系统的最早的一组设计决策，这些早期的约束比起以后的开发、设计、编码或运行服务及维护阶段的工作重要得多，对系统生命周期的影响也大得多。早期决策的正确性最难以保证，而且这些决策也最难以改变，影响范围也最大。软件架构明确了对系统实现的约束条件，决定了开发和维护组织的组织结构；架构制约着系统的质量属性，通过研究软件架构可能预测软件的质量；架构使推理和控制更改更简单，有助于循序渐进的原型设计；架构可以作为培训的基础。
|
|
|
|
（3）软件架构是可传递和可重用的模型。架构体现了一个相对来说比较小又可理解的模型。架构级的重用意味着架构的决策能在具有相似需求的多个系统中发生影响，这比代码级的重用要有更大的好处。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Java语言起源于Oak语言，Oak语言被设计成能运行在设备的嵌入式芯片上。
|
|
|
|
Java编译成伪代码，这需要一个虚拟机来对其进行解释，Java的虚拟机在几乎每一种平台上都可以运行。这实质上使得开发是与机器独立无关的，并且提供了通用的可移植性。
|
|
|
|
Java把类的概念和接口的概念区分开来，并试图通过只允许接口的多继承来克服多继承的危险。
|
|
|
|
Java的异常处理机制与C++的try/throw/catch相类似，但更加严密。在Java中，通过声明轻型线程来处理并发性，这些线程通过副作用和同步协议进行通信。
|
|
|
|
Java Beans是组件，即类及其所需资源的集合，它们主要被设计用来提供定制的GUI小配件。
|
|
|
|
Java中关于面向对象概念的术语有对象、类、方法、实例变量、消息、子类和继承。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
除了CPU，内存也是影响系统性能的最常见的瓶颈之一。看系统内存是否够用的一个重要参考就是分页文件的数目，分页文件是硬盘上的真实文件，当操作系统缺少物理内存时，它就会把内存中的数据挪到分页文件中去，如果单位时间内此类文件使用频繁（每秒个数大于5）,那就应该考虑增加内存。具体考察内存的性能的参数包括内存利用率、物理内存和虚拟内存的大小。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件，是由多个系统软件组成，在基本系统上有多种配置和选项可供选择，使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
实施项目的组织结构对能否获得项目所需资源和以何种条件获取资源起着制约作用。组织结构一般有三种类型：职能型、矩阵型和项目型。矩阵型可进一步划分为弱矩阵、平衡矩阵和强矩阵。不同组织结构的区别如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
很多组织在不同的组织层级上用到上述所有的结构，这种组织通常被称为复合型组织。例如，在典型的职能型组织中建立专门的项目团队来实施重要的项目；又如，组织采用强矩阵结构管理其大多数项目，而小项目则采用职能型结构管理。
|
|
|
|
|
|
|
|
|
|
|
|
|
