面向对象分析与设计UML实验报告

《面向对象分析与设计UML

实验报告

实验及作业一

一、实验目的

了解软件工程等基础知识,为后续的统一建模语言UML知识的学习做好准备工作。

二、实验设备与环境

装有Visio、RationalRose的计算机。

三、实验内容

1、复习阐述“软件工程开发模型”的相关概念,并分析各种模型的优缺点,写成实验报告。

2、熟悉UML软件设计工具Visio、Rational Rose的安装及环境

四、实验过程及结果

经过上网搜索相关信息进行了解软件工程开发模型 的相关概念与优缺点

一,什么是软件工程概念模型

  模型就是抽象,就是有意识地忽略事物的某些特征。抽象带来的好处是能够反映模型中元素之间的关系,清晰把握大局。

  概念模型是模型的一种,简单说就是抽象程度极高的一种模型。

  软件工程概念模型是对软件工程领域进行抽象描述的模型,它能够使我们对软件工程有一个完整把握。

二,软件工程开发模型的种类以及优缺点

三,软件工程与UML的关系

随着计算机技术的发展,软件工程技术已经进入了一个新的阶段。人们开始使用面向对象的技术,同时UML融合了多种面向对象建模方法以及多种软件工程方法,成为软件系统设计建模的主要工具。

五、实验小结:

  了解UML一些知识

实验及作业二

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

1、熟悉Visio、RationalRose、StarUML的使用。

2、熟悉利用统一建模语言进行分析、设计软件的过程,完成作业:论述面向对象(OO)方法的特点、优势以及存在的问题。

四、实验过程及结果

面向对象(OO)方法的特点

1.信息隐藏和封装特性:

封装是把过程和数据包围起来,对数据的访问只能通过已定义的界面。面向对象计算始于这个基本概念,即现实世界可以被描绘成一系列完全自治、封装的对象,这些对象通过一个受保护的接口访问其他对象。

2.继承:

继承是一种联结类的层次模型,并且允许和鼓励类的重用,它提供了一种明确表述共性的方法。对象的一个新类可以从现有的类中派生,这个过程称为类继承。新类继承了原始类的特性,新类称为原始类的派生类(子类),而原始类称为新类的基类(父类)。派生类可以从它的基类那里继承方法和实例变量,并且类可以修改或增加新的方法使之更适合特殊的需要。

3.组合特性

组合用于表示类的“整体/部分”关系。例如主机、显示器、键盘、鼠标组合成一台计算机。

4.动态特性

(1)抽象:

抽象就是忽略一个主题中与当前目标无关的那些方面,以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题,而只是选择其中的一部分,暂时不用部分细节。抽象包括两个方面,一是过程抽象,二是数据抽象。

(2)多态性:

多态性是指允许不同类的对象对同一消息作出响应。多态性包括参数化多态性和包含多态性。多态性语言具有灵活、抽象、行为共享、代码共享的优势,很好的解决了应用程序函数同名.

面向对象方法的主要优点

符合人们通常的思维方式;从分析到设计再到编码采用一致的模型表示具有高度连续性;软件重用性好。

面向对象方法的主要缺点

1、OO方法比较抽象,如楼上所说的掌握它便要付出很多!
      想一想,OO出现已经很早了,但为什么这一、两年这么受欢迎和重视呢?我想前两年(电子商务热之前),面向VISUAL大行其道,OO呢?也许只在VC界被谈得多些,但一般的应用开发领域并不怎么样啊!而正是WEB/INTERNET的大发展,类似于C语言的JAVA技术得到了空前的发展,正因为此,OO又被更多的公司所重视。
      2、OO思路在某些领域(主要集中于基于VISUAL开发的应用开发领域)并不理想——关键原因还是“太过抽象”,难以使开发团队、客户轻松理解。

五、实验小结:

      了解面向对象方法的优缺点。

实验及作业三

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

1、掌握“参与者”、“用例”、“各种关系”在StarUML或Rational Rose中的设计方法。体会用例图的设计方法。

