Presentation is loading. Please wait.

Presentation is loading. Please wait.

 CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.

Similar presentations


Presentation on theme: " CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005."— Presentation transcript:

1  CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005

2 UML Overview2

3  CII Saxion Hogeschool Enschede 3 UML This is how the UML developers see their brain child: Unified Modeling Language specifying, visualizing, constructing documentingsoftware systems "The Unified Modeling Language (UML) provides system architects working on object analysis and design with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling."

4  CII Saxion Hogeschool Enschede 4 UML : What It Is …. A language for modeling systems : Mechanical systems, electronic systems Software systems A combination But also business processes A language that helps to cope with complexity of systems : Abstracts from uninteresting details Provides different, but related views Reveals large scale structure (architecture) A language that helps to develop software systems : Modeling the problem domain Specifying desired system behavior Describe implementation

5  CII Saxion Hogeschool Enschede 5 UML … What It Isn’t A description of a software development process ((R)UP is the “corresponding” process) A programming language (models are not always executable)

6  CII Saxion Hogeschool Enschede 6 10 50 The number of OO methods increased from 10 in 1989 …… … to more than 50 in 1994 The most notable (say popular) methods were : Booch's OOD Jacobson's OOSE Rumbaugh's OMT Fusion Shlaer-Mellor Coad and Yourdon No modeling language filled all needs completely UML History

7  CII Saxion Hogeschool Enschede 7 UML History Babylonian confusion: Everybody invents and speaks his own modeling language Everybody has a different understanding of modeling concepts Tools all use a different language or dialect Interchange of models is not possible OMT One popular language (and process) emerged: OMT (2) Grady Booch observed the need for an object esperanto! the three amigos A comedy acted out in real life: the three amigos Booch Jacobson, Rumbaugh Around 1994 Booch convinced the other two famous methodologists to join him at rational : Jacobson, Rumbaugh

8  CII Saxion Hogeschool Enschede 8 History UML Booch methodOMT Unified Method 0.8 OOPSLA ´95 OOSE Other Methods UML 0.9 Web - June ´96 public feedback UML 1.5 UML 1.0 UML 2.0 2005? 2003 UML approved by the OMG Nov ‘97

9  CII Saxion Hogeschool Enschede 9 OMG OMG stands for object management group, inc. (1989) International industrial consortium with over 800 members The OMG promotes object-oriented technology E.G. CORBA and UML The OMG wants to provide a framework for software development Stimulate growth of object technology Increase interoperability of software of different vendors Reducing confusion by setting standards

10  CII Saxion Hogeschool Enschede 10 Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks en patterns, HP Fusion Operation descriptions en message numbering Embley Singleton classes en high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Booch Booch methode Jacobson OOSE Contributions to UML

11  CII Saxion Hogeschool Enschede 11 UML and other OMG technologies

12  CII Saxion Hogeschool Enschede 12 UML Diagrams The UML is constructed specifically to enable modeling of objects, their structure, behavior and interaction. With the UML it is possible to : Use Case Diagrams Display the boundary of a system & its major modes of use as observed by external actors using Use Case Diagrams. Interaction Diagrams: Illustrate how particular use cases are realized through the interactions between objects in Interaction Diagrams: Sequence DiagramsSequence Diagrams; Communication DiagramsCommunication Diagrams. Class Diagrams Model the structure of objects with Class Diagrams. State machine Diagrams. Model individual object behavior with State machine Diagrams. ComponentDeployment Diagrams. Describe the physical implementation architecture with Component & Deployment Diagrams.

13  CII Saxion Hogeschool Enschede 13 UML Diagrams

14  CII Saxion Hogeschool Enschede 14 Views Use Case View : Use Cases capture a mode of use of the system as observed by an external actor. The Use Case view is a visual representation of such modes of use. Static View : captures static relationships between conceptual entities in a domain, abstracting from their physical representation or implementation. Design View : models the structure of the application itself (structured classifiers, collaborations, components and interfaces). State Machine View : Models the possible life histories of an object of a class.

