软件工程知识点总结(3):需求分析(二)——分析模型建模

1 类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。类图 技术是 OO 方法的核心。 类图标加上它们之间的关系就构成了类图。

说明:类图描述类和类之间的静态关系。它不仅显示了信息的结构,同时还描述 了系统的行为。类图中可以包含接口,包,关系等建模元素,也可以包含对象等 实例。

类的表示:类是具有相似结构、行为和关系的一组对象的描述符。

类的命名:由字母、数字、下划线组成的惟一的字符串;大写字母开头,每个单 词以大写开始,避免使用特殊符号

类名的两种表示方法:简单名          Order

                                    路径名          java::awt::Rectanget        businessRule::Order      包名::类名

类的属性:属性名的第一个字母小写;

属性的定义格式:[可见性] 属性名 [:类型] [=初始值] [{特性}]

属性的可见性,四类:

       public(+): 即模型中的任何类都可以访问该属性.

       private(-):表示不能被别的类访问.

       protected(#):表示该属性只能被该类及其子类访问.

       Package (~):这个类只能由同一包中的其他类访问

类的方法的命名规范:第一个字母小写。

类的方法的定义格式:[可见性] 方法名 [(参数列表)] [:返回类型]

       例: +hide():Boolean        “+”:public

               -attachXWindow(xwin:XwindowPtr) “-”:private

               #create()                    “#”:protected

类的职责:职责指的是类所担任的任务,即类要完成什么样的功能,要承担什么 样的义务。在 UML 中,可以写在 document 中。

类图:接口、关系、注释、约束、包

接口: 是一种类似于抽象类的机制,是一个没有具体实现的类,只声明抽象方法。 接口可以实现多态;

2 关系:类和类之间的线就是关系(重点)

类与类之间关系划分为:1、关联:包含普通关联、自反关联、限定关联、关联 类 2、聚集:包含聚合、组合 3、依赖 4、泛化 5、实现

3 关联表示两个类的对象之间存在某种语义上的联系。长期的,稳定的。

多重性:某个类的对象可以和另个类的多个对象联系

关联:类与类之间稳定的关系(关系需要存储)

详细设计阶段:

       数据库中: 用户表       订单表       订单中含用户 id

       顾客表 :顾客 id       name       address

       订单表: 订单 id       商品 id       time       顾客 id

同类不同对象关联——自反关联:

抽取出类: “人”

类的属性: 身份证号、年龄、婚否、配偶

数据库:每人一条记录,该记录必有一个字段为配偶身份证号

       居民表 :居民 id       name       age       address       配偶 id

自反关联应用广泛,某些场合能够实现更加灵活的系统结构。

限定关联:利用限定词把一对多关系简化成了一对一关系。

例如:某操作系统中一个目录下有许多文件,一个文件仅属于一个目录,在一个 目录中文件名唯一确定一个唯一文件。

关联类:作为其他两个类之间的关联关系一部分的类,是为了说明这两个类之间 更多的关联信息。关联类与一般的类一样,也有属性、操作和关联。

关联:稳定的,长期的,为关联关系。表现在代码实现中,一个对象会作为另一 个对象的属性是关联。

关联关系也可以是单向关联,也可以是双向关联。

聚集:聚集是关联的一种特殊情况。聚集表示类与类之间的关系是整体与部分的 关系。聚集分为聚合和组合。

如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成,则 该聚集称为共享聚集,也叫聚合。

聚合图示符号:在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形。

设计中 :人的集合作为课题组的一个属性。课题组集合作为“人”类的一个属性 数据库操作中,课题组的删除,不涉及到人员删除。

4 如果部分类完全隶属于整体类,部分与整体共存,整体不存在了部分也会随之消 失(或失去存在价值了),则该聚集称为组合。

例如:记录员工基本信息。员工的地址包含多类信息:email,住所,电话等。 为了处理方便,员工与地址,抽象为两个类,为一对多。

数据库操作中,员工的删除, 涉及到地址删除

5 聚合:“弱”。如果部门没有了,员工也可以继续存在;

组合: “强”。如果部门没有了,员工也不再存在。

聚合与组合的代码表现:

这两种关系的区别是:

(1)构造函数不同

       聚合类的构造函数中包含另一个类的实例作为参数。因为构造函数中传递另一 个类的实例,因此大雁类可以脱离雁群类独立存在。

       组合类的构造函数包含另一个类的实例化。因为在构造函数中进行实例化,因 此两者紧密耦合在一起,同生同灭,翅膀类不能脱离大雁类存在。

(2)信息的封装性不同

       在聚合关系中,客户端可以同时了解 GooseGroup 类和 Goose 类,因为他们是 独立的。

       在组合关系中,客户端只认识大雁类,根本不知道翅膀类的存在,因为翅膀类 被严密地封装在大雁类中。

6 依赖:依赖关系描述两个类之间的使用关系: 两个类之间是没有关系的,但是 一个类的实现需要另一个类的协助,这就产生了依赖。

依赖关系的代码表现:局部变量、方法参数、对静态方法的调用 注意:依赖关系只会表现在方法中,不会增加属性

7 泛化:UML 中的泛化关系就是通常所说的继承关系,它是通用元素和具体元素 之间的一种分类关系。具体元素完全拥有通用元素的信息,并且还可以附加一些 其他信息。

在 UML 中,用一端为空心三角形的连线表示泛化关系,三角形的顶角紧挨着通 用元素。

没有具体对象的类称为抽象类,抽象类一般作为父类,用于描述其他类(子类) 的公共属性和行为。在类名、操作下方附加一个标记值{abstract}表示;也可用斜 体表示类名称和属性、方法。抽象类或者抽象操作的名字用斜体表示

实现:对应于类和接口(箭头指向接口)之间的关系

总结:两个类之间,分析是否为泛化、实现、依赖。如果不是,分析是否是聚合、 组合。如果不是,考虑是否存在关联类、自身关联。如果不是,为普通关联。

请用类图描述公司与雇员的关系:

8 顺序图是动态交互图,描述一个用例中对象间的交互活动,它关注对象之间消息 传送的时间顺序。

目的:通过顺序图来对执行者和系统的交互过程进行建模,方便用户更好地理解 系统的工作流程。

在 UML 中,我们将顺序图分为两类 :分析模型(分析阶段)、设计模型(设计 阶段)。

在系统分析时,顺序图可显示不同的业务对象如何交互及消息交互的顺序。一般 使用用户熟悉的业务语言来进行系统描述。

顺序图组成元素:对象-- Object、生命线-- Lifeline、控制焦点(激活)-- Activation、 消息-- Message

对象:对象排列在上方,通常将发起交互的对象放在左边,将接收消息的对象放 在右边。

对象的命名方式有三种(主要第二种):显示对象名和类名 、只显示类名(匿 名对象)、只显示对象名(不关心类)

9 生命线:表示对象存在的时间。如果对象生命期结束,则用注销符号表示。

控制焦点(激活期):对象执行某个动作的时期。

消息: 对象间通过相互发消息来实现交互,一个对象通过发送消息请求另一个 对象做事。消息从源对象指向目标对象。消息一旦发送便将控制从源对象转移到 目标对象。

源对象某方法中有代码:目标对象.message(para);比如:矩形和线段

UML 中 5 种消息 :调用(同步消息)、发送(异步消息)、返回、创建、销毁

(1)调用消息(同步消息):发送者把消息发送后,等待,直到接收者返回控 制。

(2)发送消息(异步消息):消息发送后,发送者继续操作,不等待。

异步:消息可以是一个信号或一次操作调用,收到消息即为事件。可以有两种消 息,一种是从发送者向接收者发送信号,另一种是由调用者调用接收者的操作。

(3)返回消息:表示消息的返回。同步消息本身就隐含一个返回,一般情况下 可以省略返回消息,但如果需要强调明确表示返回的结果值,则可以使用返回消 息。异步返回需要返回消息。

自调用:表示某对象调用自己的操作。

(4)创建:通常利用构造方法来实现,对象一创建,生命线就开始了。

(5)销毁:生命终止符号用一个较大的叉形符号表示。

注意:在需求分析阶段,顺序图的“消息”上可以是(1)“数据”(2)“操作(传送 的数据)” 。消息可以用文字表达,也可用英文。在设计阶段,顺序图的“消息” 上,必须为“操作(参数,..)”。 消息用英文表示

顺序图:又称时序图。通常,每一个用例建立一张顺序图。 也可以,一个用例 建立几张顺序图。 顺序编号: ——在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。

嵌套编号:——把属于同一个对象发送和接收的消息放在同一层进行编号。

嵌套编号应用:

A 要完成工作,需要 1、2、3 步。
Class A{
work(){1;2 步借助于 B.work;3;}
}
Class B{
workB(){2.1;2.2;2.3 步借助于 C.work;}
}
Class C{
workC(){...}
}

处理过程有顺序、选择、循环通过交互片段实现选择、循环。每个交互片段都有 一个操作符,操作符决定了交互片段的执行方式。

(1)表示分支的操作符:alt:支持多条件       opt:支持单条件

(2)表示循环的操作符:loop       循环次数和监护条件表达式表示执行次数

10 分析模型建模:

任务:对获取的用例模型进行理解、分析,找出描述问题域和系统责任所需要的 类及对象,建造分析模型。

分析模型:对象模型(类图,对象图)、动态模型(顺序图、状态图)

常用建立对象模型方法:(1)名词识别法 (2)类-职责-协作法 CRC( Class Responsibility Collaboration )

目标:对需求进行分析,寻找实体类及关系从现实世界可以抽象出来的。 (1)类的对象对应着现实世界中的“事物”。(2) 对必须存储的信息和相关 行为建模的类。 也可概要的称为:实体类。通常都是永久性的

1)文档来源 (基于用例模型):补充的需求规格说明、用例文档、项目说明 文档、其他文档

