Home arrow Practices arrow Page 4 - Class Relationships

Dependencies - Practices

With the UML, it is the relationships between classes that provide structure to what you are creating. This article explains how to use the UML to illustrate various kinds of class relationships. It is taken from chapter two of Fast Track UML 2.0 written by Kendall Scott (Apress, 2004; ISBN: 1590593200).

TABLE OF CONTENTS:
  1. Class Relationships
  2. Aggregation
  3. Generalization
  4. Dependencies
  5. Association Classes
By: Apress Publishing
Rating: starstarstarstarstar / 36
June 16, 2005

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

A dependency is a “using” relationship within which a change in one thing (such as a class) may affect another thing (for instance, another class). The dependent element is called the client or source; the independent element is called the supplier or target.

A dependency involving two classes appears as a dashed line with a feathered arrow pointing at the supplier. Figure 2-16 shows an example of a dependency.


Figure 2-16Dependency

If the definition of the Book class changes, the way that the checkAvailability function works may have to change as well.

The UML defines a number of stereotypes that apply to dependencies. These are explored in the following subsections.

Usage Dependencies

A usage dependency is one in which the client requires the presence of the supplier for its correct functioning or implementation.

You model a generic usage dependency using the «use» stereotype. Figure 2-17 shows that instances of the Order class require instances of the OrderItem class in order to function properly.


Figure 2-17Usage dependency

The UML defines the following five types of usage dependencies:

  • A call dependency («call») signifies that the source operation invokes the target operation.
  • A create dependency («create») signifies that the source class creates one or more instances of the target class.

Within Figure 2-18, an instance of the Order class creates one more instances of the JournalEntry class.


Figure 2-18Create dependency

  • An instantiation dependency («instantiate») signifies that one or more methods belonging to instances of the source class create instances of the target class.

Within Figure 2-19, a method belonging to an instance of the HTMLPageHandler class creates an instance of the LoginPage class.


                  Figure 2-19. Instantiation

  • A responsibility dependency («responsibility») signifies that the client has some kind of obligation to the supplier.

  • A send dependency («send») signifies that instances of the source class send signals to instances of the target class. (Signals are discussed in Chapter 6.)

Abstraction Dependencies

An abstraction dependency is one in which the client is at one level of abstraction and the supplier is at a different level.

You model a generic usage dependency using the «abstraction» stereotype. Figure 2-20 shows that the SShoppingCart class is more concrete than the ShoppingCart class. (A session bean is a type of EnterpriseJava Bean [EJB]. See Mastering Enterprise JavaBeans1 for more information about EJBs.)


Figure 2-20Abstraction dependency 

The UML defines the following five types of abstraction dependencies:

  • A derivation dependency («derive») signifies that the client can be computed or inferred from the supplier.

Within Figure 2-21, you can derive the association between Account and Order by navigating from Account to BillingInfo to Order.


Figure 2-21Derivation dependency

  • A realization dependency («realize») signifies that the supplier serves as the implementation of the client. (Note that in this context, “implementation” implies a more elaborate form of the client, not necessarily a physical implementation as, say, program code.)

Within Figure 2-22, the PhysicalOrder class “implements” the Order class. (See the section “Other Stereotypes on Classes” in Chapter 1 for a discus sion of the «implementationClass» stereotype.)


Figure 2-22Realization dependency

Note the differences between this type of dependency and the type of realization discussed in Chapter 1 (see the section “Interfaces, Ports, and Connectors” in Chapter 1).

  • A refinement dependency («refine») signifies that the supplier is at a lower level of abstraction than the client.

Within Figure 2-23, the Order class on the right is an active class that represents a refinement, at the design level, of the Order class on the left.


Figure 2-23Refinement dependency

  • A trace dependency («trace») signifies a conceptual connection among elements contained within different models.

Figure 2-24 shows that you can trace the LoginManager class, which probably belongs to the analysis-level model, to the SessionManager class, which probably belongs to a design-level model.


Figure 2-24Trace dependency

  • A manifestation dependency («manifest») signifies that a target artifact represents the concrete physical realization of one or more source classes. (Manifestations are discussed in Chapter 9.)
Permission and Substitution Dependencies

A permission dependency («permit») signifies that the supplier grants the client permission to access some or all of its constituent elements.

Within Figure 2-25, the Customer class grants the RecommendationEngine class access to its private attributes emailAddress and name.


Figure 2-25Permission dependency

A substitution dependency («substitute») signifies that the client will comply with the contract specified by the supplier at program execution time.

Within Figure 2-26, a more specific Login Page adheres to the basic framework within which a generic HTML Page works.


Figure 2-26Substitution dependency

Figure 2-26. Substitution dependency



 
 
>>> More Practices Articles          >>> More By Apress Publishing
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: