3.2 Static Model Creation

Transkript

1 3.2 Static Model Creation Seite 22 nput Use case model Description of the problem Expert knowledge from the are of the problem General knowledge Goal: Creation of a class diagram (first without operations) Strategy (according to OMT). dentify classes 2. dentify associations 3. dentify attributes 4. ntroduce inheritance 5. Restructure the model

2 3.2. dentification of classes Seite 23 Candidates are Persons or roles (e.g., student, employee, client,...) Organisations (e.g., firm, section, university,...) tems (e.g., article, car, house,...) Concepts (e.g., order, lecture, contract,...). Step: collect candidates Approach: search for nouns in the use cases.

3 2. Step: drop unsuited classes drop criteria: Seite 24 redundant classes irrelevant classes vague classes attributes or attribute values operations 3. Step: add missing classes criteria for missing classes: attributes from step 2 which are not covered by classes yet expert knowledge from the problem area

4 Example ATM:. Step: Collect nouns in the primary scenario of the use case Draw money at ATM Seite 25 Client Card ATM PN User Code Number Consortium Bank Choice Draw, Deposit, Transaction, Statement Amount Bounds Transaction Completion Execution Request Balance Money Receipt Credit

5 2. Step: drop unsuited classes Seite 26 Client Amount (attribute) Card Bounds (attribute) ATM Transaction PN (attribute) Completion (activity) User (redundant) Execution (activity) Code (attribute) Request (activity) Number(attribute) Balance (attribute) Consortium Money (irrelevant) Bank Receipt (vague) Choice (attribute) Credit(redundant) Draw, Deposit, Transaction, Statement (attribute values of choice)

6 3. Step: add missing classes Seite 27 Account (is implied by the balance attribute) Teller Terminal Tellertransaction Outtransaction (instead of choice)

7 3.2.2 dentify Associations Seite 28 Candidates are physical or logical connections with a certain duration like conceptional connections (works for, is employee of...) property (has, is contained in,...) several objects work together on the same task

8 . Step: collect candidates Approach: check for Seite 29 verbs genitive (client s credit card) possessive pronouns (his credit card) Note: verbs describe also activities (e.g., the ATM checks the PN) many objects within a sentence can indicate a frequent cooperation which is based on a association (e.g., the ATM delegates the bank code to the consortium) associations are in general harder to determine than classes. Expert and general knowledge are important.

9 Example ATM: Seite 30 The client has a credit card (... his/her credit card...) The consortium has an ATM (... ATM delegates...) The consortium consists of banks (... delegates to the bank...) The bank keeps accounts (Knowledge) Aclienthasaccounts(Knowledge)

10 2. Step: drop unsuited associations Renounce derivated associations if possible. Example ATM: Seite 3 Kunde hat.. Konto greiftzu 0.. Kreditkarte /besitzt abgeleitete Assoziation, die NCHT in das statische Modell der Analyse aufgenommen werden soll! 3. Step: add missing associations 4. Step: add perhaps multiplicities and role names Remark One can postpone the definition of tricky multiplicities to a later stage.

11 Example ATM: First class diagram Seite 32 Konsortium 0.. bestehtaus Bank führt.. Konto hat Kunde besitzt beschäftigt Kassierer eingegebenvon besitzt Kassen terminal eingegebenan Kassierer transaktion betrifft ATM eingegebenan Aussen transaktion betrifft greiftzu 0.. zugelassendurch Kredit karte

12 3.2.3 dentify Attributes Seite 33 Guideline Only attributes which are relevant for the application (knowledge important) No attributes which has objects as values (use associations for this) Attribute types can be omitted at this stage Example ATM: The primary scenario of the use case Draw Money at ATM leads to the following attributes blz is an attribute of Bank and Kreditkarte (Card) kartennr, geheimzahl are attributes of Kreditkarte form, datum and betrag are attributes of Kassierertransaktion (Tellertransaction) and Aussentransaktion (Outtransaction) grenzen is an attribute of ATM saldo is an attribute of Konto (Account)

