EnterpriseArchitect7 入门教程.doc

Enterprise Architect 7 入门教程
一．简介
生命周期软件设计方案——Enterprise Architect是以目标为导向的软件系统。它覆盖了系统开发的整个周期，除了开发类模型之外，还包括事务进程分析，使用案例需求，动态模型，组件和布局，系统管理，非功能需求，用户界面设计，测试和维护等。为整个团队提供高级的UML 2.0建模工具。
EA为用户提供一个高性能、直观的工作界面，联合UML 2.0最新规范，为桌面电脑工作人员、开发和应用团队打造先进的软件建模方案。该产品不仅特性丰富，而且性价比极高，可以用来配备您的整个工作团队，包括分析人员、测试人员、项目经理、品质控制和部署人员等。
丰富系统设计
Enterprise Architect是一个完全的UML分析和设计工具，它能完成从需求收集经步骤分析、模型设计到测试和维护的整个软件开发过程。它基于多用户Windows平台的图形工具可以帮助您设计健全可维护的软件。除此，它还包含特性灵活的高品质文档输出。用户指南可以在线获取。
快速、稳定、高性能
统一建模语言能够以一致方式构建强健和可跟踪的软件系统模型，而EA为该构建过程提供了一个易于使用和快速灵活的工作环境。
端到端跟踪
Enterprise Architect提供了从需求分析、软件设计一直到执行和部署整个过程的全面可跟踪性。结合内置的任务和资源分配，项目管理人员和QA团队能够及时获取他们需要的信息，以便使项目按计划进行。
在UML 2.0上构建
通过UML（统一建模语言），您可以构建严格的可追踪的软件系统模型。EA为UML构建软件模型提供了一个快速便捷的应用环境，它支持OMG定义的新UML2.0标准。
Enterprise Architect的基础构建于UML 2.0规范之上，不仅如此，使用UML Profile还可以扩展建模范围，与此同时，模型验证将确保其完整性。产品含有免费的extensions for BPMN 和 Eriksson-Penker profile，能够将业务程序、信息和工作流程联合到一个模型内。
利用EA，设计人员可以充分利用13种UML 2.0图表功能——EA支持全部13种 UML 2.0图表和相关的图表元素；
包括：
结构图表：类、对象、合成元素、包、组件、布局；
行为图表：使用案例、通信、序列、交互概述、行为、状态、时序；
扩展：分析（简单行为）、定制（需求、变动和UI设计）。
EA提供使用工具，能够跟踪依赖关系、支持大型模型，帮助您管理大型复杂的工程；含有CVS或SCC提供工具，以时间快照为基线，通过比较来跟踪模型变动，从而实现版本控制；含有类似explorer的项目视窗，为您提供直观高性能的工作界面。
    EA还含有一个所见即所得形式的模板编辑器，提供强大的文档生成和报告工具，能够生成复杂详细的报告，报告可以按照公司或客户要求的格式提供所需信息。
