面向对象的分析与uml

面向对象的分析与uml（精选9篇）

面向对象的分析与uml 篇1

实验二

基于UML面向对象需求分析的通讯录管理系统一、实验目的：

1、熟悉UML建模工具Visio2007

2、熟悉活动图

3、熟悉顺序图

二、所用软件：

Microsoft Visio2007

三、实验分析：

时代在发展，人们的交际圈越来越广泛，人际关系的记录也越来越多，所以我就编写了一个通讯录管理系统，此系统由JAVA语言写成，主要功能有：

1、添加联系人信息

2、模糊查找了联系人（按姓名、按号码）

3、修改联系人信息

4、删除联系人信息

通过这个系统，正快速准确的对联系人信息进行各种操作。

还有此系统运用的数据库为SQL-server数据库，各种联系人信心都储存在其中，用户输入数据，系统通过数据库数据的验证，来完成各种多通讯录的操作。

四、实验步骤

1、活动图 Customersystem写入数据库进入主页面数据库中查找号码选择业务显示查询结果号码不存在添加联系人输入数据数据库中查找姓名按号码输入号码查找联系人显示查询结果姓名不存在按姓名输入姓名数据库中查找姓名修改联系人输入联系人姓名姓名不存在修改联系人信息提取联系人信息写入数据库删除联系人输入联系人姓名数据库中查找姓名姓名不存在退出系统从数据库删除联系人信息

2、顺序图

用户选择业务增加查找修改删除顶层包：用户选择添加返回查找返回修改返回删除返回

五、心得体会

这次试验为基于UML面向对象需求分析的通讯录管理系统，试验中主要是对通讯录管理系统的进行需求分析和画出其活动图和顺序图。通过这次试验，让我对UML的顺序图和活动图有了更深一步的理解，在对系统活动流程以及系统对象之间消息发送时间顺序等都更加熟悉了。

面向对象的分析与uml 篇2

关键词：UML,面向对象,分析,设计,案例教学

UML面向对象分析与设计是软件技术专业开设的一门重要的专业基础课程,该课程的知识主要分为三大部分,分别是UML基础、面向对象的设计原则和面向对象的设计模式。统一建模语言UML贯穿与软件开发过程的不同阶段,为软件开发人员建立整个系统的模型,告诉开发人员“做什么”和“怎么做”。在软件开发的不同阶段UML的侧重点又有不同,在需求分析阶段,系统分析师可以用UML来描述用户的业务模型,从而给系统设计师做进一步的设计;在系统设计阶段,系统架构师或系统设计师可以用UML来描述架构模型以便让程序设计师进行实现设计;在详细设计阶段程序设计师可以用UML来描述具体对象模型给编程者来具体实现。由此可以看出UML是用来清晰地描述模型的,它的作用是将计算机软件开发技术和面向对象的设计思想联合起来,对软件生产工业产生了极大的影响,因此,“统一建模语言UML”课程的重要性显而易见[1]。

面向对象设计原则是设计模式的灵魂,它描述了对象设计和职责分配的基本原则。也就是说,如何把系统数据抽象成对象,如何决定一个系统有多少对象,每个对象都包括什么职责。如单一责任原则、开放—封闭原则和接口隔离原则等等。

面向对象设计模式,是在面向对象设计中针对重复发生的问题的描述和解决办法的统称。如适配器模式、装饰模式和策略模式等等。

综上所述,该课程的主要内容涵盖了软件开发过程中的各个阶段,以及面向对象设计原则和处理常见问题的方法,对软件技术专业学生的重要性是极其重要的。

1 教学现状及存在的问题

案例教学(Case Method)是由美国哈佛法学院前院长克里斯托弗.哥伦布.朗代尔(C.C.Langdell)于1870年首创,后经哈佛企管研究所所长郑汉姆(W.B.Doham)推广,并从美国迅速传播到世界许多地方,被认为是代表未来教育方向的一种成功教育方法。20世纪80年代,案例教学引入我国。现在,案例教学已经扩展到很多课程。

所谓案例教学,是一种通过模拟或者重现现实生活中的一些场景,让学生把自己纳入案例场景,通过讨论或者研讨来进行学习的一种教学方法,主要用在管理学、法学等学科。教学中既可以通过分析、比较,研究各种各样的成功的和失败的管理经验,从中抽象出某些一般性的管理结论或管理原理,也可以让学生通过自己的思考或者他人的思考来拓宽自己的视野,从而丰富自己的知识[2]。

案例教学的过程中,教师的角色应当有所转变,从以前的老师讲、学员听到现在的组织者、引导者和激励者。

1.1 案例教学内容和方式

1)采用分组的形式,让学生自由组合,并共同推举一个组长。教师提出案例场景,鼓励同一个组内的学生思考、讨论,最后由组长提交结果。

2)各组长或组员对于自己组内形成的结果进行阐述,各组之间可以相互质疑其结果或直接反驳。

3)对各组的结果进行评议,给优秀的组全体成员加分。这样使枯燥乏味的内容变得生动活泼,又促进学生的团队协作能力的提高以及增强其集体荣誉感。

1.2 UML面向对象分析与设计的案例教学中也存在的问题

1)案例的选取不当。如果案例的选取不当,直接影响了学生对课程知识的掌握和后续知识的学习(面向对象的设计原则和模式)、也影响了课程的教学目标和专业的培养目标。

2)沟通协作不够。案例教学更加强调教师与学生的沟通和协作,同时也强调小组内学生之间的沟通和协作。如果师生之间沟通不到位,容易造成学生对案例的理解不到位,分析出的结论与期望值也就相差很大;如果小组成员之间沟通协作不力,就会产生分化,有的同学积极响应老师提出的问题,而有的确出现依靠他人的思想,自己不去积极思考。

3)案例不适合特定专业。各专业有各自的培养计划和培养目标,但是由于授课教师的专业限制,不可能针对每个专业都制定不同的教学案例。例如:Web应用开发专业、移动应用专业都有开设该课程,但授课教师却不能针对两个专业分别制定案例。如果针对各专业制定不同的教学案例,就能更符合各专业的培养方向和培养目标。

2 解决方案

为了提高教学效果和学生的学习效果,针对上述三个问题,结合课程特点和各专业培养方案以及培养目标,现提出以下解决方案。

1)对于案例的选取,应当将课程特点、学生的知识背景以及专业相结合,选择的案例不能太简单,让学生觉得索然无味,提不起学生学习的兴趣;也不能太难,由于建立模型是依赖于建模者对被建模的业务领域的了解的,而授课的对象是大二学生,他们从小学上到大学,所学又为软件专业,对其他行业(商业、金融和外贸等等)业务知识的掌握基本为零,并且没有软件开发经验,所以选取的案例应当结合学生的知识背景,是学生比较熟知的,否则在授课中又要讲解领域知识,这样授课难度就可想而知了,也不能达到教学目标和学习效果。

2)对于沟通协作问题,首先是老师和学生的沟通,授课老师在将需要建模的案例场景展示给学生的时候方式不应该太单调。例如只是采用大量的文字描述一个案例场景,这样学生容易觉得枯燥。如果采用卡片、动画或者现场模拟的方式将案例场景展示学生,这样学生会觉得上课是一件轻松愉快的事情,而不是枯燥和痛苦,也会让学生对该课程产生浓厚的兴趣。让学生在对业务处理流程有一定的了解的情况下再去思考、分析和讨论,可能会取得更好的效果。但是这里又存在两个问题,一是如果采用卡片或者动画来展示案例场景,需要多媒体、图形图像等专业老师给予支持,并且需要大量的时间去准备;二是如果让学生进行案例场景的现场展示,有时候会遇到有的学生不愿意配合的问题。其次是小组内部学生之间的沟通,如果出现问题,授课老师应当积极的了解其情况,加强思想教育工作,使之积极的融入到小组的讨论和分析中去。

