Examining the UML Models: Static Models - Generalization Relationship
(Page 6 of 13 )
The generalization relationship specifies that a class is a subclass of another class and inherits the base class’s public operations and attributes. For example, if you have a base class and you want all other classes to inherit from that class, you’ll place a generalization relationship between the two classes. The same applies if your classes represent ASP.NET pages and you want all ASP.NET pages to inherit from a base ASP.NET Web page.
In Exercise 5-10, you added the VIPCustomer class to your class diagram. This class represents important customers who might be involved in a bonus program. Still, VIP customers are indeed customers as well, so inheritance from the Customer base class makes sense. In Exercise 5-11, you’ll add a generalization relationship between the Customer and VIPCustomer classes.
EXERCISE 5-11
- In the MyClassDiagram static structure diagram, add a generalization relationship between the Customer and VIPCustomer classes.
- Double-click the generalization relationship to open the UML Generalization Properties dialog box.
- Select inherits from the Stereotype list, to show this stereotype on the diagram.
- Click OK.
In Figure 5-21, you can see the VIPCustomer inherits the Customer through the generalization class, and thereby gets access to the operations and attributes from the Customer class.
In Figure 5-22, you can see the code generation preview for the VIPCustomer class. Notice that the class inherits from Customer and that it imports the MyNamespace namespace, because Customer is created within this namespace.
NOTE For code-generation purposes, you don’t need to specify the inherits stereotype. The correct code will be generated as long as you specify the appropriate generalization relationship.
Figure 5-21. Generalization relationship between the Customer and VIPCustomer classes
Figure 5-22. Code preview for the VIPCustomer class
Generalization, OOP Inheritance, and Polymorphism
In OOP, inheritance is modeled via generalization. You can create multiple inheritances (nested). However, too many levels of inheritance make your code and model difficult to read and maintain. You should avoid nesting inheritance more than three levels deep.
You can inherit a class you don’t even have the source code for and use it in your own class. Can you see the advantage? Find a class that almost does what you want. Create your own class that inherits from the one you’ve found, and add the functionality it’s missing. This is the essence of OOP.
Polymorphism is tightly related to inheritance. Polymorphism means that an operation can exist in several versions. For example, suppose that you have a class named SoccerPlayer with an operation named Run. The Run operation tells the soccer player where to run. If the player is a defender, he will run to a different location on the field than a midfielder will run. So, add two more classes called Defender and Midfielder, both inheriting from the SoccerPlayer class. Wouldn’t it be nice if both classes have an operation called Run that overrides the Run operation from the SoccerPlayer class? Yes, it would, because that way, you only need to call the Run operation in your program, and your player will always run to the right location. This is polymorphism, because your Run operation exists in different versions and overrides the parent Run operation.
To implement polymorphism, simply add an operation with the same name in both the parent class and the child class, and mark the operation in the parent class as IsPolymorphic (from the UML Class Properties dialog box or the UML Operation Properties dialog box). The code generator adds the Overridable keyword to the operation in VB; no keyword is necessary in C#.
Statechart Diagrams A statechart diagram is created to identify and document the internal behavior of an object. This way, you can get an overview of the object life cycle and identify the functionality to be implemented. Statechart diagrams are popular when developing truly object-oriented software, because they describe the dynamic behavior of an object in detail.
The content of a statechart diagram is a sequence of states that the object goes through during its lifetime. Legal state changes are shown by transitions. Events cause the object to change from one state into another. Statechart diagrams consist of the following:
- States
- Transitions
- Decisions
Figure 5-23 shows a statechart diagram with these elements. The following sections describe how they work.
Figure 5-23. Statechart diagram
Next: States >>
More .NET Articles
More By Apress Publishing
|
 This article is excerpted from Enterprise Development with Visual Studio .NET, UML, and MSF written by John Erik Hansen and Carsten Thomsen (Apress, 2004; ISBN: 1590590422) Buy this book now.
|
|
