学习uml2（不全）part1 （也许有part2）

UML 2.0 学习

《 Learning UML 2.0 》

1.Use case description

The series of examples bellow describe cases from the basic to the complicated. And a mode of use case template is introduced which is a wonderful one, I think.

『A.』 Basic:

Table 2-3. The detailed description for the "Create a new Personal Wiki" use case
Use case name	Create a new Personal Wiki
Related Requirements	Requirement A.2.
Goal In Context	A new or existing author requests a new personal Wiki from the Administrator.
Preconditions	The author has appropriate proof of identity.
Successful End Condition	A new personal Wiki is created for the author.
Failed End Condition	The application for a new personal Wiki is rejected.
Primary Actors	Administrator.
Secondary Actors	Author Credentials Database.
Trigger	The Administrator asks the CMS to create a new personal Wiki.
Main Flow	Step	Action
	1	The Administrator asks the system to create a new personal Wiki.
	2	The Administrator enters the author's details.
	3	The author's details are verified using the Author Credentials Database.
	4	The new personal Wiki is created.
	5	A summary of the new personal Wiki's details are emailed to the author.
Extensions	Step	Branching Action
	3.1	The Author Credentials Database does not verify the author's details.
	3.2	The author's new personal Wiki application is rejected.

『B.』 Include:

Use case name	Create a new Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new blog account from the Administrator.
Preconditions	The author has appropriate proof of identity.
Successful End Condition	A new blog account is created for the author.
Failed End Condition	The application for a new blog account is rejected.
Primary Actors	Administrator
Secondary Actors	None
Trigger	The Administrator asks the CMS to create a new blog account.
Included Cases	Check Identity
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects an account type.
	3	The Administrator enters the author's details.
	4 include::Check Identity	The author's details are checked.
	5	The new account is created.
	6	A summary of the new blog account's details are emailed to the author.

Use case name	Create a new Personal Wiki
Related Requirements	Requirement A.2
Goal In Context	A new or existing author requests a new personal Wiki from the Administrator.
Preconditions	The author has appropriate proof of identity.
Successful End Condition	A new personal Wiki is created for the author.
Failed End Condition	The application for a new personal Wiki is rejected.
Primary Actors	Administrator
Secondary Actors	None
Trigger	The Administrator asks the CMS to create a new personal Wiki.
Included Cases	Check Identity
Main Flow	Step	Action
	1	The Administrator asks the system to create a new personal Wiki.
	2	The Administrator enters the author's details.
	3 include::Check Identity	The author's details are checked.
	5	The new personal Wiki is created.
	6	A summary of the new personal Wiki's details are emailed to the author.

Use case name	Check Identity
Related Requirements	Requirement A.1, Requirement A.2.
Goal In Context	An author's details need to be checked and verified as accurate.
Preconditions	The author being checked has appropriate proof of identity.
Successful End Condition	The details are verified.
Failed End Condition	The details are not verified.
Primary Actors	Author Credentials Database.
Secondary Actors	None.
Trigger	An author's credentials are provided to the system for verification.
Main Flow	Step	Action
	1	The details are provided to the system.
	2	The Author Credentials Database verifies the details.
	3	The details are returned as verified by the Author Credentials Database.
Extensions	Step	Branching Action
	2.1	The Author Credentials Database does not verify the details.
	2.2	The details are returned as unverified.

『C.』 Generializtion:

Use case name	Create a new Editorial Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new editorial blog account from the Administrator .
Preconditions	The author has appropriate proof of identity.
Successful End Condition	A new editorial blog account is created for the author.
Failed End Condition	The application for a new editorial blog account is rejected.
Primary Actors	Administrator.
Secondary Actors	None.
Trigger	The Administrator asks the CMS to create a new editorial account that will allow an author to edit entries in a set of blogs.
Base Use Cases	Create a new Blog Account
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects the editorial account type.
	3	The Administrator enters the author's details.
	4	The Administrator selects the blogs that the account is to have editorial rights over.
	5 include::Check Identity	The author's details are checked.
	6	The new editorial account is created.
	7	A summary of the new editorial account's details are emailed to the author.
