Why modeling techniques?

1. Why modeling techniques? • Specific languages to describe higher level concepts and abstractions. • Graphical representations help us in understanding, documenting and explaining a problem. • Writing down ideas in a structured way helps us to tackle complexity and multi-dimensionality of software. ÞMastering one or several modeling techniques, one or several software development processes, and knowing the most important design patterns are prerequisites for successful (object-oriented) software development. S T A R T N O W ! UML

2. Formal - Informal • Formal modeling techniques • e.g. Z, VDM • COOPN, Petri-Nets • allow various kinds of checks • completeness is an issue • mainly used for core parts of a system • Semi-formal modeling techniques • e.g. Booch, UML • Informalmodeling techniques • e.g. RDD, CRC, Storyboarding They all have their place! UML

3. Business Processes Using UML for modeling business processes: • at beginning of a software project for a clear basis • for business process reengineering Þ Same diagrams for different purposes, different abstraction levels, different domains. References for business process modeling: • from amazon web-page • from rational web-page UML

4. Other sources... There exist many other modeling techniques and development methods that have influenced UML, e.g. • OOSE (Jacobson) • Fusion (HP, D. Coleman) • FORAM (Ian Graham) • OBA (Rubin et al.) • RDD (Wirfs et al.) • BON (Nerson et al.) • various scenario modeling techniques • various statechart modeling techniques and extensions • various dataflow and eventflow modeling techniques • ... UML

5. References for UML Official documents about UML from Rational: http://www.rational.com/uml/documentation.html • Object Constraint Language Specification (defines OCL, which is used to specify the well-formedness of the UML) • UML Notation Guide v1.1 • UML Semantics • UML Extension for Business Modeling • UML Quick Reference: http://www.rational.com/uml/qr/ Books about UML: • web-pages of Rational • amazon.com UML for special applications (e.g. real-time systems):... Processes that use UML as modeling technique:... UML

6. Metamodel for UML Example: Metamodel for Relationships UML

7. Models in UML Models showing the static structure of a system: • class diagrams and object diagrams • implementation diagrams: component diagrams, deployment diagrams Models showing the dynamic behavior of a system: • use case model Þexternal view of the system • activity diagrams Þexternal/internal view of a system • interaction diagrams: sequence diagrams and collaboration diagrams Þ internal view of the system Models showing the dynamic behavior of a singleclass: • statecharts diagrams, activity diagrams UML

8. Identifying System Boundaries • e.g. interfaces to humans, to other systems • actors are entities outside system boundaries that interact with system (r) • actors model roles, not persons! • use cases are started by actors (special case: use cases triggered by timing events) Defining boundaries is iterative, expect to redefine your use cases several times in first phases of project! Inside the system: you have to create it Outside the system: you do not create it (it already exists), yet you have to worry about it UML

9. System Boundaries and Abstraction Levels System boundaries can be defined at several abstraction levels (b: make order): • high level with no representatives • middle level taking into account who/what actually enters the information • lower level taking into account how data is actually entered • Actors and interactions between actors and system change with abstraction level! • Starting level depends on complexity of project! UML

10. Use Case Factoring • <<use>> - relationship between use cases • avoids repetitions, copy/paste of common steps • C contains a sequence of steps common to A and B • A and B are not complete without C • C can be used in many different use cases • C does not know in which use cases it is being used • C is described like any other use case <<uses>> A C B <<uses>> UML

11. Use Case Extension (1) • <<extend>> - relationship between use cases • for optional sequences of events and error handling • Ordering is a complete use case (ideally) unaware of the existence of its extensions Timout and Holiday Sales • Where in the flow the extension takes place is marked in the use case diagram (indicating step number) and sometimes in the use case description of the use case to be exended (not ideal) • Condition for extension is given in the use case descriptions of the extensions • Estensions are often used for subsequent versions of a system Ordering Extension Points: T, whenever timeout Sales, before step 5 <<extends>> Timeout Holiday Sales <<extends>> UML

12. Use Case Extension (2) Extending Use Case: “Timeout” if system has been waiting more than 2 minutes for input then T Extension 1. IF this has happened for the 3rd time, abort use case and notify user 2. ELSE alert user with music and continue Extending Use Case: “Holiday Sales” if holiday, and if product in sales list then Sales Extension 1. The system gets discounts for ordered items. 2. Discounts are displayed on the order for each item. 3. Total amount is adjusted. UML

13. Use Case: further Example (1) UML

