Comparative study on various approaches of identifying classes in ...

<strong>Comparative</strong> <strong>study</strong> on various approaches of identifying classesin object oriented design.Faridah Hani Mohd.Salleh 1 , Hidayah Sulaiman 2 , Zarinah Kasirun 31 Department of Computer Science2Department of Informatics3 Department of Software Engineering, Universiti Malaya1, 2 College of Information Technology, Universiti Tenaga NasionalKM7 Jalan Kajang-Puchong43009 Kajang, Selangor, MalaysiaFaridahh@uniten.edu.my , Hidayah@uniten.edu.my , zarin@fsktm.um.edu.myABSTRACTIn object-oriented software design, classes are templates for defining the characteristics and operationsof an object. Classes and objects are frequently used interchangeably as one is similar to the other.Ideally, a class is a specification that an object implements. Identifying classes can be very challenging.Should a class be badly identified, it can complicate the application’s logical structure, reducereusability, and deter the application’s maintenance. This paper discusses five existing approaches inidentifying classes and discussions will be based on how these approaches identify the class, thestrengths and weaknesses of these methods and how improvements are suggested to the weaknesses. Atthe end of this paper, brief summarization to the related techniques of identifying classes of existingapproaches is presented.1. INTRODUCTIONObject-oriented systems analysis and design using UML has become increasingly popular, but veryfew tools exist to assist developers in identifying and creating the right diagram. Among the diagramsthat will be created are use case diagram, class diagram, sequence diagram, collaboration diagram anddeployment diagram. However, in this paper we shall discuss the approaches in identifying classestogether with its benefits and weaknesses with the primary goal of assisting developers in creating classdiagram. Designing diagram that is useful for system design is not an easy task. Thus, it is desirable tolearn some existing techniques in identifying the class itself, which can help to generate class diagram.2. APPROACHES TO IDENTIFYING CLASSESThe section below shall further discuss and elaborate on the existing approaches as well as how eachof the approach works. There are currently 5 existing approaches, and each has their significantweaknesses and benefits for identifying class.2.1 Noun-phrase approachNoun-phrase Approach uses the technique of searching any documentation or requirementspecifications for nouns that represent potential objects. This approach was proposed by Wirfs-Brock etal. (1992). Workflow of Noun-phrase Approach begins with set of documents or requirementsspecification that formally specifies the system-level requirements of a single application. Developerreads through the requirements to find for noun or noun phrases. Whatever nouns appear in therequirements will be considered as a candidate and verbs as method of the classes. Then, the list ofclasses will be classified into these three categories; Relevant Classes, Fuzzy Classes and IrrelevantClasses (as shown in Figure 2.1(a)). Fuzzy Classes categorized classes that are vague. Classes that fallunder Irrelevant Classes will automatically be eliminated from the list of classes. Classes are selectedfrom the other two categories only. However, this is an iterative and flexible process, which developer

can always add or remove the class where necessary. Some of the classes may also be found fromgeneral knowledge about domain of the system.Relevant ClassesFuzzy ClassesIrrelevant ClassesFigure 2.1(a): Categories in Noun-phrase Approach. (Bahrami(1999))The workflows do not end until the correct classes are identified. Bahrami(1999) presentsguidelines that help in selecting candidate classes from relevant and fuzzy categories of classes. Classesfrom the two categories have to be assured not fall into any of the type of classes below:1. Redundant ClassesIf two or more classes use different words but describe a same idea, they are considered as redundantclass. If this happened, the class that best describe the meaning of the class will be chosen.2. Adjective ClassesThis type of classes may suggest a different kind of object, different use of the same object, or it couldbe utterly irrelevant. For example, Funny Genre behaves differently than Horror Genre, so thetwo should be classified as different classes.3. Attribute ClassesValues should be treated as attributes of class not a class itself. For example, Member Address is nota class but an attribute of class Member.4. Irrelevant ClassesTypically, this type of class has no purposes. Developer will find it difficult to generate statement ofpurpose for Irrelevant Classes.Figure 2.1(b) shows process of eliminating the redundant classes and refining the remaining classes.As what can be seen here, this process is not sequential. It is an incremental process and analyst canmove back and forth among these steps as often as they like.Reviewredundant classesReviewirrelevant classesReviewadjectivesReviewattributesFigure 2.1(b): Process of eliminating the redundant classes and refining the remaining classes(Bahrami(1999))2.2 Use Case Driven approachBahrami(1999) discuss four approaches in identifying class in his book, title: Object-OrientedSystems Development: Using the Unified Modeling Language. However, amongst the four approaches,Use Case Driven is the one that is recommended. Jacobson (1992) first introduced this approach, whichfirst breaks down the entire scope of system functionality into a number of use cases. According toBahrami(1999), this approach works in such a way that use case is further analyzed with a sequence andcollaboration diagram pair. However, as what pointed out by Bente & Sjoberg(2003), several researches

