use

case.dk

Owned sites

Other sites

Business best practice - design patterns and OOD

UML is used as notation to describe elements and their dependencies in systems.

Benefits of UML

Allow specification of architecture at abstraction level
Define notation used in communication between designers, architects and developers
Allow to systematicly capture reusable experience, solving re-occurring types of problem

1. Use Case

Elements: describes the elements used to form a usecase

1. 1. Use Case Icon

Define icon for use case: "A use case is a narrative document that describes the sequence of events of an actor (an external Agent) using a system to complete a process" [Jacobsen, I.,1992, "Object-Oriented Software Engineering: A Use Case Driven Approach].

1. 2. Actor

Define entity, interacting with the usecase. The actor or participating actor is an external body engaging in the story of the use case. Type of interaction can be providing input events or receiving response from it. An actors is represented as the role played in the use case, such as client, customer, etc. Often actors are capitalized in use case formulation for intuitive identification.

Initiator Actor - defines the initiating actor who generates the starting stimulus - causing possible further action with other participating actors.

Primary Actors Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.

Secondary Actors Actors are required by the system for assistance to achieve the primary actors goal..

1. 3. System boundary

Defines the point of interaction with the use case. Typical boundaries could be: software application, device, computer system, organisation, etc. Boundary is important in the sense that it seperates what is internal/external in regard to the use case - and identifies the responsabilities and level of interaction for the involved parties. External environment is represneted entirely by actors.

1. 4. Neighbour System

Defines other system of interest to the use case - which not necessarily interacts with the use case.

1. 5. Base Extension Points

Defines extension points for the base use case. A use case can have extension points and they show where an extending use case is allowed to add functionality - where the behavior of an extension use case can be inserted into the base use case. The specification text can be informal or precise to define the location of the extension point. Note that conditions to apply that extending use case and the extension point to use should be attached as a note to the extend relationship. Extension use case includes a Title, and one ore more parts. Parts are to be inserted at specific extension points in a base use case. A part includes:

reference to an extension point (defined in a base use case in reference to a step)
sequence of steps, except extension use cases cannot include extension points

For example:

1. 6. Alternate Extension Point

Alternative Course specifies a guarded variation of a part of another interaction course. As such, it is subject to some business condition. The location where an alternative course branches to another interaction course is called an Extension Point. Originally UML introduced the term extension point to indicate branching locations for the extend-relationship only. Extend-relationship is used to attach extracted optional behaviour residing in an additional use case, to its base use case. However, the term extension point can also be considered applicable to branching points of alternative courses that remain local textual use case properties since this reduces the number of terms needed.

1. 7. Initial node

The filled in circle is the starting point of the diagram. An initial node isn't required although it does make it significantly easier to read the diagram.

1. 8. Actor Hierarchy

Define the relationship between actors. Specification of inheritance :

1. 9. Work Process Hierarchy

Define the relationship between work processes. Specification of inheritance :

1. 10. Note

Define commenting remark not possible otherwise to specify with UML notation:

2. Relationships

Elements: describes interaction subjected to basic uml elements

2. 1. Dependancy

Defines situation where one entity uses another, but the latter is not a member of (field in) the first. If the depending entity is modified, some method of the original entity might need to be modified. The line is typically stereotyped (e.g. denoted «creates» or «modifies»)

2. 2. Dependancy: extends

Defines relationships between use cases taking advantage of re-use. Extension dependency (originating from extends relationship in UML), is a generalization relationship where an extending use case continues the behavior of a base use case. In the diagram, the extending use case #1 formally extends the base use case #2. Extension is conceptually achieved by inserting additional action sequences into the base use-case sequence. The extending use case continues the activity sequence of a base use case from the point where appropriate extension point is reached in the base use case and the extension condition is met. On completion of the extending use case activity sequence, the base use case continues.

Generally an extending usecase is introduced where logic for an alternate course of action is at a complexity level equivalent the basic course of action - or the alternate sequence of steps forms a natural unit. Extend dependencies often may make use case diagrams more difficult to understand - and should be used carefully. The extending use case in this case #1 would list the base use case #2, in its "Extends" list.

Notation for extension is a normal use case dependency with the stereotype of <<extend>>.

2. 3. Dependancy: include

Defines relationships between use cases taking advantage of re-use. Include dependency (originating from uses relationship in UML), is a generalization relationship where the use case may encapsulate behavior described by another use case. Basicly the include dependency just allows invocation of one use case by another one. In the diagram, the including use case #1 formally includes (calls) the base use case #2. The use case inclusion bear similarities to to calling a function or invoking an operation within a program. Include dependencies are used where

one use case simply requires behavior of another use case
level of complexity requires break-down of use case functionality
re-use... repeated use of similar behavior makes it sensible to encapsulate the repeated logic

Including use case functionality are often used for CRUD examples: create/retrieve/update/delete - and search functionality. Multiple use cases may require behavior to search for and update information, indicating the potential need for a "Find" or "Update" use case included by the other use cases. As you would expect, the use case #1 should list #2 in its "Includes" list. Argument for maintaining an "Includes" and an "Extends" list for use cases is to allow use cases to stand on their own. Diagrams and description may be maintained by different tools (case-tool and word processor) and both may not always be displayed simultaneously. But usage of "Includes" and an "Extends" lists will help to maintain constant focus on relations between the use cases. Disadvantage is the need to apply changes simultaneously to the diagram/lists (two places to update) - and a risk that information may become unsynchronized.

Notation for include is a normal use case dependency with the stereotype of <<include>>.

2. 4. Association (undirected): uses

Defines relationships between entities (originating from undirected association relationship in UML). Undirected, associated entities are connected by lineswithout with arrow head > or < (solid or not).

In UML notation, undirected usually means:

it has not been decided if the association is directed
the association is bidirectional

In use case perspective, the association may actually be directed despite missing arrow head, but it is not considered an important issue for the use case.

2. 5. Association (directed): initiates

Defines relationships between actor and usecase, where actor initiates the usecase.

2. 6. Association, aggregation

Defines relationships between entities, where destroying the "whole" does not destroy the parts.

Both "aggregation" and "composition" really don't have direct analogs in Java. An "aggregate" represents a whole that comprises various parts; so, a Club is an aggregate of its Members. A Meeting is an aggregate of an Agenda, Room, Attendees. At implementation time, this is not really a containment relationship since the parts of the aggregate might be doing other things elsewhere in the program. There's no implementation-level difference between aggregation and a simple "uses" relationship (an "association" line with no diamonds on it at all). In both cases an object has references to other objects. Though there's no implementation difference, it's definitely worth capturing the relationship in the UML, both because it helps you understand the domain model better, and because there are subtle implementation issues. It is possible to allow tighter coupling relationships in a composition than with a simple "uses,".

Cardinality can be used to indicate relationship to either side:

1 exactly one (usually omitted if 1:1)

0..* 0 or more

* 0 or more (as above)

n unknown at compile time, but bound

0..n between 0 and some bound number unknown at compile time (n)

1,8 either 1 or 8

1..8 between 1 and 8 (both inclusive)

2. 7. Association, composition

Defines relationships between entities with a (has) relationship. The parts are destroyed along with the "whole." Not really concept in Java - but used indirectly in the servlet definition, where method public void destroy() {} is called upon container shutdown. But used explicitly in C++ when defining destructor method to be called when object is destroyed.

Composition involves tighter coupling than aggregation, and involves containment. The basic requirement is that, if a class of objects (call it a "container") is composed of other objects (call them the "elements"), then the elements will come into existence and also be destroyed as a side effect of creating or destroying the container. It would be rare for a element not to be declared as private. An example might be an Customer's name and address. A Customer without a name or address is a worthless thing. By the same token, when the Customer is destroyed, there's no point in keeping the name and address around. (Compare this situation with aggregation, where destroying the Committee should not cause the members to be destroyed---they may be members of other Committees).

In terms of implementation, the elements in a composition relationship are typically created by the constructor or an initializer in a field declaration, but Java doesn't have a destructor, so there's no way to guarantee that the elements are destroyed along with the container. In C++, the element would be an object (not a reference or pointer) that's declared as a field in another object, so creation and destruction of the element would be automatic. Java has no such mechanism. It's nonetheless important to specify a containment relationship in the UML, because this relationship tells the implementation/testing folks that your intent is for the element to become garbage collectable (i.e. there should be no references to it) when the container is destroyed.

Cardinality specified as above.

2. 8. Generalization

Defines re-use through inheritance. Derived (sub) use case #2 is a specialization of (extends) the base (super) use case #1. #2 is the super-entity, where behaviour will be handed down to the derived entity. In other words, use case #1 inherits from the use case #2.

Inheritance can applied between use cases - or between actors. Inheritance between use cases is more rare compared to use of "extend" or "include" dependencies, but still possible. Inheritance between actors is more common, where an actor may be a specialization of a larger system or another actor.

Inheriting use case would completely replace one/more courses of action of the inherited use case. Then the basic course of action is completely rewritten to reflect that new business rules are being applied. This corresponds to overloading methods or operators in OO languages. Applying inheritance between use cases could be relevant where a single changed condition, would result in the definition of several alternate courses. Without the option to define an inheriting use case, it would be necessary to introduce an alternate course to rework the entire behaviour. Reduction of complexity is a factor where the inheriting use case becomes simpler than the base use case from where is inherited. The derived use case should have a name, description, and identifier, and contain a "Inherits From" section indicating from where the use case inherits functionality - and specification of what sections are replaced, pre-conditions and post-conditions as well as any courses of action. Where things is not replaced, the section may be left blank, indicating inheritance from the parent use case (also possible to put textual references "see parent use case," in the section). Inheritance from multiple sources into a single use case is never used - so there will usually only be a single inheritance reference to keep track of.

Inheritance between actors are often described in an "Actor Hierarchy".

For inheritance, standard UML notation (open-headed arrow), is used. When describing inheritance relations it will be appropriate to describe that the inheriting actor "is" or "is like" the inherited actor.

2. 9. Realization

Defines implementation of interface. Realization is the fullfillment of the interface contract specifying a set of methods that must be implemented by the derived entity. In C++, an interface is an entity containing nothing but pure virtual methods.

Inheritance are in fact used very rarely for use case components (actors) and does not play a practical role in the construction of use cases.

For realization, standard UML notation (open-headed arrow, dotted line), is used. When describing inheritance relations it will be appropriate to describe that the realizing actor acting within the limits of the role of the other actor.

Contents