Está en la página 1de 41

ANLISIS Y MODELADO DE SISTEMAS DE INFORMACIN

Unidad 4. Modelo de requisitos


4.1. Modelos de casos de uso. 4.1.1. Actores, Casos de uso, requerimientos funcionales y no funcionales. 4.1.2. Prototipos para casos de uso. 4.1.3. Documentacin. 4.2. Modelo de interfaces. 4.3. Modelo del dominio del problema. 4.3.1. Identificacin de clases. 4.3.2. Identificacin de asociaciones. 4.3.3. Identificacin de atributos. 4.3.4. Diccionario de clases. 4.3.5. Identificacin de mdulos.
Recopilado por: M.I Norma H. Jimnez Alor

Unidad 4. Modelo de requisitos Competencias


Identificar reas de oportunidad en una organizacin, para la propuesta y diseo de sistemas de informacin. Analizar diversas alternativas de solucin a partir de la identificacin y definicin de requerimientos especificados por el cliente. Establecer una propuesta para el anlisis y diseo de un proyecto de software de acuerdo a la alternativa de solucin planteada o establecida. Planificar y gestionar proyectos de sistemas de informacin con base en una metodologa de desarrollo. Aplicar principios de ingeniera del software en las etapas de anlisis y diseo de un sistema de informacin. Modelar casos de uso acorde a los requerimientos del proyecto.

Documentar el proyecto.
Recopilado por: M.I Norma H. Jimnez Alor

Introduccin a UML

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de modelado y no un mtodo o un proceso. El UML est compuesto por una notacin muy especfica y por las reglas semnticas relacionadas para la construccin de sistemas de software. El UML en s mismo no prescribe ni aconseja cmo usar esta notacin en el proceso de desarrollo o como parte de una metodologa de diseo orientada a objetos.
Recopilado por: M.I Norma H. Jimnez Alor

Introduccin a UML..
El

UML soporta un conjunto rico en elementos de notacin grficos. Describe la notacin para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cmo modelar la relacin entre esos elementos. El UML tambin soporta la idea de extensiones personalizadas a travs elementos estereotipados.

Recopilado por: M.I Norma H. Jimnez Alor

Modelos de casos de uso


El

modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad discreta de interaccin entre un usuario (humano o mquina) y el sistema. modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema.

El

Recopilado por: M.I Norma H. Jimnez Alor

Los

diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.

Recopilado por: M.I Norma H. Jimnez Alor

Su

ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente tiles en la comunicacin con el cliente.

Recopilado por: M.I Norma H. Jimnez Alor

Elementos bsicos
Actores Los actores representan un tipo de usuario del sistema. Se entiende como usuario cualquier cosa externa que interacta con el sistema. No tiene por qu ser un ser humano, puede ser otro sistema informtico o unidades organizativas o empresas.

Siempre hay que intentar independizar los actores de la forma en que se interacta con el sistema. Por ejemplo un teclado no es un actor en la mayor parte de los casos, slo un medio para introducir informacin al sistema. Suele ser til mantener una lista de los usuarios reales para cada actor.
Recopilado por: M.I Norma H. Jimnez Alor

Elementos bsicos

Un actor en un diagrama de casos de uso representa un rol que alguien puede estar jugando, no un individuo particular por lo tanto puede haber personas particulares que puedan estar usando el sistema de formas diferentes en diferentes ocasiones.

Recopilado por: M.I Norma H. Jimnez Alor

Elementos bsicos
Casos de uso

Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se est desarrollando. Se representan mediante un valo. Cada caso de uso debe detallarse, habitualmente mediante una descripcin textual.

Recopilado por: M.I Norma H. Jimnez Alor

Elementos bsicos
Asociaciones

Hay una asociacin entre un actor y un caso de uso si el actor interacta con el sistema para llevar a cabo el caso de uso.

Recopilado por: M.I Norma H. Jimnez Alor

Elementos bsicos
Un caso de uso debe especificar un comportamiento deseado, pero no imponer cmo se llevar a cabo ese comportamiento, es decir, debe decir QU pero no CMO. Esto se realiza utilizando escenarios. Un escenario es una interaccin entre el sistema y los actores, que puede ser descrito mediante una secuencia de mensajes. Un caso de uso es una generalizacin de un escenario.

Recopilado por: M.I Norma H. Jimnez Alor

Ejemplos: Escenario 1: Jos Garca se lleva prestado el tercer ejemplar de Guerra y Paz que hay en la biblioteca. No tiene ningn otro libro en prstamo. Escenario 2: Mnica Daz intenta llevarse prestado el primer ejemplar de Ana Karenina, pero no puede porque ya tiene tres libros en prstamo, que es el mximo. Todos los escenarios de un caso de uso deben tener en comn que son intentos de hacer esencialmente lo mismo, en este caso llevarse un libro en prstamo. Los escenarios pueden y deben posteriormente documentarse mediante diagramas de secuencia.
Recopilado por: M.I Norma H. Jimnez Alor

Recopilado por: M.I Norma H. Jimnez Alor

Tipos de asociaciones
Existen tres tipos de asociacin o relaciones en los diagramas de casos de uso: Include: Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar comportamiento comn en dos o ms casos de uso.

En la imagen anterior tanto Reservar Libro como Renovar prstamo hacen algo en comn Comprobar reserva.
Recopilado por: M.I Norma H. Jimnez Alor

Las ventajas de esta asociacin son:


Las descripciones de los casos de uso son ms cortas y se entienden mejor. La identificacin de funcionalidad comn puede ayudar a descubrir el posible uso de componentes ya existentes en la implementacin.

Las desventajas son: La inclusin de estas relaciones hace que los diagramas sean ms difcil de leer, sobre todo para los clientes.
Recopilado por: M.I Norma H. Jimnez Alor