EA具备源代码的前向和反向工程能力，支持多种通用语言，包括C++, C#, Java, Delphi, VB.Net, Visual Basic和PHP，除此，还可以获取免费的CORBA和Python附加组件。EA提供一个内置的源代码编辑器，含语法突出功能，确保能够在一致的工作环境中快速导航和查找您的模型源代码。对于Eclipse或Visual Studio.Net工作人员，Sparx Systems还提供到这些IDE的轻量链接工具，您可以在EA中进行建模，而后直接跳转到自己偏爱的编辑器中进行源代码的进一步开发。代码生成模板还允许您对生成的源代码进行定制，使之同公司规范相符。
EA还提供对大多数软件开发语言和数据库架构的逆向工程支持，令您的应用程序可视化，从源代码、Java.jar文件甚至是.Net二进制汇编语言中获取完整框架。通过导入框架和库代码，实现对您已有投资重复利用的最大化。
EA还提供变换模板，编辑和开发均非常简单，支持先进的模型驱动结构体系（MDA）。通过内置的DDL, C#, Java, EJB 和 XSD变换，您可以从简单的“平台独立模型”开始来构建复杂的解决方案，并定位于“平台专门模型”（PSM）。一个PIM可以用来生成并同步多个PSM，使工作效率得到显著提高。
主要特性
UML设计和构建；
使用案例，逻辑，动态和物理模型；
定制进程模型的扩展或其他；
高品质的MS Word 兼容文档；
应用直观方便；
低许可费；
数据建模，前向DDL数据库工程，反向ODBC数据库工程；
多用户（Professional 和 Corporate Edition）；
前向或逆向代码工 程（Professional 和 Corporate Edition）——支持Java, C#, C++, VB.Net, Delphi, Visual Basic 和 PHP；
XML导入/导出容易；
拼写检查；
产品新增特性
RTF所见即所得模板编辑器和报告生成器——EA 增强了其企业版和专业版中RTF文档生成功能，采用一个模板驱动方式生成RTF文档，允许用户在模型的元素层面上对其文档的外观、内容等进行定制。
版本控制改进——对版本控件作了明显改进，支持对嵌套软件包的控制，这样，在导入基版本控制软件包时，就不会再覆盖嵌套软件包了。大型文件加载时间显著缩短，同时对AccuRev和Perforce的支持也得到改进。
基线支持——企业版提供新的基线函数，在当前模型中，允许用户将一个完整的软件包分支保存为一个压缩的XMI文件。通过该基线函数，用户可以对当前软件包和存储的基线软件包进行比较。
MDA风格转换——EA专业版和企业版中提供MDA风格转换功能。MDA转换通过一个模板驱动方法将PIM（平台独立模型）元素转换为PSM（平台相关模型）元素。
比较工具（Diff）——专业版和企业版提供该功能，允许用户对模型结构体系和保存的XMI进行对照比较。包括以下比较内容：基线函数创建的基线、保存在硬盘上的EA XMI文件、由EA XMI控制的版本。
导入二进制模块——EA专业版和企业版允许对Java Archive (.jar), . NET PE Files* (.exe, .dll)和Intermediate Language (.il)二进制模块进行反向工程。
构建和运行——EA Professional 和 Corporate版本支持该功能，为开发人员提供集成工具，将UML开发和建模同源代码开发和编译相集成。能够使用MDA变换从源类中生成nUnit和jUnit测试类，并将测试过程直接集成到EA IDE中，如今还可以将UML和建模集成到构建/测试/运行/部署程序中。
MOF——在MOF 1.3和1.4标准下，允许向XMI导出包。向包中分配固定类型的元模型，可以创建MOF模型。MOF模型还可以输出为MOF 1.3或1.4 XMI文件规范。
工程商讨论坛——确保整个团队始终处于最新状态。使用商讨论坛可以讨论您工程的开发和进度，同时为了讨论方便，还可以将工程内容进行分类，并制定标题。用户可以针对某个标题发出消息线程或响应消息线程。在论坛消息板中，您可以链接到图表的不同元素。在当前模型下还可以使用其他模型的商讨论坛。
Web服务——支持对W3C Web服务定义语言（WSDL）的前向和反向工程。支持对WSDL文件的建模、生成、输入操作。
XML架构（XSD）——支持对W3C XML架构（WSDL）的前向和反向工程。支持对XML架构的建模、生成、输入操作。
The Corporate Edition定位于大规模开发组。它支持Desktop和 Professional版本的所有功能，如连接到SQL服务器、MySQL, Oracle9i, PostgreSQL, MSDE，Adaptive Server Anywhere 和 MS Access backends以实现知识库共享。它还支持用户安全、用户注册、用户组、复制和元素的用户级同步。该版本还包含对MDG技术的支持，而且用户还也可以获得更多的资源。
The Professional Edition定位于工作组和开发人员。它支持通过复制和网络文件实现项目共享。专业版还含有ActiveX接口，可以查询EA项目、以XMI格式提取信息。它完全支持代码导入/导出，模型元素和源代码的同步以及对SQL Server, MySQL, Oracle9i的逆向工程，而且包含对MDG技术的支持。
The Desktop Edition是为个体用户准备的，可以生成UML分析和设计模型。除代码工程（源代码和DLL导入/导出） 、Active-X接口和多用户模型共享之外，它可以实现专业版的所有功能。
二．创建工程
依次点击“File->New Project->命名保存->在“Select model”中选择需要创建的类型（如图-1）->单击“OK”确认，得到界面如图-2所示

图-1：创建工程
Business Process
业务流程
Requirements
需求分析
Use Case
用例
Domain Model
领域模型
Class
类设计
Database
数据库设计
Component
组件
Deployment
部署
Testing
测试
Maintenance
维护
Project Management
项目管理
User Interface
用户接口
表-1：创建项目的常见类型

图-2：创建项目后界面截图
三．一些基本的通用设置
3.1 设置默认代码环境
依次点击：“Tool->Options-Source Code Engineering->Default Language For Code Generation->C#”如图3所示，完成：单击“Close”确认退出。
图-3：设置默认代码环境
3.2 设置默认数据库
依次点击：“Tool->Options- Code Editors->Default Database->SQL Server 2005”如图4所示：
图-4:设置默认数据库
四．Class模型
4.1.创建“Class”模型
依次点击“File->New Project->命名保存->在“Select model”中勾选“Class”,最后单击“确定”进入设计界面。在设计界面的左边是工具箱（如图5）