13 Example ATM: Class diagram with attributes Seite 34 Konsortium 0.. bestehtaus führt.. Bank Konto hat Kunde name blz name beschäftigt kontonr saldo kreditrahmen name adresse besitzt Kassierer name eingegebenvon besitzt Kassen terminal eingegebenan Kassierer transaktion betrifft nr form datum betrag ATM nr geldvorrat grenzen eingegebenan Aussen transaktion form datum betrag betrifft zugelassendurch greiftzu 0.. Kredit karte blz kartennr geheimzahl gesperrt

14 3.2.4 ntroducing nheritance Seite 35 Mainly generalisation Collect common properties of existing classes (attributes, associations) in asuperclass. Specify which classes are abstract. Example ATM: Aussentransaktion and Kassierertransaktion have the same attributes and acommonassociationtoaccount. ) Generalisation to an abstract class Transaktion. ATM and Kassenterminal can be generalised to the (abstract) class Terminal.

15 Example ATM: Class diagram with inheritance Seite 36 Terminal {abstract} eingegebenan Transaktion {abstract} betrifft nr form datum betrag ATM geldvorrat grenzen Kassen terminal Kassierer transaktion Aussen transaktion besitzt besitzt eingegebenvon Konsortium 0.. bestehtaus Bank beschäftigt Kassierer zugelassendurch name blz name name führt.. hat Konto kontonr saldo kreditrahmen Kunde name adresse Kredit karte blz kartennr geheimzahl gesperrt greiftzu 0..

16 3.2.5 Restructuring the model Seite 37 Questions Any classes or associations missing? Any superfluous classes or associations? Any wrong associations or attributes? Qualifier for associations? Types of the attributes? Missing multiplicities? Example ATM: Atransactionswhicha ectstwoaccounts ) introduce the class Aktualisierung. Acreditcardisapieceofplastic.Thecorrespondingobjectstores therefore neither the PN (geheimzahl) nor the bankcode (blz). (redundant) Use qualifiers for the associations between Konsortium und Bank and between Bank and Konto.

17 Example ATM: Restructured class diagramm Seite 38 Terminal {abstract} nr: nteger eingegebenan Transaktion {abstract} form: String datum: Date bestehtaus..2 Aktualisierung art: String betrag: Real ATM geldvorrat: Real grenzen: Real Kassen terminal Kassierer transaktion Aussen transaktion besitzt besitzt eingegebenvon Konsortium name: String blz: nteger 0.. bestehtaus 0.. Bank name: String blz: nteger beschäftigt kontonr: nteger Kassierer name: String zugelassendurch betrifft führt 0.. Konto kontonr: nteger saldo: Real kreditrahmen: Real.. hat Kunde name: String adresse: String Kredit karte kartennr: nteger gesperrt: Boolean greiftzu 0..

18 Conclusion of Section 3.2 Seite 39 The static model describe the structural and data orientated aspects of a system. The static model is given by class (and object) diagrams. The steps in the development of a static model are: dentify classes dentify associations dentify attributes ntroduce inheritance Restructure the model

19 3.3 Modelling of nteractions Seite 40 nteraction = specific pattern of cooperation and communication between objects for the solution of a task (e.g., use case). Goal: Conception of a set of interaction diagrams for each use case. We distinct between to kinds of interaction diagrams. Sequence diagrams Communication diagrams

20 3.3. Sequence diagrams Seite 4 Describe the messaging behaviour of objects over time (i.e, send and receive). sd Name rolle:typ rolle2:typ2 rolle3:typ3 op() op2() op3() Zeit op4() Note: Receiving is an event. Sending is an action.

21 Activation The time interval in which an object is active because it performs something; it is waiting for the completion of an activity of another object which received a (synchronous) message. Seite 42

22 Asynchronous Messages and Parallel Executions Seite 43 rolle:typ rolle2:typ2 rolle3:typ3 asynchrone Nachricht synchrone Nachricht The sending object continues its processing after sending an asynchronous message (i.e., it works in parallel with the receiver).

23 Alternatives Seite 44 rolle:typ rolle2:typ2 op(x) alt [x>0] op() [else] op2()

24 Example: Sequence diagram for Preparation of Delivery Seite 45 UML 2.0 sd Lieferung vorbereiten :Auftrag erfassungsfenster :Auftrag :Auftragsposition :Lagerartikel bereitevor() loop (für alle Auftragspositionen) bereitevor() vorhanden = prüfe() Lebenslinie alt [vorhanden] entnehmen() nachzubestellen = nachbestellungnotwendig() Rückkehr Selbstdelegation [nachzubestellen] new() :Nach bestellartikel neu erzeugtes Objekt new() :Lieferartikel

