第V章、UMLおよびデータベースアプリケーション

第V章、UMLおよびデータベースアプリケーション

要約:

  1. DBASのモデリングを学びます
  2. DBAは、ビジネスプロセスや表現のニーズを理解します
  3. 発現システムの内部構造を理解DBAS
  4. システム設計式のDBAS微視的理解
  5. マクロ式を理解するために設計されたDBASシステム
  6. 表現方法DBASシステムの実装と展開を学びます

セクションI、DBASモデリング

1.1、統一モデリング言語(UML)

統一モデリング言語(UML):統一モデリング言語

  UMLモデリング言語は、Booch法、OMT、およびOOSE法、統一された記号システムの利点を組み合わせた(一般)に基づく、ユニバーサルオブジェクト指向の可視化であり、多くの他の方法と技術的手法から吸収した後実際のテストの概念とテクニック。

UMLは言語ではなく、モデリングのためのモデリング手法です。

  モデリングモデリング言語は二つの部分とモデリングプロセスを含める必要があります。

  • モデリング言語:このメソッドは、モデリング結果の記号表現を提供するために使用されます。(グラフィックシンボル:可視化)

  • モデリングプロセス:モデリングを記述する場合は次のように。

1.2、UML組成

(視覚的な標準シンボル)の組成を有するセマンティック(自然言語)表記によります。

セマンティクスは4フレームモデリングの概念で定義されています。

  Metametamodel(メタメタモデル)、定義したいすべてのものの代表。

  メタモデル(メタモデル)、UMLの基本的な要素の概念の例「の事。」

  モデル層(モデル)、UMLモデル、モデルタイプまたはモデルタイプ。

  ユーザモデル(ユーザーモデル)、UMLモデル、またはオブジェクトモデルインスタンスモデルの例。

1.3、UMLの5つのビュー

UMLの5つのビュー

ビュー例の構造、実装、行動、および環境

マップ(UML2.0)の13種類:静的構造図及び動作図カテゴリ。

UML入門

セクションII、DBASのビジネスプロセスやニーズを表明

2.1、ビジネスプロセスとアクティビティ図

ビジネスプロセスとアクティビティ図

図活動は、主に論理フロー、平行ために、システム、ユースケース、およびプログラムモジュールの実行順序を記載しました。

ベストは、ワークフローシステムやサブシステムを説明しています。

フローチャートと同様の低レベルのプログラムモジュールの図積極的な役割が、アクティビティマップは、並列に動作するように記述することができる、唯一のフローチャートは、シリアル動作を説明。

アクティビティ図が有する複数のエンドポイントを有することができ、唯一の開始点を、。

例えば

システム要件と、実施例2.2、

システム要件とユースケース図(ニーズ分析モデルとして一般に機能図の実施形態)

  システム要件:本当に心の中でユーザーが期待しています。

  ユースケースモデルは、ユーザが機能ニーズを満たすためにあるツールを表します。

ユースケースモデルは、ユースケース、役割およびシステムの3つの部分から構成されています。

  システム:「ブラックボックス」の使用例さまざまな

  役割:システムまたは他のエンティティと対話します

  ユースケース:すべての全機能の操作(オペレーション)セット

例えば:

役割の関係

汎化関係は:ユニバーサル行動として抽出された特定の文字の行動を指し、これらの行動は、共通のスーパークラスを構成しています。

ユースケースや俳優との関係に

接続関係(相関、関連する通信は):文字は、本実施形態との通信に使用できることを示し、1人の関係が双方向です。

と実施形態との関係

拡張:ユースケースが別のユースケースのように、新しいコンテンツを追加します。

含む(使用)別を使用してユースケース。

協会(組み合わせ):例は、全体として、関連するパッケージで標識しました。

第三、DBASシステムの内部構造の表現

(アウトライン設計部門と提携)

3.1システム構成図クラス

1、図クラスのシステム構成

  システムの内部構造は、一般的に分割されている静的構造と動的構造

  UMLでは、クラス図を用いて、システムの静的構造を説明する図通信のシーケンス図とシステムダイナミクス構造。

  クラス図の主な表現は、問題領域の概念モデルです。

  図のクラスのクラス名属性操作性組成物。

クラスとクラス間の関係

  アソシエーション(集約(アグリゲーション共有、組成物または組み合わせ))、継承された(または一般化と呼ばれる)、依存、精製(または実装と呼ばれます)

3.2システムの構成図のシーケンス

システム構成図のシーケンス。