2、以图书馆管理系统为例,完成其用例图的设计。并书写实验报告。

四、实验过程及结果

1、系统的用户分析

管理员 : 建立课程信息 ,可以修改,删除,保存。

学生:    查询课程信息,可以选课,付费。

2、网上选课系统事件流

(1)添加、删除选课事件流

管理员登陆,用例开始;

建立/删除/修改信息;

保存信息。

(2)学生选课事件流

     学生登陆,用例开始;

     进行选课;

     保存信息到数据库;

(3)查询课程事件流

     学生登陆,用例开始;

     查询已选课程信息;

3、画出系统的用例图。

五、实验小结:

     

了解用例图的画法

实验及作业四

                          ——用例分析综合练习

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

1、根据如下给定的系统需求,完成系统的需求分析。

需求:

   1) 管理员通过系统管理界面进入。

   2) 建立本学期要开的课程。

   3) 保存课程信息,且可改动和删除。

   4) 学生通过客户机浏览器根据学号和密码

      进入选课界面。

   5) 学生可以有三种操作:

         查询己选课程;

         选课;

         付费。

       通过业务层,这些操作结果存入数据库。

提示:实验过程应包括:1、系统的用户分析;2、网上选课系统事件流(包括添加、删除选课事件流,学生选课事件流,查询课程事件流等);3、画出系统的用例图。

四、实验过程及结果

管理员:需要登录,添加删除选课信息

学生:需要登录,查询,选课,付费

1添加、删除选课事件流:

登录

添加/删除

保存退出

2学生选课事件流:

登录

选课

付费

退出

3查询课程事件流:

登录

查询

退出

管理员用例图

学生用例图

五、实验小结:

      熟悉用例图的绘画

实验及作业五

                          ——建立概念模型

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据概念模型创建的方法,根据实验三(图书馆管理系统)的用例图,创建该系统的概念模型,并添加相应的关联。

提示:实验过程应包括:1、找出系统的概念;2、画出系统的概念类;3、在概念类中添加类之间的关联关系。

四、实验过程及结果

五、实验小结:

      学会寻找概念 和 如何关联。

实验及作业六

                          ——系统行为分析

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据实验五得出的概念模型,进行系统行为的分析。

提示:实验过程应包括:1、画出系统的顺序图;2、画出系统操作类;3、给出系统的契约。

四、实验过程及结果

五、实验小结:

    初步学习契约的画法

     

实验及作业七

                          ——类职责分配

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据实验五、六得出的概念模型、系统操作、契约,进行类职责的分配。

提示:实验过程应包括:1、请考虑系统界面;2、得出系统的真实用例;3、对系统类中的每个操作,根据契约中的后置条件,画出相应的协作图。

四、实验过程及结果

五、实验小结:

     

    学习协作图的绘画

实验及作业八

                          ——系统类图

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据实验五、六、七得出的概念模型、交互图,给出系统的类图。

提示:实验过程应包括:1、请给出系统中存在的类,并说明每个类的用途(在类图中加注释);2、添加类的关系。

四、实验过程及结果

Loan:罚款缴费

Borrower:借书者

Reservation:预定图书类

Title:图书信息类

Item:某种图书数量

五、实验小结:

     

    学习类图的绘画

实验及作业九

                          ——系统状态图

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据系统的类图,找出具有多状态的类,画出状态图。

四、实验过程及结果

五、实验小结:

     

    了解状态图的绘画

实验及作业十

                          ——系统组件图、部署图

一、实验目的

1、了解面向对象的基本概念

2、熟悉面向对象的分析、设计过程

3、了解基于UML的面向对象分析设计过程

二、实验设备与环境

装有Visio、RationalRose、StarUML的计算机。

三、实验内容

请根据之前实验结果,画出系统的组件图、部署图。

四、实验过程及结果


五、实验小结:

      学习系统组件图和部署图的绘画

 

第二篇:例解基于UML的面向对象分析与设计

例解基于UML的面向对象分析与设计