15  CII Saxion Hogeschool Enschede 15 Views Activity View : Shows the flow of control among the computational activities involved in performing a calculation or a workflow. Interaction View : Describes sequences of message exchanges among the parts of a system. Model Management View : Models the organization of the model itself. A model comprises a set of packages that hold model elements (classes, state machines, use cases) or other packages. Deployment View : A description of the allocation of components to execution resources.

16  CII Saxion Hogeschool Enschede 16 Views Major AreaViewDiagram structuralstatic viewclass diagram design viewinternal structure collaboration diagram component diagram use case viewuse case diagram

17  CII Saxion Hogeschool Enschede 17 Views Major AreaViewDiagram dynamicstate machine viewstate machine diagram activity viewactivity diagram interaction viewsequence diagram communication diagram physicaldeployment viewdeployment diagram model management model management view package diagram

18  CII Saxion Hogeschool Enschede 18 Use-Case View Use-Case Diagrams Use-Case Diagrams model modes of use of a system : Use Cases Actors

19  CII Saxion Hogeschool Enschede 19 Static View Class Diagrams Class Diagrams model structure of objects and their relationships Classes Objects Packages Lift system

20  CII Saxion Hogeschool Enschede 20 Interaction diagrams Model interactions between objects Objects Messages Interaction View

21  CII Saxion Hogeschool Enschede 21 State machine View State machine Diagrams model behavior of individual objects States Transitions Events (messages) Door

22  CII Saxion Hogeschool Enschede 22 Component View Component Diagrams Typical components: Executables DLL’s Packages Database tables Show the component dependencies Building.java java.awt Building.html background.gif Building.class Lift JavaDevicesDevices appletviewer.exe

23  CII Saxion Hogeschool Enschede 23 Deployment View Deployment Diagrams show the physical distribution of components over processors Location of components on nodes

24 Use Case s Essentials24 Use Cases The Essentials

25  CII Saxion Hogeschool Enschede 25 Requirements Requirements specification : High-level description of what should be implemented Importance of requirements : 25% of the projects fail due to problems with requirements Find out about requirements : Interview stakeholders to find out what they need system to do A requirement may be a description of : What behaviour the system should offer A specific property of the system A constraint on the system

26  CII Saxion Hogeschool Enschede 26 Functional and Non-functional Requirements Functional Requirements : What the system should do “The ATM system shall provide a facility for authenticating the identity of a system user” Non-functional Requirements : A constraint on how the functional requirements are implemented “The ATM system shall authenticate a customer in four seconds or less”

27  CII Saxion Hogeschool Enschede 27 The glossary There is always a certain jargon in a business domain Project glossary captures the language of the domain The aim of the glossary is : Define key terms Resolve synonyms and homonyms Project Glossary Term1 Definition Term2 Definition Term3 Definition …

28  CII Saxion Hogeschool Enschede 28 The system boundary Before we can build anything, we need to know : Where the boundary of the system lies Who or what uses the system What functions the system should offer System boundary is identified in UML by a Use Case model The Use Case model contains : Actors – who or what uses the system Use Cases – things actors do with the system Relationships - between actors and use cases

29  CII Saxion Hogeschool Enschede 29 Use Case Diagram

30  CII Saxion Hogeschool Enschede 30 Characteristics Use Case Modeling Use Case Modeling is OO-independent There is no UML standard way of writing requirements!

31  CII Saxion Hogeschool Enschede 31 Actors An actor is anything that interacts directly with the system Actors identify who or what uses the system Actors indicate where the system boundary lies Actors are external to the system An Actor specifies a role that some external entity adopts when interfacing with the system

32  CII Saxion Hogeschool Enschede 32 Identifying Actors When identifying actors ask : Who or what uses the system? What roles do they play in the interaction? What other systems use this system? Who gets and provides information to the system? Is there a dedicated time at which the system has to do something? Actor symbol : Visitor