14. Inheritance between Actors Actor A is a subtype of actor B: Actor A fulfills the same role as actor B, and probably some additional role==> B participates in all use cases in which A participates Attention: using inheritance easily leads to confusing roles with persons! Try first to choose good roles. (b: previous example: supervisor inheriting from salesperson?) Use Case 1 Staff Use Case 2 Use Case 3 Manager UML

15. Use Case: further Example (2) UML

16. Use Case: further Example (3) Use Case: “Place Order” (1) A customer contacts a sales-person to place an order. (2) The sales-person receives all available information about the customer (see “Supply Customer Data”). (3) Extension point: “Request Catalog”, if user needs information about specific product. (4) Sales-person enters the information about the product to be ordered (see “Order Product”). (5) If product is available, and user has approved to order it, then payment information is entered (see “Arrange Payment”). (6) If payment arrangements failed, then ordering of product has to be reversed, otherwise confirmation of ordering is printed out and sent to the customer. Þno strict rule how to describe use cases textually or with diagrams Þspecial sections for summary, description, preconditions, postconditions, exceptions, alternative courses UML

17. Documenting Use Cases (1) Includes: • Preconditions • Postconditions • Flow of events or interactions (with conditionals, branching or loops) for basicfunctionality • and for alternatives and exceptions • Error conditions • Special (non-functional) requirement, e.g. time restrictions • Priority and development status In a use case we describe the behavior of the system as perceived from the outside, from the actor’s point of view. We describe how the system interacts with the outside world, not what it does internally! (d:improve previous use case,add alternative for cancel and for incorrect inputs) UML

18. Primary and Secondary Scenarios • Scenario: one particular path through the use case (one instance of the use case) • Primary Scenario: normal path where all goes well, or most likely path • Secondary Scenarios: other paths • alternative scenarios: other regular paths (b) • exceptional scenarios: for handling errors (b) Questions for finding secondary scenarios: • other actions that can be taken at this point? • something that could go wrong at this point? • some behavior that can happen any time during the primary scenario, e.g. cancel or restart? UML

19. Documenting Use Cases (2) Structuring the description: • one complete description/diagram per scenario • complete description of the primary scenario, separate descriptions for seconday scenarios (e.g. in alternative path and exception path sections) only containing deltas to basic description • all in one text or diagram inclusive alternatives and exceptions How to describe the flow of events in a use case: • plaintext (b) • numberedsteps • pseudo code (good for some special cases, normally gets too detailed and too unreadable) (b) • activity diagrams • interaction diagrams (showing interactions between system and actors) with pseudo code, bracket code or text to the left hand side UML

20. Documenting Use Cases (3) How detailed? • depends on phase in project (inception, elaboration, construction) • depends on importance and complexity of scenario (compromise: primary scenario detailed with steps and/or diagrams, secondary scenarios only plain text description) • not too detailed: capturing requirements means not constructing the system in plain text! • define and remember the goal for which you make use cases: who creates them or uses them for what? Reader of the use cases • determine modeling technique, level of detail • who could they be? (b, r) • they determine if use case descriptions are well done, not you! Correctness, completeness • walk-throughs, reviews, observation, ... UML

21. Use Cases: Activity Diagrams (1) Activity diagrams are part of the dynamic diagrams of UML, and can also be used for documenting use cases: start of the use case end of the use case a step in the use case (represented as a state containing actions), or several steps that are detailed in a separate diagram transition between steps condition on the transitions decision with decision point Check validity claim [claim valid] step 1 [condition 2] [condition 1] step 3 step 2 UML

22. Use Cases: Activity Diagrams (2) parallel steps Drawbacks: • space for describing steps is limited on diagram • no representations of uses and extends relationships (unless you invent one and add it to the notation) • diagrams can get too complex ==> decide for each use case if textual description, activity diagram or a combination is appropriate (b: make activity diagram) step a step b step c Activity diagrams contain more model elements not shown here as these are not relevant when representing use cases. step d UML

23. Interfaces at System Boundary It may be helpful to further document the interfaces at the system boundaries given by the use cases, e.g, by: • Storyboarding (for graphical user interfaces) • just handwritten pictures showing the different screens (b) • maybe diagram showing the sequence of the screens • or user interface prototype (check motivation!!!) • Protocol definition (for system interfaces) • e.g. when exchanging XML messages, define these messages • Interaction diagrams on different abstraction levels (b) • between actors and system, use asynchronous events • description to the left • with structured English or brackets for different paths • ATTENTION: different abstraction levels! UML