3)对于案例不适合特定专业的问题,可以针对各专业建立教研室,教研室的教师根据课程内容和要求,以及专业培养目标共同商议案例的选取,使之既能达到课程要求,又能贴近其所学专业,不能让学生觉得学了这些东西好像和我所学的专业都没有关系。例如:Web应用开发专业,选择的案例最好与其Web应用开发有关;移动应用所选择的案例最好能和移动应用的开发有关。

3 UML案例教学流程

3.1 案例的选择

前面已有论述,案例的选择应当集合学生的知识背景和专业背景,对于学生来说是比较熟悉的,所以在就选择了网上图书管理系统,该案例比较有实用性,难易适中,也贴近学生的现实生活。如果在后面授课过程中出现学生对该领域的业务知识不了解的情况,也能就近取材,通过自己去借书、还书或者扮演图书馆管理员也能充分掌握该领域的工作流程,这样就便于学生将所学理论和现实应用相结合,也提高了学生的学习兴趣。但是该案例较适合Web应用开发专业、对于移动应用就不太适合,前面已论述其原因。

3.2 案例教学的实施

以前在案例教学中缺乏经验,从一开始就拿出案例,对案例进行分析讲解的过程中,需要哪些知识再讲哪些知识,最后学生听不明白讲了些什么,也不明白哪些是重点。所以,案例教学实施之前,有必要用一定的时间采用传统的授课方法对知识点进行讲解,在这个过程中最好通过其他例子来说明问题,尽量不要使用案例。在学生对基本知识点有了一定了解和掌握之后,再提出案例。

下面是案例教学实施的几个步骤:

1)场景介绍:用较短的时间对案例场景进行介绍,可以是文字介绍、现场模拟或者动画演示。例如,讲活动图对“读者借书”的业务流程进行建模的时候,可以先让学生进行现场模拟,或者到图书馆去亲身体验,或者采用动画的形式将案例场景展示给学生,从而先了解业务流程。

2)小组讨论:学生对案例场景了解了以后,告诉小组讨论的方式方法,就以小组为单位,组内相互讨论,在给定时间内得出结论。因为这是一项复杂的任务,也是软件工程中的必然一个环节,需要团队的合作,单凭某一个人来独立完成,必然会造成遗漏,这样既培养了学生发现问题,解决问题的能力,同时,也培养了学生团队合作意识,锻炼了其团队合作能力。(下转第7754页)(上接第7750页)

3)小组长讲述各自的结论:学生完成给定的任务以后,首先让小组长阐述、展示所代表组的结论,并且说明产生结论的原因。然后,看学生对其他组的结论是否有疑义,或者对其他组的结论进行反驳,从而了解学生对基本知识和案例场景的理解和掌握程度。同时,这个讨论的过程中,能让学生加深对所学知识的理解和掌握,也能体会到所学知识在实际软件开发过程中的应用。

4)总结点评:在第三步完成以后,对学生的结论进行总结点评,也可以和学生一起讨论,得出最合适结论,以帮助学生对所学知识的理解和应用。然后,为各组现场评分,以激励学生学习的热情和兴趣。

3.3 实验

实验也是案例教学的重要一环,主要是让学生掌握建模工具的使用方法,也是及时了解学生对课程内容掌握情况的手段。这需要学生充分发挥主观能动性,以锻炼其分析问题,解决问题的能力。在实验室内,老师应少讲,主要是给予提示,对于个别问题个别讲解,对于普遍性问题集中讲解。可以先选取案例中的小部分,进行讲解和演示,让学生在下边操作,以掌握工具的使用方法。然后再让学生以小组为单位,进行集中讨论,最后以小组为单位提交实验成果。

4 结束语

“UML面向对象分析与设计”教学的最终目的是要让学生学会使用UML工具进行软件设计及软件开发,培养学生的实际动手能力、发现问题和解决问题的能力。所以在案例的选取方面要精,要有代表性和典型性。

要让学生通过一个案例的学习能掌握基本知识,达到课程教学目的并且能够举一反三,而且能应用到实际的软件开发中去,需要对案例的精心选取、准备和认真授课,也需要不断地对案例教学的授课方法进行总结和探索,通过实践来检验授课方式和方法的教学效果。

参考文献

面向对象的分析与uml 篇3

1.引言

面向对象分析与设计方法学，代替传统的面向过程的结构化分析与设计方法，已逐渐成为现代软件工程领域中的主流方法。特别是随着90年代末统一建模语言UML的广泛应用，结合UML的面向对象分析与设计方法在国内外学术界和产业界普遍受到重视，成为软件工程三个要素之一。

面向对象分析与设计是软件工程专业开设的一门重要的专业基础课程。该课程主要分为UML基础，面向对象的设计原则和面向对象的设计模式。而统一建模语言UML贯穿于软件开发过程的不同阶段，为软件开发人员建立整个系统的模型 告诉开发人员做什么和怎么做。在软件开发的不同阶段的侧重点又有不同：在需求分析阶段，系统分析师可以用UML来描述用户的业务模型，从而给系统设计师做进一步的设计。在系统设计阶段，系统架构师或系统设计师可以用UML来描述架构模型以便让程序设计师进行实现设计，在详细设计阶段程序设计师可以用UML来描述具体对象模型给编程者来具体实现。由此可以看出UML是用来清晰地描述模型的，它的作用是将计算机软件开发技术和面向对象的设计思想联合起来，对软件生产工业产生了极大的影响。因此，统一建模语言UML课程的重要性显而易见。面向对象设计原则是设计模式的灵魂，它描述了对象设计和职责分配的基本原则。面向对象设计模式是在面向对象设计中针对重复发生的问题的描述和解决办法的统称。综上所述，该课程的主要内容涵盖了软件开发过程中的各个阶段，以及面向对象设计原则和处理常见问题的方法，对软件工程专业的学生是极其重要的。

2.“讲授—案例—互动—实践—考评”五段课堂教学新模式

该教学模式通过“讲授”让学生系统掌握整个知识体系，运用“案例”激起好奇心和引发应用和创新的动力，引导学生自主学习“扩展”知识面和建构自己的新知识，在项目“实践”中综合应用强化创造，最后通过综合“考评”合理评定出学生的成绩。加强工程化的教学内容建设，在课堂教学系统地传授知识的基础上，注重工程性的课程案例和循序渐进的课程项目实践的有机结合，为学生自主性和研究性的扩展学习搭建优良的网络教学环境。

1）“系统讲授”让学生系统地掌握整个知识体系。教学内容强调工程化，适应软件开发技术发展快的特点，不断跟踪国际最新标准和最新技术，及时更新教学内容，反映基于构件、模型驱动和面向服务等现代软件开发技术的最新发展趋势。课堂教学采用启发式教学，指导学生阅读经典学术论文并进行综述、评介和讨论，撰写读书笔记，培养学生阅读、概括、评价、撰写和表达等基本科研能力。

2）“案例教学”让学生置身于模拟的真实环境中，學习如何进行具体实践和问题解决，引发学生研究性学习和创新的动力。案例分为基础-扩展-提高等3个阶段。基础阶段针对UML和OOAD方法等基本内容，着重于单项练习和简单系统设计；扩展阶段着重于架构设计和设计模式、框架设计和复用等现代技术，将基础阶段的简单系统扩展为基于构件和框架复用、支持持久框架的Web系统；提高阶段则结合专题讲座，了解最新技术发展趋势。

