OA系统项目开发.docx
《OA系统项目开发.docx》由会员分享,可在线阅读,更多相关《OA系统项目开发.docx(14页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、OA系统项目开发OA 系统项目开发UML 小结以及基于领域模型的系统设计初步 UML 不是 OOA/D 也不是方法,它仅仅是一种图形表示法。其目的的确是让人能看明白你的东西。每一种图,都相当于一种角度。不同的图的确是从不同角度来观看系统。比如交通图和行政区划图,从不同角度观看中国。 必要性是画图的原那么,尽管有这种关系,但不肯定要画出来,假如非要画出来,那么应考虑不要阻碍图形的美观。活动图 活动图表示的是一种流程。例子:依次图 依次图的目的是为对象安排职责,而不是步骤的排列。上图中,ActionServlet 是没有必要画出来的,它是一个特地稳固,也不是我们自己供应的,没有必要来说明它的对象职
2、责。插在那个地点明显余外.如以下图如此就能够了:用例和用例图 用例的定义:文本形式的情节描述。 用例用于需求的发觉和记录,它会阻碍后续的 OOA/D 工作 用例不是用例图。用例图不重要,用例描述特地重要。 用例尽量不要用名词命名,尽量以动词开头,比如:治理商品。用例一样是用于功能性的需求而非性能性需求。编写用例时,在差不多路径即主胜利路径中,只书写要紧的胜利事务,而可能显现的其他情形如找不到用户应当写在扩展点中。用例粒度:比如:是把治理用户当做用例照旧把添加用户和删除用户分别当做两个用例。确定用例的粒度时,应当考虑描述那个用例的差不多路径须要几个步骤。十步以内,七八步比较合适。一个典型的用例描
3、述一个典型用例图 其中销售经理和收银员之关系是泛化关系,即经理拥有收银员所拥有的一切用例。另外还有其独有的用例。 类图 类图承诺我们标记静态内容及类之间的关系,它是 UML 中最重要的图形,能够在任何时候尝试运用类图。不要运用类图描述全部的细微环节,保持类图的简洁。UML 中要紧有三种类:边界类、操纵类和实体类 边界类位于系统与外界的交界处,例如窗体、报表、以及表示通讯协议的类、直截了当与外部设备交互的类、直截了当与外部系统交互的类等。通过用例图能够确定须要的边界类,每个 Actor/Use Case 对至少要一个边界类,但并非每个 Actor/Use Case 对要唯独的边界类。实体类能够通
4、过事务流和交互图发觉。通常每个实体类在数据库中有相应的表,实体类中的属性对应数据库表中的字段。操纵类是操纵其他类工作的类。操纵类能够被多个用例共用。其他类并不向操纵类发送特地多消息,而是由操纵类发出特地多消息。类图中,要画出类之间的关系 UML 中继承、实现、依靠、关联、聚合、组合的联系与区分 继承 ( 也叫泛化) 指的是一个类称为子类、子接口继承另外的一个类称为父类、父接口的功能,并能够增加它自己的新功能的实力,继承是类与类或者接口与接口之间最常见的关系;在 Java 中此类关系通过关键字extends 明确标识,在设计时一样没有争议性;实现 指的是一个 class 类实现 interfac
5、e 接口能够是多个的功能;实现是类与接口之间最常见的关系;在 Java 中此类关系通过关键字 implements 明确标识,在设计时一样没有争议性; 依靠 能够简洁的明白得,的确是一个类 A 运用到了另一个类 B,而这种运用关系是具有偶然性的、临时性的、特地弱的,然而 B 类的改变会阻碍到 A;比如某人要过河,须要借用一条船,现在人与船之间的关系的确是依靠;表现在代码层面,为类 B 作为参数被类 A 在某个method 方法中运用;关联 他表达的是两个类、或者类与接口之间语义级别的一种强依靠关系,比如我和我的挚友;这种关系比依靠更强、不存在依靠关系的偶然性、关系也不是临时性的,一样是长期性的
6、,而且双方的关系一样是同等的、关联能够是单向、双向的;表现在代码层面,为被关联类 B 以类属性的形式显现在关联类 A 中,也可能是关联类 A 引用了一个类型为被关联类 B 的全局变量; 聚合 聚合是关联关系的一种特例,他表达的是整体与部分、拥有的关系,即 has-a 的关系,现在整体与部分之间是可分别的,他们能够具有各自的生命周期,部分能够属于多个整体对象,也能够为多个整体对象共享;比如运算机与 CPU、公司与职员的关系等;表现在代码层面,和关联关系是一样的,只能从语义级别来 区分;组合 组合也是关联关系的一种特例,他表达的是一种 contains-a 的关系,这种关系比聚合更强,也称为强聚合
7、;他同样表达整体与部分间的关系,但现在整体与部分是不行分的,整体的生命周期终止也就意味着部分的生命周期终止;比如你和你的大脑;表现在代码层面,和关联关系是一样的,只能从语义级别来区 分;总结:继承、实现表达的是类与类、或者类与接口间的纵向关系,不易混淆;其他的四者关系那么表达的是类与类、或者类与接口间的引用、横向关系,这几种关系差不多上语义级别的,因此从代码层面并不能完全区分开来; 例如在关怀汽车的领域里,轮胎是肯定要组合在汽车类中的,因为它离开了汽车就没有意义了。然而在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就能够用聚合了。总的来说,后几种关系所表现的强弱程度依次为:组合g
8、t;聚合gt;关联gt;依靠 例如一 关联之特地例如,以下图表示一种树形结构类图,能够用如下代码实现 Public Class Node PublicID; Private Nodeparent; Private Setlt;Nodegt;children; 例如二:差不多在关联中说明白 Document 具有一个 User 类型的字段 Creator,故不必在 Document 中再写出 Creator 了。例如三:由于 User 是另一个困难的概念,因此要建立关联,而不是把 User 也作为一个简洁的属性如 name 那样 不要把困难的领域概念建模为属性。 例如四: Student 与 c
9、lass 之间是双向关联关系,因此也能够说成是 student 依靠 class,因为没有 class,student 是不能编译通过的。但画图并不是全部存在的东西都要画出来,那个地点表示成关联关系更为贴切些。另外,关联指的是关怀对方的结构,假如对象 A 只是用一用对象 B的某个方法,比如 Collections.sort(), 这明显是依靠而非关联。基于领域模型的系统设计初步 设计时重要原那么: 低耦合,高内聚. 尽量降低对不稳固对象的依靠。关于特地稳固的东西,比如 JDK 的核心类库,尽能够随意依靠它。 不要依靠于正向工程和逆向工程,假如你要让其从图形生成代码,那么你不得不在图形中留意各种
10、细微环节,那不如你自己写代码。 图形是为了抽象出逻辑主干,便利人明白得,它不能替代具体完整的文字描述。系统的核心价值 领域模型的价值不在于它的设计美丽(它只是一些对象最重要的也的确是对象之间的关系)而在于它表达了系统的核心价值。什么是系统的核心价值呢?我想我们的图书馆系统和华尔街的一个商业系统本质的区分不在于系统用了什么语言、用了什么数据库、用的是 OO照旧过程,而在于系统能为运用者供应什么服务,以及供应的质量。这些通过系统的运行方式系统的运行过程系统的业务逻辑来表达。用例的价值 系统分析员在接手一个系统后第一要做到的状况的确是得出系统的服务和服务场景。也的确是我们常常所讲的用例(use ca
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OA 系统 项目 开发
限制150内