APPENDIX M INTRODUCTION TO THE UML

Transcription

1 M INTRODUCTION TO THE UML This appendix, written only for those readers not familiar with the topic, provides a brief introduction, which cannot be considered as exhaustive, to the UML. The UML is a general-purpose visual modeling language used to specify, visualise, construct, and document the artifacts of a software system. Through visual modeling, the UML facilitates the communication between anyone involved with the project, because the complexity of the system to be developed could be understood better when displayed to us graphically as opposed to written textually. The following tables and figures present a number elements of the UML used in the present thesis. Table M.1 Business modeling A business actor is anyone or anything, a human or an information system, that is external to the organisation but interacts with it. A business worker represents a role or set of roles in the business. A business use case is a group of related workflows within the organization that tells the reader, at a high-level, what the organization does to provide value to the business actors. An organisational unit is used to group together business modeling elements such as business actors and business use cases appropriate for that unit. It tells us how the company is structured. A business entity represents an object that the organization uses to conduct its business or produces during the course of its business. Examples might be sales order, account, or contract. 253

2 A business use case diagram shows the business use cases, business actors, and business workers, and the interactions between them. It gives you the scope of the organisation, so you can see what it encompasses and where its borders are. An arrow from a business worker to a use case suggests that the worker initiate the use case. An arrow from a business use case to a business actor suggests that the organisation initiates communication with the business actor. Business Class diagram shows relationships between workers and business entities. It indicates how workers relate both to each other and to things within the business. 254

3 The structure of the workflow is described graphically with a UML activity diagram. It provides a pictorial representation of the workflow structure described in text in the business use-case specification. Activity diagram showing who performs the activities. A Business Sequence diagram shows the interaction among business workers and business actors, and also shows how business entities are accessed during the performance of a business use case. Table M.2 The new system Actor An actor is anyone or anything that interacts with the new system. Actors stimulate the system and are the initiators of events; they also can receive stimuli from system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose. When a system is implemented actors are implemented by physical objects. A Use Case is a high-level piece of functionality that the system will provide. It typically represents a major piece of functionality that is complete from beginning to end. It must deliver something of value to an actor. More strictly, a use case specifies a sequence of actions, including alternatives of the sequence that the system can perform, interacting with actors of the systems. By looking at the use cases, the customer can see what functionality will be provided, and can agree to the system 255

4 scope. Each use case must be mapped into the classes that implement the system. A class may have more than one use case. Use-Case diagrams While business Use-Case diagrams are not concerned with what is automated, Use-Case diagrams focus on just the automated process. There is not a one-to-one relationship between business use cases and use daces. Use-Cases represent (overall) system functionality, the requirements of the system from the user s perspective. A Use-Case diagram documents the actors, the use cases, and their relationships. We can view these diagrams and understand what the system is supposed to accomplish. An association relationship is a relationship between a use case and an actor. Although information flows in both directions, the direction of the arrow indicates who initiates the Use-Case diagram and communication. With the exception of use cases in includes and extends relationships, every use case must be initiated by an actor. An include relationship allows one use case to use the functionality provided by another use case. No matter how you proceed through the Purchase Ticket use case, the Check Credit use case always runs An abstract use case: is not started directly by an relationships actor; provides some additional functionality that can be used by other use cases; participates in an includes or extends relationships. In this example, 'Check Credit' is an abstract use case. The actor will run either the 'Purchase Ticket' or Change Reservation use case, but not the 'Check Credit' use case directly. An extend relationship allows one use case the 256

5 option to extend the functionality provided by another use case. Check Credit use case extends the Change Reservation use case. While the Change Reservation is running, Check Credit runs if and only if the amount of the reservation has changed. Customer Customer Service Representative Accounts Payable Clerk Write letter requesting refund Refund Request [New] The diagram can display the object and its state so that you can understand where and how the object s state changes. Objects are linked to activities through object flows (dashed arrows drawn from an activity to the object it changes, or from the object to the activity that needs to use it). Review request Refund Request [Denied] Create rejection letter [ Missing documentation ] [ Valid request with documentation ] An object (square symbol) is an entity that may be used or changed by an activity in the flow. File request Create refund check Refund Request [Approved] Notify customer Transitions between activities in different swimlanes indicate who needs to communicate with whom. Activity diagrams illustrate the flow of functionality is a system. They may be used in business modeling to shoe the business workflow, and in requirements gathering to illustrate the flow of events through the new system s use cases. The diagram shows where the workflow starts, where it ends, defines what activities occur during the workflow and in what order, the decision points in the workflow, who is responsible for completing each step, and the objects that are affected by the workflow. A transition (arrows symbols) shows how the flow of control moves from one activity to another. If needed, place greater details on the transitions, describing the circumstances under which the transition may or may not occur, and what actions will be taken during the transition. For this UML uses either an event or a guard condition. If an event is specified, the event must happen in order for the transition to occur. For an event, the transition arrow is labelled with the event name, along with any arguments in parenthesis. While an event triggers a transition, a guard condition controls whether or not the transition can occur. If a guard condition is present, it must be true in order for the transition 257

6 to occur. A guard condition is listed along the transition arrow enclosed in square brackets. Also, a way to show that two or more activities occur simultaneously is to use vertical or horizontal synchronization bars symbols, that can contain a fork (in which the control of the workflow is split into branches) or a joint (after which the workflow again has only one thread of control). Entity objects hold information and conduct business functionality Boundary objects are the forms and Windows of the application and the interfaces to the other applications. Control objects (called manager objects). They are optional objects that control the flow through the use case. An object is an entity affected by the workflow. The Interaction diagram shows, step-by-step: one of the flows through a use case; what objects are needed for the flow; what messages the objects sent to each other; what actor initiates the flow; and what order the messages are sent. Two types of Interaction diagrams are used to show the objects participating in a flow through a use case and the messages that are sent between the objects. These are The Sequence diagram (ordered by time, and showing the focus of control) Sequence diagram shows the flow of logic (functionality) through one of the flows through a use case Each arrow represents a message passed between actor and object or object and object to perform the needed functionality. Later, each Massage Name will become an Operation Name for the class. Reflexive message showing that an object is calling on its own operations. Sequence diagrams display objects not classes When we add a message to an Interaction diagram, we are assigning a responsibility to the object receiving the message. 258

7 Collaboration diagram (organised around the objects themselves, and showing the data flow). Objects (rectangles) that directly communicate with each other are shown with a line drawn between them. The absence of a line means that no communication occurs directly between objects. Several alternate flows will require several Interaction diagrams. While the Flow of Events focus of what the system needs to do, the Sequence and Collaboration diagrams define how the system will do it. While class names are very generic (e.g. Employee), the object names are very specific (e.g. John Doe). Collaboration diagrams show exactly the same information as the Sequence diagrams, but the focus is the interaction between objects shown without reference to the time. The Interaction diagrams become the cornerstones upon which the rest of the design is built. 259