开发原则(Development Principle)

1         概述

在软件设计前，将涉及很多准备工作，可能包括：

1． 如果确定需求、明确目标。头脑风暴、已有项目经验等。

2． 选择那种开发方法，Rup、UML软件统一过程、敏捷等，采用那些模板协助开发过程。

3． 如何管理项目。评估工作量、确定资源、进度控制。选择那些工具支持项目的进度。

4． 如果确定开发策略。自己开发从头开发，还是采用已有框架和工具。避免“从头造轮子”。这需要一定的经验。

5． 如何做好架构设计。包括：业务建模、接口方式、可扩展性等。

6． 如何选择技术框架、优秀技术组件、开发辅助工具等。

7． 如何确定设计的粒度。

8． 如何度量自己设计。

9． 性能考虑等等

一个不合理的设计，可能导致后果是比较严重的，例如：增加维护成本、可扩展性差、理解困难等等，为了更好的进行分析、设计工作，本文对设计提供一个指导性原则和方法，并进行了分析和实例。

2         设计愿景

我们的设计能够提供快速的、准确的、良好可扩展性的方法以满足客户需求。它应该具有下面特性：

1． 遵循UML统一软件开发过程。

a)        我们要学习和遵循他们的好的设计思想。

b)        但是不是严格的、本本主义的照搬。

c)        我们要把关键描述记录下来，并形成文档， 例如：体系架构图、关键类图、关键流程图、关键状态图。 可以作为互相交流的基础、进一步扩展的依据。

2． 具有成熟框架和工具。

a)        框架能够屏蔽底层的逻辑，比如：事务管理等。

b)        工具可以大大提高生产效率。例如：支持代码自动生成。代替重复性的劳动。

c)        容易测试。保证设计准确性。

3． 基于Web富客户端。

a)        提供友好的界面。

b)        降低分发和升级成本。

4． 应用开发平台和应用产品独立管理。应用产品建立在应用开发平台之上。

5． 基于模型驱动开发。

a)        重点在于模型，而不是代码。

6． 模块化管理。

a)        从功能角度，可以分成不同独立的模块。支持独立开发。

b)        支持可插拔方式的集成。包括：安装、卸载。并且要保证正常的行为。

c)        每一个模块应该包含必要的自述信息。例如：标识、描述、版本、依赖其他版本，安装、写在脚本和业务功能。

7． 设计架构能够支持Software as a Service (SaaS)理念。

8． 良好的文档支持。减少不必要的沟通，增强可维护性。

3         设计基本原则

1． 设计要掌握方法。掌握方法才能不断复制成功。

2． 提高开发者技能。重要的是技能。

3． 以满足核心业务需求优先。

4． 采用迭代开发方式。

5． 开发要有里程碑。

6． 关键内容要有文档或图表。

7． 避免过渡设计。

4         遵循的标准和方法

4.1         遵循标准

我们要开发要遵循行业规则，例如：行业流程、行业术语。

4.2         以UML软件统一开发过程做指导

科学的一个普遍问题是，必须对被观测的对象和情况，建立一种有意义的分类方法，以便人们理解这些观测结果，也有助于科学理论的持续发展。

――Crady Booch

它不仅仅描述了软件开发的过程指导，对日常的思考问题的方式也有指导意义。

4.2.1        开发过程解析

l         找到问题

n         到底解决什么业务问题－业务建模

n         为了解决业务问题，新开发系统应该提供什么功能和性能？－需求

输出成果：SRS

l         解决问题

n         为了提供功能，系统内部应该有什么样的核心业务机制？－分析

n         为了满足性能，系统核心机制如何选定技术实现？－设计

当前往往需求分析过程，包括：业务建模、需求、分析过程，输入为SRS

4.2.2        开发步骤

 

自外而内，逐步求精

1.      业务建模

2.      需求分析

3.      总体设计：结构设计

4.      总体设计：行为设计

5.      详细设计

4.2.3        其他开发过程比较

直接编码？RUP？XP？DSDM？FDD?SCRUM？ChinaUP？

 

4.3         UML改进分步进行

1． 愿景和涉众

a)        学会写清晰的愿景文档

b)        学会寻找涉众

c)        并在团队成员间共享这些知识

2． 业务建模和用例图

a)        用业务用例、序列图（活动图）描述现实问题

b)        找出系统改进的改进点，用用例图表示

3． 关键用例的用例文档

a)        学会针对关键用例写用例文档，而且要考虑涉众利益

b)        改进需求启发技能

4． 所有的用例文档化而且完备

a)        数据需求、业务规则、非功能需求、设计约束

b)        针对整个系统的补充规约

5． 类图和序列图（形式）

a)        从形式上学会用类图序列图表示分析和设计

6． 类图和序列图（内容）

a)        从形式上学会用类图序列图表示分析和设计

b)        掌握面向对象思想方法

