RUT - Development manual

Transcription

1 LiTH RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 Reée Lidkvist Johasso, 2005 Abstract This documet presets a case study of fudametals of UML otatio, i particular, Use Case ad Class diagrams. A Olie Hotel Reservatio system was chose as a sample project. The case study begis with the project requiremets ad the explais the otatio of UML for modelig use cases ad classes. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 1

2 Field of applicatio 1 Field of applicatio Uified Modelig Laguage (UML) is a accepted stadard of the Objected Maagemet Group (OMG), which is also the home of Commo Object Request Broker Architecture (CORBA), the leadig idustry stadard for distributed object programmig [4]. UML defies twelve types of diagrams, divided ito three categories. These categories are: Structural diagrams iclude the Class diagram, Object diagram, Compoet Diagram ad Deploymet diagram. Behavior diagrams iclude the Use Case diagram, Sequece diagram, Activity diagram, Collaboratio diagram, ad Statechart diagram. Model maagemet diagrams iclude Packages, Subsystems ad Modules. I this documet readers will be itroduced to Use Case Diagrams ad Class Diagrams. 2 Prerequisites The basic kowledge of object-orieted desig ad aalysis could be helpful i the uderstadig of this RUT. No prior experiece with UML is required as this case study presets oly the fudametal cocepts of this powerful modelig laguage. 3 Realizatio 3.1 Sample project requiremets As a software developmet team we were assiged a task to develop a ew Olie Hotel Reservatio System for a customer who has may hotels i differet coutries. They are ot satisfied with a existig system ad would like to have the hotel reservatio service olie for cliets ad i additio to that allow travel agecies to make reservatios through this system. I particular: The cliet shall be able to browse hotels ad hotel iformatio like room types, livig cost, available hotel facilities, ad room availability. The cliet shall be able to make reservatio of oe or several rooms of a particular type, for oe or several persos. After the reservatio is doe the cliet shall be able to proceed with a paymet. Paymet by credit cards should be possible. The cliet shall be able to cacel the whole reservatio or a part of the booked rooms, ad also to update a existig reservatio. If cacellatio or update of the reservatio was doe ad paymet was received, a excess amout should be paid back. Registered travel agecies shall be allowed to process reservatios. 2 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

3 Realizatio The receptioist ad the hotel admiistrator are allowed to access this system with additioal rights. The receptioist of a hotel shall be able to make/update/cacel reservatios ad exted reservatios, which may require a additioal paymet. The hotel admiistrator has the same rights as a receptioist ad i additio shall be able to update hotel iformatio. 3.2 Use case diagram Use case diagrams shows the relatioships amog use cases withi a system or sematic etity ad their actors. A use case diagram is a graph of actors, a set of use cases, possibly some iterfaces, ad the relatioships betwee these elemets. The relatioships are associatios betwee the actors ad the use cases, geeralizatios betwee the actors, ad the geeralizatios, exteds, ad icludes amog the use cases. The use cases may optioally be eclosed by a rectagle that represets the boudary of the cotaiig system or classifier. [3] These relatioships will be discussed more below. It s comparatively easy to uderstad the diagram, eve without kowig the otatio. So, the captured model ca be discussed with a customer who may or may ot have kowledge of UML. Use Cases ca be applied to the whole system. They ca also be applied to a part of a system. I our case study we ll create oe Use Case diagram for the whole system to make the discussio lighter. Use case itroductio Use Cases were first itroduced by Ivar Jacobso i the early 1990s. He iveted Use Cases as a way of collectig ad orgaizig requiremets for a telephoe switch. Use cases allow us to capture the iteded behavior of the system, without specifyig how this behavior should be implemeted. I use cases we cocetrate o user s roles ad tasks that will allow us better uderstad what is required by the customer ad by system s ed users. Thus, use cases help us to capture the fuctioal requiremets. Use cases ca help pla the developmet process. They ca be also prioritized accordig to their priority ad complexity. Aother usage of use cases is a validatio of architecture ad developed system if it coforms to the requiremets. Use Case A use case, show as a ellipse cotaiig the ame of the use case, represets a kid of task which has to be doe with support from the system. From the perspective of a actor, a use case does somethig that s of value to a actor. Use case diagram shows oly a small part of the iformatio about the use case, the details should also be described i text. A extesio poit is a referece to oe locatio withi a use case at which actio sequeces from other use cases may be iserted. Each extesio poit has a uique ame withi a use case, ad a descriptio of the locatio withi the behavior of the use case. Extesio poits may be listed i a compartmet of the use case with the headig extesio poits. The descriptio of the locatios of the extesio poit is give i a suitable form, usually as ordiary text, but ca also be give i other forms, like the ame of a state i a state machie, or a precoditio or a postcoditio. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 3

