Identifying classes and objects ooad
1 like3,809 views
This document discusses different approaches to identifying classes and objects in object-oriented analysis, including: 1. Classical categorization, conceptual clustering, and prototype theory which group entities based on common properties. 2. Behavior analysis which identifies objects based on their behaviors and responsibilities. 3. Use case analysis which identifies participant objects and responsibilities by analyzing system usage scenarios. 4. CRC cards which record each class's responsibilities and collaborations to represent system interactions.
Identifying classes and objects ooad
- 1. I D E N T I F Y I N G C L A SS E S A N D O B J E C T S J MELBA ROSALIND, DEPARTMENT OF COMPUTER SCIENCE LADY DOAK COLLEGE, MADURAI CLASSIFICATION
- 2. CLASSIFICATION APPROACHES • The following three types of classification are generally employed: 1. Classical Categorization 2. Conceptual Clustering 3. Prototype Theory
- 3. CLASSICAL CATEGORIZATION• Classical categorization originated during Greece’s classical period • All entities have common properties in common which is sufficient to define the category. Eg. Married people vs. tall people • Plato, Aristotle in classifying plants and animals • Children’s game • Aquinas says, ” we can name a thing according to the knowledge we have of its nature from its properties and effects” • Piaget observed - around the age of one child develops the concepts of object permanence • This approach uses related properties as the criteria for sameness among objects
- 4. CONTD.. •Minsky suggests, “the most useful sets of properties are those whose members do not interact too much” •Eg. Size, color, shape, substance (combination) •An eagle from a salmon (bird can fly but a fish cannot) •Particular properties in a given situation is domain-specific (color of a car in automobile manufacturing plant vs. traffic signaling) •Kosko observes, “natural categories tend to be messy” •Not all birds fly, some chairs can have any number of legs
- 6. CONCEPTUAL CLUSTERING • Modern variation of classical approach • Classes are generated by formulating conceptual descriptions and then classifying according to the descriptions • Eg. “a love song” • Probabilistic clustering of objects – related to fuzzy set theory – may or may not belong to one or more groups in varying degree of fitness • Absolute judgements of classification by focusing on the “best fit” • Eg. A Problem of classification ( ten items of a Train A - J )
- 7. PROTOTYPE THEORY • Derived from Rosh and her colleagues in the field of cognitive psychology • Class of object is represented by a prototypical object, an object is member of a class iff it resembles this prototype in significant ways • Wittgenstein observed there is no fixed boundary to the category game rather united by family resemblances • Lakoff and Johnson applied in the problem of classifying chairs (beanbag chair, barber chair, contour chair, etc., as being chairs) • Notion of Interactional properties is central part to the idea of prototype theory • Group the things according to the degree of their relationship to concrete prototypes
- 8. OBJECT-ORIENTED ANALYSIS • In this analysis, – focus is to fully analyze the problem at hand and to model the world to discover the classes and objects that comprise the vocabulary of the problem domain • Proven Approaches in carrying out this task… – Classical approaches – Behavior Analysis – Domain Analysis – Use Case Analysis – CRC Cards – Informal English Description – Structured Analysis
- 9. CLASSICAL APPROACHES • These derive from the principles of classical categorization. • Sources include (Shlaer, Mellor) – Tangible things Cars, telemetry data, pressure sensors – Roles Mother, teacher, politician – events, and Landing, interrupt, request – Interactions Loan, meeting, intersection • In database modeling perspective, Ross offers, a list like people, places, things, organizations, concepts or events • Other sources of potential objects (Coad, Yourdon) include structure, other outside agents, devices, records of events remembered , Roles played, locations, and organizational units. • Any classes identified in this way may be generalized by grouping them together.
- 10. BEHAVIOR ANALYSIS • It is more akin to conceptual clustering and consists of classifying objects according to common behavior • (Wirfs-Brock et al.,)The knowledge an object maintains and the actions an object can perform • Responsibilities convey the purpose of the object • Hierarchies of classes are formed involving super classes that represents general responsibilities, sub classes that specialize their behavior • Identify the system behaviors, understand the initiators and participants, recognize them as objects with behavioral responsibilities(Rubin & Goldberg) • (Rubin) system behavior is related to the idea of function points (Alberch)
- 11. DOMAIN ANALYSIS • The goal in domain analysis is to find classes and objects that are common to all systems dealing with problems in the same domain, then consider those which are specific to the problem at hand. – Eg. Patient record tracking, bond trading, etc., • It is helpful by pointing out the key abstractions that have been already proven • It is an attempt to identify objects, operations and relationships perceived by the domain experts • Domain analysis requires a domain expert who speaks the vocabulary of the problem domain (eg. doctor or nurse in patient record tracking) • One benefit of domain analysis is that it supports the possibility of generating more general classes which can be reused in a variety of specific problem instances • May be applied across similar applications (vertical and horizontal domain analysis) • Booch notes "It is truly amazing to see what a little bit of domain knowledge can do to assist a developer in making intelligent design decisions” • For highly complex systems, domain analysis is a formal process
- 12. USE CASE ANALYSIS • ‘first three methods are neither deterministic nor predictable successful’ where use case can be coupled to the earlier approaches • A use-case is a "particular form or pattern or exemplar of usage, a scenario that begins with some user of the system initiating some transaction or sequence of interrelated events. • Introduced by Jacobson and be applied in requirement analysis • In analysis, we may enumerate the use-cases that are fundamental to the operation of the system. • As development proceeds, the team walks through each scenario identifying the participant objects and their responsibilities, and the collaborations in which these objects participate (storyboarding technique) • Focused to craft separation of concerns among all abstractions • Secondary scenarios can be identified and existing abstractions can be reassigned
- 13. CRC CARDS (CLASS/RESPONSIBILITIES/COLLABORATO RS) • CRC cards provide a concrete product of analysis of scenarios, and other analyses, by recording each class's responsibilities and those classes with which it collaborates • useful development tool that facilitates brainstorming and enhances communication among developers • cards are arranged to show the flow of messages among prototypical instances of each class; • the cards are arranged to represent generalization/specialization or aggregation hierarchies among the classes.
- 14. INFORMAL ENGLISH DESCRIPTIONS• Meaningful approach to use informal natural language descriptions • Proposed by Abbott, who suggests writing an English description of the problem (or a part of a • problem) and then underlining the nouns and verbs • The nouns represent candidate objects, and the verbs represent candidate operations on them • it is simple and because it forces the developer to work in the vocabulary of the problem space. • This approach provides a good initial method of analysis and helps in the formation of a Data Dictionary.
- 15. STRUCTURED ANALYSIS •Structured analysis is a technique that has been used to develop programs using concepts of structured programming (CASE tools) •These diagrams provide a reasonably formal model of the problem to identify the meaningful classes and objects in three different ways 1. McMenamin and Palmer suggest starting with an analysis of the data dictionary and proceeding to analyze the model’s context diagram (The next two techniques involve analyzing individual data flow diagrams) 2. O-O elements can be retrieved from SA designs by scavenging the data dictionary for objects, and by analyzing the dataflow diagrams to identify –external entities –data stores –control stores –control transformations •Candidate classes derive from two sources: – Data flows – Control flows
- 16. CONTD.. 3. Seidewitz and Stark suggest another technique, which they call abstraction analysis • Abstraction analysis focuses on the identification of central entities which are similar in nature to central transforms in structured design • In structured analysis, input and output data are examined and followed inwards until they reach the highest level of abstraction. – The processes between the inputs and the outputs form the central transform • It is tremendously difficult to build an object-oriented system from a model that is so obviously biased toward algorithmic decomposition.