25 Typical structures of sequence diagrams Seite 46 Centralised structure ( Fork ) :Typ :Typ2 :Typ3 :Typ4 :Typ5 An object controls the other objects (and is responsible for the correct execution).

26 Decentralised structure ( Stair ) Seite 47 :Typ :Typ2 :Typ3 :Typ4 :Typ5 Each object is responsible for the correct execution.

27 3.3.2 Communication diagrams Seite 48 Highlight the structural relations (temporal and permanent) of all objects which work on an interaction. The time is given by an enumeration of the messages (we use..,.2. for nested messages). : op(x) rolle.: op2() rolle2.2: op3() rolle3 Remark The links in the communication diagrams are instances of associations and temporal relations.

28 Example: Communication diagram for Preparation of Delivery Seite 49 :Auftragserfassungsfenster : bereitevor() :Auftrag..2.: nachzubestellen = nachbestellungnotwendig(). [für alle Auftragspositionen]: bereitevor() :Auftragsposition..: vorhanden = prüfe()..2 [vorhanden]: entnehmen() :Lagerartikel..3 [vorhanden]: new()..2.2 [nachzubestellen]: new() :Lieferartikel :Nachbestellartikel Remark Sequence and communication diagrams express the same information in a di erent manner.

29 3.3.3 Creation of interaction diagrams Seite 50 nput use case descriptions (scenarios) static model Goal To model cooperation between objects from a use case with interaction diagrams. Strategy. dentify the messages which are exchanged and the objects which send and receive in a use case. 2. Construct interaction diagrams for each use case.

30 Possible Approaches: Seite 5 (A) We equip each scenario with its own interaction diagram. (B) Acomplexinteractiondiagram(withalternatives,iterations,...)which covers all scenarios of a use case Disadvantage: usually quite complex and large We focus on approach (A) and use sequence diagrams (SDs). Example: Use Case Draw Money at ATM We construct: a SD for the primary scenario a SD for the secondary scenario Credit Card Blocked a SD for the secondary scenario Transaction Failed

31 Seite 52 sd Geld am ATM abheben Benutzer :ATM :Konsortium :Bank Karte eingeben Geheimzahl erfragen Geheimzahl eingeben Karte lesen Geheimzahl lesen Geheimzahl überprüfen Karte überprüfen BLZ überprüfen Form erfragen "Karte ok" Karte bei Bank überprüfen "Karte ok" Kartennummer überprüfen Abhebung wählen Betrag erfragen Betrag eingeben Betrag lesen Grenzen überprüfen Geld ausgeben Transaktion verarbeiten "Transaktion erfolgreich" Banktransaktion verarbeiten "Banktransaktion erfolgreich" Konto aktualisieren zur Geldentnahme auffordern Geld entnehmen nach Fortsetzung fragen abschließen Beleg drucken Karte ausgeben zur Entnahme auffordern Karte und Beleg entnehmen zur Karteneingabe auffordern

32 Seite 53 sd Karte gesperrt Benutzer :ATM :Konsortium :Bank Karte eingeben Geheimzahl erfragen Karte lesen Geheimzahl eingeben Geheimzahl lesen Geheimzahl überprüfen Karte überprüfen BLZ überprüfen Meldung Karte gesperrt "Karte gesperrt" Karte bei Bank überprüfen "Karte bei Bank gesperrt" Kartennummer überprüfen Beleg drucken Karte ausgeben zur Entnahme auffordern Karte und Beleg entnehmen zur Karteneingabe auffordern

33 Seite 54 sd Transaktion gescheitert Benutzer :ATM :Konsortium :Bank Betrag eingeben Betrag lesen Grenzen überprüfen Meldung Transaktion gescheitert Transaktion verarbeiten "Transaktion gescheitert" Banktransaktion verarbeiten "Banktransaktion gescheitert" Konto aktualisieren Form erfragen Abhebung wählen Betrag erfragen