4 Realizatio Actor A actor, usually show as a stick perso with the ame of the actor below the figure, represets a particular user role, rather tha represetig a particular idividual. A actor is somethig exteral to the system ad may be cosidered to play a separate role with regard to each use case with which it commuicates. The two graphical elemet types, use case ad actor, preseted i use case diagrams is show i figure 1. Figure 1. A Actor ad a Use Case. Associatio So, a use case diagram shows actors, use cases, ad lies called associatios, coectig a particular actor to a use case if the actor performs a particular task represeted by the use case. A associatio betwee a actor ad a use case is show as a solid lie betwee the actor ad the use case. This is show i figure 2. It may have ed adormets such as multiplicity. Figure 2. Associatio betwee Actor ad Use Case. Exted A exted relatioship from use case A to use case B idicates that a istace of use case B may be augmeted (subject to specific coditios specified i the extesio) by the behavior specified by A. The behavior is iserted at the locatio defied by the extesio poit i B, which is refereced by the exted relatioship. A exted relatioship betwee use cases is show by a dashed arrow with a ope arrow-head from the use case providig the extesio to the base use case. The arrow is labeled with the keyword «exted». Geeralizatio The relatio betwee use cases or betwee actors is called geeralizatio. A geeralizatio from use case C to use case D idicates that C is a specializatio of D. A geeralizatio from a actor A to a actor B idicates that a istace of A ca commuicate with the same kids of use-case istaces as a istace of B. 4 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

5 Realizatio A geeralizatio betwee use cases (actors) is show by a geeralizatio arrow; that is, a solid lie with a closed, hollow arrow head poitig at the paret use case (more geeral actor). Iclude A iclude relatioship from use case E to use case F idicates that a istace of the use case E will also cotai the behavior as specified by F. The behavior is icluded at the locatio which defied i E. A iclude relatioship betwee use cases is show by a dashed arrow with a ope arrow-head from the base use case to the icluded use case. The arrow is labeled with the keyword «iclude» (<<iclude>> is called a stereotype. There are may predefied stereotypes i UML stadard. For more iformatio see [1] ). Use Case Diagram of the Olie Hotel Reservatio System If we go through the requiremets of Olie Hotel Reservatio System we ca easily determie all Actors that perform tasks i this system. These are Cliet, Travel Aget, Hotel Receptioist ad Hotel Admiistrator. They are show o figure 3 below. Figure 3. Actors i the Olie Hotel Reservatio System. The relatio betwee the Hotel Receptioist ad Hotel Admiistrator is a geeralizatio. So, whatever Use Cases are specified for Hotel Receptioist they are also associated with the Hotel Admiistrator. A geeralizatio ca, as metioed before, be used for use cases. Like o the followig sample diagram i figure 4, where child use-cases are more specialized versios of its paret. Figure 4. Geeralizatio for Use Cases. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 5

6 Realizatio The ext step is to determie use cases ad associatios with actors. I figure 5 the use case diagram created durig the first iteratio of requiremet aalysis is show. It does t require ay explaatio. Figure 5. Use Case Diagram created durig the first requiremets aalysis. After more detailed aalysis of requiremets we ca otice that Paymet procedure is coected to Reservatio ad Reservatio Extesio procedures. We ca deduce that they share oe commo task or use case Pay for Hotel. I figure 6 ca we see how UML provides the special otatio to show how oe Use Case ca reuse aother with <<iclude>>. Sometimes a use case may icorporate two or more differet scearios that is several differet thigs may happe depedig o circumstaces. For example, i Pay for Hotel use case the Cliet may choose paymet by credit card, which will require differet steps to be performed. We ca regard Pay by Credit Card as a extesio to Pay for Hotel. For such cases you ca use the <<exted>> stereotype. But, compare to <<iclude>>, i <<exted>> arrow goes from the exceptioal case to the ormal case. The coditio at which the extesio is performed ca be also show o the diagram ad is a extesio poit. 6 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