33  CII Saxion Hogeschool Enschede 33 Use Cases A use case is something an actor wants to do with the system. It is a “case of use” of the system by a specific actor Use cases are always started by an actor Use cases are always written from the point of view of an actor Use Case symbol : Place order

34  CII Saxion Hogeschool Enschede 34 Steps in Use Case Modeling Find actors and use cases Detail a use case : Specify the flow of events or scenario’s Specify pre- and postconditions Structure the use case model : Find relationships between use cases include extend generalization

35  CII Saxion Hogeschool Enschede 35 Use case specification Deposit VAT Preconditions : 1. It is the end of a business quarter Flow of events : 1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of VAT owed to the government. 3. The system sends an electronic payment to the government. Postconditions : 1. The government receives the correct amount of VAT Uses case name System state before the use case can begin Actual steps of the use case System state when the use case is over

36  CII Saxion Hogeschool Enschede 36 Pre and postconditions Preconditions and postconditions are constraints Preconditions : Constrain the state of the system before the use case can start Postconditions : Constrain the state of the system after the use case has executed Place Order Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system

37  CII Saxion Hogeschool Enschede 37 When to use use cases ? Use cases describe system behaviour from the point of view of one or more actors. Use cases are the best choice when : System is dominated by functional requirements System has many types of users to which it delivers different functionality Use cases are designed to capture functional requirements Uses cases are a poor choice when : The system is dominated by non-functional requirements The system has few users The system has few interfaces Develop test plan using use cases

38  CII Saxion Hogeschool Enschede 38 Questions

39 Use Cases Advanced Concepts39 Use Cases Advanced concepts

40  CII Saxion Hogeschool Enschede 40 Use case specification Deposit VAT Preconditions : 1. It is the end of a business quarter Flow of events : 1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of VAT owed to the government. 3. The system sends an electronic payment to the government. Postconditions : 1. The government receives the correct amount of VAT Uses case name System state before the use case can begin Actual steps of the use case System state when the use case is over

41  CII Saxion Hogeschool Enschede 41 Pre and postconditions Preconditions and postconditions are constraints Preconditions : Constrain the state of the system before the use case can start Postconditions : Constrain the state of the system after the use case has executed Place Order Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system

42  CII Saxion Hogeschool Enschede 42 Flow of events The flow of events lists the steps in a use case It always begins by an actor doing something A good way to start a flow of events is : “1) The use case starts when an ” Flow of events should be a sequence of short steps which are: Declarative, numbered, time ordered Alternatives can be shown by branching or by listing under “Alternative paths” A good format for steps is : The

43  CII Saxion Hogeschool Enschede 43 Branching within a flow: If Use the keyword if to indicate alternatives within the flow of events Use indentation and numbering to indicate the conditional part of the flow View Basket Flow of Events: 1. The use case starts when the customer selects “view basket”. 2. The customer selects an item. 3. The customer may delete an item from the basket, change the quantity of an item, exit “view basket” or proceed to checkout. 4. If the user selects “delete item” 4.1. The item is removed from the basket 5. If the customer types in a new quantity 5.1. The quantity of the item is updated 6. If the customer selects…

44  CII Saxion Hogeschool Enschede 44 Alternative Paths are for things that can happen at any time Section in use case specification for each alternative path with : The flow of events for the alternative path postconditions for the alternative path (optional) Flow of Events: Basic Path 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. … Alternative Path 1 1. At any time the customer can select “cancel order” and the order is deleted from the system. Alternative Path 2 1. At any time, the customer can go back to shopping. Branching: Alternative paths Checkout

45  CII Saxion Hogeschool Enschede 45 Repetition within a flow: For Use the keyword “For” to indicate the start of a repetition within the flow of events Expression immediately after “For” indicates the number of repetitions of the indented text beneath the “For” statement Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. … Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. …

46  CII Saxion Hogeschool Enschede 46 Repetition within flow: While Use the keyword “While” to indicate that something repeats while some Boolean condition is true Show Company Details Flow of Events: 1. The use case starts when the customer selects “show company details”. 2. While the customer is browsing the company details 2.1. The system plays some background music. 2.2. The system displays special offers in a banner at the top of the page. 3. …

