面向对象嵌入式系统开发笔记3-迭代和增量式的嵌入式系统开发过程

3 面向对象嵌入式系统开发笔记3-迭代和增量式的嵌入式系统开发过程

3.1智力劳动和机械劳动

    管理把劳动在复杂性视角上分为简单和复杂劳动。同样从智能视角可划分为机械和智力劳动。机械劳动结构方面是针对某一/某几个部分发生作用，从行为方面说是有限序列的重复作用。智力劳动结构上说多点作用，权重分布不是简单的线性，行为方面，对多点的作用是一个综合和运筹的过程。
    人工智能表明，人类大脑是由神经元网络组成的。人类之所以智慧，文字是很大的原因。事实上，越是越需要智慧的劳动，越需要长时间的学习。知识是如此的广大，但能进入到每个人大脑的中的知识却非常有限。大脑中的知识存储不是替代的方式，而是叠加方法。迭代是人类智力劳动的本质特征，它是由大脑神经元网络性质所决定的。

    计算制品的制作过程无疑时一种智力劳动，它具有智力劳动所固有的绝大部分特点。事实上，在开发软件过程中，无论是提出需求的用户还是软件系统开发人员，对于系统所具有的全部特征尤其是行为特征的认识并不是一次性完成的。
    用户对需求的认识实在抽象概念到具体产品实现再到概念的反复循环中得到的。
    开发人员对制品的理解也是在反复迭代过程中完成的。
    以往的软件工程中，解决这种需求变更的理论和方法十分有限，面向对象技术从诞生的那一天开始，就自然地兼容了变更问题。

3.2 用例驱动、以框架为中心和迭代增量式过程

    目前，计算机解决问题朝着更庞大、更复杂的方向发展，部分原因时计算机的性能逐年增强，用户期望值随之增大。计算机软件开发的工程化方法研究没有停止过，出现了瀑布模型、原型模型、螺旋模型等，对软件产业发展产生巨大的推动作用。但是软系统复杂性则更加，加之固有的需求变更等原因，以往的的模型难以应付，另外由于软件开发在生命过程中描述方法的不统一，各个过程阶段之间形成了难以跨越的鸿沟。
    软件问题可以归结为开发人员将大型软件所包含的各个部分集成为一个整体协作运行的系统问题。软件开发团队需要一种受控的工作方式，需要一个过程来集成软件开发的方方面面并需要通用的方法或过程来完成如下工作：
-指导一个群组活动的顺序
-布置每个开发人员和整个群体的任务
-确定开发何种制品
-提出监控和测量一个项目产品活动的准则
    UML主要发起人提出了一种软件问题解决方案，统一软件开发过程，包含将一个将用户需求转化为软件系统开发所需要的活动集合，更像是一个通用的过程框架。突出特点可以用用例驱动、以框架为中心、迭代式增量式过程三个关键字说明。
    目标：指导开发人员有效地实现并实施满足用户需求的系统。
    衡量：成本、质量、交付时间。