7 Realizatio The diagram preseted i figure 6 o page 7 cotais almost all features provided by UML for use case modelig. Use cases o this diagram are put iside the rectagle amed Olie Hotel Reservatio System. Such a rectagle is called a system boudary i UML laguage. Figure 6. Use Case Diagram after detailed aalysis of the requiremets. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 7

8 Realizatio 3.3 Class Diagram Class diagrams show the static structure of the model, i particular, the thigs that exist (such as classes ad types), their iteral structure, ad their relatioships to other thigs. A class diagram is a graph of Classifier elemets coected by their various static relatioships. Note that a class diagram may also cotai iterfaces, packages, relatioships, ad eve istaces, such as objects ad liks. [3] Itroductio to classes Classes are the most importat buildig block of ay object-orieted system [1]. A class is a descriptio of a set of objects with similar structure, behavior, ad relatioships [3]. The objects share the same attributes, operatios, relatioships, ad sematics [1]. Classes are used to capture the vocabulary of the system you are developig. These classes may iclude abstractios that are part of the problem domai, as well as classes that make up a implemetatio. Classes ca be used to represet software, hardware, ad eve thigs that are purely coceptual. [1] Well-structured classes have crisp boudaries ad form a part of a balaced distributio of resposibilities across the system. [1] To give you more uderstadig we will first show you a class diagram ad the explai the differet elemets. Class Diagram of the Olie Hotel Reservatio System The sample class diagram of the Olie Hotel Reservatio System is preseted o the ext page. This diagram icludes the most useful UML elemets for class modelig. The preseted model is just oe example how the Olie Hotel Reservatio System ca be modeled. 8 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

9 Realizatio Figure 7. Sample class diagram of the Olie Hotel Reservatio System. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1 9

10 Realizatio Class Graphically, a class is redered as a rectagle with three compartmets separated with horizotal lies [3]. The top compartmet is used for displayig the ame of the class, which represets a text cosistig of ay umber of letters, umbers ad certai puctuatio marks. I practice class ames are short ous or ou phrases draw from the vocabulary of the system s domai. The ext two compartmets are used for listig attributes ad operatios of the class. Either or both of these two compartmets may be suppressed. A separator lie is ot draw for a missig compartmet. I figure 8 shows some differet represetatios of this with the class Hotel. Figure 8. Differet graphical represetatios of the class Hotel. Visibility Oe of the most importat details that ca be specified for attributes ad operatios is its visibility. I the UML, you ca specify ay of three levels of visibility: public - ay outside class ca access a attribute or operatio; specified by prepedig the symbol +. protected - ay descedat of the class ca access a attribute or operatio; specified by prepedig the symbol #. private - oly the class itself ca access a attribute or operatio; specified by prepedig the symbol -..package - the classes withi the same package ca access a attribute or operatio; specified by prepedig the symbol ~ If the visibility is abset, public is the default value. It is importat to hide all implemetatio details ad expose oly those features that are ecessary to carry out the resposibilities of a class. Attributes A attribute is a amed property of a class that describes a rage of values that istace of the property may hold. A class may have several attributes or o attributes at all. Attributes may be draw showig o their ames or ames ad other descriptios of a attribute like visibility, type, multiplicity ad iitial value. I practice, a attribute ame is 10 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

