Use Case Diagrams

The simplest diagram in UML is the Use Case Diagram. Use Case diagrams show the functionality of a system. The diagrams have basically 3 components. First, the actor, represented by a stick figure, is usually a human user of the system, or some resource external to the system.

A Use Case is a system resource or subsystem with whom the users interact. It is a functional component needed by the users to complete a task. Use Cases are described in UML as an ellipse that is labeled.

Second, there is the system boundary, which will encompass the appropriate Use Cases. It is possible that there could be several of these system boundaries in one Use Case diagram. Such a diagram would show the interdependence of subsystems. System boundaries are also customarily labeled.

Finally, there arethe association connections that show the transfer of information between actors and use cases. It is customary, though not required to have arrows depicting the direction of the flow of information.

The above example of a Use Case diagram depicts a simplified typical business transaction beginning with the entry of an order by the salesperson, through the manufacturing and purchasing process, to the shipping and billing of the customer phase. These types of diagrams are intended only to demonstrate the functional relationships in the system and the system’s interaction with the users. The Use Case diagram is useful in defining the boundaries of systems. It differs from a flow chart in terms of absence of logical progression and decision branching.

Class and Object Diagrams

A Class Diagram depicts the general outline of a system.

In the above diagram, the Project Manager obtains specifications (is guided by) from the project document, and manages the development team by setting their goals, defining their tasks, and setting priorities. The team, utilizes the resources of the system, among other things to bring about the eventual success of the project.

Several things are worth noting from the simple diagram. First, the nature of each relationship can be noted by the direction of the arrows and by interpreting the transitivity of the verbs associated with the link. Note that the Manager is guided by the Project Document to manage the team. The team, in turn, utilizes the System resources. Secondly, the manager uses his ‘powers’ or methods to accomplish his tasks. Even though he ‘is guided by’ the project document, he gets requirements from the PD. The PD, has a method called GiveProjectRequirements(). However, notice that it is a private function,and hence not available to just anyone. That classes VerifiesAuthorization() function is public and if it succeeds, it is like that THAT function will trigger the one to GiveProjectRequirements().

In addition, there are a number of attributes, both public and private designed to expose or conceal the internal structure and workings of the classes, as appropriate to the system in general. It is this feature, called encapsulization, which makes it much easier to work on complicated systems with many parts. A developer may create a small part of the system and by employing encapsulization may use many other parts of the system without worrying about the different parts interfering with one another.

The Object Diagram is a specific instance of a Class diagram that shows the state of the project at a specific moment in time.