Iron_Sky的博客

用例不是计算机术语，即用例除了用于软件行业，其他行业也在使用。而功能是计算机术语，功能实际描述的是输入-->计算-->输出。用例可以看成是为了完成一个特定目标的一系列功能的组合。用例有几个特征：    一、用例是相对独立的。    二、用例的执行结果对参与者来说是可观察和有意义的。   三、必须有一个参与者发起。    四、必须是以动宾短语形式出现的。    用例以参与

学UML就是为了建模，UML的语法和词汇已经差不多了解了。所以开始学模型了。 用例模型是需求工作的结果， 用例模型有业务用例模型，概念用例模型和系统用例模型。他们拥有软件开发的不同生命周期阶段，它们三者是在不同的抽象层次上的，它们之间是一种精化关系。 业务用例模型  业务用例模型位于统一过程的先启阶段。从业务用例模型能够获得现实需求。现实需求是得到系统需求的前提，业务用例模型我觉得用来

分析类的官方定义是：分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念简述，则可以对分析类本身进行维护。分析类还可以产生系统设计的主要抽象——系统的设计类和子系统。  分析类是跨越需求到设计的桥梁。分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析

包是一种容器，如同文件夹，将某些信息分类形成逻辑单元。使用包是为了把复杂的信息进行整合，把某些语意上相关的或者某些方面具有相同点的信息分包。  包可以容纳任何UML元素。分包的好坏是由包之间的依赖关系来评判的，好的分包具有高内聚，低耦合的性质。  分包的一些指导性原则：  1、 如果将一个元素分成三个包A,B,C，那么被分入同一个包的那些元素应当是相互紧密联系的，甚至不可分割的。同时这

工作已经三年了，之前的工作基本上就是码代码，移植操作系统，调试驱动之类的。总之，干的很多活基本上都是在前人的基础上修修补补。     自己从头开始设计一个嵌入式软件项目，就会感到无力感，不知从何下手。所以觉得有必要学习下软件技术类的知识了。说道软件技术就不得不提面向对象了。虽然我是做嵌入式的，但是感觉面向对象时很好的一种思想，相信学会面向对象的设计思想在今后的工作中能提供很大的帮助。

用例的官方定义是：用例定义了一组用例实例，其中每个用例实例都是系统所执行的一系列操作，这些操作生成特定主角可以观察的值。具体的说，用例是一件事，完成这件事需要一系列的活动，做这件事可以用不同的方法和步骤，可会遇到各种情况，因此这件事就是由很多不同的情况集合构成的，这些情况在UML称为用例场景，一个场景就是用例的实例。  一个系统的功能性是由一些对系统有愿望的主角要做的一些事构成的，当全部主角的

业务实体是类的一种版型，特别适用于业务建模阶段建立领域模型。业务实体描述了用什么来达到业务目标及通过什么记录这个业务目标。业务实体抽象出了问题领域内核心和关键的概念。  官方定义是：业务实体代表业务角色执行业务用例时所处理或使用的“事物”。  业务实体是来自现实世界，它是主角在完成其业务目标过程中使用到或创建出来的。业务实体一定是在分析业务流程（即业务用例场景）的过程中发现的，就是说业

主角又称参与者，官方定义是：在系统之外与系统交互的人或事。所以要找到参与者，首先要分清楚系统的边界，即系统之外是哪里。可以通过两个问题来找到这个边界：   1、 谁对系统有着明确的目标和要求并且主动发出动作（系统外部）？   2、系统是为谁服务的（系统内部）？   主角不一定是人，可以是发出启动一个用例动作的任何事物，如计算机系统，计时器，传感器等...   主角与涉众的关系：涉众

版型是对UML的元素基础定义的扩展，为了让元素适用于特定场合而在同一个元素基础定义上赋予特别的含义。  面向对象分析设计的完整过程是：现实世界->业务模型->概念模型->设计模型。在这些不同的建模阶段，为了区分视图之间不同的观点，同一个元素采用不同的图示表示。例如“业务用例”、“业务用例实现”就是专门应用在业务建模场合的。

用例图用来描述系统的功能，人们要用系统实现什么目标。  用例图的组成  用例图从用户角度来描述系统功能，描述系统的参与者与系统用例之间的关系。在需求分析时使用。一般情况下，用例图有四个基本部分组成：用例，参与者，系统，关系。   用例图有四种标准关系：泛化关系，关联关系，包含关系，扩展关系。  使用关系是为了从系统中提取公共行为及其辩题。  泛化关系是指从用例中