11 Realizatio short ou or a ou phrase. Typically, you capitalize the first letter of every word i a attribute ame except the first letter, as i area or roomid. A example of a class ad attributes is give i figure 9. Figure 9. Attributes of the class Room. I its full form, the sytax of a attribute i the UML is: visibility ame : type-expressio [multiplicity orderig] = iitial-value {property-strig} For example, see table 2: [3] Tabell 1: Legal attribute declaratios Example Descriptio origi +origi origi: Poit ame : Strig [0..1] origi : Poit = (0,0) id : Iteger {froze} ame visibility, ame ame, type ame, type, multiplicity ame, type, iitial value ame, property The froze property strig, specified i the last declaratio example, idicates that the attribute s value may ot be chaged after the object is iitialized. So, this property ca be used for modelig costats. Operatios A operatio is the implemetatio of a service that ca be requested from other objects. Ofte, ivokig a operatio o a object chages the object s date or state. It s importat ot to cofuse operatio ad a method. Method is a implemetatio of a operatio. I case of class ad descedat class hierarchy, there may be several methods for the same operatio implemeted at differet hierarchy level. Durig ru time the proper method is chose. A class may have ay umber of operatios or o operatios at all. The ame of a operatio is usually a verb or verb phrase that represets behavior of its eclosig class. Typically, you capitalize the first letter of every word i a operatio ame except the first letter, as i book() or coutrooms(). Operatio sigature cotais parameter ames, type, default values ad retur type i case of a fuctio. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

12 Realizatio A example of the operatios i a class is give i figure 10. Figure 10. Operatios of the class Hotel. I its full form, the default sytax of a operatio i the UML is: visibility ame ( parameter-list ) : retur-type-expressio { property-strig } For example, the followig are all legal operatio declaratios: Tabell 2: Legal operatio declaratio Example Descriptio coutrooms ame + coutrooms visibility, ame pay (amt: Float) coutrooms() : Iteger ame, parameters ame, retur type I operatio s sigature, zero or more parameters may be provided, each of which follows the sytax: kid ame : type-expressio = default-value Kid may be ay of the followig values: i - a iput parameter, may ot be modified. out - a output parameter, may be modified to commuicate iformatio to caller. iout - a iput parameter may be modified. If the descriptio kid is abset, the parameter i is the default value. The descriptio of property strigs for attribute declaratio is ot give i this RUT. Iterfaces ad Abstract classes A Iterface is collectio of operatios that oly specifies a particular service of a class, providig o implemetatio. Oly a class or classes which realize this iterface implemet its operatios. Each class may realize may differet Iterfaces, thus providig implemetatio of differet services. Iterface ca be regarded as a cotract which specifies that all operatios defied i Iterface must be implemeted by subclasses. 12 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

13 Realizatio Abstract classes, o the other had compare to Iterfaces, may cotai attributes ad provide some implemetatio. Both iterfaces ad abstract classes ca ot be istatiated. There are two ways to represet Iterfaces o UML diagram. Oe form is a simple form which provides o iformatio about its operatios ad aother oe allows us to visualize the cotet of a iterface. I the simple form realizatio betwee subclass ad iterface is redered as a solid lie, i expaded form as a dashed directed lie with a large ope arrowhead poitig to the iterface. The figure 11 ad figure 12 represet two forms of Iterface specificatio. Figure 11. Simple form to represet a Iterface. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

14 Realizatio Figure 12. Expaded form to represet a Iterface. Sice abstract classes are ot show o the class diagram of Olie Hotel Reservatio System lets model a part of the model, which is represeted by Bookig iterface, by meas of abstract classes. So, we could have a abstract class BookigOperator, which would cotai two abstract operatios dobookig() ad cacelbookig(), ad other operatios that could be shared by all subclasses, for istace geeral purpose createbookig() ad removebookig() operatios. Oly abstract operatios would be implemeted i its ow way i subclasses Cliet, TravelAget ad Employee. The followig figure shows how this example could be represeted i UML. 14 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

15 Realizatio Figure 13. Example of abstract classes. Associatios Associatios represet structural relatioships betwee objects. For example, each room (Room) i a hotel has a particular type (RoomType) or a room was booked (RoomBookig) for several persos (Perso). Give a associatio coectig two classes, you ca avigate from a object of oe class to a object of the other class, ad vice versa. A example of this is give i figure 14. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

