使用用例驱动的对象建模实战指南

需积分: 4 184 浏览量更新于2024-07-21 收藏 1.57MB PDF 举报

"Addison.Wesley.Applying.Use.Case.Driven.Object.Modeling - 这本书是关于如何应用用例驱动的对象建模方法，通过UML进行电子商务案例的实践指导。作者Doug Rosenberg和Kendall Scott旨在帮助读者将理论知识转化为实际开发中的应用，特别是针对互联网电子商务应用程序的开发。" 在软件工程领域，用例驱动的对象建模是一种以用户需求为中心的设计方法，它强调从用户的角度出发来理解和描述系统的行为。这本书《 Applying Use Case Driven Object Modeling with UML》首先介绍了用例驱动建模的基本概念，它通过一个具体的电子商务系统——在线书店的例子，帮助读者深入理解这一方法。 UML（统一建模语言）是用于系统建模的一种标准表示法，它包括各种图表如用例图、类图、序列图等，用于描绘系统的不同视角。书中，作者详细展示了如何利用UML来创建和理解用例，以及如何将这些用例转换为对象模型，这其中包括了类、接口、关系等关键元素的定义。书中的独特之处在于其工作手册的形式，书中包含了一系列实践性的练习，让读者有机会亲自检测、识别并修正设计中的错误。这些练习基于ICONIX过程，这是一种经过验证的软件开发流程，它强调了用例在系统开发早期的作用，以确保需求的明确性和设计的正确性。作者们还特别关注了常见的设计错误，并提供了对应的正确设计方案，这对于避免在实际项目中遇到问题至关重要。通过学习本书，读者不仅能掌握用例驱动建模的技术，还能了解到如何在实践中有效地应对挑战，提高软件开发的质量和效率。这本书适合对用例驱动建模感兴趣，尤其是那些想要在实际项目中应用这一方法的软件开发者、系统分析师以及项目经理。通过深入学习和实践，读者可以更好地理解如何将业务需求转化为可操作的软件模型，从而更有效地构建满足用户需求的系统。

We’ll make our decisions about allocating behavior to our classes as we draw the

sequence diagrams. That’s going to put the operations on the software classes.

When you use a visual modeling tool such as Rational Rose or GDPro, as you draw

the message arrows on the sequence diagrams, you’re actually physically assigning

operations to the classes on the class diagrams. The tool enforces the fact that

behavior allocation happens from the sequence diagram. As you’re drawing the

sequence diagram, the classes on the class diagram get populated with operations.

So, the trick is to get from use cases to sequence diagrams. This is a non-trivial

problem in most cases because the use cases present a requirements-level view of

the system, and the sequence diagram is a very detailed design view. This is where

our approach is different from the other approaches on the market today. Most

approaches talk about use cases and sequence diagrams but don’t address how to

get across the gap between the fuzzy use cases and a code-like level of detail on the

sequence diagrams. Getting across this gap between what and how is the central

aspect of the ICONIX process.

What we’re going to do now is close the gap between the fuzzy, nebulous use case

and the very detailed and precise sequence diagram with another kind of diagram

called a robustness diagram. The robustness diagram sits in the gap between

requirements and detailed design; it will help make getting from the use cases to the

sequence diagrams easier.

If you’ve been looking at UML literature, the robustness diagram was originally only

partially included in the UML. It originated in Ivar Jacobson’s work and got included

in the UML standard as an appendage. This has to do with the history and the

sequence of how Booch, Rumbaugh, and Jacobson got together and merged their

methodologies, as opposed to the relative importance of the diagram in modeling.

Across the top of a sequence diagram is a set of objects that are going to be

participating in a given scenario. One of the things we have to do before we can get

to a sequence diagram is to have a first guess as to which objects will be

participating in that scenario. It also helps if we have a guess as to what software

functions we’ll be performing in the scenario. While we do the sequence diagram,

we’ll be thinking about mapping the set of functions that will accomplish the desired

behavior onto that set of objects that participate in the scenario.

It helps a great deal to have a good idea about the objects that we’ll need and the

functions that those objects will need to perform. When you do it the second time,

it’s a lot more accurate than when you take a first guess at it. The process that we’re

following, which is essentially Ivar Jacobson’s process as described in his Objectory

work, is a process that incorporates a first guess, or preliminary design, the results

of which appear on what we call a robustness diagram. We refine that first guess into

a detailed design on the sequence diagram. So, we’ll do a sequence diagram for each

scenario that we’re going to build.

Figure 1-5 shows that we’re adding a diagram to our subset of UML. The robustness

diagram was described in the original UML specs, but its definition was in an extra

document called Objectory Process-Specific Extensions. What we’ve found over the

past ten years is that it’s very difficult to get from use cases to sequence diagrams

without this technique. Using the robustness diagram helps avoid the common

problem of project teams thrashing around with use cases and not really getting

anywhere towards their software design. If you incorporate this step, it will make

this process and your project much easier. We didn’t invent robustness analysis, but

we’re trying to make sure it doesn’t get forgotten. Robustness analysis has proven to

be an invaluable aid in getting across the gap between requirements and design.

Figure 1-5. Robustness Diagrams Close the Gap Between Requirements and

Detailed Design

Robustness analysis sits right in the gap between what the system has to do and

how it’s actually going to accomplish this task. While we’re crossing this gap, there

are actually several different activities that are going on concurrently. First, we’re

going to be discovering objects that we forgot when we took our first guess at what

objects we had in the system. We can also add the attributes onto our classes as we

trace data flow on the robustness diagrams. Another important thing we’ll do is

update and refine the text of the use case as we work through this diagram.

We still have a question mark, though. That question mark relates to the comment

we just made about discovering the objects that we forgot when we took our first

guess. This implies that we’re going to take a first guess at some point.

There’s a magic phrase that we use to help teach people how to write use cases

successfully: Describe system usage in the context of the object model. The first

thing this means is that we’re not talking, in this book, about writing fuzzy, abstract

and vague, ambiguous use cases that don’t have enough detail in them from which

to produce a software design. We’re going to teach you to write use cases that are

very explicit, precise, and unambiguous. We have a very specific goal in mind when

discussing use cases: we want to drive the software design from them. Many books

on use cases take a different perspective, using use cases as more of an abstract

requirements exploration technique. Our approach is different because our goals are

different. Remember, our mission is to help you get from use cases to code.

We’ll start out with something called a domain model, which is a kind of glossary of

the main abstractions—in other words, the most important nouns that are in our

problem space (our problem domain). In the term domain model, the word

“domain” comes from the idea of the problem domain. For example, if our problem

domain is electronic commerce—as it is in the workbook, amazingly enough—we’ll

probably have a domain object like a catalog or a purchase order. We’re going to call

these nouns that belong to our problem space domain objects, and we’re going to

produce, at the very beginning of our analysis and design activities, something called

a domain model, which lays all these domain objects out on one big UML class

diagram.

On our robustness diagrams, we’re also going to use something called boundary

objects. Among the boundary objects, we find things like the screens of the system.

In the text of our use cases, we want to explicitly reference both domain objects and

boundary objects. We’ll write about such things as how the users interact with the

screens and how those screens interact with the domain objects, which often have

some mapping onto a database that may sit behind the OO part of our system. Our

use case text will get a lot more specific and a lot less ambiguous if we follow this

guideline of describing how the system is used in the context of the object model as

it evolves.

During domain modeling, we want to identify the most important set of abstractions

that describe the problem space, or the problem domain of the system, that we need

to build. For this task, we’ll follow the methodology Jim Rumbaugh developed: the

Object Modeling Technique (OMT), which is a very thorough treatment of some

useful techniques for helping us do this domain model.

One difference between our approach and some of the other use case–oriented

approaches you might run across is that we insist on starting the whole process with

domain modeling. In writing our use cases against the set of nouns in the domain

model, thus using that domain model as a glossary, we can unambiguously define a

set of terms that we can reference within our use case text. This approach proves to

be quite useful, especially when you’re working in a team environment where there

are multiple groups of people that are trying to describe scenarios in different parts

of the system. If you get closure and agreement on what the important nouns in the

system are, you eliminate whole layers of ambiguity in the use case models. For

example, this enables you to be clear on what a purchase order is, what a line item

is, and what a shopping cart is. All those things are clear from the beginning, due to

the fact that we’ve defined a glossary of terms before we start writing our use cases.

In terms of the UML, the domain model is basically a class diagram, so it’s the same

kind of diagram as our design-level class diagram. Generally, on the domain model,