47  CII Saxion Hogeschool Enschede 47 Complex use cases Techniques up to now are fine for modeling average use cases However, when use cases are complex, and there are many branches within the flow of events, there is a better approach Scenarios

48  CII Saxion Hogeschool Enschede 48 Scenarios One specific path through a use case with no branching Each use case has one primary scenario : This is the “happy day” or “perfect world” path through the flow Everything goes as expected and desired No errors, interrupts or branches Each use case has many secondary scenarios : Alternate paths through the flow Errors (exception scenarios) Interrupts to the main flow

49  CII Saxion Hogeschool Enschede 49 Primary scenario Use the Primary Scenario as the use case flow of events List the Secondary Scenarios under a new section Provide a separate document for each secondary scenario Checkout Flow of Events: Primary Scenario 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. The customer enters a valid customer number. 4. The system retrieves and displays customer information. … Secondary Scenarios Invalid Customer Number. Invalid Credit Card Details. Credit Card Expired.

50  CII Saxion Hogeschool Enschede 50 Secondary scenarios One specific path through flow of events with no branching Always state how the scenario begins Checkout Secondary Scenario: Invalid Customer Number Flow of Events : 1. The scenario begins in step 3 of the use case “Checkout” when the customer enters an invalid customer number. 2. For three invalid entries 2.1. Prompt the customer to enter their customer number again 3. The system asks the customer to enter new customer details 4. The customer enters new customer details. 5. The system generates a new customer number 6. …

51  CII Saxion Hogeschool Enschede 51 Finding Secondary Scenarios Identify the Primary Scenarios Examine each step in the Primary Scenario and look for : Alternative flows Errors (exception scenarios) Interrupts – something that could happen at any time

52  CII Saxion Hogeschool Enschede 52 How many scenarios? There is one Primary Scenario per use case There may be many secondary scenarios per use case It would take far too long to document them all : Pick the most important ones to document Often there are groups of similar secondary scenarios : Document one of these as an exemplar Add notes to this explaining how the others differ from it

53  CII Saxion Hogeschool Enschede 53 Structuring the Use Case Model Structure the Use Case Model by exploring relationships : Actor generalisation Use case generalisation «include» – between use cases «extend» – between use cases

54  CII Saxion Hogeschool Enschede 54 Actor Generalisation Sales agentCustomer Order products Purchaser Sales system Calculate commission Accept payment List products

55  CII Saxion Hogeschool Enschede 55 Actor generalisation semantics Actors communicate with same set of use cases in same way : Express this as generalisation to another (possibly abstract) actor Descendent actors inherit from ancestor actor : Roles and relationships to use cases held by the ancestor actor Substitutability principle : We can substitute a descendent actor anywhere the ancestor actor is expected

56  CII Saxion Hogeschool Enschede 56 Use Case Generalisation Verify User User Check BiometricsCheck Password Security System

57  CII Saxion Hogeschool Enschede 57 Use case generalisation semantics Child use cases represent more specific forms of the parent The children inherit from their parent : Preconditions, Flow of Events, Postconditions Relationships The children may add new features : New steps in the flow of events New preconditions and postconditions New relationships

58  CII Saxion Hogeschool Enschede 58 > Manager Find Employee Details Personnel System Change Employee Details View Employee Details Delete Employee Details >

59  CII Saxion Hogeschool Enschede 59 Clients include supplier behaviour Change employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The manager selects part of the employee details to change. 4. … View employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The system displays the employee details. 4. … Delete employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The system displays the employee details. 4. The manager deletes the employee details. 5.

60  CII Saxion Hogeschool Enschede 60 «include» semantics «include» works as follows : The client use case executes until the point of inclusion include(X ) Control passes to the supplier use case which executes When the supplier is finished, control passes back to the client use case which finishes execution Client use cases are incomplete without the included supplier use cases Supplier use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere

61  CII Saxion Hogeschool Enschede 61 >