Extensions	Step	Branching Action
	5.1	The author is not allowed to edit the indicated blogs.
	5.2	The editorial blog account application is rejected.
	5.3	The application rejection is recorded as part of the author's history.

『D.』 Extend:

Use case name	Create a new Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new blog account from the Administrator.
Preconditions	The author has appropriate proof of identity.
Successful End Condition	A new blog account is created for the author.
Failed End Condition	The application for a new blog account is rejected.
Primary Actors	Administrator.
Secondary Actors	None.
Trigger	The Administrator asks the CMS to create a new blog account.
Included Cases	Check Identity
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects an account type.
	3	The Administrator enters the author's details.
	4 include::Check Identity	The author's details are checked.
	5	The new account is created.
	6	A summary of the new blog account's details are emailed to the author.
Extensions	Step	Branching Action
	4.1	The author is not allowed to create a new blog.
	4.2	The blog account application is rejected.
	4.3	The application rejection is recorded as part of the author's history.

2.Activity diagram

Based on：

Use case name	Create a new Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new blog account from the Administrator.
Preconditions	The system is limited to recognized authors, and so the author needs to have appropriate proof of identity.
Successful End Condition	A new blog account is created for the author.
Failed End Condition	The application for a new blog account is rejected.
Primary Actors	Administrator.
Secondary Actors	Author Credentials Database.
Trigger	The Administrator asks the Content Management System to create a new blog account.
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects an account type.
	3	The Administrator enters the author's details.
	4	The author's details are verified using the Author Credentials Database.
	5	The new blog account is created.
	6	A summary of the new blog account's details are emailed to the author.
Extensions	Step	Branching Action
	4.1	The Author Credentials Database does not verify the author's details.
	4.2	The author's new blog account application is rejected.

3.class diagram

『A.』 dependency

declares that a class needs to know about another class to use objects of that class.

The dependency relationship is often used when you have a class that is providing a set of general-purpose utility functions, such as in Java's regular expression (java.util.regex ) and mathematics (java.math ) packages. Classes depend on the java.util.regex and java.math classes to use the utilities that those classes offer.

『B.』 association

association means that a class will actually contain a reference to an object, or objects, of the other class in the form of an attribute.

Note that: the difference between association and dependency is that in the case of the former related objects are in the form of attributes and in the latter case there is no such a requirement. In the latter case related objects may be used as local variables or locally used.

the related codes are:

