《面对对象分析ooa》由会员分享，可在线阅读，更多相关《面对对象分析ooa（39页珍藏版）》请在金锄头文库上搜索。
1、面向对象分析 (Object Oriented Analysis),需要分析设计的原因(1),软件太复杂!,我实在难以理解客户的需求是什么,你有没有理解我的需求阿，做的什么东西,程序员A,客户,亲爱的，我实在无法实现这个功能，能帮我吗？,程序员B,这个系统太复杂，还是需要分析设计的呀,项目经理,需要分析设计的原因(2),交流!,客户,需求人员,架构师,程序员,客户 原始需求,需求分析,设计,面向对象分析（OOA),面向对象分析包括需求分析和需求模型化两个部分。它的主要作用是明确用户的需求，并用标准化的面向对象模型来规范地表达这一需求，最后形成面向对象的分析模型。它是系统设计的依据。,面向对象分
2、析（OOA),面向对象分析（OOA)的目标：运用面向对象方法,对问题域和系统责任进行分析和理解,找出描述问题域及系统责任所需的对象,并定义对象的属性、操作以及它们之间的关系,目标是建立一个符合问题域、满足用户功能需求的OOA模型。,OOA与OOD的职责划分:,OOA针对现实世界中的问题域和系统责任,用面向对象的方法建立起针对问题域和系统责任的模型,作为分析的结果。OOA模型不考虑与系统的具体实现有关的因素(例如,采用什么编程语言、图形、用户界面和数据库等),从而使OOA模型独立于具体的实现环境。 OOD则是针对系统的具体的实现,运用OO方法进行系统设计。其中包括两方面的工作,一是根据实现条件对
3、OOA模型做某些必要的修改和调整,使其作为OOD模型的一个部分;二是针对具体实现条件,建立人机界面、数据存储和控制驱动等模型。这些部分与OOA采用相同的概念与表示法。,OOA模型在软件开发中的地位,过程，OOA & UML,每个项目都有不同的软件过程. OOA 是过程的一部分 UML 是OOA使用的工具,计划,实现,发布,OOA,UML,需求分析要做什么？(1),什么是需求 需求是指系统必须符合的条件或具备的功能 功能性：系统无需考虑物理约束而必须能够执行的动作 非功能性 可用性 可靠性 性能 可支持性 设计约束 实施需求 接口需求 物理需求,需求分析要做什么？(2),需求分析包括对当前商业系
4、统的详尽分析，分析其工作现状和需修改之处。另外，它还包括对系统不同操作及其与系统内外的联系的详尽分析。整个阶段需要系统分析人员和用户密切合作。如此产生的每一个需求都是新系统的特点。 需求分析最后产生的详细文档称为需求说明书。,需求分析要做什么？(3),与客户和其他涉众在系统的工作内容方面达成并保持一致。 定义系统的用户界面，重点是用户的需要和目标 使系统开发人员能够更清楚地了解系统需求。 定义系统边界（限定） 为计划迭代的技术内容提供基础。 为估算开发系统所需成本和时间提供基础。,怎么做需求分析,需求分析重要的步骤 发现USECASE 使用者 用例图 用例描述 流程 约束 功能清单,需求-角色
5、（1）,主角实例是指在系统外部与系统进行交互的人或物。 主角类定义一个主角实例集，其中的各个主角实例在系统中都担任同一角色。 与系统交互的用户 与系统交互的外部系统 与系统交互的外部硬件,需求-角色（2）,名称 应明确表示主角的角色，确保在以后不会对主角的名称产生混淆。 简要说明 所代表的对象,为何需要,在系统中能获得哪些利益 特征 职责、数量、环境、使用系统的频率、领域知识水平、计算机水平、使用的其它应用程序,需求-用例图,从每个Actor出发，考虑： 主角希望系统执行的主要任务是什么？ 主角是否将在系统中创建、存储、更改、删除或读取数据？ 主角是否需要将突发变更或外部变更通知给系统？ 是否
6、需要将系统中发生的某些特定事件通知给此主角？ 此主角是否将执行系统启动或关闭操作？,需求-用例,用例实例是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。 一个用例图定义一组用例实例,需求-用例基本描述,用例基本描述： 编号，需求ID，名称，行为者，优先级别和描述,需求-用例描述（1）,说明用例如何开始和结束。 说明在主角和用例之间交换的是什么数据。 说明流程，而不只是功能，每个动作都应从“当主角. 时”开始。 只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息”。 详细说明事件流，即回答所有包含“什么”的问题。 说明系
7、统要做什么，而不是系统怎样做。,需求-用例描述（2）,使用结构化的叙述格式 每个use case只描述没有大的分支的行为的单个线索。 在事件流里要对事件流进行结构化说明 基本事件流 描述每个情节的行为者:目标语句对应的顺序 假设之前的每一步都是成功的 备选事件流 将失败情节作为延伸部分 对于失败中的失败，用更长的前缀标记更深一层的失败情节,需求-用例流程-时序图,客户用例流程图 Sequence Diagram OO 根据客户用例描述 确定流程中实例对象。从用例描述中分离出名词，对其中的名词进行判断是否可以作为实例对象。一般情况，在需求分析阶段把系统，子系统，外在系统，外在存储实体作为实例对象
8、，采取黑盒子分析方法 确定对象之间的消息。从用例描述分离出动词，对其中的动词作出判断是否为对象之间的消息。一般情况下所有的动词都是作为消息处理的 确定时序。从用例描述中分离出连词，如：然后，接着，最后等。特别注意中间的“如果，否则等”条件连接的词，确定不同的消息分支,需求-用例描述和流程,描述：员工登录到系统中的日工作内容录入界面，填入相应数据， 系统判断录入数据的正确性，如果录入数据错误， 给出相应提示信息，需要员工重新录入，否则保存员工录入数据到数据库。,CASE：员工日工作内容录入,需求-用例（其他）,用例 前置条件 是对用例何时开始的约束，而不是使用例开始的事件 后置条件 用例应该实现
9、什么 扩展点 一个名称和一系列对事件流中一个或多个位置的引用 功能清单,需求-用例关系,泛化 扩展 包含 修车的案例,需求-用例关系图(1),将特定用例抽象为更一般的用例，子用例继承父用例的属性、操作以及行为顺序，可以增加自己的属性和操作 子用例与父用例有相同的业务目的,需求-用例关系图(2),一种依赖关系，客户用例依赖于基用例 客户用例向基用例（扩展点）插入额外的动作序列来增加增量行为,需求-用例关系图(3),在客户用例的控制下，对提供者用例在客户用例的交互顺序中的行为顺序的包含,需求-用例包,用例包是用例、主角、关系、图和其他包的集合；通过将其划分为若干个较小部分来建立用例模型,需求-概念
10、模型（1）,概念模型定义 问题域中的概念的表示 概念模型可以用一组不带操作的静态结构图描述 不是软件实体（类） 概念，概念属性以及概念关系 目的在于澄清领域内的术语和词汇,需求-概念模型（2）,识别概念模型的两种方法:概念列表和名词描述,1.This use case begins when a customer arrives at a post checkout with items to purchase 2.The cashier records the universal product code from the item 3.Determine the item price an
11、d adds the item information to the running sales transaction,需求-概念模型（3）,怎样做系统的概念模型 列出所有候选的概念（上面提到的两种方法） 把它们画在概念模型上面(使用Class Diagram) 在概念上添加必须的关联 加上必须的属性来表达需求信息 象一个地图制作者一样遵循下面的规则： 使用领域中已经有的名字 排除不相关的属性 不要添加不在地图上的东西,需求-概念模型(4),哪个更好？,需求-概念模型(5),怎样添加关联(association)？ 关注那些知道需要知道的关联(Need to know)上 识别概念比识别关系
12、重要 太多的关联会导致概念的复杂化 避免显示多余的或者推导出来的关联 也需要关注加强理解的关联,需求-概念模型-属性,尽量使属性简单和纯粹：使用简单的类型。不要和开发语言类型混淆 概念模型中是没有类似数据库的外键这个东西的,需求-术语表,定义所有需要澄清的术语，以提高交流和减少理解的风险 在每个阶段去精炼这些术语 记录领域或者业务上的规则，限制 说明这些术语尽量简洁,需求-其他,系统运行环境 系统外部接口 非功能性要求（性能要求）,需求-设计,What Requirements Investigation of domain,How Logical solution,分析和设计是连续的，不要强行分开 问题的关键是怎样获取低成本的软件,需求,设计,设计要做什么？,设计要做的最重要的两件事: 分配任务或者操作给特定的对象。也就是说系统需要采取什么样的框架(Framework)和这些对象怎么连接？我们需要类图和协作图（这是比较困难的） 实现每个类具体的任务。也就定义每个类的方法（这相对容易些）,设计-要做什么,针对OOA给出的问题域模型，用面向对象方法设计出软件基础架构（概要设计）和完整的类结构（详细设计），以实现业务功能。 生成对象类的动、静态模型（解决域）,Thank You ！,