图-5:类模型工具栏
Class Elements
Common
Package
包
Note
注释
Class
类
Constraint
约束条件
Interface
接口
Document
文档：附加文档附件
Enumeration
枚举
Artifact
人工：表示任意的系统任意的信息块
Table
表
Requirement
需求描述
Signal
对象通信信号的描述
Issue
问题描述
Association
关联
Change
变化描述
Class Relationships
Boundary
分界线
Associate
关联
Dependency
依赖关系
Generalize
泛化
Realize
实现
Compose
组成
Trace
追踪
Associate Class
关联类
Information Flow
数据流
Assembly
程序集
Note Link
注释链接
Realize
实现

Nesting
嵌套

Package Merge
包的合并

Package Import
包的导入

4.2.为模型中创建的“Class”对象使用别名
首先在工具箱中点选 ，然后在合适的位置左键单击确定，之后弹出属性窗口（如图7所示）

图-7：新建类截图
在“Name”栏中输入Class 的名称“Test”，然后在“Alias”中输入一个别名“测试”。其他相应设置好之后，确定退出属性窗口。我们发现，在默认情况下“Class”所显示的名称是Test，但如果我们需要显示别名的时候，我们需要进行以下设置；在类Test所在的包中找到class diagram，点击右键然后选择“Propreties…”进入如图8所示的窗口；

选择“Diagram”，进入如图9所示的窗口；勾选“Use Alias if Available”，别名的显示即设置完成。

五．代码的生成
5.1. 把整个包的设计类生成C＃格式代码
依次单击“Project->Source Code Engineering->Generate Package Source Code…（如图10所示）”

进入如图11所示界面：

点击“Generate”，将包中所有的类成批转换为C＃文件。
5.2.单个自动生成C＃代码
右键单击需要转换为C＃文件的“Class”，在菜单中选择“Generate Code…”或者使用快捷键“F11”，弹出如图12所示菜单：

单击图中1的位置，选择将要生成文件的存储路径，然后在2的位置选择要生成什么语言的文件（在此我们点击下拉菜单选择C＃），最后点击3位置的“Generate”生成。
六．设计模型与生成的代码同步
当生成了C＃代码之后，接下来我们就将设计模型和生成的代码同步，步骤如下：鼠标右键单击需要进行代码同步的对象，选择“Synchronize Model With Code…”或者使用快捷键“F7”，弹出如图13所示的对话框：

七．数据库模型，需求模型，组件，部署
7.1. 建立数据表；
依次点击“File->New Project…->输入一个名称后保存->在右边选中Database（如图-14所示）”

最后点击“OK”确认进入设计界面， “工程窗口”如图15所示：

工具栏及工具栏中的工具如图6及表2所示.
7.2.建立数据表
在“工具箱”中单击 ，然后将鼠标移入工作区域，此时鼠标变成 状，单击鼠标，出现如图16所示的窗口.

在进行一些表基本的设置（如表的命名“Name”等等）后，单击“Table Detail”进入表字段的设计（图17），

单击图14中红圈标识的“Columns/Attributes”进入表字段的设置。如图18所示。

设置表字段名称“Name”，数据类型“Data Type”，及主键“Primary Key”，是否为空“Not Null”，等等，单击“Save”保存，然后单击“New”新建一个，就这样逐个设置表的字段。   
八．文档的生成
8.1.Text文档的生成
依次单击“Project->Documentation->Rich Text Format(RTF) Report…（如图19）”或直接使用快捷键“F8”

在“Output to file”后面单击，选择Text文档的生成路径，而后即可。
8.2.Html文档的生成
依次单击“Project->Documentation->HTML Report…（如图16）”或直接使用快捷键“Shift+F8”，弹出图20所示窗口；

相关设置后，点击“Generate”生成即可。
九．将包导入成XML形式
依次单击“Project->XML Schema->Import XML Schema”如图21所示

在“Filename”后面单击确定生成的XML文档的名称及路径，然后单击“Import”即可
十．画图的线的弯曲，自动布局，改变线的连接点的方法
首先在“活动图”中对“实线”点击右键（必须是实线，虚线不起作用），然后点击“Set Line Style”，而后“Bezier”，拖动中间的点调整线的弯曲。
Auto Routing(自动布局的方式)    Direct（改变线的连接点）
十一．活动图及时序图的绘制
11.1.活动图的绘制
在已建立的“Package”上右键单击->New…->New Diagram…->在弹出的窗口左边选择“UML Behavioral”(如图22所示)

在“New Diagram”的右边“Diagram Types”窗口中选择“Activity”，最后单击OK保存退出。
此时，我们发现“Project Browser”窗口中增加了一个如图23所示的对象“Class Medel”。

在左边的“Toolbox”中我们看到相关的工具。（如图24及表3所示）

