IV、对象设计
在体系规范的指导下,设计可在技术上扩展和适应分析的结果。分析阶段时,域对象模型化应该和技术的细节无关,而对象设计时则是和技术因素密切相关的,包括在体系开发阶段时,采用哪一类的平台、语言和厂家。理论上,你不要修改商业对象,除非是为了维护它们基本的属性和行为而必须这样做。
在体系决议的指导下,一个详细的设计说明应该提到所有类的规范,包括必要的实现属性,它们详细的接口和伪代码或者操作的纯文本描述。规范的详细程度应该达到只要和模型框图结合,就可得到所有必要的编程信息。在许多自动化的软件生产流程中,你可以从面向对象的框图中产生代码的框架。要注意的是stub和 skeleton通常是无需在框图中展示出来的,因为它们对于设计者和编程者来说都是透明的。我在图6中包含它们只是为了说明EJB的基本点。
**************** 图六**************
在你完成详细的对象设计后,你就完成了域对象的对象相关映射。这样做的原因是,虽然面向对象的方法论在目前是比较先进的,不过最流行和持久的商店都是关系型的。此外,一个客户的IT架构在许多方面都已经反映了现有的投资和商业RDBMS厂家的选择。因此将域对象模型转换为关系模型或者数据库表是非常重要的。有很多容器管理的工具,不过它们不能代替一个好的关系数据库设计。
V、实现
有了一个好的架构和细节设计,实现将是一个很清晰的任务。此外,由于我们在体系原型阶段设计和实现了系统的一个垂直部分,因此在实现阶段我们不会碰到很多麻烦事情。在许多公司中,开发者通常都是过早进入实现阶段,特别是当经理在监视他们的时候,因为对于他们,做其它的事情等于浪费公司的时间。
结果是,不再花时间来画UML框图,而是在代码开发中测试想法,这要花数星期和几个月的时间,在这种情形下,所有的体系决议和设计都是在代码阶段作出的,通常要在几个月后才会发现开发已经进入了一个错误的方向。
VI、确认 确认包括有测试以验证该系统符合设计并且满足需求。在整个开发周期中,验证发生在开发和安装阶段。单元测试、集成测试和用户容忍度测试都是重要的主题
在体系规范的指导下,设计可在技术上扩展和适应分析的结果。分析阶段时,域对象模型化应该和技术的细节无关,而对象设计时则是和技术因素密切相关的,包括在体系开发阶段时,采用哪一类的平台、语言和厂家。理论上,你不要修改商业对象,除非是为了维护它们基本的属性和行为而必须这样做。
在体系决议的指导下,一个详细的设计说明应该提到所有类的规范,包括必要的实现属性,它们详细的接口和伪代码或者操作的纯文本描述。规范的详细程度应该达到只要和模型框图结合,就可得到所有必要的编程信息。在许多自动化的软件生产流程中,你可以从面向对象的框图中产生代码的框架。要注意的是stub和 skeleton通常是无需在框图中展示出来的,因为它们对于设计者和编程者来说都是透明的。我在图6中包含它们只是为了说明EJB的基本点。
**************** 图六**************
在你完成详细的对象设计后,你就完成了域对象的对象相关映射。这样做的原因是,虽然面向对象的方法论在目前是比较先进的,不过最流行和持久的商店都是关系型的。此外,一个客户的IT架构在许多方面都已经反映了现有的投资和商业RDBMS厂家的选择。因此将域对象模型转换为关系模型或者数据库表是非常重要的。有很多容器管理的工具,不过它们不能代替一个好的关系数据库设计。
V、实现
有了一个好的架构和细节设计,实现将是一个很清晰的任务。此外,由于我们在体系原型阶段设计和实现了系统的一个垂直部分,因此在实现阶段我们不会碰到很多麻烦事情。在许多公司中,开发者通常都是过早进入实现阶段,特别是当经理在监视他们的时候,因为对于他们,做其它的事情等于浪费公司的时间。
结果是,不再花时间来画UML框图,而是在代码开发中测试想法,这要花数星期和几个月的时间,在这种情形下,所有的体系决议和设计都是在代码阶段作出的,通常要在几个月后才会发现开发已经进入了一个错误的方向。
VI、确认 确认包括有测试以验证该系统符合设计并且满足需求。在整个开发周期中,验证发生在开发和安装阶段。单元测试、集成测试和用户容忍度测试都是重要的主题