Practical use of UML

1. Practical use of UML UML in Projects. Tips, Hints, Pitfalls…. Carl-Fredrik Sørensen mailto:carlfrs@idi.ntnu.no

2. Introduction • Development processes and UML diagrams • … • Prestudy • Requirements specification/analysis • Construction/Design • Implementation • …

3. Visual Modelling • Modelling using a standard graphical notation. • Used to: • Represent business processes, objects/classes and logic. • Analyse and design applications. • Handle complexity. • Define software architecture. • Promotes reuse. • UML, BPM, ER, DDF etc.

4. UML • Not a software development process or methodology • Combines the best of the best from • Data modelling concepts (ER Diagrams) • Business modelling (workflow) • Object modelling • Component modelling

5. UML • Standard language for visualisation, specification, construction and documentation of problems/solutions in a software-intensive system • May be used in all processes/phases in the development cycle, across different implementation technologies

6. UML Concepts • UML is used to: • Show main functions and boundaries in a system using use cases and actors. • Illustrate use case realisations using interaction diagrams. • Represent a static structure of a system using class diagrams. • Modelling object behaviour using state diagrams. • Show implementation of the physical architecture using component and deployment diagrams. • Enhance the functionality using stereotypes.

7. UML Tools • It is almost a necessity to use a UML tool to model: • Draw consistent diagrams in UML notation • Process support • Maintenance • Traceability • Extensions • Documentation • Code generators (Java, C++, SQL etc.)

8. UML Diagrams and Elements • Use case diagrams • Interaction diagrams • Sequence, collaboration • Static structural diagrams • Object, class • State diagrams • Activity diagrams • Implementation diagrams • Packages, Components, Deployment

9. Use case diagram

10. Sequence diagram

11. «external» 3 : 3 : 1 : 1 : :EcBsProductionSystem::EcBsProductionSystem getProductionSystem() getProductionSystem() Select Production System() Select Production System() 4 : 4 : Production Select Facility() Select Facility() 2 : 2 : 6 : 6 : Test Planner 10 : 10 : 7 : 7 : load() load() getFacility() getFacility() Select Well() Select Well() Select Flowline() Select Flowline() 15 : 15 : 5 : 5 : Select Separator() Select Separator() 18 : 18 : findFacilities() findFacilities() Apply() Apply() «user» :EcUsProductionTestConfiguration 19 : 19 : save() save() «business» :EcBsProductionTest 8 : 8 : 12 : 12 : findFlowlines() findFlowlines() findWells() findWells() 16 : 16 : findTestSeparators() findTestSeparators() 9 : 9 : 14 : 14 : getFlowline() getFlowline() 17 : 17 : getWell() getWell() getTestSeparator() getTestSeparator() «external» 11 : 11 : :EcBsProductionSystem::EcBsTemplate getTemplate;2() getTemplate;2() «external» :EcBsProductionSystem::EcBsFacility 13 : 13 : «external» getName() getName() :EcBsProductionSystem::EcBsFlowline «external» «external» :EcBsProductionSystem::EcBsWell :EcBsProductionSystem::EcBsTestSeparator Collaboration diagram

12. «business» ::EcBsProductionTest productionSystem_ facilityId_ separatorId_ primaryWell_ flowline_ noWells_ startTime_ endTime_ startStableTime_ endStableTime_ recentWells_ selectedWells_ debug_ systemVersion_ EcBsProductionTest;1 EcBsProductionTest;2 EcBsProductionTest;3 getConnectionString getDebug createInterface initialise getProductionSystem getFacility getSeparator getPrimaryWell setPrimaryWell getFlowline setFlowline getStartTime getEndTime getWellAssignment getWells getEnumWells getNoWells getSelectedWells setWells saveWellAssignment addWellToRecordset removeWellFromRecordset getProductionTestData getProductionTestResult setStablePeriod getStablePeriod getStablePeriodStart getStablePeriodEnd proposeStablePeriod createResult save loadTest isWellSelected Class diagram

13. Established Injecting Testing Producing Closed Closed State diagram

14. EcBsProductionTest.dll EcBsPVT.dll EcBsProductionSystem.dll EcDsProsty.dll Component diagram

15. UML support in software development • Development processes and UML diagrams • Prestudy • Requirements specification/analysis • Construction/design • Implementation

16. Prestudy • Activity diagrams should be used to model/describe the current/future business processes, dataflow etc. • Try to investigate/model the processes at the same abstraction level (used for communication). • Refine processes until the problem space is understood in enough detail to ”find” req’ts. • Do not overdo it (analysis paralysis).

17. Activity Diagrams • Stereotypes may be used to define special activity classes to obtain/show additional information. • Do not use to many colours…

18. Prestudy continued • Use cases and Use case diagrams may be used to describe functional req’ts in existing systems. • Remember that the cardinality between use cases and dialogues is not necessarily 1:1.

19. UML support in software development • Development processes and UML diagrams • Prestudy • Requirements specification/analysis • Construction/design • Implementation

20. Requirement Specification • Functional requirements. • Non-functional requirements. • Not supported directly in UML. • Very important for the design of the software architecture, influence design/ implementation/ selection of support software. • Architectural and system description. • May use implementation diagrams as a sketch.

21. Functional requirements • Use cases and Use case diagrams. • Interaction diagrams (sequence). • Class diagrams (business model). • State diagrams.

22. Use cases • A use case tells a story of reaching a goal,or a set of stories of both getting and failing. • A use case is performed by one actor in a timely manner, i.e. should be achieved in a reasonable time. • Examining the Goals the system supports makes good functional requirements.

23. Use cases • Naming: active verb first. • Use cases may be numerated. • To many use case (50+) may mean a wrong understanding/use of use cases.