20##-11-08 11:16 by EricZhang(T2噬菌体), 8762 visits, 网摘, 收藏, 编辑

摘要

      本文以实例的方式,展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸,所以将不会过多阐述,而将重点放在应用过程上。本文的目的是通过一个完整的实例,展现基于UML的OOA&D过程的一个简化模式,帮助朋友们更好的认识UML在OOA&D中起的作用。

前言

      经常听到有朋友抱怨,说学了UML不知该怎么用,或者画了UML却觉得没什么作用。其实,就UML本身来说,它只是一种交流工具,它作为一种标准化交流符号,在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外,UML也可以看做是OO思想的一种表现形式,可以说“OO是神,而UML是型”。所以,想用好UML,扎实的OO思想基础是必不可少的。然而,在UML应用到开发过程中时,还是有一定的模式可以遵循的。(注意,是模式而不是教条,我下面给出的流程只是一个启发式过程,而不是说一定要遵循这个流程。)下面,我们通过一个CMS系统的分析设计实例,看看如何将UML应用到实际的开发中。

从需求到业务用例图

      OOA&D的第一步,就是了解用户需求,并将其转换为业务用例图。我们的CMS系统需求非常简单,大致课做如下描述:这个系统主要用来发布新闻,管理员只需要一个,登录后可以在后台发布新闻。任何人可以浏览新闻,浏览者可以注册成为系统会员,注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理,如修改、删除等。
      通过以上需求描述,我们画出如下的业务用例图:
      这里要注意三点:
      1.业务用例是仅从系统业务角度关注的用例,而不是具体系统的用例。它描述的是该实现什么业务,而不是系统该提供什么操作。例如,在实际系统中,登录肯定要作为一个用例,但是这是软件系统中的操作,而用户所关注的业务是不包含登录的。
      2.业务用例仅包含客户感兴趣的内容。
      3.业务用例所有的用例名应该让客户能看懂,如果某个用例的名字客户看不懂什么意思,它也许就不适合作为业务用例。

从业务用例图到活动图

      完成了业务用例图后,我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中,用户可能会进行的操作序列。活动图有个很重要的使命:从业务用例分析出系统用例。例如,下面是“新闻管理”的活动图:
      可以看到,一个“新闻管理”这个业务用例,分解出N多系统操作。这里要特别注意这些操作,其中很多“活动”都很可能是一个系统用例(当然,不是每个都是)。例如,由这个活动图可以看出,系统中至少要包含以下备选系统用例:登录、注销登录、查看新闻列表、修改新闻、删除新闻。
      这样,将每个业务用例都绘制出相应的活动图,再将其中的“活动”整合,就得出所有备选系统用例。

从活动图到系统用例图

      找出所有的备选系统用例后,我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个,筛选就是将不符合系统用例条件的备选用例去掉。
一个系统用例应该是实际使用系统的用户所进行的一个操作,例如,“查看新闻列表”就不能算一个系统用例,因为他只是某系统用例的一个序列项。
      最终我们得出的系统用例图如下:

从系统用例图到用例规约

      得出系统用例图后,我们应该对每一个系统用例给出用例规约。关于用例规约,没有一个通用的格式,大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。
      下面给出“登录”这个系统用例的一个规约:

业务领域类图

      完成了上面几步,下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点:
      1.系统中有哪些实体。
      2.这些实体能做什么操作。
      3.实体间的关系。
      这里要特别强调:这里的实体不是Actor,而是Actor使用系统时使用的所调用的实体,是处在系统边界之内的实体。例如,管理员就没有作为一个实体出现在这里,因为管理员处在系统边界之外,它所有的工作都可以通过调用这三个类的方法完成。并且,这里的注册会员实体也不是刚才用例图中注册会员这个Actor,而是作为一个系统内的业务实体,供Actor们使用的。例如,其中的注册功能是给注册会员这个Actor使用,而移除则是给管理员这个Actor使用的。
      理解以上这段话非常重要,我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
      大家可能还注意到,我们这里没有给出每个实体的属性。其实,在领域分析阶段,实体的属性并不重要,重要的是找出实体的操作。 

