Unidad 2 Estructura de un Caso de Uso

Actividad 1 Anlisis y Diseo Orientado a Objetos Investigue en Internet o libros de desarrollo de software: Qu es el anlisis y diseo de software orientado a objetos? Cules son sus principales caractersticas? Qu lenguajes de programacin estn orientados a esta metodologa de desarrollo? Qu diferencia existe con la tcnica de programacin prodecimental o imperativa? Actividad 2 Formato de un Caso de Uso El objetivo de esta actividad es que el estudiante proponga un formato a ser utilizado al momento de determinar los requerimientos funcionales de un sistema de informacin utilizando la metodologa de Casos de Uso. El estudiante deber: Leer el documento Especificaciones de Caso de Uso que se encuentra en el Material de Apoyo del curso, en la seccin de Lecturas Utilizando esta lectura, y la presentacin de Power Point Estructura de un Caso de Uso Cul de los dos formatos le parece ms favorable? Realice una tercer propuesta de formato para ser utilizado en la definicin de los requerimientos funcionales de un sistema de informacin. D una justificacin del formato propuesto Actividad 3 Foro de Discusin: Formatos de Caso de Uso Instrucciones para la actividad Colaborativa Antes de realizar sus aportaciones en el foro de discusin, debe investigar en alguna empresa o grupo de programadores, sus opiniones respecto a la funcionabilidad de los formatos de Caso de Uso, tanto de los dos propuestos aqu en la unidad como el desarrollado por el estudiante. Una vez obtenidos los comentarios de los programadores, proceda a realizar sus aportaciones en el foro. Comparta los resultados de su investigacin y desarrollo de un tercer formato. Lecciones aprendidas Compartir informacin, reflexionar y analizar diferentes puntos de vista con respecto a la informacin compartida por todos lo

Actividad 1 Anlisis y Diseo Orientado a Objetos

Investigue en Internet o libros de desarrollo de software: Qu es el anlisis y diseo de software orientado a objetos?

Es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. es un mtodo donde se realiza un modelo de un sistema mostrando sus interacciones manejadas con una herramienta llamada UML (lenguaje unificado de modelado) que tomando como materiales los requerimientos solicitados y exigidos involucrando en la interaccin entre los objetos el proceso para llegar a una solucin o satisfacer una necesidad. Esto permite dar a conocer de forma clara y entendible a los involucrados.

Primero se analiza el entorno del problema o necesidad tomando y retomando los requerimientos, para luego hacer un diseo de los procesos e interacciones, sin embargo se puede n encontrar ms requerimientos en el transcurso del diseo y pruebas que se realizaran. El Anlisis orientado a objetos ofrece un enfoque nuevo para el anlisis de requisitos de sistemas software. En lugar de considerar el software desde una perspectiva clsica de entrada/proceso/salida, como los mtodos estructurados clsicos, se basa en modelar el sistema mediante los objetos que forman parte de l y las relaciones estticas (herencia y composicin) o dinmicas (uso) entre estos objetos. El uso de Anlisis orientado a objetos puede facilitar mucho la creacin de prototipos, y las tcnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catlogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos obtener rpidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir de objetos analizados, diseados e implementados en aplicaciones anteriores. Y lo que es ms importante, dada la facilidad de reutilizacin de estos objetos, el prototipo puede ir evolucionando hacia convertirse en el sistema final, segn vamos refinando los objetos de acuerdo a un proceso de especificacin incremental.

Cules son sus principales caractersticas?

Las tcnicas orientadas a objetos se basan en organizar el software como una coleccin de objetos discretos que incorporan tanto estructuras de datos como comportamiento. Esto contrasta con la programacin convencional, en la que las estructuras de datos y el comportamiento estaban escasamente relacionadas. Las caractersticas principales del enfoque orientado a objetos son:

Identidad. Los datos se organizan en entidades discretas y distinguibles llamadas objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad. Clasificacin. Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Una clase es una abstraccin que describe propiedades (atributos y comportamiento) relevantes para una aplicacin determinada, ignorando el resto. La eleccin de clases es arbitraria, y depende del dominio del problema. Polimorfismo. El polimorfismo permite que una misma operacin pueda llevarse a cabo de forma diferente en clases diferentes. La implementacin especfica de una operacin determinada en una clase determinada se denomina mtodo. Herencia. El concepto de herencia se refiere a la comparticin de atributos y operaciones basada en una relacin jerrquica entre varias clases. Una clase puede definirse de forma general y luego refinarse en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y aade sus propiedades particulares.