24. Use cases • Use cases address “how to make functional requirements readable, reviewable.” • Use cases hold functional requirements in an easy-to-read, easy-to-track, text format. • A use case collects how a goal succeeds/fails; A scenario shows one specific condition; Scenarios & use cases nest. • Use cases show only the functional req’ts. • They make a framework for non-functional requirements & project details. • Design is not done only in use case increments.

25. Use cases • Use cases do not collect formulae, state, cardinality. Capture them separately (e.g. in the scenario descriptions). • Pre- and post-conditions should be used to show dependencies between use cases.

26. Use case diagrams • If you find common behaviour in several use cases, this behaviour may be added in a new use case that the other use cases ”inherits” by use of the <<uses>> stereotype. • Some use cases may represent alternative or exceptions scenarios for an important use case. These use cases may be extensions of the main use case. This may represent optional behaviour.

27. Use case diagrams • Use cases may be organised in diagrams: • Together with related use cases (same business process/area). • For each actor. • Remember that actors represents active roles, not named people or passive systems/people.

28. Use cases and Interaction diagrams • Write the use case scenarios so that you can use the stepwise description directly as steps in interaction diagrams (especially sequence diagrams). • Each use case is normally realised by an interaction diagrams.

29. Business Class Model • Only address business/domain classes. • Classes may be found: • Statically by studying the functional requirements/domain knowledge. • Dynamically from the interaction diagrams. • Show associations, optionally cardinality. • Assign associations when classes need to know about another. Look both ways.

30. Business Class Model • Add important methods/attributes, e.g. from the construction of interaction diagrams. • Remember the meaning of using interaction diagrams in this context; do not dig to deep (then you are designing). • Use analysis patterns where applicable. • May uncover use cases.

31. Business Class Model • If the model grows large, use packages. • Use state diagrams if classes have interesting life cycles. • Build in teams. CRC Cards may be useful. • Use inheritance to make abstractions of common classes. A super class may replace many subclasses/associations.

32. Baseline architecture • Consists of: • Use cases. • Domain model. • Technology platform. • Non-functional requirements. • Foundation for construction/implementation.

33. Persistence • Schemas may be modelled by using class diagrams. • Class = Entity. • Association = Relation. • Association cardinality. • Needs generally to solve M:N relationships. • Tools will normally have functionality to data modelling (ER). Stereotypes may be used to distinguish persistent classes and relations from the business/design class model.

34. UML support in software development • Development processes and UML diagrams • Prestudy • Requirements specification/analysis • Construction/design • Implementation

35. Construction/design • Class and Object diagrams. • Interaction diagrams. • State diagrams. • Activity diagrams.

36. Construction/design • Transform the business model to a design model. Use stereotypes to show where the classes belong, some tools may relate these class variants. Every business class will not be design class. • Some business classes and processes may be modelled as interfaces. Interfaces are independent of implementation.

37. Construction/design • Classes that implement interfaces ”refines” the interfaces. • Interaction/activity diagrams may be used to model algorithms (important functions).

38. Construction/design • Avoid mixing groups of classes that is not related in the same diagram. • Try to achieve loose coupling and high cohesion! Look for reuse of designs from e.g. design patterns.

39. Construction/design • Remember that all relationships (associations, dependencies, aggregations) means coupling. • Coupling is however necessary to make the system do something, to collaborate. • Use packages to handle complexity, to minimize coupling, and keeping the model elements cohesive.

40. Construction/design • Use case scenarios provide the basis for design with responsibilities. • Assign responsibilities to classes that have the knowledge to perform an activity. • Responsibility-based design is based on role-playing a walkthrough of a scenario.

41. Construction/design • Multiple scenarios provide the basis for asserting that the design delivers the required function. • Use of failure scenarios make the design complete & robust. • Split large classes, join small classes. • Decide how to implement cardinalities. • Consider Design by Contract.

42. Software Architecture • UML does not address important non-functional requirements that influence the software architecture. • Use implementation diagrams to model the software architecture. • Identify components and interfaces. Model component interactions. Use class diagrams and interactions diagrams.

43. Software Architecture • Components are typically abstractions at a coarser level than classes. • Components and interfaces may represent a use case at different levels. • Split persistence (data), control (business) and user interface.

44. UML support in software development • Development processes and UML diagrams • Prestudy • Requirements specification/analysis • Design • Implementation

45. Implementation • Implementation issues affects design models. • Programming Language mechanisms. • Architectural issues. • Navigation in associations may be revealed/changed. • Use round-trip engineering to create/update code from design/design from code. • Dependencies may have been introduced. • Some classes may have appeared/disappeared. • Associations may have appeared/disappeared.

46. Testing • Use case scenarios are a good starting point for an acceptance test. • Pre- ,post-conditions and invariants may be of help in defining integration and unit tests (these may be modelled formally by OCL).

47. Summary • Use case (diagrams). • Capture requirements. • Planning and controlling iterations. • Design/implement the most critical/important use cases first. • Grouping of use cases.

48. Summary • Class/Object diagrams. • Business/domain modelling (prestudy). • Specification models (construction). • Do not try to use all available notations. Start with the single stuff (classes, associations, attributes and generalisation). Introduce other notations only if you need them. • Do not model everything, concentrate on key areas. • Keep in mind which stage the model are supposed to be used in.

49. Summary • Interaction diagrams - Shows collaborations. • Looks at the behaviour of several objects within a use case. • May be used to look at the behaviour of business methods, outline algorithms (class method).

50. Summary • Activity diagrams. • Analysing work flow. • Analysing a use case. • Understanding workflow across many use cases. • Dealing with multi-threaded applications.