24. Use Cases are good for... • figuring out problem statement (iterative process!) • figuring out system boundaries • discussing requirements with end users • specifying external behavior of system, functional requirements for system developers (tension with previous point!) • starting point for design(class diagrams, interaction diagrams) • splitting up more detailed analysis of requirements along use cases • splitting up construction iterations along use cases • derive test cases, derive user documentation • reuse, architecture (see books) • project size and cost estimation (see book of G. Schneider) • …… ==> many similar techniques are known and have been used for a long time in many successful software development projects! UML

25. Books on Use Cases • Many books, often showing application of use cases for a specific domain, e.g. telecommunication, process control systems, information systems,…. • Good general books on use cases: • Applying Use Cases, by G. Schneider: short, easy to read in one evening, guide about creating and documenting use cases, also contains how to define architecture based on use cases and do cost estimation based on use cases; get that book before you start your next software project! • Software Reuse, by Jacobson, Griss and Jonsson: good book about how to create complex and reusable software systems and architectures, shows how use cases are used for that; get that book after you have used use cases for the first time so you get more needed in-depth knowledge UML

26. Persistent and Transient Documentation Persistent Documentation • is maintained, often done in a CASE- or Diagramming-Tool • lives as long as system lives • versions, need to be managed properly, keep as few as possible ==> helps to document your system, for other people too Transient Documentation • is thrown away, often just hand-written diagrams,valuable to keep sometimes as memo for past ideas • lives for one hour, a whole phase of the project, for as long as the system lives • becomes out-of-date, many documents representing many views and abstraction levels ==> helps to figure outyour system, for yourself only Do not decide too early if a diagram is transient or persisent! UML

27. Use Cases A use case is a coherent unit of functionality provided by a system or class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. Relationships in a use case diagram: • communicates: an actor participates in a use case • uses (from use case A to use case B): any instance of A includes the behavior of B Þfactoring out common parts, reuse • extends (from use case B to use case A): instance of A may (under specific conditions specified in B) include the behavior from B at the extension point specified in A Þexceptional cases UML

28. CASE-Tools Characteristics of CASE-Tools: • one repository with one metamodel that contains whole model • navigation in various views, suppression of elements for specific views, selecting certain kinds of relationships for presentation, double-click to additional windows with full information... • versioning, access protections • prioritization (use cases), status (done, planned,….) • documentation support • integration with code-files (integrity checks, support for updates), code generation Examples: • Rational Rose, http://www.rational.com/products/rose/ • Paradigm Plus, http://www.platinum.com/products/appdev/pplus_ps.htm • Visio (just a diagramming tool) UML

29. Class and Object diagrams A class diagram is a graphic view of the static structure. • models classifiers like classes (or interfaces etc.)and their relationships • having several diagrams has no semantic meaning An object diagram is an instance of a class diagram. • shows snapshot of system at a point in time Type - Instance: • class - object » parameter - value • association - link » operation - call Notation for operation signatures and attribute types: • not predefined, target language, familiar notation One model, various views, various diagrams • different abstraction levels • only some kind of relationships, subset of classes UML

30. Various abstraction levels Abstract class: {abstract} details suppressed Class-scope: Visibility: + public - private # protected Multiplicity: [0..1] optional [*] array, list analysis-level details (types and parameters could also be suppressed) implementation-level details Nonchangeable: {frozen} UML

31. Compartments No side effect: «query» {query} More elements: . . . Kind of parameter: in, out, inout (optional) Þ keywords for grouping elements Þ additional compartments, other possibilities: description, business rules UML

32. Constraints and Comments (1) A constraint specifies conditions and propositions that must be maintained as true. • placed directly after the element it applies to (e.g. attribute), with a dashed arrow connecting elements concerned, or in a comment box • always in {} A comment can attach arbitrary textual information to any model element. • in comment box • e.g. additional explanations, open questions, status of review, to-do list UML

33. Constraints and Comments (2) comment constraint constraint UML

34. Derived Attributes and Associations • A derived element is one that can be computed from another one, • it is shown for clarity (analysis level), • or it is included for implementation purposes (design level), • it adds no semantic information. derived element computation rule UML

35. Interfaces (1) There exist various classifiers: classes, interfaces, … An interface is a specifier for the externally-visible operations of an entity like a class without specification of internal structure (attributes, states, associations). • interface often describes only part and not all of the behavior of an actual class • generalization relationships among interfaces possible • are realized e.g. by classes ÞRealizes relationship UML

36. Interfaces (2) • shortcut notation for interface • association dependencyrelationship “Realizes” relationships UML

37. Associations Adornments: » role » multiplicity » ordering: {ordered} » changeability: {frozen}, {addOnly} » visibility: +, #, - » navigability: direction of arrow » interface specifier: :nameOfInterface Constraints: » e.g. {or}, {subset} association class (class-like properties like operations, attributes, associations) binary association UML

