面向对象分析与设计1

《面向对象分析与设计1》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1面向对象技术的原则基本原则：抽象：抽象的过程就是揭示事物区别于其他事物的本质特征的过程,这个过程取决于使用者的目的，而忽略掉其他不相关的部分。封装：指对象对其客户隐藏具体的实现，它是软件模块化思想的体现。通过封装实现信息隐藏和数据抽象。泛化：是类与类之间一种非常重要的关系，通过这种关系一个类可以共享另外一个或多个类的结构和行为。为了实现泛化，采用继承机制。一个类可以继承一个或多个父类，从而实现了不同的抽象层次这些层次之间建立的isa或isakindof关系，即为泛化关系。多态：是在同一外表（接口）下表现出多种行为的能力，它是对象技术的根本特征，是将对象技术称为面向对象技术的原因所在。2、面向对象的设计原则:<1>Liskov替换原则(LSP)：子类不能添加任何父类没有的附加约束，子类对象必须可以替换基类对象。违背后解决的方法：在可能的情况下，由抽象类（接口）继承。抽象类与具体类:只要有可能，不要从具体类继承；行为集中的方向是向上的（抽象类）；数据集中的方向是向下的（具体类）。<2>OCP开放-封闭原则：软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的。关键：抽象由抽象可以随时导出新的类（开）;抽像预见了所有可能的扩展（闭）。基本思路：开放和封闭这两个互相矛盾的术语分别用于实现不同的目标如下：软件模块对于扩展是开放的：模块的行为可以扩展，当应用的需求改变时，可以对模块进行扩展，一满足新的需求；软件模块对于修改时封闭的：对模块进行扩展时，不必改变模块的源代码或二进制代码<3>单一职责原则(SRP)：就一个类而言，应该仅有一个引起它变化的原因，有关类的职责分配问题，是面向对象设计中最重要的基本原则。SRP本质：SRP体现了内聚性，类的职责定义为“变化的原因”，每个职责都是变化的一个轴线；基本思路：该原则追溯到内聚问题，内聚性是一个模块的组成元素之间的相关性。模块内聚应遵循该内聚的设计原则。其中功能内聚是内聚度最高的一种内聚形式，是指模块内所有元素共同完成一个功能，模块不能再分割。单个类也应该保持高度内聚，即功能内聚。<4>接口隔离原则(ISP)：基本思路：ISP本质：用多个专门的接口比使用单一的接口好；一个类对另一个类的依赖性应当是建立在最小的接口上的；避免接口污染。 <5>依赖倒置原则(DIP)：基本思路：高层模块不应该依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。针对接口编程，不要针对实现编程；又称控制反转(IoC，InversionofControl)、依赖注入。DIP的本质：通过抽象提取业务本质，并建立一个稳定的结构描述这个本质；对于具体的业务规则的处理是在这个本质的基础上的扩展；技术、工具、意识形态等的发展可能使业务规则不断变化，但本质不变；而DIP则帮助我们轻松的适应这些变更启发式原则：“依赖于抽象”—程序中所有依赖关系都应该终止于抽象类或者接口，启发式原则：任何变量都不应该拥有指向具体类的指针或者引用，，任何类都不应该从具体类派生，任何方法都不应该改写其任何基类中已经实现的方法。核心思想：依赖于抽象rup统一过程按时间分为四个阶段：初始、细化、构造、交互阶段。九个工作流：按内容划分（1）核心过程工作流：<1>商业建模<2>需求<3>分析和设计<4>实现<5>测试<6>部署（2）核心支持工作流<1>配置和变更管理<2>项目管理<3>环境管理4+1视图也是来自rup的：“4+1”架构中的“1”是用例视图，它是建模过程的起点和依据，面向最终用户，描述系统的功能性需求。所有其他视图都是从用例视图派生而来的，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础。其他视图有：逻辑视图、进程视图、实现视图、部署视图。2、UML的概念：统一建模语言、定义良好、易于表达、功能强大，普遍适用，可视化建模语言，可以用来对软件密集型系统下，各种通信进行可视化描述和文档化，融入软件工程领域新思想、新方法、新技术。UML的作用域：不限于支撑面向对象的分析与设计，还支持从需求分析开始的软件开发的工程。UML的作用：用很多图从静态和动态方面来全面描述我们将要开发的系统。UML的图：（1）静态的：类图、对象图、包图、组合结构图、构件图、部署图、外廓图（2）动态的：用例图、活动图、顺序图、交互概览图、通信图、时间图、状态机图2应用题中考的：用例图、活动图、顺序图、类图（1）用例图定义:有参与者用例，以及他们之间的关系构成描述系统功能的图。（2）用例图的作用<1>有利于用户与软件开发人员之间的沟通<2>直观性：用例可视化的表达了系统的需求具有直观、规范等优点，克服了全文字性说明的 布局<3>用例是完全从外部来定义系统的，把用需求和设计完全区分开来，用户不关心系统内部是如何完成各种功能的。（3）用例图的组成：<1>参与者：通过系统边界与系统进行有意义交互的任何事物<2>用例：系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用<3>关系：1>用例和用户之间的关系2>关联关系用例文档和活动图<4>参与者与参与者关系：泛化。<5>用例与参与者关系：关联。<6>用例之间的关系：扩展，包含，泛化寻找用例的方法：参与者使用系统所要实现的一个目标就作为一个用例存在。5核心元素：顺序图：对象、生命线、控制焦点、消息。类图：类、接口、依赖、关联、泛化、实现。对象图：对象、链接、多重性。包图：包、依赖。类图的几种版型：边界类，控制类，实体类。6UML图用例文档格式（1）用例建模（2）用例分析（3）用例设计（4）系统实现（5）系统测试（6）结论1500-2000字架构分析定义：（1）定义系统的备选架构来描述系统的高层组织结构，以用例组织后续的分析模型。（2）确定分析机制以记录系统中的通用问题。（3）提取系统的关键抽象以揭示系统必须能够处理的核心概念。（4）创建用例实现来启动用例分析。7架构分析过程;定义系统高层组织结构和核心架构机制的过程。8对象：对象是一个实体，这个实体具有明显定义的边界和标识，并且封装了状态和行为。9类：类是一系列对象的抽象描述，它将相似的实体抽象成相同的概念，这种抽象过程强调相关特性而忽略其他特征。10通用机制：达到对象建模目的的4种策略：（1）规格说明：文本维度的模型描述。（2）修饰：描述建模元素的细节信息。（3）通用划分：建模时对事物的划分方法。（4）扩展机制：用于扩展UML建模元素，包括构造性、约束、标记值三种机制。11业务用例模型：是说明预期功能的模型；是业务建模阶段的核心模型，用于确定组织的各个角色和可交付工件。业务用例模型由业务用例和业务参与者构成，主要目的是说明客户和合作伙伴是如何展开业务的：12识别业务参与者：为了充分理解业务目的，必须了解业务与谁进行交互，即业务为谁提供服务，即业务活动的服务对象。（2）识别业务用例：是对组织内部业务流程的说明，它定义一组业务用例实例，其中每个实例都是业务执行的一个操作序列，对于特定的业务参与者来说，这些操作序列所产生的结果是可见的。（3）描述业务用例：作为业务流程的封装体，业务用例是一个抽象的表示，业务建模过程还需要详细描述业务用例的内部流程，并将它作为软件建模的 方法表示出13分析的基本原则：（1）分析模型应使用业务语言，分析模型中的类主要应该是业务领域的术语。（2）分析模型中类的细节和关系等应该业务中明确存在的，不要刻意去细化或封装这些细节。（3）分析活动是对需求模型的重新表述，是一种以理想化的方式来实现用例所描述的行为，并不考虑具体的技术实现。（4）分析侧重于系统的主要部分，关注核心的业务场景。对于那些支撑性行为，非功能需求等内容一般不做深入分析。（5）所有的分析类应该是为项目涉众产生价值的。14识别分析类：（1）边界类：处于系统的最上层，它从那些系统和外界进行交互的对象中归纳和抽象出来，代表了系统与外界参与者交互的边界。存在两类边界类：用户界面类和系统/设备接口类。（2）控制类：处于三层构架的中间层，它封装控制系统上层的边界类和下层的实体类之间的交互行为，是整个用例行为的协调器。控制类能够有效的将边界对象和实体对象分开，让系统更能够适应其边界对象内发生的变更；并且还可以将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性。（3）实体类：代表了系统的核心概念，来自于对业务中的实体对象的归纳和抽象，用于记录系统所需要维护的数据和对这些数据的处理行为。15顺序图概念：用于显示对象间的交互活动，他关注对象之间消息传送的时间顺序。顺序图交互片段：交互片段将顺序图中的若干消息和对象封装为一个片段，针对这个片段可以实施不同的操作，从而来表示这个片段是以选择、循环还是并行等各种非顺序方式执行。（1）可选片段：操作符opt，表示该片段只有在守卫条件成立时才能够执行，否则跳过片段往后执行。（2）选择片段：操作符为alt，该片段的主体用水平虚线分割成几个分区。每个分区都有一个守卫条件，表示当守卫条件为真时执行该分区，且每次只能执行一个。（3）循环片段：操作符为loop，该片段在守卫条件为“真”的情况下循环执行，一旦为“假”，则跳过该片段往后执行。（4）并行片段：操作符为par，该片段主体也被水平虚线分成几个分区，当进入该片段后，这几个分区要并发执行16活动图：是一种动态行为图，将业务流程或其他计算的结构展示为内部一步步的控制流和数据流；主要用于描述某一方法，机制和用例的内部行为。14构造用例实现：是整个用例分析最核心的工作，目标是获得实现用例行为所必需的分析类，并利用这些分析类来描述其实现逻辑。（1）完善用例文档（2）识别分析类，包括三类分析类：边界类、控制类和实体类（3）分析交互。利用识别的分析类，利用交互图来分析用例实现的交互过程。（4）完成参与类 类图。根据交互图中的消息和实体类内在的关系来绘制参与当前用例实现的类的类图.15设计模式：是在对象设计阶段，通过定义类或特定对象之间的结构和行为，从而解决某类设计问题的通用解决方案。作用：（1）可以有效地利用前人的经验来设计系统，而不用“重复劳动”。在提高质量的同时，通过复用可进一步加快开发效率。（2）作为一种“设计语言”，便于设计者之间相互交流而不产生误解。（3）是培养优秀设计师的捷径。17构架：是一个系统的组织结构，包括系统分解成的各个部分、它们的连接性、交互机制和指导系统设计的相关原则。具有合理架构的系统，将使得对系统的理解、测试、维护和扩展都很容易。18架构分析内容：（1）定义系统的备选架构来描述系统的高层组织结构结构，以用例组织后续的分析模型（2）确定分析机制以记录系统中的通用问题（3）提取系统的关键抽象以揭示系统必须能够处理的核心概念（4）创建用例实现来启动用例分析19包：一种将模型元素分组的机制，用来包含其他的ULM元素。同时，还为其内部元素提供了名字空间，外界需要通过包的名字来访问其内部的元素。包还作为一个配置管理单元，以用于管理软件的开发和发布。依赖关系：包之间的关系称为依赖关系，用带箭头的虚线表示，箭头的方向标明了依赖的方向。包设计原则：（1）职责相似：将一组职责相似，但以不同的方式实现的类归为一组有意义的包。（2）协作关系：包含了各种不同类型的类，它们之间通过相互协作实现一个意义重大的职责。（3）复用发布等价原则（4）共同复用原则（5）无环依赖原则（6）共同封闭原则（7）稳定依赖原则（8）稳定抽象原则20使用聚合和组合关系：存在整体和部分含义的关联关系，为聚合关系；具有很强的归属关系和一致的生命周期的整体和部分关系表示为组合关系。（组合关系是一种特殊的聚合关系，在整体拥有部分同时，部分不能脱离整体而存在；当整体不存在时，部分也没有存在的意义。从现实角度来说，聚合表示一种引用关联，即整体保存部分的引用，部分本身可以相互独立的存在；而组合则表示一种关联，整体直接拥有的值，并负责部分的创建和删除）21正向工程：指按照软件开发的基本过程，将抽象层次较高的模型转换成相对具体的模型的过程。将设计模型转换成实现模型就是一种典型的正向工程。22逆向工程：是正向工程的逆操作，即根据已有的源代码获得其设计模型。主要有两种使用场合：（1）在编码时，可能会存在和设计模型不一致的地方，可以通过你逆向工程更新原有的设计模型，从而需要保持设计模型的有效性。（2）针对已有的系统,在缺少或丢失了设计文档时，可以通过逆向工程重新获得系统的设计模型,理解程序和完善文档。 23软件开发阶段：可行性分析、需求分析与说明、设计、编码、测试、维护。24关系包换哪几类：依赖、关联、聚合、组合、泛化、实现25建模方法：静态建模、动态建模、架构、需求。动态建模：是一种UML建模技术，表示软件系统静态成分行为。包括交互关系图，序列关系图，通信关系图，状态关系图，活动关系图，时序关系图。26软件开发过程：（1）业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该本质是后续用例建模的基础（2）用例建模：采用UNL用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入（3）用例分析：采用UNL用例分析技术分析软件需求，建立软件系统的分析模型（4）架构设计：在系统的全局范围内，以分析模型为基础，设计系统架构（5）构件设计：根据架构设计的结果，将分析模型细化，设计系统构件的实现细节（6）代码实现:将系统构件映射到目标语言上第二章可视化建模建模的目的:模型有助于按照所需的样式可视化系统;模型能够描述系统的结构和行为;模型提供构造系统的模板;模型可以文档化设计决策建模的原则:选择合适的模型;模型具有不同的精确程度;最好的模型是与现实相联系;需要从多个视角创建不同的模型，单一的模型是不够的（统一建模语言）定义（概念）：是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化、描述、构造和文档化软件密集型系统的各种工件。第三章业务建模业务建模的目的：理解将要实施的系统的组织结构和动态特性；理解当前在目标组织中的问题，并明确改进的潜力；确保客户、最终用户和开发人员对目标组织有统一的理解；获取用于支持目标组织的系统需求UML分析设计过程：业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础，用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入，用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型，架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构，构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节，代码实现：将系统构件映射到目标语言上识别业务参与者：在业务之外，与业务进行交互的人或组织。可在客户、供应商、合作伙伴、潜在客户、政府、组织中未建模部分中寻找业务参与者。识别业务用例：业务为业务参与者提供的价值，体现企业业务本质，是有意义的目标。识别业务用例的方法：直接获得：从业务参与者的角度，从外部推导 出来；拼装：从里面往外面看，内部业务流程的目标是什么从业务模型到系统模型：业务模型描述了目前的业务现状，系统模型才是软件开发的最终工件第四章用例建模需求：客户可接受的、系统必须满足的条件或具备的能力。RUP中的“FURPS+”软件需求模型：功能性（Functionality）；使用性（Usability）；可靠性（Reliability）；性能（Performance）可支持性（Supportability）；“+”包含以下需求：设计约束，实施需求，接口需求，物理需求等。需求工程的主要活动：定义需求；分析需求；需求管理用例建模流程：获取原始需求：收集资料；现场观察；访谈；开会；原型；问卷调查；构建初始用例模型；编写用例文档；重构用例模型从业务用例模型中获取系统需求，来构建系统用例模型：1.寻找业务改进点：流程控制，复杂业务逻辑，使用业务对象，自动化业务2.定义项目远景：远景包含了为待开发系统设定的目标和约束，它代表了项目涉及的所有人之间达成的第一个共识，是项目核心需求的概览，为更详细的技术需求提供了默契性的依据，并最终指导团队实现具体的业务目标。具体的，可测量的，可实现的，相关的，基于时间的（SMART）3.导出系统需求：从业务改进点入手，结合项目远景，导出系统需求如何识别参与者：参与者定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者应该满足以下要求：系统外：参与者不是系统的一部分，处于系统的外部；系统边界：参与者透过系统边界直接与系统交互；系统角色：参与者是一个参与系统交互的角色，与使用系统的物理人和职务没有关系；与系统进行信息交互：系统需要关注其交互过程，即系统职责；任何事物：人、外系统、外部因素、时间可以从以下要点来识别参与者：系统在哪些部门使用；谁向系统提供信息、使用和删除信息；谁与系统的需求有关联；谁使用系统的功能（用例）；谁对系统进行维护；与外部系统是否有关联；时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例参与者可以通过泛化关系来定义用例粒度-1：粒度过细，陷入功能分解；用例粒度-2：把步骤当用例，把系统活动当用例；用例粒度-3：“四轮马车”；用例粒度-4：如果CRUD不涉及复杂的交互，一个用例“管理××”即可；用例粒度-5：灵活处理CRUD 用例文档的组成：用例标识(UC)、名称、描述；涉及的参与者、涉及的用例；涉众利益；前置条件、后置条件；事件流，基本路径，备选路径；补充约束，字段列表、业务规则，非功能需求、设计约束；待解决问题；相关图(用例图、活动图、类图)重构用例模型：可以采用三类用例建模的高级技术来重构用例模型：（1）用例关系：扩展，包含，泛化（2）用例分包：按主题分包；按开发团队分包；按发布情况分包；按参与者分包（3）用例分级：用例分级的一个基本原则：高级别用例是那些对系统核心架构影响最大的用例。对架构设计有重要影响的用例；体现系统核心业务流程的用例；存在开发风险的用例；涉及新技术或者需要创新的用力；能够尽快投入使用并带来直接经济效益的用例用例分级实施策略-1：可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级。用例分级实施策略-2：依照上述的影响用例级别的特性给用例打分（特性也可能带有权值）。用例建模中常见的问题：用例不是功能分解；用例图不是流程图；用例关系的误用何时适用用例建模：系统由功能需求所主导；系统具有很多类型的用户，系统对他们提供不同的功能；系统具有很多接口。当遇到下述情况时，用例是一个糟糕的选择：系统由非功能需求所主导（如：google）；系统具有很少的用户；系统具有很少的接口（非内部功能）；如：嵌入式系统、算法复杂但接口少的系统等第五章用例分析在面向对象的方法中，业务核心机制表现为相应的对象（类）以及它们的静态和动态关系。分析模型是对分析所形成的目标工件的总称；具体来说，分析模型包含两个层次的两类模型。包括两个层次：构架分析和用例分析；包括两类模型：静态结构(包图、类图)和动态交互(顺序图、通信图)一些具体的分析原则：分析模型使用业务语言；分析类和关系等应该是业务中明确存在的；分析是对需求模型的重新表述，是以理想化的方式来实现用例行为，不考虑技术实现；分析侧重于系统主要部分，关注核心的业务场景；对支撑性行为、非功能需求等不做深入的分析；所有的分析类应该都是为项目涉众产生价值的。用例实现：是分析（设计）模型中一个系统用例的表达式，它通过对象交互的方式描述了分析（设计）模型中指定的用例是如何实现的。构架分析的过程就是定义系统高层组织结构和核心构架机制的过程：1.定义系统高层组织结构—备选构架，典型的架构模型：系统软件（层，管道和过滤 器，黑板），分布式软件（客户/服务器，经纪人，点对点），交互式软件（MVC），自适应软件（反射，微核）；以B-C-E三层划分系统三类处理逻辑：边界层(Boundary)负责系统与参与者之间的交互；控制层(Control)处理系统的控制逻辑；实体层(Entity)管理系统使用的信息。2.确定系统通用构架机制—分析机制：三类构架机制：分析机制（概念）（持久性，分布，安全性，遗留接口）；设计机制（具体）；实现机制（实际）；3.提取系统的关键抽象以揭示系统必须能够处理的核心概念—关键抽象，关键抽象是一个通常在需求上被揭示的概念，系统必须能够对其处理；来源于业务，体现了业务的核心价值，即业务需要处理哪些信息；这些信息所构成的实体即可作为初步的实体分析类；具体来源有需求描述、词汇表、特别是业务对象模型；通过一个或多个类图来展示关键抽象，并为其编写简要的说明；4.创建用例实现来启动用例分析—用例实现，构造用例实现是分析最核心的工作：获得实现用例行为所必须的分析类；利用这些分析类来描述其实现逻辑。针对每一个用例实现：1.完善用例文档2.识别分析类：边界类、控制类和实体类3.分析交互：交互图分析用例实现，利用顺序图描述交互：放置对象，描述交互，验证行为4.完成参与类类图：参与用例实现的类的类图5.处理用例关系，包含关系，扩展关系和泛化关系。定义分析类：最终目标是从系统的角度明确说明每一个分析类的职责和属性以及类之间的关系，从而构造系统的分析类视图。职责是要求某个对象所要执行的事务契约，在设计中将演化为类的操作(一个或多个)；定义职责：做型职责和知道型职责；获取类的职责：从交互图中的消息得到；从非功能需求中得到；定义职责的方式：“分析”操作，文本描述，保持类职责的一致性。定义分析类的属性：属性(Attribute)用来存储对象的数据信息，是没有职责的原子事物；从以下几个方面来定义属性：识别分析类的过程中，也可同时发现类的属性，包括：接在所有格后面的名词或形容词（即某某的属性）、不能成为类的名词以及字段列表中所描述的数据需求；作为一般业务常识，是否有从类职责范围考虑所应包括的属性该业务领域的专家意见以及过去的类似系统。定义分析类的关系：对象间的链接，关联关系（协作关系），聚合关系（整体-部分），泛化关系（抽象-具体）。限定分析机制：（非功能需求）。统一分析类：类体现了系统的静态结构，通过分析类图体现软件静态结构；统一分析类的目的是确保每个分析类表示一个单一的明确定义的概念，而不会职责重叠；在分析工作完成之前，需要过滤分析类以确保创建最小数量的新概念交互概览图元语构件图元语 图书馆管理员处理借书、还书等的用例图图书管理员的活动图 4图书管理员处理书籍借阅的顺序图5图书管理员处理书籍归还的顺序图 类图