Qu lenguajes de programacin estn orientados a esta metodologa de desarrollo?

c++ objective, c, java, smalltalk, eiffel, ruby, python, ocaml, object, pascal, clips, visual .net, actionscript, cobol, perl, c#, visual basic.net, php, simula, delphi, powerbuilder.

Qu diferencia existe con la tcnica de programacin prodecimental o imperativa?

Imperativa o procedimental La programacin procedimental clsica presenta ciertos problemas, que han ido hacindose cada vez ms graves, a medida que se construan aplicaciones y sistemas informticos ms complejos, entre los que destacan los siguientes: Modelo mental anmalo. Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras la programacin clsica se basa en el comportamiento, representado usualmente por verbos. Es difcil modificar y extender los programas, pues suele haber datos compartidos por varios subprogramas, que introducen interacciones ocultas entre ellos. Es difcil mantener los programas. Casi todos los sistemas informticos grandes tienen errores ocultos, que no surgen a la luz hasta despus de muchas horas de funcionamiento. Es difcil reutilizar los programas. Es prcticamente imposible aprovechar en una aplicacin nueva las subrutinas que se disearon para otra.

La diferencia que exiesten es: Programacin imperativa Opuesta a la programacin declarativa, este paradigma describe la computacin en trminos de un estado del programa y de unas instrucciones que cambian dicho estado. Los programas imperativos son una secuencia de comandos para que el computador realice

Programacin procedimental Es un paradigma de programacin basado en el concepto de llamado de procedimientos

Procedimientos, tambien conocidos como rutinas, subrutinas, metodos ofunciones simplemente consienen series de pasos computacionales.

Cualquier procedimiento puede ser llamado en cualquier punto durante laejecucion de un programa, incluyendo otros procedimientos o en l mismo

Solucin

Fase de Planificacin y Especificacin de Requisitos

Esta fase se corresponde con la Especificacin de Requisitos tradicional ampliada con un Borrador de Mod

una definicin de Casos de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del siste desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado pos

IV.2.1 Actividades Las actividades de esta fase son las siguientes: Definir el Plan-Borrador. Crear el Informe de Investigacin Preliminar. Definir los Requisitos. Registrar Trminos en el Glosario. (continuado en posteriores fases) Implementar un Prototipo. (opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior) Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior) Refinar el Plan. El orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede tamb de las fases de diseo, que se vern ms adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificacin de proyectos so correspondientes a creacin de planes e informes preliminares.

IV.2.2 Requisitos El formato del documento de Especificacin de Requisitos no est definido en UML, pero se ha incluido e que la actividad de definicin de requisitos es un paso clave en la creacin de cualquier producto software. describir los requisitos la tcnica de casos de uso constituye una valiosa ayuda.

IV.2.3 Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos Ntese que UML no define un formato para describir un caso de uso. Tan slo define la manera de represe actores y casos de uso en un diagrama: El Diagrama de Casos de Uso, definido en la pgina 9. Sin embargo individual no es un diagrama, es un documento de texto. En la siguiente seccin se define el formato textua de un caso de uso que se va a utilizar en este documento.. Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica de acciones e intera actores y el sistema. Ms adelante se ver la representacin de los escenarios correspondientes a un caso d Diagramas de Secuencia. En un primer momento interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el for Cuando se quiere describir un caso de uso con ms detalle se usa el formato expandido.

IV.2.3.1 Casos de Uso de Alto Nivel El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est usando un cajer - Caso de Uso: Realizar Reintegro - Actores: Cliente - Tipo: primario - Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar un reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin p Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se condensa en dos o tr comprender el mbito y el grado de complejidad del sistema.

IV.2.3.2 Casos de Uso Expandidos Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencia a un nivel ms detallado: en el formato expandido. La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de