3）“网络加自主的互动方式” 创造多元化的教学环境，将课堂上的教学与课堂外的师生互动无缝的进行集成。当今互联网环境为我们提供了便捷、丰富的交互手段，借助其以整合不同的教学要素来提升整体的教学效果，这也符合以学生为中心的教学理念。基于以上的认识，在教学过程中，可以依托网络教学平台提供丰富的互动方式，在网络上共享学习资源、在线讨论、即时沟通，达到了充分调动学生学习热情的目的。在交互的过程中，通过开放性的问题驱动学生自主选择感兴趣的方向做深入的学习和研究，充分地释放学生的个性和创造力。整体而言，课下教学组织在网络加自主的互动方式支持下有力的支持并拓展了传统的课堂教学，不仅对教学效果有明显的提升，而且对培养学生的主动性、协作能力乃至钻研精神和创新意识都有着潜在的不可忽视的帮助。

4） “项目实践”培养学生运用知识、解决问题和团作协作的能力。学生参照课程案例、文档模板、实践指南和参考资料，结合有助教指导的课内上机、课外自由上机和有助教在线指导的网上辅导教室等多种教学手段，以3-5人的小组为单位的团队方式完成一个课程项目，项目题目和需求是在教师指导下由学生自主确定，以鼓励创新。项目进度和课堂教学及课程案例基本同步，循序渐进。

5）“综合考评”从知识、创新、应用等多方面进行评价，根据每节课、每次作业、项目的每阶段评审和考试来综合考核成绩。成绩一般由课堂表现、每周作业、读书笔记、项目阶段审核和项目答辩、期末考试等部分组成。

本课程充分利用信息技术，课堂教学采用多媒体信息技术手段，基于Web的网络教学平台提供论坛、答疑、作业、问卷调查等课程互动功能，网上辅导可提供无时空限制的即时学习、小组讨论和辅导帮助等功能。

课堂教学实施方面，研究启发式、交互式等多种形式的教学方式。建立网络教学平台，同学生充分沟通，不断学习、改革和实践。摈弃了过去只注重书本内容的教授，引进了实际工作的案例。大量的案例分析，促使学生从实际出发，从现实的角度看待问题、分析问题。对项目工程的亲身实践，使得学生把所学转化为所用，并在所用中不断充实。

3.教学内容顺序及对应的学时安排如表1

除本课程的课程项目实践外，还可鼓励学生参加其他实践活动，如大学生学生创新项目的申报，可进一步强化5段式教学新模式中的 “实践”，培养学生解决实际问题的能力和创新能力。

4.课程的重点、难点及解决思路

本课程的设计符合UML最新国际标准，覆盖了国际软件工程知识体系的相关知识点，分析和设计并重，原理和案例兼顾。课程内容的重点主要有UML可视化建模技术、领域建模和面向对象系统分析方法、面向对象系统设计方法、设计模式、框架设计和复用等方面。课程内容的难点主要有对UML的深入理解和运用、领域对象识别和关系分析、架构因素分析和架构设计、分析类与设计元素的区别和联系、设计模式的深入理解和运用等。解决办法主要是通过分阶段的综合性课程案例、循序渐进的工程性课程项目实践等加强实践性教学环节，让学生在实践中学习和领悟。 另外，本课程由于工程性和实践性很强、相关技术发展快、涉及面广，在课程体系建设、教学建设和实施等方面都存在挑战。

5.实践教学的设计思想

循序渐进、手段多样的工程性课程项目实践。学生参照课程案例、文档模板、实践指南和参考资料，结合有助教指导的课内上机、课外自由上机和有助教在线指导的网上辅导教室等多种教学手段，以3-5人的小组为单位的团队方式完成一个课程项目，鼓励创新。进度与课堂教学和课程案例基本同步，循序渐进。

进一步搭建网络教学平台，将部分学生的优秀作品在平台中展示。学生利用课外时间以团队方式完成多个实际软件项目的开发，实验进度和课堂教学基本同步。项目题目和需求是在教师指导下由学生自主确定，以鼓励创新。通过实践，学生能把所学转化为所用，并在所用中不断充实，同时也加强了软件工程规范的训练，培养了学生的团队精神和沟通能力。

6.结束语

通过本课程的教学，使学生掌握面向对象技术原理、面向对象的软件系统分析和设计方法、软件设计模式等，能结合UML和工具进行面向对象的软件系统分析和设计，并具有软件开发实践和项目组织的初步经验、创新意识、团队精神。

面向对象的分析与uml 篇4

第一章

1、什么是分析与设计？

1、分析强调对问题和需求的调查研究

2、设计强调的是满足需求的概念上的解决方案

2、什么是面向对象分析与设计？

1、在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）

2、在面对对象设计过程中，强调的是定义软件对象以及它们如何协作以实现需求。

3、简单示例：

1、定义用例（use case）

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例。

2、定义领域模型（domain model）

面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。（也被称为概念领域模型—conceptual object model）

3、定义交互图

关注的是软件对象的定义—它们的职责和协作。顺序图（sequence diagram）是描述协作的常见方法。它展示对象之间的信息流，和由消息引起的方法调用。

4、定义设计类图

除了在交互图中显示对象协作的动态视图外，还可以用设计类图（design class diagram）来有效的表示类定义的静态视图。这样可以描述类的属性和方法。

与领域模型表示的是真实世界的类，设计类图表示的是软件类

要注意的是，尽管设计类图不同于领域模型，但是其中的某些类名和内容还是相似的。

第二章

1、什么是UML？

统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

UML表示法的基础是UML元模型，它描述建模元素的语义，UML元模型对模型驱动架构（Model Driven Architecture, MDA）CASE工具供应商具有影响。开发者并不需要对其进行学习。

2、三种UML应用方式

1、UML作为草图—非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的负责部分。

2、UML作为蓝图—相对详细的设计图。用于：①逆向工程；②代码生成。

3、UML作为编程语言—用UML完成软件系统可执行规格说明。

3、什么是UP？

软件开发过程（software development process）描述了构造、部署以及维护软件的方式。统一过程（UP）已经成为一种流行的构造面向对象系统的迭代软件开发过程。

4、迭代（iterative）、进化（evolutionary）和敏捷（agile）

1、迭代开发是UP和大多数其他现代方法中的关键实践。每次迭代都具有各自的需求分析、设计、实现和测试活动。

2、迭代进化开发

小步骤、快速反馈和调整是迭代开发的重要思想。短时迭代为上。迭代的一个关键时光可见

第 1 页

2013-3-31 OOAD总复习

思想是时间定量，或者时长固定。

3、瀑布生命周期

在瀑布（或顺序）生命周期过程中，试图在编程之前（详细）定义所有或大部分需求。而且通常于编程之前创建出完整的设计（或模型集）。

4、什么是敏捷模型？

1、采用敏捷方法并不意味着不进行任何建模，这是错误理解。

2、建模和模型的目的主要用于理解和沟通，而不是构建文档

3、不要对所有或大多数软件建模或者应用UML。

4、尽可能使用最简单的工具。

5、UP所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。

6、UP的四个阶段：初始（inc）、细化（elaboration）、构造（construction）、移交（transition）

第五章

1、进化式需求

1、需求就是系统（广义的说法是项目）必须提供的能力和必须遵从的条件。

2、需求分析的最大挑战是寻找、沟通和记住（通常是指记录）什么事真正需要的，并能够清楚的讲解给客户和开发团队的成员。

3、需求变更是不可避免的，因此有效的管理和关键

4、进化式需求VS瀑布式需求：„„

5、需求按照“FURPS+”模型进行分类：

1、功能性：特性、功能、安全

2、可用性：人性化因素、帮助、文档

3、可靠性：故障频率、可恢复性、可预测性

4、性能：响应时间、吞吐量、准确性、有效性、资源利用率

5、可支持性：适应性、可维护性、国际化、可配置性

6、一些次要因素：实现、接口、操作、包装、授权

6、UP制品如何组织需求：

1、用例模型：一组使用系统的典型场景。

2、补充性规格说明：基本上是用例之外的所有内容。

3、词汇表：词汇表以最简单的形式定义重要的术语。

4、设想：概括了高阶需求，项目的业务案例。

