UML Advanced Structural Modeling II

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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