You are on page 1of 4

CASOS DE USO Un Caso de Uso es una funcionalidad del sistema.

. Especifican el comportamiento de un sistema Proporcionan un medio para que los desarrolladores, los usuarios finales y los expertos del dominio lleguen a una compresin comn del sistema. Ayudan a validar la arquitectura y a verificar el sistema No se especifica cmo se implementan. Caso de Uso: Una descripcin de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. Actor: Conjunto de roles que los usuarios de los casos de uso juegan al interactuar con stos. Rol que es jugado por una persona, un dispositivo de hardware u otro sistema al interactuar con el sistema. Un escenario es una secuencia especfica de acciones que ilustra un comportamiento. Un caso de uso describe un conjunto de secuencias. Cada secuencia representa un posible flujo a travs de todas las variantes. Un escenario es una instancia de un caso de uso. Para cada caso de uso puede haber: Escenarios principales (describen secuencias esenciales). Escenarios secundarios (describen secuencias alternativas). Diagramas de Casos de Uso Diagrama de UML que se utiliza para el modelado de aspectos dinmicos de un sistema. Modela la Vista de Casos de Uso de un sistema. Permiten visualizar, especificar y documentar el comportamiento de un elemento. Contienen: Casos de Uso Actores Relaciones de dependencia, generalizacin y asociacin Conclusiones Los Casos de Uso no son parte del diseo (cmo), sino parte del anlisis (qu). Los Casos de Uso son qu hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cmo este interacta con el usuario. Los diagramas de casos de uso muestran las relaciones entre los casos de uso de un sistema y sus actores. En una relacin <<extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relacin <<include>> el actor que realiza el caso de uso base tambin realiza el caso de uso incluido. MODELO DE DOMINIOS: Modelo conceptual donde vamos a identificar distintos conceptos presentes en el dominio y como estan relacionados estos conceptos. Es bsicamente armar nuestras definiciones para poder armar nuestro modelo (representacin de la realidad). Un modelo de dominio es una representacin de las clases conceptuales del mundo real. NO COMPONENTE DE SOFTWARE. CONCEPTO: lo podemos definir por tres conceptos: - smbolo: como lo voy a identificar

intencin: que significa para m, es la definicin de la clase conceptual. que me representa dentro de mi modelo extensin: cuales son las instancias que existen de este concepto dentro de mi dominio

Descomposicin del dominio: tengo que tratar de identificar la entidad y no sus caractersticas Asociaciones entre conceptos: me representan los vnculos entre conceptos, leo ese dominio y tengo que entenderlo como funcionan entre s en mi modelo Conceptos candidatos: posibles conceptos que los voy a incluir en el dominio, puedo tratar de clasificarlos por categoras y luego empiezo analizarlos para identificar un conjunto de conceptos candidatos. Sugerencias: identificar frases nominales, y sustantivos. Concepto idneo: aquellos conceptos que son relevantes del conjunto de conceptos candidatos, me pregunto es relevante?, necesito mantener informacin de ese concepto?, ese concepto cumple alguna funcin especfica? ASOCIACIONES: busco relaciones posibles entre conceptos. Los extremos de las asociaciones se denominan papeles. Y pueden ser (nombre, cardinalidad, navegabilidad). ATRIBUTOS: que caractersticas son relevantes para ese concepto dentro del dominio, los atributos tienen que ser datos simples Actividades Dependientes: EL objetivo del modelo es identificar los conceptos relevantes del dominio para los casos de usos del ciclo actual. Por lo que es necesario contar con los casos de usos. Esta actividad puede hacerse en paralelo con el desarrollo de los casos de usos. Un Modelo de Dominio es una representacin de las clases conceptuales del mundo real, NO DE COMPONENTE DE SOFTWARE. Clase: 1. Grupo de elementos de un conjunto que tiene caractersticas comunes 2. Conjunto de propiedades inherentes a una cosa que permite caracterizarla y valorarla respecto a las restantes de su especie Por medio del modelo de Dominio se obtiene: Objetos del Dominio o clases conceptuales Asociaciones entre conceptos Atributos de los conceptos Conceptos Informalmente se puede decir que una clase conceptual es una idea, una cosa u objeto. En un lenguaje ms formal, se puede considera una clase conceptual a partir de su smbolo, intensin y extensin. Smbolo: Palabra o imagen que representa una Clase Conceptual. (Alumno) Intensin: Definicin de la clase conceptual. (Representa a un Alumnos...) Extensin: Conjunto de ejemplo que se aplica al concepto (Juan, Maria,..., etc). Descomposicin del Dominio Una estrategia para tratar la complejidad es la divisin de problema en unidades fciles de comprender. En el anlisis Orientado a objetos, la dimensin de la descomposicin es fundamentalmente por clases conceptuales. Asociaciones entre Conceptos: La Asociacin es una relacin entre dos conceptos que indica alguna conexin significativa e interesante entre ellos. Atributos de los conceptos: Un atributo es un valor lgico de un dato de un objeto. Recomendaciones: Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que especificarlo cabalmente.
2