16 Realizatio Figure 14. Example of associatios. A associatio ca have a ame (e.g. book for ), which could describe the ature of the relatioship. But sometimes, istead of associatio ame, it s more appropriate to use role ames for relatioship participats. I other words, you ame which role a particular class plays i relatioship. The same class ca play the same or differet roles i other associatios. A example of this is give i figure 15. Figure 15. Associatio with role ames for the relatioship participats. It s importat to state how may objects may be coected across a istace of associatio. This how may is called the multiplicity of a associatio. Whe you state a multiplicity at oe ed of a associatio, you are specifyig that, for each object of the class at the opposite ed, there must be that may objects at the ear ed. You ca show a multiplicity of exactly oe (1), zero or oe (0..1), may (0..*), or oe or more (1.. *). You ca eve state the exact umber, for example 3. O our diagrams is used istead of *. As metioed above, a associatio is a relatioship which specifies that objects of oe thig are coected to objects of aother. For example, there is a oe to may relatioships betwee Cliet class ad HotelBookig class. If we wat specify that Cliet objects are oly accessed through HotelBookig ad we ca t get HotelsBookig object through Cliet object, the we should use associatio avigatio. To specify associatio avigatio we just ador associatio with a arrowhead poitig to the directio of traversal as i figure 16. If o avigatio is specified for associatio the bidirectioal avigatio is assumed. 16 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

17 Realizatio Figure 16. Associatio avigatio. Aggregatio ad Compositio Aggregatio is a special kid of plai associatio. I plai associatio all participats are coceptually at the same level, while a aggregatio represets a associatio betwee peers whe oe larger thig, the whole, cosists of smaller thigs, the parts. It s so called whole/part relatioship. For example, the relatioship betwee computer keyboard ad computer could be modeled as aggregatio. It meas that a keyboard is part of computer. At the same time a object Keyboard ca exists idepedetly, without beig a part of Computer object. Sometimes difficulties may rise whe we cosider usig aggregatio or plai associatio betwee classes. As a example, cosider the relatioship betwee hotel ad its employees. Is employee a part of orgaizatio or compay? Some people say yes ad some o. I our example this case is modeled usig aggregatio to show that Hotel is orgaizatioally superior to Employee ad that they are ot at the same level. Graphically aggregatio is represeted by adorig a plai associatio with a ope diamod at the whole ed as show o figure 17 below. Figure 17. Aggregatio. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

18 Realizatio Compositio is a form of aggregatio with some importat sematics. Accordig to the composite aggregatio, a object may be a part of oly oe composite at a time. I additio, the composite is resposible for the creatio ad destructio of its parts. This meas that whe we destroy the composite all its parts are also destroyed. For example, cosider relatioship betwee Hotel ad Facility objects. I our system facilities like swimmig pool, saua, etc. ca t exist without beig a part of a hotel. Whe a Hotel object is removed all facilities of it should be also removed. Besides that, a swimmig pool ca t belog to several hotels at the same time. So, there is a composite relatioship betwee Hotel ad Facility classes. The same logic ca be applied to the Hotel ad Room relatioship. As the figure 18 below shows, compositio is specified by adorig a plai associatio with a filled diamod at the whole ed. Figure 18. Compositio. Geeralizatio A geeralizatio is a relatioship betwee a geeral thig, which is called super-class or paret, ad a more specific kid of that thig, called subclass or child. Geeralizatio meas that objects of the child may be used aywhere the paret may appear, but ot the reverse. Participatig i geeralizatio, a child iherits the properties of its parets, especially their attributes ad operatios. I additio to that, a child may have its ow attributes ad operatios or have paret operatios overridde (so called polymorphism). Graphically, geeralizatio is redered as a solid directed lie with a large ope arrowhead, poitig to the paret. This is show i figure RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

19 Realizatio Figure 19. Geeralizatio. Qualified associatios Cosider the relatioship betwee Hotel ad Room classes, which could be modeled usig a compositio as i figure 20 below. This relatioship would tell us that Room objects are part of a Hotel object ad that they could t exists idepedetly. Figure 20. Relatio betwee Hotel ad Room modeled by compositio. As you could metio there is o iformatio about how the Room objects could be accessed or idetified from the Hotel object. UML laguage provides the special otatio for specificatio of lookup qualifiers. For example, a uique room umber could be used to locate a Room object as show o the figure below. Such kid of associatio is called a qualified associatio. Figure 21. Relatio modeled with Qualified associatios. Cosider aother example. If we would like to model a chessboard, which is divided by squares, ad each square is idetified by row ad colum idexes, the we would have probably represeted it i the followig way. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

