用EA进行分析设计.docVIP

用EA轻松进行分析设计 开始前的准备（进行前的设置） 设置你默认使用的数据库 创建项目 新建项目： 选择你要保存EA文件的路径，输入EA文件的文件名： 根据您项目的情况，选择需要的类型 选择模式下需要的模型（通常我是全选，在这里全选后，还可以在项目浏览器中删除，或则增添），按确定后，模型在创建。 下面是创建好的项目模型 在这里可以删除某些认为不需要的模型，或者按一下步骤增添需要的模型 选择Model点右键 选择增添的模型 UML中3个重要的东东 在进入实际工作之前，需要了解这3个UML中重要的东东，对在EA里的操作很重要（本来这是UML中的基础，本不该在这里讲，但是在使用EA时有好多人问题一些很基本的东西，所以就补上来吧） 包：是为了系统的结构划分而存在，主要是系统之间的功能分界，也可以看作是分层次，就像我们写一篇文章，需要分目录、章节一样； 视图：视图就像一块白板，用于表现存放各元素以及元素的关系，如用例图、类图，或者是存放包的包结构图。不同的视图有不同的含义，这里就不展开了，一个视图出现后，对应和此视图相关的元素会在左边出现，如： 元素：既是UML中的元素，如：用例、类、表、包等等 连接这些元素的不同的线，代表的是其之间的关系。 和客户沟通，记录需求 在这里记录下用户的原始需求，有分功能需求和非功能需求（如性能、兼容性、部署环境要求等） 分包，同时记录用户的原始需求，这里模型中有好的一个分法，把需求从特性、规则和界面要求分开了 各个层用法（其实这里的规则和特性，概念也很模糊，通常我用的时候上面的包为Requirement只是记录需求，相应的规则和特性都记录在Features当特性表的内容） 以下是非功能性内容 然后，对每个元素和需求中填写需求的描述 以上的工作只是收集原始需求的工作，是现场或和客户沟通、接触的最直接工作以及“证据”，同时也是为了下一步的分析的根据基础，接下来是体现系统分析师的水平的工作，用例以及用例分析； 建顶层用例 用例可分顶层用例、业务用例和系统用例（这是我自己的分法，没有教程这么讲过，只需自己理解就好，其实业务用例和系统用例可以当作一些书本中说的客户需求和系统需求），以上分法目的是： 首先，从和客户的沟通和接触中，你可能会收集到很多早期的用例，特别是一开始会是用户的最初要求，也是最大的期望，通常这些都是可以归类到顶层用例中，然后根据这些顶层用例和收集的需求，根据你的理解，以其行业（看你的系统是做什么行业）的术语和业务进行分解和细化形成业务用例，这是整理以及细化的过程，可以至顶向下，也可以由细整理再归类，最后形成业务用例；同时，根据你IT的经验，把业务用例进行分析（这是见你分析设计经验的时候，架构师通常的能力就表现出来了），形成可开发化的系统用例，这过程是个分析的过程，有可能一个业务用例会被你分拆成多个用例，也有可能多个业务用例合并成一个系统用例，总之，就是系统优化的那些原则，性能、可扩展性、安全性、通用型等等什么的。这些内容调研之后的首要工作，这些可以同步迭代进行。 用例图是角色和用例之间的关系，所以通常做法我会给角色单独建一个包，然后用例根据边界的分法建包： 建立相关的包 输入包名 根据你这个包所扮演的作用选择相关视图，（一个包中可存在多个视图，可用前面说的视图按钮建立） 双击刚建好的用例视图 点击左边的元素集，选择用例元素 放置到用例视图中，填写用例名和用例描述以其其他相关的属性 或者是和此用例相关的文件 把相关的角色拖到视图中 在提示框中选者简单的连接 画上角色和用例的关联 其关联还可以通过双击关联线，标注相关的构造型和链接名 进行领域模型建模 看过《领域驱动设计》的人就知道领域模型的作用是什么了，主要是面向用户，面向业务的，顾名思义就是理解领域中的各层关系，其实画法和类模型相似，这里就不细说了，并不是必须的，看项目具体情况而定。 建类图 案例中做了个好的分法，把系统类和架构类分开了，大家可以照搬，当然也可以根据自己需要自己建包。 做法也是和之上画用例图的步骤一样的（重要的是分析设计的思想）：建包—建视图---画元素（用例、类、表等）--画关系（关联、继承、依赖等） 一个类它可以有属性和方法 建类的属性 输入属性（变量）的内容 建类的方法 输入方法的内容 建数据模型 手动建数据模型的方法和以上内容基本相似 建字段和方法的方法和类图一样（不过通常通过类转换过来的话，这些内容都有了，只是对其进行一些修正即可） 通过包转换建立类模型、数据模型 领域模型、类模型、数据模型这几者之间是可以通过包转换来进行的，也就是如果你原来建好的领域模型，