No excluir los conceptos simplemente porque no indiquen una necesidad evidente que permita recordar la informacin acerca de ella. Conceptos - Estrategias para identificarlos Obtencin de los conceptos a partir de la lista de categoras: Consiste en preparar una lista de conceptos idneos a partir de una agrupacin de categoras de conceptos. Objetos fsicos o tangibles. Especificaciones, diseos o descripciones de cosas. Lugares. Transacciones. Lnea o rengln de elemento de transaccin. Papeles de las personas. Contenedores de otras cosas. Cosas dentro de un contenedor. Eventos. Obtencin de los conceptos a partir de la identificacin de Frases Nominales. Consiste en identificar las Frases Nominales en la descripcin textual del dominio. (La fuente para esta tcnica son los casos de usos extendidos). Asociaciones Se definen las asociaciones a partir de una lista de categoras: A es parte fsica de B A es una parte lgica de B A est fsicamente contenido en B A est contenido lgicamente en B A es una descripcin de B A se comunica con B Se debe tener en cuenta que el mayor esfuerzo debe estar en la identificacin de los conceptos y no en sus relaciones. Concepto Ejemplos A se comunica con B A es una propiedad de B A usa o dirige a B Cajero A esta contenido lgicamente en B A se conoce/ introduce/ registra/presenta/ captura en B A se relaciona con una transaccin B Cliente Cajero Cuenta Banco Banco Clave Tarjeta Cliente Operacin Cajero - Operacin

Asociaciones Papeles: Los extremos de las asociaciones se denominan papeles y pueden ser: Nombre Expresin de multiplicidad Navegabilidad Atributos Los atributos a incluir en el modelo conceptual, son aquellos en los que los requerimientos indican o conllevan necesidad de recordar informacin. Los atributos en el modelo conceptual deberan ser valores simples o valores puros de datos. (Entindase: No referencias ni conceptos del dominio, los cuales es mejor representarlos por medio de las asociaciones) Cantidad y unidades (nmero, moneda, cantidad) Cuando en una relacin entre conceptos tengo que mantener informacin sobre esta relacin lo tengo que plantear como un nuevo concepto en el cual se almacena esta informacin. PATRONES Qu es un patrn?: es una gua, me da una serie de recomendaciones que me permiten tener un buen diseo. Me plantea como puedo solucionar un tema a partir de la experiencia de otra persona. Analizo ciertas cuestiones para saber cul es la mejor forma de solucionar un problema. Es una especie de plano para el anlisis.
3

Patrones de diseo: guas para la etapa de diseo y lo usaremos para realizar los diagramas de secuencia. El DSS forma parte del anlisis, ahora para definir como se har cada uno de esos contratos planteados se trabajara con Diagramas de Secuencia de Diseo. Por ejemplo en el desarrollo de software una buena forma de implementar un buen diseo es separar el mismo en tres capas. Caso de uso de nivel esencial: desde el punto de vista de la esencia. Estaremos describiendo la esencia de ese caso de uso para comprenderlo. Aqu no digo que sino el cmo, por ejemplo no digo DNI de personal sino Identificador de personal. Caso de uso reales: la diferencia es que aqu si expresa con ms detalle. Es parecido al CU esencial pero con las caractersticas de cada informacin con respecto a la plataforma donde aplicaremos el diseo. Aqu sigue teniendo la misma esencia pero se incorpora informacin acerca de la implementacin. DSS: que se tiene que hacer DSD: como se debe hacer cada cosa

Una vez planteado los CU reales: desarrollo como voy hacer cada una de las operaciones que tuve en la DSS, tengo que hacer un diagrama de secuencia de diseo (DSD) por cada operacin del DSS es decir un DSD por cada contrato. La dependencia es una asociacin de un tiempo corto o cuando se est creando un objeto La existencia del movimiento depende de la existencia de una cuenta por lo que es una asociacin de composicin. Responsabilidades: Conocer: lo que conozco de un objeto son sus atributos y las relaciones que tiene con los dems objetos Hacer: que responsabilidades le voy a asignar a que objeto Mi punto de partida siempre es mi dominio, a partir de eso veo si lo que tengo es suficiente para realizar la operacin que quiero o ese conoce a alguien ms que puede ayudarme. Por ejemplo. Yo tengo al cajero y quiero extraer (eso significa modificar el saldo de una cuenta, Saldo es una atributo de cuenta). El cajero por si solo no puede pero conoce al banco, el banco conoce a la cuenta y recin ah desde la cuenta puedo hacer el decremento del saldo y vuelve todo. Tipo de patrn EXPERTO: dice que el nico que puede modificar o procesar los datos es aquel que posea la informacin, es decir, el dueo de esa informacin es el nico responsable de hacer lo que sea con ella. Tipo CREADOR: es el encargado de crear las instancias. Lo que tenemos que lograr es que cada instancia sea creada en un solo lugar (cada vez que creo una instancia, es algo nuevo que existe en el dominio). De todas las instancias dominio una sola clase es la encargada de crear esa instancia. Si tengo una relacin de composicin, el todo es el responsable de crear sus partes, ya que al eliminar el todo tambin se tienen que eliminar sus partes Tipo CONTROLADOR: su funcin no es resolver las cosas sino saber a quin delegar. Su funcin es cuando le piden algo l sabe a quin delegar para que se realice lo que se le est pidiendo

You might also like