7． 其他UML元素

a)        在适当的情况下，灵活使用其他UML元素

5         以开源项目为依托

为了达到设计的目标，降低开发周期和开发难度，作为应用开发框架，需要采用成熟的、开源的、平台独立、灵活的、可扩展的和广泛应用的工具。主要包括：Spring, Hibernate, Apache Tomcat, Apache Ant, DWR, Dojo, JasperReports, PostgreSQL and MySQL。我们也遵循相关的开发标准，例如：XHTML, XML, Java EE, Java portlets, SOAP, ISO3166, ISO369 and ISO4217.

对于客户的需求，我们需要有非常清晰的整体解决方案视图。ERP是个整体的概念，很多其他企业级应用，已经很成熟，并形成标准，我们不从头造车。我们要集中在提供一个容易的方式，与其他企业级的应用，例如：CRM, external POS, OLAP analysis and BI, DMS等进行方便的集成。

6         基于web的富客户端

我们的产品完全基于Web。以网络作为平台，分发和允许用户通过浏览器去使用应用。浏览器是计算机的基本配置，基于Web，产品能够通过Intenet进行分发，客户端更新应用时，不用下载和安装软件。

进来，随着Internet服务的发展，基于Web的用户界面发展迅速，它能提供功能强大的、容易使用的客户端界面。向Ajax技术或相似的技术，能提供丰富的、良好交互性、界面友好的界面。例如：实时刷新界面，不用每次都下载整个界面。对于设计良好的UI，一些框架提供了很好的支撑，例如：Dojo，

7         分两个独立的产品

There are two kind of possible contributions: improvements to the core of the product, the architecture itself. And the ERP specific ones, such as creation of new verticals, modules or plug-ins. Following this logic the Openbravo platform is to be split into two different products: a development platform and the ERP itself.

Application development platform: a platform capable of developing web-based applications following a MDD/MVC architecture completely decoupled from the ERP, so it will be distributed as an independent product.

ERP: the ERP is built on top the this development platform.

This conceptual and physical isolation provides great benefits. Firstly the two products can be independently developed, mutually benefiting each other. For instance, any technological platform improvement will be immediately reflected in the ERP. Secondly, the platform should only take care of offering the core and common functionalities. This makes it specific-application agnostic, more general, and thus allows to use this platform to build other information systems

8         基于字典模型

One of the current platform's strengths lays on its dictionary, built based in a Model Driven Development (MDD). The most important aspect of a MDD architecture is the fact that it's focused on the model rather than in the program itself. It describes all the desired components of the system: tables, windows, reports, etc. Then the whole ERP is written following this model. So the real value of the ERP is condensed in this dictionary model, and at the same time it is isolated from other technologies not related to the ERP.

The system modeled by MDD is going to be implemented through a MVC architecture, using Spring.

Currently most of the Openbravo ERP's windows consist on data editing and processing interfaces, such as the Sales Order Window. This kind of interfaces are formed by various elements such as input and combo boxes, selectors, check-boxes or radio buttons among others, all them defined in the Application Dictionary. As this interfaces are built through this Application Dictionary, it is important for it to be flexible and extensible. This means it will be an easy job to add new functional object types and properties into the dictionary model.

The power of an ERP comes with its customization level. Openbravo understands this need, and this is why the new platform and Application Dictionary give special importance to this key point. Openbravo Green will have native support for localization and customization, consequenced by its multi nature: multilanguage, multiclient, multicurrency. This is possible thanks to the business logic implementation, which is typically localized or customized -such as tax calculation and accounting processing- by engine rules and by architecturing the whole system in a modular way.

9         模块化管理

In a distributed development model such as this one, with many teams and individuals contributing to the project, the new Openbravo platform introduces the possibility to package these contributions into modules. From a user and functional point of view there are different kind of modules:

Localization packs: languages and accounting schemas.

Functional extensions: add-ons to the current functionalities, or creation of new ones like human resources or data mining.

Verticals: a vertical is a development made for an specific business area, such as the construction or hotel industries.

Customizations: any other modification or adaptation.

From a software management perspective these modules will be self-contained with all the information needed to guarantee the proper behaviour of the Openbravo application after the installation of a desired module. Information like an identifier, description, Openbravo version, dependencies with other modules, scripts for installation and uninstallation and the functionality included. The Openbravo module management tool will assist the Openbravo administrator with the installation or uninstallation.

Openbravo will create a central repository with modules, easily accessible from the Openbravo module management tool, to offer the best modules available to the users. This way when an user needs a certain functionality, there will be the possibility to search in this repository for a module that fits the user's requirements and then test it, before trying to develop a new module. This repository will also be opened to all Openbravo developers who want to contribute with custom modules

10    参考资源

6.      http://wiki.openbravo.com/wiki/index.php/Design_principles_for_Openbravo_Green

7.      UMLChina提供的相关的资料。