Practices
  Home arrow Practices arrow Page 3 - Class Relationships
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
IBM Rational Software Development Conference
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
PRACTICES

Class Relationships
By: Apress Publishing
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 3 stars3 stars3 stars3 stars3 stars / 9
    2005-06-16

    Table of Contents:
  • Class Relationships
  • Aggregation
  • Generalization
  • Dependencies
  • Association Classes

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    Class Relationships - Generalization
    (Page 3 of 5 )

    Generalization refers to a relationship between a general class (the superclass or parent) and a more specific version of that class (the subclass or child). You can think of the subclass as being a “kind of” the superclass.

    A generalization appears as a line with an open triangle at one end. The class next to the triangle is the parent/superclass; the class at the other end of the line is the child/subclass. See Figure 2-12.


    Figure 2-12Generalization notation

    If a given class has more than one child/subclass, you can show each generalization using a separate line, or you can consolidate the lines, as with aggregation. Figure 2-13 shows both variations.


    Figure 2-13Generalizing multiple classes

    Figure 2-14 shows a sample generalization.


    Figure 2-14Generalization

    Note the change between Figure 2-14 and Figure 1-3 (see Chapter 1): The operations that used to belong to the Review class have been “pushed down” into Customer Review. This is because these methods don’t apply to the new Editorial Review class. This is a good example of how the subclass, Customer Review, specializes the more general superclass, Review.

    We’ve only looked at “single” inheritance to this point, but the UML also offers a way to model multiple inheritance—in other words, generalizations within which a class is a child of two or more parents. The basic notation is the same; the diagrams just get a little harder to read. Multiple inheritance is something of a tricky subject that’s outside the scope of this book, except as referenced in the following paragraphs. (It’s also something that some implementation platforms, such as .NET, and languages, such as C#, don’t support.)

    You can use a generalization set to define partitions for the subclasses of a particular class (the superclass). The superclass acts as the powertype for the generalization set, which means that the instances of that superclass are also subclasses of another class.

    Within Figure 2-15, PaymentType serves as a powertype on Payment.


    Figure 2-15Powertype

    In other words, the instances of PaymentType include those named CreditCard, CorporateAccount, and GiftCertificate—each of which is, in turn, a subclass of Payment. Each of these classes forms its own generalization set; this provides the modeler with extra flexibility in defining behavior associated with each subclass.

    The UML offers the following four constraints (see the section “More About Operations” in Chapter 1), which you can use in conjunction with generalization sets:

    • The {incomplete} constraint means that not all children have been speci fied for a given generalization set and that more can be specified.

    • The {complete} constraint means that all children have been specified for a given generalization set and that no more can be specified.

    • The {disjoint} constraint means that given multiple inheritance, no object can be an instance of more than one child within the generalization set.

    • The {overlapping} constraint means that given multiple inheritance, an object can be an instance of more than one child within the generaliza tion set.

    More Practices Articles
    More By Apress Publishing


     

    Buy this book now. This article is taken from Fast Track UML 2.0 written by Kendall Scott (Apress, 2004; ISBN: 1590593200). Check it out at your favorite bookstore. Buy this book now.

       

    PRACTICES ARTICLES

    - 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
    - Basic Ideas
    - Choosing the Right Team
    - Trees
    - Basic Array Searching in C++
    - Solving Problems with Recursion

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway