提升UML用例写作技巧：实例与指导（含PDF书签）

需积分: 22 161 浏览量更新于2024-08-02 收藏 1.04MB PDF 举报

在"UML - Writing Effective Use Cases"（**预发布第3稿**）一书中，作者Alistair Cockburn针对软件系统中的业务流程描述和行为需求写作提供了深入的指导。随着越来越多的人涉足编写用例文档，如何清晰、有效地传达系统使用场景成为一个关键问题。撰写用例实际上是一种散文写作技巧的应用，因此如何把握详略得当、表达清晰至关重要。本书的核心内容围绕以下几个方面展开： 1. **前言**: 提出了写作用例时面临的挑战，即确定所需写入的详细程度，以及如何确保写出高质量的用例。作者承认，虽然定义好一个好的用例模板相对容易，但更困难的是如何将这些原则付诸实践，使之不仅形式上符合标准，而且能真实反映出系统的实际操作和用户需求。 2. **写作指南与思考过程**：书中分享了作者在指导他人写作时使用的策略，包括思考步骤、观察要点，旨在帮助读者构建出更加完善和实用的用例集。这涉及到如何构思场景、提炼关键信息，以及如何在文字中准确传达交互细节。 3. **案例分析**：书中提供了优秀和较差用例的实例，以便读者对比学习。通过这些实例，读者可以理解不同写作风格的效果，从而提高自身的写作水平。 4. **创新方法**：作者强调了一个重要的观点，即编写用例并非必须遵循传统模式，允许探索和实验不同的写作方式，这为读者提供了更大的灵活性和创新空间。 5. **结论与启示**：最后，本书向读者传递了一个积极的信息，即尽管写作高质量的用例可能具有挑战性，但通过适当的技巧和实践，每个作者都能够创作出既实用又吸引人的用例文档。阅读这本书，读者将获得一套实用的工具和框架，帮助他们在实际项目中编写出更具说服力和易于理解的UML用例，从而提升软件开发过程中需求理解和沟通的效率。无论你是初次接触用例写作还是寻求进阶技巧，这本书都将为你提供有价值的指导。

xiv

Exercise 26 on page 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Exercise 27 on page 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Exercise 29“Fix faulty ’Login’” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Use Case 38: Use the order processing system . . . . . . . . . . . . . . . . . . . . . . . 239

Exercise 30 on page 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Exercise 34 on page 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Use Case 39: Buy stocks over the web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Exercise 37 on page 128: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Use Case 40: Perform clean spark plugs service . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 25 Appendix C: Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . 242

Main terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Types of use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Chapter 26 Appendix D: Reading . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Books referenced in the text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Articles referenced in the text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Online resources useful to your quest.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

1. I

NTRODUCTION

ASES

What do use cases look like?

Why would different project teams need different writing styles?

Where do they fit into the requirements gathering work?

How do we warm up for writing use cases?

It will be useful to have some thoughts on these questions in place before getting into the details

of use cases themselves. Feel free to bounce between this introduction and Use Case Body Parts,

picking up background information as you need.

1.1 What is a Use Case (more or less)?

A use case captures a contract between the stakeholders of a system about its behavior. The use

case describes the system’s behavior under various conditions as it responds to a request from one

of the stakeholders, called the primary actor. The primary actor initiates an interaction with the

system to accomplish some goal. The system responds, protecting the interests of all the stake-

holders. Different sequences of behavior, or scenarios, can unfold, depending on the particular

requests made and conditions surrounding the requests. The use case collects together those

different scenarios.

Use cases are fundamentally a text form, although they can be written using flow charts,

sequence charts, Petri nets, or programming languages. Under normal circumstances, they serve to

communicate from one person to another, often to people with no special training. Simple text is,

therefore, usually the best choice.

The use case, as a form of writing, can be put into service to stimulate discussion within a team

about an upcoming system. They might later use that the use case form to document the actual

requirements. Another team might later document the final design with the same use case form.

They might do this for a system as large as an entire company, or as small as a piece of a software

application program. What is interesting is that the same basic rules of writing apply to all these

different situations, even though the people will write with different amounts of rigor, at different

levels of technical detail.

When the use cases document an organization’s business processes, the system under discussion

is the organization itself. The stakeholders are the company shareholders, customers, vendors, and

Chapter 1. Introduction to Use Cases

What is a Use Case (more or less)? - Page 16

government regulatory agencies. The primary actors will include the company’s customers and