实现类图

      以上这几步,就是分析的过程。而下面的步骤就是设计了。
      设计没有分析那么好描述,因为分析是“客户面”,它只关心系统本身的功能和业务,而不关心任何和计算机有关的东西。但是,设计和平台、语言、开发模型等内容关系紧密,因而很难找出一个一致的过程。但是,一般在设计过程中实现类图是要绘制的。
      实现类图和领域类图不一样,它描述的是真正系统的静态结构,是和最后的代码完全一致的。因此,它和平台关系密切,必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此,实现类图是很复杂的,而且是平台技术有关的。所以,我在这里不可能给出一个准确的实现类图,不过为了描述,我还是给出一个简化了的实现类图,当然,它是不准确的,而只是从形式上给出实现类图的样子。
      我们假设这个系统建构于.NET 3.5平台上,并且使用ASP.NET MVC作为表示层,整体使用三层架构。那么,用户模块体系的实现类图大体是这样子(不准确):

序列图

      有了静态结构,我们还要给出动态结构,这样,才能看清系统间的类是如何交互的,从而有效帮助程序员进行编码工作。

      上图给出的是用户登录的序列图。首先注册会员作为Actor,调用UserController的Login方法启动序列,然后序列按图示步骤执行。其中UserServices作为业务组件,首先调用数据访问组件的GetByName确定用户是否存在,如果存在,再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。
      要注意,序列图在实际中是很多的,几乎每个类方法都配有相应的序列图。

最后的步骤

      在完成了上面的过程后,就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。

总结

      本文简要给出了使用UML进行OOA&D的过程。当然,由于示例较小,而且本人水平有限,所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程,随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用,让朋友们大致了解UML的使用流程。至于实际的分析设计,还需要深入的学习和实践的积累。

正确认识使用UML中的类图——辨析类图的两种存在形式

20##-10-26 12:04 by EricZhang(T2噬菌体), 3733 visits, 网摘, 收藏, 编辑

摘要
      本文通过对一个“学生选课系统”示例的简要分析与设计,说明UML图之一类图的两种作用及存在形式,以期借此澄清有些朋友可能对类图存在的误解与困惑。

前言
      在OOA与OOD大行其道的今天,UML在系统分析与设计中得到了广泛的采用。而在UML的9种图中,类图是最重要也是使用最普遍的图之一。但是,在与一些朋友,特别是初学者的聊天当中,我发现很多朋友对类图的作用及使用方法存在一定的误解和困惑。于是我写下这篇文章,希望本文能在一定程度上帮助这些朋友更好的认识和使用类图。当然,由于我对UML的认识并不很深刻,所以在文章中有错误和疏漏之处,恳请大家批评指正。