5、业务规划（领域规划）：通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或者业务所要求的，并且许多应用应该遵从这些规则。

第六章

1、用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。

2、用例常用的三种形式：

1、摘要（brief）：简洁的一段式概要，主要用于主成功场景。

2、非正式（casual）：非正式的段落格式。

3、详述（fully-dressed）：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和保证成功。

3、参与者（actor）、场景（scenario）、用例（use-case）

1、参与者是某些具有行为的事物，可以是人、计算机系统或者组织。

2、场景是参与者与系统之间的一系列特定的活动和交互，也称为用例实例

时光可见

第 2 页

2013-3-31 OOAD总复习

3、用例是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

4、准则：如何发现用例？

1、选择系统边界

2、辨别主要参与者

3、辨别每个参与者的目标

4、定义用例以满足目标

5、准则：什么样的测试有助于发现有用的用例？

1、老板测试（the boss test）：老板的一问一答

2、EBP测试(the ERP test)基本业务过程

3、规模测试(the size test)

6、示范：应用上述测试

1、就供应者合同进行协商：

比ERP更广泛，用时更长。更适合作为业务用例，而非系统用例。

2、处理退货

能够通过老板测试。看上去与ERP类似。规模适合3、登陆

如果你一整天都在登陆，老板不会满意

4、在游戏板上移动棋子

单一步骤，不能通过规模测试

第八章

1、迭代1的需求和重点：OOA/D技术的核心

2、过程：初始（inception）和细化（elaboration）

初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。

细化是一般项目中最初的一些列迭代，其中包括：

1、对核心、有风险的软件架构进行编程和测试

2、发现并稳定需求的主要成分

3、规避主要风险

第九章

1、领域模型是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念膜性能高、领域对象模型和分析对象模型。

2、应用UML表示法，领域模型被描述为一组没有定义操作（方法的特征标记）的类图（class diagram）：

1、领域对象或者概念类

2、概念类之间的关联

3、概念类的属性

3、准则：如何创建领域模型？

1、寻找概念类

2、将其绘制成UML类图中的类

3、添加关联和属性

4、准则：如何找到概念类？

时光可见

第 3 页

2013-3-31 OOAD总复习

1、重用和修改现有的模型

2、使用分类列表

3、确定名词短语

5、准则：何时需要描述类？

1、需要有关商品或者服务的描述，独立于任何商品或服务的现有实例

2、删除其所描述事物的实例后，导致信息丢失，而这些信息也是需要维护的，但是被错误地与所删除的事物关联起来

3、减少冗余或重复信息

6、关联（association）是类（更精确的说，是这些类之间的实例）之间的关系，表示有意义和值得关注的连接

7、准则：在UML中如何对关联命名？

以“类名—动词短语—类名”的格式为关联命名，其中的动词短语构成了可读和有意义的顺序。

8、准则：任何属性都不表示外键

第十章

1、系统顺序图（SSD）是为阐述与讨论系统相关的输入和输出事件而快速、简单地创建制品。它们是操作契约和（最重要的）对象设计的输入

2、SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。

3、对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件。

4、什么是系统顺序图？

系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之间的事件，所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。

第十一章

1、操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。

2、定义：契约有哪些部分？

1、操作：操作的名称和参数

2、交叉引用：会发生此操作的用例

3、前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。

4、后置条件：最重要的部分。完成操作后，领域模型对象的状态。

3、什么是系统操作？

系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。

4、后置条件描述了领域模型内对象状态变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。

5、准则：契约在何时有效？

在UP中，用例是项目需求的主要知识库。用例可以为设计提供大部分或全部所需细节。这中情况下，契约就没什么用处。

6、准则：如何创建和编写契约？

1、从SSD图中确定系统操作

时光可见

第 4 页

2013-3-31 OOAD总复习

2、如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约

3、使用以下几种类表来描述后置条件：

1、创建或删除实例

2、属性值的变化

3、形成或消除关联（UML连接）

第十三章

1、什么是逻辑架构和层？

逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。之所以称之为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理计算机上对这些元素进行部署。

层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。

OO系统中通常包括的层有：

1、用户界面

2、应用逻辑和领域对象

3、技术服务

2、什么是软件架构？

架构是一组重要的决策，其中涉及软件系统的组织，对结构元素及其组成系统所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组成，以及指导该组织结构的架构风格。

第十五章

1、交互图这一术语是对以下两种更为特化的UML图的统称

1、顺序图：以一种栅栏格式描述交互，其中在右侧添加新创建的对象。

2、通信图：以图或者网络格式描述对象交互，其中对象可以置于图中的任何位置。

2、顺序图的基本表示法：

1、消息：实心箭头

2、应答或返回：在活动条末端使用应答（或返回）消息线

3、异步调用：虚线

3、通信图的基本表示法：

1、链是连接两个对象的路径，它指明了对象间某种可能的导航和可见性。链是关联的实例。

2、消息：对象间的每个消息都可以使用消息表达式和指明消息方向的小箭头表示。

3、消息的顺序编号：

1、不为第一个消息编号

2、使用合法编号方案来表示后续消息的顺序和嵌套，其中的嵌套消息要使用附加的数字

4、可以在顺序编号后使用带有方括号[]的条件句子来表示有条件消息。为真时发送消息

5、互斥的有条件路径：在顺序编号后面加上字母，第一个字母是a

6、迭代或循环：在顺序编号后面加*

第十六章

时光可见

第 5 页

2013-3-31 OOAD总复习

1、表示UML属性的方法：属性文本和关联线

2、在DCD中使用关联表示属性时的风格：导航性箭头、角色名、3、对于领域模型使用类图的时候，需要表示关联名称，但是要避免使用导航箭头，因为领域模型不是软件透视图。

3、对数据类型对象使用属性文本表示法，对其他对象使用关联线。

4、依赖用从客户到提供者的虚线箭头表示（AB，B发生变化会影响A）

5、比较常见的依赖类型：

1、拥有提供者类型的属性

2、向提供者发送消息

3、接收提供者类型的参数

4、提供者是超类或者接口

6、依赖标签

7、插座法表示接口

8、限定关联

第十七章

1、GRASP：基本OO设计的系统方法

2、GRASP：使用职责进行OO设计的学习工具

3、RDD（responsibility-driven design）：职责驱动设计。

4、UML把职责定义为“类元的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：行为和认知。

1、行为职责：

1、自身执行一些行为，如创建对象或计算。

2、初始化其他对象中的动作

3、控制和协调其他对象中的活动

2、认知职责：

1、对私有封装数据的认知

2、对相关对象的认知

3、对其能够导出或计算的事物的认知

5、对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。

6、职责的粒度会影响职责到类和方法的转换。

7、什么是模式？

如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。

在OO设计中，模式是对问题和解决方案的已命名描述，它可以用于新的语境。

8、使用GRASP进行对象设计的简短示例

1、创建者

2、信息专家

3、低耦合4、控制器

5、高内聚

9、创建者：谁创建了A？

解决方案：（有一个为真即可）

时光可见

第 6 页

2013-3-31 OOAD总复习

1、B“包含”或组成聚集了A

2、B记录A

3、B紧密地使用A

4、B具有A的初始化数据

10、信息专家：如果给定键值，谁知道Square对象的信息？

解决方案：把职责分配给具有完成该职责所需信息的那个类

11、低耦合：为什么是Board而不是Dog？如何减少变化产生的影响？

解决方案：分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估

12、控制器：在UI层之上首先接受和协调系统操作的对象是什么？

解决方案：把职责分配给能代表下列选择之一的对象：

1、代表全部“系统”、“根对象”、运行软件的设备或主要的子系统

2、代表发生系统操作的用例场景（用例或会话）

13、高内聚：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？

解决方案：职责分配应保持高内聚，依此来评估备选方案

第十八章