2)建模步骤:①从文档中寻找类(名词),确定类的含义和职责;②定义类的 属性(名词);③确定类之间的关系;④确定操作(动词);动态模型辅助寻找 (顺序图、状态图)——“操作”也可放到设计阶段完成⑤精化类和类间的关系;

作为类的名词的特点:

       人员:系统需要保存或管理其信息的人员(如录像商店的会员、图书馆的读者), 或在系统中中扮演一定角色的人员(如录像商店的职员、论文评阅教师)。

       组织:在系统中发挥一定作用的组织机构(如录像商店的连锁店,医疗保险系统 中的医院,学校中的系)。

       物品:需要由系统管理的各种物品(如录像商店的商品、图书),包括无形事物 (如学校的一门课程、毕设题目)。

       设备:在系统中被使用或由系统进行监控的设备、仪器等,系统运行中的硬件设 备(如打印机)除外。

       事件:需要由系统长期记忆的事件(如在自动柜员机上的每次取款事件、每次借 书事件)。

11 分析类代表了系统中具备职责和行为的事物的早期概念模型,这些概念模型最终 会转换为设计模型中的类或子系统。

定义分析类的目标:从系统的角度,明确说明每个分析类的职责和属性及类之间 的关系,从而构造系统的分析类视图;根据这些视图来描述和理解目标系统,从 而为后续的设计提供基本的素材。

