Chapter 11 Object-oriented Analysis and Modeling Using the UML Define object modeling and explain its benefits.

. Recognize and understand the basic concepts and constructs of object modeling. Define the UML and its various types of diagrams. Evolve a business re uirements use!case model into a system analysis use!case model. "onstruct an activity diagram. Discover objects and classes# and their relationships. "onstruct a class diagram. Introduction to Object Modeling Object-oriented analysis (OOA) $ an approach used to study existing objects to see if they can be reused or adapted for ne% uses define ne% or modified objects that %ill be combined %ith existing objects into a useful business computing application Object modeling $ a techni ue for identifying objects %ithin the systems environment and the relationships bet%een those objects. eaching !otes & 'he object modeling techni ue prescribes the use of methodologies and diagramming notations that are completely different from the ones used for data modeling and process modeling. & (n the late )*+,s and early )**,s many different object!oriented methods %ere being used throughout the industry. 'he most notable of these %ere -rady .ooch/s Booch Method, 0ames Rumbaugh/s Object Modeling Technique (OMT), and (var 0acobson/s Object-Oriented Software Engineering (OOSE). Introduction to the UML Uni"ied Modeling Language 1UML2 $ a set of modeling conventions that is used to specify or describe a soft%are system in terms of objects. $ 'he UML does not prescribe a method for developing systems3only a notation that is no% %idely accepted as a standard for object modeling. eaching !otes & (n )**4 -rady .ooch and 0ames Rumbaugh joined forces to merge their respective object!oriented development methods %ith the goal of creating a single# standard process for developing object!oriented systems. & (var 0acobson joined them in )**5 and the three altered their focus to create a standard object modeling language instead of a standard object!oriented approach or method. & Referencing their o%n %or6 as %ell as countless others in the 77 industry# the Unified Modeling Language 1UML2 version )., %as released in )**8. UML version 9., is expected to be released in late 9,,,. & :t the time of this %riting# .ooch# Rumbaugh# and 0acobson have developed and mar6eted an object modeling methodology called the Unified Method or 7bjectory. Objects# Attributes# $ Instances Object $ something that is or is capable of being seen# touched# or other%ise sensed# and about %hich users store data and associate behavior. ;erson# place# thing# or event Employee# customer# instructor# student <arehouse# office# building# room

;roduct# vehicle# computer# videotape Attribute $ the data that represent characteristics of interest about an object. Object instance $ each specific person# place# thing# or event# as %ell as the values for the attributes of that object. eaching !otes & 'here are several concepts that object!oriented analysis is based on. =ome of these concepts re uire a totally ne% %ay of thin6ing about systems and the development process. 'hese concepts have presented a formidable challenge to veteran developers %ho must relearn ho% they have traditionally vie%ed systems. & 7bject!oriented approaches to systems development are concerned %ith identifying attributes that are of interest regarding an object. (t is important to note that %ith advances in technology# attributes have evolved to include more than simple data characteristics. 'oday# objects may include ne%er attribute types# such as a bitmap or a picture sound# or even video. & >ave students provide examples of objects# instances of objects# and their attributes that exist in the classroom. ?or instance# pen is an object# the pen ( use is an instance of that object# color of in6 is an attribute.

Objects# Attributes# $ Instances (cont%) eaching !otes & 'his figure depicts the symbol for representing an object instance using the UML modeling notation. :n object is represented using a rectangle. 'he name of the object instance and its classification are underlined and appear at the top of the symbol. 'he attribute values for the object instance are optionally recorded %ithin the symbol and are separated from the object name %ith a line. & 'he name of an object instance is the value of the attribute that uni uely identifies it. 'he attribute customer number# %hose value is 4)99,*# uni uely identifies that instance of customer. 'hus# 4)99,* is the name of the object instance and customer is its classification. &eha'ior $ (ncapsulation &eha'ior $ the set of things that the object can do that correspond to functions that act on the object/s data 1or attributes2. (n object!oriented circles# an object/s behavior is commonly referred to as a method# operation# or er!ice. (ncapsulation $ the pac6aging of several items together into one unit. eaching !otes & (n encapsulation# both attributes and behavior of the object are pac6aged together. 'he only %ay to access an object@s attributes is through that object/s behaviors. Ao other object may perform that object/s behavior. & >ave students identify the behaviors of a door# %indo%# or B"R. Object Classes Class $ a set of objects that share common attributes and behavior. =ometimes referred to as an object cla . eaching !otes & (n UML an object class is represented using a rectangle symbol. & 'he object rectangle is divided into three portions. & 'he top portion contains the name of the class. & 'he middle portion contains the names of the attributes. & 'he lo%er portion contains the behaviors 1or methods2.

&

'o simplify the appearance of a diagram# or to specify more details about a class# class symbols can be dra%n %ithout methods or attributes# or the attribute portion can be expanded to include data types# lengths# etc. 'he appearance depends on %hat the author of the diagram is intending to communicate.

Inheritance Inheritance $ the concept %herein methods andCor attributes defined in an object class can be inherited or reused by another object class. eaching !otes & (nheritance is a critical concept of 77. (n fact for a programming language or D.M= to be considered 77# it must support inheritance. (n inheritance# the child class inherits the attributes and methods from its parent class1s2. Inheritance (cont%) eaching !otes & 'he terms -eneralization and =pecialization %ill be defined on the next slide. & <al6 the students through this diagram. & 'he ;erson object has an attribute last name. 'herefore the =tudent and 'eacher objects that are based on ;erson also have an attribute last name as %ell as their o%n attributes 1-;: or ran62. & 'he ;erson object has a method %al6. 'herefore =tudent and 'each also have a method %al6 as %ell as their o%n methods 1enroll or lecture2. )enerali*ation+,peciali*ation# ,upertype# and ,ubtype )enerali*ation+speciali*ation $ a techni ue %herein the attributes and behaviors that are common to several types of object classes are grouped 1or abstracted2 into their o%n class# called a upert"pe. 'he attributes and methods of the supertype object class are then inherited by those object classes. ,upertype $ an entity that contains attributes and behaviors that are common to one or more class subtypes. :lso referred to as ab tract or parent class. ,ubtype $ an object class that inherits attributes and behaviors from a supertype class and then may contain other attributes and behaviors that are uni ue to it. :lso referred to as a child class and# if it exists at the lo%est level of the inheritance hierarchy# as concrete class. eaching !otes & 'he previous slide illustrates these terms. & 'he class supertype %ill have one or more one-to-one relationships to object class ubt"pe . 'hese relationships are sometimes called D(= :E relationships 1or D<:= :E or D"7ULD .E :E2 because each instance of the supertype Dis also anE instance of one or more subtypes. UML -epresentation o" )enerali*ation+,peciali*ation eaching !otes & >ave students identify %hat attributes and methods are inherited by the ='UDEA' and 'E:">ER classes. Object+Class -elationships Object+class relationship $ a natural business association that exists bet%een one or more objects and classes. eaching !otes

& &

&

7bjects and classes do not exist in isolation. 'he things they represent interact %ith and impact one another to support the business mission. :n objectCclass relationship is graphically illustrated in UML as a connecting line bet%een t%o classes. 'his relationship is commonly referred to as an association. 'he line is labeled %ith a verb phrase that describes the association. :ll associations are implicitly bidirectional# meaning that they can interpreted in both directions. 'he figure above sho%s the complexity or degree of each association. ?or example# in the above business assertions# %e must also ans%er the follo%ing uestionsF
& & & & Must there exist an instance of "U='7MER for each instance of 7RDERG HesI Must there exist an instance of 7RDER for each instance of "U='7MERG AoI >o% many instances of 7RDER can exist for each instance of "U='7MERG ManyI >o% many instances of "U='7MER can exist for each instance of 7RDERG 7neI

Multiplicity and UML Multiplicity !otations Multiplicity $ the minimum and maximum number of occurrences of one objectCclass for a single occurrence of the related objectCclass. eaching !otes & .ecause all associations are implicitly bidirectional# multiplicity must be defined in both directions for every association. Aggregation Aggregation $ a relationship in %hich one larger D%holeE class contains one or more smaller DpartsE classes. "onversely# a smaller DpartE class is part of a D%holeE larger class. eaching !otes & :ggregation relationships do not support inheritance. 'heir benefit lies in the ability to send a message to the parent class and that message is automatically applied to all the child classes. & >ave students provide other examples of objects %here aggregation relationships are appropriate 1car $ or any bill of material# church# order!line item# etc.2. Composition Composition $ an aggregation relationship in %hich the D%holeE is responsible for the creation and destruction of its Dparts.E (f the D%holeE %ere to die# the DpartE %ould die %ith it. eaching !otes & :ll composition relationships are aggregation relationships. .ut not all aggregation relationships are composition relationships. & "ompare ?igure ))!Ja and ))!Jb and note the different UML notations. & "ompare ?igure ))!Ja and ))!Jb and as6 students %hy composition is appropriate for the .oo6 and "hapter classes but not for the 'eam class. Messages Message $ communication that occurs %hen one object invo6es another object/s method 1behavior2 to re uest information or some action eaching !otes & 'he object sending a message does not need to 6no% ho% the receiving object is organized internally or ho% the behavior is to be accomplished# only that it responds to the re uest in a %ell!defined %ay. & : message can be sent only bet%een t%o objects that have an association bet%een them.

.olymorphism .olymorphism $ literally meaning Dmany forms#E the concept that different objects can respond to the same message in different %ays. O'erride $ a techni ue %hereby a subclass 1subtype2 uses an attribute or behavior of its o%n instead of an attribute or behavior inherited from the class 1supertype2. eaching !otes & ;olymorphism supports reusability in that the same message can be sent to different objects and be interpreted different %ays. ?or example# let/s say %e have a method called D"ompute ;ayE and t%o objects named ?ULL!'(ME EM;L7HEE and ;:R'! '(ME EM;L7HEE. 'he same Dcompute payE message can be sent to both objects but ho% each object reactsCresponds to the message is different. : full!time employee/s pay may be composed of a %ee6ly salary 1minus deductions2 %hereas a part!time employee only gets paid for the hours %or6ed 1minus deductions2. & <hen the ;:R'!'(ME EM;L7HEE object receives a message to Dcompute pay#E it %ill override the behavior of the EM;L7HEE supertype and use its o%n behavior. .ut because of polymorphism# the object sending the message never 6no%s the difference. UML /iagrams & Use-Case Model /iagrams & ,tatic ,tructure /iagrams "lass diagrams 7bject diagrams & Interaction /iagrams =e uence diagrams "ollaboration diagrams & ,tate /iagrams =tatechart diagrams :ctivity diagrams & Implementation /iagrams "omponent diagrams Deployment diagrams eaching !otes & Use-case diagrams %ere introduced in "hapter 8 as a techni ue for modeling re uirements. 'hey depict the interactions bet%een the system and external systems and users. (n other %ords they graphically describe %ho %ill use the system and in %hat %ays the user expects to interact %ith the system. & Class diagrams depict the system/s object structure. 'hey sho% object classes %hat the system is composed of as %ell as the relationships bet%een those object classes. & Object diagrams model actual object instances & ,e0uence diagrams depict ho% objects interact %ith each other via messages in the execution a use case or an operation. 'hey illustrate ho% messages are sent and received bet%een objects and in %hat equence. & Collaboration diagrams are similar to se uence diagrams but do not focus on the timing or Dse uenceE of messages. (nstead# they present the interaction 1or collaboration2 bet%een objects in a net%or6 format. & ,tatechart diagrams model the dynamic behavior of a particular object# illustrating an object/s life cycle. & Acti'ity diagrams depict the se uential flo% of activities. & Component diagrams are use to depict the organization and dependencies of the soft%are components. & /eployment diagrams describe the physical architecture.

& &

Use!"ase Model diagrams and class diagrams %ill be covered in this chapter. =e uence diagrams# statechart diagrams# component diagrams# and deployment diagrams %ill be covered in chapter )+.

he .rocess o" Object Modeling & Modeling the functions of the system. & ?inding and identifying the business objects. & 7rganizing the objects and identifying their relationships. eaching !otes & 'hese are object!oriented analysis general activities Modeling the 1unctions o" the ,ystem 'he follo%ing steps evolve the re uirements use!case model into an analysis use! case modelF (dentify# define# and document ne% actors. (dentify# define# and document ne% use cases. (dentify any reuse possibilities. Refine the use!case model diagram 1if necessary2. Document system analysis use!case narratives. ,ystem analysis use case $ a use case that documents the interaction bet%een the system user and the system. (t is highly detailed in describing %hat is re uired but is free of most implementation details and constraints. eaching !otes & :s the analyst continues to learn more about the system and its re uirements# the analyst may discover ne% actors %ho interact %ith the system and ne% use cases. & <hen t%o use cases have the same business goal but different users or interface technology# both use cases may share common steps. <e can extract these common steps into a separate use case called an abstract use case. 7r %e can extract complext steps of a single use case into an extension use case. -e'ised ,ystem Use-Case Model /iagram eaching !otes & : use case model diagram can be used to graphically depict the system scope and boundaries in terms of use cases and actors. & 'he use case model diagram for the Member =ervices =ystem is sho%n in the above figure. (t %as created using ;op6in =oft%are/s S" tem #rchitect and represents the relationships bet%een the actors and use cases defined for each business subsystem. & 'he subsystems 1UML pac6age symbol2 represent logical functional areas of business processes. & 'he partitioning of system behavior into subsystems is very important in understanding the system architecture and is very 6ey to defining your development strategy 3 %hich use cases %ill be developed first and by %hom. Use-Case Narrative & Use-Case !arrati'e (cont%) Abstract Use-Case !arrati'e Modeling Use-Case Acti'ities Acti'ity diagram $ a diagram that can be used to graphically depict the flo% of a business process# the steps of a use case# or the logic of an object behavior 1method2.

 7ne or more activity diagram can be constructed for each use case 1more than one if use case is long or contains complex logic2. =olid dot represents the start of the process. : rounded!corner rectangle represents an activity or tas6 that needs to be performed. :rro%s depict triggers that initiate activities. : solid blac6 bar is a synchronization bar that allo%s you to depict activities that occur in parallel. (2ample o" an Acti'ity /iagram 1inding and Identi"ying the &usiness Objects & ?ind the ;otential 7bjects Revie% each use case to find nouns that correspond to business entities or events. & =elect the ;roposed 7bjects Aot all nouns represent business objects. :s6F (s the candidate a synonym of another objectG (s the candidate outside the scope of the systemG (s the candidate a role %ithout uni ue behavior# or is it an external roleG (s the candidate unclear or in need of focusG (s the candidate an action or an attribute that describes another objectG

eaching !otes
& Using use cases as a source for finding objects is a popular approach for object identification.

.artial Use-Case !arrati'e 3ith !ouns 4ighlighted .otential Object List Cleaning Up List o" Candidate Objects eaching !otes & :dditional objects %ere included that are part of the case study but %ere not identified in the use case. 'hese additional objects are introduced here because they appear in later diagrams. .roposed Object List Organi*ing the Objects and Identi"ying their -elationships & (dentifying :ssociations and Multiplicity & (dentifying -eneralizationC=pecialization Relationships & (dentifying :ggregation Relationships & ;repare the "lass Diagram Class diagram $ a graphical depiction of a system/s static object structure# sho%ing object classes that the system is composed of as %ell as the relationships bet%een those object classes. eaching !otes & (t is very important that the analyst not only identify relationships that are obvious or recognized by the users. 7n %ay to help ensure that possible relationships are identified is to use a objectCclass matrix. 'his matrix lists the objectsCclass as column headings as %ell as ro% headings. 'he matrix can then be used as a chec6 list to

&

&

ensure that each objectCclass appearing on a ro% is chec6ed against each objectCclass appearing in a column for possible relationships. 'he name of the relationship and the multiplicity can be recorded directly in the intersection cell of the matrix. -eneralizationC=pecialization relationships may be discovered by loo6ing at the class diagram. Do any associations exist bet%een t%o objects that have a one!to!one multiplicityG (f so# can you say the sentence Dobject K i a object HE and it be trueG (f it is true# you may have a generalizationCspecialization relationship. :lso loo6 for objects %hich have common attributes and behaviors. (t may be possible to combine the common attributes and behaviors into a ne% super!object. <hy do %e %ant generalizationCspecialization relationshipsG (t allo%s us to ta6e advantage of inheritance %hich facilitates the reuse of objects and programming code. :ggregation relationships are asymmetric# in that object . is part of 7bject : but# object : is not part of object .. :ggregation relationships do not imply inheritance# in that object . does not inherit behavior or attributes from object :. :ggregation relationships propagate behavior in that behavior applied to the %hole is automatically applied to the parts.

Object Association Matri2 eaching !otes & 'his tool can be used to record the possible association bet%een any t%o objects. & 'o interpret the contents of the cells# start %ith the object on the left of the ro%# read the contents of the cell# and then finish %ith the object at the top of the column. ?or exampleF & : "LU. MEM.ER places zero to many orders. & : "LU. MEM.ER and ;R7DU"' have no association bet%een them. )enerali*ation+,peciali*ation 4ierarchies .ersistent and ransient Object Classes .ersistent class $ a class that describes an object that outlives the execution of the program that created it. =tored permanently as in a database ransient object class $ a class that describes an object that is created temporarily by the program and lives only during that program/s execution. Class /iagram