发信人: connor()
整理人: majorsun(1999-11-19 15:07:16), 站内信件
|
当然抄了许多,呵呵.论文不都是这样攒出来的吗?
记得当时要完成的首要任务就是把自己的论文看一遍.
权当读书笔记把.
----------------------------------------------------------这样就没有图和表格了
毕业设计论文
——软件工程方法与CASE工具的结合及教学课件上网
1．引言——任务
1分析比较面向过程的软件工程与面向对象的软件工程的方法、理论。
1．2试用CASE工具——ROSE
1．3软件工程教学课件上网
2．技术背景
1分析比较面向过程的软件工程与面向对象的软件工程的方法、理论。
2．1．1传统的软件工程开发方法（Parnas，SASD，Jackson，Warnier 等）简介，问题所在
2．1．2面向对象的软件工程开发方法（OOA，OOD） 简介
2．2评价、比较、现有的CASE工具
2．2．1 Rational 公司的ROSE
1） 特点
2）技术
2．2．2 I2DEF简介
2．2．3其他CASE工具简介
2．2．4比较及评价
2．3WWW及HTML介绍
3．工作描述
1介绍ROSE
3．1． 1界面介绍
3．1．2使用方法
3．2使用ROSE辅助软件工程开发——示例
3．2．1问题描述
3．2．2目标与需求
3．2．3开发过程
3. 2．4 WWW开发工具——Frontpage98简介
3．3软件工程课件上网
3．3．1界面介绍
3．3．2使用方法
3．3．3维护方法
4．工作总结
4．1 学到了思想、行动的方法——提出问题，分析问题，解决问题
4．2 掌握了多种工具软件
5．讨论
5．1 ROSE的一些问题
5．2 FrontPage98及课件上网中的一些问题
6．结束语——致谢
7．参考文献
1． 引言
随着人类社会的发展及计算应用的普及，软件的开发在计算机应用领域中所占的
比例越来越大。并由于软件需求的迅猛增长，60年代中期开始爆发了众所周知的
软件危机。使人们认识到大中型软件与小型软件有本质的不同:它们的复杂性已
远远超出人脑所能直接控制的程度,软件的开发不能再沿袭早期小型软件随心所欲
的开发方式,而是必须立足于科学的理论基础上。为了缓解和克服软件工业出现的
这一系列危机，计算机工作者们通过总结实际经验，从理论着手，研究出各种的
软件开发方法和管理方法，并将研究成果推广到实际应用中去，从而逐步实现了
当今软件开发的新局面——即一整套的开发方法和与之相适应的集成软件开发环
境的结合。
在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，
并在以后不断发展、完善。软件工程学就这样诞生了。这是软件开发史上重要的
里程碑,它标志着软件开发进入了划时代的新阶段。
CASE就是指计算机辅助软件工程，是用软件工程的计算机软件来进行开发软
件工程。用了CASE工具，开发软件能更加规范，标准化。它能自动生成文档，从
而提高软件开发的效率。
现在各个发达国家对软件工程及CASE工具的研究和开发工作都很重视，已经
有很多技术先进的CASE工具商业化了，如Rational ROSE等。国内也已经有些公司
做出产品，比如北大青鸟，I2DEF，BLUEPRINT等。我小时研究通信系统的专业学
校，而通信软件的复杂性是众所周知的。因此，必须把软件工程的方法应用到软
件开发中来，用CASE工具提高效率，提高软件质量，这些都是很值得研究的问题。
2．概述——技术、概念及方法
2． 1 软件工程
2．1．1 软件、软件危机和软件工程
软件是指指令、程序以及相关的数据结构和文档。因为软件是一个逻辑部件，
因此与硬件在表现形式、生产方式、要求及维护上都有不同。
由于软件的逻辑性质，人的缺陷容易在复杂的开发维护过程中暴露出来。因
此就必须用工程的方法来解决随之而来的软件危机。软件工程是指导计算机软件
开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软
件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结
合起来，这就是软件工程。
1． 随着软件的不断扩大、开发维护也越来越复杂。因此、软件的发展也经历了
三个阶段：
程序设计阶段：50--60年代
程序系统阶段：60--70年代
程序工程阶段：70年代以后
2． 软件工程实际是由硬件和系统工程派生出来的。它包含四个关键元素：方法、
语言、工具和过程。方法提供如何构造软件的技术。包括一组广泛的任务，有各
种估算、分析、数据结构设计等。还通常引入专用的图形符号、以及一套软件质
量的准则。
语言用以支持软件的分析、设计和实现。不仅有传统的编程语言，还有规格
说明语言和原型开发语言。
工具为方法和语言提供自动半自动化的支持。将这些工具集成起来，有一个
工具产生的信息可以被另一个使用时，就形成了一个支持软件开发的系统、称之
为计算机辅助软件工程——CASE。
软件工程的过程是粘结剂（glue），把方法、语言和工具粘结在一起，能使
计算机软件理性化和适时化。
2．1．2 软件工程的开发模式
软件工程是由一系列方法、语言、工具和过程的步骤组成。这些步骤通常叫
做软件工程模式(paradigms)。许多软件工程把一个项目的开发分为几个阶段，
称之为瀑布模型。生存期模型（life-cycle model）是系统开发项目总貌的一种
描述，着眼于对项目管理的控制和逐步逼近的策略。它的目的就是给出软件开发
项目的一个降低风险的结构。
下面是常见的几种软件工程模式：
一、 瀑布式模型
瀑布式模型（waterfall model）是传统的软件工程生存期模式。它由系统需求分
析开始，跟着是软件需求分析、设计、编码、测试和维护。
这种典型的生存期模式是最古老和最广泛使用的软件工程模式。但这种模式
的实质是面向阶段的，线性的和传统的开发策略，除了确认（validation）和验
证(verification)外，其他所有阶段都是线性执行的。因此，这种模式在硬件生
产中工作得很好但对软件开发的适应性却不强。
在用生存期模型开发软件时，会出现三个问题：
（1） 越早出现的活动，对它的注释(notation)就越少。
（2） 越早出现的活动，我们对它的理解就越少。
（3） 一个错误在项目中出现的越早,它所造成的影响就越重。
例如，早期需求分析中的错误，要改正它所需开销是现实中改正错误所需的100倍
到1000倍，甚至导致数百万美元的项目不得不被取消。
这种模型，往往不能真实反映客户需求，这是因为：
（1） 用户与开发者之间，以及它们之间的交流存在巨大的文化差异。客户不能通
过阅读技术系统规格说明文档来沟划出系统模样。
（2） 用户不熟悉信息技术，所以会提出很含糊的需求，而这种含糊的需求有可能
被开发人员随意解释。
（3） 用户需求往往是会变化的，但这种模型不能及时反映。
由此可看出、这种模型是建立在一个系统规格说明是完整的、简明一致的、而
且可以先于设计实现之前产生这种假设上的。但这种假设通常是不可行的，因为用
户并不知道他们需要什么！
这种生存期模型由许多缺陷、导致它只能用于类似嵌入式软件、实时系统这样
的领域。缺陷主要有：
（1） 不能对付含糊不清和不完整的用户需求。
（2） 由于开销的逐步升级问题，它不希望存在早期阶段的反馈。
（3） 不能恰当地研究和解决使用系统时人的因素。
（4） 最终产品将更多地反映用户开始时的需求，而不是最后需求。
二、 原型开发模型
为了避免瀑布式的种种缺陷，近来出现了快速原型开发方法
（rapid prototyping）。这种方法就是在项目早期尽快生产出一个简化的系统原型
版本，以便为构造系统的规格说明提供必不可少的反馈信息。这样就能弥补瀑布式
的缺陷了。
原型开发的主要哲学论点就是允许失败，因为无论怎样，开发软件中错误是不
可避免的，用原型法能用较小的代价避免较多的错误（尤其是早期的），从而大大
减少了维护工作量。实际上，原型也是确定软件需求的一种机制。
但原型法也有一些待解决的问题：
（1） 用户看到了可运行的软件，但并不知道这只是临时搭起来的，当告诉他们产
品要重新生产时，用户难以接受。往往，项目管理者就不坚持原则了。
（2） 为使原型尽快投入使用，开发者经常使用一些折衷的解决方法。如不适当的
操作系统、开发语言、效率低的算法……等时间一长，开发者可能熟悉了自己的选
择，就忘了它们不适当的原因。最后很能就变成系统集成的一部分了。
三、螺旋开发模型
螺旋开发模式综合了传统的生存周期模型和原型开发模型的优点，同时增加了
风险分析（risk analysis）这个新元素，用来弥补两者的不足。风险就是项目可
能失败的风险，例如能否达到规定的实时性要求等。先是计划，以确定可选方案；
第二是风险分析，并研究解决风险；第三是进行工程开发；第四是用户评价。然后
根据用户评价周而复始地进行下去。直至达到系统要求。
螺旋模型开发模式采用软件工程逐步逼近的演化（evolutionary）方法，使开
发者和用户能了解每个演化级的风险，并作出反应。它将原型开发作为减少风险的
机制，还保留了传统生存期逐步求精和细化的方法，这样综合到一个重复的框架以
后，就可以对真实世界进行更为现实的反应。
但螺旋模型也有缺陷，主要是难以让用户确信这种演化方法是可以控制的，还
要求有风险评价的专门技术，若主要风险不能发现，则问题一定会发生。而且，这
种模型比较新，使用还不够不广泛。
四、面向对象生存期模型
OO软件工程是在面向对象技术逐渐成熟之后提出的。
在OO的生存期中，仍然有分析、设计和实现三个阶段。这些阶段可以与当前用
来支持传统软件开发的任意种方法（如瀑布式模型、原型法的演化模型）结合在一
起，为了利用对象固有的模块性和获得最大的可扩充性，OO软件的生存期类似于演
化模型。OO软件开发生存期与传统的结构化生存期相比较，在性质上具有更多的递
增和迭代的性质。
传统的生存期有逻辑数据设计和逻辑过程设计这两个不同的阶段，但在OO生存
期中这两个阶段合并为一个既包含数据，有包含过程的类。即完成高层分析和设计
使用的类应同时包含数据和服务。
对象使用客户/服务器模型提供服务，在客户/服务器模型中通过消息交互作用。
这就导致了一种“响应—驱动”的系统。
由于一个完全集成化的OO生存期来自从问题到问题各个阶段中相容对象模型的
使用，许多相同的技术，在分析、设计和事项中都用到了。它们不同的区别在于：
在分析阶段，这些技术用于高层对象，这些高层对象模拟事务过程、角色，以及结
构内的规则等。而在设计阶段，对这些对象求精和细化，是通过增加一些对象用于
管理用户对话、相互关系、相关的完整性和处理等。然后，直接使用OO编程语言来
实现这些对象。
在观察问题域的方法上，OO分析与传统结构化分析有不同：一个类，在逻辑上
既包含数据，又包含功能。它取消了实体只能定义数据的老概念。集成性取代了实
体关系的子类型。处理分析图描述了不同类的实例之间的消息传送，取代了数据流
图。传统的实体关系图被类的关系图和类的分层图所取代。
2．1．3 软件开发方法
随着软件工程学的不断发展，软件研究人员也在不断探索新的软件开发方法，
只今为止已经形成了以下几种软件开发方法：
一、Parnas方法
这种最早的软件开发方法是由D．Parnas在1972年提出的。主要针对软件在可
维护性和可靠性面这两个严重问题。他提出两个原则：1）信息隐蔽原则：在概要
设计时列出将来可能发生变化的因素,并在模块划分时将这些因素放到个别模块的
内部。2）在软件设计时应对可能发生的种种意外故障采取措施。
Parnas对软件开发提出了深刻的见解。遗憾的是，他没有给出明确的工作流程。
所以这一方法不能独立使用，只能作为其它方法的补充。
二 、SASD方 法
1978年，E．Yourdon 和 L．L．Constantine提出了结构化方法，即SASD方法，
也可称为面向功能的软件开发方法或面向数据流的软件开发方法。1979 年
Tom DeMarco对此方法作了进一步的完善。
Yourdon方法是80年代使用最广泛的软件开发方法。它首先用结构化分析（SA）
对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化
编程（SP）。这一方法不仅开发步骤明确，SA、SD、SP相辅相成，一气呵成，而且
给出了两类典型的软件结构（变换型和事务型），便于参照，使软件开发的成功率
大大提高。
三、面向数据结构的软件开发方法
Jackson方法
1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。这一方法
从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就
可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别
有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详
细设计。
Jackson方法有时也称为面向数据结构的软件设计方法。
Warnier方法
1974年，J．D．Warnier提出的软件开发方法与Jackson方法类似。差别有三点：
一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；另一个差别是使
用的伪码不同；最主要的差别是在构造程序框架时，Warnier方法仅考虑输入数据
结构，而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。
四、问题分析法
PAM问题分析法。PAM（Problem Analysis Method）是80年代末由日立公司提出
的一种软件开发方法。
PAM方法希望能兼顾Yourdon方法、Jackson方法和自底向上的软件开发方法的优
点，而避免它们的缺陷。它的基本思想是：考虑到输入、输出数据结构，指导系统
的分解，在系统分析指导下逐步综合。这一方法的具体步骤：从输入、输出数据结
构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，
直到画出整个系统的PAD图。从上述步骤中可以看出，这一方法本质上是综合的自底
向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系
统的输入、输出数据结构。
PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图，是到目前为止
最好的详细设计表示方法之一，远远优于NS图和PDL语言。
这一方法在日本较为流行，软件开发的成功率也很高。由于在输入、输出数据结
构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。
五、面向对象的软件开发方法
详见后叙
2．2 传统的软件工程方法
2．2．1概述
传统的软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。也
就是对问题进行分解然后再分别解决各个子问题的策略。采用的生存周期方法学就
是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次
划分为若干个阶段。每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。
采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶
段一个阶段地进行开发。前后阶段紧紧衔接，每一个阶段的开始和结束都有严格标
准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和
管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检
查通不过，则必须进行必要的返工，并且返工后还要再经过审查。
2．2．2传统软件工程开发的各个阶段
软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进
一步划分成若干个阶段。
软件定义时期通常进一步划分成三个阶段，即问题定义、可行性研究和需求分
析。开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组
成：总体设计，详细设计，编码和单元测试，综合测试。维护时期的主要任务是使
软件持久地满足用户的需要。通常对维护时期不再进一步划分阶段，但是每一次维
护活动本质上都是一次压缩和简化了的定义和开发过程。
下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。
１问题定义
问题定义阶段必须回答的关键问题：“要解决的问题是什么？”。通过问题定
义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。
２可行性研究
这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决
办法吗？”系统分析员需要在较抽象的高层次上进行的分析和设计的过程。这个阶
段的任务不是具体解决问题，而是探索这个问题是否值得去解，是否有可行的解决
办法。
３需求分析
这个阶段的任务是准确地确定“为了解决这个问题，目标系统必须做什么”，主要
是确定目标系统必须具备哪些功能。系统分析员在需求分析阶段必须和用户密切配
合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据
字典和简要的算法描述表示系统的逻辑模型。
４总体设计
这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”。
系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的
成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（
最佳方案），并且制定实现所推荐的系统的详细计划。总体设计阶段的第二项主要
任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通
常用层次图或结构图描绘软件的结构。
５详细设计
详细设计阶段的任务就是把解法问题的办法具体化，也就是回答下面这个关键
问题：“应该怎样具体地实现这个系统呢？”这个阶段的任务是设计出程序的详细
规格说明。它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
通常用ＨＩＰＯ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计
语言）描述详细设计的结果。
６编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。程序员应
该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用
汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编
写出的每一个模块。
７综合测试
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定
的要求。 最基本的测试是集成测试和验收测试。
应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来
，做为软件配置的一个组成成分。
８软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需
要。
通常有四类维护活动：1）改正性维护，也就是诊断和改正在使用过程中发现
的软件错误；2）适应性维护，即修改软件以适应环境的变化；3）完善性维护，即
根据用户的要求改进或扩充软件使它更完善；4）预防性维护，即修改软件为将来
的维护活动预先做准备。
2．2．3传统软件工程方法的局限性
尽管这些软件工程很大地提高了软件开发的效率、但它还是存在有很多的局限性：
1． 软件的开发进行难以与用户沟通。
2． 面向处理和面向数据这两种分析方法有着无法弥补的鸿沟
3． 分析和设计存在鸿沟，主要是思想方法上的和使用工具上的。
4． 容易由于理解不一致而产生错误。
5． 开发是必须严格按步骤进行、因此难于修改前一阶段的错误。
2．3 面向对象的软件工程
八十年代末以来，随着面向对象技术成为研究的热点出现了几十种支持软件
开发的面向对象方法。其中，Booch, Coad/Yourdon, OMT, 和Jacobson的方法在
面向对象软件开发界得到了广泛的认可。特别值得一提的是统一的建模语言UML
（Unified Modeling Language），该方法结合了Booch, OMT, 和Jacobson方法
的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检
验的概念和技术。UML方法自去年提出后到现在已发展到1.1版，并已提交给对象
管理集团OMG，申请成为面向对象方法的标准。
面向对象方法都支持三种基本的活动：识别对象和类，描述对象和类之间的
关系，以及通过描述每个类的功能定义对象的行为。
当重要的对象被发现后，通过一组互相关联的模型详细表示类之间的关系和
对象的行为，这些模型从四个不同的侧面表示了软件的体系结构：静态逻辑、动
态逻辑、静态物理和动态物理。
静态逻辑模型描述实例化（类成员关系）、关联、聚集（整体/部分）、和一
般化（继承）等关系。这被称为对象模型。一般化关系表示属性和方法的继承关
系。定义对象模型的图形符号体系通常是从用于数据建模的实体关系图导出的。
对设计十分重要的约束，如基数（一对一、一对多、多对多），也在对象模型中
表示。
动态逻辑模型描述对象之间的互相作用。互相作用通过一组协同的对象，对
象之间消息的有序的序列，参与对象的可见性定义，来定义系统运行时的行为。
Booch方法中的对象交互作用图被用来描述重要的互相作用，显示参与的对象和对
象之间按时间排序的消息。可见性图用来描述互相作用中对象的可见性。对象的
可见性定义了一个对象如何处于向它发送消息的方法的作用域之中。例如，它可
以是方法的参数、局部变量、新的对象、或当前执行方法的对象的部分。
静态物理模型通过模块描述代码的布局。动态物理模型描述软件的进程和线
程体系结构。
以下就表述这几种面向对象的软件开发方法。
2．3．1 Coad/Yourdon方法
Coad/Yourdon方法严格区分了面向对象分析OOA和面向对象设计OOD。该方法
利用五个层次和活动定义和记录系统行为，输入和输出。这五个层次的活动包括：
* 发现类及对象。描述如何发现类及对象。从应用领域开始识别类及对象，形成
整个应用的基础，然后，据此分析系统的责任。
* 识别结构。该阶段分为两个步骤。第一，识别一般－特殊结构，该结构捕获了
别处的类的层次结构；第二，识别整体－部分结构，该结构用来表示一个对象如
何成为另一个对象的一部分，以及多个对象如何组装成更大的对象。
* 定义主题。主题由一组类及对象组成，用于将类及对象模型划分为更大的单位
，便于理解。
* 定义属性。其中包括定义类的实例（对象）之间的实例连接。
* 定义服务。其中包括定义对象之间的消息连接。
在面向对象分析阶段，经过五个层次的活动后的结果是一个分成五个层次的
问题域模型，包括主题、类及对象、结构、属性和服务五个层次，由类及对象图
表示。五个层次活动的顺序并不重要。
面向对象设计模型需要进一步区分以下四个部分：
* 问题域部分（PDC）。面向对象分析的结果直接放入该部分。
* 人机交互部分（HIC）。这部分的活动包括对用户分类，描述人机交互的脚本，
设计命令层次结构，设计详细的交互，生成用户界面的原型，定义HIC类。
* 任务管理部分（TMC）这部分的活动包括识别任务（进程）、任务所提供的服
务、任务的优先级、进程是事件驱动还是时钟驱动、以及任务与其它进程和外界
如何通信。
* 数据管理部分（DMC）。这一部分依赖于存储技术，是文件系统，还是关系数
据库管理系统，还是面向对象数据库管理系统。
2．3．2 Booch方法
Booch方法的过程包括以下步骤：
。在给定的抽象层次上识别类和对象
。识别这些对象和类的语义
。识别这些类和对象之间的关系
。实现类和对象
这四种活动不仅仅是一个简单的步骤序列，而是对系统的逻辑和物理视图不
断细化的迭代和渐增的开发过程。
类和对象的识别包括找出问题空间中关键的抽象和产生动态行为的重要机制。
开发人员可以通过研究问题域的术语发现关键的抽象。语义的识别主要是建立前
一阶段识别出的类和对象的含义。开发人员确定类的行为（即方法）和类及对象
之间的互相作用（即行为的规范描述）。该阶段利用状态转移图描述对象的状态
的模型，利用时态图（系统中的时态约束）和对象图（对象之间的互相作用）描
述行为模型。
在关系识别阶段描述静态和动态关系模型。这些关系包括使用、实例化、继
承、关联和聚集等。类和对象之间的可见性也在此时确定。
在类和对象的实现阶段要考虑如何用选定的编程语言实现，如何将类和对象
组织成模块。
在面向对象的设计方法中，Booch强调基于类和对象的系统逻辑视图与基于模
块和进程的系统物理视图之间的区别。他还区别了系统的静态和动态模型。然而，
他的方法偏向于系统的静态描述，对动态描述支持较少。
Booch方法的力量在于其丰富的符号体系，包括：
.. 类图（类结构－静态视图）
.. 对象图（对象结构－静态视图）
.. 状态转移图（类结构－动态视图）
.. 时态图（对象结构－动态视图）
.. 模块图（模块体系结构）
.. 进程图（进程体系结构）
用于类和对象建模的符号体系使用注释和不同的图符（如不同的箭头）表达
详细的信息。Booch建议在设计的初期可以用符号体系的一个子集，随后不断添加
细节。对每一个符号体系还有一个文本的形式，由每一个主要结构的描述模板组
成。符号体系由大量的图符定义，但是，其语法和语义并没有严格地定义。
2．3．3 OMT方法
Rumbaugh的OMT方法从三个视角描述系统，相应地提供了三种模型，对象模型，
动态模型和功能模型。对象模型描述对象的静态结构和它们之间的关系。主要的
概念包括：
.. 类
.. 属性
.. 操作
.. 继承
.. 关联（即关系）
.. 聚集
动态模型描述系统那些随时间变化的方面，其主要概念有：
.. 状态
.. 子状态和超状态
.. 事件
.. 行为
.. 活动
功能模型描述系统内部数据值的转换，其主要概念有：
.. 加工
.. 数据存储
.. 数据流
.. 控制流
.. 角色（源/潭）
该方法将开发过程分为四个阶段：
1 分析。基于问题和用户需求的描述，建立现实世界的模型。分析阶段的产物有：
.. 问题描述
.. 对象模型＝对象图＋数据词典
.. 动态模型＝状态图＋全局事件流图
.. 功能模型＝数据流图＋约束
2 系统设计。结合问题域的知识和目标系统的体系结构（求解域），将目标系统
分解为子系统。该阶段的主要产物是：
系统设计文档：基本的系统体系结构和高层次的决策
3 对象设计。基于分析模型和求解域中的体系结构等添加的实现细节，完成系统
设计。主要产物包括：
.. 细化的对象模型
.. 细化的动态模型
.. 细化的功能模型
4 实现。将设计转换为特定的编程语言或硬件，同时保持可追踪性、灵活性和可
扩展性。
2．3．4 Jacobson方法
Jacobson方法与上述三种方法有所不同，它涉及到整个软件生命周期，包括
需求分析、设计、实现和测试等四个阶段。需求分析和设计密切相关。需求分析
阶段的活动包括定义潜在的角色（角色指使用系统的人和与系统互相作用的软、
硬件环境），识别问题域中的对象和关系，基于需求规范说明和角色的需要发现
use case，详细描述use case。设计阶段包括两个主要活动，从需求分析模型中
发现设计对象，以及针对实现环境调整设计模型。第一个活动包括从use case的
描述发现设计对象，并描述对象的属性、行为和关联。在这里还要把use case的
行为分派给对象。
在需求分析阶段的识别领域对象和关系的活动中，开发人员识别类、属性和
关系。关系包括继承、熟悉（关联）、组成（聚集）和通信关联。定义use case
的活动和识别设计对象的活动，两个活动共同完成行为的描述。Jacobson方法还
将对象区分为语义对象（领域对象）、界面对象（如用户界面对象）和控制对象
（处理界面对象和领域对象之间的控制）。
在该方法中的一个关键概念就是use case。use case是指行为相关的事务
（transaction）序列，该序列将由用户在与系统对话中执行。因此，每一个
use case就是一个使用系统的方式，当用户给定一个输入，就执行一个use case
的实例并引发执行属于该use case的一个事务。基于这种系统视图，Jacobson将
use case模型与其它五种系统模型关联：
.. 领域对象模型。use case模型根据领域来表示。
.. 分析模型。use case模型通过分析来构造。
.. 设计模型。use case模型通过设计来具体化。
.. 实现模型。该模型依据具体化的设计来实现use case模型。
.. 测试模型。用来测试具体化的use case模型。
2．3．5 面向对象方法的优点以及与传统方法的比较
面向对象的方法是一种自底向上和自顶向下相结合的方法。它以对象建模为
基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结
构。因此Jackson 方法和PAM中输入、输出数据结构与整个系统 之间的鸿沟在面
向对象方法中不再存在。它不仅具有Jackson方法和PAM 的优点，而且可以应用于
大型系统。更重要的是，在Jackson方法和PAM方法中，当它们的出发点——输入、
输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。但在面向
对象中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
一、需求分析彻底
需求分析不彻底是软件失败的主要原因之一。即使在目前， 这一危险依然存
在。传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种
问题。正是由于这一原因，人们提出了原型化方法，推出探索原型、实验原型和进
化原型，积极鼓励用户改进需求。在每次改进需求后又形成新的进化原型供用户试
用，直到用户基本满意，大大提高了软件的成功率。但是它要求软件开发人员能迅
速生成这些原型，这就要求有自动生成代码的工具的支持。
面向对象方法彻底解决了这一问题。因为需求分析过程已与系统模型的形成过
程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。开发人
员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语
言，避免了 传统需求分析中可能产生的种种问题。
二、可维护性大大改善
在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方
面作出了极大的努力，使软件的可维护性有较大的改进。但从本质上讲，基于功能
分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的
变化，甚至推倒重来。更严重的是，在这种软件系统中修改是困难的。由于种种原
因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件
成本增长失 控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维
护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。功能是对象的使用，
它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此
当需求变化时对象的性质 要比对象的使用更为稳定，从而使建立在对象结构上的
软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。在OO语言 中，子类不仅可以继承
父类的属性和行为，而且也可以重载父 类的某个行（虚函数）。利用这一特点，
我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行（即虚函
数或虚方法）进行重载，也就是对它们重新定义。 由于不再在原来的程序模块中
引入修改，所以彻底解决了软件可修改性，从而也彻底解决了软件的可维护性。OO
技术还提高了软件的可靠性和健壮性。
2．4 CASE的发展和技术方法
2．4．1 CASE的演进
1．早在1986年正式使用CASE来称谓"支持软件工程方法学的计算机辅助手段"
以前,软件工具就已大量出现了。可以说,软件工程从诞生起就面临着如何组织人进
行大兵团作业、如何逐步代替人进行作业两大课题。而且首先是解决前者——确定
有次序、有效率、科学的工程作业方法,然后才能一步步用计算机取代各工程阶段
的人工作业。
CASE的演进是按孤立型→扩充型→接口型→统一型来发展的。 如下：
80年代初，孤立型：文档生成自动化，图表生成自动化，分析设计辅助工具
80年代中，扩充型：分析设计自动化，及其一致性检查，系统信息中心库
80年代后，接口型：根据设计规格自动生成源代码，程序维护工具，项目管理
工具
90年代， 统一型：与AI技术结合，与重用技术结合，向全工程
2.CASE相关概念
CASE技术有两个突出特点:使开发支持工具与开发方法学统一和结合起来;通过实现
分析、设计、程序开发与维护的自动化,提高整个系统开发工程的生产率。由此可
知,工具与CASE工具的一个重要区别是看其是否与方法学有关。但下游工程多数与
方法学无关,所以对下游工具和下游CASE工具常不做区分。
·CASE工具 对某个具体的软件生存期任务,部分或全部地实现自动化的工具
软件。
·智能CASE工具(ICT) 使用最低限度人机接口的CASE工具。
·CASE工具箱 支持软件工程中某一阶段任务或某种开发功能及作业的一组
工具。工具箱里的工具可能集成化,也可能部分集成化。如分析工具箱、设计工具
箱、图形工具箱、项目管理工具箱等。
·CASE工作台 旨在实现整个软件生存期自动化或提供自动化辅助手段的智能
CASE工具的集成。
·CASE系统 使用公共用户接口,并能在公共计算机环境下运行的CASE工具的
集成。
·正向软件工程(Forward Software Engineering ,FSE)CASE支持软件较高
级抽象向较低级抽象求精过程的CASE。
·逆向软件工程(Reverse Software Engineering ,RSE)CASE 支持从已存在
的后期软件状态自动返回正向软件工程过程前期状态的CASE。
·再造软件工程(Resoftware Engineering ,RE,也译作再软件工程)CASE支
持对既存系统根据新需求进行更新、改造、换代的软件工程CASE,包括RSE和
FSE CASE。再软件工程CASE支持维护性软件开发自动化。
·CASE中心库 这是CASE技术的核心概念,是存储、组织所有与特定软件系统
有关信息资源的一种机构,也称为设计辞典、设计数据库、面向目的的数据库、
设计知识库、百科全书等。其根本目的是保证开发全过程中存储信息的一致性、
完整性和方便的共享性。90年代前有用文件系统结构来实现中心库的,目前其主
流为RDB和OODB,也有个别实现了知识库(KB)结构。CASE中心库决定着CASE的集成
化程度和自动化水平。它应是重用库,其结构设计应有利于最大限度地采用既存
重用部件及生成新的重用部件。
2.4.2 CASE与方法学
1.概述
CASE从诞生起就有明确的辅助软件工程的性质,即与软件工程方法学不可分。
在各种CASE目前的实用水平下,一个成功软件项目的关键仍在于选择正确的软件工
程方法,它比使用最好的工具更重要。一个集成的CASE工作台(或系统)所支持的方
法学必须让开发人员知道,正确运用CASE所支持的方法学是正确运用CASE的前提。
将方法学植入CASE大致有两个方向:
(1)方法指导
即让用户边使用CASE边接受方法学指导,方法指导系统贯穿整个开发过程,其
主要指导方式如:
·方法学help系统 可提供应答性指导和主动性指导。
·强制检查系统 检查当前开发任务是否完成,是否符合方法学规则和标准,必
要的最小信息量是否已产生等。只有检查通过才能进入下一阶段活动,以保证开发
过程的顺序性、连续性和完整性。
(2)方法驱动
方法驱动是把软件工程专家们的经验和知识加入到CASE中,使每个CASE使用者
在使用工具的同时还能运用专家的经验,从方法学的繁琐操作和过程性问题中解脱
出来,把精力集中到策略性问题上。这就是智能CASE采用的新技术——方法驱动器
(Method driver)技术。它是把软件工程方法学知识植入CASE工具的专家系统,是人
工智能与CASE技术相结合的产物。它掌握特定方法的处理过程,是真正实现软件自
动化的基础和保证。可支持方法驱动器的CASE中心库必须具有知识库结构。
方法指导与方法驱动的区别在于,前者不能脱离开发人员的指导来独立执行该
方法的处理过程,例如在系统结构设计中具体划分模块的作业必须由开发人员自己
完成,即方法指导系统并未真正理解方法的使用过程;而后者有对方法的理解和处理
能力,它不仅能告诉或建议你该怎么做、指出你的错误及原因、记录被你忽视的地
方,还可以向你提供更好的方法,甚至独立执行特定方法的处理过程。
2.CASE改变着软件工程
如果方法驱动器理论得以实现,软件自动化将成为现实。尽管目前真正实现的
还仅限于方法指导系统,但CASE的迅速发展仍超出了辅助软件工程的范围。近年来
,CASE使软件工程从技术、方法学到观念、认知体系都发生了深刻变化。
(1)简化、缩短了软件工程周期
传统软件工程方法提出了重视上游的理想的软件工程周期模型,它是针对于早
期重视下游的软件工程周期模型。近年来,急于编程已成了软件开发经验不足、缺
乏软件工程常识的重要标志,这势必造成开发人员挣扎在修改差错的没完没了的测
试作业中,并带来下游周期长(占65%)、文档不完备、文档、程序差错率高、开发成
本高等恶性后果。强调上游的软件工程周期模型虽然认识到后果最严重、付出代价
最大的错误都是由分析设计错误造成的,因而从理论上将上游周期提高到60%,下游
周期压到40%,但实现起来上游周期很少达到40%。这与文档和程序生产过程手工化、
急于编程习惯势力太强有关。自动化工具首先把目标放在程序代码生成和程序单元
测试自动化上,并获得了巨大成功,使编码阶段大大缩短、乃至大部分消失,单元测
试工作量也大大减轻,使上游周期有可能扩大到85%。
CASE使下游工程大大简化,使开发人员真正可能把主要精力集中到分析和设计
上。分析设计工具的方法指导系统保证了上游文档的完整性、正确性,使差错诱因、
测试开销降至最少,促成整个工程的良性循环。
(2)改变了系统分析方法
需求分析正确与否是软件工程的出发点和前提,需由用户确认。而用户处于软
件工程约束之外,一般不具备对软件产品的预见能力,所以经过漫长的开发过程后,
产品常常不符合用户需求。其实,再理想的结构化软件工程也难免"需求变更"
———实际上的返工。如果在上游阶段就能确认需求分析正确与否无疑最理想,其
方法即快速原型法,但该法的实现需要软件工具的支持。实践表明,引入CASE支持
下的快速原型开发方法对保证软件质量、消灭返工率、减少下游工作量,并最终提
高开发效率、降低开发成本有显著效果。
(3)简化了软件维护、丰富了软件维护方法
软件工程周期(分析、设计、实现、测试)加上维护期统称为软件生存期。这
里所说的维护是广义的,包括改正性、适应性、完善性维护。一方面,引入CASE后
软件开发自动化程度增高,人工介入减少,加上工具智能化,使软件差错大大减少,
--
※ 来源:．网易 BBS bbs.netease.com．[FROM: 202.96.152.112]
发信人: maomaobug (毛毛虫), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Tue May 18 21:47:21 1999), 站内信件
【 在 connor (虎耳) 的大作中提到: 】
: 当然抄了许多,呵呵.论文不都是这样攒出来的吗?
: 记得当时要完成的首要任务就是把自己的论文看一遍.
: 权当读书笔记把.
: ----------------------------------------------------------这样就没有图和表格
了
: .......
写得不错，但没有时间看！
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.238.47]
发信人: ebug (瞳儿), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Wed May 19 02:28:12 1999), 站内信件
感谢connor我已保存了。会仔细学习。
【 在 maomaobug (毛毛虫) 的大作中提到: 】
: 【 在 connor (虎耳) 的大作中提到: 】
: : 当然抄了许多,呵呵.论文不都是这样攒出来的吗?
: : 记得当时要完成的首要任务就是把自己的论文看一遍.
: : 权当读书笔记把.
: .......
--
风是天的情绪，歌是我的情绪
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.98.118.37]
发信人: margot (可可), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Wed May 19 14:48:15 1999), 站内信件
【 在 ebug (瞳儿) 的大作中提到: 】
: 感谢connor我已保存了。会仔细学习。
: 【 在 maomaobug (毛毛虫) 的大作中提到: 】
: : 【 在 connor (虎耳) 的大作中提到: 】
: : .......
: .......
有没有搞错?! :) :(
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.171.73]
发信人: project (等待...), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Thu May 20 09:23:13 1999), 站内信件
【 在 connor (虎耳) 的大作中提到: 】
: 当然抄了许多,呵呵.论文不都是这样攒出来的吗?
: 记得当时要完成的首要任务就是把自己的论文看一遍.
: 权当读书笔记把.
: ----------------------------------------------------------这样就没有图和表格
了
: .......
怎么不完整？我关心的Rose使用部分没内容？
能给我一份完整的吗？
多谢！
email: [email protected]
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.104.98.83]
发信人: connor (虎耳), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易 BBS (Thu May 20 09:48:54 1999), 转信
: 怎么不完整？我关心的Rose使用部分没内容？
: 能给我一份完整的吗？
:
: 多谢！
:
: email: [email protected]
确实不完整，因为那部分图比较多。
我倒是有ROSE的示例来着，不过要找一找。
好象还是英文的，好想还有一个教程。
都不知道有没有了。
--
※ 来源:．网易 BBS bbs.netease.com．[FROM: 202.96.151.222]
发信人: majorsun (major), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易 BBS (Thu May 20 10:55:19 1999), 转信
如果图的部分可以电子化存储的话，可以放到网站上来，我有空间。
【 在 connor (虎耳) 的大作中提到: 】
: : 怎么不完整？我关心的Rose使用部分没内容？
: : 能给我一份完整的吗？
: : 多谢！
: : email: [email protected]
: 确实不完整，因为那部分图比较多。
: 我倒是有ROSE的示例来着，不过要找一找。
: 好象还是英文的，好想还有一个教程。
: 都不知道有没有了。
--
落英缤纷 拈花微笑
※ 来源:．网易 BBS bbs.netease.com．[FROM: 210.75.59.214]
发信人: project (等待...), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Thu May 20 16:14:25 1999), 站内信件
【 在 connor (虎耳) 的大作中提到: 】
: : 怎么不完整？我关心的Rose使用部分没内容？
: : 能给我一份完整的吗？
: : 多谢！
: : email: [email protected]
: .......
不急，你找到后给我就行！
多谢！
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.182.42]
发信人: youduofu (:-)), 信区: SystemAnalysis
标 题: Re: 当年的毕业论文
发信站: 网易虚拟社区 (Fri May 21 02:11:21 1999), 站内信件
【 在 connor (虎耳) 的大作中提到: 】
你到底怎么把,Rose和Fontpage凑到一起?
这个设计好不好玩?
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.37.201]
|
|