统一建模

所谓DSL其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。

对于统一过程而言，敏捷建模是在保持统一过程原有基本优点的前提下，加强这一重量级软件过程敏捷程度的有效途径。相信，会有越来越多的统一过程软件开发实践将受益于对敏捷建模精髓的汲取，而太原同城系统开发的成功实践就是其中一个很好的例子。

系统分析是项目开发中最艰巨的工作，本阶段需要特别注意的工作重点在于：· 补充完善上一阶段可能欠缺的系统的性能需求；· 系统分析员需要站在全局出发，设计合理可行的设计方案；· 在需求不明的情况下设计多种解决方案供客户选择，· 将系统分解模块，最大限度地设计代码复用；· 使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率

这里指的对象是从业务视角观察的对象，如订单，产品，合同，顾客都是一个典型的业务对象，我们关心的也是如何对订单这个业务对象进行建模。系统一般采用关系型数据库来实现了数据的持久性机制，所以存在了面向对象的模型和关系模型间的转换和映射问题。对于小型系统可以直接机械的将面向对象模型转换为关系模型。但对于大型系统这个问题需要进一步考虑。

系统分析决定系统开发的成败，软件建模使系统开发走向成熟。

在本文中我介绍了 JML，说明了它对面向对象分析和设计过程的帮助，并为您举例说明了如何在 Java 程序中使用 JML 注释。

　 组件图经常是一个架构师在项目的初期就建立的非常重要的图。然而，组件图的有用性跨越了系统的寿命。组件图是无价的，因为它们模型化和文档化了一个系统的架构。

序列图用于描述对象之间两种不同类型的交互。一种交互类型是 必须 (must) 交互，其中对象 A 必须向对象 B 发送特定消息。另一种交互类型是 可能 (may) 交互，其中对象 A 可能(但不一定)向对象 B 发送特定消息。这两种形态的序列图描述了这两种不同类型的交互。

回顾20世纪晚期--准确地说是1997年，OMG组织(Object Management Group对象管理组织)发布了统一建模语言(Unified Modeling Language，UML)。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。

所谓的“模型驱动”开发(MDD)方式，已经显示出了它们从根本性上提高软件质量和开发生产力方面的潜力。与传统的方法相比，这种方式是基于较高层次上的抽象和更好的自动化利用的。

至少存在两个了解类图的重要理由。第一个是它显示系统分类器的静态结构；第二个理由是图为UML描述的其他结构图提供了基本记号。开发者将会认为类图是为他们特别建立的；但是其他的团队成员将发现它们也是有用的。

序列图主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。很象类图，开发者一般认为序列图只对他们有意义。然而，一个组织的业务人员会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。

用例模型由一张图表和一组阐明该用例的描述组成。一个用例是在一个系统中的一组可能的交互，它的参与者朝着同一个被定义的目标进行。

　　谈到为我们的系统和外部元素(如其它系统)之间的交互建模，通常的做法是，创建一些类，它们表示这些元素和我们的系统之间的交互方式。把外部实体表示为类，这样一种设计模式称为 镜像映象(Mirror Image)模式。

子整体软件开发是灵活运动的逻辑扩展。它需要高度理解用于编制软件的技术，还需要开发者对交付使用系统负责。子整体软件开发小组把过程用作指南，而不是支柱。

本文主要介绍了java设计模式中Flyweight模式的应用和实现。

面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。

为实现所选择的需求收集过程极大的影响着软件开发项目的成功。因为需求收集是开发周期的基础，一个无效或选择欠妥的需求分析过程极大的增加了项目失败的可能性。这种可能性导致我们死守着已知的过程，通常与一个单独的、受偏爱的软件开发方法有关。

UML 没有排斥任何特殊的软件开发方法或过程;它只不过标准化了标记法的格式。然而，许多开发方法都合并了 UML。

针对用户对图书资源进行有效利用和管理的功能需求，用建模技术对图书管理资源采用面向对象的描述方式，在具体系统功能实现之前，建立起系统模型是很必要的，这里采用具有可视化、能够柔性实现分析、设计和开发系统的统一建模语言实现系统模型构建。同时，结合最流行的基于浏览器的数据管理模式，建议采用基于组件技术的B/S(brower/server)系统结构。