【文档说明】如何进行软件工程面向对象分析与设计.pptx，共(61)页，1.772 MB，由精品优选上传

转载请保留链接：https://www.ichengzhen.cn/view-290951.html

以下为本文档部分文字说明：

软件工程—面向对象分析与设计回顾一下面向对象的精华面向对象的历史:面向对象诞生与上世纪90年代初期,最初是专指在程序设计中采用封装、继承、抽象等设计方法,后来没有想到这种思想对问题的抽象和解决提供了很好的方案,甚至最后应用到了分布式系统、网络管理结构、CAD技术、人工智能等领域,仿佛在一夜

之间所有和计算机相关的专业都朝着面向对象迈进.内容介绍UML基础UML关系UML案例什么是UMLUML(统一建模语言):是一种可视化的建模语言,它能让系统构造者用标准的,易于理解的方式建立起能够表达出他们想象的系统蓝图,并且提供一种机制,以便于不同的人之间有效地共享和交流设计结果.Uml

是干什么的我们用面向对象的思想总结出了一些重要的东西,那么这些重要的东西怎么样存放呢,放在脑子里面吗,记在本子上吗,都不是,uml是一个标准,是用来统一大家总结出来的一套重要信息,大家可以运用这个标准去描绘搜集的信息,让其他人很容易的明白你的思想.UML的组成(常用视图)类图

用例图状态图时序图协作图活动图构件图部署图UML工具经常用的有MicrosoftOfficeVisio2007优点:资源多,画出的图比较漂亮,操作简单,功能强大.IBMRationalRose2003优点:更