Activity
Activity Relation
Activity
活动状态
Control Flow
控制流
Structured Activity
嵌套活动
Object Flow
对象流
Action
动作
Interrupt Flow
中断流
Partition
分区
Common
Object
对象
Note
注释
Central Buffer Node
中央缓冲节点
Constraint
约束条件
Datastore
数据存储
Document
文档：附加文档附件
Decision
判断
Artifact
人工：表示任意的系统任意的信息块
Merge
合并
Requirement
需求描述
Send
发送
Issue
问题描述
Initial
最初的
Change
变化描述
Final
最终的
Boundary
分界线
Flow Final
流结束
Dependency
依赖关系
Region
区域
Realize
实现
Exception
异常
Trace
追踪
Fork/Join
并发
Information Flow
数据流

Note Link
注释链接
11.2.时序图的绘制
在已建立的“Package”上右键单击->New…->New Diagram…->在弹出的窗口左边选择“UML Behavioral”(如图25所示)

在“New Diagram”的右边“Diagram Types”窗口中选择“Sequence”，最后单击OK保存退出。此时，我们发现“Project Browser”窗口中增加了一个如图26所示的对象“Class Medel”。

在左边的“Toolbox”中我们看到相关的工具。（如图27及表4所示）

Interaction Elements
Common
Actor
角色
Note
注释
Lifeline
生命线
Constraint
约束条件
Boundary
 分界线
Document
文档：附加文档附件
Control
控制
Artifact
人工：表示任意的系统任意的信息块
Entity
实体
Requirement
需求描述
Fragment
片段
Issue
问题描述
Endpoint
端点
Change
变化描述
Diagram Gate

Boundary
分界线
State/Continuation
延时状态
Dependency
依赖关系
Interaction Relationships
Realize
实现
Message
消息
Trace
追踪
Self-Message
安全消息
Information Flow
数据流
Call
呼叫
Note Link
注释链接
Recursion
递归

11.3.如何添加注释
在Toolbox中点击 图标，然后在Workspace中左键单击你所需要添加注释的方位。弹出如图-28所示的窗口；

在空白区域填入注释内容，然后左键单击“OK”返回。
11.4.设置图中的字体样式
当我们在图中建立好元素后，使用下列方式对元素进行样式改变。图-30是在11.2的时序图的基础上增加了几个元素。

下面我们就来改变注释中的字体样式。
鼠标选中注释对象，下图是选中注释对象的前后对比；

图-31

11.5.将一个图的元素重新复制一份新的到其它图
首先新建一个图，然后在Project Browser中使用鼠标左键点中需要复制的元素不放指导拖到新建的图中即可。
十二、UML 用例图
用例图包含六个元素，分别是：执行者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
1、 执行者（Actor）
a) 执行者概念
是指用户在系统中扮演的角色。如图1-1是一个用户管理的用例图，图中的用户、管理员就是用例的执行者。

图1-1
b) 从业务中找出执行者
获取系统用例首先要找出系统的执行者。我们可以通过用户回答一些问题的答案来识别执行者。可以参考以下问题：
l 谁使用系统的主要功能（主要使用者）？
l 谁需要系统支持他们日常工作？
l 谁来维护、管理系统使其正常工作（辅助使用者）？
l 系统需要控制哪些硬件？
l 系统需要其他哪些系统交互？这里包含其他计算机系统或者应用程序。
l 对系统产生结果感兴趣的是哪些人和哪些事物？
c) 执行者之间关系
因为执行者是类，所以多个执行者之间可以具有与类相同的关系。在用例图中，使用了泛化关系来描述多个执行者之间的公共行为。如果系统中存在几个执行者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在执行者超类中描述的场合。特殊化的执行者继承了该超类的行为，然后在某些方面扩展了此行为。执行者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。图1-2

图1-2
2、 用例（Use Case）
a) 用例概念
    用例就是外部可见的系统功能，对系统提供的服务进行描述。
b) 从业务中找出用例
找出系统的用例，我们从执行者入手，对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例。可以参考以下问题：
l 执行者要求系统提供哪些功能（执行者需要做什么）？
l 执行者需要读、产生、修改、删除或者存储系统中的信息有哪些类型？
l 执行者必须提醒系统事件有哪些？把这些事件表示成系统用例。
3、 用例之间关系
a)  关联关系（Association）
关联关系是连接执行者和用例，表示该执行者代表的外部系统实体与该用例描述的系统需求有关。

图1-3
b) 包含(include)
包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　
例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

c) 扩展(extend)
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。 
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

d) 泛化(generalization)
泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
*****************************************************************
(1) 系统整体用例图

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!
转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
●泛化侧重表示子用例间的互斥性；
●包含侧重表示被包含用例对Actor提供服务的间接性；
●扩展侧重表示扩展用例的触发不定性；详述如下：
既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
⒈ 条件发生：肯定发生的；
⒉ 有条件发生：未必发生，发生与否取决于系统状态；
因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。
另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。