Use Case Driven Data Modeling with UML : Theory and Practice 閱讀筆記(1)

 一直以來想系統的研究一下，模型驅動的開發模式，順便複習一下UML的知識，於是在網上得到了這本書：Use Case Driven Data Modeling with UML : Theory and Practice  。由於這幾天有足夠的時間，所以打算有計劃的研讀一下這本書。今天開始，嘗試以一種筆記的方式來驅動我的讀書過程，順便記下我的讀書心得，希望得到預期的效果。

 

  今天，看它的第一章：Domain Modeling , 理解成漢語的意思就是--域建模。在很多的項目中，項目成員之間溝通的時候，由於使用的描述語言的差異，往往會導致，彼此之間相互誤解。這就是域建模的產生背景。

看原文：

The domain model is a live, collaborative artifact. It is refined and updated throughout the project, so that it always reflects the current understanding of the problem space.

 

這下明白了，領域模型是為了對反映當前問題空間的理解，而且，它在整個項目開發過程中是不斷被提煉和更新的。

 

  下面這句話再明白不過的了：

In this chapter we’ll look at domain modeling, which aims to solve the problem of miscommunication on projects by establishing a common vocabulary that maps out the
problem space.

 

 領域模型就是用來項目中溝通錯誤這個問題的，它通過建立一個公用的詞彙表來反映問題空間。

 

Domain modeling is the task of building a project glossary, or a dictionary of terms used in
your project.

域建模是用來構建工程詞庫的任務，構建一個在項目中使用的詞典。

The domain model for a project defines the scope and forms the foundation on
which to build your use cases.

一個項目的領域模型定義了用來構建用例的範圍和形式。

A domain model also provides a common vocabulary to enable
clear communication between members of a project team.

領域模型也提供了一個公用詞彙表，使得項目成員間能夠正確清晰的進行溝通。

 So even though this book is about
use case–driven development, we have to begin at the beginning with domain modeling.

這也是為什麼，在一本用來講述用例驅動開發的書的開頭，我們不得不以域建模開始。

As just mentioned, a domain model is, essentially, a project glossary: a “live” dictionary of all
the terms used in your project.

領域模型實質上是一個項目的詞彙庫：一本包括了你的項目中用到的所有詞的詞典。

But a domain model is better than a project glossary, because
it shows graphically how all these different terms relate to each other.

領域模型不僅是一本詞典，因為它還會顯示各個詞之間的關係。

 In practice it’s a simplified class diagram, with lines drawn between the different classes (domain objects) to show how they relate to each other. The domain model shows aggregation and generalization relationships (has-a and is-a relationships) between the domain classes.

領域模型包含兩種關係，彙總和泛化即has-a 和 is-a的關係。

 

Our advice is pretty much the opposite: your use case text should be grounded in reality, and
it should be very close to the system that you’ll be designing. In other words, the use cases
should be written in the context of the object model (i.e., the use case text needs to reference
the domain objects by name). By doing this, you’ll be able to tie together the static and
dynamic parts of the model, which is crucial if you want your analysis and design effort to
be driven forward by your use cases.

我們的建議是，你的用例本文要立足於實際，而且要十分貼近你正在設計的系統。換句話說，這些用例應該在物件模型的上下文中來書寫。這樣，就能把模型的動態部分和靜態部分聯絡起來。如果想要用例來驅動你的分析和設計，這是十分重要的。

 

So before you write your use cases, you need to come up with a first-pass attempt at
a domain model. The domain model forms the foundation of the static part of your model,
while the use cases are the foundation of the dynamic part. The static part describes structure;
the dynamic part describes behavior.

因此，在書寫用例之前，有必要先顧及一下領域模型。領域模型構成了模型的靜態部分的基礎，而用例構成了模型的動態部分的基礎。

Top 10 Domain Modeling Guidelines

 

10. Focus on real-world (problem domain) objects.

 When creating a domain model, be sure to focus on real-world objects within the problem
domain. Try to organize your software architecture around what the real world looks like. The
real world tends to change less frequently than software requirements.

建立領域模型的時候，務必集中於問題空間的現實世界對象，儘力按照現實世界的樣子來組織你的軟體架構。現實世界的變化沒有需求變化的那麼頻繁。

 

9. Use generalization (is-a) and aggregation (has-a) relationships to show how the
objects relate to each other.

These and regular (plain vanilla) associations are the most important relationships in
your domain model. Ninety-five percent of your model’s class relationships can be modeled
using aggregation and generalization relationships.

勾畫對象之間的is-a和has-a的關係。 這些常規的關係在你的領域模型中是最重要的，模型中百分之九十五的類的關係能夠用著兩種關係來建模。

 

8. Limit your initial domain modeling efforts to a couple of hours.