public class BlogAccount { // Attribute introduced thanks to the association with the BlogEntry class private BlogEntry[] entries; // ... Other Attributes and Methods declared here ... } public class BlogEntry { // Attribute introduced thanks to the association with the Blog class private BlogAccount blog; // ... Other Attributes and Methods declared here ... }

Note two words in the diagram: “blog” and “entries”. They are corresponded to the two fields in the two classes. And are there necessaries to mark up fields in the class diagram?

4.Object diagram

Object with a name:

Object with the name and class:

Anonymous object:

Class diagram and object diagram:

Class diagrams describe how all of the different types of objects within your system interact with each other. They also draw attention to the many ways that the objects will exist and interact within your system at runtime. In addition to class diagrams, object diagrams help you capture the logical view of your model,

5.Sequence Diagram

Table 7-1. How to understand the components of a participant's name
Example participant name	Description
admin	A part is named admin, but at this point in time the part has not been assigned a class.
: ContentManagementSystem	The class of the participant is ContentManagementSystem, but the part currently does not have its own name.
admin : Administrator	There is a part that has a name of admin and is of the class Administrator.
eventHandlers [2] : EventHandler	There is a part that is accessed within an array at element 2, and it is of the class EventHandler.
: ContentManagementSystem ref cmsInteraction	The participant is of the class ContentManagementSystem, and there is another interaction diagram called cmsInteraction that shows how the participant works internally (see "A Brief Overview of UML 2.0's Fragment Types," later in this chapter).

Event, signal, message:

Events are the building blocks for signals and messages. Signals and messages are really different names for the same concept: a signal is the terminology often used by system designers, while software designers often prefer messages.

another diagram:

message signatures:

A message arrow comes with a description, or signature. The format for a message signature is:

attribute = signal_or_message_name (arguments) : return_type

You can specify any number of different arguments on a message, each separated using a comma. The format of an argument is:

<name>:<class>

Table 7-2. How to understand the components of a message's signature
Example message signature	Description
doSomething( )	The message's name is doSomething, but no further information is known about it.
doSomething(number1 : Number, number2 : Number)	The message's name is doSomething, and it takes two arguments, number1 and number2, which are both of class Number.
doSomething( ) : ReturnClass	The message's name is doSomething; it takes no arguments and returns an object of class ReturnClass.
myVar = doSomething( ) : ReturnClass	The message's name is doSomething; it takes no arguments, and it returns an object of class ReturnClass that is assigned to the myVar attribute of the message caller.

Nested messages:

When a message from one participant results in one or more messages being sent by the receiving participant, those resulting messages are said to be nested within the triggering message,

message types:

sequence fragment，建模复杂结构：

更多参见

http://www.ibm.com/developerworks/rational/library/3101.html

Table 7-4. The fragment family and explanations why each type might be useful when creating sequence diagrams
Type	Parameters	Why is it useful?
ref	None	Represents an interaction that is defined elsewhere in the model. Helps you manage a large diagram by splitting, and potentially reusing, a collection of interactions. Similar to the reuse modeled when the <<include>> use case relationship is applied.
assert	None	Specifies that the interactions contained within the fragment box must occur exactly as they are indicated; otherwise the fragment is declared invalid and an exception should be raised. Works in a similar fashion to the assert statement in Java. Useful when specifying that every step in an interaction must occur successfully, i.e., when modeling a transaction.
loop	min times, max times, [guard_condition]	Loops through the interactions contained within the fragment a specified number of times until the guard condition is evaluated to false. Very similar to the Java and C# for(..) loop. Useful when you are trying execute a set of interactions a specific number of times.
break	None	If the interactions contained within the break fragment occur, then any enclosing interaction, most commonly a loop fragment , should be exited. Similar to the break statement in Java and C#.
alt	[guard_condition1] ... [guard_condition2] ... [else]	Depending on which guard condition evaluates to true first, the corresponding sub-collection of interactions will be executed. Helps you specify that a set of interactions will be executed only under certain conditions. Similar to an if(..) else statement in code.
opt	[guard_condition]	The interactions contained within this fragment will execute only if the guard condition evaluates to true. Similar to a simple if(..) statement in code with no corresponding else. Especially useful when showing steps that have been reused from another use case's sequence diagrams, where <<extend>> is the use case relationship.
neg	None	Declares that the interactions inside this fragment are not to be executed, ever. Helpful if you are just trying to mark a collection of interactions as not executed until you're sure that those interactions can be removed. Most useful if you happen to be lucky enough to be using an Executable UML tool where your sequence diagrams are actually being run. Also can be helpful to show that something cannot be done, e.g., when you want to show that a participant cannot call read( ) on a socket after close( ).Works in a similar fashion to commenting out some method calls in code.
par	None	Specifies that interactions within this fragment can happily execute in parallel. This is similar to saying that there is no need for any thread-safe locking required within a set of interactions.
region	None	Interactions within this type of fragment are said to be part of a critical region. A critical region is typically an area where a shared participant is updated. Combined with parallel interactions, specified using the par fragment type, you can model where interactions are not required to be thread- or process-safe (par fragment) and where locks are required to prevent parallel interactions interleaving (region fragment ). Has similarities synchronized blocks and object locks in Java.

UML1.X使用guard的方式：

6.State Machine Diagrams

The key elements are state and transition.

Internal Behavior of states:

Entry behavior happens as soon as the state becomes active and is written as entry/behavior. Exit behavior happens immediately before the state becomes inactive and is written as exit/behavior. do behavior, which is behavior that is ongoing while the state is active.

internal transition: a transition that causes a reaction within a state, but doesn't cause the object to change states. An internal transition is different from a self transition because self transitions cause entry and exit behavior to occur whereas internal transitions don't.

Internal transitions are written as trigger [guard] / behavior, and they are listed inside a state.

singles:

The main purpose of the diagram bellow is to visually emphasize sending and receiving signals. Although both diagrams say the same thing, the version with the signal icons focuses on the transitions and, in this case, makes the diagram more readable.