如何进行软件工程面向对象分析与设计.pptx

《如何进行软件工程面向对象分析与设计.pptx》由会员分享，可在线阅读，更多相关《如何进行软件工程面向对象分析与设计.pptx（61页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件工程面向对象分析与设计回顾一下面向对象的精华面向对象的历史:面向对象诞生与上世纪90年代初期,最初是专指在程序设计中采用封装、继承、抽象等设计方法,后来没有想到这种思想对问题的抽象和解决提供了很好的方案,甚至最后应用到了分布式系统、网络管理结构、CAD技术、人工智能等领域 ,仿佛在一夜之间所有和计算机相关的专业都朝着面向对象迈进.内容介绍UML基础UML关系UML案例什么是UMLUML(统一建模语言):是一种可视化的建模语言,它能让系统构造者用标准的,易于理解的方式建立起能够表达出他们想象的系统蓝图,并且提供一种机制,以便于不同的人之间有效地共享和交流设计结果.Uml是干什么的我们用面向对

2、象的思想总结出了一些重要的东西,那么这些重要的东西怎么样存放呢,放在脑子里面吗,记在本子上吗,都不是,uml是一个标准,是用来统一大家总结出来的一套重要信息,大家可以运用这个标准去描绘搜集的信息,让其他人很容易的明白你的思想.UML的组成(常用视图)类图用例图状态图时序图协作图活动图构件图部署图UML工具经常用的有Microsoft Office Visio 2007优点:资源多,画出的图比较漂亮,操作简单,功能强大.IBM Rational Rose 2003优点:更接近标准，用的人多，但是安装具有一定的挑战性。我们以IBM Rational Rose 2003为主.UML的组成(常用视图)

3、类图:把现实事物抽象出来,用图来表示. 视频类名属性事件UML的组成(常用视图)用例图:从用户的观点对系统行为的一个描述. 视频UML的组成(常用视图)状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。 状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。 UML的组成(常用视图)状态图： 视频开始状态结束UML的组成(常用视图)时序图(Sequence Diagram)用来显示对象之间的关系，并强调对象之间消息的时间顺序，同时显示了对象之间

4、的交互。时序图中包括如下元素：类角色，生命线，激活期和消息1，类角色(Class Role)类角色代表时序图中的对象在交互中所扮演的角色，位于时序图顶部和对象代表类角色。类角色一般代表实际的对象2，生命线(Lifeline)生命线代表时序图中的对象在一段时期内的存在。时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线，对象间 的消息存在于两条虚线间。3，激活期(Activation)激活期代表时序图中的对象执行一项操作的时期，在时序图中每条生命线上的窄的矩形代表活动期。它可以被理解成C语言语义中一对花括号“”中的内容4，消息(Message)消息是定义交互和协作中交换信息的类，用

5、于对实体间的通信内容建模，信息用于在实体间传递信息。允许实体请求其他的服务，类角色通过发送和接受信息进行通信 UML的组成(常用视图) 视频UML的组成(常用视图)协作图：用来描述系统的工作目标是由哪些组元素相互协作完成的。强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。 活动图:和流程图很类似,它可以显示出工作步骤(活动),判定点和分支. 活动图和时序图都表示时间的先后性, 具体在哪种情况下使用哪一种图? 时

6、序图主要用来表示对象之间的时间关系,要求比较精确.活动图没有很严格的要求,里面可以有名词也可以有动词,像流程图一样只用表示出先后次序即可,所以活动图经常用于和用户交谈的时候,因为它没有严格的要求所以可以一边交谈一边画. 视频UML的组成(常用视图)构件图：软件组成中的一个单元。视频包构件UML的组成(常用视图)部署图：一个UML部署图描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。 部署图显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间件，显示了基于计算机系统的物理系统结构。第二部分 UML细节1 如何认识面向对象中的元素2 UML中的关系。如何认识

7、面向对象中的元素如果我们有一个项目需要做需求分析，这时客户和你交谈的时候因该注意什么呢？动词 名词名词通常是我们面向对象中类的表示。动词通常是我们面向对象中事件，方法，行为的表示。把握好名词动词，并且把它们合理的抽象出来，在软件开发的前期有着重要作用。如何认识面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每个篮球队由5名队员：两个前锋，两名后卫和一名中锋。上面一小段文字里面，能够抽象出什么呢？如何认识面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每个篮球队由5名队员：两个前锋，两名后卫和一名中锋。红色为名词，蓝色为动词如何认识

