Clase 14, 17/10/2007

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


Hay tres tipos de clasesClases de entidad

Clases de frontera

Clases de control


Clases de entidadModela información de larga vida

EjemplosClase cuenta

Clase inversión


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


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


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


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


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


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


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

Clase 14, 17/10/2007

Documents

Transcript of Clase 14, 17/10/2007