we suppress quite a bit of detail; in particular, we don’t show the attributes and the

operations on the classes. The domain model is more of a global summary-level class

diagram. In fact, it’s a first guess at a class diagram, focusing entirely on the

problem domain of the system we’re building. We take this first guess at our class

diagram, and then we work through all the details of our use cases and refine our

view of the system. As we work through the scenarios, the first-guess class diagram

evolves into our detailed static model for the system.

As you can see in Figure 1-6, we now have a fairly complete picture, with no big

gaps in it, that helps us get from use cases and prototypes over on the left side to

design-level class diagrams and source code over on the right side.

Figure 1-6. Referencing Domain Objects by Name Removes Ambiguity from

the Use Cases

Note that we’re using a very streamlined approach. We’re only using four different

kinds of UML diagrams. That’s four out of a set of nine different kinds of diagrams

that make up the UML. Generally, for most projects, most of the time you can do

most of your work using less than half of the UML. Limiting your focus to this core

subset of diagrams will make a significant impact on your learning curve as you learn

how to do modeling with UML.

We’re going to start off with the domain model, which is an analysis-level class

diagram, as our first guess at the static structure of the system. We’re going to

continuously refine and add detail to this model, with the ultimate result being our

detailed design. The class diagram, which is in the bottom half of Figure 1-6, is a

static description of how the code is organized, whereas the use cases are a dynamic

description of the runtime behavior.

We’ll take the first guess at our static model, and then we’ll spend most of our time

working through use case after use case. Every time we work through a use case,

we’ll add some detail to the class diagram. After we work through all the scenarios

that the system has to support, add in all the detail needed to make all those

scenarios happen, and review what we’ve done a couple of times, we should have a

design that meets the requirements, and we’ll be well positioned to write code.

Figure 1-7 shows the “big picture” for the ICONIX process. This figure appears on the

first page of every chapter in our book Use Case Driven Object Modeling with UML.

The picture has two parts to it: The top part is the dynamic model, which describes

behavior, and the bottom part is the static model, which describes structure.

Figure 1-7. The ICONIX Process—A Streamlined Approach to UML Modeling

We might start with some prototypes, or perhaps simple line drawings of our

screens. Then, after getting some assurance from users that we’re on the right track,

we can work from this beginning to identify use cases on our use case diagram,

which shows all the scenarios that the system has to perform. Then we write the text

of our use cases. We refine the use case text during robustness analysis. It’s

important to try to get the text stabilized and corrected during the preliminary design

phase before moving into detailed design, which we do on sequence diagrams.

Many people complain about constantly changing requirements. Some use this as an

excuse to start coding prematurely. We’re willing to bet that the vast majority of

these folks have never used robustness analysis, which is enormously helpful in

getting those requirements stabilized.

By breaking exploration of the dynamic model into these three steps, we get two

chances to review the behavior description; hopefully, by the time we’ve reviewed it

the second time, our understanding of the required behavior is detailed and fairly

stable, and we can start designing against it.

As you can see on the static part of the picture, we start with a quick first guess

about objects based totally on the problem space description. We go through one

long continuous refinement that’s driven by our analysis of the dynamic runtime

behavior of the system. We think in detail how one scenario is supposed to work,

then update our class diagrams based on our improved understanding of that. Then,

we go back and think more about what the behavior of the system should be.

剩余126页未读，继续阅读

eleven198202

粉丝: 0
资源: 1

使用用例驱动的对象建模实战指南

Addison.Wesley.UNIX.Network.Programming.Volume.1.3rd.Ed.The.Sockets.Networking.API.eBook-LiB

Addison.Wesley,.Applying.UML.and.Patterns.An Introduction.to.Ob

Addison.Wesley.Eclipse.Modeling.Framework.A.Developers.Guide 中文版

Addison.Wesley.Test.Driven.JavaScript.Development.Sep.2010.rar

Addison.Wesley.Test-Driven.iOS.Development

addison.wesley.domain.driven.design.tackling.complexity.in.the.heart.of.software.rar

Addison.Wesley.Effective.Use.of.Microsoft.Enterprise.Library.Jun.2006

Addison.Wesley.Effective.Use.of.Microsoft.Enterprise.Library.Jun.2006.chm

Addison.Wesley.Refactoring

Addison.Wesley. Accelerated.C

最新资源