38. Aggregation and Composition (1) Composition is a form of aggregation with strong ownership and coincident lifetime of the part with the whole. • unshared • multiplicity of aggregate end is 0 or 1 Other example: bicycles in shop (composition, physical aggregation) or in a catalog (catalog aggregation) UML

39. Composition Different yet equal representations: UML

40. Specialization- Generalization Generalization is the taxonomic relationship between a more general and a more specific element (classes, use cases, interfaces, …) that: • is fully consistent with the first element • and adds additional information. Adornments: » {overlapping}or {disjoint} » {incomplete}or {complete} discriminator (name of a partition of subtypes of a supertype) UML

41. Dependencies A dependency relationship between two elements (e.g. classes) indicates that a change to the target element (e.g. deletion) may require a change to the source element. Some predefined keywords: • Element A does not function without element B: {uses} • Historically different elements (new and old) on different abstraction levels but represent same concept: {trace} • Element A calls functions of element B: {calls} • Friend-relationship as used in C++: {friend} see also example interfaces UML

42. Dependency Graphs • Dependency graphs just show all dependencies between classes, often without keywords. • Usage graphs only show all the “use” dependencies. • How do you derive dependency graphs? ==> rather for quality analysis of existing models and software than for documentation Goals: • minimize dependency on too many classes to improve maintenance • maximize cohesion within and minimize coupling between classes (use dependencies) to decrease complexity UML

43. CRC CRC: Class - Responsibility - Collaboration • CRC-Cards are (together with some diagrams) cornerstone of RDD (responsibility driven design), an alternative to UML • classes are found by looking for responsibilities • classes are documented on cards by stating class name, responsibility and collaborators (attributes and operations are added later on in design) • class diagrams are refactored (changing the structure of the diagram without changing its overall behavior)based on responsibilities and various quality criteria ==> add a compartment “responsibility” or put the responsibility into the class description and think in responsibilities ==> no good class diagram without at least one or two (major) refactoring (==> iterative process!) UML

44. Whole Values and Quantities Distinguish between atomic types, whole values, and quantities: • social security number (d: possible operations?) • your height • number of CD’s you have • phone number • purchase price of a book (d: possible operations?) • name of authors of a book • number of authors of a book • credit card number ==> whole values and quantities belong are classes, operations on them belong into these classes and not into some containing class ==> do not mix concepts together into one object! ==> make small objects and group them into packages! UML

45. Goals of Modeling Different goals: • Goals determine the content ==>you better know your goal • Examples for goals? (b: make list) Different abstraction levels • The same system/problem can be modeled on different abstraction levels, resulting in several models • Example abstraction levels for specific goals? • How do models on different abstraction levels relate to each other? (d) just adding more details, refinement, attributes become operations, no 1:1 mapping Different views: • The same model can be represented by various diagrams • Possible views for specific goals?(d) UML

46. Static object diagrams Snapshot of the system at a point of time showing a subset of its objects, their states, attribute values, links. Syntax: »objectname : classnames [statenames] »attributename : type = value UML

47. Packages - Subsystems Packages allow to group classes and other model elements • into subsystems (keyword <<subsystem>>) • into a framework (keyword <<framework>>) • <<system> contains all classes <<subsystem>> Finances <<subsystem>> Finances <<subsystem>> Credits <<subsystem>> BankInterface <<subsystem>> Finances Charge Account (…) Credit Account (…) Process Payments (…) Payment Status (…): status <<subsystem>> Accounts UML

48. Packages - Dependencies Examples of an architecture diagram showing subsystems and their dependencies: <<subsystem>> User Interface <<subsystem>> Business Rules Benefits <<subsystem>> Business Rules Salary <<subsystem>> Database UML

49. Subsystems - Design Criteria Each subsystem should have: • a single functionality • strong cohesion: strong relationships between classes within subsystem • loose (external) coupling: minimize dependencies among subsystems • minimal communication to other subsystems • reusability (d: what are the criteria here?) Also: consider architecture of systems you are integrating with and architecture preferences of COTS subsystems. See also architectural patterns (lecture on architecture). UML

50. Breaking down Use Cases (1) • Assign steps of a use case to the various subsystems (taking into account responsibility of subsystem). • One (or part of or several) step(s) of the system-wide use case becomes one use case of a subsystem. ==>superordinate use case, its subordinate use cases • The other subsystems (only those with which interaction is necessary for carrying out the step) become actorsof this subsystem. Who is the trigger of this new use case? • A new, more detailed description of the subsystem use case is created, containing again several steps. If use case is still to high-level and complex, iterate! UML