认识 MVC 三层架构:

       在系统分析的早期,倾向于使用一种通用的分层策略——MVC 三层架构。

       系统中的类对应三个层次:视图(View)、控制器(Controller)和模型(Model)。 视图:

视图(View):面向用户显示交互(接收用户输入的数据,展示数据给用 户)

模型(model): 是应用程序的主体部分,由多个类组成。主要包括业务逻辑模块 (完成软件的功能)和数据模块(对数据的存取)。

控制器(Controller):接收来自视图(view)的请求, 并交给模型(model)进行处 理。将模型(model)处理结果传递给视图(view)。它只是接收请求并决定调用哪个 模型去处理请求,然后再确定用哪个视图来显示返回的数据。UML 中分析模型 采用的就是 MVC 模式。

对象系统中的类相应的对应 MVC 架构的三个层次:边界类 Boundary,控制类 Control, 实体类 Entity 。它们统称分析类。

12 识别分析类:

       边界类(Boundary class)位于系统与外界的交界处,处于系统最上层,处理系统环 境和系统内部间的通信。

       边界类分为两类:用户界面类:系统与外部进行交互的类,在分析阶段关注于为 用户提供哪些操作,如用户输入数据,展示数据给用户。系统/设备接口类:系 统与外部系统或设备之间交互的接口类,在分析阶段关注交互的协议。