20 Realizatio Figure 22. Model of a chessboard represeted with Qualified associatios. Associatio classes I associatio betwee two classes, the associatio itself might have properties. For example, i relatioship betwee a Hotel ad a RoomType, there is a RoomRate that represets the properties of that relatioship, i particular, rates ad discouts for each room category i a hotel. This example is modeled i figure 23. Figure 23. Example of associatio class betwee two classes. Depedecy Whe a class uses aother class ad so is depedet of that class we have a depedecy relatioship. The depedet class does t have a referece to the other class. Ofte the class has temporary referece to other class through a parameter i a method call. Graphically a depedecy relatioship is represeted by a dashed arrow with a ope arrowhead from the depedet class. Depedecy relatioship is ot represeted i the Olie Hotel Reservatio System diagram so here we give aother example by extedig the diagram slightly: cosider a factory that is resposible for the creatio of ew Hotel objects. The factory just creates ew istaces of the Hotelclass but does t keep a referece to them. The depedecy relatioship is show i figure 24. Figure 24. Depedecy relatioship. Stereotypes The Olie Hotel Reservatio System case does t iclude ay stereotypes i it s origial form. But sice stereotypes ca be very useful they are described here ad proposals 20 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

21 Realizatio how they could be used i the class diagram of the Olie Hotel Reservatio System are give. Stereotypes are a way to clarify the defiitio of elemets i a UML diagram. Stereotypes are depicted as a keyword withi matched guillimets. This is the quotatio marks used i the Frech laguage ad ca also be represeted by two agle brackets. Example brackets: <<foo>>. Example Guillimets: «foo». Stereotypes ca be applied to classes, attributes, operatios ad associatios. Thus, it ca be applied to almost all elemets i UML where it is suitable. Stereotypes i classes ca be used to idicate the role of a class. I the class diagram of the Olie Hotel Reservatio System you could add stereotypes to some classes to achieve this. Let s say for example that we wat to clarify that the classes RoomRate ad RoomBookig are class associatios. The we ca add stereotypes to this classes that idicate that they are associatio classes. I figure 25 this stereotype is added to class RoomRate. Figure 25. Stereotypes used to clarify the role of a class. Stereotypes ca also be useful to idicate the type of depedecy relatioship betwee two classes. I the example with the factory that is resposible for the creatio of Hotels we could add a stereotype to describe the depedecy. This is show i figure 26 below. Figure 26. Stereotype i a depedecy relatioship. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

22 Realizatio Operatios ad attributes ca also be give stereotypes to idicate what type of operatio or attribute it is. The operatios i the Hotel class i the class diagram could use stereotypes to idicate whether they modify the values of the attributes of their objects or ot. A example of this is show i figure 27. Figure 27. Stereotypes used to clarify attributes of the Hotel class. 22 RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1

23 Results 4Results 5 Templates ad forms 6 Verificatio of results 7 Examples with explaatios 8 Solutios to commo problems 9 Adjustmets to the PUM-course 10 Measuremet of the process 11 History of the process Ver Chages from previous versio Editor Examiatio/ Decisio Start date 0.1 New RUT David Akhvlediai 0.2 Layout update. Emil Carlsso Not ispected Not ispected Added sectios of stereotypes ad depedecy relatioship. 1.1 Chaged ad added text i ch Some laguage correctio Emil Carlsso Reée Lidkvist Johasso Not ispected Not ispected Chages ot yet atteded to Laguage correctio. Ispectio. Descriptio of realizatio relatioship is missig. RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v

24 Refereces 13 Refereces [1] Grady Booch,James Rumbauch, Ivar Jacobso The Uified Modelig Laguage Users Guide, 1999 [2] Marti Flower UML Distilled, 1997 [3] Grady Booch, James Rumbauch, Ivar Jacobso OMG Uified Modelig Laguage Specificatio, 2003 [4] wathis.com (2005). Uified Modelig Laguage - a Whatis.com defiitio RUT - Developmet maual 7.20 UML Case Study - Use case ad class diagrams v 1.1