Issue 1582: Type vs. Implementastion class (issues) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the Notation Guide, version 1.1. Complete suggested text is availabl ein the issues"s archive Resolution: Revised Text: same as issue 1365---redundant Actions taken: June 26, 1998: received issue June 26, 1998: closed issue Discussion: closed issue End of Annotations:===== Return-Path: X-Sender: seidewitz@mail.dhr.com Date: Thu, 25 Jun 1998 17:24:13 -0400 To: uml-rtf@omg.org From: Ed Seidewitz Subject: My Action Item: Type vs.Implementation Class (Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the Notation Guide, version 1.1.) Classes can be stereotyped as types or implementation classes (although they can be left undifferentiated as well). A type is used to specify of a domain of objects together with operations applicable to the objects without defining the physical implementation of those objects. A type may not include any methods, but it may provide behavioral specifications for its operations. It may also have attributes and associations that are defined solely for the purpose of specifying the behavior of the type's operations and do not represent any actual implementation of state data. An implementation class defines the physical data structure (for attributes and associations) and methods of an object as implemented in traditional languages (C++, Smalltalk, etc.). An implementation class is said to _realize_ a type if the implementation class provides at least all the operations defined for the type with the same behavior as specified for the type's operations. An Implementation Class may realize a number of different types. Note that the physical attributes and associations of the implementation class do not have to be the same as those of any type it realizes and that the implementation class may provide methods for its operations in terms of its physical attributes and associations. An object may have at most one implementation class, since this specifies the physical implementation of the object. However, an object may conform to multiple different types. If the object has an implementation class, then that implementation class should realize the types to which the object conforms. If dynamic classification is used, then the types to which an object conforms may actually change dynamically. A type may be used in this way to characterize a changeable role that an object may adopt and later abandon. Although the use of types an implementation classes is different, their internal structure is the same and they are both classifiers of objects. Therefore they are modeled as stereotypes of classes. As such, they both fully support the usual generalization/specialization and the inheritance of attributes, associations and operations. Note, however, the types my only specialize other types and implementation classes may only specialize other implementation classes. Types and implementation classes can be related only be realization. [I also noticed that the example in section 5.9.3 on the next page has a problem. It doesn't really make sense for the Set type to have an attribute of type Collection, since a set IS a Collection. It also doesn't make sense for the implementation class HashTableSet to have this attribute at all. I would drop the attribute on Set, eliminate the generalization from HashTableSet to HashTable and make the elements attribute of HashTableSet have type HashTable (or use an association with HashTable).] _______________________________________________________________________ Ed Seidewitz Manager, Object Systems Product Line DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________