34 Conclusion of Section 3.3 Seite 55 nteraction diagrams describe the cooperation and communication between several objects. We distinct between sequence and communication diagrams (model time respectively structural behaviour). Amodelofinteractionsisbasedontheusecasedescriptionandthestatic model. A use case yields usually several interaction diagrams (each scenario induces one diagram).

35 3.4 Creation of State and Activity Diagrams Seite 56 Starting point: a set of SDs from use cases. Goal A state diagram for each class with interesting behaviour (i.e., the objects of the class have a non-trivial life cycle) Activity diagrams which describe the behaviour of operations Remark State and activity diagrams cover the complete behaviour of each object with respect to many scenarios. One can omit to introduce an activity diagram if the behaviour of the operation is already given by an interaction diagram.

36 Criteria for interesting object behaviour Seite 57 There is at least one event which may lead to di erent reaction, dependent on the state of the object. e/a e/a2 Z Z2 Z3 Example: setting up a digital clock At least one event will be ignored in certain states. Example: ATM Bereit Karte eingeben Karte gelesen Geheimzahl eingeben Typical state dependent objects are: control objects for use cases and client interfaces devices (video recorder, digital clock,...) objects with a limited capacity (full, empty,...)

37 State classification Seite 58 Astatewhichhasatleastoneactivityandcanbeexitedonly if a completion event occurs is called activity state. Astatewhichhasnoactivityiscalledstable state (or inactive state).

38 Guidelines for the construction of state diagrams Seite 59. Chose a SD which shows a typical interaction of an object from the class under study (usually the SD of the primary scenario). 2. Project the SD to the lifeline of the object 3. Construct a chain of states and transition from the lifeline of the object such that the intervals in which the object is inactive are modelled by stable states the activations of the object are modelled by activity states (the activity is modelled by local operations) arriving events are modelled by marked transitions from stable to activity states the completion of an activity is modelled by an completion event from an activity to a stable state 4. Express sequences which can be repeated by cycles. {a certainsdisprocessed,butwithoutdetalisationoftheactivationsyet}

39 5. Proceed as long as there are SDs of objects from the class under study as follows: choose such a SD and project it to the lifeline of the object find an activity state where the sequence di ers from the already inferred behaviour append the new sequence as an alternative to this state find (if possible) a stable state such that one can unify the alternative sequence with the already inferred state diagram {all SDs processed, but without detalisation of the activations yet} 6. Construct activity diagrams for local operations (those which are called in activity states, cf. step 3) Seite Refine perhaps the existing state diagram by adding conditions to the outgoing transitions of activity states {all SDs with all activations processed} 8. ntegrate (if needed) all secondary scenarios which has no SD yet.

40 Remark Seite 6 The steps -5 lead in general to non-deterministic state diagram. Step 7 leads then to a deterministic state diagram. A precise formalisation of the above algorithm may be found in R. Hennicker, A. Knapp: Activity-Driven Synthesis of State Machines. Konferenzband FASE 2007, Fundamental Approaches to Software Engineering, Springer Lecture Notes in Computer Science 4422, 87-0, 2007.

41 Example ATM: Seite 62 nteresting behaviour : ATM (state diagram) Operation : (activity diagram) ATM: local operations Consortium: check credit card process a transaction Bank: check credit card at the bank process a bank transaction

42 Construction of the ATM state diagram Seite 63. Choose SD for the primary scenario of Draw Money at ATM 2. Consider the lifeline of :ATM 3. Construct a chain of states and transactions which has an activity state after each client interaction 4. Loop at the state Bereit (ready) 5. ntegrate SD for Karte gesperrt (card blocked) ntegrate SD for Transaktion gescheitert (transaction failed) 6. Construct activity diagrams for the local operations which are called in the activity states 7. ntroduce conditions for the outgoing transitions of the above activity states 8. Refine the state diagram 9. ntegrate secondary scenarios which are not covered yet ( Abbruch, etc.)

43 State diagram of the ATM (after the steps -5) Seite 64 do/karteneingabe AuffordernActivity() Bereit Karte eingeben do/karteeinactivity() Karte und Beleg entnehmen Bereit zur Kartenentnahme Karte gelesen Geheimzahl eingeben do/abschlussactivity() do/geheimzahleinactivity() abschließen Geld entnommen Geheimzahl und Karte geprüft Abhebung wählen do/geldentnehmen Activity do/abhebungactivity() Geld entnehmen Transaktion durchgeführt do/betrageinactivity() Betrag eingeben Transaktionsform bestimmt

