Metodologías de Análisis
Clase 14 – 17/10/2007
Christian Sifaqui
Análisis OO
Análisis OO es una técnica semiformal para el paradigma OOHay más de 60 técnicas equivalentes
Hoy en día, el Proceso Unificado es la única alternativa viable
Durante este workflowSe extraen las clases
ObservaciónEl Proceso Unificado asume conocimiento de
extracción de clases
Workflow de análisis
El workflow de análisis tiene dos objetivosObtener un conocimiento más profundo de los
requerimientos
Describirlos de una manera que resulte en un diseño e implementación mantenible
Workflow de análisis
Hay tres tipos de clasesClases de entidad
Clases de frontera
Clases de control
Workflow de análisis
Clases de entidadModela información de larga vida
EjemplosClase cuenta
Clase inversión
Workflow de análisis
Clases de fronteraModela la interacción entre el producto y el
ambiente
Una clase frontera se asocia generalmente con entrada o salida
EjemplosClase reportes de inversión
Clase reportes de hipotecas
Workflow de análisis
Clases de controlModela cálculos complejos y algoritmos
EjemplosClase estimar fondos para la semana
Notación UML para los tres tipos de clases
Estereotipos (extensiones de UML)
Clase entidad Clase frontera Clase control
Extracción de las clases de entidad
Desarrollar los siguientes tres pasos en forma incremental e iterativa
Modelamiento funcionalPresentar escenarios de todos los casos de uso (un escenario es una
instancia de un caso de uso)
Modelamiento de clasesDeterminar las clases de entidad y sus atributosDeterminar las interrelaciones e interacciones entre las clases de
entidadPresentar este información en la forma de un diagrama de clases
Modelamiento dinámicoDeterminar las operaciones desarrolladas por o hacia cada clase de
entidadPresentar esta información en la forma de un diagrama de estados
Ejemplo: ascensores
El mismo caso visto anteriormente
Ejemplo: ascensores
Un caso de uso describe la interacción entre:El producto, y
Los actores (usuarios externos)
Casos de uso
Para el problema del ascensor, sólo hay dos casos de uso posiblesPresionar un botón de ascensor, y
Presionar un botón de piso
Usuario
Ascensor
Presionar un botón
de ascensor
Presionar un botón
de piso
Escenarios
Un caso de uso provee una descripción genérica de la funcionalidad general
Un escenario es una instancia de un caso de uso
Se necesita estudiar bastantes escenarios para lograr una visión completa del producto a ser modelado
Escenario normal: caso ascensor
1.- Usuario A presiona el botón de piso hacia arriba en el piso 3 para solicitar un ascensor. El usuario A desea ir al piso 7
2.- Se ilumina el botón del piso hacia arriba3.- Un ascensor llega al piso 3. Éste contiene al usuario B, que ingresó al ascensor en el
piso 1 y presionó el botón del ascensor para el piso 94.- La puerta del ascensor se abre5.- Se inicia el tiempo de espera. El usuario A ingresa al ascensor6.- Usuario A presiona el botón del ascensor para el piso 77.- El botón del ascensor del piso 7 se ilumina8.- Las puertas del ascensor se cierran después de un timeout9.- Se apaga el botón de piso hacia arriba10.- El ascensor viaja al piso 711.- El botón del ascensor del piso 7 se apaga12.- Las puertas del ascensor se abren permitiendo al Usuario A salir del ascensor13.- Se inicia el tiempo de espera. El usuario A sale del ascensor14.- Las puertas del ascensor se cierran después de un timeout15.- El ascensor continúa al piso 9 con el usuario B
Escenario de excepción: caso ascensor
1.- Usuario A presiona el botón de piso hacia arriba en el piso 3 para solicitar un ascensor. El usuario A desea ir al piso 1
2.- Se ilumina el botón del piso hacia arriba3.- Un ascensor llega al piso 3. Éste contiene al usuario B, que ingresó al ascensor en el
piso 1 y presionó el botón del ascensor para el piso 94.- La puerta del ascensor se abre5.- Se inicia el tiempo de espera. El usuario A ingresa al ascensor6.- Usuario A presiona el botón del ascensor para el piso 17.- El botón del ascensor del piso 1 se ilumina8.- Las puertas del ascensor se cierran después de un timeout9.- Se apaga el botón de piso hacia arriba10.- El ascensor viaja al piso 911.- El botón del ascensor del piso 9 se apaga12.- Las puertas del ascensor se abren permitiendo al Usuario B salir del ascensor13.- Se inicia el tiempo de espera. El usuario B sale del ascensor14.- Las puertas del ascensor se cierran después de un timeout15.- El ascensor continúa al piso 1 con el usuario A
Modelamiento de clases de entidad: caso ascensor
Extraer clases y sus atributosRepresentarlas usando un diagrama UML
Una alternativa: deducir las clases de los casos de uso y sus escenariosPeligro: a menudo hay muchos escenarios y por eso
hay muchas clases candidatas
Otras alternativasTarjetas CRC (si se tiene conocimiento del dominio)
Extracción de sustantivos
Extracción de sustantivos
Un proceso de dos etapas
Etapa 1: Definición concisa del problemaDescribir el producto de software en un solo párrafo
Botones en ascensores y en pisos controlan el movimiento de n ascensores en un edificio con m pisos. Los botones se iluminan al ser presionados para solicitar que el ascensor se detenga en un piso específico; se apaga la iluminación cuando el pedido se satisface. Cuando un ascensor no tiene pedidos, permanece en su piso actual con las puertas cerradas
Extracción de sustantivos
Etapa 2: identificar los sustantivosIdentificar los sustantivos en la estrategia informal
Botones en ascensores y en pisos controlan el movimiento de n ascensores en un edificio con m pisos. Los botones se iluminas al ser presionados para solicitar que un ascensor se detenga en un piso específico; se apaga la iluminación cuando el pedido se satisface. Cuando un ascensor no tiene pedidos, permanece en su piso actual con las puertas cerradas
Utilizar los sustantivos como clases candidatas
Extracción de sustantivos
SustantivosBotones, ascensor, piso, movimiento, edificio,
iluminación, pedido, puertaPiso, edificio y puerta están fuera de las fronteras del
problema excluirMovimiento, iluminación, pedido son sustantivos
abstractos excluir (podrían convertirse en atributos)
Clases candidatas:Clase Ascensor y Clase Botón
Subclases:Clases Botón Ascensor y Clase Botón Piso
Primera iteración del diagrama de clases
ProblemaLos botones no se comunican directamente con los ascensoresSe necesita una clase adicional: Clase Controlador de Ascensor
Clase Botón
Clase Botón de pisoClase Botón de Ascensor
Clase Ascensor
Puertas abiertas: boolean
Encendido: boolean
1m 2m -2ncomunica concomunica con
Segunda iteración del diagrama de clases
Todas las relaciones son ahora 1-n
Esto hace el diseño e implementación más fácil
Clase Botón
Clase Botón de pisoClase Botón de ascensor
Clase Controlador de Ascensor
Encendido: boolean
1nm 2m -2
1
controla controla
Clase Ascensor
Puertas abiertas: boolean
1
n
controla
Tarjetas CRC
Usadas desde 1989 para OOAPara cada clase, llenar una tarjeta
mostrandoNombre de la ClaseFuncionalidad (Responsabilidad)Lista de clases que invoca (Colaboración)
Hoy en día, las tarjetas CRC están automatizadas (componentes de herramientas CASE)
Tarjetas CRC
FortalezaCuando se usan por miembros de un equipo,
las tarjetas CRC son poderosas para mostrar ítemes faltantes o incorrectos
DebilidadSi se usan las tarjetas CRC para identificar
clases de entidad, se necesita experiencia en el dominio
Modelamiento dinámico: caso ascensores
Producir un diagrama de estados UML
Estado, evento y predicado se distribuyen en el diagrama de estado
Modelamiento dinámico: caso ascensores
Este diagrama de estados UML es equivalente a los diagramas de transición de estados mostrados durante el análisis clásico
Se muestra considerando escenarios específicos
Un diagrama de estados se construye modelando los eventos de los escenarios
Workflow de test: OOA
Tarjetas CRC son una buena técnica de testCLASE
Clase Controlador de Ascensor
RESPONSABILIDAD
1.- Encender botón ascensor
2.- Apagar botón ascensor
3.- Encender botón piso
4.- Apagar botón piso
5.- Mover ascensor un piso hacia arriba
6.- Mover ascensor un piso hacia abajo
7.- Abrir puertas del ascensor e iniciar tiempo de espera
8.- Cerrar puertas del ascensor después de timeout
9.- Revisar pedidos
10.- Actualizar pedidos
COLABORACIÓN
1.- Clase botón ascensor
2.- Clase botón piso
3.- Clase ascensor
Tarjetas CRC
Considerar responsabilidad1.- encender botón ascensor
Esto es totalmente inapropiado para el paradigma OODiseño orientado a la responsabilidad ha sido ignoradoOcultamiento de la información ha sido ignorado
Responsabilidad1.- Encender botón ascensor
debería ser1.- Enviar mensaje a Clase Botón Ascensor para que se
encienda
Tarjetas CRC
Además una clase no se consideró
Las puertas del ascensor tienen un estado que cambia durante la ejecución (características de clase)Agregar Clase Puertas Ascensor
Consideraciones de seguridad
Modificar la tarjeta CRC
Segunda iteración de la tarjeta CRC
CLASE
Clase Controlador de Ascensor
RESPONSABILIDAD
1.- Enviar mensaje a Clase Botón Ascensor para encender botón ascensor
2.- Enviar mensaje a Clase Botón Ascensor para apagar botón ascensor
3.- Enviar mensaje a Clase Botón Piso para encender botón piso
4.- Enviar mensaje a Clase Botón Piso para apagar botón piso
5.- Enviar mensaje a Clase Ascensor para mover ascensor un piso hacia arriba
6.- Enviar mensaje a Clase Ascensor para mover ascensor un piso hacia abajo
7.- Enviar mensaje a Clase Puertas Ascensor para abrir puertas del ascensor
8.- Iniciar tiempo de espera
8.- Enviar mensaje a Clase Puertas Ascensor para cerrar puertas del ascensor después de timeout
9.- Revisar pedidos
10.- Actualizar pedidos
COLABORACIÓN
1.- Clase Botón Ascensor (subclase)
2.- Clase Botón Piso (subclase)
3.- Clase Puertas Ascensor
4.- Clase Ascensor
Tarjetas CRC
Habiendo modificado el diagrama de clases, reconsiderar:Diagrama de casos de uso (no hay cambios)
Diagrama de clases (sí hay cambios)
Diagrama de estado
Escenarios (sí hay cambios)
Tercera iteración del diagrama de clases
Clase Botón
Clase Botón de pisoClase Botón ascensor
Clase Ascensor
Pedidos: tipoPedido
Encendido: boolean
1nm 2m -2
1controla controla
Clase Ascensor
1
n
controla
Clase Puertas Ascensor
Puerta abierta: booleancontrola1 n
Segunda iteración del escenario normal
1.- Usuario A presiona el botón de piso hacia arriba en el piso 3 para solicitar un ascensor. El usuario A desea ir al piso 7.
2.- Se botón del piso informa al controlador de ascensor que el botón del piso ha sido presionado3.- El controlador de ascensor envía un mensaje al botón de piso hacia arriba para que se ilumine4.- El controlador de ascensor envía una serie de mensajes al ascensor para que se mueva al piso 3. Éste contiene al
usuario B, que ingresó al ascensor en el piso 1 y presionó el botón del ascensor para el piso 95.- El controlador de ascensor envía un mensaje a las puertas del ascensor para que se abran6.- El controlador de ascensor inicia el tiempo de espera. El usuario A ingresa al ascensor7.- Usuario A presiona el botón del ascensor para el piso 78.- El botón de ascensor informa al controlador de ascensor que el botón del ascensor ha sido presionado9.- El controlador de ascensor envía un mensaje al botón del ascensor para que se ilumine el botón del piso 710.-El controlador de ascensor envía un mensaje a las puertas del ascensor para que se cierrean después de un
timeout11- El controlador de ascensor envía un mensaje al botón de piso hacia arriba para que se apague12.- El controlador de ascensor envía una serie de mensajes al ascensor para que se mueva al piso 713.- El controlador de ascensor envía un mensaje al botón del ascensor del piso 7 para que se apague14.- El controlador del ascensor envía un mensaje a las puertas del ascensor para que se abran permitiendo al
usuario A salir del ascensor15.- El controlador de ascensor empieza el tiempo de espera. El usuario A sale del ascensor.16.- El controlador de ascensor envía un mensaje a las puertas del ascensor para que se cierren después de un
timeout.17.- El controlador de ascensor envía una serie de mensaje al ascensor para moverlos al piso 9 con el usuario B.
OOA: caso ascensor
El OOA está OK
Se debiera decir mejorEl OOA está OK por ahora
Necesitamos devolvernos al workflow OOA durante el workflow de OOD
Extrayendo las clases de frontera y control
CadaPantalla de ingresoPantalla de salida, yReporte
se modela por sus propias clases de frontera
Cada cálculo no trivial se modela por una clase de control
Recommended