Modelado de casos de uso
•Descargar como PPT, PDF•
1 recomendación•9,714 vistas
U.T.P.L. Carrera: Ciencias de la Computación Materia: Metodología y Tecnología de la programación II Periodo: Abril - Agosto 2010 Ponente: Ing. Patricio Abad Espinoza
![Temática ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Modelado de casos de uso
Similar a Modelado de casos de uso (20)
Más de Videoconferencias UTPL
Más de Videoconferencias UTPL (20)
Último
Último (20)
Modelado de casos de uso
- 1. Modelado de casos de uso ESCUELA: Ciencias de la Computación NOMBRE: Ing. Patricio Abad Espinoza FECHA: ABRIL - AGOSTO 2010
- 4. 4.1 Casos de uso Realizar llamadas Enviar mensajes Tomar fotos Capturar video Navegar por la web Reproducir música Grabar notas de voz Tomar notas de texto Planificar citas Visualizar archivos
- 8. Diagramas de casos de uso
- 10. Definir el esquema de UC Nombre del UC Descripción breve Flujo básico 1. Paso 1 2. Paso 2 3. Paso 3 A1 Flujo alterno 1 A2 Flujo alterno 2 A3 Flujo alterno 3 Estructurar el flujo en pasos Numerar los pasos
- 11. ¿Porque esquematizar el UC? La estructuración ayuda a encontrar flujos alternos Borrador Use Case ¿Muy pequeño? Use Case Size ¿Muy grande? ¿Hay mas de un caso de uso? ? ? ?
- 13. Representación de flujos Step1 Step2 A1 A3 Step4 A4 Step3 A2 A5 <Nombre del Caso de uso> 1. Descripción breve 2. Flujo de eventos 2.1 Flujo básico Paso 1 Paso 2 Paso 3 Paso 4 2.2 Flujos alternos 2.2.1 A1 … 2.2.2 A2 … 2.2.3 A3 … 2.2.4 A4 … 2.2.5 A5 … Básicos y Alternos
- 14. Qué es un escenario? Flow Scenario Flujo : Una secuencia de pasos. Caso de uso : El contenedor que describe todos los flujos Escenario : Un conjunto ordenado de flujos desde el inicio hasta una de las salidas del caso de uso.
Notas del editor
- utpl
- utpl
- utpl
- MRMUC Instructor Notes Module 6 - Define the System Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later you add in the descriptions. The outlines are not official documents, but a start toward developing a document. The outlines would probably be sketched on easel paper at a requirements workshop. The basic flow shows the major steps in accomplishing the goal of the use case. The alternative flows show alternative behavior: what may go wrong and optional behavior. Animation is automatic; structure the flow into steps with either bullets or numbers. Review the basic concepts for developing a use-case outline. See Student Notes. Ask: Why do you think we number the steps in the flows? Answer: It makes the sequence easier to understand. It helps you identify specific steps.
- MRMUC Instructor Notes Module 6 - Define the System Some of the reasons to outline your use cases are: Iterative development reduces risk. For the same reason we do not implement the whole system in one hit, we do not develop the detailed requirements all at once. Avoid getting bogged down in too much detail too early. You do not know everything at once. Outlining helps you discover what you don’t know. Outlining use cases creates a rough draft for fully specifying your use cases. Outlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help decide whether the use case is actually more than just one use case. Once you write out your steps, you might find that they really belong in another use case. If the outline shows that the use case does not have much to it, it may not be a use case at all. Outlining adds value to finding all possible alternate flows.
- MRMUC Instructor Notes Module 6 - Define the System The outline of the flow of events for a use case has two main sections: Basic Flow of Events. Alternative Flow of Events. The outline is used as a base when you start to write the full use-case specification. Structure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up or finish. The basic flow of events should be relatively short and very easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. Most of the other details go into alternative flows. You can think of the alternative flows as “detours” from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are: Regular variants : Handle freshman enrollments differently. Odd cases : Handle registering for over 25 credit-hours differently. Exceptional (error) flows : Invalid student ID Number. You develop both the basic and alternative flows in the outline you make in the Find Actors and Use Cases activity. Note, the diagram above is informational only and is not a valid UML diagram. This slide adds more depth about basic and alternative flows. Review some reasons to have alternative flows of events. Ask: “Why not just put all the descriptions of all the options into the basic flow of events?” Answer: Because it would be hard to read, like reading a flowchart in text form. The basic flow of events should be relatively short and very easy to read (like a single story). Typically, most of the other descriptions are located in alternative flows. A short example may help to illustrate the different kinds of subflows (see Student Notes).
- MRMUC Instructor Notes Module 6 - Define the System The basic and alternative flows of events are captured in sections of the use-case specification. Each flow has its own section in the use-case specification. The steps in each flow are listed within the flow’s section.
- MRMUC Instructor Notes Module 6 - Define the System A scenario describes an instance using the system (an instance of a use case). It is one path through a use case flows from its beginning to one of its end points. Each use-case has a web of flows of events with a scenario being a particular path through the web. When you describe this path, you are describing a scenario of the use case. The scenario might involve the basic flow and any number of alternative flows in any number of combinations. In the above example, the bold lines highlight some possible scenarios for the basic and alternative flows previously described. How many scenarios are needed? Simple answer: As many as one needs to understand the system being developed. You should elaborate the scenarios of the interesting and high-risk use cases. Scenarios can be used to understand, as well as to validate the use-case flows of events. Some people write scenarios first and extract use cases, while others find use cases first and validate those use cases by writing scenarios. Scenarios make excellent test cases. When planning a project, we need to decide which use cases or which flows we plan on building in the current iteration. If you have enumerated the scenarios for a use case you can use those as a planning mechanism. You allocate a scenario to an iteration.
- MRMUC Instructor Notes Module 6 - Define the System Documenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios. Each scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but use different data values to ensure all the boundary conditions are tested. Give the scenario a descriptive name and list the flows (in order) that make up the scenario. Scenarios should be captured in a separate section of your use-case specification or as part of your test cases. The benefit of capturing the scenarios in the use-case specification is that all the information required for analysis, design, and test is co-located with the use-case description. Scenarios do not contain details of the data that is input to or output from the system. That information forms part of your test cases. Note : Currently the RUP use-case specification template does not contain a section for listing scenarios. You can customize the templates if you wish to capture scenarios in your use-case specifications. According to the book Use Case Modeling by Kurt Bittner and Ian Spence, “Capturing scenarios is useful for a number of reasons: The scenarios will match your test cases. Scenarios are what actually gets performed, so they are useful for discussing what the system will do in practice. Scenarios are useful for analysis and design, since they help the developers think about how the system will be used.” This style came from Kurt Bittner’s and Ian Spences’ book.
- MRMUC Instructor Notes Module 6 - Define the System Here is a list of questions to help you make decisions about the details in the flow of events. Alternative flows describe how the system should behave when things go wrong or when unusual things happen. When working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. At this point in the process, however, it is enough to identify the alternatives without describing them in detail. This is a good list of questions for students to use in developing their own flow of events. Suggest that the students mark this page so they can find it easily. Use lots of examples to illustrate the differences between the types of alternative flows. There is a different question to identify each type. What variations or options do we need to consider? What unusual circumstances must be handled a bit differently? What can go wrong? The point is to be able to identify all of the alternatives needed in a use case.
- MRMUC Instructor Notes Module 6 - Define the System This is an example of a step-by-step outline for a use case. It shows a step-by-step outline for the Get Quote use case from the RU e-st system. The basic flow shows the major steps. The alternative flows show optional behavior. Notice the level of detail in this example. Remember, this is just a brief step-by-step outline to help understand what functions are contained in the use case. Further describe these steps in Module 8, Refine the System Definition. Go over the outline. This is a first draft for the use case, and we develop more detail later. For those not familiar with stock trading, you might need to explain that a “quote” refers to getting the currently traded price of a stock. Points for discussion: What can you tell about the use case by looking at this outline? What questions might you have about this use case that are still not defined?
- MRMUC Instructor Notes Module 8 - Refine the System Definition There are many styles for writing flows of events. One of the styles Rational® uses is to number and title each step. This gives the reader an overview of the flow without all the details and can refer to a step when it is being reviewed. There are many other styles. You can encourage consistency in style by specifying acceptable style guidelines when you write your Use-Case Modeling Guidelines. When you detail each step in the outline, be sure to describe the flow of events, not only what the system is doing. A suggestion for how to enforce this is to start every step with “When the [actor] ... ” Rational recommends making each step in the flow of events show a roundtrip of events, usually in the form of messages: What the actor does: <Actor> messages <System> , and What the system does in response: <System> messages <An Actor> ... Making each step a roundtrip ensures testability, ensures adherence to the purpose of a use case, and makes sequence diagrams far easier to develop and read. However, observe that step 3 is not a roundtrip of events. In this particular case, it made the use case description easier to read if we described the user action on its own. You should strive for roundtrip descriptions, but they are not always be practical. Some interactions are system-controlled. That is, after the user’s initial request to begin the use case, the system controls the interaction: the system asks for information and the user supplies information. The system asks for additional information and the user supplies it, and so on. In these cases, a roundtrip within a step would begin with system actions and then have the user response. Animation: Starts automatically after 2 seconds. Review the example of a basic flow for RU e-st. Remind students that this topic was introduced and discussed in the Introduction to Use-Case Modeling module. The student notes are the same as the corresponding slide in the Introduction to Use-Case Modeling module. The repetition is intended to remind students about writing flows of events and to prepare them for the exercise in writing detailed flows of events for the class project. Detail the use case by defining the basic flow of events. Structure flow into steps. Number each step. Describe each step in 1-3 sentences. Make each step a roundtrip event.
- utpl