tambin incluye otros apartados como se ve en el siguiente ejemplo: - Caso de Uso: Realizar Reintegro - Actores: Cliente (iniciador) - Propsito: Realizar una operacin de reintegro de una cuenta del banco - Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar que la operacin p Cliente coge el dinero y la tarjeta y se va. - Tipo: primario y esencial - Referencias: Funciones: R1.3, R1.7 - Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero. 2. Pide la clave de identificacin. 3. Introduce la clave. 4. Presenta las opciones de operaciones disponibles. 5. Selecciona la operacin de Reintegro. 6. Pide la cantidad a retirar. 7. Introduce la cantidad requerida. 8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo. 9. Recoge la tarjeta. 10. Recoge el recibo. 11. Recoge el dinero y se va. Cursos Alternativos: Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin. Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la operacin. El significado de cada apartado de este formato es como sigue: - Caso de Uso: Nombre del Caso de Uso - Actores: Lista de actores (agentes externos), indicando quin inicia el caso de uso. Los actores son norma ser humano desempea, pero puede ser cualquier tipo de sistema. - Propsito: Intencin del caso de uso. - Visin General: Repeticin del caso de uso de alto nivel, o un resumen similar. - Tipo: 1. primario, secundario u opcional (descritos ms adelante). 2. esencial o real (descritos ms adelante). - Referencias: Casos de uso relacionados y funciones del sistem requisitos. - Curso Tpico de Eventos: Descripcin de la interaccin entre los actores y el sistema mediante las accion uno. Describe la secuencia ms comn de eventos, cuando todo va bien y el proceso se completa satisfacto haber alternativas con grado similar de probabilidad se pueden aadir secciones adicionales a la seccin pr ms adelante. - Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripcin de la excepc IV.2.3.3 Identificacin de Casos de Uso La identificacin de casos de uso requiere un conocimiento medio acerca de los requisitos, y se basa en la documentos de requisitos existentes, y en el uso de la tcnica de brainstorming Como gua para la identificacin inicial de casos de uso hay dos mtodos: a) Basado en Actores 1. Identificar los actores relacionados con el sistema y/o la organizacin. 2. Para cada actor, identificar los procesos que inicia o en los que participa. b) Basado en Eventos 1. Identificar los eventos externos a los que el sistema va a tener que responder. 2. Relacionar los eventos con actores y casos de uso. Ejemplos de casos de uso:

Pedir un producto. Matricularse en un curso de la facultad. Comprobar la ortografa de un documento en un procesador de textos. Comprar un libro en una tienda de libros en Internet

IV.2.3.4 Identificacin de los Lmites del Sistema En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para que los casos d significado completo es necesario que el sistema est definido con precisin. Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo que es externo exterior se representa mediante los actores. Ejemplos de sistemas son: El hardware y software de un sistema informtico. Un departamento de una organizacin. Una organizacin entera. Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como sistema el prime hardware y el software del sistema que se quiere construir.

IV.2.3.5 Tipos de Casos de Uso a) Segn Importancia Para establecer una primera aproximacin a la priorizacin de casos de uso que identifiquemos los vamos Primarios: Representan los procesos principales, los ms comunes, como Realizar Reintegro en el caso d Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Aadir Nue Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso d abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturale brevedad y abstraccin. Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la so se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos

Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico ten descripcin del Curso Tpico de Eventos: Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 2. Pide el PI Identification Number). 3. Introduce el PIN a travs del teclado numrico. 4. Presenta las opciones de operaciones disponibles. 5. etc. 6. etc. En principio, los casos de uso reales deberan ser creados en la fase de Diseo de Bajo Nivel y no antes. Si proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que so En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decis pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el d una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso E normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Real

IV.2.3.6 Consejos Relativos a Casos de Uso a) Nombre El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un proceso, por ejemplo: Realizar Pedido. b) Alternativas equiprobables Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cur