3.2.1 用例驱动

    参与者：用户，不仅仅是人。
    交互：用户与系统之间的相互作用。
    用例：一个有意义的交互。
    用例获取的是系统(某一级类元）的功能需求，所有的用例集合是用例模型，可以取代需求规格书。
    用例除了能够在用户、分析和设计人员之间提供理解、交流和达成共识的平台外，也是系统分析、设计、和开发人员进入工作的基础以及成为系统最后测试验收的依据。还能够驱动系统设计、实现、和测试的进行。

每个软件开发组织的业务流程组织过程可能是不同的，但是一定要有一个业务流程，否则业务组织就会处于混乱状态。

    虽然用例可以驱动过程，但是这个过程不是单向的。用例与系统框架是协调发展的。用例驱动不仅是分析系统需求时，也是开发技术人员介入系统的切入点，而且是各个层级的类元（系统、子系统、类）的构造过程也是从用例开始的。反过来系统框架又会影响用例的调整。
     需求捕获目标：1.发现真正的需求；2.以适合用户和开发人员的方式加以表示。
    真正的需求是指实现时可以给用户带来预期价值的需求。注意往往在项目开始，用户本身也不能十分确定这些东西。
    分析和设计期间，用户模型经过分析模型转换为设计模型。简单地说，分析和设计模型都是由类元和说明如何实现用例的实现结合组成的。分析模型是需求的详细的规格说明，开发人员利用分析模型将需求工作流中描述的用例转换为概念性类元间的协调。分析模型也可以用来创建可复用的软件组件。分析模型与设计模型不同，他是一个概念集合而不是软件实现元素的集合。分析模型中的每个元素都可以从实现它的设计模型中得到跟踪。
    设计模型是一个用于描述用例实现的类元集合。它即关注功能需求和非功能需求，也关注与实现环境有关的并最终影响系统的其他约束。是系统实现的蓝图。和实现模型之间存在直接的映射关系
    开发人员根据设计模型实现设计好的类。或者说把设计模型直接精化，实现过程不改变系统结构，只是在设计好的框架（骨架）里添加血和肉。软件开发人员所建立的源代码和相关文档的集合就成为实现模型。实现模式是设计模型依某种关系形成的直接映射。这种映射何以通过自动程序实现也可以通过人工完成。
    最后，测试工作流期间，测试人员验证系统是否能够实现用例中所描述的功能和系统需求。每个测试用例定义了输入、运行条件和结果的集合。测试用例和相应的用例存在跟踪依赖关系。执行用例的测试属于系统功能测试。迭代该过程不同之处在于功能测试不一定等待系统全部完成后才开始，执行用例的测试可以在分析模型、设计、实现模型上以不同的粒度进行。测试模型除了与功能有关的测试（黑盒)用例外，还应该由对于各层级系统的结构和实现方面的测试(白盒)。

