Unified Modeling Language (UML)

  • 408 views
Uploaded on

This is an overview of UML for OOP-based system design. This is to be studied in conjunction with presentations on C++ and Design Pattern.

This is an overview of UML for OOP-based system design. This is to be studied in conjunction with presentations on C++ and Design Pattern.

More in: Engineering
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
408
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
163
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • OMT - Object Modeling Technique (James Rumbaugh et al.)
    especially suited for analysis of data intensive information systems
    among others, employment of extended Entity-Relationship diagrams
    Booch-Method (Grady Booch)
    particularly suited for modeling real-time systems and concurrent systems
    strong relationship to programming languages (Ada)
    OOSE - Object-Oriented Software Engineering (Ivar Jacobson)
    use case-oriented approach
    excellent support for business engineering and requirements analysis
    modeling and simulation of telecommunication systems by means of Message Sequence Charts and SDL (Specification and Description Language)
    UML unifies many of their concepts and introduces new ones

Transcript

  • 1. Modeling for SoftwareModeling for Software Design and UMLDesign and UML ewË&ewËhevxshqhs„`b`wËxaewË&ewËhevxshqhs„`b`wËxa xrqxrqËËwËËw
  • 2. UML - OutlineUML - Outline Introduction to Modeling Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UML SyntaxUML Syntax and Semanticsand Semantics 
  • 3. WHAT IS A MODEL?WHAT IS A MODEL? WHY WE NEED MODELS?WHY WE NEED MODELS? Software Engineering Model 
  • 4. Motivation for Analysis and DesignMotivation for Analysis and Design Why do we model?Why do we model? “When it comes down to it, the real point of software development is cutting code” “Diagrams are, after all, just pretty pictures” “No user is going to thank you for pretty pictures; what a user wants is software that executes” [M. Fowler,“UML Distilled”,Addison Wesley, 1997]
  • 5. Models we may have seen …Models we may have seen … Physics ◦ Time-Distance Equation Chemistry ◦ Valency-Bond Structures Mathematics ◦ All about models … Geography ◦ Maps ◦ Projections Electrical Circuits ◦ Kirchoff’s Loop Equations ◦ Time Series Signals & FFT ◦ Transistor Models Building & Bridges ◦ Drawings ◦ Finite Element Models Machine Design ◦ Differential Equations !
  • 6. Why do we need models?Why do we need models? Solutions Method: Real Systems may not be available, accessible, affordable … ◦ Represent the System as a Model ◦ Solve problems on the Model ◦ Map the solutions back to the System Human Cognition Mechanism is limited ◦ Short Term & Long Term Memory ◦ Ability to track only up to 7 entities Models are Abstractions that help track complexity "
  • 7. Implication in Program DevelopmentImplication in Program Development A small program having just a few variables: ◦ Is within easy grasp of an individual. As the number of independent variables in the program increases: ◦ It quickly exceeds the grasping power of an individual:  Requires an unduly large effort to master the problem. !
  • 8. Implication in Program DevelopmentImplication in Program Development Instead of a human, if a machine could be writing (generating) a program, ◦ The slope of the curve would be linear. But, why does the effort-size curve become almost linear when software engineering principles are deployed? ◦ Software engineering principles extensively use techniques specifically to overcome the human cognitive limitations. "
  • 9. How to overcome Human CognitiveHow to overcome Human Cognitive Limitations?Limitations? Two important principles are profusely used in SE: ◦Abstraction ◦Decomposition #
  • 10. AbstractionAbstraction Simplify a problem by omitting unnecessary details. ◦Focus attention on only one aspect of the problem and ignore irrelevant details. ◦Also called Model Building $
  • 11. AbstractionAbstraction Suppose you are asked to develop an overall understanding of some country. ◦ Would you:  Meet all the citizens of the country, visit every house, and examine every tree of the country? ◦ You would possibly only refer to various types of maps for that country. %
  • 12. AbstractionAbstraction A map is: ◦ An abstract representation. i
  • 13. AbstractionAbstraction Several abstractions of the same problem possible: ◦Focus on some specific aspect and ignore the rest. ◦Different types of models help understand different aspects of the problem. 
  • 14. Abstraction -ViewsAbstraction -Views Maps ◦ Physical ◦ Political ◦ Road Network ◦ Rivers Electrical Design ◦ Schematic ◦ Layout ◦ Timing Building Design ◦ Physical  Plan  Elevation ◦ Water Supply ◦ Electrical Distribution ◦ Sewage 
  • 15. AbstractionAbstraction For complex problems: ◦ A single level of abstraction is inadequate. ◦ A hierarchy of abstractions needs to be constructed. Hierarchy of models: ◦ A model in one layer is an abstraction of the lower layer model. ◦ An implementation of the model at the higher layer. 
  • 16. DecompositionDecomposition Decompose a problem into many small independent parts. ◦ The small parts are then taken up one by one and solved separately. ◦ The idea is that each small part would be easy to grasp and can be easily solved. ◦ The full problem is solved when all the parts are solved. "
  • 17. DecompositionDecomposition A popular use of decomposition principle: ◦ Try to break a bunch of sticks tied together versus breaking them individually. Any arbitrary decomposition of a problem may not help. ◦ The decomposed parts must be more or less independent of each other. #
  • 18. Decomposition ExampleDecomposition Example Example use of decomposition principle: ◦You understand a book better when the contents are organized into independent chapters. ◦Compared to when everything is mixed up. $
  • 19. Decomposition is HierarchicalDecomposition is Hierarchical Decompose the WHOLE into PARTs Decompose each PART into SUB-PARTs Decompose each SUB-PART into SUB-SUB-PARTs %
  • 20. Decomposition HierarchyDecomposition Hierarchy ExamplesExamples Books ◦ Chapters  Sections  Paragraphs  Sentences  … Cars ◦ Engine  Piston  Cylinders ◦ Wheels  Tyre  Tube ◦ Steering ◦ Brakes ◦ AC ◦ Seats ◦ … i
  • 21. Modelling Relations forModelling Relations for HierarchiesHierarchies Abstraction Hierarchy ◦IS-A Decomposition Hierarchy ◦ HAS-A 
  • 22. Motivation for Analysis and DesignMotivation for Analysis and Design The Model as an Abstraction of the RealityThe Model as an Abstraction of the Reality We are not able to comprehend a complex system in its entirety - a single model is not enough ◦ different perspectives are required, which in turn require different models being independent from each other ◦ each model must exist on different levels of granularity Good models are necessary ... ◦ for making complex systems more understandable ◦ for visualizing the essential aspects of a system ◦ for communication among project members and with the customer ◦ for ensuring architectural soundness 
  • 23. UML OVERVIEWUML OVERVIEW Software Engineering Model 
  • 24. What is the UML?What is the UML? GoalsGoals  Provide users with an expressive modeling language ◦ for the specification, construction, visualization and documentation of the artifacts of a software system ◦ for the construction of different kinds of models ◦ for the exchange of models  Provide users with ready-to-use core concepts ◦ however, extensibility and specialization mechanisms are available  Provide a formal basis for understanding the modeling language ◦ metamodel in terms of a UML class diagram ◦ “Semantics” is part of the official UML documentation  Support higher-level development concepts ◦ such as collaborations, patterns, and components  Integrate best practices !
  • 25. What is the UMLWhat is the UML notnot?? It is the explicit intention of the UML developers not to prescribe ◦ a certain process ◦ a certain modeling tool ◦ any modeling guidelines ◦ a certain programming language Dedicated Goal: Openness! "
  • 26. Objects – Core to S/W ModelsObjects – Core to S/W Models Defines object-orientation Has multiple viewpoints ◦ Modeling / Conceptual ◦ Philosophical ◦ Software Engineering ◦ Implementation ◦ Formal Fundamental and most widely used UML model 
  • 27. ObjectsObjects ModelingViewpoint ◦ Conceptual Model ◦ An object has  Identity  Substance – Properties 
  • 28. ObjectsObjects PhilosophicalViewpoint ◦ Existential Abstractions ◦ Two types of abstractions  Objects created, used and destroyed  Eternal Objects  Numbers, Dates, Colors
  • 29. ObjectsObjects Software EngineeringViewpoint ◦ Data Abstractions ◦ Encapsulates  Data  Operations ◦ Language Types  Object-based Languages: C  Encapsulating Modules  Object-oriented Languages: C++, Java  Supports inheritance !
  • 30. ObjectsObjects ImplementationViewpoint ◦ Contiguous Structure in Memory ◦ An Object is a  Composite or aggregate – possessing other objects  At lowest level has atomic objects ◦ An object supports  Value Semantic  Reference Semantics "
  • 31. ObjectsObjects FormalViewpoint An object is a state machine with ◦ Finite set of states ◦ Finite set of state functions #
  • 32. Defining ObjectsDefining Objects Characterized by a set of properties ◦ Set of Attributes and ◦ Set of Associations  Relationships ◦ Attributes are  Structural  Behavioral Description of Properties ◦ Called a Class $
  • 33. Behaviors of ObjectsBehaviors of Objects Behavior is ◦ Services provided by an object Services are invoked by ◦ Sending Messages In Client-ServerView ◦ Clients request for Services ◦ Servers provide Services ◦ Contract between client and server ensures correctness %
  • 34. Objects – Number ExampleObjects – Number Example Complex Numbers ◦ Variables  Real Part  Imaginary Part ◦ Operations  Create  Norm  Add / Subtract !i
  • 35. Objects – Geometry ExamplesObjects – Geometry Examples Points ◦ Variables  X Coordinate  Y Coordinate ◦ Operations  GetX / SetX  GetY / SetY  FindQuadrant Lines ◦ Variables  Point 1  Point 2 ◦ Operations  GetPt1 / SetPt1  GetPt2 / SetPt2  FindLength !
  • 36. Objects – Geometry ExamplesObjects – Geometry Examples Triangles ◦ Variables  Point 1  Point 2  Point 3 ◦ Operations  GetPt1 / SetPt1  GetPt2 / SetPt2  GetPt3 / SetPt3  FindPerimeter  FindArea Polygon ◦ Variables  Number of Points  Array of Points ◦ Operations  GetPtCount  GetPt(int i)  FindPerimeter  FindArea !
  • 37. Objects – Library Example 1Objects – Library Example 1 Books ◦ Variables  Acc_no  Title  Author  Publisher  Status // Issued,Available  Borrower // Member ◦ Operations  Get  Acc_no,Title,Author, Publisher, Status  Issue(Member)  Return Members ◦ Variables  Member_ID  Name  Address  Books_Issued // Array of Books ◦ Operations  Get  Member_ID, Name, Address, Books_Issued, FreeCards !
  • 38. Objects – Library Example 2Objects – Library Example 2 Books ◦ Variables  Acc_no, Title, Author, Publisher, Status ◦ Operations: Get Members ◦ Variables  Member_ID, Name, Address, Count of Books_Issued ◦ Operations: Get Borrow_Register ◦ Variables  Borrow_ID  Acc_no  Member_ID  Borrow_Date  Operator_ID ◦ Operations  Borrow(Books, Members)  Return(Books) !
  • 39. Relations between ObjectsRelations between Objects Relation Example Specialization- Generalization , IS-A Book is-a Publication Journal is-a Periodical Periodical is-a Publication Whole-Part, HAS-A Book has-a Title Book has-a Publisher Publisher has-a Address Member-of, HAS Library has Member !!
  • 40. Relations between ObjectsRelations between Objects IS-A ◦ Class or Type Hierarchy HAS-A ◦ Composition  Uniquely contains the component ◦ Aggregation (called ‘Weak’ Aggregation)  Multiple containments possible Member-of ◦ Special case of HAS-A ◦ Does not support transitivity !"
  • 41. History of UMLHistory of UML Various Methods Booch’91 OMT-1 OOSE Booch’93 OMT-2 Unified Method 0.8 June `99 OMG accepts the UML as the official industrial standard for software modeling notations on 17th Nov. ‘97 Submission to OMG, Sept ‘97 Submission to OMG, Jan ‘97 Beta Version OOPSLA ‘96 WWW-June ‘96 OOPSLA ‘95 UML 0.9 UML 1.0 UML 1.1 Public Feedback “Method Wars” Industrialization Standardization Unification Fragmentation UML 1.3 !#
  • 42. Diagrams of UMLDiagrams of UML (1) Use Case Diagram (2) Class Diagram (3) Sequence Diagram (4) Collaboration Diagram (5) Statechart Diagram (6) Activity Diagram (7) Component Diagram (8) Deployment Diagram Implementation Diagrams Interaction Diagrams Behavior Diagrams !$
  • 43. Views supported by UMLViews supported by UML Use Case ViewUse Case View  Use Case DiagramUse Case Diagram  Statechart DiagramStatechart Diagram  Interaction DiagramsInteraction Diagrams  Activity DiagramActivity Diagram Logical/Design View Logical/Design View Class Diagram Class Diagram Statechart Diagram Statechart Diagram Interaction Diagrams Interaction Diagrams Activity Diagram Activity Diagram Process/Concurrency View Process/Concurrency View Class Diagram Class Diagram Statechart Diagram Statechart Diagram Interaction Diagrams Interaction Diagrams Activity Diagram Activity Diagram System Deployment ViewDeployment View Deployment DiagramDeployment Diagram Statechart DiagramStatechart Diagram Interaction DiagramsInteraction Diagrams Activity DiagramActivity Diagram [after Booch et al., 1999][after Booch et al., 1999] Component / Impl. ViewComponent / Impl. View Component DiagramComponent Diagram Statechart DiagramStatechart Diagram Interaction DiagramsInteraction Diagrams Activity DiagramActivity Diagram !%
  • 44. Ongoing ExampleOngoing Example Calendar Manager “CALENDARIUM” (1/2)Calendar Manager “CALENDARIUM” (1/2) Multi-user calendar manager on Internet basis Visualization ◦ views on a yearly, monthly, weekly and daily basis ◦ insert/update of appointments in each view ◦ highlighting of days with appointments (in year view only) Appointments ◦ single appointments; appointment series ◦ possibility to define different kinds of appointments (private, business, etc.) ◦ management of a to-do list ◦ appointments are relocatable or fixed "i
  • 45. Ongoing ExampleOngoing Example Calendar Manager “CALENDARIUM” (2/2)Calendar Manager “CALENDARIUM” (2/2) Communication ◦ timely notification of all persons involved in an appointment ◦ advance notice of appointments ◦ management of access rights ◦ coordination of joint appointments ◦ search capability for possible appointments with n participants Definition of named groups of persons Export of appointments within a certain time frame ◦ printer, spread sheet, HTML Various visualization parameters may be configured by the user "
  • 46. Process for Introducing UMLProcess for Introducing UML Phases (1/2)Phases (1/2) ContractContract Requirements ModelRequirements Model Analysis ModelAnalysis Model Design ModelDesign Model CodeCode Requirements SpecificationRequirements Specification AnalysisAnalysis DesignDesign ImplementationImplementation TestTest [else] [else] [else] [Analysis Model complete] [Requirements Model complete] [Design Model complete] "
  • 47. Process for Introducing UMLProcess for Introducing UML Phases (2/2)Phases (2/2) TestTest Start of OperationStart of Operation EmploymentEmployment [else] [else] [else] [incremental development necessary] [Start of operation successful] [Test successful] [Maintenance necessary] [additional functionality required] "
  • 48. OutlineOutline Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UML-SyntaxUML-Syntax and -Semanticsand -Semantics "
  • 49. REQUIREMENTREQUIREMENT SPECIFICATION PHASESPECIFICATION PHASE UML Diagrams "!
  • 50. Phase 1: Requirements SpecificationPhase 1: Requirements Specification Goal is the description of the required system functionality from the user‘s point of view ◦ Description of the use cases (“use case driven”) ◦ conceptual model of the Universe of Discourse to which the application belongs ◦ defines how the system should communicate with its environment, represented by actors Communication medium between user and developer ""
  • 51. Models of theModels of the Requirements Specification PhaseRequirements Specification Phase Use Case Model Problem Domain Model Interface Model Constructing the Use Case Model Constructing the Problem Domain Model Constructing the Interface Model [else] [no further use cases][no further use cases] "#
  • 52. Results of theResults of the Requirements Specification PhaseRequirements Specification Phase Use Case Model Interface Model Requirements Model 1 1 1 1 * * «UML» Class Diagram «UML» Use Case Diagram UI Specification Spec. of System Interfaces Problem Domain Model Description of Use Cases* 1 "$
  • 53. USE CASE MODELUSE CASE MODEL UML Diagrams in Requirement Specification Phase "%
  • 54. Use Case ModelUse Case Model System, Actor and Use CaseSystem, Actor and Use Case Functional decomposition of the system into use cases and actors interacting with them ◦ use cases represent the requirements of the customers Results of constructing the use case model: ◦ global use case diagram ◦ a detailed textual description for each use case #i
  • 55. Use Case DiagramUse Case Diagram CALENDARIUMCALENDARIUM queryquery appointmentappointment exportexport appointmentsappointments deletedelete appointmentappointment changechange appointmentappointment insertinsert appointmentappointment CALENDARIUMCALENDARIUM UserUser #
  • 56. Actor (1/2)Actor (1/2)  Actors interact with the system ◦ by using the system, i.e., by initiating the execution of use cases ◦ by being used by the system, i.e., by providing functionality for realizing use cases ◦ each actor is required to communicate with at least one use case ◦ the communication relationship is undirected  Actors represent roles ◦ concrete users are allowed to adopt/play/discard more than one role at a time ◦ actors are located outside the system boundaries «actor»«actor» UserUser UserUser #
  • 57. Actor (2/2)Actor (2/2) Classification ◦ human: e.g. novice/trained user; system administrator ◦ non-human: e.g., fax, e-mail ◦ primary: ultimate user of the system ◦ secondary: ensures the correct functionality of the system ◦ active: initiates use cases ◦ passive: corresponding use case is initiated by the system Questions for identifying actors: ◦ Who uses the essential use cases? ◦ Who needs system support in order to fulfill the daily tasks? ◦ Who is responsible for system administration? ◦ What are the external devices/software systems the system has to communicate with? ◦ Who is interested in the results of the system? #
  • 58. Use CaseUse Case  Use cases represent the functionality expected by the system under development  Identification of use cases can be done by collecting user requirements and by analyzing the problem description insertinsert appointmentappointment Short DescriptionShort Description:: »An appointment can be inserted for one or more»An appointment can be inserted for one or more participants by an authorized user, who does not needparticipants by an authorized user, who does not need to be one of the participants. All participants must beto be one of the participants. All participants must be notified of this new appointment. New appointmentsnotified of this new appointment. New appointments must be visualized immediately in all open calendars ofmust be visualized immediately in all open calendars of the respective participants.«the respective participants.« NoteNote #
  • 59. «include» -Relationship ◦ the behavior of B is included into A ◦ the included use case B is necessary to ensure the functionality of the base use case A ◦ formerly called «uses» -relationship Relationships Between Use Cases (1/4)Relationships Between Use Cases (1/4) AA BB «include»«include» basebase use case;use case; needs Bneeds B includedincluded use case;use case; is self-containedis self-contained #!
  • 60. «extend» -Relationship ◦ the behavior of B may be incorporated into A ◦ the extending use case B may be (but need not be) activated by the base use case A ◦ extension points specify the location where the extending use case extends the base use case Relationships Between Use Cases (2/4)Relationships Between Use Cases (2/4) AA BB«extend»«extend» basebase use case;use case; is self-contained;is self-contained; controls, if B is executed or notcontrols, if B is executed or not extendingextending use case;use case; is self-containedis self-contained #"
  • 61. Relationships Between Use Cases (3/4)Relationships Between Use Cases (3/4) ◦ the condition under which the extending use case is incorporated has to be specified ◦ more than one extension point can be specified for each use case ◦ the names of extension points have to be unique ◦ the names of extension points need not be equal with the names of the extending use cases configureconfigure access rightsaccess rights configureconfigure parametersparameters configure programconfigure program extension pointsextension points Modify access rightsModify access rights Modify parametersModify parameters «extend» (Modify access rights) [Access rights selected] «extend»(Modify parameters)[Parameters selected] ##
  • 62. Generalization Relationship ◦ Similar to the generalization relationship between classes ◦ B inherits the behavior of A and is allowed to override and extend it ◦ B inherits all relationships of A ◦ Modeling of abstract use cases is also possible ({abstract}) Relationships Between Use Cases (4/4)Relationships Between Use Cases (4/4) AA BB basebase use case;use case; is self-containedis self-contained subsub use case;use case; needsneeds AA (gets base functionality from(gets base functionality from AA);); controls, what is executed fromcontrols, what is executed from AA and what gets changedand what gets changed #$
  • 63. Use Case DiagramUse Case Diagram CALENDARIUM (refined, 1/2)CALENDARIUM (refined, 1/2) queryquery entryentry exportexport entriesentries deletedelete entryentry changechange entryentryinsertinsert entryentry CALENDARIUMCALENDARIUM UserUser updateupdate calendarcalendar notifynotify participantsparticipants configureconfigure ProgramProgram configureconfigure parametersparametersconfigureconfigure access rightsaccess rights administeradminister usersusers administeradminister entry typesentry types AdministratorAdministrator «extend»«extend» «include»«include» «include»«include» «actor»«actor» E-Mail-SystemE-Mail-System «actor»«actor» Fax-SystemFax-System «include»«include» #%
  • 64. Use Case DiagramUse Case Diagram CALENDARIUM (refined, 2/2)CALENDARIUM (refined, 2/2) insertinsert entryentry {abstract}{abstract} UserUser insertinsert appointmentappointment insertinsert to-do entryto-do entry Analogous for query/export/delete/change entryAnalogous for query/export/delete/change entry $i
  • 65. Excursion (1/4)Excursion (1/4) Semantics of the «include»-RelationshipSemantics of the «include»-Relationship  Problem:Where and how should «include» be located within the base use case ?  Possible solution:“Probes” from OOSE A B B AA BB «include»«include» $
  • 66. Excursion (2/4)Excursion (2/4) Semantics of the «extend»-RelationshipSemantics of the «extend»-Relationship AA BB«extend»«extend» “inner” of the language BETA B A $
  • 67. B A Excursion (3/4)Excursion (3/4) Semantics of the Generalization RelationshipSemantics of the Generalization Relationship AA BB “super” of the language Smalltalk $
  • 68. Excursion (4/4)Excursion (4/4) Generalization Relationship between ActorsGeneralization Relationship between Actors  An actor A which inherits another actor B is able to communicate with the same use cases as B  Multiple inheritance also allowed  It can be distinguished whether multiple actors have to communicate with a use case in common or not AA BB AA BB AA BB AA BB $
  • 69. Partitioning Use Case DiagramsPartitioning Use Case Diagrams Package (1/3)Package (1/3)  Large use case diagrams are becoming too complex and confusing (as is the case for all diagrams :-()  UML abstraction mechanism: Package  Criteria for partitioning: ◦ Functional cohesion ◦ Actors ◦ Experience ◦ .... AppointmentAppointment ManagerManager System AdministrationSystem Administration «system«systemModelModel»» CALENDARIUMCALENDARIUM $!
  • 70. Partitioning Use Case DiagramsPartitioning Use Case Diagrams Package (2/3)Package (2/3) «actor»«actor» E-Mail-SystemE-Mail-System «actor»«actor» Fax-SystemFax-System notifynotify participantsparticipants updateupdate calendercalender changechange entryentry deletedelete entryentry insertinsert entryentry queryquery entryentry exportexport entriesentries UserUser Appointment ManagerAppointment Manager «include»«include» «include»«include» «include»«include» «include»«include» «include»«include» «include»«include» $"
  • 71. Partitioning Use Case DiagramsPartitioning Use Case Diagrams Package (3/3)Package (3/3) UserUser Adminis-Adminis- tratortrator configureconfigure programprogram administeradminister usersusers administeradminister entry typesentry types configureconfigure access rightsaccess rights configureconfigure parametersparameters System AdministrationSystem Administration «extend»«extend» «extend»«extend» $#
  • 72. Excursion (1/4)Excursion (1/4) Description of Use CaseDescription of Use Case  Name/Short Description  Preconditions: prerequisites for successful execution  Postcondition: system state upon successful completion  Failure Situations: only domain-related failures  Postcondition in case of failure  Actors: communicating with the use case  Trigger: initiating event for the use case  Main Success Scenario: single (atomic) steps/other use cases  Extensions/Variations: deviations from main success scenario [cf.: A. Cockburn, Goals and Use Cases. JOOP, Sept. 1997][cf.: A. Cockburn, Goals and Use Cases. JOOP, Sept. 1997] $$
  • 73. Excursion (2/4)Excursion (2/4) Description of Use Case - “Insert Appointment”Description of Use Case - “Insert Appointment”  Name and Short Description: Insert appointment »An appointment can be inserted for one or more participants by an authorized user, who does not need to be one of the participants. All participants must be notified of this new appointment. New appointments must be visualized immediately in all open calendars of the respective participants.«  Precondition: User is known by the system.  Postcondition: ◦ New appointment is inserted. ◦ All participants are notified either about the new appointment or that due to authorization problems it was not possible to change their calendar. ◦ All calendar views are updated.  Failure Situations: The user lacks proper authorization for every participant in order to insert the new appointment into their calendars. $%
  • 74. Excursion (3/4)Excursion (3/4) Description of Use Case - “Insert appointment”Description of Use Case - “Insert appointment”  Postcondition in case of failure: ◦ appointment could not be inserted. ◦ The calendars of all participants as well as their views haven‘t been changed by the use case.  Actors: User (primary actor), E-Mail-System (secondary actor), Fax-System (secondary actor).  Trigger: -  Main Success Scenario: (1) User identifies him/herself. (2) The details of the new appointment (time, location, duration, participants, etc.) are being recorded. (3) User is authorized to insert the appointment for all participants. (4) appointment does not cause any collisions and is inserted. %i
  • 75. Excursion (4/4)Excursion (4/4) Description of Use Case - “Insert appointment”Description of Use Case - “Insert appointment” (5) All participants (except the user in case (s)he is a participant too) are notified according to their preferred type of communication («include»notify participants) (6) All currently open calendars of participants are updated. («include»update calendar)  Extensions/Variations: (3’) For at least one participant, the user is not authorized to insert a appointment. (4’) Analogous to (4) (5’) Analogous to 5, whereas each participant whose calendar could not be changed is notified about this authorization problem. (6’) All calendars of participants without authorization problems are updated, where proper authorization exists. %
  • 76. PROBLEM DOMAINPROBLEM DOMAIN MODELMODEL UML Diagrams in Requirement Specification Phase %
  • 77. Problem Domain ModelProblem Domain Model Represents the conceptual model of the problem domain (also called universe of discourse) ◦ does not contain any implementation details ◦ supports the communication between developer and user Result of problem domain modeling: ◦ class diagram, visualizing the static structure of the system under development (“static structure diagram”) %
  • 78. Class and ObjectClass and Object  Class:  Object: Name of object (and class) is underlined UserUser name: Stringname: String authorization: Rightauthorization: Right pwd: Stringpwd: String number: Integernumber: Integer validatePW (PW: String): boolvalidatePW (PW: String): bool computeNumber(): IntegercomputeNumber(): Integer Class AttributeClass Attribute Class OperationClass Operation AttributesAttributes OperationsOperations : User: User aUseraUser : User: User aUseraUser %
  • 79. Characteristics of a ClassCharacteristics of a Class  Class attributes/operations: underlined  Properties of attributes: ◦ “/” attribute name: derived attribute ◦ {optional}: null values permitted  Properties of operations: ◦ {query}: operation without side effects ◦ {sequential}, {guarded}, {concurrent}: kind of concurrency  Visibilities: ◦ + ... public ◦ - ... private ◦ # ... protected %!
  • 80. Abstract ClassAbstract Class  Cannot be instantiated  Useful for generalization hierarchies only  Factors out common properties of subclasses  The same notation is used in order to distinguish between abstract operations and implemented operations EntryEntry {abstract}{abstract} EntryEntryoror %"
  • 81. Excursion (1/3)Excursion (1/3) Identification of ClassesIdentification of Classes Linguistic analysis of the problem description - extraction of nouns Rules of thumb: ◦ elimination of irrelevant terms ◦ elimination of names of values ◦ elimination of vague terms ◦ identification of attributes ◦ identification of operations ◦ elimination of terms which are in fact relationships [cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983] %#
  • 82. Excursion (2/3)Excursion (2/3) Identification of AttributesIdentification of Attributes Linguistic analysis of the problem description - extraction of adjectives and participles Rules of thumb: ◦ attributes describe objects and should be neither class- valued nor multi-valued ◦ derived attributes should be marked as such ◦ context-dependent attributes should be assigned to associations rather than to classes The list of attributes is usually incomplete in the problem description [cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983] %$
  • 83. Excursion (3/3)Excursion (3/3) Identification of OperationsIdentification of Operations Linguistic analysis of the problem description - extraction of verbs Rules of thumb: ◦ which operations can be executed by a certain object ◦ not only the current requirements should be considered, but also reusability should be taken into account ◦ which events are expected ◦ which objects can react to these events ◦ which other events are raised in turn [cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983] %%
  • 84. Classes in Different PhasesClasses in Different Phases / visualization: Color/ visualization: Color start: DateTimestart: DateTime description: Stringdescription: String duration: Timeduration: Time hyperlink[0..1]: URLhyperlink[0..1]: URL type: AppointmentTypetype: AppointmentType numberOfAppointments: IntnumberOfAppointments: Int AppointmentAppointment - startDate: Date- startDate: Date - startTime: Time = “09:00”- startTime: Time = “09:00” - duration: Time = “01:00”- duration: Time = “01:00” - description: String = ""- description: String = "" +visualization(): Color+visualization(): Color +collidesWith (t: Appointment):+collidesWith (t: Appointment): boolbool ...... «entity»«entity» AppointmentAppointment {persistence=persistent}{persistence=persistent} {visualization = colorCode(type)}{visualization = colorCode(type)} Requirements Specification:Requirements Specification: Design:Design: ≅ ¬(t.startDate=startDate ∧ (t.startTime ≥ startTime+duration ∨ t.startTime+t.duration ≤ startTime))NoteNote ii
  • 85. Association (1/3)Association (1/3)  Association between classes ◦ association name (optional) ◦ arrow above each edge expresses reading direction (optional) ◦ arrow at the end of an edge expresses navigation direction (optional) ◦ each end of an association is defined by means of multiplicity ◦ for a binary association, the multiplicity on the target end constrains how many objects of the target class may be associated with a given single object from the other (source) end  Link between objects ◦ represents an instance of an association CalendarCalendar AppointmentAppointment attachedToattachedTo1..*1..* ** aCalendar :aCalendar : CalendarCalendar a1:Appointmenta1:Appointment attachedToattachedTo attachedToattachedTo a2:Appointmenta2:Appointment i
  • 86. Association (2/3)Association (2/3) MultiplicityMultiplicity  arbitrary number “ * ”  a range is specified by means of “ .. ”  possible numbers are separated by means of commas exactly 1: 1 ≥ 0: * (or 0..*) 0 ∨ 1: 0..1 fixed number (e.g. 3): 3 range (e.g. 3 or more): 3..* range (e.g. 3-6): 3..6 enumeration (e.g. 3,6,7,8,9): 3, 6..9 i
  • 87. Association (3/3)Association (3/3) RoleRole Classes play roles within associations ◦ a single class can play more than one role i PersonPerson InsuranceInsurance ContractContract InsuranceInsurance CompanyCompany insurerinsurer 11 issued byissued by 0..*0..* referefe rsrs toto 1..*1..* 0..*0..* policyholderpolicyholder husbandhusband married tomarried to EmployeeEmployee superiorsuperior subordinatesubordinate 0..*0..* 0..10..1 0..10..10..10..1 wifewife married to is stillmarried to is still incompletelyincompletely specified...specified... 0..*0..* 0..*0..* peerpeer
  • 88. Properties of Associations (1/2)Properties of Associations (1/2)  {sorted}  {ordered} Ordering is independent of QueueItem attributes. CalendarCalendar isOpenisOpen AppointmentAppointment /visualization/visualization startstart descriptiondescription durationduration typetype {sorted}{sorted} **1..*1..* QueueQueue QueueItemQueueItem 11 containscontains ** {ordered}{ordered} i!
  • 89. Properties of Associations (2/2)Properties of Associations (2/2)  Exclusive Or {xor} ◦ only one of a set of possible associations can be instantiated for a certain object at a certain time  {subset} 1..*1..* ToDoEntryToDoEntry {sorted}{sorted} 1..*1..* AppointmentAppointment {xor}{xor} {sorted}{sorted} SerialEntrySerialEntry 11 1 UserUser AppointmentAppointment 1..*1..* participatesparticipates ** **{subset}{subset} coordinatescoordinates 11 participantparticipant coordinatorcoordinator i"
  • 90. Qualified AssociationQualified Association  A Qualifier is an attribute or a list of attributes ◦ whose values partition the objects of the associated class in a disjoint manner ◦ in most cases, multiplicity is reduced to one  Represents a property of the association BankBank PersonPerson account#account# ** 0..10..1 BankBank PersonPerson ** ** GroupOfParticipantsGroupOfParticipants UserUser namename groupNamegroupName 1..*1..* 11 11 ** consistsOfconsistsOf ParticipantParticipant OwnerOwner managesmanages i#
  • 91. Association Class (1/2)Association Class (1/2)  Necessary in case of m:n-associations with attributes:  It enhances flexibility in case of 1:1 and 1:n-associations: UserUser AppointmentAppointment**1..* isRelocatableisRelocatable CompanyCompany namename addressaddress ** PersonPerson namename socSec#socSec# addressaddress loanloan positionposition EmploymentEmployment loanloan positionposition 11 associationassociation classclass {{ ParticipationParticipation i$
  • 92. Association Class (2/2)Association Class (2/2) Object ClassObject Class ≠≠ Association ClassAssociation Class Person Project** Employment qualificationProfile hours dailyRate Person Project ** Employment qualificationProfile hours dailyRate 1 1 P1P1 E1E1 E3E3 E4E4 Pr1Pr1 P2P2 Pr2Pr2 E2E2 P1P1 E1E1 E3E3 E4E4 Pr1Pr1 P2P2 Pr2Pr2 i%
  • 93. N-ary AssociationN-ary Association Relationship between more than two classes ◦ navigation direction cannot be specified Example of a ternary association: CalendarCalendar AppointmentTypeAppointmentTypeUserUser ** **** associationassociation classclass AuthorizationAuthorization set of [r, w, d]set of [r, w, d] validateAuth(...)validateAuth(...) i
  • 94. AggregationAggregation Aggregation is a special kind of association having the following properties: ◦ Transitivity: C is part of B and B is part of A ⇒ C is part of A ◦ Anti-Symmetry: B is part of A ⇒ A is NOT part of B UML supports two kinds of aggregation: ◦ “Weak” Aggregation ◦ Composition 
  • 95. Weak AggregationWeak Aggregation The multiplicity at the aggregate end may be > 1 Properties: ◦ weak relationship, i.e., parts are independent of the whole ◦ there is almost no propagation semantics ◦ the aggregated objects form a directed, acyclic graph GroupOfPersonsGroupOfPersons UserUser ** AA BB * * 
  • 96. CompositionComposition  The multiplicity at the aggregate end must be <= 1  Properties: ◦ a certain part can be incorporated at a certain time in at most one composite object only ◦ the parts are dependent on the composite object ◦ propagation semantics ◦ the composite objects form a tree AA BB DocumentDocument AnnotationAnnotation GraphicGraphic ParagraphParagraph * * * * * 1 0..1 * 
  • 97. Composition vs.AssociationComposition vs.Association Rules of ThumbRules of Thumb  Physically embedded vs. references: ◦ the parts are physically embedded within the composite object ◦ objects are associated by means of references  Visibility: ◦ the part is visible for the composite object only ◦ the visibility of the associated object is public  LifeTime: ◦ the composite object creates and deletes its parts ◦ there is no existential dependency between associated objects  Copy Semantics: ◦ composite objects and parts are copied together ◦ only the references to associated objects are copied 
  • 98. Generalization (1/2)Generalization (1/2)  is a taxonomic relationship between a specialized class and a more general class ◦ the specialized one inherits all properties of the generalized one ◦ additional properties can be added ◦ an instance of the subclass can be used wherever an instance of the superclass is allowed (at least syntactically) ◦ multiple inheritance is also allowed: University MemberUniversity Member StudentStudent LecturerLecturer InstructorInstructor ...... The model contains moreThe model contains more subclasses than actuallysubclasses than actually shown in this diagramshown in this diagram {overlapping}{overlapping} !
  • 99. Generalization (2/2)Generalization (2/2) Properties of Generalization: ◦ non-complete / complete (default)  complete: all possible subclasses are already part of the model (but not necessarily visualized!) ◦ overlapping / disjoint (default)  2 interpretations of overlapping:  Concerning multiple inheritance: two or more subclasses can have again common subclasses (e.g. Instructor)  Concerning multiple classification: an object can be instance of more than one subclass EntryEntry SerialEntrySerialEntry ToDoEntryToDoEntry EmployeeEmployee {complete,{complete, disjoint}disjoint} {incomplete,{incomplete, overlapping}overlapping} AppointmentAppointment TechnicalTechnical EmployeeEmployee AdministrativeAdministrative EmployeeEmployee 2 alternative2 alternative notationsnotations "
  • 100. Example CALENDARIUMExample CALENDARIUM Extract of the Class Diagram (1/2)Extract of the Class Diagram (1/2) /visualization: Color/visualization: Color description: Stringdescription: String type: App’tmentTypetype: App’tmentType EntryEntry isOpen: boolisOpen: bool CalendarCalendar ViewView namename authorizationauthorization UserUser 1..*1..* ** partici-partici- patespates visualizesvisualizes ** ** is-is- AttachedToAttachedTo {sorted}{sorted} ** 1..*1..* CALENDARIUMCALENDARIUM NotificationNotification managesmanagesmanagesmanages **** isDirectedToisDirectedTo remindsOfremindsOf deadline: Datedeadline: Date ToDoEntryToDoEntry durationduration frequencyfrequency Series EntrySeries Entry start: DateTimestart: DateTime duration: Timeduration: Time hyperlink [0..1]: URLhyperlink [0..1]: URL nOfAppts: IntnOfAppts: Int AppointmentAppointment 11 {sorted}{sorted} 11 {{xorxor}} ** ** /collidesWith/collidesWith 1..* {sorted}1..* {sorted} 1..*1..* GroupOfPersonsGroupOfPersons ** ** ** ** 0..30..3 11 1111 #
  • 101. Example CALENDARIUMExample CALENDARIUM Extract of the Class Diagram (2/2)Extract of the Class Diagram (2/2) C_User(b:User)C_User(b:User) C_User()C_User() start()start() finish()finish() ««controlcontrol»» C_UserC_User B_User(b:User)B_User(b:User) validate():boolvalidate():bool start()start() «boundary» B_UserB_User User()User() save()save() delete()delete() ««entityentity»» UserUser ««controlcontrol»» CALENDARIUMCALENDARIUM «instantiate»«instantiate» «instantiate»«instantiate» 0..10..1 11 11 11 $
  • 102. Template ClassTemplate Class A template class describes a “family” of classes on the basis of formal parameters ◦ each class is specified by binding the parameters with actual values Alternative 1:Alternative 1: Array<Point,3>Array<Point,3> Alternative 2:Alternative 2: ListOfPointsListOfPoints «bind» (Point,3)«bind» (Point,3) ArrayArray T,k: IntT,k: Int length: 0..klength: 0..k ...... putAt (e: T, i: Int)putAt (e: T, i: Int) at (i: Int): Tat (i: Int): T i
  • 103. INTERFACE MODELINTERFACE MODEL UML Diagrams in Requirement Specification Phase 
  • 104. InterfaceInterface  Required behavior is defined by specifying the necessary operations ◦ of a class ◦ of a component ◦ of a package  Difference to abstract classes ◦ abstract class contains operations AND attributes ◦ abstract class can be realized by subclasses only, whereas an interface can be realized by means of arbitrary classes  Classes realizing a certain interface (supplier) can contain additional operations  Classes using an interface (clients) are not forced to use all available operations 
  • 105. Example CALENDARIUMExample CALENDARIUM Interface “SMTPServer”Interface “SMTPServer” Email (String to, String message)Email (String to, String message) notify()notify() EmailEmail open (String hostId, int port)open (String hostId, int port) sendmsg (String from,sendmsg (String from, String to,String to, String subject,String subject, String message)String message) close()close() «interface»«interface» SMTPServerSMTPServer QsmtpQsmtp +open (String hostId,+open (String hostId, int port=25)int port=25) +sendmsg (String from,+sendmsg (String from, String to,String to, String subject,String subject, String message)String message) +close()+close() +Qsmtp ()+Qsmtp () #finalize()#finalize() «use»«use» mailer.open (“mailbox.univie.ac.at”, 25); mailer.sendmsg (“CALENDARIUM“, “hitz@acm.org”, “Reminder”, “Meeting at 12.1.99, 14:00”); mailer.close(); QsmtpQsmtp SMTPServerSMTPServer EmailEmailClientClient SupplierSupplier «realize»«realize» 
  • 106. Benefits of InterfacesBenefits of Interfaces  By means of interfaces, the inheritance of implementations can be separated from the inheritance of interfaces ◦ frameworks especially are built on the basis of interfaces  A class can be seen as a set of roles which are specified by means of use cases ◦ each interface represents a role played by the class ◦ different clients use only those roles which are interesting for them ◦ by means of interfaces, different views on a class can be realized for different clients ◦ coupling is reduced, flexibility with respect to maintenance and extensibility is increased 
  • 107. Interface ModelInterface Model Goals ◦ Specification of the user interface for each use case / actor not explicitly supported by UML ◦ Specification of the internal interfaces supported by UML in terms of interfaces !
  • 108. User Interface SpecificationUser Interface Specification Example (1/2 - Poor Man’s Prototype)Example (1/2 - Poor Man’s Prototype) WednesdayWednesday 3030 10-1210-12 ConsultConsult Hour (2)Hour (2) 66 1313 10-1210-12 ConsultConsult Hour (2)Hour (2) 11-1211-12 ConsultConsult Hour (1)Hour (1) 2020 10-1210-12 ConsultConsult Hour (2)Hour (2) 11-1211-12 ConsultConsult Hour (1)Hour (1) 2727 10-1210-12 ConsultConsult Hour (2)Hour (2) MondayMonday 2828 44 1111 MeetingMeeting (1,2)(1,2) 1818 2525 TuesdayTuesday 2929 55 1212 14-1714-17 UMLUML Meeting (2)Meeting (2) 1919 2626 ThursdayThursday 3131 77 1414 8-9:308-9:30 InfoSys IIInfoSys II (1)(1) 2121 8-9:308-9:30 InfoSys IIInfoSys II (1)(1) 2828 8-9:308-9:30 InfoSys IIInfoSys II (1)(1) FridayFriday 11 88 16-1816-18 C++ (2)C++ (2) 1515 16-1816-18 C++ (2)C++ (2) 2222 16-1816-18 C++ (2)C++ (2) 2929 16-1816-18 C++ (2)C++ (2) 17-18 Info-17-18 Info- sys II Exam.sys II Exam. SaturdaySaturday 22 99 1616 2323 3030 SundaySunday 33 *Konstan-*Konstan- tin (2)tin (2) 1010 1717 2424 3131 GK (1)GK (1) MH (2)MH (2) JanuaryJanuary 19991999 TT WW MM JJ "
  • 109. User Interface SpecificationUser Interface Specification Example (2/2 - GUI Builder Prototype)Example (2/2 - GUI Builder Prototype) #
  • 110. OutlineOutline Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UMLSyntaxUMLSyntax and Semanticsand Semantics 
  • 111. Phase 2:AnalysisPhase 2:Analysis  Goal is a detailed analysis of problem domain and use cases ◦ complementation of the model by means of additional objects ◦ definition / refinement of the object‘s structure ◦ definition of the object‘s behavior ◦ definition of the interaction between the objects  Preservation of a certain level of abstraction enhances the potential of reusability  Categorization of objects increases locality of changes and therefore leads to a more stable system architecture ◦ entity objects ◦ boundary objects ◦ control objects !
  • 112. Models of the Analysis PhaseModels of the Analysis Phase Refining the Problem Domain Model Structure Model [constructed] [no additional refinements necessary][no additional refinements necessary][else][else] Constructing the Behavior Model Behavior Model [constructed] "
  • 113. Results of the Analysis PhaseResults of the Analysis Phase BehaviorBehavior ModelModel Analysis ModelAnalysis Model StructureStructure ModelModel «UML»«UML» Class DiagramClass Diagram 1111 11 «UML»«UML» Collaboration DiagramCollaboration Diagram ** «UML»«UML» Activity DiagramActivity Diagram ** «UML»«UML» Sequence DiagramSequence Diagram ** «UML»«UML» Statechart DiagramStatechart Diagram ** #
  • 114. Structure ModelStructure Model The structure model is a refinement of the problem domain model ◦ a copy of the problem domain model is used as the basis of a contract between client and developer Partitioning of the Structure Model ◦ UML Packages $
  • 115. Example CALENDARIUMExample CALENDARIUM Extract of the Class Diagram (1/2)Extract of the Class Diagram (1/2) /visualization: Color/visualization: Color description: Stringdescription: String type: App’tmentTypetype: App’tmentType EntryEntry isOpen: boolisOpen: bool CalendarCalendar ViewView namename authorizationauthorization UserUser 1..*1..* ** partici-partici- patespates visualizesvisualizes ** ** is-is- AttachedToAttachedTo {sorted}{sorted} ** 1..*1..* CALENDARIUMCALENDARIUM NotificationNotification managesmanagesmanagesmanages **** isDirectedToisDirectedTo remindsOfremindsOf deadline: Datedeadline: Date ToDoEntryToDoEntry durationduration frequencyfrequency Series EntrySeries Entry start: DateTimestart: DateTime duration: Timeduration: Time hyperlink [0..1]: URLhyperlink [0..1]: URL nOfAppts: IntnOfAppts: Int AppointmentAppointment 11 {sorted}{sorted} 11 {{xorxor}} ** ** /collidesWith/collidesWith 1..* {sorted}1..* {sorted} 1..*1..* GroupOfPersonsGroupOfPersons ** ** ** ** 0..30..3 11 1111 %
  • 116. Example CALENDARIUMExample CALENDARIUM Extract of the Class Diagram (2/2)Extract of the Class Diagram (2/2) C_User(b:User)C_User(b:User) C_User()C_User() start()start() finish()finish() ««controlcontrol»» C_UserC_User B_User(b:User)B_User(b:User) validate():boolvalidate():bool start()start() «boundary» B_UserB_User User()User() save()save() delete()delete() ««entityentity»» UserUser ««controlcontrol»» CALENDARIUMCALENDARIUM «instantiate»«instantiate» «instantiate»«instantiate» 0..10..1 11 11 11  i
  • 117. Partitioning of the Class DiagramPartitioning of the Class Diagram PackagePackage  Large class diagrams are quickly getting complex and confusing  UML abstraction mechanism: Package  Criteria for partitioning: ◦ Functional cohesion ◦ Informational cohesion ◦ Access control ◦ Distribution structure ◦ ....  Elements of a package may be all kinds of UML model elements  Visibility of elements may be restricted (+,#,-)  
  • 118. Dependencies between PackagesDependencies between Packages  Elements of one package require elements of another one ◦ «access»-dependency on the level of packages ◦ forms a graph ◦ «access»-dependencies are NOT transitive!  Certain elements of a package require certain elements of another one ◦ specific relationship on the element level ◦ or incorporation by means of qualification PackagePackage XX PackagePackage YY ««accessaccess»» Class AClass A Package XPackage X Package XPackage X Class AClass A Package YPackage Y ::Class C::Class C Class BClass B Class DClass D Package YPackage Y ««accessaccess»» Class CClass CClass BClass B  
  • 119. Kinds of PackagesKinds of Packages  Package ◦ represents a grouping mechanism only  Subsystem ◦ allows also the specification of the behavior of a package ◦ interfaces and operations may be specified ◦ icon:  Model ◦ describes a certain view of the system to be modeled ◦ icon: ∆ «subsystemsubsystem» «modelmodel» SS PP MM  
  • 120. Packages and SubsystemsPackages and Subsystems  Interfaces offer part of the behavior of packages (subsystems!) ◦ realized by means of an arbitrary number of classes within the package  Packages can be nested ◦ semantics is determined by the implementation language ◦ arbitrary depth ◦ package hierarchy forms a tree Package XPackage X Class AClass A Package YPackage Y Class BClass B Class AClass A Class BClass B Package XPackage X Class CClass C Class DClass D ««subsystemsubsystem»» Package YPackage Y II 
  • 121. GeneralizationGeneralization  Generalization relationships between packages ControllerController DiagramDiagram ElementsElements DomainDomain ElementsElements GraphicsGraphics CoreCore MotifCoreMotifCore WindowsCoreWindowsCore MotifMotif WindowingWindowing SystemSystem MSWindowsMSWindows «subsystem»«subsystem» EditorEditor «access»«access» «access»«access» «access»«access» «access»«access» «access»«access» «access»«access» ⇒⇒ There exists at least oneThere exists at least one generalization relationshipgeneralization relationship between the elements of thebetween the elements of the respective packagesrespective packages  !
  • 122. Example CALENDARIUMExample CALENDARIUM PackagesPackages «system«systemModelModel»» CALENDARIUMCALENDARIUM User InterfaceUser Interface B_CalendarB_Calendar B_CalendariumB_Calendarium B_AppointmentB_Appointment ...... Appointment ManagerAppointment Manager AppointmentAppointment CalendariumCalendariumUserUser ...... CalendarCalendar System AdministrationSystem Administration «access»«access» «access»«access» «access»«access»  "
  • 123. ExcursionExcursion Employment of PackagesEmployment of Packages  Bottom-up approach ◦ a-posteriori-decomposition of class diagrams ◦ goal is small units and intuitive groupings ◦ packages are “automatically” disjoint  Top-down approach ◦ a-priori-allocation of use cases to packages ◦ goal is distribution of work ◦ similar concepts may occur several times in multiple packages  Normalization of packages eliminates redundancies ◦ recognize common properties (Generalization?) ◦ factor out classes ◦ explicitly import classes and operations  #
  • 124. Behavioral ModelBehavioral Model Goal ◦ Specification of the inter-object behavior (interaction structure, responsibilities) interaction diagrams:  sequence diagram  collaboration diagram statechart diagram activity diagram ◦ Specification of the intra-object behavior statechart diagram  $
  • 125. Interaction DiagramsInteraction Diagrams Illustrate the communication between objects Purpose: ◦ Specifying the realization of an operation ◦ Specifying the realization of a use case 2 Kinds: ◦ generic kind, i.e., all possible scenarios are described by means of branching and iteration ◦ exemplary kind, i.e., one certain scenario is described  %
  • 126. Interaction DiagramsInteraction Diagrams Sequence and Collaboration DiagramSequence and Collaboration Diagram  Both specify the same information  However, each emphasizes different aspects ◦ sequence diagram is “temporally”-oriented  shows graphically the order of messages  does not show how to get the receiver object ◦ collaboration diagram is “spatially”-oriented  shows the static and dynamic relationships between objects - the context aspect  the order of messages is expressed by means of decimal classification only  time is no dimension on its own 11 1.11.1 1.21.2 !i
  • 127. Interaction DiagramsInteraction Diagrams Sequence DiagramSequence Diagram  Objects are represented by means of vertical lines (“lifelines”) ◦ depict also the time line ◦ the horizontal ordering of the objects has no meaning  An activation (“focus of control”) shows the period during which an object is directly or indirectly executing an operation  Messages between objects are denoted by means of arrows  [Guard] specifies conditional sending of messages : User: User : Calendar: Calendar a2:Appointmenta2:Appointment totalDuration()totalDuration() return(total)return(total) duration()duration() return(meetingTime)return(meetingTime) duration()duration() return(meetingTime)return(meetingTime) a1:Appointmenta1:Appointment !
  • 128. return(total)return(total) Interaction DiagramsInteraction Diagrams Sequence Diagram - ExampleSequence Diagram - Example : User: User : Calendar: Calendar a: Appointmenta: Appointment insertAppt(“a1”)insertAppt(“a1”) new()new() deleteAppt(“a2”)deleteAppt(“a2”) delete()delete() totalDuration()totalDuration() [aType[aType ≠≠ private] duration()private] duration() a = 1 .. nOfApptsa = 1 .. nOfAppts a1:Appointmenta1:Appointment a2:Appointmenta2:Appointment return(meetingTime)return(meetingTime) type()type() return(aType)return(aType) exampleexample !
  • 129. Interaction DiagramsInteraction Diagrams Collaboration DiagramCollaboration Diagram  Examples of messages (events): ◦ simple message: 2: display(x,y) ◦ nested call including return value: 1.3.1: p:= find (specs) ◦ conditional message: [x<0] 4: invert(x,color) ◦ synchronization with other threads and iterations: A3, B4 / C3.1*|| [i:= 1..n]: update 1.1 : meetingTime:= duration()1.1 : meetingTime:= duration() : User: User a1:Appointmenta1:Appointment 1 : total:= totalDuration()1 : total:= totalDuration() : Calendar: Calendar 1.2 : meetingTime:= duration()1.2 : meetingTime:= duration() a2:Appointmenta2:Appointment !
  • 130. 3: total := totalDuration()3: total := totalDuration() : User: User Interaction DiagramsInteraction Diagrams Collaboration Diagram - ExampleCollaboration Diagram - Example : Appointment: Appointment a1:Appointmenta1:Appointment {new}{new} 1: insertAppt(“a1”)1: insertAppt(“a1”) 2: deleteAppt(“a2”)2: deleteAppt(“a2”) 1.1:1.1: newnew()() 2.1:2.1: deletedelete()() a2:Appointmenta2:Appointment {destroyed}{destroyed} 3.1.1: a := select(i)3.1.1: a := select(i) a:Appointmenta:Appointment 3.1.3 [aType3.1.3 [aType≠≠private]:private]: meetingTime := duration()meetingTime := duration() 3.1*[i=1..nOfAppts]:complete3.1*[i=1..nOfAppts]:complete 3.1.2: aType := type ()3.1.2: aType := type () : Calendar: Calendar !
  • 131. Interaction DiagramsInteraction Diagrams Relationships & Roles in Collaboration DiagramsRelationships & Roles in Collaboration Diagrams  The kind of relationship between sender object and receiver object may be specified (:: Sequence Diagram!) ◦ attribute «association» (default) ◦ global variable «global» ◦ local variable (temporary object) «local» ◦ parameter «parameter» ◦ self referencing «self» :Calendarium:Calendarium : User: User loggedInUserloggedInUser «local»«local» readAuthorization( )readAuthorization( ) !!
  • 132. Interaction DiagramsInteraction Diagrams Collaboration Diagram - ExampleCollaboration Diagram - Example :Controller:Controller :Window:Window :Line:Line {new}{new} left: Beadleft: Bead right: Beadright: Bead windowwindow redisplay()redisplay() ««parameterparameter» window» window 1.1.3.1: add(self)1.1.3.1: add(self) contents {new}contents {new} 1.1.2: create(r0,r1)1.1.2: create(r0,r1) 1.1.3: display(window)1.1.3: display(window) 1: displayPositions1: displayPositions (window)(window) wirewire 1.1.1b: r1:=position()1.1.1b: r1:=position()1.1.1a: r0:=position()1.1.1a: r0:=position() 1.1*[i:=1..n]:1.1*[i:=1..n]: drawdraw Segment(i)Segment(i) wire: Wirewire: Wire ««locallocal» line» line i-1i-1 ii ««selfself»» [from Rumbaugh et al. 1999, p.202][from Rumbaugh et al. 1999, p.202] !"
  • 133. Interaction DiagramsInteraction Diagrams Numbering of MessagesNumbering of Messages  Ordering of messages is defined by means of a nested numbering scheme  “Decimal classification”: ◦ n.m … mth message with the realization of message n ◦ If the only differences between two or more message numbers are the names at their end, then they may be potentially executed in parallel: 1.1.1a can be executed at the same time as 1.1.1b (both represent message 1.1.1)  In case of asynchronous control flow decimal classification is not used !#
  • 134. Interaction DiagramsInteraction Diagrams Kinds of Control FlowKinds of Control Flow  Synchronous ◦ a nested control flow, typically realized as a procedure call  Return ◦ optional  Unspecified ◦ is used if kind of control flow is not of interest at this point in time ◦ (however, typically asynchronous)  Asynchronous holds for sequence and collaboration diagrams !$
  • 135. Example CALENDARIUMExample CALENDARIUM Sequence Diagram “Insert Appointment” (1/2)Sequence Diagram “Insert Appointment” (1/2) : B_Calen-: B_Calen- dariumdarium c : Calen-c : Calen- dariumdarium User:User: ClassClass Authorization :Authorization : ClassClass ca :ca : CalendarCalendar pa :pa : UserUser login(user,pwd)login(user,pwd) login(user,pwd)login(user,pwd) checkAuthorization (user, pa, “write“)checkAuthorization (user, pa, “write“) forall pa in particforall pa in partic checkCollision (bD, eD)checkCollision (bD, eD) forall pa in particforall pa in partic checkCollision (bD, eD)checkCollision (bD, eD) okok authorizedauthorized storeApptstoreAppt (partic,appt)(partic,appt) okokokok newnew apptappt okok login(...)login(...) !%
  • 136. Example CALENDARIUMExample CALENDARIUM Sequence Diagram “Insert Appointment” (2/2)Sequence Diagram “Insert Appointment” (2/2) : B_Calen-: B_Calen- dariumdarium c : Calen-c : Calen- dariumdarium User:User: ClassClass Authorization :Authorization : ClassClass ca :ca : CalendarCalendar d_new :d_new : AppointmentAppointment pa :pa : UserUser d_new := new (...)d_new := new (...) forall pa in particforall pa in partic insertAppt(d_new)insertAppt(d_new) insertAppt(d_new)insertAppt(d_new) cv : Calendarcv : Calendar ViewView notify(d_new)notify(d_new) update( )update( ) forall cvforall cv donedone Observer !Observer ! "i
  • 137. Statechart DiagramStatechart Diagram describes ◦ the life cycle of the instances of a class ◦ the execution of an operation on an instance of a class models ◦ the possible states of the instances of a class ◦ the possible transitions from one state to another one ◦ the events firing transitions ◦ the operations (actions and activities) which are executed within states or during a transition "
  • 138. Statechart DiagramStatechart Diagram Kinds of EventsKinds of Events  CallEvent: receipt of a message: cancel  SignalEvent: receipt of a signal: left_button_down  ChangeEvent: a condition evaluates to true: when(x<y)  TimeEvent: relative or absolute point in time: after(5 sec.) AppointmentAppointment startstart durationduration cancel ()cancel () delete ()delete () deletedelete deletedelete ActiveActive newnew CanceledCanceled cancel FinishedFinished whenwhen(start+duration<=now)(start+duration<=now) Enter DetailsEnter Details ““automatic transition”automatic transition” "
  • 139. Statechart DiagramsStatechart Diagrams StateState  State: ◦ state (in the strict sense) ◦ final state  Pseudostates: ◦ initial state ◦ history state, synch state, fork, join etc.  Action and Activity: ◦ action: atomic and non-interruptible ◦ activity: complex (possibly nested statechart diagram) and interruptible  Action / Activity within a state: ◦ entry / action action is executed when entering the state ◦ exit / action action is executed when leaving the state ◦ do / activity activity is executed, parameters are allowed ◦ event / action event is handled within the state ss "
  • 140. Statechart DiagramStatechart Diagram State TransitionState Transition  A state transition takes place, if ◦ the event occurs ◦ and the guard is true  Default Assumptions ◦ the lack of an event corresponds to the event “activity is finished” (completion transition) ◦ the lack of a condition corresponds to [true]  Actions on state transitions are possible ◦ Special action: Sending a message to another object send receiver.message() ◦ Example: right-mouse-down (loc) [ loc in window ] / obj:= pick-obj (loc); send obj.highlight() "
  • 141. Statechart DiagramStatechart Diagram ExampleExample modemode ButtonButton inc / min:= min+1inc / min:= min+1inc / hours:= hours+1inc / hours:= hours+1 modemode ButtonButton modeButtonmodeButton DigitalWatchDigitalWatch modeButton()modeButton() inc()inc() Display timeDisplay time do/ displaydo/ display current timecurrent time Set hoursSet hours entry/ beepentry/ beep do/ display hoursdo/ display hours Set minutesSet minutes entry/ beepentry/ beep do/ display minutesdo/ display minutes newnew ““self transition”self transition” "!
  • 142. Statechart DiagramStatechart Diagram Refining Statechart DiagramsRefining Statechart Diagrams  Refinement of a state by means of a nested statechart diagram ◦ disjoint substates (OR-refinement) exactly one substate is active in case that the superordinate state (complex state, super state) is active ◦ parallel substates (AND-refinement) all substates are active in case that the super state is active; the substates are again or-refined AA ZZ BB ZZ AA BB ""
  • 143. Statechart DiagramStatechart Diagram Example “Appointment” (1/2)Example “Appointment” (1/2) ActiveActive CanceCancelledlled cancelcancel FinishedFinished whenwhen(start+duration<=now)(start+duration<=now) deletedelete Enter DetailsEnter Details newnew "#
  • 144. Statechart DiagramStatechart Diagram Example “Appointment” (2/2)Example “Appointment” (2/2) RescheduleReschedule do/ notify participantsdo/ notify participants and update viewsand update views CurrentCurrent reschedule (newStart)reschedule (newStart) [not in Current][not in Current] / start:=newStart/ start:=newStart Not CurrentNot Current whenwhen(start<=now)(start<=now) whenwhen(start+duration<=now)(start+duration<=now) FixedFixed ActiveActive OccurredOccurred CanceCancelledlled cancelcancel "$
  • 145. Statechart DiagramStatechart Diagram History State (1/2)History State (1/2)  Complex states are able to remember the internal state which had been left due to an interruption  At a later point in time, one can go back to this internal state by means of a transition from superordinate states via a dummy state “H” ◦ all entry actions are executed again  By means of “H*” all states along the given nesting depth are memorized "%
  • 146. Statechart DiagramStatechart Diagram History State (2/2)History State (2/2) NormalNormal FrozenFrozen FreezeFreeze UnfreezeUnfreeze ++ -- whenwhen(Balance < 0)(Balance < 0) whenwhen(Balance > 0)(Balance > 0) HH Withdrawal(b) [not in Frozen]Withdrawal(b) [not in Frozen] /Balance := Balance - b/Balance := Balance - b Deposit(b)Deposit(b) / Balance :=/ Balance := Balance + bBalance + b BalancingBalancing [not in Frozen][not in Frozen] / Balance := 0/ Balance := 0 OpenOpen / Balance := 0/ Balance := 0 #i
  • 147. Statechart DiagramStatechart Diagram Semantics of AND-RefinementsSemantics of AND-Refinements FreezeFreeze UnfreezeUnfreeze +/N -/N whenwhen(Balance < 0)(Balance < 0) whenwhen(Balance > 0)(Balance > 0) H Withdrawal(b)Withdrawal(b) /Balance := Balance - b/Balance := Balance - b BalancingBalancing / Balance := 0/ Balance := 0 OpenOpen / Balance := 0/ Balance := 0 +/F -/F when(Balance < 0)when(Balance < 0) when(Balance > 0)when(Balance > 0)H* Deposit(b) / Balance := Balance + bDeposit(b) / Balance := Balance + b FreezeFreeze UnfreezeUnfreeze #
  • 148. Statechart DiagramStatechart Diagram Stubbed StateStubbed State QuestionQuestion yesyes nono QuestionQuestion ““F1“ / display helpF1“ / display help do / pose questiondo / pose question yesyes nono ““njet“njet“““da“da“ #
  • 149. Statechart DiagramStatechart Diagram Synch StateSynch State  Synchronization of control between two concurrent regions  “Producer-Consumer”  Upon activation, a token is inserted into the synch state (at most k tokens, k = 1, 2, … *)  Outgoing transition can fire if at least one token is available kk P1P1 P2P2 C1C1 C2C2 #
  • 150. Activity DiagramActivity Diagram Concepts (1/5)Concepts (1/5)  Describes a process consisting of: ◦ actions and activities ◦ control flow ◦ input and output objects, object flow ◦ responsible objects  Action ◦ atomic ◦ represented by an action state  Activity ◦ can be further decomposed hierarchically ◦ represented by a subactivity state Define start ofDefine start of contractcontract Check plausibilityCheck plausibility #
  • 151. Activity DiagramActivity Diagram Concepts (2/5)Concepts (2/5)  Control flow ◦ order of actions / activities ◦ represented by transition arrows ◦ no events - as soon as execution of the predecessor is finished, execution of the successor is started ◦ guards and (send-) actions are allowed  Responsibilities (swimlane) ◦ responsible “objects”can be assigned ◦ e.g., objects of the system to be realized, actors or organizational units AA BB [not[not finished]finished] #!
  • 152. Activity DiagramActivity Diagram Concepts (3/5)Concepts (3/5)  Start state: start of an activity diagram  End state: end of an activity diagram  Object flow ◦ from actions to objects ◦ from objects to actions ◦ the current state of the object may be specified ◦ in case that control flow and object flow are identical, only the object flow is drawn ContractContract [[computedcomputed ]] ComputeCompute contractcontract AuthorizeAuthorize contractcontract #"
  • 153. Activity DiagramActivity Diagram Concepts (4/5)Concepts (4/5)  Guard ◦ a transition may be annotated with a guard or further actions ◦ in this case, both the execution of the predecessor must be finished and the condition must be true in order to be able to execute the successor  Alternative Sequences ◦ either by means of mutually exclusive guards placed on the outgoing transitions of an action or ◦ by means of dedicated decision states [OK][OK] ComputeCompute contractcontract CheckCheck plausibilityplausibility ##
  • 154. Activity DiagramActivity Diagram Concepts (5/5)Concepts (5/5)  Decision state ◦ makes alternative sequences explicit ◦ complex decisions can be visualized by means of decision trees ◦ outgoing transitions are required to have mutually exclusive guards  Concurrency ◦ a fork denotes the starting point of the concurrent execution of activities/actions ◦ a join depicts the corresponding end ◦ conditional branches are possible [else][else] [bonus > 500][bonus > 500] ComputeCompute contractcontract #$
  • 155. Activity DiagramActivity Diagram Example (1/2)Example (1/2) Attach policyAttach policy holderholder AttachAttach insurance prod.insurance prod. EstablishEstablish covercover Define start ofDefine start of contractcontract CreateCreate contract#contract# Automatic ProcessingAutomatic ProcessingClaim ProcessingClaim Processing Claim CheckClaim Check CheckCheck plausibilityplausibility #%
  • 156. Activity DiagramActivity Diagram Example (2/2)Example (2/2) ComputeCompute contractcontract DrawDraw samplesample AuthorizeAuthorize contractcontract {{∆∆t<24h}t<24h} ReleaseRelease contractcontract ContractContract [released][released] ContractContract [authorized][authorized] ContractContract [computed][computed] [else][else] [bonus>500][bonus>500] [is a sample][is a sample][else][else] AutomaticAutomatic ProcessingProcessing Claim ProcessingClaim Processing SpecializedSpecialized Claim CheckClaim Check $i
  • 157. OutlineOutline Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UML SyntaxUML Syntax and Semanticsand Semantics $
  • 158. Phase 3: DesignPhase 3: Design  Previous focus: WHAT is required from the system New focus: HOW should the system fulfill these requirements ◦ implementation dependent decisions are made, constituting the basis for refining the analysis model  System design ◦ decomposition of the system into parts and distribution thereof ◦ concurrency and real-time aspects ◦ persistency mechanisms ◦ ...  Detailed design ◦ completing the class diagram by means of impl.dep. concepts ◦ completing the class properties (e.g. visibilities) ◦ decomposing structures which cannot be implemented as such $
  • 159. Models of the Design PhaseModels of the Design Phase Design Model [refined] Design Model System Design Detailed Design [else] [no further refinements necessary] $
  • 160. Results of the Design PhaseResults of the Design Phase «UML»«UML» ComponentComponent DiagramDiagram «UML»«UML» DeploymentDeployment DiagramDiagram ArchitecturalArchitectural DescriptionDescription StructuralStructural ModelModel BehavioralBehavioral ModelModel Design ModelDesign Model 11 11 11 11 11 $!
  • 161. DistributionDistribution Distribution Alternatives (1/2)Distribution Alternatives (1/2) Distributed User Interface Remote User Interface Distributed Application ApplicationApplication PresentationPresentation    DataData ManagementManagement $"
  • 162. DistributionDistribution Distribution Alternatives (2/2)Distribution Alternatives (2/2)  Distributed User Interface  Remote User Interface  Remote DB  Distributed DB  Distributed Application Complexity Security Consistency Reusability Distribution Costs Bottlenecks $#
  • 163. DistributionDistribution Component DiagramComponent Diagram  Describes SW-components and their dependencies ◦ source code components (can offer interfaces - Java) ◦ binary code components (can offer interfaces - OLE) ◦ executable code components: instances are represented by means of deployment diagrams  Packages can contain components and vice versa file3. javafile3. java file2. javafile2. javafile1.javafile1.java Compilation Dependencies II file4. javafile4. java $$
  • 164. DistributionDistribution Deployment Diagram (1/3)Deployment Diagram (1/3) Shows the actual HW configuration consisting of ◦ nodes (processors (default), I/O, ...) ◦ SW-components ◦ processes ◦ objects and of the communication channels between nodes Properties of nodes can be denoted by means of tagged values and/or stereotypes (e.g., capacity, reliability) Calen-Calen- dariumdarium ClientClient ** Calen-Calen- dariumdarium ServerServer DBDB ServerServer «internet»«internet» «device»«device» TapeTape $%
  • 165. DistributionDistribution Deployment Diagram (2/3)Deployment Diagram (2/3)  Possible system configuration: Calen-Calen- dariumdarium ServerServer DBDB ServerServerCalen-Calen- dariumdarium Client 2Client 2 Calen-Calen- dariumdarium Client 1Client 1 %i
  • 166. DistributionDistribution Deployment Diagram (3/3)Deployment Diagram (3/3) Objects - Processes - Components - Nodes: User Interface Appointment Manager Calendarium Client Calendar Server Program calendarium appobj t1:calThread ... System Administration DBAccessDB-Server Applet b_calendarium Calendarium Server «internet» «access» «access» «access» «access» %
  • 167. DistributionDistribution Migration between NodesMigration between Nodes notebooknotebook :Customer:Customer newCustomernewCustomer mainServermainServer :Customer:Customer newCustomernewCustomer «become»«become» %
  • 168. System DesignSystem Design ConcurrencyConcurrency  UML does not provide a dedicated diagram type in order to express different aspects of concurrency ◦ instead, concurrency aspects are incorporated into existing diagram types, in particular into behavior diagrams  Active objects are represented using rectangles with bold border lines ◦ in sequence diagrams, in addition, the whole lifeline is depicted as activation ◦ in collaboration diagrams, different objects sharing a certain process can be grouped together using a bolded rectangle  Implementation alternatives for active objects: ◦ heavyweight processes: own address space ◦ lightweight processes (threads): common address space %
  • 169. Concurrency in Sequence Diagrams (1/2)Concurrency in Sequence Diagrams (1/2) : Credit Registry : Local Credit Agency anUnfunded Order : Credit Agency authorizePurchase (312779, 8144-22-7999, $22,64) : Credit Authorization new(...) execute( ) lookup( ) authorize(...) authorize(...) authorized( ) authorized( )authorized( )return(true) : Funds Request %
  • 170. Concurrency in Sequence Diagrams (2/2)Concurrency in Sequence Diagrams (2/2) Objects may be used by multiple other objects in parallel An object is able to initiate parallel executions Server One Server Two System Clock currentTime currentTime Client Request Handler handleRequest [x<100] doPart [y>5] doPart %!
  • 171. Concurrency in Collaboration DiagramsConcurrency in Collaboration Diagrams  Concurrency is expressed by different names instead of numbers at the same level of the decimal classification  Synchronization is expressed by message numbers preceding a slash :Oven:Oven:Robot:Robot currentJobcurrentJob :TransferJob:TransferJob :Factory:Factory SchedulerScheduler :Factory:Factory JobMqrJobMqr jobjob 1:start(job)1:start(job) A2,B2 / 2:completed(job)A2,B2 / 2:completed(job) :FactoryManager:FactoryManager A1/A1/A2:completedA2:completed 1 / A1:start(job)1 / A1:start(job) B1/B1/B2:completedB2:completed 1 / B1:start(job)1 / B1:start(job) [cf.: Rumbaugh et al., 1999] %"
  • 172. System DesignSystem Design Real-Time (1/2)Real-Time (1/2)  Application areas for real-time systems: ◦ telecommunication, embedded systems, mobile computing, ...  Properties of real-time systems: ◦ reactive: reaction to events whose occurrence and order of occurrence cannot be predicted ◦ timeliness: correct reaction within certain time intervals ◦ dynamic: system components must be reconfigurable dynamically due to frequent changes of environmental characteristics ◦ concurrency ◦ distribution ◦ ... Proposal for an integration of the concepts of ROOM (Real Time Object Modeling Language, ObjecTime Inc.) in UML http://www.objecTime.com/uml/index.html %#
  • 173. System DesignSystem Design Real-Time (2/2)Real-Time (2/2)  The time axis may contain metrics information (time restrictions) ◦ duration for executing an operation ◦ duration for sending a message : Local Credit Agency : Credit Agency b: authorize() { c.sendTime - b.receiveTime < 0,1 sec } : Funds Request a: authorize() { d.receiveTime - a.sendTime < 1 sec } { b.receiveTime - b.sendTime < 0,5 sec } d: c: %$
  • 174. System DesignSystem Design PersistencePersistence  Decision about the type of persistence mechanism ◦ File system ◦ object-relational database system ◦ object-oriented database system  Selecting the classes which should be made persistent ◦ mapping of these classes to the selected persistence mechanism  Defining the transaction boundaries  Specifying the coupling between application and database (DB) %%
  • 175. PersistencePersistence Connecting to Relational DB - Alternative 1Connecting to Relational DB - Alternative 1  Database access is not decoupled from application specific behavior  Each persistent class performs the mapping and access to the underlying relations by itself  Disadvantages: ◦ high coupling between problem domain classes and DB structure ◦ DB-specific code is intermingled with different classes ◦ poor portability of the application, since changes of the DB structure influence the application and vice versa save() : Calendarium : Appointment makePersistent /* SQL-Code */ ii
  • 176. PersistencePersistence Connecting to Relational DB - Alternative 2Connecting to Relational DB - Alternative 2  Separation of DB access and application specific behavior ◦ for each persistent problem domain class, n DB classes are implemented, corresponding 1:1 to the DB relations ◦ these DB classes realize both, mapping and access to the DB relations  Disadvantages: ◦ inflexible, high maintenance overhead, poor scalability saveAppt(appt) : Calendarium : DBAppointment: DBManager : Appointment save (appt) get Description makePersistent i
  • 177. PersistencePersistence Connecting to Relational DB - Alternative 3Connecting to Relational DB - Alternative 3  Separation of DB access and application specific behavior ◦ there exists a generic interface to a relational DB, automatically realizing mapping and access to the relations  Can be realized by means of the Broker-pattern or by deriving from a persistent class save() : Calendarium : Termin : DBManager makePersistent(this) i
  • 178. PersistencePersistence Coupling Alternatives (1/2)Coupling Alternatives (1/2) A fat client ◦ all data from the database is located at the client (Calendarium is located at the client too) ◦ all checks are performed by the client B thin client ◦ on every check, the client accesses the Calendarium within the DB ◦ B1 methods are implemented on the basis of SQL-statements, operating on relational counterparts of the objects, namely the tuples within the DB (Alternative 1) B2 methods and all objects which are accessed are located within memory (Alternative 3) i
  • 179. PersistencePersistence Coupling Alternatives (2/2)Coupling Alternatives (2/2) «boundaryboundary» :X «SQLSQL» ClientClient ServerServerB1B1 X1X1 X2X2 X3X3 ClientClientAA ServerServer «useuse» «SQLSQL» :X1 :X2 :X3 ClientClient ServerServer B2B2 «useuse» «SQLSQL» :X1 :X2 :X3 i
  • 180. Example CALENDARIUMExample CALENDARIUM DB Access for “Insert Appointment”DB Access for “Insert Appointment” : B_Calen- darium c : Calen- darium «persistent» User : Class «persistent» Authorization : Class «persistent» ca : Calendar «persistent» u : User login(user,pwd)login(user,pwd) checkAuthoriz (user, pa, auth) forallpa inpartic checkCollision (bD, eD) checkCollision (UD, eD) ok authorized storeAppt (partic, appt) con forall painpartic con : Connection authorizationData executeQuery(sqlString) u select(pa) concon new appt login(user,pwd) select(“User“,pa,2) dbmgr : DBManager u new() Alternative 3 Alternative 1 login(...) i!
  • 181. Detailed DesignDetailed Design Completing ClassesCompleting Classes  State variables from statechart diagrams, which were not considered within the class diagram yet  Operations, ◦ implementing activities of states ◦ implementing reactions to events in statechart and interaction diagrams ◦ reacting on external events with or without state transitions ◦ for CRUD (create, read, update, delete) ◦ managing associations  Visibility of attributes / operations i"
  • 182. Detailed DesignDetailed Design Realizing RelationshipsRealizing Relationships  Mapping of associations / aggregations to oo programming language and DB ◦ specifying the realization of relationships (global, local, etc.) within collaboration diagrams and modifying the class diagram accordingly ◦ navigation - optimizing access paths by means of redundant associations ◦ materializing derived attributes ◦ realizing collections of objects  Mapping of generalizations to oo programming language and DB ◦ multiple, extensional, overlapping i#
  • 183. Detailed DesignDetailed Design Pattern - Framework - ComponentPattern - Framework - Component Pattern: schematic solution for an often recurring problem, emphasizing on the collaboration between objects Framework: collection of reusable design decisions (patterns) of a domain, represented by abstract and concrete classes as well as collaborations (“inversion of control”) Component: reusable unit having a clearly defined offering interface and a clearly defined required interface i$
  • 184. Patterns in UMLPatterns in UML Example “Observer Pattern”Example “Observer Pattern” Observer: ◦ goal is the automatic notification of dependent objects in case of state changes of an object ◦ ensures consistency for loosely coupled objects ◦ most often used in the area of graphical user interfaces : Calendar cv1 : CalendarView Observer subject observer cv2 : CalendarView observer i%
  • 185. Schema of the Observer PatternSchema of the Observer Pattern addObserver (Observer)addObserver (Observer) removeObserver (Observer)removeObserver (Observer) notifyObservers()notifyObservers() SubjectSubject for all o in observersfor all o in observers o->update(this);o->update(this); update (Subject)update (Subject) ObserverObserver observerStateobserverState update (Subject)update (Subject) ConcreteObserverConcreteObserver subjectStatesubjectState getState ()getState () setState ()setState () ConcreteSubjectConcreteSubject return subjectState;return subjectState; observerState=subject->getState()observerState=subject->getState() observersobservers ** subjectsubject // change state…// change state… notifyObservers();notifyObservers(); i
  • 186. Observer Pattern in CALENDARIUMObserver Pattern in CALENDARIUM Updating the CalendarViewsUpdating the CalendarViews ca :ca : CalendarCalendar pa :pa : UserUser insertAppt (d_new)insertAppt (d_new) cv1 : Calendarcv1 : Calendar ViewView update(this)update(this) cv2 : Calendarcv2 : Calendar ViewView addObserver(this)addObserver(this) addObserver(this)addObserver(this) notifyObservers()notifyObservers() update(this)update(this) appointments( )appointments( ) appointments( )appointments( ) further acces methods okok further access methods 
  • 187. OutlineOutline Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UML SyntaxUML Syntax and Semanticsand Semantics 
  • 188. Pitfalls & WorkaroundsPitfalls & Workarounds A (constructive) critical viewA (constructive) critical view  Aggregation semantics  Generalization semantics ◦ Static view ◦ Dynamic view  Use Case formalization ◦ Interaction diagrams for algorithmic views ◦ Use case extension (include / extend / generalize) in I.D. ◦ Dynamic object references in sequence diagrams  Some OCL obscenities  Traceability of model refinement 
  • 189. Aggregation SemanticsAggregation Semantics Problems in UML: ◦ Weak aggregation does not bear useful semantics ◦ “Canonical” variations of aggregation not completely covered 
  • 190. Aggregation SemanticsAggregation Semantics Standard ClassificationStandard Classification  Additional variants: ◦ exclusive, dependent, but no delete propagation! ◦ very specific semantics: only transition “0 1” allowed Weak aggregation is indeed weak :-) (Rumbaugh:“modeling placebo”) dependentdependent exclusiveexclusive sharedshared ?? independentindependent 11 ** 0..10..1 11 0..10..1 ?? + user specified del./propagation semantics+ user specified del./propagation semantics necessarynecessary!! 1..*1..* !
  • 191. Generalization SemanticsGeneralization Semantics Problems in UML: ◦ “Canonical” variations of generalization not completely covered  w.r.t. static view (class diagram)  w.r.t. dynamic view (state diagram) ◦ Properties of generalization relationships are ambiguous, depending on basic assumptions:  multiple inheritance allowed?  multiple classification allowed?  Both allowed??? "
  • 192. Generalization SemanticsGeneralization Semantics Flavors of InheritanceFlavors of Inheritance  Specification inheritance ◦ yields type hierarchies ◦ preconditions must not become stricter, postconditions not weaker ◦ DQueue subtype-of Stack ◦ contravariance  Stack::push: Stack x Element Stack  DQueue::push: Stack x Element Stack (possibly: DQueue)  Specialization inheritance ◦ yields is-a hierarchies ◦ Integer is-a Rational ◦ covariance  Rational::*: Rational x Rational Rational  Integer::*: Integer x Integer Integer  Implementation inheritance ◦ no conceptual relationship at all «implementation»«implementation» notdistinguishedinUML!notdistinguishedinUML! #
  • 193. Generalization SemanticsGeneralization Semantics PropertiesProperties  incomplete / complete (default) ◦ complete:All possible subclasses are already part of the model ◦ additional interpretation (outside UML) (with multiple classification): Each super class instance must also belong to at least one subclass  overlapping / disjoint (default) ◦ 2 interpretations of overlapping:  w.r.t. multiple inheritance: two or more subclasses can have again common subclasses (e.g. Instructor)  w.r.t. multiple classification: an object can be instance of more than one subclass EntryEntry SerialEntrySerialEntry ToDoEntryToDoEntry {complete,{complete, disjoint}disjoint} AppointmentAppointment EmployeeEmployee {incomplete,{incomplete, overlapping}overlapping} TechnicalTechnical EmployeeEmployee AdministrativeAdministrative EmployeeEmployee $
  • 194. s1s1 createcreate s2s2 establishestablish s3s3 consumeconsume s4s4 sendSorryLettersendSorryLetter paypay Generalization SemanticsGeneralization Semantics Inheritance of State Chart Diagrams (1/2)Inheritance of State Chart Diagrams (1/2) class Reservationclass Reservation inheritance hierarchyinheritance hierarchy ReservationReservation Reservation_Reservation_ with_Cancelwith_Cancel Reservation_Reservation_ with_Insurancewith_Insurance %
  • 195. s1s1 createcreate s2s2 establishestablish s3s3 consumeconsume s4s4 sendSorryLettersendSorryLetter paypay ReservationReservation cancelcancel Reservation_with_CancelReservation_with_Cancel ((contracontravariance)variance) ((cocovariance)variance) Reservation_with_InsuranceReservation_with_Insurance s6s6 s7s7 makeInsurancemakeInsurance Generalization SemanticsGeneralization Semantics Inheritance of State Chart Diagrams (2/2)Inheritance of State Chart Diagrams (2/2) UML remains silent about these alternatives!UML remains silent about these alternatives! 
  • 196. Use Case FormalizationUse Case Formalization Use Cases need formal specifications ◦ Sequence Diagrams (SD) ◦ Collaboration Diagrams (CD) ◦ Activity Diagrams Interaction Diagrams (SD, CD) ◦ are well suited to scenario description ◦ are not adequate for algorithmic views (same applies for other behavioral aspects) 
  • 197. c:Customerc:Customer b:Bankb:Bank transfer(rcvb, rcva, amnt)transfer(rcvb, rcva, amnt) [amnt<limit] true[amnt<limit] true [amnt >= limit] false[amnt >= limit] false alternativealternative Alternatives (1/2)Alternatives (1/2) Guarded Messages ◦ A message guard is a Boolean expression (a predicate) that indicates under what circumstances the message can occur ◦ The guard appears in square brackets as part of the message label ◦ Multiple guarded messages within a single SD reduce the SD’s readability considerably! 
  • 198. c:Customerc:Customer b1:Bankb1:Bank bal:=getBal()bal:=getBal() ackack a1:Accounta1:Account b2:Bankb2:Bank BTransfer(BTransfer(rcvb,rcvb, rcva,rcva, amnt)amnt) add(add(a-bal)a-bal) transfer(transfer(rb,ra,a)rb,ra,a)[[balbal≥≥a]a] deposit(deposit(a-bal)a-bal)[[bal<a]bal<a] conditionalconditional lifelinelifeline Alternatives (2/2)Alternatives (2/2) Conditional Lifelines ◦ A conditional lifeline expresses alternative behavior of a single component ◦ Conditional lifelines typically occur in conjunction with guarded messages and reduce an SD’s readability even further! 
  • 199. b1:Bankb1:Bank b2:Bankb2:Bank initMultiTransfer()initMultiTransfer() finishMultiTransfer()finishMultiTransfer() BTransfer(t)BTransfer(t) ackack for allfor all tt inin transactionSettransactionSetlooploop conditioncondition loop arealoop area RepetitionRepetition The UML lets us specify loops by enclosing the section to repeat, and by indicating (informally) the repetition 
  • 200. Real Life ExampleReal Life Example CALENDARIUM SD “Insert Appointment” (excerpt)CALENDARIUM SD “Insert Appointment” (excerpt) : B_Calen-: B_Calen- dariumdarium c : Calen-c : Calen- dariumdarium User:User: ClassClass Authorization :Authorization : ClassClass ca :ca : CalendarCalendar papa :: UserUser login(user,pwd)login(user,pwd) login(user,pwd)login(user,pwd) checkAuthorization (user, pa, “write“)checkAuthorization (user, pa, “write“) forallforall papa in particin partic checkCollision (bD, eD)checkCollision (bD, eD) forallforall papa in particin partic checkCollision (bD, eD)checkCollision (bD, eD) okok authorizedauthorized storeApptstoreAppt (partic,appt)(partic,appt) okokokok new apptnew appt okok login(...)login(...) [authorized =[authorized = false]false] [ok = false][ok = false] ?? scopescope of pa?of pa? 
  • 201. Use-Case FormalizationUse-Case Formalization Problems with Algorithms in Interaction DiagramsProblems with Algorithms in Interaction Diagrams  Decisions ◦ Where should you branch to? ◦ Message arrows pointing downwards (time dimension!)  Iterations ◦ No multi-object in sequence diagrams ◦ Loops need pseudo-messages in collaboration diagrams  Class methods ◦ how to represent class methods ◦ classes seen as objects ◦ however: new is treated differently…  Dynamic object references (e.g., pa) : Appointment: Appointment 
  • 202. AA o1o1 o2o2 o3o3 BB o3o3 o4o4 o5o5 AA BB ««includeinclude»» Use-Case FormalizationUse-Case Formalization Referencing of Use Cases (1/2)Referencing of Use Cases (1/2) “Probes” from OOSE are missing in UML BB 
  • 203. Use-Case FormalizationUse-Case Formalization Referencing of Use Cases (2/2)Referencing of Use Cases (2/2) Variant borrowed from the MSC-96 standard b1:Bankb1:Bank a:Accounta:Account withdraw(a)withdraw(a) SDSD SuccessfulWithdrawalSuccessfulWithdrawal ackack b1:Bankb1:Bank a:Accounta:Account initTransfer()initTransfer() endTransfer()endTransfer() refref SuccessfulWithdrawalSuccessfulWithdrawal referencereference 
  • 204. c:Customerc:Customer b1:Bankb1:Bank bal:=getBal()bal:=getBal() ackack a1:Accounta1:Account b2:Bankb2:Bank BTransfer(BTransfer(rcvb,rcvb, rcva,rcva, amnt)amnt) add(add(a-bal)a-bal) transfer(transfer(rb,ra,a)rb,ra,a) deposit(deposit(a-bal)a-bal) alt:alt: [[balbal≥≥a]a] alt:alt: [[bal<a]bal<a] AlternativesAlternatives Separate “alternation boxes” ◦ Each alternative has its own guard ◦ The disjunction of all guards must equal true ◦ Any one of the alternatives whose guard equals true will occur in an execution that complies with the SD 
  • 205. RepetitionRepetition Use “repetition box” with guards for specifying loops The loop guard is of any one of the following forms: ◦ loop<lb,ub> : at least lb and at most ub repetitions ◦ loop<*>: any finite number of repetitions ◦ loop<∞>: an infinite number of repetitions ◦ loop<g>: if g is a Boolean expression then the repetition occurs as long as g evaluates to true b1:Bankb1:Bank b2:Bankb2:Bank BTransfer(t)BTransfer(t) ackack loop<1,10>loop<1,10> i
  • 206. ActionsActions  Use “action boxes” for specifying that a component performs a local activity, such as an assignment to its attributes  The activity’s position on the component’s lifeline indicates when the activity occurs b1:Bankb1:Bank a:Accounta:Account withdraw(withdraw(amnt)amnt) bal :=bal := bal-amntbal-amnt action symbolaction symbol 
  • 207. OCLOCL  Purpose ◦ Capture properties of modelling elements not conveniently covered by other UML constructs ◦ Documentation specification ◦ Reason about specification ◦ Execution (of a sub-language)  Characteristics ◦ First-order specification language  Boolean operators, quantifiers ◦ Basic datatypes included ◦ very similar to  Algebraic specification language  Logic language 
  • 208. Missing Definitions in OCLMissing Definitions in OCL let-construct: ◦ let p = a*b min(x,y) = if(x<y) then x else y fi in min(a,p)+min(b,p) dataype-construct: ◦ dataype Error = Ok | ReadOnly | ReadErr | DiskErr(String) both from functional languages 
  • 209. The Russel ParadoxonThe Russel Paradoxon  “Each type is subtype of OclAny.” ◦ Therefore, Set(OclAny) is subtype of OclAny.  Define set R and Boolean value P: ◦ R = OclAny.allInstances -> select( x:Set(OclAny) | not x->includes(x) ) ◦ P = R->includes(R)  P is neither True nor False, ◦ as both would lead to contradiction  Logic contains contradictions:  Everything can be deduced 
  • 210. Prevention of the Russel ParadoxonPrevention of the Russel Paradoxon No OclAny type, or OclAny type, but no operations on it (?) Disallowing type constructors on OclAny Instead: ◦ Define operations for each type separately! ◦ Introduce “OclObject” as top for all Classes! !
  • 211. Traceability of Model RefinementTraceability of Model Refinement Example 1Example 1 «refine» and «trace» dependency ◦ between 2 model elements (need some kind of n:m-relationship…) ◦ «trace» semantics not quite clear ◦ impossible for model elements on different diagrams XX op’()op’() op’’()op’’() YY αα **11 XX op()op() YY αα 1111 «trace»«trace» «refine»«refine» "
  • 212. X Yα *1 X Y-Set Y α2 *α11 1 Traceability of Model RefinementTraceability of Model Refinement Example 2Example 2 Only reasonable workaround: Tool support «refine» #
  • 213. ConclusionConclusion UML 1.3 ◦ is well under way to become the lingua franca ◦ has several deficiencies yet to be eliminated  major problem: algorithmic views (may be repaired?!)  major problem: traceability (needs tool support)  minor problem: unclear semantics of some model elements $
  • 214. OutlineOutline Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References }}UML SyntaxUML Syntax and Semanticsand Semantics %
  • 215. UML 2.0 Roadmap DraftUML 2.0 Roadmap Draft [Kobryn99][Kobryn99] Heavyweight extension mechanisms and profiles Activity graph semantics independent of state machines semantics State machine generalization Refinement of «refine» Generalization of association Variations of aggregation OCL extensions Cleanup constructs not used based on feedback from vendors and users  i
  • 216. Literature (1/5)Literature (1/5)  Official documentation of the UML, v. 1.3 June 1999 (http://uml.shl.com): ◦ UML Summary ◦ UML Semantics ◦ UML Notation Guide ◦ UML Extensions  UML Extension for Software Development Processes  UML Extension for Business Modeling ◦ OA&D CORBAfacility Interface Definition ◦ Object Constraint Language Specification (OCL) ◦ UML Metamodel  
  • 217. Literature (2/5)Literature (2/5)  ScottW.Ambler, Building Object Applications - Patterns,Architecture, Design, Construction, andTesting, SIGS Books, 1997, ISBN 0-13-789215-2  Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide,AddisonWesley Longman, 1999, ISBN 0-201-57168-4  R. Breu, I. Krüger, B. Rumpe: Applied Software Engineering Principles for UML, Tutorial Notes,TOOLS Europe 1999.  Rainer Burkhard, UML - Unified Modeling Language,Addison Wesley, 1997, ISBN 3- 8273-1226-4  Murray Cantor, Object-Oriented Project Management with UML, John Wiley, 1998, ISBN: 0-471-25303-0  Paul Dorsey, Joseph Hudicka, Oracle8 Design Using UML Object Modeling, Osborne McGraw-Hill, 1999, ISBN: 0-078-82474-5  Bruce Powel Douglass, RealTime UML - Developing Efficient Objects for Embedded Systems,Addison Wesley Longman, 1998, ISBN: 0-201-32579-9  Hans-Erik Eriksson and Magnus Penker, UMLToolkit, John Wiley & Sons, 1998, ISBN: 0- 471-19161-2  
  • 218. Literature (3/5)Literature (3/5)  Martin Fowler, UML Distilled:Applying the Standard Object Modeling Notation, Addison Wesley, 1997, ISBN: 0-201-32563-2  Martin Fowler, Kendall Scott, UML konzentriert, deutsche Übersetzung von UML Distilled,Addison-Wesley, 1998, ISBN 3-8273-1329-5  Paul Harmon, Mark Watson, Understanding UML -The developer guide, Morgan Kaufmann Publishing, 1997, ISBN: 1-558-60465-0  M. Hitz, G. Kappel, UML @ Work:Von der Analyse zur Realisierung, dpunkt.Verlag, 1999  Ari Jaaksi, Juha-Markus Aalto,Ari Aalto, Tried andTrue Object Development, Industry- Proven Approaches with UML, 1998, ISBN: 0-521-64530-1  Bernd Kahlbrandt, Software-Engineering - Objektorientierte Softwarentwicklung mit der UML, SpringerVerlag, 1998, ISBN 3-540-63309-X  C. Kobryn: UML RTF Status, http://uml.shl.com, 1999.  
  • 219. Literature (4/5)Literature (4/5)  Craig Larman, Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design, Prentice Hall, 1998, ISBN: 0-137-48880-7  Richard C. Lee,William M.Tepfenhart, UML and C++:A Practical Guide to Object- Oriented Development, Prentice Hall, 1997, ISBN 0-13-619719-1  James Martin, James J. Odell, Object-Oriented Methods:A Foundation, UML Edition, Prentice Hall, 1997, ISBN 0-13-905597-5  James J. Odell, Advanced Object-Oriented Analysis & Design Using the UML, Cambridge University Press, 1998  Bernd Oestereich, Objektorientierte Softwareentwicklung mit der UML, Oldenburg Verlag, 4.Auflage, 1999, ISBN 3-486-24319-5  Pierre-Alain Muller, Instant UML,Wrox Press, 1997, ISBN: 1-861-00087-1  Horst Neumann, Objektorientierte Softwareentwicklung mit der Unified Methode, 1998, Hanser-Verlag, ISBN 3-446-18879-7  Terry Quatrani, Visual Modeling with Rational Rose and UML,Addison Wesley Longman, 1998, ISBN 0-201-31016-3 
  • 220. Literature (5/5)Literature (5/5)  James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual,Addison Wesley Longman, 1999, ISBN 0-201-30998-X  Martin Schader,Axel Korthaus (eds.): The Unified Modeling Language -Technical Aspects & Applications, Physica-Verlag, 1998, ISBN: 3-7908-1105-X  J. Seemann, J.Wolff von Gudenberg, Software-Entwicklung mit der UML, SpringerVerlag, 1999, ISBN 3-540-64103-3  Sinan Si Alhir, UML in a Nutshell, O'Reilly, 1998, ISBN: 1-56592-448-7  M.Thron, UML - Objektorientierte Entwicklung in der Praxis, SpringerVerlag, 1999, ISBN 3-540-64420-2  !
  • 221. UML Web addressesUML Web addresses  Rational Software Corporation: www.rational.com UML RevisionTask Force: http://uml.shl.com  Interesting Links in this Area: http://www.infosys.tuwien.ac.at/cetus/oo_uml.htm l  Presenter‘s UML Site: http://www.ifs.univie.ac.at/UML  "
  • 222. Source & CreditSource & Credit This presentation is adopted from: ◦ ftp://ftp.ifs.uni-linz.ac.at/pub/wieland/uml.ppt ◦ © Hitz, Kappel, Retschitzegger; Information Systems Group (IFS), http://www.ifs.uni-linz.ac.at/ ◦ @ Johannes Kepler Universitat Linz, Germany,  #