8、面向对象中的元素例如：比赛的目标是要把篮球投入篮框并且要尽量比对手得更多的分数。每个篮球队由5名队员：两个前锋，两名后卫和一名中锋。对应的UML类图UML 类与类之间的关系 (1)泛化泛化(Generalization)(2)关联关联(Association)(3)依赖依赖(Dependency)(4)聚合聚合(Aggregation) UML中的关联关联：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。UML中的泛化在UML中泛化其实就是我们面向对象中的继承.根叶子UML中的聚合当对象A被加入到对象B中，成为对象B的组成部分时

9、，对象B和对象A之间为聚合关系。聚合是关联关系的一种，是较强的关联关系，强调的是整体与部分之间的关系。UML中的依赖对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。第三部分 案例分析 我们以餐馆的例子来展开分析。我们会学到 1 开发初步类图2 收集系统需求3 开发用例4 交互请看下面的描述。（请注意其中的名词和动词）餐馆案例感谢您花费宝贵的时间与我交谈,分析员说.不客气,您想知道些什么呢?,餐馆的工作人员说.让我们先从一次具体的业务过程开始吧.当一名顾客走进餐馆时,你们要做些什么呢?经过是这样的,如果客户穿着外套,我们会

10、帮助他脱下外套,将外套存放在存衣间里面,并给客户一张取衣票,对戴帽子的客户也是如此的“假设顾客比较多,需要排队等候,怎么办呢?餐馆案例如果确实要排队的话,我们会询问客户是否要预定席位,并尽可能处理好客户的预定,让客户尽快入席.如果没有空缺的席位可供预定,顾客可以登记下他的名字,并且可以选择先到我们安排的休息室喝点饮料,休息一会.当然顾客也可以不去休息室,也可以到一个指定的候餐区等候.“通过上一段的描述,我们可以绘制出活动图餐馆案例餐馆案例“在顾客入座之前,餐桌必须要提前准备好,清洁师要事先清理桌面,除去旧的桌布,换上新的桌布,还要调整好桌子和座位.当一切准备就绪后,领餐员将顾客领到餐桌前就座,

11、并且叫一名服务员来招待顾客.“然后服务员就接管了这一桌的顾客.他给每一位就餐者一份菜单,并且询问顾客是否要预定酒水,然后服务员会叫一名助手,助手会负责酒水,面包,黄油,等等.不需要则等待顾客点菜.通过上一段的描述,我们可以绘制出活动图餐馆案例泳道活动图,每个泳道只有这个对象的活动,这样图会很好扩展(视频)餐馆案例顾客点了菜,服务员记录下顾客所点的菜,接着呢?接着通知厨师,服务员将顾客的选择填写在一张表格中然后交给厨师“就餐完毕后,服务员会上前咨询顾客是否要些甜食,如果顾客要吃,服务员要给顾客上一份甜食菜单,并记录,如果客户不吃则服务员拿来帐单让顾客来确认,过几分钟后服务员回来收钱,给顾客收据,

12、顾客离开座位,取回衣帽,离开餐馆.顾客走后,服务员还要找来清洁师清理餐桌,并重新布置餐桌和座椅准备下一批客户使用.通过上一段的描述,我们可以绘制出活动图餐馆案例开发初步类图经过上述的描述我们已经作出了活动图,下面我们要根据活动图和描述中的名词构造出一些类.名词:我们很容易的发现在一些名词中有很多的相近的.比如说侍者(waiter)和服务员(server)是同义词,所以我们保留一个好听的吧服务员(server).再有顾客(customer)和就餐者(diner)也是同义词,所以我们也保留一个,就叫顾客(customer),还有很多大家请细看.开发初步类图经过上述的描述我们已经作出了活动图,下面我