3.2.2 以框架为中心

    构架这里一般指软件系统组织总要决定的集合，是对系统全方位的问题的决策。软件构架不只是涉及结构和行为，还涉及到使用、功能、性能、柔性、复用、可理解性、经济性和技术约束以及折衷方案、美学等。本书中，体系结构表示机械、电子和软件三个部分的系统结构和之间接口(关系）的定义.
    本书中框架是指反应系统软件类元结构和行为本质特征的软件体系结构，就像一个建筑物钢筋骨架。系统分析的主要目的之一是获得一个稳定的和经得起较长时间检验检验的系统软件分析框架，而其他组件可以通过迭代逐步增加和精化。
    软件框架概念包含了系统中最重要的静态和动态特性。框架是根据用例模型和系统的其他方面约束（硬件的功能与结构、操作系统、网络通信需求）共同影响综合形成的。框架刻画了系统的整体设计，它去掉了细节部分，突出了系统的重要部分。换句话说，它是系统在体系结构层级的抽象。因为究竟什么是重要的部分依赖于判断，判断又来自于经验，所以，框架的好坏也就依赖于框架设计师的素质。然而，过程可以帮助他们确定正确的目标，如易理解性、适于将来变化的柔性以及可复用性等。也可以从已有的模式中选择组件或者从中获得灵感。
    每一个系统都具有功能和表现形式两个方面。这里功能与用例相对应，通过用例来精细化描述系统行为。用例和框架之间相互影响的。一方面，用例在实现时必须适合框架；另一方面，框架必须预留空间以实现现在或将来需要的用例。事实上，开发过程中框架和用例往往都是并行进化的。
    软件开发不仅仅是盲目依赖用例驱动工作流就能完成的，要得到一个可用的系统还需要考虑更多的因素，比如框架和系统约束，可以把框架看成是所有参与开发的人员必须达成或者至少能够给共同理解的系统实现的规格说明书。
    要建立一个狗窝、小房子、教堂、购物中心或者摩天大楼，情况是不一样的。许多大型建筑需要一组建筑设计师来设计它们。设计组成员必须彼此了解设计的进度，也就是说，他们需要把自己的工作用其他成员能够明白的形式记录下来，并且用一种非专业人员如业主、用户和其他项目相关人员等可以理解的方式表达出来。最后，还得通过施工图纸将设计交给建筑商。
    一个大型、复杂的嵌入式系统软件需要一个框架设计师，以便于开发人员可以向着一个共同的目标努力。
    嵌入式系统软件开发过程需要一个框架通常原因如下：
 1.理解系统
 2.组织开发
 3.鼓励复用
 4.进化系统

1.理解系统

    系统的描述必须被所有相关人员所理解。以框架为中心和基于模型的开发，可以防止出现这种无法理解的想象。

2.组织开发

    通过将系统划分为带有明确定义接口的子系统或组件，并让一个开发小组或个人负责其中的一个部分，无论他们是在哪里，框架都可以减少负责不同子系统的开发组之间的交流工作量。一个好的框架应该明确定义这些接口，尽可能减少子系统间的通信。

3.鼓励复用

     就像计算机硬件推行标准化需要一定的时间一样，软件组件的标准化也需要积累经验，空吧会需要经历更长的实践过程。
     软件产业要达到很多硬件领域已经达到的标准化水平，好的框架模式和明确的接口是实现这个一目标的关键。好的框架为开发人员提供了可以在其上开展工作的骨架，而框架模式是已经验证时正确的，安全可靠的和接口定义明确的框架。

4.进化系统

    实际要求是，开发人员应该可以改变部分设计和实现，而不必担心这种改变会对整个系统产生非期望的效果。使用基于模型和以框架为中心的方法，开发人员完全可以在系统中实现心得功能（用例）,而不会对现有的设计和实现造成太大的影响。换句话说，系统本身应该对变化具有一定的柔性（容变能力）。

3.2.3 迭代和增量式过程

    将一个长期而复杂的任务划分成一系列较小的任务时切实可行的，每一个小任务可以成为一个袖珍项目，每个袖珍项目都是一次能够产生一个增量的迭代过程。每一个迭代都需要经过需求、分析、设计、实现和测试等主要流程。而增量是指通过一次迭代时目标或者从模型，或者从代码方面会有所增长。为了获得最佳效果，迭代过程必须时受控的，也就是说，他们必须按照计划好的步骤有选择地执行。
    开发人员基于两个因素确定在一次迭代过程中要实现的目标。首先，迭代过程要处理一组用例，其次，迭代过程要解决突出的风险问题。
    迭代前期，技术方面主要是形成系统框架为基本目标，迭代后期主要以选定的框架为向导来创建设计，用组件来实现设计，并验证这些组件是否满足相关用例。
    为了在开发过程中取得最好效果，项目组应设法选择迭代过程实现目标。事实上，减少不可预见问题最需要的就是开发经验，同时开发经验也是降低系统其他风险的最直接保障。受控迭代的好处如下：
1.将成本风险降低为获得增量所需要的费用
2.降低产品早期阶段的错误风险
3.加快项目的进度
4.适应计算制品中必然存在的需求变更问题

     用例驱动、以框架为中心和迭代增量式过程三个概念时三位一体的，去掉三个概念中的任何一个都会使同意过程开发过程不够完整）。
初始阶段
 迭代过程围绕着如何将一个好的想法发展为最终产品的构想而进行。需要弄清如下：
1.系统向他的用户提供什么样的基本功能？
2.该系统的架构应该时什么样子的？
3.开发该产品的计划如何，开销多大？
这个阶段需要处理用例。这个阶段，框架是实验性的，通常只是包括主要子系统的大致轮廓。要确定系统最主要的风险及其优先顺序，需要对下一个阶段（细化阶段）进行详细规划，并对整个项目进行粗略的估计。

    
细化阶段
 主要围绕着形成系统框架而进行。该阶段，需要详细说明该产品的绝大部分用例，并设计出能够被测试的系统框架。在细化的末期，需要规划完成整个项目所需要进行的所有活动，估算完成项目所需要的资源。这里的关键问题是：用例、框架和计划是否足够稳定可靠，风险是否得到充分控制，是否能够按照合同的规定完成整个开发任务。

构造阶段
 主要围绕着详细设计和实现产品而进行。在这一阶段，将构造出最终产品，或者说为骨架增加肌肉和美化皮肤。在构造阶段的末期，产品将包括组织内部实现相关的和用户要求的对所发布版本达成共识额所有用例。但是，产品时智力劳动的制品，不可能没有缺陷的，很多缺陷将在移交阶段发现和改正。这个阶段的末期需要回答的问题是：移交给用户的产品是否完全满足了用户的需求？

移交阶段
 主要围绕完善产品的实现而进行。少数有经验的用户试用该产品并报告产品的缺陷和不足，开发人员则改正所报告的问题，通过适当的迭代过程，最终完成该产品。移交阶段包括制作、用户培训、提供在线支持以及改正交付之后的缺陷等活动。

ROPES模型

分析

    1.需求分析，从客户那里获取需求，辨识黑盒的系统的全部需求，包括功能和非功能上的。
    2.系统分析，将系统的关键概念和关键结构进行细化，并将系统功能划分给各个硬件组件和软件组件。不隐指任何类或对象，更不用说去识别他们，经常在大型系统上，这个阶段需要确定大尺度的组织单元，为组织单元构造详尽的行为规格说明，按软件、电子、机械三方面对系统将功能进行划分，最后用可能的方式最执行模型进行行为测试。目标时获得档次迭代的实施模型、运行规格说明和软硬件规格说明。
    3.对象分析。该阶段要给出重要的对象何类，以及他们的主要属性。系统分析定义了系统要求具备的行为，这些行为 要通过这个阶段给出的对象结构予以满足。这里的类和对象时实现前边阶段定义的系统功能主要概念结构，而不是最终实现的物理结构。这个阶段得到的模型为概念模型而不能成为物理模型的原因。对象分析包括对象结构分析和对象行为分析两个基本过程。在实践中，这个过程通常是交替甚至并发进行的。这个阶段的主要活动包括：应用对象定义策略来发现重要对象，对对象进行抽象进而给出类，解释对象和类时如何关联的，构造符合用例行为需要的对象协作机制，定义交互对象最重要的行为，给出对象最重要的操作和属性，将性能约束分解为类操作的性能约束等。

设计

设计定义了与分析模型保持移植的对所处理问题的特定解决方案。设计模型和分析模型都是系统模型在不同抽象层次上的试图，显然它两保持一致是非常重要的。分析模型到设计模型的进化可以通过细化和转化两种方式进行。转换时自动/半自动过程。细化时人工方式主要包括如下：
    1.框架设计。主要关注影响大部分或全部应用策略的设计决策。系统分析阶段的框架主要时针对包括电子、机械和软件三方面的概念框架，而这个阶段的框架设计主要指软件框架。主要活动包括任务的是识别和特征刻画，定义软件组件及其分布情况，设计模式的应用，全局性错误（保险性、容错等）处理等。
    2.机制设计。该阶段给前面产生的框架（协作）添加心得更精细化的内容，并根据某些系统优化标准对其进行优化。作用域空间是系统框架中的单个协作，通过添加类或者应用模式对协作中的类元具体化。系统大需要多次迭代，系统小一次定义每个协作或系统框架中所有的类是可能的。这个子阶段的活动包括添加类或应用模式来细化协作，确定类之间的关系实现，确当类的绝大多数属性和操作等。所获得的设计模型应该时面向对象软件实现的最小划分的全集，也就是说系统的所有可封装的类和对象在这里全部表示完毕。
    3.详细设计。时设计的最低层次。这个子阶段，添加了优化最终原型所需要的更详细信息，包括对关联、聚合和组合的实现方式的定义，操作的前置不变量和后置不变量、类的异常处理、属性的确切类型和有效范围、方法或则和状态中的复杂算法设计等。这个阶段所得到的设计模型，应该能使看得懂模型的代码设计人员无异议低进入代码设计过程。

转换

转换过程将系统UML模型转换为所使用的开发语言程序的源代码，并听过编译器生成可执行目标代码。这个阶段的单元测试属于百合测试，用于保证所测试单元的内部正确性并符合设计要求。

测试

测试过程要在应用程序时应用一组测试用例并产生可观察的结果。这个测试阶段过程属于黑盒测试。用例主要基于需求分析和对象分析阶段所确定的场景。每次测试对一个迭代原型进行，包括集成测试和验证测试两个子过程。

评审

不可或缺，最终确认此次迭代产生的原因的正确性与不足，决定是否增加迭代次数。

3.3 嵌入式系统软件框架

3.3.1 什么是系统软件框架

    实践中发现从三个相关但不相同的视角来建模系统就可以描述系统的无论从结构还是从行为方面的本质特征。三个视角为内部结构视角、类元交互视角和类元生命历史状态视角，反应这三个是视角的UML模型时类模型、交互模型和状态模型。这里把这个三个模型的集合成为系统的软件框架。
    类模型描述系统内部类元的特征、类元之间的相互关系以及类元所属的每个类的属性和操作，该模型捕获系统的静态特征。分析阶段产生的概念模型，就是最高层次的类模型。
    交互模型描述类元要如何交互才能产生所需要的结果，它从系统独立类元间的交互视角描述了系统类元件的协作行为。跨越了从系统整体来看的外部共鞥到内部结构的界限，也跨越了系统由结构到行为的界限。可以从不同抽象层次上建模,与状态模型互补。
    状态模型,可以从不同层面（系统、子系统、对象）以整个类元行为的全为描述空间，从可控制视角描述全景行为。描述所表现类元通过相应外部激励而产生的操作序列，而不是描述操作做了些什么，对什么进行操作或操作是如何实现的。典型的软件过程其实合并了这三个方面：数据结构来表现类元的属性，按事件设定操作顺序，定在类元之间传递数据和控制。

3.3.2 组成框架的三种模型

1.类模型

描述系统中类元的结构，及他们的标识，与其他类元的关系、属性和操作。提供了状态模型和交互模型的上下文。对象是面向对象划分世界的单元，而类是对象的静态描述。目标时从真实世界中捕获那些对应用而言的重要的概念。

2.状态模型

描述了与操作的时间和顺序相关的某个类元全景行为，及标记变化的事件，界定事件上下文的状态以及事件和状态的组织。捕获控制，它反映操作出现的顺序，不考虑操作做了什么，他们在操作什么，或者他们时如何实现的。状态图中的动作和事件转化成了类模型中类元的操作。

3.交互模型

描述了类元之间的交互，某一级别域（系统、子系统、组件）内部独立类元之间如何通过协作来完成该与从外部看来的功能行为。由UML通信图或顺序图来表达。

3.3.3 框架模型间的关系

每一种模型都描述了系统的一个方面，也包含了对其他模型的应用。类模型描述状态模型和交互模型操作的数据结构。类模型中的操作对应于事件和动作。状态模型描述了类元的控制结构，它显示了依赖于类元取值的决策，并引发动作来改变类元取值和状态。交互模型专注于类元之间的信息交换，并提供了系统协作的整体视图。

对于框架的三个模型无法捕获系统的那部分内容，通过附加其他图或描述语言仍然可以接受的。

3.4 过程中的阶段制品

管理方面，应该注重里程碑时间的记录和技术文档的归档。里程碑事件包括可行性研究、用户需求、项目开发计划、需求模型、分析模型、设计模型、实现模型和测试模型等，可能还需要加上用户手册和维护手册等。这里仅讨论技术过程所需要文档，不涉及项目管理文档

1.需求分析文档

从书面的用户需求开始合理的技术介入点。需求分析的结果制品是分析模型，包括用例图和场景图。
需求分析之后，系统的后期活动都应围绕这框架进行。分析框架从技术上来说，是系统自上而下向内部的第一层观察，如果系统足够大且足够复杂，这一层可能只看到构成系统的子系统和构件，如果系统足够小且足够简单，这一层可能看到的就是构成系统的类（甚至对象)和构件。重点不是系统的具体实现而是功能实现，往往是粗粒度的，知注重咋样的协作达到系统的功能要求，而对于非功能要求是不需要细致考虑的。