1、用例实现描述某个用例基于协作对象如何在设计模型中实现。更精确的说，设计者能够描述用例的一个或多个场景的设计，其中的每一个设计都称为用例实现。

2、下面说明了一些制品之间的关系：

1、用例指出了SSD中所示的系统操作

2、系统操作可以称为输入到领域层交互图的控制器中的起始消息

3、领域层交互图阐述了对象如何交互完成所需任务—用例实现

第十九章

1、可见性是一个对象看见其他对象或引用其他对象的能力

2、实现对象A到对象B的可见性通常有四种方式：

1、属性可见性—B是A的属性

2、参数可见性—B是A中方法的参数

3、局部可见性—B是A中方法的局部对象（不是参数）

4、全局可见性—B具有某种方法的全局可见性

第二十章

1、用OO语言（java或者C#）创建代码并不是OOA/D的一部分，它是最重的目标

2、在UP中具有实现模型。源代码、数据库定义、JSP/XML/HTML页面等都是实现制品

3、面向对象语言中的实现需要以下元素编写源代码：

1、类和接口的定义

2、方法的定义

第二十三章

1、在迭代1结束的时候，应该已经完成以下任务：

1、所有软件都已经被充分地测试

2、客户定期地参与对已完成部分的评估

3、已经对系统进行了完成的集成和固化，使其成为基线化的内部版本

2、迭代2的需求和重点：对象设计和模式

时光可见

第 7 页

2013-3-31 OOAD总复习

1、支持第三方外部服务的变化

2、复杂的定价规则

3、需要进行设计，使得在销售总额变化时刷新GUI窗口

第二十五章

1、之前介绍了5个GRASP模式：信息专家、创建者、高内聚、低耦合、控制器

2、下面介绍最后4个GRASP模式：多态、间接性、纯虚构、防止变异

3、多态：如何处理基于类型的选择？如何创建可插拔的软件构件？

解决方案：当相关选择或行为随类型（类）有所不同时，使用多态操作作为变化的行为类型分配职责。推论：不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择

4、纯虚构：当你并不想违背高内聚和低耦合或者其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？

解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念—虚构的事物，用以支持高内聚、低耦合和复用。这种类是凭空虚构的。

5、间接性：为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使用对象解耦合，以支持低耦合并提高复用性潜力？

解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。中介实现了其他构件之间的间接性

6、防止变异：如何设计对象、子系统和系统，使其内部的变化或不稳定不会对其他元素产生不良影响？

解决方案：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口

第二十六章

1、适配器（GoF）：如何解决不相容的借口问题，或者如何为具有不同接口的类似构件提供稳定的借口？

解决方案：通过中介适配器对象，将构件的原有接口转换为其他接口。增加一层间接性对象，通过这些对象将不同的外部接口调整为在应用程序内使用的一致接口

2、工厂：当有特殊考虑（例如存在复杂创建逻辑，为了改良内聚而分离创建职责等）时，应该由谁来负责创建对象？

解决方案：创建称为工厂的纯虚构对象来处理这些创建职责

3、单实例类：只有唯一实例的类即为“单实例类”。对象需要全局可见性和单点访问

解决方案：对类定义静态方法用以返回单实例

4、策略：如何设计变化但相关的算法或政策？如何设计才能使这些算法或政策具有可变更能力？

解决方案：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同接口

5、组合：如何能够像处理非组织（原子）对象一样，（多态地）处理一组对象或具有组合解耦股的对象呢？

解决方案：定义组合和原子对象的类，使它们实现相同的接口

6、外观：对一组完全不同的实现或接口需要公共、统一的接口。可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变，怎么办？

解决方案：对子系统定义惟一的接触点—使用外观对象封装子系统。该外观对象提供了惟一和统一的接口，并负责与子系统构件进行协作

7、观察者（发布—订阅）：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并时光可见

第 8 页

2013-3-31 OOAD总复习

且想要在发布者产生事件时以自己独特的方式作出反应。此外，发布者想要保持与订阅者的低耦合。如何对此进行设计呢？

解决方案：定义“订阅者”和“监听器”接口。订阅者实现此接口。发布者可以动态注册关注某事件的订阅者，并在事件发生时通知它们

第三十章

1、包含关系：多个用例中存在部分相同的行为，这是常见的现象

2、如下情形可以分解出子功能用例并使用包含关系：

1、用例在其他用例中重复使用

2、用例非常复杂并冗长，将其分解为子单元便于理解

3、具体用例是由参与者发起，完成了参与者所期望的完整行为。它们通常是基本业务过程用例

4、抽象用例永远不能被自己实例化，它是其他用例的子功能用例

5、包含其他用例的用例，或者是被其他用例扩展或者泛化的用例被称为基础用例

6、被其他用例包含的用例，或者扩展、泛化其他用例的用例被称为附加用例

7、扩展关系的思路是，创建扩展或附加用例，并且在其中描述：在何处何何种条件下该用例扩展某基础用例的行为

8、事实上，直接更新基础用例的扩展部分是推荐的方法，这样避免了创建复杂的用例关系

9、扩展关系的UML表示法：

1、扩展用例指向基础用例

2、在线上可以表示条件和扩展点

第三十一章

1、泛化是在多个概念中识别共性和定义超类（普通概念）与子类（具体概念）关系的活动

2、概念超类与子类之间是什么关系？

3、概念超类的定义较子类的定义更为概括或包含范围更广

4、泛化和类集的关系：概念子类集合的所有成员都是其超类集合的成员 5、100%规则：概念超类的定义必须100%适用于子类，子类必须100%与超类一致：属性、关联

6、Is-a规则：子类集合的所有成员必须是其超类集合的成员

7、什么是正确的概念子类？

潜在的子类应该遵守下述规则：

1、100%规则（定义的一致性）

2、Is-a规则（集合成员关系的一致性）

8、在下述几种情形下创建概念类的子类

1、子类有额外的有意义的属性

2、子类有额外的有意义的关联

3、子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方式是我们所关注的4、子类概念表示了一个活动体（例如动物、机器人等），其行为与超类或者其他子类不同，而这些行为是我们所关注的

9、在下述情形下可以创建与子类具有泛化关系的超类

1、潜在的概念子类表示的是相似概念的不同变体

2、子类满足100%和Is-a规则

时光可见

第 9 页

2013-3-31 OOAD总复习

3、所有子类都具有相同的属性，可以将其解析出来并在超类中表达

4、所有子类都具有相同的关联，可以将其解析出来并与超类关联

10、在领域模型中，如果类C可能同时有多个相同的属性A，则不要将属性A置于C至中，应该将属性A放在另一个类中，并且将其与C关联

11、在领域模型中增加关联类的可能线索有：

1、有某个属性与关联有关

2、关联类的实例具有依赖于关联的生命期

3、两个概念之间有多对多关联，并且存在于关联自身相关的信息

12、在下述情况下，可以考虑组合关系：

1、部分的生命期在组成生命期界限之内，部分的创建和删除依赖于整体

2、在物理或逻辑组装上，整体—部分关系很明确

3、组成的某些属性会传递给部分

4、对组成的操作可能传递给部分

13、在关联中可能会

面向对象的分析与uml 篇5

会议纪要

9月20日下午4：00在计算机学院计算机基础教学部办公室举行了《VC＋＋与面向对象技术》重点课程教学研讨会。计算机基础教学部甘玲、李盘林、李兴春、蒋贵全、张璞、汪建、刘达明，计算机软件教学部王晓蓉、刘群，计算机实验中心吴思远、邹洋等老师参加了会议。会议由项目组负责人甘玲主持。

会议议程：

1．该课程在本学期教学中发现的问题及措施；该课程的内容及学时分布； 2．该课程的考试方式及成绩计算； 3．该课程实验要求及集中上机的问题； 4．该课程网站建设情况；