A vs D
      要想正确认识与使用类图,我们首先要正确认识两个概念——“A”和“D”。
      A是Analyse的缩写,即我们所说的“分析”;而D是Design的缩写,即“设计”。一般来说,一个系统在编码前,都要经过分析与设计两个步骤。而对这两个概念认识的模糊不清,正是导致很多朋友无法正确使用类图的原因。
      分析,我对其的解释是:根据用户的需求,做出一系列与业务领域相关而和计算机技术无关的整理与识别。
      很多朋友有个错误的认识,认为软件开发工作一定要由懂计算机的人完成,不懂计算机的人怎么能进行软件开发呢?当然,对于设计和编码等工作,当然是这样,但是唯有“分析”这一工作,可以由完全不懂计算机的人来进行,甚至从某种程度上说,不懂计算机的人更适合做软件分析师的工作。因为想要把分析做好,一定要仅与业务相关,而抛开具体技术。一个满脑子计算机技术的程序员去做分析时,很容易想到编码、实现、平台、数据库设计等具体细节,这种思维形式恰恰成为做好分析的最大障碍。此为误解一:只有懂计算机技术的人才能做系统分析师。我现在所在的研究所(北京航空航天大学计算机学院软件工程研究所)曾经接过一个日本项目,当时日方那边派来一个系统分析师对计算机就完全是外行,而是一个领域专家,但是他很好的完成了系统分析的工作。
      另外一个误解就是UML图,特别是类图,就是给开发人员用的。很多人觉得UML是计算机业内专业语言,不懂计算机的怎么能用它呢?用了做什么呢?但是很多不懂计算机的系统分析师在进行分析工作时,也在使用UML图,而类图就是其中一种。一般情况下,分析师在进行分析时,确实会绘制一套类图。但是,它所画的类图不管是从视角还是作用,与设计师所做的类图是不同的,具体将在下面介绍。此为误解二:只有计算机人士才使用UML图。
      分析说完了,下面说设计。与分析不同,我对设计的解释是:根据分析材料与技术平台,确定软件系统的架构结构、编码方式及一切与具体技术有关的宏观问题。
      这里可以看到,设计与分析不同,它必须由计算机方面的人来完成,因为它和具体技术是息息相关的。而且,设计师在进行设计时,也会绘制一套类图。
      到这里,我们明确了,原来软件在分析与设计两个阶段各自会绘制一套类图,而且是由分析师和设计师两个不同的角色绘制的。那么这两套类图有什么异同呢?下面将解释这个问题。

领域类图 vs 实现类图
      上文提到,在软件分析与设计过程中,会由两种角色产生两套类图。一般情况下,分析师绘制的类图叫做“领域类图”,而设计师绘制的类图叫做“实现类图”。这里要声明,这两个名词是我的习惯性叫法,并不是大家都认同的通用叫法。下面,我对这两种类图给出我的定义:
      领域类图:产生于分析阶段,由系统分析师绘制,主要作用是描述业务实体的静态结构,包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。
      虽然这个类图也叫“类图”,但是说实话,它和编程中的“类”实在是没啥关系,因为最后的系统中可能根本没有类和它们对应,而且很多最后系统中的类如控制类和界面类这套类图中也没有。也就是说这套图和具体技术无关,也不是画给程序员看的,它只是表达业务领域中的一个静态结构。下面给个例子:

      这是一个选课系统的简单领域分析类图。可以看到,主要实体有教师、学生、课程和开课安排。每个实体标注了其在业务上具有的属性和方法。而且图中还标明了实体间的关系。
      但是,最终系统中可能没有一个学生类和其对应。因为最终系统中有哪些类、各个类有什么属性、方法依赖于所选择的平台和架构。例如,如果使用了Struts2,则会存在很多Action类,而使用了ASP.NET MVC,则会有很多Controller类等,所以,领域类图只于业务有关,和具体实现及编码等计算机技术无关。
      下面该说说实现类图了:
      实现类图:产生于设计阶段,由系统设计师绘制,其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。
      就像上面的领域类图,如果你把它交给程序员编码,我想程序员会疯掉,因为它没有提供任何编码的依据。假如我们使用的是.NET平台分层架构,并使用ASP.NET MVC,则设计师应该在实现类图中绘制出所有的实体类、数据访问类、业务逻辑类和界面类,界面类又分为视图类、控制器类等等,还要表示出IoC和Aop等信息,并明确指出各个类的属性、方法,不能有遗漏,因为最终程序员实现程序的依据就是实现类图。

总结
      最后,我们总结一下本文的要点:
      1.软件分析与设计是编码前的两个阶段,其中分析仅与业务有关,而与技术无关。设计以分析为基础,主要与具体技术有关。
      2.分析阶段由分析师绘制领域类图,设计阶段由设计师绘制实现类图。
      3.领域类图表示系统的静态领域结构,其中的类不与最终程序中的类对应;设计类图表示系统的技术架构,是程序员的编码依据,其中的类与系统中的类对应。
      4.领域类图中类的属性与操作仅关注与业务相关的部分,实现类图中的属性与操作要包括最终需要实现的全部方法与操作。

相关推荐