図は、シーケンシャルに使用する各特定のユースケースでは、オブジェクトのクラス図を使用する方法を提供しなければならない実施形態の仕様にタスクを実行します

図配列は主に記載されたシステム内のオブジェクト間のメッセージ送受信シーケンスのために使用されます。

図のシーケンスのすべての要素は、クラス図で存在しなければなりません。

3.3、図1の通信システムの構造。

通信システムの構成図。

通信图是交互图的一种,也称为协作图。

通信图显示对象间组织交互关系和链接。不侧重交互顺序,用序列号来确定消息及其并发线程的顺序。

顺序图强调时间,通信图强调空间

第四节、DBAS系统微观设计的表达

4.1、微观设计与对象图

系统设计中,需要考虑细节部分。UML中,对于细节方面的内容可用对象图、状态机图及时间图来表达、分析和描述某个特定状况下系统的运作情况。

对象图是类图的实例,描述特定时间中所有对象在系统中的结构,是一个快照

4.2、微观设计与状态机图

状态图用来描述有关事件或对象的状态转移。

状态图只能有一个起始状态,可有多个结束状态。

状态间的转移由事件驱动。

4.3、微观设计与时间图

当状态的转换由时间因素决定时,使用时间图来描述状态的变化。

描述时间驱动的状态转换,即当状态维持多少时间后转移。

时间图中,整个矩形框就是一个生命线。

第五节、DBAS系统宏观设计的表达

5.1、宏观设计与包图

宏观设计指将涉及的焦点放在研究比较大范围中的元素之间的联系,如包、命名空间、子系统等。

一个良好的命名空间,便于开发人员理解,并使得各个命名空间之间能够松耦合,而命名空间内则可满足高内聚的要求。

包图表示系统中不同包、命名空间或不同项目间的彼此关系。也就是逻辑层次上与实体层次上的关联性。

5.2、宏观设计与交互概述图

是将活动图和顺序图嫁接在一起的图

以活动图为基础,在控制流间连接交互图,从而将所有交互图关系呈现出来。

交互概述图可以把不同的交互图结合在同一张图中来表达。

5.3、宏观设计与复合结构图

外部系统的整合关系着项目的成败。

在项目开始前,最好将待开发的系统与外部系统的关系做一个初步的定义。

复合结构图适用于系统间的沟通接口,适合做构架师在初期阶段评估系统复杂度的工具,也可以是系统维护的参考图。

第六节、DBAS系统实现与部署的表达

6.1、系统实现与组图

组件图用来表示系统的静态实现视图。

用来展现一组组件间的组织和依赖,用于对源代码、可执行的发布、物理数据库等的系统建模。

组件是逻辑设计中定义的概念和功能在物理构架中的实现

6.2、系统实现与部署图

部署图又叫配置图,描述系统中硬件和软件的物理配置情况与系统体系结构。

部署图说明实体组件,如可执行程序,将如何部署到实际的计算机中。

部署图要在项目进行集成测试前提供。

例题:

1、

用UML建立业务模型是理解企业业务的第一步,业务人员扮演业务中的角色及其交互方式,例如航空公司的售票员是业务员,电话售票员也是业务员,它们直接的关系是(  )
A.关联关系   
B.泛化关系
C.聚集关系     
D.依赖关系
答案: B
角色和角色之间的关系一般是泛华关系

2、

统一建模语言UML是一种常用于数据库应用系统设计和开发的可视化建模语言。关于UML,下列说法错误的是(  )
A.UML中的视图是由一个或多个图组成的,一个图是系统模型中的某个侧面的展示
B.用例图、顺序图和状态图都是UML的行为视图,用于描述系统的功能和活动
C.类图和对象图都是UML的结构视图,用于描述系统在某个时间的静态结构
D.在用例图中,与系统交互的人和其他实体都可以成为系统的角色
答案:B
用例图所属用例图

3、

设用UML设计某数据库应用系统,设计人员规划了一组应用程序集,该集合由动态链接库和可执行程序构成。为了展现这些应用程序集间的组织和依赖关系,以对源代码、可执行程序的发布等进行系统建模,应采用的UML图是 (  ) 图。
答案:组件

4、

在UML中,用例模型由用例、系统和 (  ) 三部分组成。
答案:角色

5、

在UML中,当要描述状态之间的转换时,可通过(  )图来体现时间因子的作用。
答案:时间

6、

7、

在UML模型中,用于表达一系列的对象、对象之间的联系以及对象间发送和接收消息的图是(  )。
答案:通信图(协作图)

おすすめ

転載: www.cnblogs.com/shaoyayu/p/12355327.html