Chap 5

CHAPTER 5 - Conceptual Design: Object Technology Concepts and U!
Class Diag"a#s
CHAPTER O$%ECT&'E( )*OU (HOU!D $E A$!E TO+:
1. Define and give examples of class, object, attribute, operation, relationship, message, persistence and
state.
2. Describe and use several strategies used to find classes and objects.
3. Describe a technique for keeping track of future enhancements for the information system.
. !dentify several questions to ask to help discover attributes.
". Define three types of attributes.
#. Describe one attribute data dictionary technique.
$. %e able to create a &'( )lass Diagram for a problem domain.
*elcome to +bject ,echnology 1-1. +,/1-1 is an introductory 0course0 covering basic object technology
concepts. 1very profession is steeped in its o2n jargon, and soft2are development is no different. !n
soft2are development the jargon is often associated 2ith concepts and principles that contribute to the
discipline. +ur soft2are development jargon has a long history and continues to evolve almost every day.
+ne can hardly pick up one of our do3ens of 2eekly trade press ne2spapers or maga3ines 2ithout finding
at least one ne2 0bu33/2ord.0 ,he purpose of this next section is to briefly explain the follo2ing object
technology concepts4 object, class, attribute, operation, relationship, message, persistence, and state. 5ll of
these concepts are vital to an understanding of the &'( )lass Diagram that is discussed later in this
chapter. 1njoy the 0course0.
O$%ECT( A,D C!A((E(
*hat is an object6 *hat is a class6 7imply stated, an object is defined as an abstraction of a person, place,
thing or concept 2ithin the problem domain that the information system must be a2are of. 5 class is a set
or collection of abstracted objects that share common characteristics. ,herefore a class may be thought of
as a template or 0factory0 from 2hich objects are instantiated 8created9. )lasses can either be abstract or
concrete. 5n abst"act class 2ill never have any objects that are instantiated from the class. +ne could say
that an abstract class is like a template that is never used or a factory that doesn:t produce anything. ;ou
might be asking, 0*hy 2ould such a class exist60 ,he ans2er is that an abstract class is used to sho2 a
hierarchical 8parent/child9 relationship and accompanying inheritance. %oth relationships and inheritance
are discussed later in this +,/1-1 0course0. 5 conc"ete class, al2ays referred to simply as a class, either
has or could have the ability to instantiate one or more objects. <igure ".1 illustrates both of these concepts.
,he &'(:s class notation does not differentiate bet2een an abstract class and a =concrete> class 2ith
the exception that one could 8but is not required9 label an abstract class as ??abstract@@. 5s a general rule,
2hen 2e discuss the notion of a class 2e normally are referring to one that could or does have objects
instantiated from it. !n keeping 2ith the &'( reference materials, the first letter of any identified class is
al2ays capitali3ed. <or example, a class of bicycles 2ould be called %icycle.
1xamples of objects, or 2hat is often referred to as instances, could be your bicycle, your backpack,
your automobile, your telephone, each shoe you o2n, each key on your key chain, each slice of bread in a
loaf of bread, the paycheck you received last pay day, and so on. ,hese physical objects and others in the
real 2orld are the easiest type of objects to identify. (ater in the chapter 2e 2ill discuss the more difficult
types of objects to identifyAthe ones that are not so obvious.
Copy"ight - ./// Ronald %0 ,o"#an D"a1t date: ,o2e#be" 34 .///
,o pa"t o1 this #anusc"ipt #ay be "ep"oduced 5ithout 5"itten pe"#ission 1"o# the autho"0
This boo6 5as p"e2iously published by P"entice-Hall4 &nc0
B"
1xamples of classes could be %icycle, %ackpack, 5utomobile, ,elephone, 7hoe, Cey, %read, and
Daycheck. )lasses are al2ays referred to in the singular even though they typically represent a collection of
one or more objects 2ith similar characteristics. 7o, the %icycle class could contain instances of your
bicycle, my bicycle, your roommate:s bicycle, and so on.
!n the &'( a Class Diag"a# is created that 2ill contain all of the classes that are important for the
architecture of the information system. 1ach individual class on a class diagram is partitioned into three
sections from top/to/bottomAthe class name, the class attributes, and the class operationsAas sho2n in
<igure ".1. 5ttributes and operations are discussed in the next section of +,/1-1.
%e sure to use terminology and names the user of the information system 2ill be comfortable 2ith,
other2ise user acceptance of the information system may be difficult to obtain. <or example, in a recent
requirements/gathering session 2ith a client, several synonyms 2ere discovered to mean basically the same
thing. +f the seven people in the meeting, five users and t2o systems analysts, four different terms 2ere
favoredAorigin code, priority code, source code, and key codeAby different individuals thus introducing a
potential communication gap bet2een the people. <urther discussion revealed that all four 2ere in fact
synonyms. ,he group finally reached a consensus to use one of the four termsAorigin codeAuniversally
from that point on in order to eliminate confusion and misunderstanding. 7ometimes use of the synonyms is
acceptable and agreed to by the users, but, over time, organi3ational dynamics can negatively affect the use
of synonyms as in the preceding example.
7ometimes it is necessary to use an adjective along 2ith a noun for the class name such as Eental
5greement instead of 5greement in order to further clarify the class and to make it more meaningful to the
user. !n the &'(:s notation, class names 2ith more than one 2ord are compressed together 2ith no spaces
and the first letter of each 2ord is capitali3ed. <or example, Eental 5greement 2ould become
Eental5greement. ,here are a fe2 simple rules and guidelines for creating classes that are summari3ed in
<igure ".2.
B#
5ll classes and objects have three responsibilities4
1. *hat they kno2 about themselves F referred to as attributes
2. *hat they do F referred to as operations
3. *hat other objects they kno2 about F referred to as relationships
1ach of these responsibilities is discussion in the follo2ing sections of this chapter.
ATTR&$UTE(
Eeferring back to <igure ".1 you see several classes. ,he center section of each class symbol is reserved for
any associated characteristics belonging to the class that is collectively referred to as attributes. 5n
att"ibute is data that further describes an object instance. 1xamples of attributes that are all related to a
student could be a student:s last name, first name, address, city, state, and grade point average. 5ttributes
related to a course at a university could be course number, course name, course units, and course
prerequisites.
!n business/oriented information systems, such as a university course registration system, many of the
classes 2ill represent data, such as students, courses, faculty, products, rooms, video movies, and so on.
*ithin these data/oriented classes, each object must have one or more attributes 2hose values make the
object unique from all other objects 2ithin the class. <or example, a class called 5utomobile that has
unique instances of automobilesAfor example, your automobile, your roommate:s, your brother:s, your
parent:s, and so onAmust have some 2ay of identifying one specific automobile object from all the other
automobile objects 2ithin the class. ,his is no different than an 5,' machine being able to read your bank
card and then being able to tell your bank account number from all the other thousands it keeps track of, or
the fact that your fingerprints are like no other on the face of this earth 8so 2e are told9.
,he 2ay business/oriented information systems identify one object as being unique from all other
objects in the class is to identify some attribute or combination of attributes that 2ould distinguish it from
all other objects. <or example, ho2 is one automobile object instance identified uniquely from all other
automobiles in the 5utomobile class6 *ell, in the real 2orld, each automobile has a unique vehicle
identification number 8G!H9 associated 2ith it and assigned by the vehicle:s manufacturer. ,here should not
be t2o G!H numbers alike on the face of the earth 8so 2e are told9. ,herefore, this attribute could be used
to uniquely identify one automobile from all the others. 5ttributes are more fully discussed in a later section
of this chapter.
OPERAT&O,(
Eeferring back to <igure ".1 once again you see several classes ,he bottom section of the class symbol is
B$
reserved for operations. +perations are often referred to as #ethods in the object/oriented programming
2orld. Ope"ations are actions that each object in the class is responsible for exhibiting or performing. !n
keeping 2ith this definition of an operation, you as an object could be expected to 2alk, talk, listen, eat,
sing, smile, etc. 5s 2ith any example or metaphor, this example 0breaks/do2n0 because you and ! kno2
that not all people objects can perform every one of these listed operations, but at least you should get the
idea.
!n object/oriented information systems operations are usually very specific and focused. <or example,
the 2alking operation from above is really composed of many smaller actions that are put together to create
the 2alking operation. ,he more ato#ic 2e make our operations the more they have the potential to be
reused over and over again 2ithin and across several information systems. <or example, an operation that
simply retrieves a person:s first name from a database of names and addresses is more reusable than an
operation that retrieves a person:s first name and does ten other things in addition. 7ome examples of
operations could be4 get<irstHame89, set<irstHame89, get(astHame89, set(astHame89, compute7ales,ax89
and so forth. +perations are more fully explored in )hapter $.
5n example of a class 2ith attributes and operations for a university course registration system is
illustrated in <igure ".3. Hot all possible attributes and operations are listed due to space considerations,
but hopefully enough are sho2n to give you the idea of these concepts. Ceep in mind that the class notation
is flexible enough to fit the needs of the problem domain.
RE!AT&O,(H&P(
,he third and final responsibility of classes and objects is relationships. 'uch of )hapter # is devoted to
this concept since it is so important. !n the &'( )lass Diagram a "elationship can be established bet2een
t2o classes that is referred to as a gene"ali7ation "elationship or a relationship can be established bet2een
objects either belonging to different classes or belonging to the same class and this form of relationship is
referred to as an object association "elationship. !n the &'( )lass Diagram there are three 839 forms of
object association referred to as association, agg"egation, and co#position. 1ach of these 2ill be explored
in much more detail in the next chapter. Eelationships allo2 a class to be related to one or more other
classes or an object to be related to one or more objects either belonging to the same class or different
classes. <igure ".1 illustrates the gene"ali7ation relationship and <igure ". illustrates the co#position
association relationship.
BB
Eelationships contribute to the &'( )lass Diagram in t2o 2ays4 19 relationships help to simplify a
)lass Diagram, and 29 relationships help to communicate the architectural relationships that must exist
2ithin the information system in order for it to accomplish its intended purpose.
E((A8E
5 #essage is a 0signal0 from one object to another object requesting the receiving object to carry out one of
its operations. 'essages are ho2 objects communicate 2ith one another in order to accomplish the
information systems purpose. Ceep in mind that 0the operation is the message0 2hich means that one object
specifically identifies another object:s operation by name 2hen it needs assistance to accomplish some task.
<or example, in the real 2orld you might ask me 2hat grade you have earned so far in this course. ,hat is
the messageAyou asking me 2hat grade you have earned so far. !, as an object, 2ould look in my grade
book and tell you your grade. 7o, my action of looking in my grade book for your grade and telling you
your grade is the essence of the operation that ! perform 2hen you send me the 02hat is my current grade0
message. !n object technology a message identifies an object and the specific operation to perform.
PER(&(TE,CE and (TATE
*e conclude our +,/1-1 0course0 2ith t2o final object technology conceptsApersistence and state. ,hese
t2o concepts are easy to explain and are mainly identified here because they are vocabulary 2ords often
associated 2ith computer science or soft2are engineering but rarely used in the information technology
community. Pe"sistence simply refers to the permanent, long/term storage of data. !t is analogous to the
storing of data in files on a hard disk, diskette, or )D. Dersistent data can 2ithstand the turning/on and
turning/off of electrical po2er 2hereas memory/resident data are volatile and are erased 2hen po2er is
turned/off. ,he information technology community often refers to persistence as a database.
(tate refers to the condition of an object at a specific moment in time. <or example, my personal
2eight on a <riday afternoon might be 1B- pounds. ,he follo2ing 'onday morning my 2eight might be
1B3 pounds or 1$B pounds depending on my food consumption and my activity or lack thereof over the
2eek/end.
9&,D&,8 O$%ECT( A,D THE&R C!A((E(
Ietting started. +nce again 2e are faced 2ith creating a different &'( diagramAthe )lass Diagram. 5s
2e move on to a discussion of finding objects and their classes for the )lass Diagram an important
characteristic of the object/oriented problem/solving strategy comes to mind. ! bring this up here because
finding classes and objects is an object/oriented problem/solving strategy for defining and documenting an
BJ
information system. )lasses and their associated attributes and operations are relatively stable over time.
1ven though some of the attribute values of a class may change 8e.g., you move so your address and
telephone number must be changed in your object9, or the 2ay the information system performs one of the
operations that belongs to a class may change do2n the road 8e.g., an 5,' machine:s display screen
changes from monochrome and text to color and graphics9, the class 2ill remain a constant and an integral
part of the overall problem domain. ,his is good ne2s. 7tability over time is very important 2hen it comes
to the amount of time, resources, and cost to maintain the information system throughout its life. (ike a
building 2hose foundation is instrumental to the long/term usability of the building, an information
system:s foundation is also critically important. !n general there is a correlation bet2een the stability of the
information system:s foundation and the amount of time, resources, and cost to maintain it over its lifetime.
Ho2 that you have an understanding of objects, classes and the other object technology concepts, 2e
2ill discuss three strategies for helping you discover classes and objects in the problem domain of interest
to you and your user. ,his section is going to present strategies for finding objects and their classes. 5s you
kno2, no object #ay stand-aloneK therefore, 2hen you find an object, you automatically find the class that
2ill group all objects of that type. <or example, in a university course registration system, let:s say that a
student object is deemed a candidate object. 7ince there are lots of student objects 8one for each student
registering for courses9, you automatically find a class called 7tudent or 7tudent!nformation, 2hich 2ill be
the grouping of all student objects.
,he strategy or strategies you select for finding objects and their classes are often dependent on several
factors0 9i"st, the type of requirements documentation you have to 2ork 2ith in the beginning 2ill play a
significant role in determining this. !f you have something like Co3ar:s requirements model as the
requirements document for the problem domain, as discussed in an earlier chapter, or some other
2ell/defined document, you may choose freely from the strategies discussed later. !f you are getting
together 2ith your user in a brainstorming or L5D session in lieu of having a requirements document, you
may need to use the third strategy discussed later.
(econd, your user may have a preferred 2ay of initially looking at the problem domain. Discussed in
an earlier chapter 2ere the data, functional, and behavioral 8user interface9 characteristics of an
information system. ;our user may have a preference for one or more of these as the basis for discussing a
model of the problem domain. <or example, a recent client of mine had prepared a simplified user
requirements document prior to meeting 2ith me. Mis document focused primarily on the data aspects of an
information system. Me had dra2n samples of half a do3en or more reports that he 2anted from the
information system. 5n object/oriented model could still be constructed starting from a data perspective
such as this.
Thi"d, you may have a bias to2ard one or more of these three aspects of information systems and feel
more comfortable using a certain one. *ith over 2- years of systems analysis and design consulting
experience, ! have a predisposition to use the functional aspect but have tempered this to use both the data
and behavioral 2hen necessary. !astly, the information system itself may cry out for a specific aspect
emphasisAdata, functional, or behavioral 8user/interface9.
:i"1s-$"oc6 ,oun Ph"ase (t"ategy
,he first strategy, discussed in more detail in the end of chapter reference book, approaches the problem of
finding objects and their classes by focusing on the nouns and noun phrases that exist in the requirements
specification document. Eebecca *irfs/%rock and her colleaguesA%rian *ilkerson and (auren *ienerA
suggest the follo2ing steps be follo2ed by the systems analyst and are quite often done 2ith discussion and
assistance from the user4
J-
1. Eead and understand the requirements document because the goal of the 0finding objects and their
classes0 activity is to create a model that very closely parallels the real/2orld problem domain in
question.
2. Eeread the document looking specifically for nouns and noun phrases. 'ake a preliminary list of
these nouns and noun phrases and change all plurals in the list to singular, such as bicycles to
bicycle.
3. Divide the noun and noun phrase list into three categories4 obvious objects 8classes9, obvious
nonsense objects 8classes9, and 0not sure of0 objects 8classes9.
. Discard the nonsense noun and noun phrase list.
". Discuss the 0not sure0 noun and noun phrase list in more detail until each one can be moved to
either the obvious or nonsense list.
<igure "." is a copy of part of the Gideo 7tore:s requirements from an earlier chapter. !t is presented
here for illustration of step 2 in the *irfs/%rock approach for finding objects and their classes. ,he
pertinent nouns and noun phrases in the list have been underlined as object 8class9 candidates. <igure ".#,
2hich represents the results of step 2, lists the noun and noun phrases from the information system
objectives in <igure ".". ,hese are the candidate objects 8classes9. Hote that plurals have been converted to
singular at this point, and that all 2ords have been capitali3ed. ,he systems analyst 2orking 2ith the user
2ould perform steps 3 through ". <inally, the systems analyst 2ould end up 2ith a refined list of candidate
objects 8classes9 that may undergo additional changes as the analysis and design proceed.
J1
Conglo#e"ation o1 othe" (t"ategies
,he other strategies for finding objects 8classes9 have not been articulated as succinctly as the *irfs/%rock
strategy. ,herefore, they are combined for presentation purposes in this section, and each is documented in
one or more of the end of chapter references. ,hese strategies are similar and compatible 2ith each other
and are often used together to find objects. (ater in the chapter these suggestions 2ill be applied to finding
objects in the video store information system example. 5s you begin to find objects for the problem
domains that you are 2orking 2ith, you should look for the follo2ing4
1. Tangible ite#s such as vehicles, furniture, creditNdebit cards, insurance policies, buildings,
animals, scanners, keyboards, displays, conveyors, bins, invoices, shipping documents, sales
receipts, 5,' transaction receipts, paychecks, patient charts, maps, and so on. !t is possible that
not all of the tangible items in the problem domain of interest 2ill be discovered at the beginning of
your search for objects. 7ometimes objects are discovered later on during later conceptual design
activities. ,his is completely normal because most information systems are complex and difficult to
fully comprehend at the beginning of their development life cycle.
2. Roles played by people o" o"gani7ations such as student, teacher, administrator, patient, clerk,
employee, nurse, homeo2ner, department, region, sales office, division, and so on.
3. &ncidents;inte"actions. !ncidents happen at a specific point in time such as paying bills, an
airplane flight, payday for employees, register to vote, register for classes, football or other game,
maintenance call, telephone call, and so on. !nteractions are of a transaction/like nature and similar
to incidents, such as making a purchase at a store, checking out a book at the library, 2ithdra2ing
money from an 5,', making a deposit through the 5,', and so on. !t is not necessarily important
to distinguish bet2een an incident object and an interaction object, nor is it al2ays even possible to
do. ,he important point here is to give you t2o concepts to use to help you identify objects.
. (peci1ications 2hich have a tabular 8ro2Ncolumn9 quality such as a list of sales offices, list of &.7.
state abbreviations, list of 7tandard !ndustry )odes 87!)9, tax rate table, and so on.
5s you create the list of candidate objects 8classes9 or after you have a list, each object on the list
should be challenged based on at least the follo2ing generic ideas4
1. ,eeded "e#e#b"ance. Does the information system need to keep track of this object over time6
*hy6
2. Any att"ibutes< Does the object have at least one identifiable attribute6 !f none or only one can be
identified, then seriously consider the need to keep this as a separate object. !f it is still justifiable,
then by all means, keep it.
3. Any ope"ations< Does the information system need to have certain operations performed by this
object6 *hy6 5n object that does nothing 8e.g., no operations9 is not useful or necessary to the
information system. Mo2ever, sometimes operations are simply not discovered early in the process
J2
of finding objects. !t is often later on that operations are discovered and assigned to objects.
,herefore, don:t just thro2 an object a2ay because it has no operations early in the development
life cycle but rather 2ait until later in the conceptual design to do so.
. Only one object o1 this type< *ill there be more than one of this type of object that could be
grouped into a class6 !f none or only one object can be identified for the class, then seriously
consider the need to keep this as a separate object. !f it is still justifiable, then keep it. ,his
challenge can often be similar to the foregoing needed remembrance challenge. 5n example of this
challenge could be a class called &niversity, 2hich contains instance objects such as Marvard, ;ale,
7tanford, &)(5, 'ichigan, Hotre Dame, 5ri3ona, 'innesota, and so on. ,his candidate class
2ould pass this challenge. !n another information system situation having &niversity as a class,
you may find that the information system need only have one instance object, such as the object for
your specific university. ,his should be challenged. During the challenge, your user tells you that
the information system needs to keep track of specific information about your university because it
is needed to allo2 the information system to perform its duties. %ased on the user:s explanation, the
need for the &niversity class 2ould override this challenge and be kept as a candidate. !f the user
could not justify the need for keeping the &niversity class, then it probably should be dropped from
the candidate list of objects 8classes9.
". A2oid de"i2ed "esults as objects. +ften derived results appear on reports or displays. Derived
results are often the result of a calculation. <or example, a 7ales 7ummary Eeport in a Gideo 7tore
could look like the follo2ing simplified chart. 'ultiplying the &nit Drice by the Ouantity 7old
derives the dollars in the ,otal Drice column. 5dding up the individual ,otal Drice dollars derives
the Irand ,otal dollars. ,hose five 8"9 values are derived results and normally 2ould not be stored
as part of an object since they can be calculated 2henever they are needed. ,he Ouantity 7old
column values are also probably derived but the derivation is not as easily seen as is the ,otal Drice
and Irand ,otal values. 7ince this report represents groups of products there are probably
individual sales of products that are summari3ed to produce the one/line summary line for each
product group. 1ach of those individual sales of products has a quantity sold that must be
summari3ed by the information system before printing the product group:s Ouantity 7old hence it
too is derived.
Droduct Iroup &nit Drice Ouantity 7old ,otal Drice
7oda P-.$" "B P3."-
Dopcorn P-."- 11- P"".--
&sed Gideos P12.J" B3 P1,-$.B"
&sed Iames P1.J" 1" P22.2"
Irand ,otal P1,3J$.#-
,he systems analyst must retain and therefore document the fact that these derived values are needed in
order to keep from losing some important requirements information. +ften derived results are identified as
belonging to a particular object but 2ith the additional de"i2ed 2ord identifier 8e.g., ,otal Drice 8derived9,
and Irand ,otal 8derived99.
Ho single strategy has emerged as the definitive 2ay to find objectsK therefore, it is common for
different project teams to create some2hat different candidate objects for the same problem domain. ,his
situation continues to make the modeling activity more of an art rather than a science. 5s object/oriented
technology matures, object patterns 2ill become more available to use as a starting point for finding
objects. ,he systems analyst 2ill have a group of candidate objects to begin 2ith and can then customi3e
J3
them as the specific problem domain 2here they might be useful is further discussed for its actual
requirements.
$ec6 and Cunningha# CRC (t"ategy
!n a 1JBJ research conference paper, Cent %eck and *ard )unningham proposed their )E) strategy for
finding and documenting objects. ,his strategy takes a holistic vie2 of objects and combines the discovery
of classes 8objects9 along 2ith their associated "esponsibilities and collabo"ationsA)E). %eck and
)unningham classified attributes and operations 802hat an object kno2s about itself0 and 02hat an object
does09 as responsibilities and 2hat 2e are calling a third responsibilityA02hat other object8s9 does an
object kno2 about0Aas a collaboration. 5s one begins to discover objects, their attributes, operations and
collaborations, it becomes necessary to document these discoveries. %eck and )unningham proposed a lo2
technology or lo2/fidelity 2ay of documenting them and their responsibilities and collaborations. ,hey
suggested the use of x# cardsAone per class, dividing it up into three sectionsAclass name,
responsibilities 8attributes and operations9, and collaborations 8other object interactions9. Eefer to <igure
".$ for a )E) card sample. ! have used this documenting tool very successfully on a number of occasions
both in the classroom and in 0the real 2orld.0 Deter )oad may have introduced the use of the sticky 0post/
it/note0 pieces of paper as a surrogate for x# cards. Me also suggested the use of different colors of post/
it/note papers to differentiate various types of classes. ,hese ideas are simplistic but sometimes it:s the
simple ideas that can be really useful. !n this case itQs a simple 2ay to visuali3e a )lass Diagram model of
the information system.
The 'ideo (to"e E=a#ple--9inding Objects
,he video store:s problem domain presented in )hapter 3 2ill continue to be used to develop an object/
oriented information system example from the ground up. Mere the emphasis is on finding objects. ,he
video store information system model, as mentioned earlier, 2as developed in the classroom 2orking 2ith
about three/do3en undergraduate students over several 2eeks of a semester. 5s you 2ould expect, these
students 2ere all subject matter experts 2ith respect to at least visiting a video store. ,he intent of the
J
exercise 2as not to build the ultimate video store information system but to practice using an object/
oriented methodology and notation to create an object model of a simple business information system.
&sing Co3ar:s Eequirements 'odel the students helped develop the video store mission statement,
goals, business objectives, business tactics, information system objectives, and information system tactics
as sho2n in )hapter 2 and partially sho2n in this chapter as <igure ".". 7everal brainstorming sessions
2ere held to create the object/oriented video store )lass Diagram model, sho2n in )hapter 3, 2orking from
these lists intermixed 2ith classroom discussion. )hapter addressed features, actors and use cases. <or
our purposes features are synonymous 2ith Co3ar:s business objectives.
*hile interacting 2ith the students for this exercise ! chose to use the conglomeration of strategies for
finding objects as discussed earlier in this chapter as the strategy for finding objects. ,he primary reason
for doing so 2as that almost all of the students had some personal interaction 2ith video store movie rentals
and, therefore, could be considered kno2ledgeable in the problem domain. ! could have used either the
*irfs/%rock or )E) 7trategy as discussed earlier but ! 2anted to have a significant amount of
free/flo2ing discussion of the problem domain 2ith the students that ! did not 2ant to inhibit for
pedagogical and learning reasons. *hat the students discovered through the brainstorming sessions 2as
that there 2ere many different opinions of 2hat happens in a video store. 'any of the differences 2ere
subtle but some 2ere significant. ,he significant ones 2ere mostly due to the variety of types of video
stores that the students had visited to check out movie videos.
During an initial class period of brainstorming in order to find candidate objects, <igure ".B 2as
developed. ,his list 2as referred to as the Gideo 7tore !nformation 7ystem )andidate (ist of +bjectsADass
+ne. Ho attempt 2as made during the session to discuss details of these candidate objects. !n fact, in the
spirit of brainstorming, !, as the facilitator, expressly discouraged any comments about the positive or
negative merits of each. Ho attempt 2as made to identify 2hether a candidate item 2as an object or not. !n
fact, 2e referred to all of the items discussed as just objects. ,he discussion 2as lively 2ith many of the
students offering their object suggestions.
5fter a fe2 brainstorming and discussion sessions, the studentNinstructor team refined the first/pass list
of candidate objects to come up 2ith the second/pass list of candidate objects grouped into classes as
sho2n in <igure ".J. Hote that the class names are the same as the original object names. ,his is not
required but often ends up being the case. 7ome of the candidate objects 2ere removed from the list
because they did not pass the 0challenge based on0 ideas from an earlier section of this chapter. ,he
students indicated that they felt pretty good about their first fe2 attempts at finding objects during the
brainstorming and discussion sessions. ,hey did admit, ho2ever, that having experience 2ith video stores
allo2ed them to find more of the important objects early in the process.
J"
Maving completed Dass 2 in the 0finding objects0 activity for the video store information system, the
students believed that the core objects for the )lass Diagram model had been identified. 'ore objects may
be identified as the methodology:s activities progress. <igure ".1- sho2s the grouping of the identified
objects into classes, each having the same name as the object it is a collection of. ,his is a common
phenomenon in object modelingAclass names being the same as the object namesAsince a class is a
collection of objects.
5ttributes, operations and collaborationsAobject responsibilitiesAare still needed for each of the
identified classes. <inding and documenting these responsibilities could be done at this time if the systems
analyst or user 2ould prefer it. <or purposes of this book, identifying attributes are discussed in the next
section 2hereas collaborations are the topic of )hapter # and operations are addressed in )hapter $.
%efore moving on to attributes ! first 2ant to briefly discuss a 1utu"e enhance#ents st"ategy. !n a real
problem domain, additional object identification brainstorming and discussion sessions may take place. 5s
they do, it is quite likely that the user 2ill suggest additional ideas and features for the information system.
'any of these ideas and features can be deferred until a later time or a later version of the proposed
information system. )omments like, 0!t 2ould be nice if the system could do . . .0 tend to result in ideas or
J#
features that can be put on a future enhancements list to be dealt 2ith after the information system has been
implemented. 5lso time to develop and cost factors may shift current features into a future enhancements
list in order to reduce the overall development time andNor cost of implementing the first iteration of the
information system. 5 future enhancements list 2as created and expanded throughout the brainstorming and
discussion sessions surrounding the video store example. ,he complete future enhancements list is
presented here, as <igure ".11, even though the actual future enhancements list at this point in the project
2ould have included fe2er items.
ATTR&$UTE(
*hat:s your name6 *hat si3e shoe do you 2ear6 *hat is your address6 *hat color are your eyes6 Mo2
much do you 2eigh6 *hat is your date of birth6 ,hese questions are some2hat intrusive, aren:t they6
)haracteristics such as name, shoe si3e, address, eye color, 2eight, and date of birth are called attributes in
the object/oriented methodology. ,he responses you give regarding the preceding questions represent the
data values of the attributes for you. ;our best friend:s ans2ers to these questions represent his or her data
values for these attributes, and your instructor:s ans2ers represent his or her data values for these
attributes.
5s you have already read, objects 8classes9 have responsibilities that they are expected to exhibit in an
object/oriented information system. ,here are three basic types of object responsibilities4
1. *hat 0!0 kno2 about myself
2. *hat 0!0 do
3. *ho 0!0 kno2
1ach object kno2s things about itself, called attributes. 1ach object kno2s 2hat functions it has to
perform, called operations. <inally, each object kno2s about other objects, called relationships. ,his section
addresses the 0*hat 0!0 kno20 responsibility of an object. ,he other t2o basic responsibilities are covered
in the next t2o chapters. %ack in an early section in this chapter ! defined att"ibute as data that further
describes an object instance.
5ttribute names 8e.g., name, shoe si3e, eye color, and so on9 become the template or pattern that can be
J$
applied to all object instances 2ithin a class that has attributes associated 2ith it. <or example, refer back
to <igure ".3, the 7tudent class sho2s the list of attributes that the information system is responsible for.
,herefore, each student object instance 8e.g., you and each of your classmates9 has its o2n personal data
values for each of the attributes that make up this attribute template. +ne final thought for you to be a2are
of is that it is possibleAalthough highly unlikelyAthat a class in a business information system may not
have any attributes.
7ometimes the attribute values in one object instance may be the same as the attribute values in another
object instance, but that happens most often by chance. <or example, the eye color attribute probably has
only a fe2 possible values such as blue, bro2n, green, and so on, 2hereas a date of birth attribute could
have tens of thousands of possible values.
5nother name for an attribute value is an att"ibute state, and 2e 2ill consider these t2o terms as
interchangeable. 7tate 2as discussed early in this chapter and represents the condition of the attribute at
any moment in time for a specific object instance. 7ome attributes: state rarely or never changes once
established. <or example, your value for the Date of %irth attribute should never changeK your value for the
Hame attribute might change a fe2 times in your lifetime. <or example, Millary Eodham:s name changed to
Millary Eodham )linton. 7ome attributes: state changes frequently. <or example, your value for the 7hoe
7i3e attribute changed several times as you 2ere gro2ing upK your value for the *eight attribute could
change every day or more frequentlyK your value for your %ody ,emperature could also change frequently.
7ome information systems do not need to be as precise as kno2ing that your 2eight changes daily. <or
example, 2eight values on driver:s licenses are only changed, if at all, at rene2al time, 2hich may be every
four years.
)andidate classes often have one or more attributes. 'ore often the case is that many of the classes
have do3ens, even hundreds, of attributes. 5ttributes have already been mentioned several times in this
book because they are an integral and necessary component of object/oriented models and often contribute
to the identification and grouping of classes. 5ttributes add more detail to classes, 2hich in turn reveals
more of ho2 the model should be constructed.
+ver the years professional men and 2omen and students have commented that 2hen they 2ere first
learning about objects, attributes, and states, they found it helpful to make a mental picture of some
examples. 1xamples may help you also. <igure ".12 represents a mental picture example that has been
helpful to others.
!dentifying and defining attributes is an ongoing and iterative activity that involves the systems analyst
interacting 2ith the user. 5 specific problem domain may potentially have thousands of attributes, but
chances are that only a portion of them is a necessary requirement of the system. !n an earlier chapter, the
necessary subset 2as referred to as the information system:s responsibility. +nce again, the analysis activity
is performed to prune the list of potential attributes do2n to the list of those that are necessary for the
information system to fulfill its responsibilities, as in <igure ".13.
JB
5ttributes are manipulated by operationsAthe topic of a later chapter. !n general, attributes in a
specific class may only be manipulated by their o2n operations. ,his feature of object orientation supports
the encapsulation or in1o"#ation-hiding principle that helps to manage the complexity inherent in any
information system. !n other 2ords, the operations in a specific class have the responsibility of managing
and changing the state or data values of their attributes. 7ome object/oriented programming languages
support the notion of 1"iend objects. <riend objects are allo2ed to manipulate some or all of other
friend/designated objects: attributes.
5 change made to an attribute state can be anything that is allo2ed for the specific attribute. <or
example, a ne2 object instance may not have a specific value for any of its attributes 2hen createdK then
JJ
one or more operations 2ithin the class are called upon to populate the attributes 2ith data values for each
attribute. ,he operation that changes the eye)olor attribute value to 0blue0 had better kno2 the policy or
rule pertaining to allo2able data values for this attribute. !f the request 2as made for this operation to
change the eye)olor attribute data value to 0purple,0 it should kno2 2hether or not this is a valid eye color
data value. ,here are other 2ays of handling attribute value validations beyond the one just presented here,
and several are discussed in a later chapter dealing 2ith input and output design.
Dete"#ining Att"ibutes
Determining attributes, like finding objects, is still a highly cognitive activity involving the analyst and the
user. 'any traditional information systems have predetermined attribute templates from 2hich to begin, but
even these must be investigated as to their significance 2ithin a user:s specific problem domain. Lust
because every ne2 car sold in the &nited 7tates has a cigarette lighter in it doesn:t mean that every buyer
2ill use it. ,he same is true for using attribute templates for common information systems. Mo2ever, unlike
the car:s unused cigarette lighter, 2hich is there and never needs any attention beyond an occasional
dusting, an attribute that is not needed but still part of the information system can add confusion and
overhead in the form of increased processing and storage requirements.
+mitting an attribute can also be problematic if it is determined later that a specific output from the
information system is not possible 2ithout that attribute. Eetrofitting it is costly, just as retrofitting
anything in a construction project 2ould be. 5s the systems analyst and the user discuss the inclusion and
exclusion of attributes, the systems analyst should ask the user to think of the future need for an attribute
that is no2 not necessary and is tentatively going to be excluded. !f the user says there is a good chance
that the attribute might be needed 2ithin a year or t2o, the systems analyst might be 2ise to include it in
the information system:s requirements no2 in order to avoid the retrofitting later on.
,here are endless questions that could be asked of users to help determine the required attributes for the
many classes in the information system. !n the follo2ing list are a fe2 of the more generic/type questions
that can be used in almost any situation and often can start the investigation moving 2ith the users. Hote
that these questions are in the first/person mode because 2e have found that this technique often helps to
0put yourself in the class: shoes for a fe2 minutes0 to better relate to it.
1. Ho5 a# >&> desc"ibed in gene"al< <or example, if you 2ere a personal computer 8just for a fe2
minutes9, ho2 2ould you describe yourself generally6 ;ou 2ould probably mention something
about the brand, type, and speed of microprocessor you have, type of floppy disk drive you have,
si3e of hard disk, amount of E5', number of parallel, serial and &7% ports, type of monitor, and
so on.
2. Ho5 a# >&> desc"ibed in this speci1ic p"oble# do#ain< <or example, ho2 2ould you describe
yourself if you 2ere a specific brand of personal computer, say a )ompaq model R;S6 ;ou 2ould
tell us the specific components that make up the )ompaq model R;S. 7ome of your responses
2ould be identical to your responses to question 1 above, 2hile others 2ould be slightly different
because 2e are focusing on a specific situation. !n addition, some of your responses might be
contrary to the 0general0 responses you gave in question 1, again because the )ompaq model R;S
may have something different than the generic personal computer.
3. :hat do >&> )as this class o" object+ need to 6no5< !n other 2ords, 2hat data are important to
the success of this information system6 7ometimes looking at the desired outputs 2ill help
determine the necessary inputs. ,he necessary inputs often tend to become the attributes.
. :hat state in1o"#ation do >&> need to "e#e#be" o2e" ti#e< ,his question can help identify
additional attributes that are neither obvious nor identified by the prior questions. +ften this
1--
question is probing to identify attributes that may be needed in order to provide historical values
over time for one or more attributes. !f, for example, it is important to retain all temperature
readings from a free3er:s thermometer, and the readings are done every 1" minutes to prevent food
tha2ing caused by an air/conditioner failure 2ithin the free3er, then one or more attributes and
possibly a ne2 class need to be created.
". :hat states can >&> be in< +nce attributes are identified, you can then ask the user this question
for each attribute to determine the policy for each attribute and its accepted values.
<inally, in addition to these questions, you 2ill no doubt ask questions that start 2ith the 2ords 02hat0
02hy,0 02hen,0 02ho0 and 0ho2.0
Att"ibute Types
5s you discuss attributes and their states, at least three types of attributes 2ill be discovered in many
information systems. ,hese types are4
.0 (ingle-2alue att"ibutes
?0 utually e=clusi2e-2alue att"ibutes
@0 ulti-2alue att"ibutes
1ach of these attribute types is discussed next. <ollo2ing the discussion of these attribute types, there 2ill
be a discussion of the strategy used in object/oriented models to accommodate these attributes.
,he single/value attribute is perhaps the most frequently encountered attribute type. 5 single/value
attribute is one that has only one value or state for itself at any moment in time. Eeferring to <igure ".1,
examples of this type of attribute are name, student!dentificationHumber, eye)olor, height, 2eight, and
date+f%irth. 1ven though a student:s height and 2eight 2ill change over time, at any single moment in
time, there is only one height and only one 2eight for a specific student. 'any single/valued attributes have
a descriptive nature to them, as do these examples.
,he mutually exclusive/value attribute is most often problem domain dependent. *hat this means is
that the identification of this type of attribute can only be determined by discussing it in its role as part of
the problem domain and more specifically ho2 it relates to the other attributes 2ithin a specific class in the
problem domain. 5n attribute is said to be a mutually exclusive/value attribute if the presence or absence of
its value is dependent upon the presence or absence of one or more other attribute values. ,he business
policy decisions that this information system is representing play a vital role in determining 2hether an
attribute is of the mutually exclusive value type. <igure ".1" illustrates mutually exclusive value attributes.
,he business policy for this information system states that an employee may be either hourly or salaried,
but not both. *ith this in mind then, either the hourlyEate attribute or the 2eekly7alary attribute 2ould
have a value for each 1mployee object instance.
1-1
,he third attribute type is the multi/value attribute. ,his attribute is the opposite of the single/value
attribute because it can have, as its name implies, multiple values at any moment in time. <igure ".1#
illustrates this, again using the 7tudent class. <or this illustration the 7tudent class has name,
college5ttended, and collegeIradeDoint5verage attributes. 5 specific student, you for example, may be
attending or have already attended one or more other colleges, community colleges, or vocational training
schools. ,he business policy decision that is being enforced or supported by these attributes says that a
student is to list all current and prior colleges, community colleges, and vocational training schools that he
or she attended.
Class Diag"a# Conceptual Design (t"ategy 1o" utually E=clusi2e-'alue Att"ibutes
1-2
+ne of the goals of developing information systems using an object/oriented methodology and the &'( is
to simplify the decision logic that is embedded 2ithin the programming code for the information system.
<or example, using <igure ".1", the programming code embedded in one of the class:s operations 2ould
have to be able to distinguish an hourly employee from a salaried employee, since both types of employee
objects are associated 2ith this class. ,he reason the programming code 2ould need to kno2 about this
distinction bet2een hourly and salaried employees is that different processing actions 2ould be performed
on each employee type. 5 )lass Diagram conceptual design strategy for handling mutually exclusive
attributes 2ould be to create ne2 classes, one for each employee typeAhourly and salariedAas sho2n in
the lo2er portion of <igure ".1". *ith this structure all 1mployee objects instantiated from
Mourly1mployee are hourly employees and all 1mployee objects instantiated from 7alaried1mployee are
salaried employees. ,here is still only one class//Mourly7alaried1mployee//containing employee objects,
but hourly employees are associated 2ith the Mourly1mployee class and salaried employees are associated
2ith the 7alaried1mployee class.
!n object/oriented methodology theory this 2orks 2ell. %ut just ho2 practical is it in every situation6
*ell, it often depends on the number of mutually exclusive/value attributes belonging to a class. ,he theory
2orks 2ell for a class having t2o mutually exclusive/value attributes, as in <igure ".$. ,he class having
t2o sets of t2o attributes that are mutually exclusive can probably also be structured similarly to <igure
".1". %ut 2hat about three, four, five, six, or more sets of pairs of mutually exclusive/value attributes in
one class6 7tructures to support these 2ould get quite cumbersome. 5lso the example so far only has
considered pairs of mutually exclusive/value attributes. *hat about the situation 2here there are three
attributes 8or four, five, six, and so on9 that is mutually exclusive 2ith each other6 5nd 2hat about sets of
these groups of attributes6 5gain, elaborate object/oriented structures to accommodate these situations may
be more problematic than they are 2orth, even though in theory mutually exclusive/value attributes should
be split apart and represented by a generali3ation class relationship pattern, 2hich is discussed in the next
chapter.
Class Diag"a# Conceptual Design (t"ategy 1o" ulti-'alue Att"ibutes
During conceptual design multi/value attributes also suggest the splitting up of one class into t2o or more
classes in an object association relationship to more effectively represent them. (ooking at the top portion
of <igure ".1#, there are three student names. 1ach 2ould be an object. Mo2ever, notice that because of the
multi/value attributes, the first name has t2o colleges attended and the last name has three colleges
attended. %ecause of these multiple values, there 2ould actually be six 7tudent objects//t2o for the first
name, one for the second name, and three for the last name. 1ach 7tudent object 2ould have data values for
each attribute, causing redundancy as sho2n in the bottom portion of <igure ".1#.
5s illustrated in <igure ".1$ objects that have multi/value attributes can be moved to create a ne2 class
that becomes part of an object association relationship pattern that 2ill be discussed in the next chapter. %y
doing this, redundancy is avoided. ,he )lass Diagram 2ould no2 contain t2o classesA7tudent and
)ollege5ttended. Hote that the name and student!dHumber attribute data values are no longer duplicated,
as 2as the case in the lo2er portion of <igure ".1#. 1ach 7tudent object in <igure ".1$ is associated 2ith
the appropriate number of )ollege5ttended objects, as illustrated to the right side of the object association
relationship pattern in the figure. +bject association constraints are also noted on either end of the line 2ith
the diamond on the left end, 2hich allo2s the soft2are to administer the number of )ollege5ttended objects
associated 2ith each 7tudent object and vice versa. !n the figure, a 7tudent object may have 3ero or more
)olleges attended, and a )ollege5ttended object must be associated 2ith one and only one 7tudent.
1-3
<inally, the preceding discussion is more focused on 0ho20 rather than 02hat,0 making it more
appropriate for consideration during either the conceptual or physical design phase of information systems
development. *hat this means is that during the user requirements determination and analysis phase, the
object/oriented model may contain mutually exclusive/value and multi/value attributes in the same class.
Mo2ever, during the design, mutually exclusive/value and multi/value attributes 2ill be looked at from a
0ho2 to design and implement0 perspective and adjusted via the class generali3ation and object association
relationship patterns as discussed earlier. 5s al2ays, if during user requirements determination and analysis
it is beneficial for the user:s understanding of the problem domain:s )lass Diagram, then creating ne2 class
patterns to accommodate both of these attribute types is acceptable. 5s mentioned earlier, both the class
generali3ation and the object association relationship patterns are discussed in more detail in the next
chapter.
THE U! C!A(( D&A8RA - THE '&DEO (TORE EAAP!E - &DE,T&9*&,8
ATTR&$UTE(
,he video store information system:s user requirements model no2 includes classes. 5 fe2 more
brainstorming sessions yielded the attributes sho2n in <igure ".1Ba,b,c for the 11 classes identified earlier.
,rying to sho2 a )lass Diagram 2ith all of the attributes assigned to the various classes becomes
cumbersome on paper since the model 2ill overlap several pages. 7o a t2o/column spreadsheet approach is
taken in <igure ".1B is to just list the classes in the left column and their associated attributes in the right
column. ,he students suggested almost all of the attributes 2ith little prodding from me, 2hich indicated
that they had some familiarity 2ith video stores.
1-
5n additional piece of documentation that is extremely useful to maintain 2ith )lass Diagrams is
called an attribute data dictionary. 5n attribute data dictionary is an alphabeti3ed list of attribute names,
2hich class each belongs to, and details regarding each attribute:s definition and editing rules. !D1 soft2are
that supports &'( )lass Diagrams may automatically support an attribute data dictionary, but the systems
analyst must still incorporate each attribute:s definition and editing rules into the !D1 soft2are:s )lass
Diagram. 5 sample of an attribute data dictionary for the video store example is sho2n in <igure ".1J
belo2.
1-"
5fter some additional massaging of the Gideo 7tore )lass Diagram:s 11 classes 2e expanded the
diagram to 1$ classes. <our of the ne2 classes are abstractA!nventory, 7ale!tem, Eental!tem, and
,ransaction. ,2o additional classes 2ere important to accommodate multi/valued attribute situationsA
7aleEental(ine!tem and Durchase+rder(ine!tem. ,he resulting Gideo 7tore &'( )lass Diagram no2
appears as <igure ".2- and 2ill be discussed in more detail in the next chapter.
1-#
(UAR*
,his chapter defined several object technology conceptsAobject, class, attributes, operations, relationships,
messages, persistence and stateAand gave examples of each. 7everal strategies 2ere presented as 2ays to
help the systems analyst find objects and classes in a problem domain. ,hese strategies and others are
helpful given the facts that the problem domains are quite diverse and the object/oriented methodology is
still emerging and needs to mature. ,he *irfs/%rock strategy 2as discussed in a step/by/step fashion in
order to illustrate its approach. ,he combination of several other 0finding objects0 strategies 2as used to
begin the development of the video store information system object/oriented &'( )lass Diagram. 5s
requirements are being gathered for an information system, it is helpful to keep a list of proposed future
enhancements for possible addition to the information system at a later time. 5ttributes 2ere defined,
described, and illustrated 2ith examples. 7everal questions 2ere presented that can help a systems analyst
discover attributes. ,hree types of attributes 2ere discussed and illustratedAsingle/value, mutually
exclusive/value, and multi/value attributes. ,he )lass Diagram strategy to handle mutually exclusive/value
and multi/value attributes 2as discussed. <inally, the video store information system example 2as further
expanded to include attributes.
E,D O9 CHAPTER BUE(T&O,(
THE(E ARE ,OT THE BUE(T&O,( 9OR THE RE'&(ED CHAPTER 5 )(o""yC+
".1 %riefly define and give an example of a class and an object.
".2 *hat is the difference bet2een a class and class/2ith/objects6
".3 *hat is the major distinction bet2een classes and objects6
1-$
". Mo2 many different notation symbols are used for class and object6 Dra2 each of them.
"." !n object/oriented notation, ho2 is a class distinguished from a class/2ithobjects6
".# *hat are the three sections 2ithin the class template6 Iive examples of each.
".$ *hat are the steps in a noun phrase strategy of identifying objects6
".B !n general, 2hat is a noun phrase strategy trying to find6
".J Mo2 does your ans2er to the previous question change if you are using a verb strategy6
".1- *hen starting a search for objects, 2hat are some of the items you should be especially a2are of6
".11 *hat is meant by challenging a list of possible objects6
".12 *hat is generally done 2ith derived results such as an employee report6 *hy6
".13 *hat is done 2ith requirements that can be deferred6
".1 *hat is an attribute, and 2hat is an attribute:s purpose in an object model6
".2 *hat is the most important method for identifying and defining attributes6 Discuss 2hy this is
so important.
".3 *hat are some of the specific questions that can be asked of a user in an attempt to best
identify attributes6
". *hat is a single/value attribute6
"." Define and give a fe2 examples of a mutually exclusive/value attribute.
".# *hat is the purpose of demoting multi/value attributes to the lo2er level in a 2hole/part
object connection pattern6
".$ *hat aspect of using multi/value attributes in a 2hole/part object connection pattern makes
this task better suited for the design phase of systems analysis and design6
".B *hat is an attribute data dictionary and 2hat is its purpose in an object/oriented
methodology6
RE9ERE,CE(
%eck, C. and )unningham, *., 05 (aboratory for ,eaching +bject/+riented ,hinking0,+bject/+riented
Drogramming system (anguages and 5pplications 8++D7(59, +ctober 1/#, 1JBJ, He2 +rleans, (5.
%ooch, I., Object-Oriented Analysis and Design with Applications 82nd ed.9. 'enlo Dark, )54
%enjaminN)ummings, 1JJ.
)oad, D., Horth, D., and 'ayfield, '., Object Models: Strategies, Patterns, and Applications. 1ngle2ood
)liffs, HL4 Drentice Mall, 1JJ".
)oad, D., and ;ourdon, 1., Object-Oriented Analysis, 82nd ed.9. He2 ;ork4 ;ourdon DressN Drentice Mall,
1JJ1.
<iresmith, D.I., Object-Oriented Requireents Analysis and !ogical Design. He2 ;ork4 Lohn *iley T
7ons, 1JJ3.
Menderson/7ellers, %., A "oo# o$ Object-Oriented %nowledge. He2 ;ork4 Drentice/Mall, 1JJ2.
Eumbaugh, L., %laha, '., Dremerlani, *., 1ddy, <., and (orensen, *., Object-Oriented Modeling and
Design. He2 ;ork4 Drentice Mall, 1JJ1.
7hlaer, 7., and 'ellor, 7.L., Object-Oriented Systes Analysis: Modeling the &orld in Data. He2 ;ork4
;ourdon DressNDrentice Mall, 1JBB.
*inblad, 5.(., 1d2ards, 7.D, and Cing, D.E., Object-Oriented So$tware. Eeading, '54 5ddison/*esley,
1JJ-.
*irfs/%rock, E.(, *!(C1E7+H, %., and *!1H1E, (., Designing Object-Oriented So$tware. He2 ;ork4
Drentice Mall. 1JJ-.
1-B
1-J

Chap 5

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chap 5

Hochgeladen von

Copyright:

Verfügbare Formate

CHAPTER 5 - Conceptual Design: Object Technology Concepts and U!

Das könnte Ihnen auch gefallen