cuando se tienen distintas opciones, todas ellas consideradas normales se puede completar el Curso Tpico secciones adicionales. As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner opciones que dirigen el ca que se detalla al final del Curso Tpico de Eventos, en la siguiente forma: - Curso Tpico de Eventos: - Seccin: Principal Accin del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando Actor llega al sistema. 2. Pide la operacin a realizar. 3. Escoge la operacin A. 4. Presenta las opciones de pago. 5. Selecciona el tipo de pago: a. Si se paga al contado ver seccin Pago al Contado. b. Si se paga con tarjeta ver seccin Pago con Tarjeta. 6. Genera recibo. 7. Recoge el recibo y se va. Cursos Alternativos: Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin. - Seccin: Pago al Contado Accin del Actor Respuesta del Sistema 1. Mete los billetes correspondientes 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad est satisfecha 3. Devuelve el cambio. Cursos Alternativos: Lnea 3: No hay cambio suficiente. Se cancela la operacin. - Seccin: Pago con Tarjeta ...

IV.2.4 Construccin del Modelo de Casos de Uso Para construir el Modelo de Casos de Uso en la fase de Planificacin y Especificacin de Requisitos se sig pasos: 1. Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los actores 2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundari 3. Se dibuja el Diagrama de Casos de Uso. 4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el D Uso. 5. Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen en el formato deja la definicin en formato expandido esencial del resto de casos de uso para cuando sean tratados en po desarrollo, para no tratar toda la complejidad del problema de una sola vez. 6. Se crean casos de uso reales slo cuando: Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema. El cliente pide que los procesos se describan de esta forma. 7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin).

IV.2.5 Planificacin de Casos de Uso segn Ciclos de Desarrollo La decisin de qu partes del sistema abordar en cada ciclo de desarrollo se va a tomar basndose en los ca cada ciclo de desarrollo se le va a asignar la implementacin de uno o ms casos de uso, o versiones simpl uso. Se asigna una versin simplificada cuando el caso de uso completo es demasiado complejo para ser tr (ver Figura 37).

Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos segn prioridad. un caso de uso especfico que van a hacer que un caso de uso tenga una prioridad alta son las siguientes: a. Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del persistencia en los datos. b. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo. c. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo. d. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva o arriesgada e. Representa un proceso de gran importancia en la lnea de negocio. f. Supone directamente un aumento de beneficios o una disminucin de costes. Para realizar la clasificacin se puede asignar a cada caso de uso una valoracin numrica de cada uno de e conseguir una puntuacin total aplicando pesos a cada apartado. En la siguiente tabla se muestra un ejempl clasificacin: Peso 3 2 4 1 3 4 Suma Caso de Uso a b c d e f Realizar reintegro 5 4 1 0 5 2 50 ...

IV.2.5.1 Caso de Uso Inicializacin Prcticamente todos los sistemas van a tener un caso de uso Inicializacin. Aunque puede ser que no tenga la clasificacin realizada segn el punto anterior, normalmente va a interesar que sea desarrollado desde el Inicialmente se desarrolla una versin simplificada, que se va completando en cada ciclo de desarrollo para necesidades de inicializacin de los casos de uso que se tratan en dicho ciclo. As se tiene un sistema en ca que puede funcionar.

anterior

indi ce

siguiente

Diagrama ul Uml Documento detallado

Introduccin a los casos de uso22 junio, 2010Deja un comentarioIr a los comentarios

Ya hemos realizado una entrevista al director de la empresa Canteras S.L y tenemos un nuestro poder un documento que especifca los requisitos funcionales que debe tener el sistema software que desarrollemos.

Casos de usoUna buena manera de comprender los requerimientos es creando casos de uso.

Un caso de uso es un documento narrativo que describe el comportamiento de un sistema desde el punto de vista de un actor. El actor es una entidad externa del sistema que participa en el caso de uso, suelen ser seres humanos o cualquier tipo de sistema.Para entenderlo mejor vamos a poner un ejemplo. En nuestro caso de estudio podemos identificar a partir de los requerimientos el caso de uso Registrar empresa y el actor Usuarioque es el que registrar la empresa en el sistema mediante una interfaz grfica. Un error comn es identificar las operaciones o transacciones individuales como casos de uso. Un ejemplo de esto en nuestro caso de estudio es identificar la operacin de comprobar si la empresa est registrada en la cantera como un caso de uso. Esa operacin forma parte del caso de uso Registrar empresa, pero no es un caso de uso en s. Los casos de uso son descripciones amplias de un proceso de negocios, esta descripcin abarca muchos pasos o transacciones. Podemos identificar los casos de uso de nuestro sistema software a partir de los actores. Para ello primero identificamos a los actores y para cada actor vemos los procesos de negocios que inicia o en los que participa.

