[办公应用]Module2-UMLDiagrams12Htostudents.ppt

In this section, we will discuss the key concepts of use-case modeling -- the actor and the use case, as well as what relationships can exist between them. We will also look at the artifacts that make up the use-case model: the use-case model, use-case specifications, and activity diagrams. No system exists in isolation. Every system interacts with people or automated systems for some purpose. These interactions result in some sort of predictable result. This predictable result is system behavior. Use cases are the mechanism for capturing the desired behavior for the system that is under development, but do not specify how the behavior is to be implemented. The UML specifies a model for communicating system behavior, the use-case model. A use-case model describes a system’s functional requirements in terms of use cases. It is a model of the systems intended functionality and its environment. The use-case model serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle. When the customer approves the use-case model, you know the system is what the customer wants. You can also use the model to discuss the system with the customer during development. Potential users use it to better understand the system. Designers use it as a basis for their work and to get a system overview. Testers use it to plan testing activities (use-case and integration testing) as early as possible. Those developing the next version of the system use it to understand how the existing version works. Documentation writers use the use cases as a basis for writing the systems user guides. The architect uses the use-case model to identify architecturally significant functionality. The manager use it to plan and follow up on the use-case modeling and the subsequent design. Actors and use cases are discussed on the next several slides. Use this slide to set th