62  CII Saxion Hogeschool Enschede 62 «extend» semantics «extend» is a way of adding new behaviour to base use case by inserting behaviour from one or more extension use cases Base use case specifies extension points in its flow of events : Base use case does not know about the extension use cases Remains unchanged as new extension use cases are added Extension use case may contain several insertion segments The «extend» relationship specifies which of the base use case extension points it is extending

63  CII Saxion Hogeschool Enschede 63 Base use case Return book Preconditions: 1. A valid librarian is logged on to the system Flow of events: 1. The librarian enters the borrowers ID number 2. The system displays the borrower details including the list of borrowed books 3. The librarian finds the book to be returned in the list. 4. The librarian returns the book. 5. …

64  CII Saxion Hogeschool Enschede 64 «include» and «extend» «include» is used where we want to reuse the same behaviour again and again in many different use cases «extend» is used when we want to modify an existing use case by inserting some new behaviour at named extension points Extend also allows us to reuse behaviour fragments, but in a more flexible way

65 Interaction Diagram65 Class Diagrams The Essentials

66  CII Saxion Hogeschool Enschede 66 Class diagrams Models the static design view of the system : Involves modelling vocabulary of the system Involves modelling collaborations in the system Class diagrams show : Classes Interfaces Relationships between classes Constraints Adorned by navigational and multiplicity information Further described by the rules on the classes and associations The class diagram shows the first formal definition of a class Leads to specification of abstract data types, that can be used by the software engineer.

67  CII Saxion Hogeschool Enschede 67 Class diagram Floor floorNumber : int LiftCage * RequestToServiceFloor 0..1 IsAt * *

68  CII Saxion Hogeschool Enschede 68 Classes and objects in UML simple name path name An object icon has the object name underlined A class icon has compartments for attributes and operations

69  CII Saxion Hogeschool Enschede 69 Attributes An attribute is a property of a class At a given moment an object of a class will have specific values for every one of its class’s attributes In the attribute compartment attributes can Be of different types Have different visibility : + for public, - for private, underlined for class scope (static)

70  CII Saxion Hogeschool Enschede 70 Operations An operation is the implementation of a service. Invoking an operation can change the data and the state of the object In the operation compartment operations can Be described with return type and parameters, signature + for public, - for private underlined for class scope (static operation) Operations are applied to objects of a class Operations are also called functions Operations describe what service a class offers Format for operations name (parameter-list) : return-type-expr Each parameter is specified with : name : type-expr = value Specifying value is optional

71  CII Saxion Hogeschool Enschede 71 Attributes and operations example

72  CII Saxion Hogeschool Enschede 72 Class relationships Classes will in general have relations with other classes Objects may have other objects as parts Objects may be associated to other objects Three different kinds of relationships are the most important Generalization Specialized classes inherit from more generalized classes in a subclass/superclass or parent/child relationship Association A structural relationship between instances of classes Dependency Using relationship, one instance of a class depends on an instance of another class There may be constraints on class relations : Multiplicities are constraints A LiftCage may have 12 FloorRequestButtons

73  CII Saxion Hogeschool Enschede 73 Types of class relationships Association Is a connection between classes An instantiation of association is a link (between objects) Generalization A specialised subclass is derived from a superclass Shows that a subclass shares the structure and/or behavior defined in the superclass Dependency The client class depends on the supplier class to provide services Services include accessing attributes, operations or using types Realization A relationship between classes or components and interfaces An interface is a set of well-defined functions and their signatures Shows how a class realizes operations offered by the interface

74  CII Saxion Hogeschool Enschede 74 relationships Association Adornments Navigable association Aggregation Composition Generalization Dependency Realization

75  CII Saxion Hogeschool Enschede 75 Association, role, multiplicity Company Person Works for association name employeeemployer 1..* * role name multiplicity

