1. UML Advanced Structural Modeling II

2. Basic Structural Modeling
Classes
Attributes, Operations, Responsibilities
Relationships
Dependency, Generalization, Association, Role, Multiplicity, Aggregation
Common Mechanisms
Specifications, Adornments, Common Divisions, Extensibility Mechanisms
Diagrams
Class , Object , Component , Deployment Dagrams

3. Other UML concepts
Interface
Type
Role
Activity Diagram
Package
Component
Deployment Diagram
Process and Threads

4. Interfaces (chapter 11)
Collection of operations used to specify a service
Specify a behavior of an a element (class or component) independent of its implementation
Important for large scale project where different teams are developing different parts of the system
Described by abstract operations (signatures)
Used to model the seams of a system
Components on eah side of seams should not be affected by changes on the other side
Concept supported in Java, Corba IDL, COM

5. Interfaces IStuff Graphical Representation: Or Class Stereotype:
Storable
load()
save()
no attribute

6. Interfaces Relationships
Participate in: generalization, association dependency, realization
Realization: Class or Component may realize one (or many) interface(s):
class provides a set of methods that implement the operations of all the interfaces it realizes
Exemple:
Telemetry
Sensor
IFilter
realization
dependency

7. Types and Roles Types: Roles: Same as Interface + Attributes
Allow to model the semantics of an abstraction and its conformance to a specific interface.
Roles:
In a given context, an instance may present only one of its interface. Each interface represents a role the object plays
Person
Company
e:Employee

8. Activity Diagrams (Chapter 19)
Used to model dynamic aspects of a system
Flowchart showing flow of control from activity to activity
Kind of a State Machine where :
states are activity states and action states
transitions are triggered by completion of activities
Activity is an on-going nonatomic execution within a state machine
Purpose: focus on flows driven by internal processing (not external events), usually the implementation of an operation

9. Activity Diagrams (cont.)
Contains: action state, activity state, transitions, branching, forking/joining, swimlanes
Action State: can’t be decomposed, atomic, not interupted,
Activity State: can be decomposed, non atomic, can be interupted, may have some additional parts (entry/exit actions)
Transitions: triggerless transitions from one state to another, once action or activity ends.
Branching: specifies alternate paths taken based Boolean expression
forking/joining: model concurrent flows
swimlanes: Allow to parttion the activity states into groups, each group representing the business organization responsible for those activities

10. Acitivity Diagram Example
customer
sale
warehouse
request product
process order
pull material
ship order
receive order
bill customer
pay bill
close order

11. Activity Diagrams (Hints and Tips)
Where to use Activity Diagrams:
Before/While developing Use Cases:
Help understand a business process
Capture the workflow of the business that the system will support
Describe Control mechanisms within the system
Describe complex sequential algorithm in an operation
Develop multithreaded applications
Where NOT to use Activity Diagrams:
See how Objects collaborate
See how object behave over its lifetime
Represent complex conditional logic

12. Packages (chapter 12)
General purpose mechanism for organizing modeling elements into groups
Use Packages for Architecture Views
Organize elements semantically close into large chunks
Well structured Packages are loosely coupled and very cohesive
Graphical Representation:
Robot Kinematics

13. Packages (cont.) Package may own other elements
classes, interfaces, components, nodes, collaborations, use cases, other packages.
Package form namespace (same named element cannot be in same package, but can be in two different packages)
Robot Kinematics
Robot Kinematics
+Joints
+Vector
- Matrix
+Joints
+Vector
- Matrix

14. Packages Visibility
Specify whether an element owned by a package can be used by other package:
+ public: any package that import this package can use the feature
# protected: any descendant of the package can use the feature
- private: only the elements in the package itself can use the feature
Collectively the public parts of a package constitute the package’s interface

15. Package Import and Export
Importing a Package grants a one way permission for the elements in one package to access the elements in the other package
Allows to control the complexity of large number of elements in large scale project
Public parts of a package are called its Exports
Parts exported by one package are visible to the contents of the packages that import it
Robot Controller
Robot Kinematics
+Joints
+Vector
- Matrix
<<import>>
<<import>>
+DataCollector
+Control
- Timer
GUI
+Window
+Frame
#EventHandler

16. Package Example GUI DB Facade to Relational Translation AppWin
AppFrame
SQL Generator
Bus.Obj.
Facade Service
Entity Business Object
Control Business Object

17. Components (chapter 25)
Physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces
Physical implementation of a set of logical elements such as classes and collaborations.
Represent physical things that live in the world of bits, on a node
Graphical Representation:
winApp.dll

18. Components (cont.) Three kinds of components:
deployment components - components needed for an executable system, such as dynamic libraries, executables, COM objects, JavaBeans, DB tables, CORBA objects
work product components - source code files, data files, products from development process
execution components - created as a result of an executing system COM+ object instantiated from dll
Five standard stereotypes for components:
executable, library, table, file, document

19. Component - Example of Use 1- Source code dependencies
MathCtrlr.h
MathCtrlr.cpp
Matrix.h
Vector.h
Joint.h
Allow to discover cluster of source code which can be put in a package

20. Component - Example of Use 2- Modeling API (Application Programming Interface)
animator.exe
IScripts
IRendering
IApplication
IModels

21. Component - Example of Use 3- System Configuration
RobotControl.hlp
ForwardKin.dll
RobotControl.exe
RobotControl.ini
InvKin.dll
Target.txt
Telemetry.dll

22. Deployment (chapter 26)
Model of the physical/hardware aspects of a system
Main concept: Node - typically a computational resource
Nodes used to model the hardware topology of the system
Graphical Representation:
edp_server
Node can be tailored to any specific kind of devices using stereotypes
Nodes can be parts of packages
Components are executed by Nodes

23. Nodes Connections Nodes can have different types of relationships:
dependency, generalization, associations
Most common kind of relationship is an association representing a physical connection among nodes
edp_client
workflow_server
Raid farm
connection
node
web_server

24. Nodes and Components Components are allocated/distributed across Nodes
Model distribution of components in nodes by listing them:
edp_client
workflow_server
Raid farm
deploys
wwwf.exe
perl.exe
deploys
netscape.exe
web_server
deploys
iis.exe

25. Processes and Threads (chapter 22)
Used to model independent flow of control
Process is a heavyweight flow that can execute concurrently wih other processes
Thread is a lightweight flow that can execute concurrently with other threads within the same process
Allow to reason about crucial issues such as concurrency, communication, synchonization
Supported in languages: Java, Smalltalk, Ada.

26. Processes and Threads Graphical Representation: Active Class
RobotController
attributes
operations
Signals