Extend: Se puede incluir una relacin entre dos casos de uso de tipo include si se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relacin implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En principio esas variaciones pueden tambin mostrarse como diferentes descripciones de escenarios asociadas al mismo caso de uso. La flecha en el caso de las relaciones extend va hacia el caso de uso original.

Recopilado por: M.I Norma H. Jimnez Alor

Generalizaciones: En un diagrama de casos de uso tambin pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos estn relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos ltimos la semntica es muy similar a las relaciones extend.

Recopilado por: M.I Norma H. Jimnez Alor

Limites del sistema: Resulta til dibujar los lmites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema .

Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de clases

El propsito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programacin. Un diagrama de clases o estructura esttica muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes entre clases y objetos.

Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de clases
Clase: representa un conjunto de entidades que tienen propiedades comunes.

Una clase es un constructo que define la estructura y comportamiento de una coleccin de objeto denominados instancia de la clase. En UML la clase est representada por un rectngulo con tres divisiones internas, son los elementos fundamentales del diagrama.
Recopilado por: M.I Norma H. Jimnez Alor

Clase: representa un conjunto de entidades que tienen propiedades comunes.

Una clase es un constructo que define la estructura y comportamiento de una coleccin de objeto denominados instancia de la clase.

En UML la clase est representada por un rectngulo con tres divisiones internas, son los elementos fundamentales del diagrama.
Recopilado por: M.I Norma H. Jimnez Alor

Recopilado por: M.I Norma H. Jimnez Alor

Multiplicidad: Describe la cardinalidad de la relacin, es decir, cuanto objetos de esa clase pueden participar en la relacin dada. La multiplidad puede ser:

Recopilado por: M.I Norma H. Jimnez Alor

Herencia (Especializacin/Generalizacin):

Indica que una subclase hereda los mtodos y atributos especificados por una superclase, por ende la subclase adems de poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de la superclase (public y protected), ejemplo:

Recopilado por: M.I Norma H. Jimnez Alor

Agregacin:

Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Recopilado por: M.I Norma H. Jimnez Alor

Agregacin:

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).

Recopilado por: M.I Norma H. Jimnez Alor

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.

Recopilado por: M.I Norma H. Jimnez Alor

En donde se destaca que:

Un Almacn posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el objeto Almacn tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.

Recopilado por: M.I Norma H. Jimnez Alor

Asociacin:

La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.
Recopilado por: M.I Norma H. Jimnez Alor

Dependencia o Instanciacin (uso):

Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicacin grfica que instancia una ventana (la creacin del Objeto Ventana esta condicionado a la instanciacin proveniente desde el objeto Aplicacin):

Recopilado por: M.I Norma H. Jimnez Alor

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicacin).

Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de secuencias
Los

Diagramas de Secuencias muestran la forma en que un grupo de objetos se comunican (interactan) entre s a lo largo del tiempo

Un Diagrama de Secuencia consta de objetos, mensajes entre estos objetos y una lnea de vida del objeto representada por una lnea vertical

Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de secuencias

Los diagramas de secuencia describen como los objetos del sistema colaboran. Se trata de un diagrama de interaccin que detalla como las operaciones se llevan a cabo, qu mensajes son enviados y cuando, organizado todo en torno al tiempo. El tiempo avanza hacia abajo en el diagrama. Los objetos involucrados en la operacin se listan de izquierda a derecha de acuerdo a su orden de participacin dentro de la secuencia de mensajes.

Recopilado por: M.I Norma H. Jimnez Alor

Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de secuencias

Las lneas verticales o lneas de la vida representan el tiempo de vida del objeto. La vida del objeto Carlos no termina en este diagrama, sin embargo la del objeto tosty s y esto viene representado mediante el aspa al final de su lnea de la vida. Los rectngulos verticales son barras de activacin y representan la duracin de la ejecucin del mensaje. El mensaje Encender, posiblemente implementado mediante la introduccin del enchufe en una toma de pared, tiene una duracin escasa y similar a la de Apagar. No ocurre lo mismo con la llamada al mtodo
Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de secuencias

tostar(), que dura desde la pulsacin del botn de tostar hasta que el pan es retirado de la bandeja y adems interviene la emisin de un aviso cuando el pan est lo suficientemente caliente, a fin de evitar que se queme. Como se puede observar, la accin tostar viene condicionada por la presencia de pan en la bandeja de la tostadora. En UML los corchetes [] expresan condicin y si estn precedidos de un asterisco indican interaccin mientras se cumpla la condicin.
Recopilado por: M.I Norma H. Jimnez Alor

Diagramas de secuencias

Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia pueden ser sncronos o asncronos. Los mensajes asncronos son aquellos tal que el emisor puede enviar nuevos mensajes mientras el original est siendo procesado. El mensaje asncrono ocurre en el tiempo de manera independiente a otros mensajes.

Los mensajes sncronos son todo lo contrario, el emisor debe esperar a que termine el tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML emplea los siguientes convenios para representar Recopilado por: M.I Norma H. Jimnez Alor el tipo de mensaje.

Tipos de mensaje en diagramas de interaccin

Recopilado por: M.I Norma H. Jimnez Alor

Referencias electrnicas
http://www.sparxsystems.com.ar/resources/tutorial/

use_case_model.html http://msdn.microsoft.com/eses/library/dd409377.aspx http://www.codecompiling.net/files/slides/UML_cla se_06_UML_secuencia.pdf http://msdn.microsoft.com/eses/library/dd409377.aspx http://www.codecompiling.net/files/slides/UML_clas e_06_UML_secuencia.pdf


Recopilado por: M.I Norma H. Jimnez Alor