1. Method – Notation
8 Hours

2. Agenda The Unified Modeling Language Package Diagrams
Component Diagrams
Deployment Diagrams
Use Case Diagrams
Activity Diagrams

3. The Unified Modeling Language
Standard notation is required for communicating models with others.
Blueprint for construction, advanced problems, eliminates tedium for checking correctness.
History:
1997, UML standard by OMG.
Models and Multiple Views
It is impossible all minute details of complex software in a single diagram.

4. Example: Sports being covered from different cameras.
UML has numerous diagrams which, each providing certain view of the system.
Example: Sports being covered from different cameras.
Class C in two diagrams, and operation names in two diagrams.
Diagram Taxonomy
2 groups: Structure and Behaviour diagrams

6. Static structures of elements in the system. They include
Structure Diagrams
Static structures of elements in the system. They include
Package diagram
Class diagram
Component diagram
Deployment diagram
Object diagram
Composite structure diagram
Structure diagrams are used in conjunction with behaviour diagrams, Class with state machine diagram.

7. Behaviour Diagrams
Objects are created and destroyed, they send messages, external events triggers operations.
Use case diagram
Activity diagram
State machine diagram
Interaction diagram
Sequence diagram
Communication diagram
Interaction overview diagram
Timing diagram

8. UML Diagrams in Practice
UML provides detail specification but sometimes proper subset of this notation is sufficient.
Architect specifying the exact 3 dimensions of a light bulb will be foolish.
Conceptual, Logical, and Physical Models
CM captures system in terms of domain entities and its association with other entities.
LM maps conceptual model with key abstractions and mechanisms for overall design.
PM describes software and hardware requirements of system implementation.

9. The Role of Tools
Consistency checking, constraint checking, completeness checking.
It cannot create class structures on its own, it requires a person who is expert in OOD and articulate classification heuristics.
The Products of OOD
End-to-end connection exists among all diagrams.

10. Package Diagrams The benefits of organizing the artifacts
Clarity and understanding
Concurrent model use
Version control
Abstraction at multiple levels
Encapsulation, containment, modularity
Group UML elements
Package, Visibility and Dependencies.

11. Essentials: The Package Notation

12. Essentials: Visibility of Elements

13. Essentials: The Dependency Relationship

14. Dependencies aggregated at packet level

15. Can also be used to organize use cases
Can also be used to organize use cases. For large systems, to bring clarity or to partition work. Good packages, loosely coupled and highly cohesive. package name :: element name

16. Advanced concepts: Import and Access Import is public package import Access is private package import

17. Component Diagrams: Notation
parts, ports and connectors
<<component>> and icon
ports, public.
port name : port type
Provided and required interfaces
Black-box representation

18. One-to-one is not required.
Group interfaces

19. Essentials: The Component Diagram
Ball and socket notation
Assembly connectors/interface connectors
Dependency
Replacing of a component

20. Essentials: Component Interfaces
If more details are required, then interface specification is provided.
CoolControl: start(), stop(), setTemp(), setFanSpeed()
Further detail can also be specified like parameters and return types.

21. Alternate notations with realizations

22. Essentials: Component Realizations
Component is realized by classes Plan, Controller and SensorInput.
Container representation of realization with associations among classes.

23. Advanced Concepts: A component’s Internal Structure
Sub components
<<delegate>>

24. Deployment Diagrams: The Artifact Notation
Physical collection of nodes that serve as the platform for execution.
artifacts, nodes and connections.
Artifact: physical item that implements portion of software, document, related item to software code.

25. Essentials: The Node Notation
Node: computational resource, containing memory and processing on which artifacts are deployed.
Devices: modem, sensor
Execution: database, J2EE server
3d cube icon, visual specification
Communication path, info about connection

26. Essentials: The Deployment Diagrams <<deploy>>
Essentials: The Deployment Diagrams <<deploy>> .xml file <<manifest>> dependency among artifacts

27. Use Case Diagrams
Software projects fails because of lack of proper communication between stakeholders.
Business people and development people.
Use case diagrams provide the context and defines the functionality of the system.
It depicts who interacts with the system and what the outside world wants the system to do.

28. Essentials: Actors Entities that interface with the system.
People or other systems.
Stylized stick figures.
To identify actors, consider their real world roles

29. Essentials: Use Cases What the actors want the system to do for them.
A use case must be a complete flow of activity, from the actor’s point of view.

30. Essentials: The Use Case Diagram
Which actors use which use cases. Who initiates which use case.
Different formats, most include the following:
Name of the use case
Purpose
Optimal flow
Pragmatic flows
Use case name: Maintain Storage Tanks
Use case purpose: provides the ability to maintain the fill levels of the contents of the storage tanks and hence maintain specific sets of water and nutrients tanks.

34. Advanced Concepts: <<include>> and <<extend>> relationships Actors, Nutritionist and Gardner cannot update encyclopedia and manage garden without viewing reports.

35. View reports is not required when manage garden is running, hence extend is used.

36. If extended, specify the extension point

37. Advanced Concepts: Generalization
Like classes, use cases can have common behaviours that others can use cases.

38. Activity Diagrams
Provide visual depictions of flow of activities, in a business, workflow, other processes.
Elements: nodes, control nodes and object nodes.
Control nodes
Initial node and final node
Decision and merge
Fork and join

39. Essentials: Actions Elementary units of behaviour.
callBehaviour action.
Primitive actions that model manipulations of objects and links

40. Essentials: Starting and Stopping
Solid dot start
Bull’s eye stop (circle with nested ‘X’)

41. Essentials: Decision and Merge Nodes
For controlling the flow in a activity diagram.
Diamond shape.
Guard condition.
Merge takes multiple input flows and gives one output flow.

42. Essentials: Partitions, Forks, Joins and Concurrency Fork: One flow in and multiple flows out (Concurrent flows) Join: All incoming flows must be completed before outbound commences

43. Additional Concepts: Object Flows Objects can be shown in activity diagrams. Not recommended.