5．该课程第一阶段工作情况及下一阶段工作安排； 6．该课程在教学计划中的课程整合及修改意见。

会议就以上问题展开了讨论，与会者都发表了自己的见解。

1．本学期教学中，老师们普遍感到学生基础太差，前面学习的C语言知识基本都忘了，感觉学时不够。如果按照《Visual C++》课程的要求是不可能完成的。这也符合我们修改教学计划（将2004级《Visual C++与面向对象技术》改为两门课限选课《面向对象程序设计－C++》和任选课《Visual C++》）、修改教学大纲（2003级仍按《Visual C++与面向对象技术》的执行，但修改了教学大纲）、制订相应授课计划，大家统一了认识，明确了目标，重点在C＋＋面向对象技术。

2．由于学时的问题，及上述意见，确定了考试方式用笔试和上机考试结合的方式，笔试占70％，机试占20％，平时（作业及出勤）占10％。机试采用随堂测试，由实验老师完成。

3．集中上机安排有些欠妥，课程还未完成，即在开学第四周进行。鉴于客观原因，只在Visual C++平台下，复习巩固C＋＋面向过程部分的编程能力的训练，同时，提前做一些C＋＋面向对象部分的编程能力训练，为课程的高效进行提供良好的基础，望实验老师注意！

4．现在网站正在紧张地进行，由李兴春和李盘林两位老师负责，9月份内完成，本周看初样。希望各位老师配合，提供资料（如源代码）。由汪建老师为课件加工处理形成网络课件，同时负责录像资料上网。

5．经过一年的建设，该课程取得了一些成绩，如师资队伍、教材建设、网站建设、教学大纲（统一了理论与实践）等教学资料共享等，但在教学研究、论文撰写等方面还需努力！刘达明老师负责资料的收集整理。

6．与该课程密切相关的C语言程序设计课程应该调整到第二学期上，而且在程序设计能力方面尚待加强。后续课程《Visual C++》与《Windows程序设计》也应修改教学大纲，明确教学目标，形成一条有序的程序设计链，完成学校赋予我们的使命，完成学生寄予我们的厚望！

面向对象的分析与uml 篇6

面向对象(Object Oriented,OO)是当前计算机界关心的重点，它是90年代软件开发方法的主流，不过随着时代的发展，很多人对OO编程方法的看法也出现了一些变化；

最近在网上面看到有个名人喷面向对象的文章，我们可以先看一看：

“面向对象编程是一个极其糟糕的主意，只有硅谷里的人能干出这种事情。” — Edsger Dijkstra(图灵奖获得者)

“面向对象设计是用罗马数字做计算。” — Rob Pike（Go语言之父）

““面向对象”这个词包含很多意思。有一半是显而易见的，而另一半是错误的。“ — Paul Graham（美国互联网界如日中天的教父级人物）

“实现上的继承就跟过度使用goto语句一样，使程序拧巴和脆弱。结果就是，面向对象系统通常遭受复杂和缺乏复用的痛苦。” — John Ousterhout（ Tcl and Tk 的创始人） Scripting, IEEE Computer, March

“90%的这些胡说八道都称现在它很流行，非要往我的代码里搓揉进面向对象的石粒。” — kfx

“有时，优雅的实现只需要一个函数。不是一个方法。不是一个类，不是一个框架。只是一个方法。” — John Carmack（id Software的创始人、第一人称射击游戏之父）

“面向对象编程语言的问题在于，它总是附带着所有它需要的隐含环境。你想要一个香蕉，但得到的却是一个大猩猩拿着香蕉，而其还有整个丛林。” — Joe Armstrong（Erlang语言发明人）

“我一度曾经迷恋上了面向对象编程。现在我发现自己更倾向于认为面向对象是一个阴谋，企图毁掉我们的编程乐趣。” — Eric Allman（sendmail的创造者）

——摘自:面向对象编程从骨子里就有问题

下面我们来分析一下他们为什么讨厌面向对象，过度追求OO到底有什么问题：

面向对象的生产效率

这是OO编程比较推崇的一点，不过我们可以先看看这篇文章:如此理解面向对象编程

在文章中，某“ ”，将下面一段代码，“面向对象”成了7个文件，代码量由原来的几行变成了几十行。

public class PrintOS

{

public static void main(final String[] args)

{

String sName = System.getProperty(“os.name”) ;

if (osName.equals(“SunOS”) || osName.equals(“Linux”))

{

System.out.println(“This is a UNIX box and therefore good.”) ;

}

else if (osName.equals(“Windows NT”) || osName.equals(“Windows 95”))

{

System.out.println(“This is a Windows box and therefore bad.”) ;

}

else

{

System.out.println(“This is not a box.”) ;

}

}

}

文中的这位“ ”将学院派的做法发挥到了极致，

虽然这只是一个OO的教学文档，但确实很像OO的一篇高级黑，但我们仍能看出一味地追求OO会增加多么大的代码量。你现在明白你为什么需要IDE来辅助了吧？ 在茫茫多的文件中寻找一个变量是多么的不容易呀。

面向对象的性能

这篇文章详细地讨论了OO的性能：Pitfalls Of Object Oriented Programming.

文中指出，从1980年至今，CPU的性能提高了近10W倍，但内存的访问性能只提高了不足10倍，原因就是内存的访问相对速度大为降低，OO的滥用使程序要经过很多间接过程才能访问到目标内存地址，

因而过度使用面向对象，会严重影响性能， 作者推荐优化数据和代码结构为先，并尽量使用KISS（keep it simple, stupid)原则来设计软件。

面向对象的可维护性

面向对象从一开始就要求我们完全了解各个子类的不同，并将他们的“共性”提取到父类里，从而实现代码复用， 在这个过程中自然形成了一种最强的耦合关系。这种设计方法在需求非常确定的情况下是有效的，但在实际生活中我们发现需求总是在开发过程中不断提出的，而且也总在变化，甚至跟之前完全相反，当你看到你精心设计的框架成为你需求变更的障碍时，你做何感想？

在一个完全OO的系统中，我们会不自觉地使用设计模式驱动型编程，正如这种编程的名字所说的，这种编程风格使用大量的设计模式，在你的程序中，四处都是设计模式，你的代码到处都是Facade，Observer ，Strategy，Adapter，等等等等。于是，你的程序要处理的业务逻辑被这些设计模式打乱得无法阅读，最后，也不知道是业务需求重来，还是设计模式重要，总之，实际业务需求的程序逻辑被各种设计模式混乱得不堪入目。摘自：各种流行的编程风格

该如何面向对象

面向对象的分析与uml 篇7

关键词：UML,一卡通,用例,类

1 UML概述

U M L是一种定义良好、易于表达、功能强大且普遍适用的通用建模语言。它融入了软件工程领域的新思想、新方法和新技术,它的作用域不限于支持面向对象分析与设计,还支持从需求分析开始的软件开发的全过程。它代表了面向对象方法的软件开发技术的发展方向,具有广阔的发展前景。UML可以对任何具有静态结构和动态行为的系统进行建模。它由两部分组成,一部分是语义,用于描述元模型定义;另一部分是表示符,用于定义符号的表示法。UML可以通过两种建模机制,九种图形把系统的重要业务表示出来。其中静态建模机制包括用例图、类图、对象图、包图、构件图和配置图;动态建模机制包括顺序图、合作图、活动图和状态图。

2“校园一卡通”系统概述

“校园一卡通”是消费者手中持一张卡能实现多种功能,使该卡既是学生证,又是借书证,而且还能实现校内一卡通消费(食堂就餐、机房上机、INTELNETH上网计费、洗浴收费、图书借阅、考勤管理等),实行一卡多用,一卡通用。该系统是现代信息识别技术、自动控制技术以及网络技术相结合的产物。每位消费者都有一张储值卡,卡内记录着消费者的基本信息,帐户金额。消费时,消费者将卡放在读卡机上或者插入插槽,显示幕自动显示卡上的金额,营业员按读卡机上的数字键,显示屏自动计算并显示本次消费额和余额。这样管理中心可以随时监控每一笔消费,统计出各个部门的消费情况,如,食堂每个窗口的就餐人数;浴室部门的沐浴人数、机房的上网人数等,使得学校能够快速、准确地掌握每位学生、每个部门的收入、支出情况,便于统一管理。