perhaps their suppliers.

When the use cases record behavioral requirements for a piece of software, the system under

discussion is the computer program. The stakeholders are the people who use the program, the

company owning it, government regulatory agencies, and other computer programs. The primary

actor will be the user sitting at the computer screen or another computer system.

I show several examples of use cases below. The parts of a use case are described in the next

chapter ("Use Case Body Parts"). For now, just note that the primary actor is the one with the goal

that the use case addresses. Scope identifies the system that we are discussing, the preconditions

and guarantees say what must be true before and after the use case runs. The main success

scenario is a case in which nothing goes wrong. The extensions section describes what can happen

differently during that scenario. The numbers in the extensions refer to the step numbers in the

main success scenario at which each different situation gets detected (for instance, steps 4a and 4b

indicate two different conditions that could show up at step 4). When a use case references another

use case, the second use case is written in italics or underlined

The first use case describes a person about to buy some stocks. over the web To signify that we

are dealing with a goal to be achieved in a single sitting, I mark the use case as being at the "user

goal" level, and tag the use case with the "sea-level" symbol . The second use case describes a

person trying to get paid for a car accident, a goal that takes longer than a single sitting. To show

this, I mark the level as "summary", and tag the use case with the "above sea level" kite symbol

. These symbols are all explained in more detail later.

The first use case describes the person’s interactions with a program (the "PAF" program)

running on a workstation connected to the web. I indicate that the system being discussed is a

computer system with the symbol of a black box, . The second use case describes a person’s

interaction with a company. I indicate that with the symbol of a building, . The use of symbols

are completely optional. Labeling the scope and level are not.

Here are the first two use cases.

Chapter 1. Introduction to Use Cases

What is a Use Case (more or less)? - Page 18

ASE

2: G

PAID

FOR

CAR

ACCIDENT

Primary Actor: The Claimant

Scope

: The insurance company ("MyInsCo")

Level

: Summary

Stakeholders and Interests:

the claimant - to get paid the most possible

MyInsCo - to pay the smallest appropriate amount

the dept. of insurance - to see that all guidelines are followed.

Precondition

: none

Minimal guarantees

: MyInsCo logs the claim and all activities.

Success guarantees

: Claimant and MyInsCo agree on amount to be paid, claimant gets paid

that.

Trigger:

Claimant submits a claim

Main success scenario

1. Claimant submits claim with substantiating data.

2. Insurance company verifies claimant owns a valid policy

3. Insurance company assigns agent to examine case

4. Insurance company verifies all details are within policy guidelines

5. Insurance company pays claimant and closes file.

Main success scenario

1a. Submitted data is incomplete:

1a1. Insurance company requests missing information

1a2. Claimant supplies missing information

2a. Claimant does not own a valid policy:

2a1. Insurance company declines claim, notifies claimant, records all this, terminates pro-

ceedings.

3a. No agents are available at this time

3a1. (What does the insurance company do here?)

4a. Accident violates basic policy guidelines:

4a1. Insurance company declines claim, notifies claimant, records all this, terminates pro-

ceedings.

4b. Accident violates some minor policy guidelines:

4b1. Insurance company begins negotiation with claimant as to degree of payment to be

made.

________________________________________

Most of the use cases for this book come from live projects, and I have been careful not to touch

them up (except to add the scope and level tags if they weren’t there). I want you to see samples of

what works in practice, not just what is pretty in the classroom. People rarely have time to make

the use cases formal, complete, and pretty. They usually only have time to make them "sufficient".

Sufficient is fine. It is all that is necessary. I show these real samples because you will rarely be

able to generate perfect use cases yourself, despite whatever coaching I offer in the book. I can’t

even write perfect use cases most of the time.

剩余248页未读，继续阅读

bygoner

粉丝: 0
资源: 4

提升UML用例写作技巧：实例与指导（含PDF书签）

Writing Effective Use Cases（编写有效用例）—— 完整中文版

writing effective use case

Writing.Effective.Use.Case.pdf

Writing Effective Use Cases

编写有效用例(writing effective use cases)

编写有效用例(Writing Effective Use Cases)中英文版

UML统一用例方法

基于 C++构建 Qt 实现的 GDAL 与 PROJ4 的遥感图像处理软件课程设计

【java毕业设计】娜娜服装企业物流管理系统源码（完整前后端+说明文档+LW）.zip

2009年国际大学生数学建模竞赛成果公告

最新资源