Neo4j - How KGs are shaping the future of Generative AI at AWS Summit London ...
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.