3 U M L在“校园一卡通”系统中的应用

3.1“校园一卡通”的静态分析设计

“校园一卡通”的参与者有消费者、营业员和管理员。这里的消费者也就是储值卡;营业员也就是收款机;管理员也就是服务器,其中消费者主要是消费,营业员主要是收款,管理员主要是对卡和事件进行处理。

3.1.1 用例模型

根据消费者、营业员和管理员三种角色来确定系统的用例,经过分析,得到如下的用例:

●与消费者相关的用例

卡的管理事项;

消费事项。

●与营业员相关的用例

消费事项;

经营结算事项。

●与管理员相关的用例

卡的管理事项;

消费事项;

经营结算事项

用例图如图(1)所示:

3.1.2 类模型

根据分析,可得到如下的类:

服务器类、收款机类、储值卡、消费事项类、经营结算事项类、卡的管理事项类、消费日志类。

●服务器类

该类直接与系统进行交互,与消费者、服务组进行业务联系,该类对象直接操作系统主程序。

●收款机类

该对象直接与系统联系,模拟服务员的登录系统、收款等行为。

●储值卡类

代表消费者与系统和收款机进行交互,模拟消费者进行充值、消费等活动。

●消费事项类

消费者在某服务窗口进行一组消费,通过服务员连续操作POS完成收款活动,就称为一次消费事件。

●经营结算事项类

对每一个服务组所有消费事件的数据按日志进行汇总,从而实现服务中心与服务组的结算。

●卡的管理事项类

此类事件主要是管理卡的注册、发放、充值、挂失、注销工作。

●消费日志类

为提供消费清单查询和经营结算等行为实施监控提供详细记录,需要系统有实施日志。考虑到未来经营窗口的变更,比如窗口收款机的进一步扩充,并以关联类和集合管理器为核心设计样式。

类图如图2所示:

4“校园一卡通”系统的实现

4.1 功能需求

高校有着大量的学生、员工、部门等对象,而且他们是动态变化的。从根本上讲,系统需要具有对各种信息的添加、修改、删除、查询和大量的统计功能。此外,还需要提供对上述对象的分组、对象属性的设置等功能。

4.2 系统的运行环境

系统采用Windowsoft公司的策略和产品,用B/S模式开发,系统开发完成后分成两个部分:系统初始化设置专为系统管理员提供的,放在O A S(O r a c l e Application Server)上。数据库放在数据库服务器上。

●硬件环境:网络硬件由一台高档服务器组成。

●软件环境:

(1)服务器软件环境:

网络操作系统:WindowsNT4.0或Linux

数据库系统:SQL Server

W e b服务器:O A S

(2)客户端软件环境

操作系统:Windows2000

浏览器:Internet Explorer

(3)使用开发环境

Web服务器与数据库服务器的连接技术是CGI/API。开发工具是PL/SQL。

根据上面的分析,笔者使用Java语言进行了仿真,并且能够正常运行。

5 结束语

以上是利用U M L对校园一卡通系统进行建模。采用UML及其它所支持的工具Rational Rose,就使得我们能够理解需求,对所开发的系统作出正确的分析和设计,并且在一个经过验证的规则上开发一个方案和作出最佳的实现,从而不仅可以大大提高应用程序的开发效率,而且可以明显地提升可扩展、易维护和便于长期使用软件的机会。实践表明:UML作为软件工程中的建模语言,代表了面向对象方法的软件开发技术的发展方向,获得了广泛的支持,具有广阔的应用前景。

参考文献

[1]袁涛,孔蕾蕾.统一建模语言UML.北京:清华大学出版社.2010

[2]马晓丽,张洁等.基于面向方面的校园一卡通系统的设计.河北软件职业技术学院学报.2010.2

面向对象的分析与uml 篇8

关键词：面向对象；关系型数据库；映射；类；属性

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）20-0012-02

1 引言

面向对象（Object Oriented，OO）是把面向对象的思想应用于计算机软件开发中，以对象为内核，以类、继承、封装、多态等概念构造系统，进行客观事物的软件开发设计的一种方法。面向对象，对象其实就是一个封装体，包含数据和控制命令。随着计算机技术和开发软件的不断升级，面向对象的方法和应用已经不仅仅局限于软件开发和程序设计，已经逐渐扩展到数据库系统、分布式系统、网络管理、人机交互等计算机领域，甚至对人工智能、计算机辅助工具、信息系统等產生深远影响。计算机和网络都离不开数据库，面向对象的广泛应用，也给数据库技术增添了新鲜血液。面向对象方法与数据库技术，尤其是关系型数据库如何有效结合，更好的支持数据库的应用，是一个非常值得研究的课题。

2 面向对象的关系型数据库

2.1 关系型数据库

电子商务、云存储、云计算等计算机信息系统，已经是当今信息技术的重要手段，而数据库技术是计算机系统的重要组成部分和核心内容。数据库类型有网状、层次和关系几类，其中关系型数据库以其集合的操作方式得到了最为广泛的应用。关系型数据库是一种建立在关系数据库模型基础上的数据库，用集合代数方法对数据库单元中数据进行处理，是一组相互之间有关联关系的表，表的关系通过相关字段进行关联，表中的数据可以根据需求情况进行存取且不用重新组织数据库表格。新建一个关系型数据库时，每一行包含一个数据实体，是被列定义的种类。目前应用较多的数据库有oracle、sqlserver、mysql等。

2.2面向对象分析法

面向对象分析法（Object-Oriented Analysis，OOA），是指一个软件开发项目在开发过程中，首先要对业务情况进行调研，然后用面向对象的思想对该项目业务进行归纳、分类、分析。OOA强调的是业务对象之间的关系以及对象的属性和行为。面向对象分析法使用户和设计者之间的沟通更容易，设计者能够更好地理解用户的需求，设计者了解了用户的需求，才能更好地设计出用户与数据库之间的映射方式，从而设计出用户满意的数据库。

OOA方法的程序设计，从结构框架来说，一个是针对开发者的外部层，外部层是应用程序的整体设计；内部层针对物理存储，称为物化视图，是基于远程表格的，也可以称之为快照；概念层介于外部层和内部层之间，是内外部的映射，用DDL表示，概念层是关系型数据库的真正表现形式。对象与关系型数据库通过映射发生关系，映射方法就是将关系型数据库进行概念层的设计。从对象到关系型数据库的映射内容包括：属性与列的映射，关系型数据库中的继承，类与表的映射，映射的关联，聚合和组合以及实现关系等。

将对象建模和映射的过程就是将对象转换成概念层的数据库模型，对象模型转换为关系型数据库的映射有如下关系：

1）每个对象是唯一的，有唯一的标识符，具有唯一性。对象的标识一般用主键或者是系统自动生成的伪标识符来标识，而不是通过描述对象的属性来标识。

2）类与关系型数据库中的表的转换，可以通过直接调用表的名称，或者可以通过在类的名称前加前缀的方式修改成表的名称来实现。

3 基于面向对象技术的关系数据库的设计方法

3.1 整体思路

基于面向对象技术的关系型数据库的设计方法，首先要确定应用程序中的领域类，领域类中将数据信息和对数据的操作、调用方法进行了封装。领域类实例化，就得到对象，因此，需要提前把对象的存储、地址、检索方法、调用方法等问题设计好，做好准备工作。