2 .设计阶段

产生能偶被编码人员具体实施的设计框架，对分析框架的进一步净化。包括选择和细化两个主要内容，选择是一种优化过程，对于分析框架的实现可能由多种方案可以选择，设计要从中按照某种优化原则选择出最佳，可以参考已完成的各种设计模式。如果模式不能满足系统的设计要求，需要自己实现系统的所有细节。从框架的设计力度方面可以再分为架构设计、机制设计和详细设计三个子过程。架构设计需要对分析架构进行设计视角的再次确认，根据实现需要进行适当调整；机制设计的最小考虑单元应该是最小实体类和对象，而设计的重点是这些最小实体间的协作，涉及到关系、结构、职责和角色等，详细设计的目标时系统编码人员可以从这个模型开会时直接进行编码的工作，它涉及到对象所有属性和操作的具体落实如关系、服务、接口、状态和算法的实现等。

3. 转换阶段

把本次迭代原型生成目标代码。目标代码可与i在目标机上运行，也可以在开发机上模型与运行，这个阶段的测试成为单元测试。单元测试仅保证代码所实现的功能的正确性。

4.测试阶段

根据迭代开始的原型所涉及的需求用例来涉及测试用例，并根据测试用例填写测试文档。保证原型能安装在框架内运行的过程就是集成测试。

5.评审阶段

是一次迭代的借宿，也是迭代的开始。项目管理和技术评价的一个交汇点，最后要形成交给管理部门存档的表格或者是一组文件。