We recommend that you establish a time budget for building your initial domain model.
A couple of hours is all you should need. You’re not going to make it perfect anyway, so do it
quickly and expect to fix it as you proceed. You should be vigilant about making necessary
adjustments to your analysis-level class model in response to discoveries made during robustness
analysis and throughout the project.

建議建立一個時間段來建立初始的領域模型。幾個小時足夠了，不用追求完美；快速完成，然後在後續的步驟中來修正它。

在健壯分析以及真箇項目進程中有新發現時，我們會對分析層次的類模型進行調整，但是要保持警醒。

 

You’ll discover missing objects as you work through use cases and robustness diagrams.
The use case–driven process assumes that the domain model is incomplete and provides
a mechanism for discovering what was missed.

當你進行用例部分和健壯分析部分的工作時，你會發現遺漏的對象。用例驅動的開發過程，假定領域模型是不完全的，並且提供了一個發現遺漏的機制。

The initial domain modeling session is probably the most important two hours you’ll
spend on the project! It’s likely that you’ll discover 80% of your domain classes during that
two-hour brainstorming session. If you can get 80% of your domain vocabulary disambiguated,
then that’s two hours well spent.

花費兩個小時來發現百分之八十的域詞彙，這樣就很不錯了。

 

7. Organize your classes around key abstractions in the problem domain.

It’s generally good practice to organize your classes around key abstractions in the problem
domain. Remember that the domain model is a first-cut class diagram that becomes the foundation
of your software architecture. This makes the model more resilient in the face of
change. Organizing the architecture around real-world abstractions makes the model more
resilient in the face of changing requirements, as the requirements will usually change more
frequently than the real world does.

通常一個很好的實踐是：以問題空間的關鍵抽象為中心來組織你的類。記住，領域模型是最初的類圖，而類圖是軟體架構的基礎。這樣使得模型面對變化更有彈性。圍繞現實世界的抽象組織架構，使得模型面對變化的需求更有彈性。

6. Don’t mistake your domain model for a data model.

Even though the diagrams might look similar, remember that what’s good practice on a data
model is not likely to be good practice on a class diagram (and vice versa). Classes are small
and tables are bigger. A table in a relational database often relates a number of things. Conversely,
classes are better designed if they’re relatively small packets of data and behavior.

In a class diagram, it’s likely that you’ll have a class that manages a database table, and
you might show some sort of TableManager class aggregating a regular domain class. The purpose
of these TableManager-type classes is to hide the details of the database management
system (DBMS) from the rest of the code base.

5. Don’t confuse an object (which represents a single instance) with a database table
(which contains a collection of things).

An object represents a single instance of something. A database table represents a collection
of things. You don’t have to be as literal-minded as in the Enterprise JavaBeans (EJB)
world, where an entity bean generally represents a single row in a table. Domain classes
are similar, though. If you call a domain class Book, then you don’t mean a book table—you
mean a single book.
Columns in a table generally map to attributes on a class. However, database tables
typically contain a lot more columns than a class contains attributes (tables often have
foreign keys, as one example), so there may not be a direct 1:1 mapping between table
rows and objects.

4. Use the domain model as a project glossary.

If ambiguous requirements are the enemy, the domain model is the first line of defense.
Ambiguous usage of names by “subject matter experts” is very common and very harmful.
The domain model should serve as a project glossary that helps to ensure consistent usage
of terms when describing the problem space.
Using the domain model as a project glossary is the first step toward disambiguating your
model. In every Jumpstart workshop that Doug teaches, he finds at least two or three domain
classes where students are using ambiguous names (e.g., “shopping cart,” “shopping basket,”
or “shopping trolley”).

3. Do your initial domain model before you write your use cases, to avoid name
ambiguity.

Since you’re using the domain model to disambiguate your problem domain abstractions,
it would be silly to have your use cases written using ambiguous terms to describe domain
classes. So spend that two hours working on the domain model before writing your use cases.
Writing the use cases without a domain model to bind everything together stores up lots of
problems for later.

2. Don’t expect your final class diagrams to precisely match your domain model,
but there should be some resemblance between them.

The class diagrams will become a lot more detailed than the domain model as the design
progresses; the domain model is deliberately kept quite simple. As you’re designing (using
sequence diagrams), detailed design constructs such as GUI helpers, factory classes, and
infrastructure classes get added to the class diagram, and the domain model diagram will
almost certainly be split out into several detailed class diagrams. However, it should still
be possible to trace most classes back to their equivalent domain class.

1. Don’t put screens and other GUI-specific classes on your domain model.

Doing so opens up Pandora’s box and leads to an overcrowded domain model containing lots
of implementation-specific detail. Performance optimization classes, helper classes, and so
on should also be kept out of the domain model. The domain model should focus purely on
the problem domain.