SECTION1 GETTING STARTED Classes are giscussed in Chapters + and 9 Things in the UML There are four kinds of things in the UML: 1, Structural things: 2, Behavioral things 3, Grouping things 4, Annotational things “These things are the basic object-oriented building blocks of the UML. You use them to write well-formed models. sof UML models, These the Structural Things Struct are the mostly static parts of a model, rey resenting elements that are either conceptual or apne In all, there are seven kinds of structural things, First, a class is a description of a set of objects that share the same attributes, ‘operations, relationships, and semantics. A class implements one or more inierfaces-Graphically, a class is rendered as a rectangle, usually including its ‘name, attributes, and operations, as in Figure 2-1. pw Window | origin size open) ae close() x move() x display) ee Figure 2-1: Classes. ~ class or Com ‘An interface th ponent \erefore describs behavior of that element. An interface, ae a ae of a class f tha por Sef oF operatio ‘ation Trrcleme tie raphivea ae ures), but cag a i hee © the class OF component that realizes the intertace, as in Nate iy ‘ Oe \Speliing Figure 2-2: InterfayCHAPTER 2 INTRODUCING THE UML a 6llaboration defines an interaction and is a society of roles and other nts that work to} ‘Ovi Vior that's bigger is have structural, as imensions. A given class might participate in several col- laborations. These collaborations therefore represent the implementation of patterns that make up a system.'Graphically, a ths as an & _cllipse with dashed lines, usually including only its name, as in Figure 2-3.” vt Semen meant ta . Xe At? Use cases aro (lens, es ete tua en. i are forms that yields able result of value to a Particular actorgA use Fo - case Is used to ae ‘behavioral things in a model4A use case is realized by a collaboration’ Graphically, a use case is rendered as an ellipse with solid nc, uualy including Sly aug Se RS Place order — Figure 2-4: Use Cases (Gre remaining three things —ecti ve classes, components, and nodes—are all cee ere ee a set of objects that share the same Sibi operators atcha aid scountes]Howens err ecaie ifferent enough and are necessary for modeling certain aspects of an object- oriented system, and so they warrant special treatment. Active classes Fifth, ive class is are discussed in Chepter 22, ith other elements {Gray cally, an active-class.is rendered just like a class, butwatr Reavy Tines usually including its name, attributes SAT operators in Figure 2-5. , 4 ae VW ~nents cussed oter 24. are sed in er 26. seneperensstenreentesnnne fan Sgn tsi) ‘suspend() flush(), Figure 2-5: Active Classes (Gixth,!a component isa physical and replaceable part of a system that con- forms to and provides the real ization of a set of interfacest Jn a system, you'll encounter different kinds of deployment components, such as COM+ compo- nents or Java Beans, as well as components that are artifacts of the develop- ment process, such as source code files. A component typically represents the physical packaging of otherwise logical elements, such as classes, interfaces, and collaborations {Graphically,-a component is rendered as a rectangle with ] erdertorm java Figure 2-6: Components ode is a physical element tha(Gxists at run time ay lat eXists at ruy 3 computational resourcey generally having at least oR Fig Presents 2 , ee fteT. processing capability. A set of components may reside on anode and m: I jay also migrate from node to nodeAGraphically, a 5 ints from ode. no Ja phe 2 a node is rendered as a cube, usually — em eure -— Figure 2.7: Nodesinclude in a UML model. There are also variations on these seven, such as actors, signals, and utilities (kinds of classes), processes and threads (kinds of active classes), and applications, documents, files, libraries, Pages, and tables (kinds of components). [Behavior Things Behavioral things are the dynamic parts of UML mod- els. These are the verbs of a model, representing behavior over time and sp Tn all, there are tw primary kinds OF behavioral things, re (First, an interaction is a behavior that comprises a set of messages exchanged amion in a particular context to a pass The behavior of a society of objects or of an indi ry specified with an interaction/An interaction involves a nuimiber of other ele- ments, including messages, action sequences phe penavior invoked by a mes- sage), and links (the connection between objects)Graphically, a message is rendered as a digas line. almost always including the name of its operation as in Figure 2-8. aren aa a ad display wo ES STS a Figure 2-8: Messages ap faae® A = Second, a stale machine is a behavior that specifies the sequences of states an > “object or an interaction goes through during its lifetim nse 10.e¥. to; TW’ to those eventsAThe behavior of an individual class ‘or a collaboration of classes may be specified with a state machine. A state machine involves a number of other elements, including states, transitions (the flow from state to state), events (things that trigger a transition), and activities (the response to a transition). Graphic state is rendered as a rounded rect- angle, usually including its name and its substates, | if any, as in Figure 2-9. a reds > Waiting ae Figure 2-9; States These two elements—interactions and state machines—are the basic behav- ioral things that you may include in a UML model. Semantically, these eleSECTION1 GETTING STARTED i wi RS ee es are ed in r 12. sare ssed in ter 6. fe ments are usually connected to various structural elementss primarily classes, collaborations, and objects. x Boiss ii ([¢rouping Things Groupin; things are the anizational parts.of UML m “boxes into which amodel can | e decomposedjtn all, n ‘These are the a [can be decs there is one primary kind of grouping thing, namely, packages. fa package is.a general-purpose | mechanism for organizing elements into groaps,,Structural things, behavioral things, and even other grouping things May be placed in a package} Unlike components (which exist at run time), a__ o packs is purely conceptual (meaning that it exists only at development time). / ‘a package is rendered as a tabbed folder, usually including only its ‘aphically, fame and, sometimes, its contents, as in Figure 2-10. » SO eeicear onan c—— R Business rules ye Figure 2-10: Packages Packages are the basic grouping things with which you may organize a UML model. There are also variations, such as frameworks, models, and subsystems (kinds of packages). : : {Annotational Things Annotational things are the e cuaae -xplanatory parts, coodele Thee ae TE COMMENTS FOU MAY App to MERSIN remark about any element in a model, There is one primary } ¢ , primary kind of annota- tional thing, call ote, A note is simply a symbol Fetes Te and comments attached to an €lement or a collection of elements eraein a’ is rendered as a rectangle with a dog-eared x ; : corner, togethe! tual or graphical comment, as in Figure oH Aun ee i; return copy = LS ee of self Figure 2-11: NotesCHAPTER 2 INTRODUCING THE UML 45, comments that are best expressed in informal or formal text. There are also variations on this element, such as requirements (which specify some desired behavior from the perspective of outside the model). Vfelationships in the UML There are four kinds of relationships in the UML: * ST Dependency | 9 2. Association ea 3. Generalization / 4, Realization ~ + vv These relationships are the basic relational building blocks of the UML. You use them to write well-formed models. Devendences [Fi between two things in which a are discussed j independent thing) may affect the semantics of the inChaptersS “other thin; idént thing). Graphically, a dependency is rendered as a and 10 : “spent : : gore shed line, possibly directed, and occasionally including ¢ label. as in Figure 212. zi ent a Figure 2-12: Dependencies Associations: Second, an association is.a structural relationship that describes a set of links, are discussed link being a connection among objects. Agaregation isa special Kind of asso- wCnagies 5 Satron, fepresenting a structural relationship Between Whole and its parts. ard 10. 5 oh x Graphically, an association is rendered as a solid line, possibly directed, occa- Seren rsceaMs Tbe and lien containing other adornments, such as mul- ili in Figure 2-13. tiplicity and role names, as in Fig a ot ‘employer ‘employee Figure 2-13: Associations Gerorates- [~ Third, a generalization isa specializationigeneralization relationship in which fons ae abjects of the speeTalized element (the child) are substituuable for objects ofthe discussedin generalized element (the parent). In this way, the child shares the structare ach andte «the behavior of the patent. Graphically, a generalization relation ren dered as a solid line with a hollow arrowhead pointing to the parentyas in Fig- ure 2-14,Realizations are discussed in Chapter 10. The five views of an architec- ture are discussed in the following section. 46 ‘SECTION 1 (diagrams in the UML A diagram is the graphical presentation of a GETTING START 14; Generalizations Figure 2 between classibers. wherein [ ant ic relationship 2 Fourth, a realization is @ semantic relat ther classifier guarantees to carry out, ontract that ano" wo places: between interfaces ‘ne classifier specifies a c that an oe spur fealzation relationships im (WO FAT ce cases and the and the classes or components that realize them, al Pe airs i collaborations that realize them. Graphically, areal Re aistieatip, os a cross between a generalization and a depe! a se : Realization j ‘These four elements are the basic relational things you may include in a UML model, There are also variations on these four, such as refinement, trace, include, and extend (for dependencies). Figure 2-1 elements, most of cted graph of vertices perspectives, so a diagram is a projection into a system. For all but the most iFivial systems, a diagram represents an elided view of the elements that make up a system. The same element may appear in all diagrams, only a few dia- grams (the most Common Case), oF mo Uagrams a all (every care case). In theory, a diagram may contain any combination of things and relationships. I practice, however, a small number of common combinations arise, which sre consistent with the five most useful views that comprise the architecture a a sofiware-intensive system, For this reason, the UML i i abet n, the UML includes nine such A. Class diagram 2. Object diagram A. Use case diagram i. Sequence diagram —5- Collaboration diagram 6. Statechart diagram 9 7. Activity diagram _-8° Component diagram 9. Deployment diagramcass diagrams are discussed in Chapter 8. Object / © diagrams are discussed in *\ Chapter 14 use case diagrams are aiscussed in | Chapter 17. Interaction diagrams are aiscussed in Chapter 18. Statechart diagrams are discussed in. Chapter 24. Activ, diagrams are discussed in Chapter 19. Component diagrams are discussed in Chapter 29. i CHAPTER 2 INTRODUCING THE UML at A class diagram shows a set of classes, interfaces, and. collaborations and their Jationships, These diagrams are the most common diagram found in model- ing object-oriented systemsaClaks diagrams address the static design view of a | system, Class diagrams that include active classes address the static process view of a system * An object diagram shows a set of objects and their relationships. Dbject dia- grams represent static(Snapshots of instances of the things found in class dia- grams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases. A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system. aie’ Both sequence diagrams and céllaboration diagrams are kinds of interaction diagrams. An interaction diagram shows an interaction, consisting of a set of objects and their relationshipsy including the messages that may be dispatched among them, Interaction diagrams address the dynamic view of asystemsA sequence diagram is an interaction diagram that emphasizes the time-ordering of messages; a collaboration diagram is an interaction diagram that empha- sizes the structural organization of the objects that send and receive messages. Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other. A statechart diagram shows a state machine, consisting of states, transitions, events, and activities. Statechart diagrams address the dynamic view of a sys- jem. They are especially important in modeling the behaviog of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems. ‘An activity diagram is a special kind of 2 statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic viewjof a system.gThey are especially important in modeling the func- tion of a systém and emphasize the flow of control among objects A component diagram shows the organizations and dependencies among a set ‘of components. Component diagrams address the static implemientation view of a systemyThey are related to class diagrams in that a component typically maps to one or more classes, interfaces, or 7) ggSecrion1 GETTING STARTED loyment fe deployment diag) rams are used in pter 30. n of run-time pr essing nodes iapgrams address the static nd the components that live on them era se gistcins d t view of an architecture, They are re we nt aa ae ally encloses one or more components.) in that a node typic js may use the UML to provide other t common you will e configuration sth ram shows "em, Deployment diagrams. Tool! isi sed list of ‘This is not a closed list of hitpaas ine ire by far the most kinds of diagrams, althoug] encounter in practice. Rules of the UML ————eene The UML’s building blocks can’t simply be thrown together in a random . fashion. Like any languagesthe UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models. erences n Smee The UML has semantic rules for w7 Names What you can call things, relationships, and diagrams Scope The context that gives specific meaning to a name = Visibility How those names can be scen and used by others = Integrity How things properly and consistently relate to one another = Execution What it means to run or simulate a dynamic model 7 ee Is built during the development of a software-intensive s t system tend to ouplye and y be viewed by many stakeholders in different ways and at dif- ee a ‘or this reason, it is common for the development team to not only build models that are well-formed, but also to build models that are Pm oeeen orton @ Eli i i z eae Certain elements are hidden to simplify the view incomplete Certain elements may be missing ettieod Pike Heonsistent The integrity of the model is not guaranteed \_-~ ‘These less-than- itifoldee ee ra oad models are unavoidable as the details of a system ring the software development life cycle.he rules of the UML encour, you—to address the most important anne eee you—but do not force » sign, and implementation questions that push such models to become well-formed over as—— SECTION 1 GETTING STARTED — tends the prol ies building block, allowing you A tagee ie. rties Of UML build n value extends U prope! ae eae it yo re set a information it that elements pecificalio’ Pe oxan P je, if eT d undergoes man releas wra 7 —2 duct ‘are working on @ ro author of certain crt trac- They can be addi d ses OVEr 2 tions. Vi to any building block, such as a cl: s, by introdu ‘Iding block. In Figure 2-19, for example, the class Eve Le extended by marking its version and author explicitly. ntQueue Is ‘A constraint extends the semantics of a UML pbuilding block, allowing you to Tadd new rules or modify existing ones. For exal ou might want to con- Grain the Event Queue class 80 that all additions are done in order. As Figure 3-79 shows, you can add a constraint that explicitly marks these for the opera- ‘tion adc EventQueue (version = 3.2 Ey = ‘ ‘Overflow add() -- = - } ~~~ - {order temove() Holaaech flush() Figure 2-19: Extensibility Mechanisms Collectively, these thi : , these three extensibility 1 : © e y mechanisms tie ma oe to your project's heeds inisms allow you to shape and iware technolog These mechanisms also let the UML ful dsiibted programing languages: i sat mae po modify the anguages Like ely emergence of more pow- You cana e i i ‘an add new building blocks. specification of exist] ry ‘aturall ion of existing ones, and ev, even change ec i's important tha Extensions ant that you do so in their semanti ( ‘ou remi S$0-tn ci r semantics / information, ain true to the UML ICs. so that through these aecthn icatian he communication of a hn aInterfaces are ‘iscussed in Chapter 11, The UML's extensibility ‘mechanisms are discussed in Chapter 6. CHAPTER 2 INTRODUCING THE UML, 51 Second, there is the separation of interface and implementation. declares a contract, and an implementation represents one concrete realization of that contract, responsible for faithfully carrying out the interface’s complete Semantics. In the UML, you can model both interfaces and their implementa- tions, as shown in Figure 2-18, O aa Unknown Cae 'Spelling \ Figure 2-18: Interfaces And Implementations In this figure, there is one component named spel] ingwizard.dl11 that implements two. interfaces, [Unknown and I, Spelling. Almost every building block in the UML has this same kind of interface/imple- mentation dichotomy. For example, you can have use cases and the collabora- tions that realize them, as well as operations and the methods that implement them. Extensibility Mechanisms The UML provides a standard language for writing software blueprinty, but it is not possible for one closed language to ever be sufficient to express all possible nuances of all models across all domains across all time. For this reason, the UML is opened-ended, making it ‘possible for you to extend the language in controlled ways. The UML's exten- sibility mechanisms include '@ Stereotypes 7m Tagged values @ Constraints A stereotype extends the vocabulary of the UML, allowing you to create new guage, such as Java or C++, you will often want to model exceptions. In these Tanguages, exceptions are just classes, although they are treated in very spe “ways. Typically, you only want to allow themig be tense you only want to allow them to be thrown and caught, nothing _tlse. You can make exceptions first class citizens in your that they are treated like basic building blocks by appropriate stereotype, as for the class Over flow in Figure 2-19. mn Stereotype, as for the class OveSecTion 1 GETTING STARTED. — pjects are scussed in hapter 13. adorned to indi i 2-16 she notation. For example, Figure @ BotBpstract class with two public, One protected. a en Transaction Lat eoashaeloel 2 ctl + execute() + roliback() # priority() = timestamp() abe itat Figure 2-16: Adornments Every element in the UML’s notation starts with a basic symbol, to which can bbe added a variety of adornments specific to that symbol. n Divisions In modeling object-oriented systems, the world often gets divided in at least a couple of ways. First, there is the division of class and object. A class is an abstraction; an abject is one conerete manifestation ofthat abstraction, In the UM, you can “ode classes as well ak objects as shown in Figure ?-17- van: Customer Customer name : address. Customer phone oF Elyse Figure 2-17: Classes And Objects In this fij there i: jee, Rue: there is one class, named Customer, together with three Teastomer Gh ms ee es licitly as being a Customer object), Specification is mato ee tS comer object), and Elyse (which in its as bei shown explicitly here) ing akind of Customer object, all ough it’s not 7 ; : is this same kit ~xample, you ean have use cases and use Ras i eat instances, nodes and node inst . linguishes an object by using the s object’s nane: sand soon. class and th on I then si ‘ame symbol as its private operation. Intertac discuss Chapteates and her adorn yents are iscussed in chapter 6. < 4 Salles CHaPTER2 — INTRODUCING THE UML 49, Common M i i lechanisms in the UML A building is made simpler and more har ‘monious by the conformance to a pat- tern of common features. A house may Ke a \ be built in the Victorian or French country style largely by using certain architectural patterns that define those styles. The same is true of the UML. It is made simpler by the presence of four common m }echanisms that apply consistently throughout the language. 1. Specifications 2. Adornments 3. Common divisions 4, Extensibility mechanisms Specifications ‘The UML is more than just a graphical language. Rather, behind every part of its graphical notation there is a specification that provides A textual statement of the syntax and semantics of that building block. For example, behind a class icon is a specification that provides the full set of altibuiss, operations Grluding ictal sieeatine oad tekstas tar that the ‘class embodies; visually, that class icon might only show a small part of this specificationd Furthermore, there might be another view of that class that pre- ‘Sents a completely different set of parts yet is still consistent with the class’s underlying specification! You use the UML's graphical notation to visualize a system; you use the UML's specification to state the system’s details. Given Fcapotiiza meee bald up a model incrementally by drawing diagrams and then sing semantics to the model’s specifications, or directly by creating a specification, perhaps by reverse ei oberg sual ay poten Creating diagrams that are projections into those specifications. The UML's specifications provide a semantic backplane that contains all the parts of all the models of a system, each part related to one another in a consis- tent fashion. The UML’s diagrams are thus simply visual projections into that backplane, each diagram revealing a specific interesting aspect of the system. Adornments Most elements in the UML have a unique and direct graphical ‘polation that provides a visual representation of the most important aspects of ‘the clement. For example, the notation for a class is intentionally designed © ‘Be easy to draw, because classes are the most common element f mod- ling object-oriented systems {The class notation also exposes the most impor tant aspects of a class, namely its name, attributes, and op AA class's specification may include other details, such as whether iti* or the visibility of its attributes and operation’ Many of tnese details £207 ~ ree ular rendered as graphical or textual adomments to the class'> basic ees