44 Seite 65 ad karteeinactivity check = kartelesen() [check = "lesbar" ] Geheimzahl erfragen return "Karte lesbar" [check = "nicht lesbar" ] Meldung Karte nicht lesbar abschlussactivity() return "Karte nicht lesbar" ad abschlussactivity Beleg drucken Karte ausgeben zur Entnahme auffordern

45 Seite 66 ad geheimzahleinactivity Geheimzahl lesen check = geheimzahlüberprüfen() [check = "Geheimzahl ok" ] check = konsortium.karteüberprüfen() [check = "falsche Geheimzahl" ] [check = "falsche BLZ" ] [check = "Karte ok" ] [check = "Karte gesperrt" ] Meldung falsche Geheimzahl Meldung falsche BLZ Meldung Karte gesperrt Form erfragen Geheimzahl erfragen abschlussactivity() return "Geheimzahl falsch" return "Karte nicht ok" return "Karte ok"

46 Seite 67 ad betrageinactivity Betrag lesen check = grenzenüberprüfen() [check = "Grenzen ok" ] check = konsortium.transaktionverarbeiten() [check = "Grenzen überschritten" ] [check = "Transaktion erfolgreich" ] [check = "Transaktion gescheitert" ] Meldung Grenzen überschritten Geld ausgeben Meldung Transaktion gescheitert Betrag erfragen zur Geldentnahme auffordern Form erfragen return "Grenzen überschritten" return "Transaktion erfolgreich" return "Transaktion gescheitert"

47 Seite 68 ad abhebungactivity Betrag erfragen ad geldentnehmenactivity nach Fortsetzung fragen ad karteneingabeauffordernactivity zur Karteneingabe auffordern

48 State diagram of the ATM (after steps 6-8) Seite 69 do/karteneingabe AuffordernActivity() Bereit Karte eingeben do/check = karteeinactivity() Karte und Beleg entnehmen [check = "Karte nicht lesbar" ] [check = "Karte lesbar" ] Bereit zur Kartenentnahme Karte gelesen Abbruch [check = "Geheimzahl falsch" ] Geheimzahl eingeben do/abschlussactivity() [check = "Karte nicht ok" ] do/check = geheimzahleinactivity() abschließen [check = "Karte ok"] Geld entnommen [check = "Transaktion gescheitert" ] Geheimzahl und Karte geprüft Abbruch Abhebung wählen do/geldentnehmen Activity() do/abhebungactivity() Geld entnehmen Transaktion durchgeführt [check = "Transaktion erfolgreich" ] do/ Betrag eingeben check = betrageinactivity() [check = "Grenzen überschritten" ] Transaktionsform bestimmt Abbruch

49 Activity diagrams for the operations of the consortium class Seite 70 ad karteüberprüfen check = blzüberprüfen() [check = "BLZ falsch" ] return "falsche Bankleitzahl" [check = "BLZ richtig" ] check = banken[blz].bankkarteüberprüfen() [check = "Karte bei Bank gesperrt" ] return "Karte gesperrt" [check = "Karte ok" ] return "Karte ok" ad transaktionverarbeiten check = banken[blz].banktransaktionverarbeiten() [check = "Banktransaktion erfolgreich" ] [check = "Banktransaktion gescheitert" ] return "Transaktion erfolgreich" return "Transaktion gescheitert"

50 Activity diagrams for the operations of the consortium bank Seite 7 ad bankkarteüberprüfen check = kartennummerüberprüfen() [check = "gesperrt" ] return "Karte bei Bank gesperrt" [check = "gültig" ] return "Karte ok" ad banktransaktionverarbeiten check = kontoaktualisieren() [check = "gescheitert" ] return "Banktransaktion gescheitert" [check = "erfolgreich" ] return "Banktransaktion erfolgreich" Remark The consistency of the diagrams with respect to each other can be checked easily.

51 Conclusion of Section 3.4 Seite 72 State and activity diagrams can be constructed systematically from the interaction model State diagrams are developed for classes which objects have a non-trivial life cycle We distinct between stable and activity states during the construction of state diagrams Activity diagrams are used to describe the behaviour of operations