Filetype PDF | Posted on 02 Feb 2023 | 3 years ago
Authentication
digital resources
227x Filetype PDF File size 1.59 MB Source: journals.sru.ac.ir
http://jecei.srttu.edu
Journal of Electrical and Computer Engineering Innovations
SRTTU JECEI, Vol. 3, No. 2, 2015
Regular Paper
Objects Identification in Object-Oriented Software
Development - A Taxonomy and Survey on Techniques
Hassan Rashidi
Department of Statistics, Mathematics, and Computer Science, Allameh Tabataba’i University
Corresponding Author’s Information: hrashi@atu.ac.ir
ARTICLE INFO ABSTRACT
Analysis and design of object oriented is one modern paradigms for
ARTICLE HISTORY: developing a system. In this paradigm, there are several objects and each
Received 8 July 2015 object plays some specific roles. Identifying objects (and classes) is one of
Revised 23 December 2015 the most important steps in the object-oriented paradigm. This paper
Accepted 25 December 2015 makes a literature review over techniques to identify objects and then
presents six taxonomies for them. The first taxonomy is based on the
KEYWORDS: documents exist for a domain. The second taxonomy is based on reusable
Taxonomy previous knowledge and the third one relies on commonalities in a
Class domain. The fourth taxonomy is concerned with decomposing a domain.
Object The fifth taxonomy is based on experience view and sixth one is related to
Object-Oriented use the abstraction in a domain. In this paper, the constraints, strengths
Software Engineering and weaknesses of the techniques in each taxonomy are described. Then,
the techniques are evaluated in four systems inside an educational center
in a university. A couple of approach is recommended for finding objects,
based on some practical experiences obtained from the evaluation.
1. INTRODUCTION responsibility to classes and objects in object-oriented
Object-Oriented (OO) is one modern paradigm for design.
developing software. In this paradigm, we describe The first step for building an OO model is to find
our world using the object categories (classes) or out the objects, on which we focus. In this step, we are
object types (pure abstract class or Java interface) not really finding objects. In fact, we are actually
(see [18], [19], [23], [24], [31], [42], [43], [46]). Each finding categories and types (analysis concepts) that
class/object plays a specific role in the software. will be implemented using classes and pure abstract
These roles are programmed in Object-Oriented classes. The results of problem analysis is a model
languages such as C++ and Java. that: (a) organizes the data into objects and classes,
Several attributes (data variables) and services and gives a structure to the data via relationships of
(operations/functions/methods) are assigned to these inheritance, aggregation, and association; (b) specifies
classes. Then, we model the behavior of the world as a local functional behaviors and defines their external
sequence of messages that are sent between various interfaces; (c) captures control or global behavior; and
objects. In OO models, a number of relationships (d) captures constraints (limits and rules).
(inheritance, association, and aggregation- see [11], The main motivation of this paper is to have a
[14], [38], [45] and [46]) are identified between the survey on the techniques to find the potential objects
classes/objects. Moreover, there are many popular and makes six taxonomies for them. The remainder of
design modeling processes and guidelines such as this paper is as follows. In Section 2, the literature
GRASP [49] and ICONIX [48] for assigning review and taxonomies of techniques to find objects
are presented. In Section 3, the experiences of
J. Elec. Comput. Eng. Innov. 2015, Vol. 3, No. 2, pp. 99-114 99
Hassan Rashidi
applying the approaches to four systems are and supported by the system. Coad and Yourdon (
presented. In Section 4, two approaches to find objects [12], [47]) categorized the objects into different
in the object-oriented paradigm are recommended. groups: (a) Structure (“kind-Of” and “part-Of”
Finally, Section 5 is considered for summary and relationships); (b) Other systems (External Systems);
conclusion. (c) Devices; (d) Events (A historical event that must
be recorded); (e) Roles (the different roles that are
2. LITERATURE REVIEW AND TAXONOMIES applied to the users); (f) Locations; (g) Organizational
One of the major challenges in the Object-Oriented units (groups to which the user belongs).
development and transforming the legacy systems Schlaer and Mellor in [39] and [40] categorized
into Object-Oriented one is how to identify objects. To objects into five groups: (a) Tangibles (cars, telemetry,
do this, many methodologists have their own favorite sensors); (b) Roles (mother, teacher, and
techniques. Almost, all techniques have shortcomings; programmer); (c) Incidents (landing, interrupt,
i.e., they sometimes fail to identify all objects and collision); (d) Interactions (Loan, meeting, marriage);
sometimes identify false objects. Deursen and Kuipers (e) Specification (product specification, standards).
(1999) have used clustering and concept analysis to Ross [36] categories objects into six groups: (a)
identify objects in the legacy code [15]. Canfora et al. People (humans who carry out some function); (b)
(2001) have employed an eclectic approach to Places (areas set aside for people or things); (c)
decompose legacy systems into objects [10]. Things (physical object); (d) Organizations (collection
Few researches have focused on refactoring the of people, resources, facilities, and capability having a
systems and extract class in this area. Fokaefs et al. defined mission); (e) Concepts (principles or ideas not
(2012) have described a method and a tool, designed tangible, per se); (f) Events (things that happen-
to fulfill exactly the extract class refactoring [17]. It usually at a given date and time, or as steps in an
has three steps: (a) recognition of extract class ordered sequence. One major gap and research need
opportunities, (b) ranking the opportunities in terms is to have an overview and taxonomy on techniques to
of improvement to anticipate which ones should be identify objects in Object-Oriented software
considered in the system design, and (c) fully development. According to Merriam-Webster [29],
automated application of the refactoring selected by taxonomy is the study of the general principles of
the developer. The first step relies on a hierarchical scientific classification, and is especially the ordered
agglomerative clustering algorithm based on Jaccard classification of items according to their presumed
distance between class members, which identifies natural relationships. The major difference between
cohesive sets of class members within the system techniques to find out objects, in general, depends on
classes. The second step, measures the design quality the circumstances around existing some documents in
by the entity placement metric. Through a set of a domain, how previous knowledge are reused, how
experiments, implemented as an Eclipse plug-in, the the commonalities are factored out, how the
research has shown that the tool is able to identify composition of a domain is performed, how the
and extract new classes that developers recognize as experience of developers aids, what level of
“coherent concepts” and can improve the design abstraction is used, and how we use individual
quality of the underlying system. objects. There are, therefore, six taxonomies to
Bavota et al. (2014) have proposed an approach for categorize techniques that find out objects in Object-
automating the extract class refactoring [1]. This Oriented development. They are described in the
approach analyzes structural and semantic following with their advantages and disadvantages.
relationships between the methods in each class to A. The first taxonomy: Document view
identify chains of strongly related methods. The for identifying objects is concerned with existing
identified method chains are used to define new document such as the requirement analysis report or
classes with higher cohesion than the original class, it the data flow diagram in a domain. Therefore, there
can also preserve the overall coupling between the are a couple of paradigms for this taxonomy such as,
new classes and the classes interacting with the using nouns and using data flow-diagram:
original one. In the literature, there are several Use Nouns (UN):
reported works in which the objects, in the object-
oriented software, are classified. Jacobson et al. in [21] This technique is traditional and starts with the
and [22] categorized the objects into Entity, document written for a problem. It was invented by
Boundary, and Control. The Entity objects represent Russell J. Abbott and popularized by Grady Booch ( [4],
the persistent information tracked by the system. The [5], [6]) and cited in many publications (e.g. [26], [32],
Boundary Objects represent the interactions between [33] , [41], [44]). To use this technique, the nouns,
the actors and the system. The Control objects pronouns and noun predicated in the written
represent the tasks that are performed by the user documents are used to identify objects. This technique
100
Objects Identification in Object-Oriented Software Development - A Taxonomy and Survey on Techniques
has many advantages: (i) Narrative language (English, redundantly and independently identified.
Chinese, French, German, Japanese, etc.) are well Transforms are not required to be a service of an
understood by everyone in a project staff; (ii) there is object. Therefore, transforms are often compound
usually one-to-one mapping from nouns to objects or operations that need to be assigned to multiple
classes; (iii) Using nouns requires no learning curve; objects. If the objects are not properly identified, this
the technique is straightforward and well defined, and leads to fragmented objects and classes.
does not require a complete paradigm shift to the OO B. The Second Taxonomy: Knowledge View
paradigm for the beginner; (iv) This technique does The second taxonomy is based on reusing previous
not require a prior Object-Oriented Domain Analysis knowledge from which objects are explicitly
(OODA); the analyst can apply it to an existing extracted. The previous knowledge can be collected
requirement specification [37], written for structural already in the Object-Oriented domain analysis,
analysis and / or any other methodology. On the framework, repository and individual objects(classes).
contrary of the advantages, this technique has some There are four techniques in this taxonomy:
shortcomings, in general. For one thing, this is an
indirect approach to find objects and classes. Nouns Use OO Domain Analysis (UOODA):
are not always classes or objects in problem domain. This technique is specified in [26] , [33] , [34] and
In many cases, the nouns, especially subjects of [35]. This technique assumes that an OO Domain
sentences, refer to: (a) an entire assembly or a Analysis has already been performed in the same
computer software configuration; (b) a subassembly problem domain. This technique supports the reuse
or a software component; (c) an attribute; (d) a and tends to maximize the cohesion in classes and
service. minimize the message and inheritance coupling. If one
Use Data Flow Diagrams (UDFD): assumes that the previous OODA is solid, indeed this
This technique was first published by Seidewitz technique offers a "reality check" on present work
and Stark of NASA's Goddard Space Flight Center [26]. because the objects and classes should be the similar
It assumes that a Data Flow Diagram (DFD) in the to the ones in the OODA. Thus, considerable time and
domain exists. The major benefit of this technique is effort can be saved if the original OODA is relevant
that it requires no paradigm shift by the analysts and and complete. On the contrary, finding adequate and
developers. If the original DFDs are well constructed, relevant OODA is not easy today. Most systems have
false-positive identification of objects and classes are either incomplete OODA or no OODA model at all. To
rare. Additionally, there are a lot of projects that make the reuse more effective, the problem domain
already have the context diagrams and DFDs. must be well documented and understood by the
Unfortunately, the shortcoming of UDFD is also developers. Tailoring for performance and other
directly related to not making the paradigm shift. business constraints in a specific project may decrease
Nearly all of the DFDs were originally written for the reuse. Although it is easier to reuse than to
functional decomposition, and they have a tendency to reinvent, the Not-Invented-Here (NIH) syndrome of
create a top-heavy architecture of classes. With many developers must be successfully overcome.
functional decomposition, there is a tendency to Reuse an Application Framework (RAF):
assume that the stem is an assembly of subassemblies This technique is specified in [20], [26] and [35].
at the appropriate level. Developers tend to assign Gurp et al. (2001) defined it as a partial design and
services at the corresponding level where the implementation for an application in a given
subassembly was found. This may cause objects to be domain [20]. This approach assumes that at least one
identified in the wrong subassembly. Although false- OODA has been already performed to create an
positive identification of objects and classes is rare, application framework of reusable classes. RAF has
not all of the objects or classes are identified. The some limitations. Developers must be able to identify
rareness of false-positive identification is totally one or more relevant application frameworks that
dependent on the quality of the original DFDs. This is have been previously developed and stored in a
still an indirect method of finding objects and classes; repository. Most likely, not all of the needed classes
it is based on data abstraction and not on object will be in the application framework(s) examined. One
abstraction. In many instances, an object or class concern with application frameworks is the NIH
contains more than one data store. Thus, their syndrome. This syndrome is translated into a general
attributes may be mapped to objects and classes while belief that if the application framework was not
their associated objects and classes remain developed locally, then it cannot take into account all
unidentified. Because the DFDs represent functional of the concerns of the local team. This concern is not
decomposition, pieces of an object may be scattered totally unfounded. In particular, application
across several DFDs assigned to different persons. frameworks often contain both analysis and design
Thus, different variants of the same object may be
J. Elec. Comput. Eng. Innov. 2015, Vol. 3, No. 2, pp. 99-114 101
Hassan Rashidi
classes. Unfortunately, it is not easy to distinguish subclasses. When using subclasses, we skip finding
between these two types. objects and directly start identifying classes. The key
Reuse Class Hierarchies (RCH): benefit of this technique is reuse. In contrast, when
This technique is specified in [26] , [33] and [35]. misused, it leads to difficult maintainability and
This technique assumes that a reuse repository with opaque classes that reuse randomly unrelated
relevant reusable class hierarchies has been resources that do not logically belong to subclasses of
developed. This technique has the same advantages as the same superclass. Additionally, USC also may
using OODA. The major advantage of this technique is produce inappropriate or excessive inheritance
that it maximizes the use of inheritance and is a coupling.
natural fit for some OO languages. In contrast, it has D. The Fourth Taxonomy: Decomposition View
additional limitations beyond those for OODA as with The fourth taxonomy for identifying objects is
all techniques. Additionally, the existing classification based on decomposition view; i.e., how we decompose
hierarchies may not be relevant to the current a domain and its objects. In this view, we have a
application. Existing classes may need to be couple of techniques, which are specified in the
parameterized, or new subclasses may need to be following:
derived. Use Subassemblies Method (USM):
Reuse Individual Objects and Classes (RUIOC): This technique is specified in [26] , [33] and [35]. It
This technique is specified in [26] , [33] and [35]. assumes that the developers are incrementally
We can reuse specific objects and classes from the developing subassemblies using a recursive
repository with relevant reusable objects and classes. development process. The major advantage of this
The major advantage of this technique is that it is technique is that it supports incremental
inexpensive and easy to use so that little efforts is identification of objects/ classes. It also identifies all
invested in making the classes, and they can be easily the subassemblies in an application domain. It is very
discarded. Also, this method stimulates similar to functional decomposition ( [32], [33]), so
communication and is not intimidating to beginners. there is less culture shock for developers trained in
On the contrary, this technique has some very serious the structured methodology. On the contrary, there
shortcomings. One major concern with the repository are some limitations for implementation of this
is NIH syndrome. This syndrome is translated into a technique. It identifies only assembled objects. Thus,
general belief that if the repository is not developed one must have some other techniques to identify
locally, then it cannot take into account all of the fundamental components of the subassemblies.
concerns of the local team. Use Object Decomposition (UOD):
C. The Third Taxonomy: Commonalities View This technique is specified in [26] and [35]. This
The third taxonomy for identifying objects is based technique assumes that most objects are composed of
on finding communalities and factoring out on them. the other objects. The key benefit of this technique is
In this view, we have a couple of techniques, which reuse, but it has some serious drawbacks. When
are specified in the following: misused, it leads to un-maintainable and opaque
Use Generalization (UG): classes that reuse randomly unrelated resources that
This technique is specified in [26] and [33]. It do not logically belong to subclasses of the same
assumes that objects are identified prior to their superclass. It also may produce inappropriate or
classes (every object is an instance of some class), and excessive inheritance coupling.
that communalities among objects can be used to E. The Fifth Taxonomy: Experience View
generalize classes. The first advantage of this The fifth taxonomy for identifying objects is based
approach is that it promotes reuse and supports the on how we use personal experience in different
development of one or more classification hierarchies. human activity. In this view, we have a couple of
In contrast, UG requires significant training, practice, techniques, which are specified in the following:
intuition, and experience. Use Personal Experience (UPE):
Use SubClasses (USC): UPE technique is presented in [26] and [35]. This
This technique is specified in [26] and [35]. The technique assumes that the developer has already
steps are: (a) Identifying classes that share common performed an analysis and can use its experience.
resources (i.e., attributes, service name, methods, Based on one's experience, this technique provides a
etc.); (b) Factoring out the common resources to form reasonable "reality check" on projects. Thus, the
a super-class (parent), and then use inheritance for all quality of the classes and objects may be substantially
classes that share these resources to form simpler improved, as they are based on classes and objects
102
no reviews yet
Please Login to review.