在面向对象的关系型数据库中，数据通过对象形式存储到数据库中，并且对象之间的关联关系是自动存储的。关系型数据库本身不存在集合和分解的问题，可以由与对象相关的状态图像构成。面向对象的关系型数据库是通过对对象进行查询、检索、调用的，不存在对某个表的一行或一列进行某些操作。因此需要提前定义对对象的各种操作方法。比如：writeObject（）是一个写入并存储一个对象及所有对象相关；read Object（）是读取一个对象及所有对象相关。每个对象有唯一的标识ID，在写入和读取时通过唯一的标识ID进行。

以消费者对电子账户的写入、读取操作为例子，来说明面向对象数据库数据存储模式，如图1所示。将消费者对电子账户的操作对象的属性描绘成字段，指向其他对象需要映射到相应的外部关键字上，此处的操作动作不能封装。数据库中的每一个表对应一个类，对数据库中的表的操作设定为函数。

3.2 对象映射成关系数据库

RDBMS的表都是二维表，一个二维表是一个管理单元，二维表及表与表之间的关联关系用来描述对象模型的属性，即对象模型与关系型数据库的映射关系。将每个对象的类存储到数据库的表中，一个类对应一个对象实例，并进行存储。不仅对象实例映射到关系型数据库中，对象之间的关联关系也要映射到关系型数据库中，这样才能进行后续的操作。

对象之间的关系有四种：关联、继承、聚合、组成。关联是关系型数据库中对象之间的关联关系，聚合不仅需要对关系型数据库的整体进行操作，还需要对部分进行操作，即读取时需要整体读取的同时也需要在部分数据中进行读取。关联是不需要的，在关联中存储和读取的执行操作不明显。关联和聚合的区别在于对象之间的联系程度不同。

对关系型数据库中的数据不但有存储、调用等动作，还有删除的动作，那么将数据库对对象的存储和删除也是一样，对象映射成关系型数据由一些规则，如下：

1）一个类与一个库表对应映射，也可以多个类与一个库表对应映射。

2）类中存在父子关系的类，映射关系时可以分别与父和子类分别映射，或者不对父类进行定义，让子类具有父类的属性；不对子类进行定义，让父类具有子类的属性。

3）映射关系定义为一个表，包含一对一、一对多、多对多等关联关系，也可在类表之间定义外键。

4）聚合的方式有两种：一种是用一张表将所有对象类的属性合并；一种是分别用两张表分别将对象类的整体和部分分别合并，利用外键关联整体与部分的关系。

5）有些类是没有属性的，没有属性则没有映射表。

6）映射后的关系型数据库表需要进行冗余操作，使其关系范式合理。

4 结论

面向对象的关系型数据库系统以其模型简单、数据独立的优势，成为数据库技术发展的主流方向，本文针对面向对象的技术和关系型数据库的特点，将两者相结合，研究了将面向对象技术方式应用于关系型数据库，进行系统设计方法的研究，重点描述了对象映射成关系数据库的方法。

参考文献：

[1] 杨玉芬，李明明.高晓旸对象管理在面向对象数据库中的应用研究[J].吉林大学学报（信息科学版），2013，9（5）：548-553.

[2] 肖刚.面向对象数据库在教学信息管理系统中的应用[J].硅谷，2012（6）：79.

[3] 陆登，李善平，郑春昭. 基于对象数据库的扩展Java集合框架[J].计算机应用与软件，2011（1）：133-136.

[3] 陈文宇.面向对象的关系数据库设计[J].电子科技大学学报，2002（1）：53-56.

c面向对象的笔试题 篇9

答案：通用寄存器给出的地址，是段内偏移地址，相应段寄存器地址*10H+通用寄存器内地址，就得到了真正要访问的地址。

2. 比较C++中的4种类型转换方式?

请参考：，重点是static_cast, dynamic_cast和reinterpret_cast的区别和应用。

一、C 风格(C-style)强制转型如下：

(T) expression // cast expression to be of type T

函数风格(Function-style)强制转型使用这样的语法：

T(expression) // cast expression to be of type T

这两种形式之间没有本质上的不同，它纯粹就是一个把括号放在哪的问题。我把这两种形式称为旧风格(old-style)的强制转型。

二、C++的四种强制转型形式：

C++ 同时提供了四种新的强制转型形式(通常称为新风格的或 C++ 风格的强制转型)：

const_cast(expression)

dynamic_cast(expression)

reinterpret_cast(expression)

static_cast(expression)

每一种适用于特定的目的：

dynamic_cast 主要用于执行“安全的向下转型(safe downcasting)”，也就是说，要确定一个对象是否是一个继承体系中的一个特定类型。它是唯一不能用旧风格语法执行的强制转型，也是唯一可能有重大运行时代价的强制转型。

static_cast 可以被用于强制隐型转换(例如，non-const 对象转型为 const 对象，int 转型为 double，等等)，它还可以用于很多这样的转换的反向转换(例如，void* 指针转型为有类型指针，基类指针转型为派生类指针)，但是它不能将一个const 对象转型为 non-const 对象(只有const_cast 能做到)，它最接近于C-style的转换。

const_cast 一般用于强制消除对象的常量性。它是唯一能做到这一点的 C++ 风格的强制转型。

reinterpret_cast 是特意用于底层的强制转型，导致实现依赖(implementation-dependent)(就是说，不可移植)的结果，例如，将一个指针转型为一个整数。这样的强制转型在底层代码以外应该极为罕见。

旧风格的强制转型依然合法，但是新的形式更可取。首先，在代码中它们更容易识别(无论是人还是像 grep 这样的工具都是如此)，这样就简化了在代码中寻找类型系统被破坏的地方的过程。第二，更精确地指定每一个强制转型的目的，使得编译器诊断使用错误成为可能。例如，如果你试图使用一个 const_cast 以外的新风格强制转型来消除常量性，你的代码将无法编译。

==

== dynamic_cast .vs. static_cast

==

classB { ... };

class D : public B { ... };

voidf(B* pb)

{

D* pd1 = dynamic_cast(pb);

D* pd2 = static_cast(pb);

}

If pb really points to an object of type D, then pd1 and pd2 will get the same value.They will also get the same value if pb == 0.

If pb points to an object of type B and not to the complete D class, then dynamic_cast will know enough to return zero. However, static_cast relies on the programmer’s assertion that pb points to an object of type D and simply returns a pointer to that supposed D object.

即dynamic_cast可用于继承体系中的向下转型，即将基类指针转换为派生类指针，比static_cast更严格更安全。dynamic_cast在执行效率上比static_cast要差一些,但static_cast在更宽上范围内可以完成映射,这种不加限制的映射伴随着不安全性.static_cast覆盖的变换类型除类层次的静态导航以外,还包括无映射变换,窄化变换(这种变换会导致对象切片,丢失信息),用VOID*的强制变换,隐式类型变换等...

==

== static_cast .vs. reinterpret_cast

==

reinterpret_cast是为了映射到一个完全不同类型的意思,这个关键词在我们需要把类型映射回原有类型时用到它.我们映射到的类型仅仅是为了故弄玄虚和其他目的,这是所有映射中最危险的.(这句话是C++编程思想中的原话)

static_cast 和reinterpret_cast 操作符修改了操作数类型. 它们不是互逆的; static_cast 在编译时使用类型信息执行转换, 在转换执行必要的检测(诸如指针越界计算, 类型检查). 其操作数相对是安全的. 另一方面,reinterpret_cast 仅仅是重新解释了给出的对象的比特模型而没有进行二进制转换, 例子如下:

int n=9; double d=static_cast < double >(n);

上面的例子中, 我们将一个变量从 int 转换到 double. 这些类型的二进制表达式是不同的. 要将整数 9 转换到 双精度整数9, static_cast 需要正确地为双精度整数 d 补足比特位. 其结果为 9.0. 而reinterpret_cast的行为却不同:

int n=9;

double d=reinterpret_cast (n);