Keynote address - data abstraction and hierarchy
OOPSLA '87 Addendum to the proceedings on Object-oriented programming systems, languages and applications (Addendum)
Object-oriented modeling and design
Object-oriented modeling and design
EROOS: an entity-relationship based object-oriented specification method
TOOLS 7 Proceedings of the seventh international conference on Technology of object-oriented languages and systems
Object-oriented programming in the BETA programming language
Object-oriented programming in the BETA programming language
An introduction to object-oriented programming (2nd ed.)
An introduction to object-oriented programming (2nd ed.)
On formal requirements modeling languages: RML revisited
ICSE '94 Proceedings of the 16th international conference on Software engineering
Object-oriented software construction (2nd ed.)
Object-oriented software construction (2nd ed.)
The Unified Modeling Language reference manual
The Unified Modeling Language reference manual
On the representation of roles in object-oriented and conceptual modelling
Data & Knowledge Engineering
Constraints in Object-Oriented Analysis
Proceedings of the First JSSST International Symposium on Object Technologies for Advanced Software
On the Transformation of Object-Oriented Conceptual Models to Logical Theories
ER '02 Proceedings of the 21st International Conference on Conceptual Modeling
Hi-index | 0.00 |
The driving force in object-oriented analysis to use the concept of specialization/generalization is polymorphism: the capability and need to reason about the union of the sets of objects of the specialization classes. Hereby features will be defined at the appropriate place. The fact that classes have common features is not a sufficient condition to generalize. The principle of strengthening specifications of features is an indispensable rule to manage class hierarchies. From the viewpoint of polymorphism, multiple specialization/generalization is only a logical extension of this modeling concept and not an optional or exotic one. Further, we discuss some guidelines to build sound class hierarchies, such as using (multiple) partitions.