控制类 Control: 处于中间层,封装上层的边界类和下层的实体类之间的交互行 为,是整个用例行为的协调器。控制类可以有效的将边界对象和实体对象分开, 更适应系统边界对象的变更; 将用例所特有的行为与实体对象分开,使实体对 象有更高的复用性。

控制类 Control 特点:独立于外部环境,不依赖于环境的变更;定义控制逻辑和 事务逻辑;实体类内部结构或行为发生变更时控制类不会有大的变更。

实体类(Entity class):代表系统的核心概念,来自对业务中的实体对象的抽象,用 于记录系统所需要维护的数据和对这些数据的处理行为。

通常,实体类不是某一个用例实现所特有的(及一个实体类会跨越多个用例)

分析类的重要性:分析类用于获取系统中主要的“职责簇”,是系统必须处理的主 要抽象概念的“第一个关口”,之后对系统的“高级”设计都是基于此进行。分析类 是从功能性需求向计算机实现转化过程中的“第一关口”。分析类可以产生系统的 设计类和子系统。这意味着计算机实现是可以通过某种途径“产生”出来的,而不 是拍着脑袋拍出来的。

13 OOA 动态模型-状态图: 一个 UML 状态图是为了以下的研究目的:研究类、角色、子系统、或组件的复 杂行为。

作用:(1)描述一个特定对象的所有可能状态及其引起状态转移的事件。(2)描述 业务领域的业务流程: 在什么状态下,有什么事件发生,导致了什么后果。

状态的动作;do 事件则指定在该状态下的动作。如“do/看手机”

需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

事件表达式的语法:事件说明[守卫条件]/动作表达式

事件说明的语法为:事件名(参数表)。 守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件,则当且仅当事 件发生且布尔表达式为真时,状态转换才发生。如果只有守卫条件没有事件说明, 则只要守卫条件为真状态转换就发生。

事件说明和[守卫条件]至少写一个,动作表达式可以没有。

14 事件(Event)细述:

       事件:是对一个时间和空间上占有一定位置的有意义的事情的规格说明。

       事件的类型 :信号事件、调用事件、变化事件、时间事件

(1)信号事件(signal event): 对象之间可以通过发送信号和接收信号实现通信。所谓信号,是指由一个对象异 步的发送、并由另外一个对象接收的一个已命名的对象。

信号事件表示对象接收到某个信号。

(2)调用事件(call event): 一个对象请求调用某个对象的成员方法。如 turnOn

(3)变化事件(change event): 频繁的测试表达式,只要表达式由假变为真,事件就会发生。用关键字 When, 后面跟布尔表达式。

(4)时间事件(time event): 满足 一个绝对时间的到达,或者相对时间的消耗。用关键字 After 表示

绘制状态机图的一般步骤是: 1.对对象进行分析,寻找主要的状态; 2.寻找外部事件,以便确定状态之间的转换; 3.详细描述每个状态和转换; 4. 把简单状态图转换为复合状态图。

  • 15
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

茜茜西西CeCe

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值