opinion seems to be converging toward the viewpoint that use case is a primary artifact in theidentification of system classes. Use case driven process has been criticized for not providing asufficient basis for the construction of class diagrams.The sequence or collaboration diagram is a systematic way to think about how use case(scenario) can take place. With these two diagrams, it is indirectly forcing the analyst to think aboutclass or object involved in the scenario. It is recommended to generate sequence diagram for every usecases. Classes that appear in sequence diagram are considered as classes in class diagram. On the otherhand, messages passed across the classes are considered as method. Figure 2.2 shows the steps of a usecase driven approach.RequirementsClasses,attributes,associationsUse case modelScenariosClassesDomain modelClasses,attributes,associationsSequence diagramsMethods,associationsClass diagramFigure 2.2: The use case driven approach (Bente & Sjoberg(2003))2.3 CRCBeck & Cunningham (1989) first introduced CRC-Cards in 1989 at the annual OOPSLAconference. CRC stands for Class, Responsibilities, and Collaborator, which characterize objects byclass name, responsibilities, and collaborators, as a way of giving learners a direct experience of objects.Although Bahrami (1999) states that CRC is more suitable for learning purpose, other reportedcase <strong>study</strong> have demonstrated the effectiveness of CRC Card beyond simply learning.CRC session is conducted by having all the information of class such as responsibilities andcollaborators written on a 4” x 6” index card. Cards are used because of its portability, readilyavailability, and familiarity. The class name is written underlined in the upper-left hand corner. List ofresponsibilities are written in bullet format under class name in the left two-thirds of the card. List ofcollaborators are written in the right third of the card. Figure 2.5(a) depicts the idealized CRC card andFigure 2.5(b) depicts example of implementation of CRC card in banking machine problem, aspresented by Beck & Cunningham (1989)..Figure 2.5(a): A CRC Index Card

Figure 2.5 (b): A CRC Index Card (Beck & Cunningham (1989)).CRC card session is always performed in group. The group members are encouraged to pick upthe card whose role they are assuming while “executing” a scenario. Classes are extracted from the usecase descriptions by performing a grammatical parse. List of classes is made up of the nouns in theproblem statement. Bahrami(1999) writes:Start with few cards (classes) then proceed to play “what if”. If the situation class forresponsibility not already covered by one of the objects, either add the responsibility to anobject or create a new object to address the responsibility. If one of the objects becomes toocluttered during this process, copy the information on its card to a new card, searching formore concise ways of saying what the object does. If it is not possible to shrink the informationfurther and the object is still to complex, create a new object to assume some of theresponsibilities.Identify classes andresponsibilityIterateIdentifycollaborationAssignresponsibilityFigure 2.5(c): The Classes, Responsibilities, and Collaborators process (Bahrami(1999)).2.4 Common-Class PatternAccording to Bahrami(1999), Common-Class Pattern approach is based on the knowledge baseof the common classes proposed by various researchers, such as Shlaer and Mellor, Ross, and Coad andYourdon. These researchers compiled and listed several categories for finding the candidate classes andobjects. Candidate classes and objects come from one of the following sources, as presented byBahrami(1999):• Concept class - e.g: reservation• Events class - e.g: arrival