76  CII Saxion Hogeschool Enschede 76 Multiplicity Multiplicity is defined as Specification of a range of allowable cardinalities that a set may assume Multiplicity has meaning for associations It indicates how may objects relate to how many other objects Multiplicity info is indicated ‘at the end’ of an association. single integer: 1[exactly one] range: 0.. 1[zero or one] : 2.. 4[two, three or four] range: 1.. * / 1..n[one or more] single star: * (= 0.. *)[zero or more]

77  CII Saxion Hogeschool Enschede 77 Navigation UserPassword navigable association *

78  CII Saxion Hogeschool Enschede 78 Generalization/specialization Generalization is a special kind of relationship The ‘is-a’ or ‘is a kind of’ relationship Generalization is called generalization/specialization An example is the relationship between a car and a truck : A car is a specialization of a vehicle A vehicle is a generalization of of a car In the design phase it is also called inheritance relationship A car has all properties of a vehicle and possibly more A car inherits from a vehicle

79  CII Saxion Hogeschool Enschede 79 Generalization/specialization example

80  CII Saxion Hogeschool Enschede 80 Multiple inheritance Classes may have more then one base class Avoid multiple inheritance in the analysis : May introduce problems in the design or programming phase If necessary use interfaces

81  CII Saxion Hogeschool Enschede 81 Aggregation A special kind of association is a “has a” (containment) relationship Models the whole-part relation Object of the whole has objects of the part Simple (weak) aggregation Whole ‘controls’ parts Composition (strong aggregation) Whole consists of parts

82  CII Saxion Hogeschool Enschede 82 Aggregation examples

83  CII Saxion Hogeschool Enschede 83 When to use class diagrams? Always To model static structure of system There is one class diagram describing the structure Don’t go to implementation details too early.

84 Interaction Diagrams84 Interaction Diagrams

85  CII Saxion Hogeschool Enschede 85 Object Interaction Diagrams An object interaction diagram shows two aspects Which objects and messages are involved in the interaction How objects and messages are involved in the interaction A Use Case is realised through a pattern of interactions Interaction models show how a Use Case (or part of it) is realised Usually one interaction diagram for each scenario in the Use Case

86  CII Saxion Hogeschool Enschede 86 Sequence diagram Illustrates how objects interact with each other The focus is on message sequences Reveals an interaction for a specific scenario It shows specific interaction between objects at some point in time Two axes present in sequence diagram The vertical axis shows time The horizontal axis shows a set of objects The objects are represented by An object rectangle A dashed line representing the object lifeline Shows communication between objects As horizontal message lines between object’s lifelines

87  CII Saxion Hogeschool Enschede 87 Sequence diagram Object and timeline :

88  CII Saxion Hogeschool Enschede 88 Sequence diagram sample

89  CII Saxion Hogeschool Enschede 89 Analyze flows of control and time ordering To further model a flow of control and time ordering on a sequence diagram: Set the context of interaction Identify the objects which play a role in the interaction Set the lifeline for each object Lay out the messages showing their properties (parameters) Adorn each object’s lifeline with its focus of control (optional) Adorn each message with a timing mark and attach time or space constraints (optional) Attach pre- and post-conditions to each message (optional)

90  CII Saxion Hogeschool Enschede 90 Frames new since UML 2.0 graphical boundary of a diagram basis for many diagram elements

91  CII Saxion Hogeschool Enschede 91 Sequence Diagram References reference to sequence digram

92  CII Saxion Hogeschool Enschede 92 Sequence Diagram References

93  CII Saxion Hogeschool Enschede 93 Alternative (no messages) optional element (‘if without else’)

94  CII Saxion Hogeschool Enschede 94 Loops / conditionals loop condition nested conditional alternate branches guard conditon

95  CII Saxion Hogeschool Enschede 95 Order and timing constraints on sequence diagrams duration constraint message with duration duration constraint expression

96  CII Saxion Hogeschool Enschede 96 When to use sequence diagrams? For each use case They show interaction between objects to realize use case. Alternative: communication diagram

97  CII Saxion Hogeschool Enschede 97 Interaction overview diagram decision interaction use fork join

