EOS应用开发过程参考手册
另外，对于参与EOS应用设计的人员，建议对EOS的结构和开发方式以及相关资源有较好的理解，这样才能知道在设计中哪些工作不需要做了，哪些内容需要结合EOS产品的特点进行考虑。
4.2.2. 进入条件
? 已掌握应用项目的基线性需求，即使存在部分不确定的需求，但该部分飘浮不定的
需求不足以对应用架构产生大的影响； ? 设计人员到位，使得工作的开展有人力的保障。
4.2.3. 工作任务
制定项目阶段计划 项目经理 必须 项目经理通过阶段工作计划确定本阶段的工作目标和内容，以及人力计划，时间计划，里程碑的设置等。 系统总体设计 系统架构师、开发经理 必须 不要将系统总体设计的过程理解为完成系统设计说明书中相应章节文档的过程，总体设计如同高屋建瓴，为整个系统确定大体框架，和系统建设的目标。通过总体设计，将明确采用的技术路线、系统外部接口，以及形成下一步具体设计工作的内容和要求。 该项工作在开发经理带领下与系统架构师和项目组中其他有经验的设计人员共同完成，一般采用讨论会议的形式，形成项目组设计人员对系统一致的设计思路。 数据库设计 系统架构师、主程序员、业务专家 必须 数据库设计最好由参与了需求调研工作的数据库设计人员完成，对于小型项目（数据对象在50以内），可以由一个有较强数据库设计能力的人为主形成系统完整的业务对象模型（包含对象名称、主要数据项和对象关系的数据库概念模型），在此基础上设计组讨论通过后，再进行数据项的补充，以及定义形成物理数据模型。而对于中大型项目，则可以分为业务主题交给不同的设计人员完成概念模型，然后整合形成统一的系统概念模型后进行讨论。 在进行数据库ER设计的同时，要求同时收集整理形成系统的业务字典定义表，本项工作最终将输出数据库设计文件（例如PD工具产生的pdm文件）和《业务字典定义表》。 数据库设计工作推荐选择数据库建模的工具，例如PowerDesigner或者ERWin， 页面框架设计 开发经理、架构师、美工 必须 对于WEB应用，需要考虑系统用户界面的表现方式，例如页面的风格要求、菜单形式、页面布局模式、页面样式定义以及web资源（页面文件、图片文件、js文件、样式文件等等）的命名要求和目录规划等等，如果用户对于系统的界面效果有较强的要求，需要美工在WEB框架设计的指导下，形成应用的页面效果图和一套风格统一的样式。 由于EOS提供了基础的应用框架，包含了缺省的页面布局、菜单风格、页面样式等，http://www.primeton.com/ 第21页共44页
EOS应用开发过程参考手册
在进行应用的页面框架设计时，要充分考虑与EOS应用框架融合的问题。可以采用2种处理方案，方案一：在EOS提供的框架基础上进行补充扩展，例如，沿用EOS提供的样式定义，只是修改样式标记的效果定义（美工完成），这样修改后的样式使得EOS提供的应用功能（如权限管理）和应用本身的功能在风格上一致起来。另外，沿用EOS应用框架中js、图片、样式文件的目录等，方案二：应用完全自主定义页面框架，这样可以不受限于EOS的内容，采用这种方案的项目往往项目组已经有一些原有项目的WEB框架复用方案、或者认为EOS提供的WEB框架不符合应用项目的要求。 以上两种方案都是可行的，前者要求对EOS应用框架的内容有一定了解，采用这种方案将有助于降低项目在WEB框架设计的工作量，所以也是推荐的方式。 页面框架设计的工作成果可以体现在《系统设计说明书》和《项目开发规范》中。 系统功能分解 开发经理、架构师、主程序员、业务专必须 家 系统功能分解的工作包括： ? 针对需求和业务模型（数据库概念模型）完成子系统、一级和二级模块的划分，并完成模块编码，其中一级模块对应系统功能的一个业务主题，二级模块对应系统实现时的一个构件包 ? 针对二级模块对照业务需求分解功能点，并且完成功能点的编号 ? 功能分解的成果整理到《系统功能分解与跟踪矩阵》中。 划分构件包（二级模块）的原则：在考虑构件包功能相对独立的前提下关注构件包的规模，项目中构件包划分粒度太细或者太粗都不利于管理和复用，推荐的适度规模为一个构件包包含对3个以内业务实体和实体之间关系表的管理，当然，这不是严格的限定，而是需要设计人员来把握的。 分解功能点的原则：对于功能点的粒度定义为：在程序实现中基于业务操作的角度不可能再细分的功能单元，例如”课程管理”并不是一个功能点，只有细分到“增加课程“、“删除指定课程”、“删除符合查询条件的课程”这样的粒度才是一个功能点。分解完整后的系统功能点一定包含需求定义中的所有业务功能。 另外，对于某些不是由业务功能需求所带来的工作任务，也可以作为特殊的功能反映在《系统功能分解与跟踪矩阵》中。 在功能分解的过程中，还要考虑分解的功能是否已经由EOS提供的构件库实现或者由以往的EOS应用项目实现（譬如EOS已经提供了权限管理、组织机构管理，是否满足本项目的需求），或者在已有构件库实现的基础上进行扩展。对于此类功能，需要特殊标注，以便在考虑设计和实现的工作量时加以区别对待。 本项工作内容形成的《系统功能分解与跟踪矩阵》是项目实施过程的重要文档，从这个文档形成开始，所有与项目开发相关的工作的评估、分配和跟踪都是基于它完成。有关该文档的使用方法，将在参考模板部分详细说明。 功能设计任务分配 项目经理、开发经理 必须 针对上一步完成的《系统功能分解与跟踪矩阵》，项目经理和开发经理将组织设计组进行功能设计的优先级和工作量的评估，并在此基础上进行设计工作的分配。在进行任务分配的同时，开发经理需要结合前期整理的开发规范和总体设计内容对设计工作提出要http://www.primeton.com/
第22页共44页
EOS应用开发过程参考手册
求。 本项工作的成果将体现在对《系统功能分解与跟踪矩阵》的修改中。 页面原型设计 主程序员，构件包所有者 可选 页面原型设计即通过静态页面（html）方式实现系统的用户界面，页面原型将承载设计的如下信息： ? 系统的界面风格：如菜单形式、页面效果、页面布局形式等 ? 通过菜单和功能链接所体现出的系统的功能 ? 各个功能的界面表现形式、界面信息和信息输入（显示）方式、界面提供的功能链接或者按钮等 ? 功能与功能之间的链转关系 页面原型的详细设计要求可以写入到开发规范中，因为原型的绝大多数规范同样也是功能实现时的规范，所以在考虑原型规范时，要确定是否能够在开发时有很好的延续，这种延续包括：目录命名、界面内容、资源（js/css）等等，最好的做法是：开发时只需将html页面改为jsp页面，同时替换其中的静态数据部分就可以了。 另外，在设计静态原型时要考虑整个原型是一个整体（有统一的入口和链接关系），而不是每个功能单独提供，还要求能够脱离服务器使用，以文件包形式提供，这样可以很方便的向最终用户演示。（在很多项目中，页面原型设计被用户要求在需求阶段完成，作为需求规格的一部分，但这并不能说明该项工作属于需求阶段，而只是需求与设计结合起来了）。 良好的页面原型设计将有助于提升设计的质量，是系统设计说明书最佳的补充。原型设计是比较耗费时间的工作，在权衡进度与质量的要求情况下，对于系统中某些简单的功能或者与已设计的功能原型很类似的其他功能原型，可以不实现原型。 应用功能设计 主程序员，构件包所有者 必须 应用功能设计是这对分解后的功能点进行设计的过程，由于已经完成了数据库设计和界面（原型）设计，所以功能设计将侧重于原型和数据库设计所不能表达的内容，包括： ? 功能的隐含信息：在页面上无法体现的内容，例如在增加操作员功能的原型中，界面并不会体现出“增加时间、操作员ID”等数据项，这些信息是在业务逻辑处理时由系统增加的 ? 功能的处理流程：描述在界面上激活某个操作时系统的处理过程，对于简单的处理，可以通过文字进行描述，对于复杂的情况，则建议以序列图结合文字描述方式 ? 功能的业务规则：譬如业务编码方式、输入数据格式要求，数据验证格式等等 ? 功能对应的数据实体对象：该功能需要操作的数据库表和视图 从以上对功能设计的要求来看，相当于功能的详细设计，但设计过程主要考虑的是业务处理的流程和数据，而没有OO的对象设计概念，这也是EOS体系下进行系统设计的一个重要特点。 可以说，数据库设计、原型设计和功能设计是系统设计的有机整体，彼此之间相辅相成，在三者设计充分的情况下，在EOS上进行开发就显得比较简单了。但是如果没有进行页面原型设计，则要求功能设计时，详细描述功能对应页面的信息内容和输入/显示方式，布局要求等等，所有的功能设计将按照功能分解的层次整理到系统设计说明书中。 http://www.primeton.com/
第23页共44页
EOS应用开发过程参考手册
制定项目开发规范 开发经理、架构师 必须 项目开发规范并不是仅仅指导开发过程的规范，实际上整个项目实施过程中对于技术工作的要求都可以整理进来，包括了设计、原型、开发、测试以及文档编写等等，通过这个文档，形成对各项技术工作的指导，有利于形成项目组统一的工作方式，有利于开发出一个性能卓越，质量优良的系统，同时也便于系统的后期管理和维护。 制定项目开发规范的过程是渐进和迭代的，实际上从需求阶段就可以开始此项工作，将工作过程中的一些统一要求和做法加入到规范中，形成项目团队共同的规范要求，开发规范内容完善的方式有2种：一种是规划性的，在开始某些工作前先考虑对于工作的要求，另一种是改进或者补充，是指在具体的工作过程中，对于规范内容的补充或者改进，两种方式相辅相成，形成最终完整的项目开发规范。 关于项目开发规范的文档内容结构，没有统一的要求，可以在提供的参考模板上结合项目的情况进行补充或者删减。需要注意的是，规范中涉及到的内容必须是统一的，避免出现前后语义矛盾或者冲突的地方。 一般而言，项目开发规范将作为系统测试中对于非功能性要求的重要标准，制定它很重要，制定后的执行则更为重要，否则花费时间做了这个事情而不严格执行，还不如不做。另外，越早制定完整，对项目的帮助越大，如果一个规范性要求在进入到规范之前，已经在项目组形成了不同的做法，再要求统一到这个规范下，无疑要浪费很多的时间，例如，项目开发进行到一定阶段后，意识到要求统一日期时间的显示格式，而这是，每个开发人员都按照自己的方式处理日期的显示格式，这样，无论统一成那种格式，都会引起某些开发人员的改动工作。因此、项目开发规范要求在设计阶段就定义清楚。 开发环境准备 开发经理 必须 开发环境准备的工作包括： ? 准备开发时数据库服务器，并按照数据库设计初始化数据库表和视图，分配数据库用户（建议开发人员共享同一个数据库服务器，而不是每个开发人员各自连接独立的数据库） ? 开发时应用集成环境服务器的准备（应用服务器、EOS Server、以及应用环境的初始化） ? 对于开发环境的使用要求说明（可以放到项目开发规范文档中） ? 在EOS Studio中结合页面框架设计的内容对EOS的构件模板进行修改，并导出形成项目级的模板文件，以下是EOS提供的模板设计和开发结合的流程示意图： http://www.primeton.com/ 第24页共44页
EOS应用开发过程参考手册
分析设计人员开发人员数据实体设计导入模板页面布局模板页面向导模板管理CSS样式模板设计视图控件模板功能模板源代码视图展现构件开发业务构件开发导出模板分发模板页面调试构件调试 ? 通过EOS Studio初始化EOS项目工程，并导入到配置管理服务器中（推荐使用CVS），初始化的工作包括：建立项目（如果分为子系统，则按每个子系统建立一个项目）、建立项目中的构件包、为每个构件包导入对应的数据实体，这样，开发人员开发时，首先在STUDIO中从CVS导出项目，然后就可以在初始化的项目工程基础上进行开发。 【注意】：如果开发没有使用配置管理服务器，则可以在完成项目初始化后，通过EOS Studio导出源码工程，提供给开发人员进行导入。 技术课题攻关 架构师、主程序员 可选 在一个项目实施中，总会或多或少或大或小存在一定技术上的难点或风险，譬如，如果没有采用EOS，可能会考虑应用框架的整合工作。譬如，项目中要提供单点登录，需要对单点登录的技术方案进行技术预研等等。这些都统称为技术课题攻关，一般在系统进行总体设计后，由开发经理和架构师决定是否需要列出某些技术课题进行预研，预研过程可以由主程序员在架构师的指导下进行，通常会形成具体的技术提交物或者技术解决方案。对于技术提交物，还需要提供使用手册，包括实现的说明、使用的接口描述、是否存在技术风险等等。而通过评审的技术提交物，将直接进入到项目初始化工程中。 如果开发经理和架构师认为列出的技术风险是可控的，而且所花费的时间对项目的进度影响比较小，在设计阶段资源紧张的情况下，也可以将这些工作直接放到开发阶段中处理。 制定和实施配置管理方案 开发经理、配置管理人员 可选 从本阶段开始，项目组的人员规模在不断扩大，工作的产物也越来越多，为确保项目组工作成果的管理和共享，建议进行项目的配置管理。配置管理的对象包括项目的文档和源码，以及其他的项目中间产物。考虑到EOS Studio与CVS的良好继承性，推荐使用CVShttp://www.primeton.com/
第25页共44页