摘要：分析类共有三个：边界类（boundary）、控制类（control）和实体类（entity），这些分析类都是类的版型。分析类是跨越需求到设计实现的桥梁。边界类：从需求向现实的转换过程中，任何两个有交互的关键对象之间都应该考虑建立边界类。对现实世界来说，边界类的实例可以是窗口、通信协议、打印机接口、传感器、终端等。 在计算机世界里，当我们打算对A对象和B对象之间的交互进行建模时，边界类可以充当这一载体。控制类：用于对一个或几个用例所特有的控制行为进行建模。控制对象通常控制其他对象，因此他们的行为具有协调性质。控制类将用例的特有行为进行封装。实体类：用于对必须存储的信息和相关行为建模的类。实体对象 阅读全文

摘要：包是一种容器，如同文件夹一样，将某些信息分类，形成逻辑单元。包可以容纳任何UML元素，例如用例、业务实体、类图等，也包括子包。一、分包原则：（1）高内聚：被分入同一个包的元素相互联系紧密，伸至不可分割。同时这些元素具有某些相同的性质，使得包可以抽象出一些接口来代表包事物与包外进行交互。（2）低耦合：包的最理想状态是修改A、B、C任意一个包的元素，其他的任何一个包中的内容不受影响，即ABC之间无依赖关系或松耦合。（3）依赖关系不传递：如果实际情况难以做到完全解除依赖关系，那么至少应该保证包之间的依赖关系不会被传递。（4）单向依赖：包之间的关系应该是单向的，应该尽量避免双向依赖和循环依赖。二、基本 阅读全文

摘要：定义：边界是无形的，是可大可小的，同时参与者、用例和边界又有着相生相克的性质。与其说边界是UML元素，还不如说它是一种分析方法。1、需求是动态的过程：系统边界是无形的，看不到的，不好理解，倒不如说需求的集合来的准确。但是不能先有需求再反过来推定边界，需求总是晚于系统边界出现的。 然而，需求是靠参与者和用例确定的，但是参与者和用例得以明确的前提条件又是边界确定；需求就是在不断调整这个矛盾的过程中逐步明确进而更加确定边界的。这个过程不可避免的会导致参与者和用例的变化，所以需求是一个动态的过程，统一过程需要迭代。 因此，在收集需求时要先假定一个边界，这个边界的大小是不确定的，随着需求的明确边界也逐步 阅读全文

摘要：定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一些列操作，这些操作生成特定主角可以观测的值。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。1、理解用例：用例就是参与者希望通过系统达到的愿望。一个系统的功能性是由一些对系统有愿望的参与者要做的一些事构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。捕捉功能性需求就是用例的作用。2、特征：（1）用例是相对独立的；（2）用例的执行结果对参与者来说是可观测的和有意义的；（3）用例必须由参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用 阅读全文

摘要：定义：参与者是在系统之外与系统交互的某人或某事物。参与者在建模过程中处于核心地位。1、系统之外：系统之外的定义说明在参与者和系统之间存在明确的边界，参与者只能存在于边界之外，边界之内的所有人和事务都不是参与者。2、参与者可以非人：不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。没有人参与的需求一定有别的事务在发出启动操作，这个事务就是参与者，可能是另一个计算机系统、一个计时器、一个传感器等。3、特点：参与者对系统有着明确的目标和要求并且主动发出动作； 系统是为参与者服务的。4、边界不同，参与者会随之变化：（1）机票购买者通过登录网站购买机票：机票购买者；（2）机票购买者 阅读全文