系统建模就是建立系统抽象模型的过程，其中每一个模型表示系统的一个不同的视角或观点。系统建模现在通常意味着在UML中的图类型基础上使用某种图形化的表示法表示系统。然而，也有可能要开发系统的形式化（数学）模型，通常将其作为详细的系统规格说明。
在需求工程中使用模型，是为了帮助得到详细的系统需求；在设计过程中使用模型，是为了向实现系统的工程师描述系统；在实现系统之后还要使用模型，是为了描述系统的结构和运行。
可以同时针对现有系统和待开发系统开发系统模型：
1.现有系统的模型在需求工程过程中使用。这些模型帮助阐明现有系统做什么，并且可以用于让利益相关者之间的讨论聚焦于当前系统的优势和弱点。
2.新系统的模型在需求工程过程中使用。这些模型帮助解释对其他系统利益相关者所提出的需求。
你可以开发不同的模型来从不同的视角表式系统：
1.外部视角，会对系统的上下文或环境进行建模；
2.交互视角，会对系统及其环境或者系统的构件之间的交互进行建模；
3.结构化视角，会对系统的组织或者系统所处理的数据的结构进行建模；
4.行为视角，会对系统的动态行为以及系统如何响应事件进行建模。
当开发系统模型时，开发者经常可以灵活决定图形化表示法的使用方式。开发者并不总是需要严格坚持一些细节。
图形化模型的3种常见的使用方式：
1.作为一种推动关于现有或所设想的系统的讨论以及使讨论聚焦的方式。
2.作为一种文档化现有系统的方式。
3.作为一种可以用于生成系统实现的详细系统描述。
【UML】
统一建模语言（The Unified Modeling Language, UML）是一组13种不同的图形类型，它们可以用于建模软件系统。UML是在20世纪90年代的面向对象建模方面的工作基础上出现的，其中相似的面向对象表示法被集成到一起创建了UML。
一些调研表明，大多数UML用户认为5种类型的图就可以表式系统的基本特性了。
§5.1上下文模型
在系统规格说明的早期阶段，应当确定系统的边界，也就是说确定哪些属于、哪些不属于所开发的系统。有些时候，系统及其环境的边界相对清楚。而在其他情况下则存在更多的灵活性，你需要在需求工程过程中确定系统及其环境的边界由哪些因素构成。
在有些情况下，系统的用户基础非常分散，用户有很多不同的系统需求。可以采用刻画一个允许系统在部署时再确定边界的可配置系统。系统边界的定义不是一个与价值无关的判断。 会和组织关注点可能意味着系统边界的位置可能要由非技术因素决定。
一旦关于系统边界的一些决定已经做出，需要进行的一部分分析活动是定义系统上下文以及系统对于环境的依赖。通常，产生一个简单的体系结构模型是该活动的第一步。
上下文模型通常显示环境包括多个其他的自动化系统。然而，这种模型没有显示环境中的系统与所描述的系统之间关系的类型。简单的上下文模型可以和其他模型一起使用。业务过程模型描述了人以及自动化的过程，其中会使用特定的软件系统。
§5.2交互模型
所有系统都包含某种类型的交互。可以是用户交互，其中包含用户输入和输出；也可以是所开发的软件和环境中的其他系统之间的交互；或者是软件系统内部不同构件之间的交互。
主要有两个相关的交互建模方法：
5.2.1用况建模
一个用况可以作为一个用户在该交互中对系统的期望的简单描述。如之前所述，用况模型在系统设计的早期而不是需求工程中比较有用。线形小人表示法最初使用时是为了表示与人的交互，但现在也可以表示其他外部系统和硬件。
用框图对于交互给出了一个简单的概览，在此基础上还要增加更多的细节以获得完整的交互描述。这些细节可以是简单的文本描述、使用表格的结构化描述，或者顺序图。
5.2.2顺序图
UML中的顺序图主要用于建模参与者与系统的对象之间的交互以及这些对象自身相互间的交互。顺序图显示在一个特定的用况或用况实例执行过程中发生的交互序列。
§5.3结构模型
软件的结构模型按照构成系统的构件以及它们之间的关系显示系统的组织。结构模型可以是描述系统设计组织的静态模型，也可以是描述系统执行时的组织的动态模型。这两种模型是不一样的——系统的动态组织是一组相互交互的线程，这与系统构件的静态模型很不一样。
5.3.1类图
当开发一个面向对象系统模型来显示系统中的类以及类之间的关联时，可以使用类图。大致上可以将对象类理解为一类系统对象的泛化定义。关联是类之间的链接，表示这些类之间存在某种关系。因此，每个类可能都要具有与之相关联的类的一些知识。
5.3.2泛化
泛化（generalization）是用于管理复杂性的一种日常技术。我们日常生活中并不是从经历的所有事情的详细特性中进行学习的，而是学习通用的类以及这些类的特性。
在建模系统时，检查一下系统中的类，看看是否存在泛化和创建类的空间经常很有用。这意味着通用的信息只需要在一个地方保存即可。这样做的优点在于如果有变更需求，那么不需要在系统的所有类里面寻找可能受变更影响的地方。可以在最高的泛化层次上实施变更。
UML有一个特定类型的关联关系来表示泛化。泛化表示为一个向上指向更泛化的类的箭头。在泛化关系中，与更高层的类相关的属性和操作同样也与较低层的类相关。较低层的类是从它们的父类那里继承属性和操作的子类。这些较低层类可以增加更加特定的属性和操作。
5.3.3聚集
现实世界中的对象经常由不同的部分组成。有时候需要在系统模型中描述这种组成关系。UML为此提供了一种类与类之间的特殊的关联关系类型，称为聚集（aggregation），其意思是一个对象（整体）由其他对象（部分）组成。为了定义聚集，在链接关系中表示整体的那一端加上一个菱形。
§5.4行为模型
行为模型是关于系统在运行时的动态行为的模型。这种行为描述了当系统对来自环境的激励进行响应时发生什么或者应该发生什么。激励可以是数据或事件。
1.系统必须处理的数据产生了。
2.一个事件发生了，触发了系统处理。
许多业务系统是主要由数据驱动的数据处理系统。这些系统由输入给系统的数据来控制，外部事件处理相对较少。它们的处理包括在数据上的一系列动作以及产生一个输出（即IPO模型）。
而相对的，实时系统通常都是事件驱动的，数据处理比较少。
【数据流图】Data-flow diagram, DFD是一种展现功能性视角的系统模型，其中每个转换（transfromation）表示单个的功能或过程。数据流图用于描述数据流如何从一系列处理步骤中流过。UML中的活动图可以用于表达数据流图。
5.4.1数据驱动的建模
数据驱动的模型描述处理输入数据以及生成相关的输出过程中所涉及的动作序列。这种模型可以在需求分析过程中使用，因为它们描述了系统中端到端的处理。也就是说，这种模型描述了从处理一个初始的输入到产生相应的输出（系统的响应）的整个过程所发生的整个动作序列。
数据驱动的模型是最早使用的图形化软件模型之一。20世纪70年代，结构化设计方法将数据流图（DFD）作为一种描述系统中的处理步骤的方法使用。数据模型很有用，因为追踪并描述与特定过程相关的数据是如何在系统中流动的，可以有助于分析人员和设计者理解在此过程中做了什么。数据流图简单、直观，因此对于利益相关者而言比其他类型的模型更容易理解。通常可以向潜在的系统用户解释这些数据流图，从而让他们参与模型的确认。
在UML中，可以使用活动图或顺序图来替代结构化软件工程中的数据流图。
5.4.2事件驱动的建模
事件驱动的建模描述一个系统如何对外部和内部事件做出响应。这种模型建立在系统具有有限数量的状态以及事件（激励）可以导致状态间的转换的假设基础上。这种系统观点特别适合于实时系统。事件驱动的建模在实时系统的设计和文档化中得到了广泛使用。
UML通过状态图（state diagram）支持基于事件的建模，而UML状态图是基于此前提出的状态图（state chart）的。状态图描述了系统状态以及导致状态间转换的事件。状态图不会描述系统中的数据流，但是可以包含关于每个状态中所执行的计算的额外信息。
在UML状态图中，圆角矩形表示系统状态。每个状态可以包含对在该状态中所执行的动作的一个简要描述（在“do”之后）。带标签的箭头表示驱动从一个状态转换到另一个状态的激励。可以像活动图一样使用实心圆表示开始和终结状态。
基于状态的建模的问题是，可能的状态的数量会快速增长。因此，对于大的系统模型，需要在模型中隐藏细节。一种隐藏细节的方式是使用“父状态”（superstate）的概念，在其中封装了一些独立的状态。这种父状态看起来像是高层模型中的单个状态，但是可以在另一个图中展开以显示更多的细节。
系统状态模型提供了关于事件处理的概览，但是通常还要在此基础上扩展更详细的关于激励以及系统状态的描述。可以使用一个表格来列出状态以及激励状态转换的事件，同时包括对每个状态和事件的描述。
5.4.3模型驱动的工程
模型驱动的工程（Model-Driven Engineering, MDE）是一种软件开发方法，其中开发过程的主要产物是模型而不是程序。在硬件/软件平台上运行的程序是从模型自动生成的。模型驱动的工程的支持者坚持认为这一点提高了软件工程的抽象层次，从而使工程师不再需要关注编程语言的细节或者执行平台的细节。
模型驱动的工程是从模型驱动的体系结构（Model-Driven Architecture, MDA）基础上发展起来的。MDA是由对象管理组织（Object Management Group, OMG）提出的一种新的软件开发范型。MDA关注软件开发的设计和实现阶段，而MDE则关注软件工程过程的所有方面。
§5.5模型驱动的体系结构
模型驱动的体系结构是一种关注模型的软件设计和实现方法，使用了UML模型的一个子集来描述系统，其中会创建不同抽象层次上的模型。模型驱动的体系结构（MDA）方法建议应当产生以下3种类型的抽象系统模型：
1.计算无关模型（Computation Independent Model, CIM）。CIM对系统中使用的重要的领域抽象进行建模，因此有时被称为领域模型。
2.平台无关模型（Platform-Independent Model, PIM）。PIM在不涉及实现的情况下对系统的运转进行建模。
3.平台相关模型（Platform-Specific Model, PSM）。PSM是对平台无关模型转换后得到的，对于每个应用平台都有一个单独的PSM。
基于模型的工程允许工程师在较高的抽象层次上考虑系统，不用关心它们的实现细节。这减少了错误的可能性，加快了设计和实现过程，同时还可以创建可复用、平台无关的应用模型。通过使用强大的工具，可以利用同样的模型为不同的平台生成系统实现。
在实践中，很少能做到完全自动化地从模型转换到代码。从高层的CIM到PIM的转换仍然是一个研究问题。而平台无关模型向平台相关模型的转换是一个较简单的技术问题。有一些商业化工具和开源工具可以使用，这些工具使用了一个广泛的平台相关的规则和模式库来实现PIM到PSM的转换。
MDA之所以没有成为主流的软件开发方法还有其他几个原因：
1.模型是一个便于讨论软件设计的好的方法。但是，对讨论有用的抽象对实现而言并不总是正确的抽象。
2.对于大多数复杂系统，实现不是主要的问题——需求工程、信息安全和可依赖性、遗留系统集成和测试都是更重要的问题。
3.追求平台无关性只对大型、长生命周期的系统有意义，其中平台会在系统生命周期过程中逐渐变得过时。
4.在MDA方法发展过程的同一时期，被广泛采用的敏捷方法成功地将开发人员的注意力从模型驱动上吸引走了。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！