2007年09月04日 16:21:32
为什么要进行软件建模
|
为什么要进行软件建模 1. 什么是模型模型是什么？模型是对现实存在的实体的抽象和简化，模型提供了系统的蓝图。模型过虑非本质的细节信息，抽象出的问题本质，使问题更容易理解。抽象是一种允许我们处理复杂问题的方法。为了建立复杂的软件系统，我们必须抽象出系统的不同视图，使用精确的符号建立模型，验证这些模型是否满足系统的需求，并逐渐添加细节信息把这些模型转变为实现。这样的一个过程就是模型形成的过程，建模是捕捉系统本质的过程，也就是把问题从问题领域转移到解决领域的过程。软件建模是开发优秀软件的一个核心工作，其目的是把要设计的结构和系统的行为联系起来，并对系统的体系结构进行可视化和控制。 最后形成的这个软件模型是非常复杂的，所以要划分成若干互相独立的视图(想象一下描述机器零件的三维视图)以降低其复杂性。由于这种划分，每个独立视图的内容都可以用某种方法来说明，这种方法适用于某个特定的视图，而且不用过多注意其与其他视图之间纷繁复杂的内外部关系。然后，视图之间的关系与模型结合，并且介入过程链的总体分析，而没有任何冗余。 可视化的建模的是使用一些图形符号进行建模(如UML、Aris等)，可视化建模的作用如下：它可以捕捉用户的业务过程，可以作为一种很好的交流工具，可以管理系统的复杂性，可以定义软件的架构，还可以增加重用性。本文所提的建模都是指可视化建模。 2. 为什么要建模 降低模型复杂性的第二种方法就是对不同的说明层次进行分析。现在的软件越来越大，大多数软件的功能都很复杂，使得软件开发只会变得更加复杂和难以把握。解决这类复杂问题最有效的方法之一就是分层理论，即将复杂问题分为多个问题逐一解决。 软件模型（例如用UML进行建模）就是对复杂问题进行分层，从而更好地解决问题。这就是为什么要对软件进行建模的原因。有效的软件模型有利于分工与专业化生产，从而节省生产成本。对于公司而言，也是为了降低软件的复杂程度，便于提早看到软件的将来，便于设计人员和开发人员交流使用了建模技术。对于软件人员来说，模型就好像是工程人员的图纸一样重要。只是目前来看软件模型在软件工程中的重要性还远远没有达到图纸的在其它工程中地位。 企业建模（例如用ARIS进行建模）同样为控制类似复杂的任务提供了有力的支持。在过去，软件开发的目标主要是系统设计最优化，以及使系统有良好的综合性。近几年来，这种目标已经有了较大的转变，而是越来越向为满足企业个别部门的特殊需求而寻求解决方法的方向发展。分布式的信息系统越来越容易取得，而且它们可以与综合信息网络进行结合。这就使得企业在运营过程的组织环境中节省金钱和时间有了新的可能。 在职能上分为若干部分，但各部分都有一个共同的中心取向的凝固式组织结构。使得企业在运营中缺少灵活性，因为这种中心取向依靠于有限可能的集中式的主机环境。开始，很少有人意识到这一点，或是注意到在电脑及电脑服务越来越分散化的情况下，信息系统进一步分散化有了新的可能性，以及随之而来的全新的信息系统的概念。（例如：客户端/服务器，任务流管理，等等）然而，正在稳步加强的竞争已经使它们成了每一家企业最热门的话题。把注意力集中在内部运营过程上的灵活结构有可能会成为企业在竞争中取胜的决定性因素。但是，只有拥有一种全局性的观念才能通过一种最优化的信息系统环境对内部互连的过程进行识别，流线化和形成有力支持。与传统的中心化运营环境的管理方式相比较，这种新的结构的管理方式的灵活性要远远超过前者。在这种情况下，明晰与统一的职能定义，最大透明度的系统结构，能达到各种企业标准的同质通讯基础，以及以企业目标为导向的流线型项目管理，对一个信息系统的成功与否是至关重要的。 而企业建模方法为控制这些复杂的任务提供了有力的支持。对于分析营运过程，使项目与企业总体目标相符合，以及最后找到理想的，兼具分布式及综合式系统优点的信息结构，业务模型都是一个至关重要的先决条件。 3. 建模的好处 Ø 使用模型便于从整体上、宏观上把握问题，可以更好的解决问题 Ø 建模是使你逐层深入解决问题的办法 Ø 确认应用系统的功能需求并为事务处理原则建模 Ø 可以加强人员之间的沟通 Ø 可以更早的发现问题或疏漏的地方。模型为代码生成提供依据 Ø 模型帮助我们按照实际情况对系统进行可视化 Ø 模型允许我们详细说明系统的结构或行为 Ø 模型给出了一个指导我们构造系统的模板 Ø 模型对我们做出的决策进行文档化。 4. 软件建模UML UML（Unified Modeling Language，统一建模语言）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，同样，在网站设计或以网站为表现形式的各种网络应用项目中，UML也表现出强大的作用。UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言，但我们可以用代码生成器将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML模型。 可以看的出，建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进UML模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。 虽然软件建模可以在开发的任何阶段进入，但是在设计初期，应该将精力更加集中在系统功能及性能分析、系统运行环境、选择编程语言等，而不是考虑考虑程序的细节，如在屏幕上的什么位置放置按钮等。在项目开发的中期引入建模是非常有意义的，通过建模把握程序开发的方向，准确完成需求分析中所要求的任务。 区分UML模型和UML图是非常重要的，UML图，包括用例图、协作图、活动图、序列图、部署图、构件图、类图、状态图，是模型中信息的图形表达方式，但是UML模型独立于UML图存在。 5. 业务建模Aris ARIS(architectureofintegratedinformationsystem)是德国Saarland大学的Scheer教授提出的一种面向过程的模型结构。他提出这个模型主要有两个目标：a) 它可以对建模方法进行评价，而且通过对它们焦点问题的进行浓缩的方法而对它们进行集成处理。b) 由于它结构因素上的特点，它可以充当复杂开发项目的定位框架--- 它本身包含一个固有的用于集成系统开发的程序模型。 当然，这样的一个体系结构确实能使建模方法的运用标准化。因此，新的基于ARIS体系结构的建模方法已经被组合运用，以形成一种对营运过程建立模型的整体方法。 不仅如此，ARIS体系结构也是ARIS工具组的开发基础。ARIS工具组是由IDS Scheer AG 开发的一种家用工具。当业务过程重组时，ARIS工具组为资讯者和企业创造，分析和评价公司业务过程提供支持。ARIS 设计通 为业务过程建模和文件证明的简易方法提供了必要功能。 ARIS结构是从过程链模型抽取、发展而来的。在ARIS的概念中，“过程”是由起始事件和终止事件定义的（例如订单处理起始于“已到达的顾客订单”，终止于“已确认订单”甚至是“生产计划”）。过程的对象可以是物质的转变过程（如生产过程），也可以是信息的转变过程（如管理过程）。根据Gutenberg的生产理论，人力、生产设备和信息技术设备都是物质转变过程的相关因素，可用过程来描述、组合这些因素。这样，通过过程链就可以完整地描述企业过程。 为了减少结构的复杂性以及冗余，ARIS对过程链模型进行了简化处理，关注信息的转变，舍弃与信息过程无关的因素，采用更加一般的描述视图，利用分阶段的或者程序化的模型来减少相互间的关系。例如，真实的物质转变过程、物质转变过程中的人的行为、所需的物料及设备，都以“环境条件”的形式出现在信息描述中。这使得从信息过程的角度来看，生产过程不再是物料、人力和生产设备的使用，而是生产过程中数据的交换。这个信息过程的操作还包括：过程计划、路径规划、生产规划和工厂数据收集等。经过处理，过程模型链被分解成五个视图：数据视图、过程视图或功能视图、组织视图、资源视图和控制视图。 Ø 数据视图：描述事件和环境条件，它们表征了信息对象； Ø 过程/功能视图：描述过程规则和过程结构，也就是描述要实现的功能以及功能间的关系； Ø 组织视图：描述使用者和组织单元间的结构关系； Ø 资源视图：描述信息技术设备，例如，CPU、外围设备、网络和数据库等； Ø 控制视图：记录和维护组织视图、数据视图和功能视图间的关系。 在ARIS结构中，组织、数据和功能视图的发展过程是相对独立的，也就是说，发展其中任何一种视图，并不需要利用其他视图的信息，这样大大减少了描述的复杂性和冗余。它们间的关系由控制视图来描述。控制视图是ARIS区别其他结构的重要特征。它用来记录和维护组织视图、数据视图和功能视图间的关系。由于资源视图仅用于描述信息技术设备，因此，根据组织、数据和功能视图与信息技术的结合程度，生命周期模型取代了作为独立描述对象的资源视图。面向生命周期，ARIS定义了三个层次的概念：需求定义、设计说明和实施描述。 例如订单处理过程，整个过程由从事件“已到达的顾客订单”开始。这一事件又影响到随后启动的事件“已接受订单” 的运行（或处理）。为了保证这个操作的执行，对相关环境的状态说明是相当必要的。在这个例子中，状态对顾客以及订单中指定的产品都产生了影响。在工作流处理过程中，环境数据的状态是可以被改变的，举例说明，当预定产品的数据更新时，货物库存的数据也随之更新。这些功能由各部门所属的人员处理完成。部门使用特定的信息技术工具（如个人电脑，打印机等）来完成这些任务。 事件“已确认订单” 即是“已接受订单”的运行结果。事件“已接受订单”引起了其他的附加操作（订单跟踪，生产计划）。 反之，数量众多的，亦作为人力与技术资源的状态说明，在这些操作的运行过程中也是非常必要的。这些资源可以与其他过程的组成成分建立连系。因此，就可能会需要同样的状态说明或使用同样的资源。 类似于 “已收的客户订单” 或“已开发票” 之类的事件对信息目标（数据）的状态差别进行了定义。参考内容的状态，如“客户状态”或“产品状态”也可以以数据的形式来表示。像这样，状态和事件就构成了ARIS 体系的数据视图。 这些要被完成的功能（过程）以及它们的内部关系构成了另一个视图，及功能视图。这个视图包括对功能本身的定义，总体关系之下独立的子功能的列举，以及功能之间存在的地位关系。 组织视图表现的是客户与组织单元之间的结合，同时也表现了它们之间的关系以及与之相关的结构。 信息技术资源构成了第四个说明目标，即资源视图。而这一视图在为说明与业务更加直接相关的成分提供一般条件的范围内，对业务过程中的相关观点是至关重要的。由于这一原因，对其他视图的成分说明 （数据，功能，即组织结构）都是在它们与信息技术资源的接近基础上完成的。由此，这些资源是在其他视图的设计规范和实施描述说明层次进行处理的（见第二章第三小节）。因此，在对不同层次进行分析的基础上而定义的生命周期模型就可以取代作为独立说明对象的资源视图。 把最初的过程划分为若干各子块会降低其复杂性—纵然这要牺牲掉视图的过程成分之间的关系。由于这一原因，控制视图 的概念被作为一个额外的视图而引进于此。它的作用主要是说明视图之间的关系。在一个独立的视图中，这种关系的集成使它有系统的介入系统分析，而不存在冗余。 |
一共有 1 条评论