UML PSM

UML Protocol State Machines

• always defined in the context of a classifier (e.g. a class or interface)
• specifies which operations of the classifier can be called in which state and under which condition
• states of protocol state machine cannot have entry, do and exit behaviors
• protocol state machines cannot have history and deep history pseudo states
• transitions of protocol state machines cannot have effects
• transitions have [precondition]trigger/[postcondition]:

• classifier operations not represented in a protocol state machine do not have an impact on state
• protocol conformance defined explicitly via ProtocolConformance (specific state machine, general state machine tuple)

Use Case In UML 2.0

Use Case in UML 2.0

Use case diagram has below key elements:
1. Actors:
2. Use Cases:
To describe the functionality unit which can be detected by the external world provided by the system. It is depicted to interaction between the system unit and one or more actors who intercts with it.
3. Relationships
1. Extend:
The extend relationship specifies that the behavior of a used case may be extended by the behavior of another use case. It is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in another used case which is meaningful independently of the extending use case. It is something like the relationship between the base interactions(extended use case) and the supplementary services(extending use case).
This relationship also has below elements:
a) Condition: Reference the condition that must be hold when the first extension point is reached for the extension to take place. If no condition is associated with the extend relationship, the extension is unconditional.
b) Extension point. Please see below element on the description.
2. Include
This is quite a simple relationship, in which the behavior of a use case (included use case) can be inserted into behavior of another use case (including use case). The include relationship is extended to be used when there are common parts of the behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the base use cases having this part in common. Since the primary use of the include relationship is for reuse of the common parts, what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful.
4. Extension points:
Do not confuse it with the extend relationship!
It is a feature indicating a point where the behavior of a use case can be augmented with elements of another (extending) use case. In other words, this point resides in the extended use case, while the extended case adds the behavior at this point. And please also note that the extending case is not aware of the existence of the extending use cases. This is like the trigger point of the base interaction flow.
5. Extension Location
6. Subject:
7. Package: Usually the use case are owned by the package.

UML 4+1 View Materials

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different perspective to classify and apply UML diagrams. The 4+1 view is essentially how a system can be viewed from a software life cycle perspective. Each of these views represents how a system can be modeled. This will enable us to understand where exactly the UML diagrams fit in and their applicability.

These different views are:

• Design View: The design view of a system is the structural view of the system. This gives an idea of what a given system is made up of. Class diagrams and object diagrams form the design view of the system.
• Process View: The dynamic behavior of a system can be seen using the process view. The different diagrams such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are used in this view.
• Component View: Next, you have the component view that shows the grouped modules of a given system modeled using the component diagram.
• Deployment View: The deployment diagram of UML is used to identify the deployment modules for a given system. This is the deployment view of the
• Use case View: Finally, we have the use case view. Use case diagrams of UML are used to view a system from this perspective as a set of discrete activities or transactions.

------------------------------

The Unified Modeling Language (UML) was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobson (the Three Amigos) as a way to define large complicated systems. This small page summarizes and over-simplifies some of their important work. Although titled 'UML' some of the Rational Unified Process (RUP) has somehow crept in.

1. UML has a Four+1 view of a system:
   1. Use Case View (the '+1' part).

      This spans all the other views and is central to UML and the Rational Unified Process. It presents a user centric view of the system without regard to implementations. The Use Case view should focus our attention all through the software development process on what we are really trying to accomplish. The main elements of this View are

      1. Actors - outside entities that interact with the system. These can be people or other systems. Represented by a stick figure.
      2. Use Cases. Represented by an oval.
      3. Use Case Diagrams. Contain actors with relationships.
      4. Interaction (Sequence, Collaboration) Diagrams
      5. Packages
   2. Logical View

      This view shows both the static and dynamic views of the system. The logical view concentrates on getting the best logical grouping of functionality into objects. The main objects of this View are

      1. Classes
      2. Stereotypes
      3. Packages
      4. Class Diagrams
      5. Relationships
      6. Collaborations
      7. Interactions
   3. Implementation View

      This view concentrates on taking the Logical view and dividing the logical entities into actual software components.

      1. Components
      2. Component Diagrams
      3. Hierarchy of Classes and Packages
   4. Process View

      This view is concerned with how all the independent flows of execution play together.

      1. Processes
      2. Interconnections between processes and threads
   5. Deployment View

      This view details how the software is deployed into that somewhat important layer we call 'hardware'.

      1. System performance
      2. Design times for responses
      3. Quality of Service (QoS)
      4. Maintenance frequency and effects on uptime
      5. Computing nodes within the system
2. UML has eight and a half types of diagrams
   1. Activity - the actions taken by an operation
   2. Class diagram - the static relationships, methods, and fields of an object
   3. Collaboration - the relationship between components
   4. Sequence - flow of events over time (oddly enough contains the same info as Collaboration)
   5. Component - the physical components
   6. Deployment - how to push the software to hardware
   7. Object - objects and their relationships
   8. Statechart - operation of system shown through states
   9. Use Case - the functions of a system from the user's perspective.

----------------------------