Upload
joben
View
37
Download
1
Embed Size (px)
DESCRIPTION
Algunas Herramientas de Apoyo al Diseño de Software. Agustín J. González ELO329: Diseño y programación orientados a objetos. Resumen. - PowerPoint PPT Presentation
Citation preview
Algunas Herramientas de Apoyo al Diseño de Software
Agustín J. GonzálezELO329: Diseño y programación
orientados a objetos
Resumen
Para desarrollar software hay varias herramientas de apoyo que se han propuesto y son de gran utilidad independientemente de la metodología usada en el desarrollo.
Veremos: Descripción de casos de uso, Tarjetas CRC, viene de clase, responsabilidad
y colaboradores, Diagramas UML (Unified Modeling Language)
Casos de Uso
Recordemos las principales actividades del desarrollo: Definición de requerimientos, análisis, diseño, implementación, pruebas, distribución.
El estudio de casos de uso es una técnica de que sirve tanto para definir requerimientos como en el análisis.
Cada caso de uso se concentra en un escenario específico.
Caso de uso = Secuencia de acciones Acción = Interacción entre actor(es) y el sistema bajo
desarrollo. Cada acción conduce a un resultado Cada resultado tiene un valor para uno de los
actores Se usa variaciones para situaciones excepcionales.
Ejemplo de caso de uso: Sistema de mensajes de voz en teléfono.
Nombre: Dejar un mensaje Actor: llamador Descripción: El llamador deja un mensaje en una casilla de voz. Flujo principal: 1. El llamador marca el número principal del sistema de mensaje
de voz. 2. El sistema responde con un mensaje hablado pidiendo:
Ingrese el número de la casilla seguido por un signo #. 3. El usuario marca el número de la extensión. 4. El sistema le habla:
Usted se ha contactado con la casilla xxxx, Por favor deje su mensaje ahora.
5. El llamador deja el mensaje. 6. El llamador cuelga. 7. El sistema pone el mensaje en la casilla.
Ejemplo: Variantes
Es común especificar variantes de un caso de uso: Variante 1: 3A1. El usuario ingresa un número de extensión
inválido. 4A1. El sistema de mensaje de voz responde:
Usted ha marcado un número de casilla inválido. 5A1: Continúa con paso 2. Variante 2 5A2. El usuario cuelga en lugar de dejar un mensaje. 7A2. El sistema de mensaje de voz descarta el
mensaje vacío.
Tarjeta CRC: Class, Responsibilities, Collaborators.
CRC: Clase, Responsabilidades, Colaboradores.
Es una herramienta principalmente de diseño. Creamos una tarjeta por cada clase El nombre de la clase va en la parte superior. Responsabilidades a la izquierda y
1-3 responsabilidades Colaboradores a la derecha.
Colaboradores de la clase, no de cada responsabilidad.
Ejemplo tarjeta CRC:
(Casilla)
Típicamente los sustantivos de los casos de uso son una buena pista para encontrar candidatos a clases.
Los verbos de los casos de uso son candidatos a responsabilidades.
Recorrido de Caso de uso
El recorrido de los casos de uso permite identificar otras clases.
Caso de uso: Dejar un Mensaje Llamador se conecta al sistema de mensajería. Llamador marca extensión. “Alguien” debe ubicar la casilla (Mailbox). Ni la casilla ni el mensaje pueden hacer esto. Surge una nueva clase: SistemaMensajeria
(MailSystem). Responsabilidad: Administrar las casillas.
CRC inicial para: SistemaMensajeria
(SistemaMensajeria)
Usar los casos de uso para llenar las tarjetas CRC. Cambiar las tarjetas a gusto. Es común hacer cambios
al considerar nuevos casos de uso. Lo común: el primer diseño no es el perfecto.
Diagramas UML
UML= Unified Modeling Language Unifica las notaciones de los "3 Amigos"
Booch, Rumbaugh, Jacobson Hay varios tipos de diagramas. Nosotros veremos tres tipos:
Diagrama de Clases Diagrama de Secuencia Diagrama de Estados
Diagrama de Clases
Cada clase es representada por:
Casilla
newMessages
savedMessages
add()getCurrentMessage()
Atributos
Métodos
Nombre
Tipos de Relaciones entre clases
Dependencia puede existir entre cualquier elemento, normalmente más usada para ilustrar dependencia entre paquetes. La idea es indicar que un cambio de la clase de la cual se depende afecta a la clase. Por ejemplo para indicar que una clase llama a otra.
Tipos de relaciones Agregación: relación “tiene” o “contiene”
Composición: Caso especial de agregación. Contenido no existe fuera de la clase.
Asociación: Puede tener roles, algunos la usan a cambio de agregación. Relación de asociación más general.
Tipos de relaciones Asociación: para indicar dirección. Algunas son bidireccionales, otra no. Ejemplo: Los mensajes no saben en qué cola de mensajes están contenidos
Interfaces: Describe un conjunto de métodos. No hay estado ni implementación.
Algunas recomendaciones
Usar UML para informar, no para impresionar.
No dibujar un único diagrama sobrecargado.
Cada diagrama debe tener un propósito específico.
Omitir detalles no esenciales.
Diagrama de clases para sistema de mensajería
A esto se llega luego de analizar varios casos de uso y construir las tarjetas CRC para cada clase.
“Depende de”
“contiene”
Diagrama de Secuencia
Cada diagrama muestra la dinámica de un escenario.
Incorporación de un nuevo mensaje.
Ubicación de casilla
Creación de una casilla
Diagrama de secuencia para: “Dejar un Mensaje”
Diagrama de Estados
Son utilizados en las clases cuyos objetos tiene estados de interés.
Como diagrama de estados en “Sistemas Digitales”.
Diagrama de Estado para la conexión del dueño de la casilla
Estado Inicial