Diagramas de casos de usoUML no especifica un formato para describir casos de uso. UML utiliza diagramas de casos de uso para explicar grficamente un conjunto de casos de uso de un sistema, los actores y la relacin entre estos y los casos de usos.

Formatos de casos de usoNarrativamente podemos escribir un caso de uso en diferentes formatos y con diferentes niveles de detalle:

- Formato de alto nivel: Un caso de uso de alto nivel describe un proceso de negocios del sistema muy brevemente. Utilizamos este tipo de formato durante el examen inicial de los requerimientos para entender rapidamente la funcionalidad del sistema. Una muestra de un caso de alto nivel:

Caso de uso: Registrar empresa Actores: Usuario Tipo: Primario Descripcin: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe. Sino existe registra la empresa en el sistema.- Formato expandido: Un caso de uso expandido describe un proceso de negocios ms a fondo que el de alto nivel. Durante la fase del anlisis conviene escribir en este formato solo los casos ms importantes. Una muestra de dos casos expandidos:

Caso de uso: Registrar empresa Actores: Usuario Propsito: Registrar una empresa en el sistema. Tipo: Primario Descripcin: El usuario registra una empresa en el sistema rellenando los datos de la empresa. El sistema comprueba si la empresa existe. Sino existe registra la empresa en el sistema. Curso normal de los eventos: 1.El usuario introduce los datos de la empresa que quiere registrar. 2.El sistema busca entre las empresas registradas si existe una empresa con el mismo identificador. 3.El sistema informa al usuario que la empresa se ha registrado satisfactoriamente. Cursos alternos: Lnea 3: El sistema informa al usuario que ya existe una empresa con el mismo identificador registrada en el sistema. Caso de uso: Registrar vehculo Actores: Usuario Propsito: Registrar un vehculo en el sistema. Tipo: Primario Descripcin: El usuario registra un vehculo a una empresa en el sistema rellenando los datos del vehiculo. El sistema comprueba si el vehiculo existe. Sino existe registra el vehiculo en el sistema. Curso normal de los eventos: 1.El usuario introduce los datos del vehculo que quiere registrar. 2.El sistema muestra una lista de empresas registradas en el sistema 3.El usuario selecciona una empresa. 4.El sistema busca la empresa seleccionada y muestra los datos de la empresa. 5.El sistema busca en los vehiculos registrados si el vehiculo ya esta registrado en el sistema. 6.El sistema registra el vehiculo en la empresa y muestra un mensaje satisfactorio al usuario. Cursos alternos:

Lnea 6: El sistema no registra el vehiculo y muestra un mensaje informando al usuario que el vehiculo ya est registrado.

Caso esenciales de uso y casos reales de usoLos casos esenciales de uso son casos que se expresan de forma muy abstracta, sin detalles de implementacin. Los detalles de diseo se dejan para la etapa del diseo. En la etapa del diseo veremos los casos reales de uso. Estos casos de uso describen concretamente el proceso de negocios con detalles de diseo y sujeto a tecnologas de entrada y salida, como por ejemplo la interfaz grfica.

Casos de uso dentro de un proceso de desarrolloEn la fase de planificacin y especificacin de requerimientos (en la que estamos ahora) despus de haber definido los requerimientos del sistema software estamos preparados para identificar los casos de uso. 1. Identificamos los actores y los casos de uso. 2. Escribimos los casos de uso en el formato de alto nivel. 3. Relacionamos los casos de uso. 4. Dibujamos un diagrama de casos de uso. 5. Escribimos en el formato expandido los casos de uso ms importantes. En la fase de anlisis escribimos los casos esenciales de uso en formato expandido para los que todava no lo hemos hecho. En la fase de diseo escribimos los casos reales de uso a partir de los casos esenciales de uso de la fase del anlisis.

RESUMENYa hemos visto la teora de los casos de estudio y ya estamos preparados para identificar los casos de uso de nuestro caso de estudio y de dibujar un diagrama de casos de uso que muestre las relaciones de los actores y los casos de uso de nuestro caso de estudio.