作用帮助我们对软件系统进行面向对象的和建模.ppt

一个用例就是一个服务过程,用例的外部是申请服务的人,也就是主角(Actor),用例的内部是提供服务的人,也就是角色(Work). 就象你站在食堂的窗口外打饭,你在窗口外,是主角,打饭的师傅在窗口内,是角色.打饭就是一个用例.  1.是用例所包含的主角交互过程? 2.是用例所包含的角色的工作过程? 打饭就是一个用例,站在打饭的窗口外看到的打饭过程就是这个用例的外部,站在打饭的窗口里面看到的打饭过程就是这个用例的内部.  所以,当你用到“用例内部”一词的时候要非常小心.你所指的到底是关于用例的主角交互过程的详细描述内容,还是用例内部对象协作过程的描述?一定要严格区分. 对于用例模型,只需要描述外部景象,对于用例的内部景象,则需要用对象模型来描述.所谓用例实现就是用例的内部景象. 2. sequence diagram 按时间先后顺序，从上到下分析使用案例，确定案例的处理流程。 3 Collaboration diagram ： 确定对象之间的关系的处理过程的分析流程。 任务：通过分析Use-Case Diagrams ，得到所用到的类，分析这些类的属性、操作和它们之间的关系。 所用到的框图： 1.Class Diagrams. 显示系统中类与类之间的交互。 2.包：具有一些共性的类组合在一起的图。 任务：细化和个性Use-Case 的描述，如类的操作和对象之间的消息相对应，填充参数及复杂的类的 设计。 所用到的框图： 1.Class Diagrams 2.State Diagrams:显示一个对象从生成到删除的生命周期。 任务：进行软件的开发和测试，生成组件框图。 组件：表示代码的物理模块。 组件框图：表示系统中的组件及相互依赖性。 Delpoyment Diagrams:显示网络中的物理布局和各种组件的位置。 要开发一个软件系统,首先要对软件系统的需求进行分析,要做的工作是深入描述目标系统的功能和性能,确定软件设计的限制和软件同其他系统元素间的接口细节,定义软件的其他有效性需求. UML的用例图较详细和确切地描述了用户的功能需求，使系统责任明确到位，奠定UML对系统建模的基础，这样，其他模型图的构造和发展依赖于用例图中所描述的内容，直至系统能够实现用例图中描述的功能。采用用例图描述的图书管理主要包括三类用户：读者、图书管理员、系统管理员。其中，读者是多个，图书管理员是几个，系统管理员是一个。对于系统，读者可以查询自己的借阅情况、分门别类的查询图书和在规定期限内续借不能超过一次操作的情况下进行自行登录续借书等。 在用例分析基础上，根据需求可建立起系统的静态数据模型，即建立系统类图，以及相关的关系和方法。在面向对象分析中，一般只考虑与问题描述域和系统功能相关的对象。在对系统进行分析时，这里把系统的类对象抽象为图书管理、图书流通两方面。 在状态图中，把每时刻的系统状态抽象成状态和事件，然后组成一个网络，侧重于描述每一类对象的动态行为。它是对某一时刻中属性特征的概括，并且每种状态间存在着迁移，迁移则表示了这类对象在何时对系统内外发生的哪些事件作出何种响应。状态图设计一般是在对操作序列的顺序图细化的基础上表达。这里以借书的状态图为例，把上面的面向对象分析与设计、并对系统静态结构的把握后，建立起系统动态数据的逻辑视图. * Rational Rose实验 定义：一种面向对象的统一建模语言。 作用：帮助我们对软件系统进行面向对象的和建模。 核心：类，类之间的关系。 建模：通过将用户的业务需求映射为代码，保证代码满足这些需求，代码能方便地回溯需求，这个过程叫建模。 UML 通过建立各种类、类之间的关联、类/对象怎样相互配合实现系统的动态行为等成分（这些都称为模型元素）来组建整个模型，刻画客观世界。UML 提供了各种图形，比如Use Case 图、类图、顺序图、协作图、状态图等，来把这些模型元素及其关系可视化，让人们可以清楚容易的理解模型。我们可以从多个视角来考察模型，从而更加全面的了解模型，这样同一个模型元素可能会出现在多个图中，对应多个图形元素。 UML由视图view，图diagram，模型元素model element 和通用机制general mechanism 等几个部分组成. 视图是表达系统的某一方面特征的UML 建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示.图是模型元素集的图形表示，通常为弧（关系）和顶点（其他模型元素）相互连接构成的。 模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念.通用机制用于表示其它信息，比如注释、模型元素的语义等。 用例视图(use case view)，强调从用户的角度看到