98  CII Saxion Hogeschool Enschede 98 Communication Diagram A communication diagram basically only shows relations between objects that are involved in the realisation of a Use-case. If needed the sequence of messages can be specified using sequence number, but information about parallelism, timing and timing requirements are not shown as a specific dimension Useful when the emphasis is more on the static structure, which objects are involved in this interaction

99  CII Saxion Hogeschool Enschede 99 Communication diagram

100  CII Saxion Hogeschool Enschede 100 When to use communication diagram? For each use case Shows interaction between objects to realize use case. Alternative: sequence diagram

101 101 Class Diagrams Advanced Concepts

102  CII Saxion Hogeschool Enschede 102 Recursive Association

103  CII Saxion Hogeschool Enschede 103 Association Class

104  CII Saxion Hogeschool Enschede 104 Examples aggregation and association

105  CII Saxion Hogeschool Enschede 105 Examples aggregation and association

106  CII Saxion Hogeschool Enschede 106 Composition Strong form of aggregation is called composition in UML Composition characteristics : Part lives only and as long as the whole lives Lifetimes of of whole and part are the same Part is owned by exactly one whole Multiplicity is one on the whole side Example of simple aggregation versus composition : School has teachers is aggregation School has classrooms is composition

107  CII Saxion Hogeschool Enschede 107 Qualified Associations target class association relation without qualification qualified class qualifier Multiplicity after qualification

108  CII Saxion Hogeschool Enschede 108 Parameterised classes Generic class of which actual class not known until runtime: Generic class has one or more formal parameters Actual class is parameter when generic class is instantiated Synonym: template class Typical use of parameterized classes are containers Generic container class Set with formal class T as argument: Actual class Car can be bound to T at run time by Set Each of the Set objects will represent set of cars

109  CII Saxion Hogeschool Enschede 109 Parameterised class example explicit binding implicit binding class with an anonymous name

110  CII Saxion Hogeschool Enschede 110 Interfaces Interface described by set of abstract operations Class, package or component connected to interface : Implements or supports specific interface Interface represents contract that is implemented by object: Programming equivalents are COM en java interfaces Component can choose to implement interface

111  CII Saxion Hogeschool Enschede 111 Interfaces: representation supplier and client full interface required interface provided interface

112  CII Saxion Hogeschool Enschede 112 Realization Semantic relationship between classifiers : One classifier specifies a contract Another classifier guarantees to carry it out Relationship often used in combination with interfaces : Interfaces specify a contract for a class Interfaces do not dictate any implementation Class may realize many interfaces : Class provides methods of the interface with implementation

113  CII Saxion Hogeschool Enschede 113 Realization example

114  CII Saxion Hogeschool Enschede 114 Constraints Restrictions on usage or semantics of element Example is association between Person and Group : Limit membership group on age attribute Number of pre-described constraints available

115  CII Saxion Hogeschool Enschede 115 Constraints {ordered} Constraint ordered means that the links ({LiftCage, FloorRequestButton} instances) are ordered. The FloorRequestButtons are positioned in order in the LiftCage Example: Ordered association

116  CII Saxion Hogeschool Enschede 116 Constraints Specify conditions that must be true for a well formed model : Value constraints on class attributes Pre-postconditions and invariants Constraint modeling in UML : Free-form text between brackets More formally described by OCL (object constraint language) A number of constraints are predefined in UML

117  CII Saxion Hogeschool Enschede 117 Dependencies A modelelement A is dependant of modelelement B means that, when the interface of B changes, also A has to change. Most common dependency. One class uses another class as a parameter for an operation. Modeled by drawing a dependency to the class used as parameter. It is also possible to use a class as return type of an operation.

118  CII Saxion Hogeschool Enschede 118 Dependency example

119  CII Saxion Hogeschool Enschede 119 Dependency stereotypes Classes and objects access bind call create derive instantiate permit realize refine send substitute trace use Packages access import Use Cases extend include


Download ppt " CII Saxion Hogeschool Enschede 1 Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005."

Similar presentations


Ads by Google