系统建模_系统建模工具updm - CSDN
精华内容
参与话题
  • 系统建模

    2011-09-10 21:17:20
    当接手了一个项目,第一部是进行可行性分析,第二步是进行需求分析(可参考本人另一篇博客),完成需求分析后,... 用例建模是客户需求分析的重要组成部分,它从最终用户的角度来理解软件系统的需求,强调谁在使用系统,系统

            当接手了一个项目,第一部是进行可行性分析,第二步是进行需求分析(可参考本人另一篇博客),完成需求分析后,可以画出系统业务功能需求框图.接着便可以进行用例建模了.

            用例建模是客户需求分析的重要组成部分,它从最终用户的角度来理解软件系统的需求,强调谁在使用系统,系统可以完成哪些功能.

            用例建模一般有以下几个步骤:

                 (1) 业务需求分析.这在个过程中分析系统的业务需求,有时业务需求会很庞大,这个时候需要将一些子系统合并.

                 (2) 确定系统边界.这是在业务需求分析结束后,整理规划出整个系统的分割,以及确定每部分的范围.

                 (3) 确定执行者.通过对业务需求的分析可以得到在系统外的执行者.一般分为若干执行者以及若干系统执行者.执行者主要是操作用例.

                 (4) 确定用例.划分了系统边界,那就可以得出系统边界内有多少个用例,系统边界外有多少个执行者.并对用例之间的关系加以适当的描述.

                 (5) 绘制用例图.用图的形式表现出用例与用例之间的关系,让人更容易理解.

                 (6) 描述用例.对每个用例进行描述,一般包括用例名,执行者,目的,过程描述,异常事件处理流.这部分要尽可能的详细地对用例进行描述.因为这是后面对象类建模的信息来源.

                 (7) 对每个子系统进行从(1)开始的过程,直到把系统描述完毕.

           

           对象类建模的主要工作就是从客户需求和系统分析阶段抽象出对象类,类有三种主要的版型:实体类,边界类,控制类.

            实体类可以创建持久对象,持久对象可以存放进持久存储体.对于关系数据库而言,通常每个实体类映射数据库中相应的一个二维表,实体类中的属性对应该表中的字段,而每个对象就是该表中的一条记录.

             边界类位于系统与外界的交界处,包括所有窗体,报表,以及表示通信协议的类,直接与外部设备交互的类,直接与外部系统交互的类等都是边界类.通过用例图可以确定需要的边界类,每个执行者/用例对至少要有一个边界类,但并非每个执行者/用例对要有唯一的边界类.

             控制类是控制其他类工作的类.每个用例通常有一个控制类,用来控制用例中事件发生的顺序,控制类也可以在多个用例间共用.其他类一般不向控制类发送消息,而是由控制类向其他类发出消息.

           以下主要以CRC技术进行说明对象类建模的流程.

           类--责任--协作者(Class-Responsibility-Collaborator,CRC)技术是一种简单有效的面向对象的分析技术,它实际上是一组描述类的索引卡片,每张卡片分成3部分:类名描述,类的责 任描述和类的协作者描述其是开发一个有组织的类的表示法.CRC卡片的格式如下:

    ----------------------------------------------------------------

    |   类名:                                                                       |

    ----------------------------------------------------------------

    |   类的类型:(如:设备,角色,场所等)                         |

    ----------------------------------------------------------------

    |   类的特征:(如:有形的,原子的,并发的等)              |

    ----------------------------------------------------------------

    |   责任:                          |   协作者:                            |

    ----------------------------------------------------------------

               CRC卡片的格式

            对象类建模(采用CRC技术)一般有以下几个步骤:

                 (1) 确定类对象.

                           (a) 发现潜在对象

                           一组具有相同属性和操作的对象可以定义成一个类,因此标识类和标识对象是一致的.通常陈述中的名词或者是名词短语是可能的对象.例如:

                            * 与系统交互的角色.如管理者,管理员.

                            * 系统的工作环境场所.如车间,办公室.

                            * 概念实体,发生的事件或者事件.如报告,显示,信函.

                            * 部门.如学校.

                            * 设备.如汽车,计算机.

                            * 与系统有关的外部实体.如其他系统,设备,人员等,他们生产或消费计算机使用的信息.

                          (b) 标识对象名的原则

                            * 使用单个名词或名词短语.

                            * 对象名称必须简洁是明了.

                            *尽量使用用户熟悉的行业标准术语.

                         (c) 筛选对象

                            * 可以根据关键性,可操作性,信息含量,公共属性,公共操作和关键外部信息等来选择和确定最终的对象.

                         (d)对象分类

                            * 对象还可以根据有形性,包含性,顺序性,持久性,完整性等特征来进行分类.


                 (2) 标识对象类的属性,属性描述对象类的静态特征.

                          (a) 可以从以下角度来发现和确定对象潜在的属性

                            * 常识性: 按一般常识,该对象应具有的属性

                            * 专业性: 在当前问题论域中,该对象应具有的属性.

                            * 功能性: 根据系统功能的要求,该对象应有的属性.

                            * 管理性: 建立该对象是为了保存和管理哪些属性.

                            * 操作性: 为了实现对象的操作功能,需要增设哪些属性.

                            * 标志性: 是否需要增设属性来区别对象的不同状态.

                            * 外联性: 用属性来表示对象的整体-部分联系和实例连接.

                          (b) 在确定了对象的属性后,应对各属性命名以示区别.还 应该对每个属性加以详细说明,包括以下信息:

                            * 属性的解释.

                            * 属性的数据类型.

                            * 属性的取值范围以及对象所体现的关系.

                            * 属性的实现要求和其他.


                 (3) 标识对象类的操作.对象的操作可以理解为对象应该展现的外部服务的总和.操作定义了对象的行为并以某种方式修改对象的属性值或系统的状态.通常描述中的动词可以作为候选的操作.类所选择的每个操作都展示了某种行为.

                          (a) 命名操作的标识名

                            * 一般按约定命名.

                          (b) 对每个操作应加以详细说明,包括以下信息:

                            * 操作解释: 作用与功能.

                            * 消息协议: 入口消息格式.

                            * 消息发送: 执行期间,需要请求哪些其它对象的操作.

                            * 约束条件: 执行的前置,后置条件及执行事件等说明事项.

                            * 操作流程: 对复杂的操作应画出操作过程流程图.


    展开全文
  • 业务建模和系统建模

    千次阅读 2004-07-15 15:59:00
    业务建模:用用例的观点来研究业务.把业务内的各种流程看做是为业务执行者提供价值的方式. 业务执行者和业务工人: case:医院:业务是治病 业务执行者:患者 业务工人:医生,收费员等. 由此可见,系统执行者不一定就是业务...

    业务建模:用用例的观点来研究业务.把业务内的各种流程看做是为业务执行者提供价值的方式.

    业务执行者和业务工人:

       case:医院:业务是治病

                业务执行者:患者

                业务工人:医生,收费员等.

       由此可见,系统执行者不一定就是业务执行者.

    展开全文
  • 需求分析——系统建模方法

    千次阅读 2019-07-31 07:37:07
    (1)数据体系结构(data architecture):数据体系结构为业务功能的信息需要提供了一个框架,包含许多业务过程中使用的数据对象,(确定E-R是使用...(2)应用体系结构(applications architecture):由多个系统...

    需求分析学习指导目录:https://blog.csdn.net/weixin_42562514/article/details/90572761

    (1)数据体系结构(data architecture):数据体系结构为业务功能的信息需要提供了一个框架,包含许多业务过程中使用的数据对象,(确定E-R是使用);

    (2)应用体系结构(applications architecture):由多个系统构件组成,这些构件为业务过程变换数据体系结构中的数据对象,(use-case 动态模型);

    (3)技术基础设施(technology architecture):为数据体系结构和应用体系结构提供支持,包括硬件和软件,(硬件:服务器、主机、网络、交换机、路由器;内存:软件:操作系统、数据库、LAMP);

    LAMP:Linux、Apache网页服务器、MySQL、PHP脚本语言。

    展开全文
  • 系统建模过程

    2013-01-09 14:33:54
    系统建模过程 第15章 简述 面向对象的软件工程,同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别。 UML 是 OOA 和 OOD 的常用工具。使用 UML ...
    第四部分 系统建模过程

    第15章   简述

    面向对象的软件工程,同传统的面向过程的软件工程相比,在需求的获取、系统分析、设计和实现方面都有着很大的区别。 UML OOA OOD 的常用工具。使用 UML 来构建软件的面向对象的软件工程的过程,就是一个对系统进行不断精化的建模的过程。这些模型包括用例模型、分析模型、设计模型,然后,我们需要使用具体的计算机语言来建立系统的实现模型。当然,在整个软件工程中,我们还需要建立系统的测试模型,以保证软件产品的质量。

    使用面向对象的工具来构建系统,就应该使用面向对象的软件工程方法。然我,我们经常会发现,在实际的开发过程中,很多开发人员虽然能够理解 UML 的所有图形,却仍然不能得心应手的使用 UML 来构建整个项目,其很大的原因,是仍然在使用原有的软件工程方法,而不清楚如何使用 UML 来建立系统的这些模型,不清楚分析和设计的区别,以及他们之间的转化。

    应用软件系统,就其本质来说,是使用计算机对现实世界进行的数字化模拟。应用软件的制造过程,按照 UML 的方法,就是建立这一些列模型的过程。本文将就一个图书馆系统,说明如何使用 UML 来对系统进行这一系列的建模。

    关于这个图书馆系统,基本的需求比较简单,就是允许学生可以在图书馆借阅和归还图书,另外,也可以通过网络或者图书馆的终端来查阅和预订书。当然,图书馆管理员也可以对图书进行管理。为了简化系统,我们没有把图书馆中的人员作细分。

    之所以采用这个相对简单案例,是因为很多人都对图书馆系统有很强的感性认识,这样,读者不需要花很多的时间来理解系统包含的业务知识。同时,也因为本文只是对使用 UML 的过程做一个探讨,着眼于使用 UML 进行建模的过程,说明各个层次的模型之间的区别和联系,展示系统演进的过程,而不会深入 UML 的细节方面。对于更加复杂的系统,其分析和设计的方法是相通的,可以举一反三。


    第16章   用例模型——系统需求的获取

    用例模型定义系统做什么,是用来获取系统需求的有效手段。用例模型由“角色”和“用例”组成。我们在构建一个用例的时候,通常要做的第 一件事情是识别角色,或者说,参与者。然后我们我们需要识别系统为参与者提供的服务,或者说,参与者的行为,也就是用例。最后,我们确定角色和用例之间的 关系。在这个图书馆系统中,我们可以识别出的角色有学生和图书管理员。整个用例模型包含的用例有:借书、还书、查阅图书、预订图书,以及图书维护。用例模 型可以用用例图表示如下:

     

    确定有效用例的关键是,检查用例是否包含了一个完整的功能。用例不能定的过细,不能把一个完整的功能的一个部分作为一个用例,也不能在 一个用例中包含过多的功能。例如,用户的登录。学生在预定图书的时候,可能会需要首先登录系统,这是系统的一个功能。但是,这个功能只是预定图书这个完整 的功能中的一个步骤,或者说一个子功能,就不适于做成一个用例。另一方面,借书和还书,都是相对完整的功能,如果把这两个用例合并成一个类似于“处理图 书”的用例,显然是不能明确的表达用例需要表达的含义的。

     

    描述用例

    需要了解的是,使用 UML 进行系统建模,并非只是意味着画 UML 图形,对 UML 图的文档说明是同样重要的。学习 UML ,不仅仅要学习 UML 图形,相应的文档描述方法也同样要学习,也同样重要。

    在描述用例时,我们可以用文字来描述,也可以用其他图形来描述,例如,顺序图或者活动图等等。下面给出了一个 RUP 中推荐的描述用例的完整的结构:

     

    w   名称 。名称无疑应该表明用户的意图或用例的用途,如 研究班招生

    w   标识符 [ 可选 ] 。唯一标识符,如 "UC1701" ,在项目的其他元素(如类模型)中可用它来引用这个用例。

    w   说明 。概述用例的几句话。

    w   参与者 [ 可选 ] 。与此用例相关的参与者列表。尽管这则信息包含在用例本身中,但在没有用例图时,它有助于增加对该用例的理解。

    w   状态 [ 可选 ] 。指示用例的状态,通常为以下几种之一:进行中、等待审查、通过审查或未通过审查。

    w   频率 。参与者访问 此用例的频率。这是一个自由式问题,如用户每次录访问一次或每月一次。

    w   前置条件 。一个条件列表,如果其中包含条件,则这些条件必须在访问用例之前得到满足。

    w   后置条件 。一个条件列表,如果其中包含条件,则这些条件将在用例成功完成以后得到满足。

    w   被扩展的用例 [ 可选 ] 。此用例所扩展的用例(如果存在)。扩展关联是一种广义关系,其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有 <<extend>> 的用例关联来建模的。

    w   被包含的用例 [ 可选 ] 。此用例所包含用例的列表。包含关联是一种广义关系,它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是使用带有 <<include>> 的用例关联来建模的。也称为使用具有 (has-a) 关系。

    w   假设 [ 可选 ] 。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设,或者将它们变为决策的一部分,或者将它们添加到操作的基本流程或可选流程中。

    w   基本操作流程 。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式,所以通常称其为适当路径 (happy path) 主路径 (main path)

    w   可选操作流程 。用例中很少使用的逻辑路径,那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。

    w   修改历史记录 [ 可选 ] 。关于用例的修改时间、修改原因和修改人的详细信息。

    w   问题 [ 可选 ] 。如果存在,则为与此用例的开发相关的问题或操作项目的列表。

    w   决策 。关键决策的列表,这些决策通常由您的 SME 作出,并属于用例的内容。将这些决策记录下来对于维护团体记忆库 (group memory) 是相当重要的。

     

    下面,我们对借书这个用例来做描述:

     

    名称 :借书

    说明 :学生在图书馆挑选好需要的图书后,通过图书管理员把书借回去。

    参与者 :学生,图书管理员

    频率 :每天可能会有很多次。最繁忙的情况是,借书的人非常多,按照现在的速度,大约每分钟完成一个人的结束工作。

    前置条件 :无

    后置条件 :修改所借出的图书的剩余数量。

    假设: 借书者总是从图书馆找到书,然后才能拿书办理借书手续,因此,总是有足够的书可以出借。

    基本操作流程 :借书成功。

    1)  学生将所借图书和借书证交给图书管理员

    2)  图书管理员将学生借书证号码和所借图书输入系统

    3)  系统校对借书信息,比对该学生以往借书情况和当前借书情况,如果不存在不允许借书的情况,则记录借书交易的信息,并且修改相应的馆藏图书的数量信息。

    4)  如果该学生已经预订了这本图书,则撤销该预定。

    5)  报告交易成功。

    可选操作流程 :所借图书超出最大借书数量。

    1)  学生将所借图书和借书证交给图书管理员

    2)  图书管理员将学生借书证号码和所借图书输入系统

    3)  系统校对借书信息,比对该学生以往借书情况和当前借书情况,发现已超出最大借书数量,则停止当前交易,并且提示用户错误原因。

    4)  图书管理员可以应学生的意见,减少借书数量,并重新提交系统。

    流程活动图: 见图一。

     

    图一:借书活动图

    问题: 暂无

    决策 :略。

     

    上面,我们就这个用例做了一个比较详细的描述。按部就班,我们就可以逐步把整个系统的用例模型完成。

    再次强调一点,使用 UML 建模,文档说明和图形同样重要,并且,要使用 UML 的方法来编写文档。


    第17章   分析模型——开发者的视野

    在系统分析的过程中,我们所关注的依然是问题,但是,同用例模型不同的是,用例模型是从最终用户的角度来看待问题,而分析模型是从开发 者的角度来描述问题。用例模型的主要工作是描述现实世界的业务流程,而很少会涉及系统的概念。分析,则是从系统的角度来来看待软件应该为用户提供的服务。 同样,同设计不同的是,分析仍然停留在“做什么”的层次,。而设计,则需要解决“怎么做的问题”。

    开发语言等技术选择通常不会在分析模型中考虑。分析模型是独立于实现的,这样,可以提供最大的复用,并且,可以帮助开发人员方知过早的陷入技术的细节中去,从而能够从一个更加一般的角度去理清思路。

     

    静态模型的建立

    进行分析建模的第一步,通常是识别对象,然后提取出类。考虑著名的 MVC 模式,我们需要识别实体、控制和边界三种对象。按照 MVC 模式来为识别对象做指导,是非常好的做法。对象识别的结果,就是我们所需要的静态模型,通常表现为类图。

    我们首先识别出实体对象,这些对象通常来说是比较明显的,例如系统中的角色,系统需要处理的资料,如本系统中需要处理的图书资料等;有 些实体对象需要稍微分析一下才能得到,例如,在本系统中,为了记录图书借还的信息,我们可能需要一个对象来专门记录这一信息。这些对象就是所谓的 Modal (实体类)。

    然后我们需要识别为了完成系统业务逻辑而需要的业务逻辑对象,以及同用户进行交互的界面类,在 MVC 模式中,他们分别对应于 Control (控制类)和 View( 边界类 ) 。在分析阶段,这些对象通常都按照比较自然的方式来组织,例如,为了完成一个业务功能,我们通常需要一个控制类和一个边界类,控制类执行业务逻辑,边界类同客户进行交互。当然,这不是绝对的,在进行进一步深入的分析后,这些类可能会被分解和合并。

    一口不能把所有的饭都吃掉,系统分析也是这样。我们需要一个一个用例的来进行分析。现在,我们首先来分析借书这个用例。

    在这个用例中,我们首先可以识别出一些直接的对象,包括图书管理员 (BookAdmin) 、学生 (Student) 、图书 (Book) ,然后,稍作分析,我们会发现我们需要一个实体对象来记录图书的借还信息 (BorrowInfo) 。最后,我们发现,在借书的过程中,我们会使用到预定图书的信息( SubscribrInfo )。到这一步,我们基本完成了实体对象的识别。然后,我们发现我们需要一个借书的控制类 (Borrow) 来执行借书的动作,以及一个用户界面( BorrowInterface )来接受用户的输入。这样,初步的模型我们就可以建立了。

     

    图二:借书类图

     

    在分析模型中,我们也需要识别出类的一些属性和方法。同样的,为了避免过早的陷入细节中,以及适应将来在设计时类的变化,在分析模型中,我们一般只把一些主要的属性和方法标识出来。例如,对于 Student 类,我们只需要 Name CardNo (借书证号)属性,对于 Book ,我们只需要 BooKID AllCount( 书的总数 ) CurrentCount( 当前数量 ) 等属性。现在,我们为我们的类图添加上述属性,就可以得到下面的结果:

     

     

    图三:借书类图

     

    不过,把这些属性都标上后,图形就比较难布置。因为文章版面的问题,在以后的文字中,除非必要,一般会把属性都隐藏起来,这样,看起来会整洁一些。

    依样画葫芦,我们把还书、查阅图书、预定图书、管理图书这些用例一并分析后,我们就能够得到整个系统的静态分析模型。

     

    当然,我们随后需要对这个初步的模型作进一步的整理和分析,类图会发生变化,各个类之间会产生一些联系。我们也可能会使用一些分析模式,来进一步优化我们的分析结果。关于分析模型的知识,可以参见 Martin Fowler 所著的《 Analysis Patterns —— Reusable Object Models 》一书。在这里,我们就不进一步做探讨了。

     

    动态模型的建立

    在面向对象的系统中,业务流程表现为对象之间的交互。我们有了上面分析的得到的对象后,就可以来描述他们是怎么进行交互和协作的了。在 UML 中,我们可以使用顺序图、活动图或者状态图来建模这些动态的过程。同样的,我们首先来看借书这个用例。

    在借书这个用例中,有两个事件流:借书成功(正常事件流)和所借图书超出最大借书数量(非正常事件流)。我们首先来做“ 借书成功 这个事件流,下面是这个事件流的顺序图:

     

    分析过程中,消息的传递同后面的设计模型和实现模型相比,可能会有区别,也不太严密,例如, Borrow 的过程中,记录 BorrowInfo 的动作,到最后,可能不会是 BorrowInfo 这个实体类自己来记录(往往会有一个实体访问类来完成这个功能,如 JDO 中的 PersistanceManager ,这取决于你采用的具体的技术框架),但是,在这里,我们可以这样来传递消息,表示需要记录这个信息。

    同样的,我们也可以为“所借图书超出最大借书数量 ”来作他的顺序图,这个图相对简单一些:

     

    同样的,我们也可以为其他用例的其他事件流创建动态模型,在这里就不一一画出来了。

    动态模型和静态模型的建立是一个交互的过程。在建立动态模型的过程中,我们会发现一些新的类,也会为已有的类找到一些新的属性和方法,这样,我们会需要去修改我们的类图。反之亦然。

    当分析模型完成后,我们就对系统需要完成的功能有了一个比较完整和清晰的认识,下面,就可以开始我们的设计工作了。


    第18章   系统设计——实现方案

    设计是对系统的详细描述。我们需要在这里提供详细的解决方案。设计同分析所使用的工具一样,也需要建立静态和动态的模型,也同样使用类图、顺序图、协作图、活动图、状态图等来表示。

    在正式进行设计之前,我们还有一些工作需要完成,那就是选择我们的技术方案,这会影响到我们设计。

     

    技术选择——设计前的工作

    设计是为实现服务的,实现时准备采用的技术会影响设计方案的采用。以下这些技术问题是需要考虑的:

    u   准备使用什么样的客户端?

    u   准备采用什么编程语言?

    u   准备采用什么框架技术?

    u   如果是分布式系统,那么,准备采用什么通信机制?

    在这个图书馆系统中,我们发现,对于借书和还书来说,总是在图书馆内部发生,并且客户端的数量是有限的数个,其使用的频率比较高,效率和使用的方便性是需要注重考虑的,而客户端软件的维护工作量相对比较少,可以不用考虑太多,因此我们准备采用传统的 Windows Form 的客户端。但是,对于图书的查阅以及预定来说,我们希望在整个校园网内提供这个功能,使得学生无论在什么地方都能够使用这个功能,所以,我们会考虑采用 Web 浏览器的客户端,这样会方便系统的部署。也就是说,我们的系统需要同时支持两种不的客户,显然,采用 N 层系统结构,把系统逻辑集中在应用服务器上是一个比较好的方案。最后,为了系统的安全,我们希望把 Web 服务器和应用服务器分开。这样,我们的系统的架构的拓扑图就基本上如下所示:

     

    这是一个典型的分布式系统,在考虑了各种平台和技术之后,我们决定采用 EJB 技术来构建这个系统,他已经为我们提供了构建应用系统所需要的优秀的技术框架,同时,我希望在客户端和应用服务器的调用中,采用 Web Service 的方式(试验一下新技术:))。 Windows Form 的客户端,我们使用 Java 来创建一个 Windows 应用程序, Web 客户,则采用 JSP 技术。

    当然,你也可以采用微软的 .Net 平台以及 C# 语言来完成这个工作,但是由于微软在 .Net 平台上尚未提供象 J2EE ,或者 JDO 一样成熟的应用系统框架,因此,你必须自己来设计这个框架。在这个方面,鄙人也设计了一个自己的 Websharp 框架,或许可以帮助你省略这方面的工作。关于 Websharp 的内容,可以参见拙作 《面向对象的应用服务层设计》

    这样,我们在具体技术方面的决策基本上就完成了,可以开始进行具体设计了。当然,在实际项目中,可能还有很多细节的工作需要去做,例如系统的约定,设计规范等,但这不是本文讨论的内容。

     

    设计包或者子系统

    首先我们需要来对系统进行一个划分。因为我们的系统是一个 N 层的分布式系统,包含了应用服务器和客户端,而客户端又包含了 Windows Form 客户端和 Web 客户端,所以,我们首先把系统分成 3 个包:应用服务器、 Winform 客户和 Web 客户:

     

    因为我们的系统包含了 5 个用例,每个用例都是一个完整的子系统,因此,我们可以在上述 3 个包的下面,又各自划分成 5 个子包。但是,在这里,因为系统比较简单,每个用例需要完成的功能都比较简单,因此,在这里我们就不错进一步的划分了。

     

    设计应用服务器

    下面,我们首先来设计应用服务器部分。我们还是从借书这个用例开始设计。

    从分析模型中,我们知道,需要一个控制类来完成借书的业务逻辑,在这里,我们设计一个 BorrowLogic 类来完成这个功能,这个类被设计成 SessionBean ;同时,因为我们需要向客户端提供服务,而我们又不希望直接把业务逻辑暴露给客户端,所以,设计 BorrowServer 这个 Web Service 来向客户端提供服务。这样,实际上,在分析模型中的 Borrow 类,在这里,被映射成了 BorrowLogic BorrowServer 两个类。

    同样的,我们需要 Book 类来记录图书的信息, Student 来标识学生,我们也需要 BorrowInfo SubscribeInfo 类来分别记录借书和图书预定的情况。这样,建立设计模型中的静态模型所需要的类基本上已经齐全了。当然,到最后阶段,我们需要为这些类补充完整属性和方法。这些实体类,最后都被设计成 EntityBean

    这个部分的整个设计模型看上去就基本上会是这个样子:

     

     

    然后,我们来为借书成功这个事件流设计他的动态模型。我们还是使用顺序图来表示之。

     

     

    设计客户端

    现在,我们为借书成功这个事件流来设计客户端。客户端在这里比较简单,他需要一个界面来接受输入,然后,通过一个 BorrowServer 的客户端把借书的请求发送给 BorrowServer ,我们把这个类设计成 BorrowClient 。类图如下所示:

     

    Sequent 图可以表示如下:

     

     

    这样,对于借书这个用例,我们就完成了他的设计。依葫芦画瓢,我们就能够完成其他用例的设计。当然,在设计的过程中,我们可能采用一些 技巧,来使得我们的设计更加有弹性,更加合理,这是对系统设计的优化。关于这个内容,最好的书籍莫过于著名的“四人帮”所著的《设计模式》一书了。

    设计的最后工作,是根据我们设计的对象模型,把数据库的工作完成,并且,给出对象同数据库的映射关系。这个,就不是本文所准备讨论的问 题了。另外,从某种意义上来说,数据库的设计,实际上是实现模型所需要完成的工作,他是实现我们的设计的一个部分的工作。这个观念,同原来的设计方法中, 设计工作的主要任务就是做数据库设计的观念,不能不说是一个挑战。

    可以看出,对于同样一个用例,在分析模型中的一个模型,在设计模型中被拆分成了两个部分。这时因为,在分析中,我们关注的还是系统的逻 辑问题,而在设计中,我们必须给出实现这些逻辑的解决方案,包括系统的架构、系统的部署、应用的分布等。在分析模型中的一个类,在设计模型中可能会被映射 成两个类,当然,也可能在分析中的多各类,会在设计中被映射成一个类。对于分析和设计的这些不同的侧重点和区别,是我们需要注意的。

     

    实现模型——构造我们的系统

    对于实现模型来说,其工作是非常清晰的,就是设计模型,转换成能够运行程序代码,这个工作,是我们所有的程序员每天都在做的事情,因此 本文就不准备做过多的讨论了。提醒的一点是,同分析模型到设计模型的转换一样,在从设计模型向实现模型转换的时候,也会发生一些变化,这是正常的事情。

     

    结束语

    使用 UML 来为系统建模实际上是一个非常自然的过 程,只要我们按照既定的合理步骤,采用合理的方法,一步一步的进行深入的分析,就能够很好的完成我们的任务。在本文中,我们通过一个简单的系统,演示了这 样一个基本的步骤和方法,展示了各个模型的不同点和相互之间的联系,以及他们的转换和演化过程,希望能够对大家在设计更加复杂的系统时有所启发和帮助。

     

    原文链接:http://blog.csdn.net/jane082/article/details/772998

    展开全文
  • UML预约挂号系统建模(团队作业)

    千次阅读 多人点赞 2020-05-02 18:00:51
    根据以下资料,进行业务建模、用例建模、用例分析。团队自制,没有答案!有些部分不能保证质量,望高人指点改进! 具体要求: 1. 根据现有业务描述,识别业务参与者、业务用例,建立业务用例模型,用活动图描述...
  • 系统建模与仿真

    2020-07-27 23:32:31
    系统建模与仿真的课程ppt第三章,希望对大家有所帮助。
  • 信息系统建模方法

    千次阅读 2004-06-16 15:21:00
    信息系统建模方法周中元(本文转载自软件工程专家网www.21cmm.com,不代表gigix观点) 大型信息系统通常十分复杂,很难直接对它进行分析设计,人们经常借助模型来设计分析系统。模型是现实世界中的某些事物的一种...
  • 尤其是“阿尔法狗”战胜人类,为复杂系统建模仿真研究提供了启示。社会管理、战争决策、经济治理、指挥控制、医疗健康等复杂系统领域,一直存在着对经验、直觉等认知建模的需求。“阿尔法狗”所采用的人工神经元网络...
  • 本节主要解决5个问题: 1.动态系统建模要素 2.开放式动态系统建模 3.动态系统分类 4.建立方程模型 5.Simulink建模提示
  • 目录参考资料第一章 绪论1.1 电力系统建模的重要意义1.2 电力系统建模的基本概念1.2.1 电力系统模型1.2.2 电力系统建模1.2.3 电力系统辨识1.2.4 电力系统建模对象 第一章 绪论 1.1 电力系统建模的重要意义 基础:...
  • 本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具,或者不熟悉如何根据需求去建立模型的角度出发,简单的阐述了在系统架构的过程中我们应 该从什么样的角度出发去分析需求并且建立抽象模型。这应该...
  • 通信系统建模与仿真 笔记2

    千次阅读 2017-03-22 17:18:14
    simulink 建立系统模型:输入两个不同频率、振幅的正、余弦信号,输出它们的和
  • 系统建模与仿真-方水良在线阅读百度网盘下载(dsko)书名:系统建模与仿真作者:方水良格式:EPUB, HTMLZ, PDF路径:点击打开出版:浙江大学排序作者:方水良排序书名:系统建模与仿真日期:09 12月 2018uuid:2471cc87-9ca3-...
  • 芯片系统建模与分析

    千次阅读 2014-08-11 10:11:18
    在最初开始确定一颗芯片的需求之后,需要进行系统分析,确定系统的架构。这个过程的方法,我相信是很多系统架构设计者苦苦思索,一直追求的事情。一般从学习标准开始,了解协议,研究算法,确定整个系统的框架,然后...
  • MATLAB通信系统建模与仿真

    千次阅读 2018-05-31 21:36:37
    第七部分:OFDM系统 正交频分复用OFDM OFDM是一种无线环境下高效的数据传输方式,其基本思想是在频域内将给定信道分成许多正交子信道,在每个子信道上使用一个子载波进行调制,并且各子载波并行传输。这样,...
  • 生产物流系统建模与仿真-基于WITNESS建模视频教程 摘自:www.iescm.com/simubook​​​​​​​ 5.1 partMachineBuffer元素介绍5.2 partMachineBuffer元素建模示例-家电维修店5.3 Witness建模元素-...
  • 实时系统建模与分析UML

    千次阅读 2016-07-13 00:12:10
    建模/MDA/MDD的基本概念建模 建模是对现实世界的一个简化 因为不能完整地理解一个复杂的系统,所以要对它建模 建模是为了更好的理解我们正在开发的系统 UML(Unified Modeling Language) AADL(Architecture Analysis ...
  • 分布式系统建模与关键技术

    千次阅读 2018-06-11 21:53:18
    1、互联网之上的可可扩展计算1、1互联计算机时代1、1、1平台变革1、1、2高性能计算1、1、3高吞吐量计算1、1、4三种新计算范式1、1、5范式间的区别1、1、6分布式系统家族1、2可扩展性计算趋势和新的范式1、2、1并行度...
  • 第一章.MATLAB基础与通信系统仿真 第二章. Simulink仿真基础 第三章. 通信信号与系统分析 第四章. 信道 第五章. 模拟调制 第六章. 数字基带传输 第七章. 数字信号载波传输 第八章. 信道编码和交织 第九章. OFDM系统...
  • 什么是系统建模语言(SysML)?

    千次阅读 2011-06-21 10:57:05
    SysML(Systems Modeling Language),系统建模语言,是UML在系统工程应用领域的延续和扩展,是近年提出的系统体系结构设计的多用途建模语言,用于由软硬件、数据和人综合而成的复杂系统的集成体系结构说明、分析、...
1 2 3 4 5 ... 20
收藏数 205,300
精华内容 82,120
关键字:

系统建模