Valid use case pattern notes (vi) (vii) (eight)

Full note download

sixth chapter scene and step <?xml:namespace prefix = o ns = "Urn:schemas-microsoft-com:office:office"/>

6.1DetectableConditions

Writers are always racking their brains to think about how many conditions are included and what conditions are included

Reason:

· The system cannot handle events it cannot detect

· Developers need to know what conditions to test

· Fear of ignoring important branches allows developers to describe unrelated conditions that the system does not detect

· Many seemingly different conditions may lead to the writing of unnecessary branches

So:

Contains only detectable conditions, merging the same conditions that ultimately affect the system

6.2 leveledsteps

An oversized or too small use case step-by party blurs the target and uses examples that are difficult to read and understand.

Reason:

· Too little steps make the use cases unfair and difficult to read, and they blur the "why".

· Too large a step may obscure important behavior.

· In a scene, writing with different levels of detail can distract the reader's attention

So:

keep the scene in 3~9 step inside. Ideally, the steps are written at a similar level and are the level of abstraction under the use-case goal

6.3ActorIntentAccomplished

Readers and developers will be confused about the behavior of the system if they are responsible for performing the steps and what the participants are trying to accomplish in this step is not clear enough.

Reason:

· Writing high-quality use cases is a difficult task

· Developers need to know exactly what they want to achieve, when the system should wait for input information, and what time the system should take action.

So:

Write each step to clearly show which participant is performing the action and what the participants have done.

6.4ForwardProgress

The writer must decide how much behavior to include in any one step. They are easy to write too much detail, making use cases tedious and difficult to read.

Reason:

· Clear and concise steps reduce the effort required to understand and evaluate use cases.

· Expectations of completeness and detail can lead to steps that include deviations from use-case goals.

So:

Eliminate or merge steps that do not advance the participants. Simplifying content that distracts readers from achieving their goals.

6.5TechnologyNeutral

including technical constraints and implementation details in a use case description increases complexity and blurs the purpose of the use case.

Reason:

· Many people like to use specific words to think about problems

· Technology is unstable and details that contain specific technologies will result in rework.

· Technical details create inappropriate constraints on future activities

· Adding technical details increases the cost of reading and writing use cases

· Sometimes adding technical details is a need.

So:

Write each use case in a technically neutral way

The seventh chapter case Relationship

7.1CommonSubBehavior

Writing the same steps for different use cases is not only a waste of time and effort, but it's also more difficult to see common sub-processes in a use-case model

Reason:

· Rewriting public steps is redundant and increases the risk of model inaccuracies and inconsistencies

· Dividing a single use case is likely to distract important behavior and will be difficult to understand using examples

· Misunderstanding the inclusion relationship can lead to misuse

So:

with lower layers of " include " use CASE expression shared action path

7.2　interruptsasextensions

A branch that affects multiple steps in a scene will scatter the details in the use case, omitting important information or confusing the reader.

Reason:

· A branch that deviates or interrupts several steps in a scene several times may cause the reader to lose the path clue that they are trying to understand and may indicate a problem with the underlying scenario itself.

· Creating a cover case tends to distract important behaviors and make them more difficult to understand

· Misunderstanding "extended" relationships can lead to misuse of extensions

So:

Create an extension use case when the branch motion path interrupts a large number of steps in a scene.

7.3 promotedalternative

Lengthy or complex branches can occupy a large part of the use case because they are so prominent that their importance is exaggerated.

Reason:

· A complex or lengthy branch confuses one use case and blurs other branches.

· Some of the problems are complex, and they require that they be adequately described in complex use cases

· Dividing a single use case easily distracts important behaviors and makes them more difficult to understand.

So:

Consider moving a complex branch of excessive dominance of use cases into a single use case

7.5　capturedabstraction--- application of UML generalization model

In one use case, try to put two or more different branches ( any one does not dominate ) documenting is difficult and confusing.