• Organization class - e.g: Department• People class - e.g: passenger• Places class - e.g: travel office• Tangible things and devices class - e.g: sensorUsing this approach, analyst should think about classes that fall into entire sources as presentedabove. For example, Food Service Management System: restaurant and food stores arepossible classes categorize under Places class. The process not yet finishes till all the six classes areconsidered.2.6 KRB Seven-Step MethodMost of existed approaches do not discuss about how to generate complete class diagram, whichinclude association and multiplicity. One approach named KRB Seven-Step Method is found to providea way to generate complete class diagram. Brown (2002) introduces this approach with assistance fromAnil Kapur and Ravi Ravindra. The KRB Seven-Step Method provides more complete and detail stepscompared to other approaches. The seven steps are presented below:Step 1: Candidate classesClasses are discovered from interface, entity, and control classes that are significant to the system.There are four ways to generate a list of nouns for candidate entity classes; client interview,requirements model and other documentation, brainstorming and Delphi method.Step 2: Define classesOnce the classes have been identified, some checking has to be done to see if the class is reallyimportant to the domain of the system. Each candidate class is subjected to three checks: Real-worldidentifier, Definition, Sample attributes and Behaviors.Step 3: Establish associationsThis step is concerned with the question: “What does one of these do to one of those?” In findingand handling the answer to this question, below factors are considered:• Discovering the verb• Establishing the multiplicity• Capturing all possible interactions• Attitude of the usersStep 4: Expand many-to-many associationsBrown (2002) realizes that an M:M association has nowhere to place event data attributes. As such,a new intersection class must be created to carry them. Every M:M association is break out into pair of1:M associations, with the many ends pointing at this new intersection class.Step 5: AttributesUsers are required to go through each of the classes in the model and find any thinkable attributes.Step 6: NormalizationThe principle of normalization in this context is to make sure that every data element (attribute) isattached to the class of objects that it truly describes. Normalization is performed till the third level ofnormalization (1NF, 2NF and 3NF).Step 7: OperationsMethods used to identify operations are object states and statechart diagram, Rebecca Wirfs-Brock’smethods that used responsibilities and collaborations and sequence diagram.

3. BENEFITS AND WEAKNESSESApproach Benefit Weakness Improvements byRelated researchNoun-phrase • Uses requirementspecification,which indirectlyencourage analystto use what theyalready havewithout a need togenerate newthings to identifyclass for classdiagram.Use-Case Driven • Helps in dealingwith complexity ofsystem. (Regnell etal.(1995))• Simple. (Regnell etal.(1995))• Usage to validatedesign model.(Shull et al.(1999))CRC • Portable• Tangible• Difficulty involvedwith having to dealwith a large numberof nouns indocumentation orrequirementspecifications.(Poo(1999))• Assumes developer tohave a well specifiedrequirements orproblem specificationdocument beforebeing able to identifynouns from them.• A largely manualprocess driven byheuristics thatanalysts acquirethrough experience.(Overmyer etal.(2001))• Analyst with limitedexperience may findthis processcumbersome.• Not providing asufficient basis for theconstruction of classdiagrams.• A gap between theuse case model andthe class diagram.• Missing classesbecause the use casemodel is insufficientfor deriving allnecessary classes.• Mistakingrequirements fordesign• Lack of synthesis• Dependency• Unable to generatetest casesautomatically(Regnell et al.(1995))• Possibility of LowCohesion and High• Overmyer etal.(2001) proposesLIDA (LinguisticAssistant forDomain Analysis),which providelinguisticassistance in themodeldevelopmentprocess.• The greatestimprovement thatLIDA does toNoun-phraseapproach ismaking transitionfrom textualdescriptions toother notations forobject-orientedanalysis bychanging theprocess frommanual toautomated.• Poo(1999)proposes theextension of theUse CaseModelingapproach, aprocess known asEvent Scripting.• Usage OrientedRequirementsEngineering(UORE), as anextension of UseCase DrivenAnalysis. (Regnellet al.(1995))• Liu et al.(2001)proposes a formalmethod, which isable to buildmodels forrequirementanalysis.• Fayad et al.(2003)proposes new CRC

