Lecture 6-7 : UML introduction

1. Lecture 6-7:UML introduction Telematics systems and their design Doc.Ing. Ondřej Přibyl, Ph.D. Department of applied mathematics Faculty of Transportation sciences, CTU

2. Example of UML (1)

3. Example of UML (2)

4. Example of UML (3)

5. Example of UML (4)

6. Example of UML (5)

7. Lecture 5 – Overview • What is UML • History of UML • UML diagrams • Overview • Description

8. What is UML? • UML = Unified Modeling Language • A language (notation) for modeling object-oriented systems • A standard maintained by the Object Management Group • A modeling language including 13 diagrams • A means for visualizing, specifying, constructing, anddocumenting software as well as hardware systems http://www.uml.org

9. Unified: • Unification of earlier object-oriented analysis and design methods. • Same concepts and notation for different application domains and different development processes. • Same concepts and notation through the whole development lifecycle. U M • Modeling: • Making a semantically* complete abstraction of a system.(* The formal specification of the meaning and behavior of something) L • Language: • a system for encoding and decoding information • UML - A graphical language

10. DIscussion • What is a model?

11. Reality Model Modeling • When you make a model you are making a mapping from the problem domain to a representation of the system you are modeling. • When you work object-oriented the model tends to be close to the system modeled, and a program execution can be regarded as a simulation of the behavior of the system.

12. Models http://www.business-prototyping.com/methods-and-techniques/models-and-metamodels/

13. DIscussion • Why do we model?

14. Why do we model? • Models give us a template that guides us in constructing a system. • If you want to make a building you first make a blueprint of the building to make • Models help us visualize a system at different levels of abstraction, this makes it easier to manage complexity and to understand the system. • Provide structure for problem solving • Experiment to explore multiple solutions • Modeling allows the following business benefits: • Reduce time-to-market for business problem solutions • Decrease development costs • Manage the risk of mistakes

15. Characteristics of a Model • A model is never equal to the real system, because it is always simpler than the reality • The accuracy of a model is determined by its tendency to approach the real system • Is that a problem? 15 • Yes, if the model ignores important parameters of the real system (over simplification) • No, if the model takes into account the important parameters (ignoring some details is sometimes not problematic) • No, if we simplify those features not relevant for our research - We use a mathematical model of an engine to study its power, but we do not model its heating characteristics

16. Discussion • Why do we need UML?

17. Why do we need UML? • Unified communication language • Unify ideas from other modeling languages and incorporate industry best practices. • Everybody understands UML in the same way! • Graphical notation • A picture is worth a thousand words • An easy-to-learn but semantically rich visual modeling language • Provides multiple diagrams for capturing different architectural views • Promotes component reusability • Provide flexibility for applying different processes and mapping to different programming languages.

18. Customer Salesman Product manager Developer Problems with communication…

19. History of UML

20. History of UML UML 2.5 was released in October 2012 as an "In process" version and has yet to become formally released

21. UML is not a development process A development process defines: - Who is doing What, - When to do it, and - How to reach a certain goal • The UML is intentionally process independent • Defining of a standard process was not a goal of UML. Different domain may require different processes. • UML authors promote a development process that is use-case-driven, architecture centric, iterative and incremental. (Example of method: RUP)

22. Discussion - Control questions • What is UML • Is UML better or worst than water fall methodology? • Why do we want to use UML? (Advantages) • Are there any disadvantages of UML? • How do we use UML as part of SAD?

23. Introduction:Ways of using UML

24. As a Sketch • Most common use of UML • Used to help communicate some aspect of a system and to better understand it • Used for both forward engineering (i.e., build diagrams before coding) and reverse engineering (i.e., build diagrams from existing code) • Strives to be informal and dynamic • Only emphasizes those classes, attributes, operations, and relationships that are of interest • More concerned with selective communication than complete specification

25. As a Blueprint • Goal is completeness • Is more definitive, while the sketch approach is more explorative • Used to describe a detailed design for a programmer to follow in writing source code • Notation should be sufficiently complete so that a programmer can follow it in a straightforward manner • Can be used by a designer to develop blueprint-level models that show interfaces of subsystems or classes • Developers then work out the implementation details • As a reversed engineered product, diagrams convey detailed information about the source code that is easier for developers to understand

26. As a Programming Language • Specifies the complete system in UML so that code can be automatically generated • Looks at UML from a software perspective rather than a conceptual perspective which concentrates on the domain of study • Diagrams are compiled directly into executable code so that the UML becomes the source code • Challenge is making it more productive to use UML rather than some another programming language • Another concern is how to model behavioral logic • Done with interaction diagrams, state diagrams, and activity diagrams