接近标准，用的人多，但是安装具有一定的挑战性。我们以IBMRationalRose2003为主.UML的组成(常用视图)类图:把现实事物抽象出来,用图来表示.视频类名属性事件UML的组成(常用视图

)用例图:从用户的观点对系统行为的一个描述.视频UML的组成(常用视图)状态图(StatechartDiagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。状态图用于显示状态机（它指定对象

所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。UML的组成(常用视图)状态图：视频开始状态结束UML的组成(常用视图)时序图(SequenceDiagram)用来显示对象之间的关系，并强调对象之间消

息的时间顺序，同时显示了对象之间的交互。时序图中包括如下元素：类角色，生命线，激活期和消息1，类角色(ClassRole)类角色代表时序图中的对象在交互中所扮演的角色，位于时序图顶部和对象代表类角色。类角色一般代表实际的对象2，生命线(Lifeline)生命线

代表时序图中的对象在一段时期内的存在。时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线，对象间的消息存在于两条虚线间。3，激活期(Activation)激活期代表时序图中的对象执行一项操作的时期，在时序图中每条生命线上的窄的矩形代

表活动期。它可以被理解成C语言语义中一对花括号“{}”中的内容4，消息(Message)消息是定义交互和协作中交换信息的类，用于对实体间的通信内容建模，信息用于在实体间传递信息。允许实体请求其他的服务，类角色通过发

送和接受信息进行通信UML的组成(常用视图)视频UML的组成(常用视图)协作图：用来描述系统的工作目标是由哪些组元素相互协作完成的。强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象

之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。活动图:和流程图很类似,它可以显示出工作步骤(活动),判定点和分支.活动图和时序图都表示时间的先后

性,具体在哪种情况下使用哪一种图??时序图主要用来表示对象之间的时间关系,要求比较精确.活动图没有很严格的要求,里面可以有名词也可以有动词,像流程图一样只用表示出先后次序即可,所以活动图经常用于和用户交谈的时候,因为它没有严格的要求所以可以一边交谈一边画.

UML的组成(常用视图)构件图：软件组成中的一个单元。视频包构件UML的组成(常用视图)部署图：一个UML部署图描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。部署图显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间

件，显示了基于计算机系统的物理系统结构。第二部分UML细节1如何认识面向对象中的元素2UML中的关系。如何认识面向对象中的元素如果我们有一个项目需要做需求分析，这时客户和你交谈的时候因该注意什么呢？？动词名词名词通常是我们面向对象中类的表示。动词通常是我们面向对象中事件，方法，行为的表示。把握

好名词动词，并且把它们合理的抽象出来，在软件开发的前期有着重要作用。如何认识面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每个篮球队由5名队员：两个前锋，两名后卫和一名中锋。上

面一小段文字里面，能够抽象出什么呢？？？如何认识面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每个篮球队由5名队员：两个前锋，两名后卫和一名中锋。红色为名词，蓝色为动词如何认识面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每

个篮球队由5名队员：两个前锋，两名后卫和一名中锋。对应的UML类图UML类与类之间的关系(1)泛化(Generalization)(2)关联(Association)(3)依赖(Dependency)(4)聚合(Aggregation)UML中的关联关联：对于两个相对独立的对象，

当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。UML中的泛化在UML中泛化其实就是我们面向对象中的继承.根叶子UML中的聚合当对象A被加入到对象B中，成为对象B的组成部分时，对象B和对象A之间为聚合关系。聚合是关联关系的一种，是较强的关联关系

，强调的是整体与部分之间的关系。UML中的依赖对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。第三部分案例分析我们以餐馆的例子来展开分

析。我们会学到1开发初步类图2收集系统需求3开发用例4交互请看下面的描述。（请注意其中的名词和动词）餐馆案例"感谢您花费宝贵的时间与我交谈",分析员说."不客气,您想知道些什么呢?",餐馆的工作人员说."让我们先从一次具体的业务过程开始吧.当一名顾客走进餐馆时,你们要做些什么呢?""经过是这

样的,如果客户穿着外套,我们会帮助他脱下外套,将外套存放在存衣间里面,并给客户一张取衣票,对戴帽子的客户也是如此的“"假设顾客比较多,需要排队等候,怎么办呢?"餐馆案例"如果确实要排队的话,我们会询问客户是否要预定席位,并尽可能处理好客户的预定,让客户尽快入席

.如果没有空缺的席位可供预定,顾客可以登记下他的名字,并且可以选择先到我们安排的休息室喝点饮料,休息一会.当然顾客也可以不去休息室,也可以到一个指定的候餐区等候.“通过上一段的描述,我们可以绘制出活动图餐馆案例餐馆案例“在顾客入座之前,餐桌必须要提前准备

好,清洁师要事先清理桌面,除去旧的桌布,换上新的桌布,还要调整好桌子和座位.当一切准备就绪后,领餐员将顾客领到餐桌前就座,并且叫一名服务员来招待顾客."“然后服务员就接管了这一桌的顾客.他给每一位就餐者一份菜单,并且询问顾客是否要预定酒水,然后服务员会叫一名助手,助

手会负责酒水,面包,黄油,等等.不需要则等待顾客点菜.通过上一段的描述,我们可以绘制出活动图餐馆案例泳道活动图,每个泳道只有这个对象的活动,这样图会很好扩展(视频)餐馆案例"顾客点了菜,服务员记录下顾客所点的菜,接着呢?""接着通

知厨师,服务员将顾客的选择填写在一张表格中然后交给厨师"“就餐完毕后,服务员会上前咨询顾客是否要些甜食,如果顾客要吃,服务员要给顾客上一份甜食菜单,并记录,如果客户不吃则服务员拿来帐单让顾客来确认,过几分钟后服务员回来收钱,给顾客收据,顾客离开座位,取回衣帽,离开餐

馆.顾客走后,服务员还要找来清洁师清理餐桌,并重新布置餐桌和座椅准备下一批客户使用.通过上一段的描述,我们可以绘制出活动图餐馆案例开发初步类图经过上述的描述我们已经作出了活动图,下面我们要根据活动图和描述中的名词构造出一些类.名词:我们很容易的发现在一

些名词中有很多的相近的.比如说侍者(waiter)和服务员(server)是同义词,所以我们保留一个好听的吧服务员(server).再有顾客(customer)和就餐者(diner)也是同义词,所以我们也保留一个,就叫顾客(customer),还有很多大家请细看.开发初步类图经过上

述的描述我们已经作出了活动图,下面我们要根据活动图和描述中的名词构造出一些类.整理后的名词:顾客(customer),外套(coat),储衣室(cloakroom),取衣票(coat-checkticket),帽子(ha

t),队列(waitinglist),休息室(cocktaillounge),饮料(drink),正餐(dinner),餐桌(table),清洁师(busser),桌布(tablecloth),领餐员(maitred’),菜单(menu),助手(assi

stant),服务员(server),厨师(chef),订单(order)….等等其实这些就是我们所需要的类开发初步类图需要用到的类(后面的步骤将对这些类逐步细化):形成关联有一些类是有关系的,我们要合理的组织这些关系,后期的代码编

写量会少一些.例如:这几个类可以预见有很多属性是相同的,所以我们就创建一个它们都有的父类形成关联还要找出这些类会和那些类有交互,以便为后面的用例图打基础.填充类的信息关系都找完后,下面要做的就是,要对类的信息进行详细的填充.填充类的

时候,通常还需要和客户进行沟通,必要时也可以自己添加.填充类的信息和客户交互后发现Customer类属性:name,arrivaltime,order,serveTime事件:eat(),drink(),order(),pay()Em

ployee类属性:name,address,socialSecurityNumber,yearsExperience,hireDate,salary事件:carry(),pour(),collect(),

call(),checkOrderStatus()填充后的类图收集系统需求看下面一段话。协调员:"这个系统做好后准备叫什么名字呢?"厨师:"叫MASTERCHEF怎么样?"协调员:"不好听,在想一个吧"系统工程师:"来个简明快捷的吧,就叫WirelessIn

teractiveNetwork---WIN."分析员:"恩,比较有创意,刚好这个名字也是胜利的缩写,要不就采用这个吧"大家:"好“这段话比较简单，我们能够确定系统的名字收集系统需求系统工程师:"WIN这个系统,它的大致工作情况是这样的,服务员使用PDA与厨师和清洁师进行通信.清洁师也适用P

DA接受信息.厨房中安装一台PC或者多个终端,用来接受信息,经理办公室也安装一台桌面电脑.这段话能够确认系统的部署。收集系统需求部署图：收集系统需求系统按照模块工作,每个成员在自己的模块中工作,模块有Server,Chef,Busser,Assistant,Manager“这段话我

们能够确认角色收集系统需求角色模块：收集系统需求收集信息的最后我们要确定用例了，也就是说那些角色和模块应该做什么。收集系统需求Server包中的用例Takeanorder（输入定单）Transmittheor

dertothekitchen（将定单发送到厨房）Changeanorder（修改定单）Receivenotificationfromkitchen（接收来自厨房的通知）Trackorderstatus

（跟踪定单状态）Notifychefaboutpartystatus（通知厨师客人的用餐状态）Totalupacheck（结算帐单）Printacheck（打印帐单）收集系统需求Chef包中的用例Storeare

cipe（记录一个菜谱）Retrievearecipe（取得一个菜谱）Notifytheserver（通知服务员）Receivearequestfromtheserver（接收来自服务员的请求）Acknowledgeserverreque

st（确认服务员的请求）Enterthepreparationtime（输入准备的时间估计值）Assignanorder（指派一个定单）收集系统需求(系统功能包图)开发用例用例分析：通常以下七个步骤可以完整地描述出

一个用例场景的简单陈述关于场景的假设条件用例的发起参与者场景的前置条件场景中与系统相关的步骤序列场景完成后的后置条件用例的收益参与者开发用例我们以Server包中的一个用例为例子Server包中的用例Takeanorder（输入定单）开发用例发起参与者：Se

rver收益参与者：Customer简单陈述：服务员将顾客的定单信息输入到他的手提电脑并将定单信息传递到厨房。假设条件：顾客想就餐，顾客已经阅读了菜单并做出了选择电脑已经出现了“输入定单”用户界面。开发用例前置条件：顾客已经就坐并阅读了菜单。后置条件：

定单被输入进WIN系统中。步骤序列：1.服务员激活电脑中“输入定单”用户界面。2.“输入定单”界面显示在电脑屏幕上。3.服务员将顾客的菜单选项输入到WIN系统。4.系统将定单发送到厨房的桌面电脑。开发用例为什么要这么繁琐的描述一个用例呢？我们知道,我们软件开发这一行通常人

员流动性很大,如果了解这套系统业务的人走了怎么办,新来的员工将会无从下手,系统将会延期,而用例是关联着类内部和类之间的通信,起着重要作用,绘制的详细,其实就是对业务的描述,新员工来后看用例部分就知道其中的业务逻辑了不需要在重新做一次需求分

析.Thankyou