13、们要根据活动图和描述中的名词构造出一些类.整理后的名词:顾客(customer),外套(coat),储衣室(cloakroom),取衣票(coat-check ticket),帽子(hat),队列(waiting list),休息室(cocktail lounge),饮料(drink),正餐(dinner),餐桌(table),清洁师(busser),桌布(tablecloth),领餐员(maitre d),菜单(menu),助手(assistant),服务员(server),厨师(chef),订单(order).等等其实这些就是我们所需要的类开发初步类图需要用到的类(后面的步骤将对这些类逐步

14、细化):形成关联有一些类是有关系的,我们要合理的组织这些关系,后期的代码编写量会少一些.例如:这几个类可以预见有很多属性是相同的,所以我们就创建一个它们都有的父类形成关联还要找出这些类会和那些类有交互,以便为后面的用例图打基础.填充类的信息关系都找完后,下面要做的就是,要对类的信息进行详细的填充.填充类的时候,通常还需要和客户进行沟通,必要时也可以自己添加.填充类的信息和客户交互后发现Customer类属性:name,arrivaltime,order,serveTime事件:eat(),drink(),order(),pay()Employee类属性:name,address,socialS

15、ecurityNumber,yearsExperience,hireDate,salary事件:carry(),pour(),collect(),call(),checkOrderStatus()填充后的类图收集系统需求看下面一段话。协调员:这个系统做好后准备叫什么名字呢?厨师:叫MASTER CHEF怎么样?协调员:不好听,在想一个吧系统工程师:来个简明快捷的吧,就叫Wireless Interactive Network-WIN.分析员:恩,比较有创意,刚好这个名字也是胜利的缩写,要不就采用这个吧大家:好“这段话比较简单，我们能够确定系统的名字收集系统需求系统工程师:WIN这个系统,它的大

16、致工作情况是这样的,服务员使用PDA与厨师和清洁师进行通信.清洁师也适用PDA接受信息.厨房中安装一台PC或者多个终端,用来接受信息,经理办公室也安装一台桌面电脑.这段话能够确认系统的部署。收集系统需求部署图：收集系统需求系统按照模块工作,每个成员在自己的模块中工作,模块有Server,Chef,Busser,Assistant,Manager“这段话我们能够确认角色收集系统需求角色模块：收集系统需求收集信息的最后我们要确定用例了，也就是说那些角色和模块应该做什么。收集系统需求Server包中的用例包中的用例Take an order（输入定单） Transmit the order to t

17、he kitchen（将定单发送到厨房）Change an order（修改定单）Receive notification from kitchen（接收来自厨房的通知）Track order status（跟踪定单状态）Notify chef about party status（通知厨师客人的用餐状态）Total up a check（结算帐单）Print a check（打印帐单）收集系统需求Chef包中的用例包中的用例Store a recipe（记录一个菜谱） Retrieve a recipe（取得一个菜谱）Notify the server（通知服务员）Receive a req

18、uest from the server（接收来自服务员的请求）Acknowledge server request（确认服务员的请求）Enter the preparation time（输入准备的时间估计值）Assign an order（指派一个定单）收集系统需求(系统功能包图)开发用例用例分析：通常以下七个步骤可以完整地描述出一个用例场景的简单陈述关于场景的假设条件用例的发起参与者场景的前置条件场景中与系统相关的步骤序列场景完成后的后置条件用例的收益参与者开发用例我们以Server包中的一个用例为例子Server包中的用例包中的用例Take an order（输入定单） 开发用例发起参

19、与者：Server收益参与者：Customer简单陈述：服务员将顾客的定单信息输入到他的手提电脑并将定单信息传递到厨房。假设条件：顾客想就餐，顾客已经阅读了菜单并做出了选择电脑已经出现了“输入定单”用户界面。开发用例前置条件：顾客已经就坐并阅读了菜单。后置条件：定单被输入进WIN系统中。步骤序列：1.服务员激活电脑中“输入定单”用户界面。2.“输入定单”界面显示在电脑屏幕上。3.服务员将顾客的菜单选项输入到WIN系统。4.系统将定单发送到厨房的桌面电脑。 开发用例为什么要这么繁琐的描述一个用例呢？我们知道,我们软件开发这一行通常人员流动性很大,如果了解这套系统业务的人走了怎么办,新来的员工将会无从下手,系统将会延期,而用例是关联着类内部和类之间的通信,起着重要作用,绘制的详细,其实就是对业务的描述,新员工来后看用例部分就知道其中的业务逻辑了不需要在重新做一次需求分析.Thank you