• Reviewable• Simple• Multi-Purpose• Accessible• Traceable• Mapping Ability• Reusable(Fayad et al.(2004))Common-Class Pattern • Suitable for nontechnicaland semitechnicalusers dueto inclusion ofsome of thefamiliar classesKRB Seven-Step • More rigorous, indepth,simplewithout too muchmath.• Covers all aspectsof class diagramincludingnormalizationCoupling• Object performs mostof the work, leavingall the minoroperations to a set ofessentially uselessclasses• Difficulty in DefiningResponsibilities• Difficulty in Mapping• Difficulty inIdentifying Classes• Difficulty in Mapping• More suitable to beused when analystswork in group(Fayad et al. (2003))• Concepts of some ofthe classes aremisinterpreted• Fully manual process• For a very large andcomplex system, itmay take some timeto think of all possibleclasses that may beinvolved.• No guided steps inidentifying attributes.card format.Limitedresponsibilitieswill help preventlow cohesion andhigh coupling aswell as reduce thepossibility ofmacho classes(multipleresponsibilities areassigned to certainclass).4. CONCLUSIONFor the existing approaches discussed above, skill of defining class depends on the experienceand overall knowledge of analyst and developers. Use Case Driven Approach, Common ClassPattern and Noun Phrase Approach are the three approaches that apparently require these skills.Other than that, use case diagram, sequence diagram, requirements document, brainstormingsessions and cards are some of the development work-product used by the other two approaches.One general weakness of the existing approaches found is lack of explanations on when to applythese methods. In addition, these current approaches not always attain the essential aspects neededby many in future, where everybody wants something simple and time-saving in constructingclasses. However, one good aspect from all the existing approaches is that the usage of use casediagram is remained as it is because it could be used to guide and verify the generated class diagramand make more refined design judgments.

REFERENCESBahrami, A. (1999). Object Oriented Systems Development: Using the Unified Modeling Language.Singapore: McGraw-Hill.Brown, D.W. (2002). An Introduction to Object-Oriented Analysis: Objects and UML in Plain English,2 nd Edition. US: John Wiley & Sons, Inc.Jacobson, I. (1992). Object-oriented Software Engineering—A Use Case Driven Approach, Addison-Wesley.Wirfs-Brock, Rebecca; Wilkerson, Brian; Wiener, Lauren. (1992). Designing Object-Oriented Software.Englewood Cliffs, NJ: Prentice Hall.Beck, K.; Cunningham, W.(1989) A Laboratory For Teaching Object-Oriented Thinking. In:Conference proceedings on Object-oriented programming systems, languages and applications, Volume24 Issue 10, September 1989, ACM Press.pp.1-6Fayad, M.E.; Hamza, H.; Sanchez, H. (2003) A pattern for an effective class responsibility collaborator(CRC) cards. In: IEEE International Conference on Information Reuse and Integration, Oct. 2003, IEEEComput.Assoc.Press.pp.584 - 587Poo, D.C.C (1999) Events in Use Cases as a Basis for Identifying and Specifying Classes and BusinessRules. In: Proceedings of Technology of Object-Oriented Languages and Systems, June 1999, IEEEComput.Assoc.Press.pp.204 - 213Fayad, M.E.; Hamza, H.; Sanchez, H.(2004) A Pattern Language For Crc Cards. In: The 11th ConferenceOn Pattern Languages Of Programs (Plop2004), Sept. 2004Regnell, B.; Kimbler, K.; Wesslen, A.(1995) Improving The Use Case Driven Approach ToRequirements Engineering. In: Proceedings of the Second IEEE International Symposium onRequirements Engineering, March 1995, IEEE Comput.Assoc.Press.pp.40 – 47Anda, B.; Sjoberg, D.I.K.(2003) Applying Use Cases to Design Versus Validate Class Diagrams - aControlled Experiment Using a Professional Modeling Tool. In: Proceeding of International SymposiumEmpirical Software Engineering, 30 Sept.-1 Oct, IEEE Comput.Assoc.Press.pp.50 – 60Shull, F; Travassos, G.H.; Carver, J.; Basili, V.R Evolving a Set of Techniques for OO Inspections.University of Maryland Technical Report CS-TR-4070, October 1999Z. Liu; J. He; X. Li.(2001) Formal and Use-Case Driven Requirement Analysis in UML. In: ComputerSoftware and Applications Conference -COMPSAC , 8-12 Oct. 2001, IEEEComput.Assoc.Press.pp.215 - 224Overmyer, S.P.; Benoit, L.; Owen, R.(2001) Conceptual modeling through linguistic analysis usingLIDA. In: Proceedings of the 23rd International Conference on Software Engineering (ICSE), 12-19May, IEEE Comput.Assoc.Press.pp.401 – 410Software Quality and Coupling and Cohesion, Access Date: 25 March 2005 Kellen,V. 12 December1993, http://www.kellen.net/Coupling%20and%20Cohesion.htm