文章目录
Chapter5:System Modeling
5.1 brief
5.1.1 System modeling
-
Topics covered
-
统一建模语言、上下文模型、交互模型、结构模型、行为模型、模型驱动的软件工程
UML、外部系统的关系、系统间的交互、系统间结构关系、系统的状态变化和活动过程、通过建立抽象的系统模型自动生成软件。
-
System modeling:
每一个模型都是从一个角度or方面来反应系统。大家一般都用UML语言来modeling
modeling:有助于帮助理解系统的功能、与客户之间的交流。
5.1.2 UML
-
UML语言:
之前的建模语言都是侧重于一个方面,而UML呢,把各种方法组合在一起,形成了一个统一的建模语言。
可用于:可视化、定义、构建、写文档。可用于所有的过程,即:在软件的整个生命周期中都是有效的。
-
UML的由来:
原来三个人有三种方法,后来他们把三种方法组合起来形成了UML,解决了行业内标准不一致的问题即建模不融合的问题。
-
UML各类模型来自于之前的什么方法?
-
UML中各类模型适用于:
use cases and actors:用例图:系统边界和主要功能
interaction diagrams:交互图:用例的实现
class diagrams :类图:系统静态结构
state transition diagrams:状态转移图:对象行为
component & deployment diagrams :组件/实施图:物理实现
stereotypes:构造型:可扩展功能
-
UML里的4种基本元素:
5.2 Things
-
Things :
Class, interface, package, component etc.
5.2.1 Structural thing: Class
-
Class类的三种表示
在软件设计的起初到结束,类逐渐有更深层次的表示。
既可以表示现实世界中的实体,也可以表示软件世界里的对象类。
既可以用于分析阶段,也可以用于设计阶段。
5.2.2 Structural thing: Interface
-
描述了一个类or组件的外部行为。
两种描述方式:1. 简化描述 2. 以interface类的形式来描述
5.2.3 Structural thing: Components
-
物理组件,用于表示系统中实际存在的物理组件,比如 .java,.exe 等
UML用Components Diagram来表示各个组件时间的关系,可以建模整个系统的物理架构,也可以和系统的Deployment Diagram 在一起,反应物理部件在实施中的情况。
5.2.4 Behavioral thing: Interaction
-
两个对象之间的通讯。
例图表示:存在一个由Company发起的对Person的交互Assign
5.2.5 Grouping thing: Package
-
分组事务,把逻辑相关的事务组成一个组,用包package表示出来。
包图常用于建模一个系统的逻辑架构。
package是逻辑相关的事务,component是物理相关的。
5.2.6 Comment thing: Comment
注释事务。
5.3 Relationships
-
Relationships :
association,generalization, dependency, realization
5.3.1 Association
-
association 关联关系
用一根实心的线来关联两个事物。类似于数据库中实体关系模型。
-
聚合Aggregation 和 组合Composition
他们都属于:关联关系 association
聚合和组合都是:整体和部分的关系,a-part-of 关系。
- 聚合:如何没有这样一个部分,整体依然存在。空心菱形。
- 组合:没有这个部分,整体就不存在了。实心菱形。
-
例中:
Order由:运输信息、订单信息、清单信息组成。
我们可以没有ShippingInfo,但是不能没有Book和BillingInfo
5.3.2 Generalization
-
泛化关系、一般和特殊的关系、a-kind-of关系、常在面向对象的系统表示继承关系
空心的三角箭头
5.3.3 Dependency
-
依赖关系:虚线箭头。表示一个事物,会受另外一个事务的影响。
-
CourseSchedule会依赖于Course【参数】,Iterator依赖于CourseSchedule【友元】
5.3.4 Realization
-
实现关系:一个事物是由另外一个事物来实现的。
-
实现分为两种情况,如下图
-
椭圆:代表系统提供的功能or服务。虚线椭圆加虚线箭头 实现 实线椭圆。
即:Order Management 实现 Place Order
虚线椭圆:表示一种协作,是由一系列对象配合完成的,可以用时序图or协作图表示。
5.4 Diagrams
-
Diagrams:
Be made of things and relationships.
Use case diagram, class diagram, sequence diagrams … and other diagrams. -
将Things用Relationship联系起来,就形成了Diagrams
-
不同的Diagrams可以为不同的model服务
-
模型对 existing and planned systems 的作用
对existing system:可以帮助理清已经做了什么,优缺点。
对 new system:便于在此基础上添加新系统。
对model-driven engineering process:可以产生一个完整的系统实现
-
System perspectives 观察系统的角度
静态:反映系统本身的结构特性:类、结构、部署动态:反映行为、状态变化、工作流程、各个对象or组件之间的交互
-
Use of UML diagrams 【各种图的适用】
5.5 Models
5.5.1 Context models & System boundaries
Context models:
反映一个系统的边界情况,和其他系统之间的关系,在整体环境中的所处位置。
System boundaries:
- define what is inside and what is outside the system.
- has a profound effect on the system requirements.
例子:Mentcare系统的context model
也就是说,在开发Mentcare这个系统的时候不需要考虑Patient record等一系列系统。
5.5.2 Process models & activity diagram
过程模型:揭示大量的业务处理过程是。用UML中的activity diagram来做process model
例子:非自愿拘留的过程模式
5.5.3 Interaction models
-
Interaction models 两类:
-
Modeling system-to-system interaction :use case diagram
-
Modeling component interaction :sequence diagram
-
-
Use case models
-
用例最初是为了支持需求捕获Requirements elicitation而开发的,现在被合并到UML中。
-
每个用例代表一个离散的任务discrete task,它涉及到与系统的外部交互。
-
用例中的参与者Actors可能是人people或其他系统other systems。
-
用图表的形式表示,以提供用例的概述,并以更详细的文本形式表示。
例子:
Medical receptionist 发起交互,目标是Transfer data;Transfer data 发起交互,Patient record system是接收方,接收方一定有对应的接口。
系统的use-case diagram是粗粒度的,概要性的,所以需要一个表格模板use-case description来描述细节
-
-
Sequence diagrams
components in system;actors和objects之间的交互。
时序图,是在特定用例执行的时候,发生在期间的交互的顺序。
一个用例是一个粗粒度的、概要性的功能描述,通过若干个组件和对象来协作完成用例的功能。
序列图展现的就是若干个组件和实体以及actors之间的顺序交互,实现这个用例的过程。
例子:Sequence diagram for View patient information
第一排:objects + actor 【P是Patient Info这个类的实例or对象】四列:虚线表示时间线,蓝色空矩形框表示:对象的生命周期【对象从产生到消亡(撤销)的过程】
alt矩形框:代表两种不同的情况下,认证OK和fail的情况,的两种事件流。
【时序图,是用来详细描述,用例图,的内容】
在用例图View patient information中:有1个actor和三个objects来交互协作,他们协作的sequence是由箭头所示。
对象之间的交互消息,可能是程序中的方法调用【method invocation】
系统模型可以用在分析和设计阶段建模,这章模型更多的是设计模型,因为更多是软件世界里的元素。但是如果病人病历、医院档案库、认证机构,那么这个模型就可以认为是分析模型。业务模型、分析建模、粗粒度;软件模型、设计模型、细粒度。并且分析和设计的界限比较模糊,没有统一标准。
5.5.4 Structural models
结构模型往往是静态的,但也有动态的。
表示系统的结构组织、各个类之间的结构关系,程序执行情况下的执行关系。
-
Class diagrams
是Structural models里的
反应类之间关系的【上面讲的4种】
在现实世界的一些系统,其中的一些事物or人可以用对象类来表示。
分析阶段分析模型其中的一种。
例子1:Patient和Patient record的类图
例子2:Classes and associations in the MHC-PMS 【1对1 and 1对多关系】
例子3:consultation类
-
Generalization
用泛化关系,来描述OO中父类子类的继承关系。减少复杂性manage complexity。
例子:
类图1:描述父类doctor和各个子类的继承关系
类图2:还包含了每个类的细节
5.5.5 Aggregation model
5.5.6 Behavioral models
系统执行时的动态行为dynamic behavior。
描述的是一个系统在受到外部环境的触发stimulus时,系统的响应行为。
两种stimulus:
-
data:当数据到达的时候,系统会如何处理。
-
events:一些事件的发生,也会出发系统处理。
5.5.7 Data-driven modeling
5.5.8 Activity model
-
Sequence model例子
不是以数据为中心的,但是是处理的数据。适用于OO系统的算法设计,由多个对象合作。描述业务处理过程可以采用数据处理模型or时序模型,前者:工作流的顺序,后者:实体间的协作顺序。
5.5.9 Event-driven modeling
5.5.10 State machine models
例子:微波炉的状态图
5.6 Model-driven architecture(MDA)
5.6.1 brief
-
同样的,还需要对每个状态进行详细解释,见ppt20表
-
此外,状态图可以zoom in&out,从而体现不同的层次,如下是对operation的zoom in
-
Model driven architecture(MDA)
模型驱动的体系结构MDA,通过UML建模来产生一个Model
可以构建不同层次的抽象模型。
若构建的UML模型满足形式化的,有附加精确的数学定义,则可以自动出来程序
5.6.2 types of model
-
Types of model
CIM:问题域层次的抽象
PIM:独立于实现平台,不管我是采用J2EE还是.NET。
PSM:特定平台模型,主要是在PIM的基础上加入了特定平台的一些细节
-
从高层抽象的独立模型到可执行代码的过程
-
Multiple platform-specific models
5.6.3 Agile methods and MDA
如果一个程序可以通过PIM完全自动生成,那么原则上这个程序可以用于敏捷开发。
If transformations can be completely automated and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process
5.6.4 Executable UML
-
Executable UML
前面讲的都属于半形式化模型。光靠这样的模型还不能自动生成代码completely automated transformation ,还需要加一些形式化的定义。
UML发展到UML2,UML2 + OCL(对象约束语言) = xUML(可执行UML)
xUML是UML的一个子集。
-
Features of executable UML