27. Comparing and ContrastingWays of Using UML • UML sketches are useful with both forward and reverse engineering and in both conceptual and software perspectives • Detailed forward engineering blueprints are difficult to do well and slow down the development effort • Actual implementation of interfaces will reveal the needs for changes • The value of reversed engineered blueprints depends on the CASE tool • A dynamic browser would be very helpful; a thick document wastes time and resources • UML as a programming language will probably never see significant usage • Graphical forms have not shown to be more productive in writing code than textual code for most programming tasks

28. Overview of UML diagrams

29. Standard diagrams in UML (Ver. 2.2)

30. I. Behavior 1. Activity 2. State Machines 3. Use case II. Interaction 4. Communication 5. Interaction Overview 6. Sequence 7. Timing III. Structure 8. Class 9. Composite Structure 10. Object IV. Organization (Structure) 11. Package 12. Component 13. Deployment Standard diagrams in UML • 13 Types in UML 2.0 (Superstructure specs)

31. I. What is Behavioral modeling? • a view of an system that emphasizes the behavior of particular modules as well as processes. I. Behavior 1. Activity 2. State Machines 3. Use case

32. 3. Use case diagram • Captures Use Cases and relationships between Actors and the subject (system). • It describes the functional requirements of the system, the manner in which outside things (Actors) interact at the system boundary, and the response of the system • Displayed aspects • System boundary and context of system • Users and neighbor systems • Functionalities • Relationships between functionalities (calling/dependency, taxonomy) • Functional requirements • Some non-functional (“quality”) requirements as comments/annotations

33. 3. Use case diagram - Actors • Actors • specifies a role played by a user or any other system that interacts with the subject

34. 3. Use case diagram - Example

35. Project relevant details (Assignment 3) • See presentation (P1 – Actors) • Stored also at the course web site together with additional reading • Usecases.pdf • UML Handbook

36. SSC system: Example Actors (Class 2012)

37. 3. Use case diagram – Discussion • Prepare a simple Use case diagram for • Section speed control system

38. SSC system: UC example

39. Result from class 2011 (Section speed control system)

40. Result from class 2012 (Section speed control system)

41. Scenarios • Scenario is another name for a particular flow of events. • A use case covers a range of situations – a scenario is just one. • Each use case typically has: • a main flow describing the “happy path” • alternate flows describing major exceptions • Several alternatives exist for specifying the use case scenarios.

42. Write text to describe the interaction of the actor(s) and the system. Simple and easy approach May be limiting: Numerous alternate flows make it hard to understand where normal flow can branch. Long alternate flows need to be broken out as steps too. Use Case: Checks out item Customer sets item on counter. Sales clerk swipes UPC reader across UPC code on item. System looks up UPC code in database procuring item description and price. System emits audible beep. System announces item description and price over voice output. System adds price and item type to current invoice. System adds price to correct tax subtotal. Error case 1: UPC code unreadable If after step 2, the UPC code was invalid or was not properly read, emit an audible ‘bonk’ sound. Error case 2: No item in database If after step 3 no database entry is found for the UPC flash the ‘manual entry’ button on the terminal. Accept key entry of price and tax code from Sales Clerk. Set Item description to “Unknown item”. Go to step 4. Describing Scenarios Textually

43. Describing Scenarios Graphically • Create an Activity Diagram to graphically show the interaction of the actor(s) and the system. • Requires a little UML savvy • Easy to slip into too much detail • Create a Sequence Diagram to graphically show the interaction of the actor(s) and the system. • Requires more UML savvy • Great start for design activities

44. 1. Activity diagram • Activity diagrams present all kinds of control flow and data flow. • They are kind of dual to state machines: • focus is on actions rather than states. • Activity diagrams have applications throughout the whole software life cycle for many purposes • Analysis • design or document processes in the application domain (business processes) • Design • design or document processes as compositions of preexisting elements like manual tasks or automated jobs • Implementation • document existing programs (i.e. functions, services, …) • design algorithmic processes with an intention of turning them into implementation language code

45. 1. Activity diagram - Example

46. 1. Activity diagram – Partitioning (Example)

47. 1. Activity diagram – Discussion • Prepare a simple Activity diagram for one use case from: • Section speed control system • Nice explanation and examples: http://www.zicomi.com/viewActivityDiagram.jsp

48. SSC system: AD example

49. 2. State machine diagram - Overview • State machines model behavior • object and use case life cycles • control automata • protocols • State machines consist of • States … • connected by Transitions (with triggers, guards, and effects) • State machines communicate via event pools. • State machines are executed by run-to-completion steps.

50. 2. State machine diagram - Example