• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clase 14, 17/10/2007
 

Clase 14, 17/10/2007

on

  • 5,681 views

 

Statistics

Views

Total Views
5,681
Views on SlideShare
5,649
Embed Views
32

Actions

Likes
0
Downloads
171
Comments
0

2 Embeds 32

http://ici313-2-2007.blogspot.com 16
http://www.slideshare.net 16

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Clase 14, 17/10/2007 Clase 14, 17/10/2007 Presentation Transcript

    • 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 OO
        • Hay más de 60 técnicas equivalentes
        • Hoy en día, el Proceso Unificado es la única alternativa viable
      • Durante este workflow
        • Se extraen las clases
      • Observación
        • El Proceso Unificado asume conocimiento de extracción de clases
    • Workflow de análisis
      • El workflow de análisis tiene dos objetivos
        • Obtener 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 clases
        • Clases de entidad
        • Clases de frontera
        • Clases de control
    • Workflow de análisis
      • Clases de entidad
        • Modela información de larga vida
      • Ejemplos
        • Clase cuenta
        • Clase inversión
    • Workflow de análisis
      • Clases de frontera
        • Modela la interacción entre el producto y el ambiente
        • Una clase frontera se asocia generalmente con entrada o salida
      • Ejemplos
        • Clase reportes de inversión
        • Clase reportes de hipotecas
    • Workflow de análisis
      • Clases de control
        • Modela cálculos complejos y algoritmos
      • Ejemplos
        • Clase 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 funcional
          • Presentar escenarios de todos los casos de uso (un escenario es una instancia de un caso de uso)
        • Modelamiento de clases
          • Determinar las clases de entidad y sus atributos
          • Determinar las interrelaciones e interacciones entre las clases de entidad
          • Presentar este información en la forma de un diagrama de clases
        • Modelamiento dinámico
          • Determinar las operaciones desarrolladas por o hacia cada clase de entidad
          • Presentar 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 posibles
        • Presionar 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 arriba
      • 3.- 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 9
      • 4.- La puerta del ascensor se abre
      • 5.- Se inicia el tiempo de espera. El usuario A ingresa al ascensor
      • 6.- Usuario A presiona el botón del ascensor para el piso 7
      • 7.- El botón del ascensor del piso 7 se ilumina
      • 8.- Las puertas del ascensor se cierran después de un timeout
      • 9.- Se apaga el botón de piso hacia arriba
      • 10.- El ascensor viaja al piso 7
      • 11.- El botón del ascensor del piso 7 se apaga
      • 12.- Las puertas del ascensor se abren permitiendo al Usuario A salir del ascensor
      • 13.- Se inicia el tiempo de espera. El usuario A sale del ascensor
      • 14.- Las puertas del ascensor se cierran después de un timeout
      • 15.- 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 arriba
      • 3.- 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 9
      • 4.- La puerta del ascensor se abre
      • 5.- Se inicia el tiempo de espera. El usuario A ingresa al ascensor
      • 6.- Usuario A presiona el botón del ascensor para el piso 1
      • 7.- El botón del ascensor del piso 1 se ilumina
      • 8.- Las puertas del ascensor se cierran después de un timeout
      • 9.- Se apaga el botón de piso hacia arriba
      • 10.- El ascensor viaja al piso 9
      • 11.- El botón del ascensor del piso 9 se apaga
      • 12.- Las puertas del ascensor se abren permitiendo al Usuario B salir del ascensor
      • 13.- Se inicia el tiempo de espera. El usuario B sale del ascensor
      • 14.- Las puertas del ascensor se cierran después de un timeout
      • 15.- El ascensor continúa al piso 1 con el usuario A
    • Modelamiento de clases de entidad: caso ascensor
      • Extraer clases y sus atributos
        • Representarlas usando un diagrama UML
      • Una alternativa: deducir las clases de los casos de uso y sus escenarios
        • Peligro: a menudo hay muchos escenarios y por eso
        • hay muchas clases candidatas
      • Otras alternativas
        • Tarjetas 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 problema
        • Describir 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 sustantivos
        • Identificar 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
      • Sustantivos
        • Botones, ascensor, piso, movimiento, edificio, iluminación, pedido, puerta
        • Piso, edificio y puerta están fuera de las fronteras del problema  excluir
        • Movimiento, iluminación, pedido son sustantivos abstractos  excluir (podrían convertirse en atributos)
      • Clases candidatas:
        • Clase Ascensor y C lase Botón
      • Subclases:
        • Clases Botón Ascensor y C lase Botón Piso
    • Primera iteración del diagrama de clases
      • Problema
        • Los botones no se comunican directamente con los ascensores
        • Se necesita una clase adicional: C lase Controlador de Ascensor
      Clase Botón Clase Botón de piso Clase Botón de Ascensor Clase Ascensor Puertas abiertas: boolean Encendido: boolean 1 m 2m -2 n comunica con comunica 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 piso Clase Botón de ascensor Clase Controlador de Ascensor Encendido: boolean 1 nm 2m -2 1 controla controla Clase Ascensor Puertas abiertas: boolean 1 n controla
    • Tarjetas CRC
      • Usadas desde 1989 para OOA
      • Para cada clase, llenar una tarjeta mostrando
        • Nombre de la C lase
        • Funcionalidad ( R esponsabilidad)
        • Lista de clases que invoca ( C olaboración)
      • Hoy en día, las tarjetas CRC están automatizadas (componentes de herramientas CASE)
    • Tarjetas CRC
      • Fortaleza
        • Cuando se usan por miembros de un equipo, las tarjetas CRC son poderosas para mostrar ítemes faltantes o incorrectos
      • Debilidad
        • Si 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 test
      CLASE 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 responsabilidad
        • 1.- encender botón ascensor
      • Esto es totalmente inapropiado para el paradigma OO
        • Diseño orientado a la responsabilidad ha sido ignorado
        • Ocultamiento de la información ha sido ignorado
      • Responsabilidad
        • 1.- Encender botón ascensor
      • debería ser
        • 1.- 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 piso Clase Botón ascensor Clase Ascensor Pedidos: tipoPedido Encendido: boolean 1 nm 2m -2 1 controla controla Clase Ascensor 1 n controla Clase Puertas Ascensor Puerta abierta: boolean controla 1 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 presionado
      • 3.- El controlador de ascensor envía un mensaje al botón de piso hacia arriba para que se ilumine
      • 4.- 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 9
      • 5.- El controlador de ascensor envía un mensaje a las puertas del ascensor para que se abran
      • 6.- El controlador de ascensor inicia el tiempo de espera. El usuario A ingresa al ascensor
      • 7.- Usuario A presiona el botón del ascensor para el piso 7
      • 8.- El botón de ascensor informa al controlador de ascensor que el botón del ascensor ha sido presionado
      • 9.- El controlador de ascensor envía un mensaje al botón del ascensor para que se ilumine el botón del piso 7
      • 10.-El controlador de ascensor envía un mensaje a las puertas del ascensor para que se cierrean después de un timeout
      • 11- El controlador de ascensor envía un mensaje al botón de piso hacia arriba para que se apague
      • 12.- El controlador de ascensor envía una serie de mensajes al ascensor para que se mueva al piso 7
      • 13.- El controlador de ascensor envía un mensaje al botón del ascensor del piso 7 para que se apague
      • 14.- El controlador del ascensor envía un mensaje a las puertas del ascensor para que se abran permitiendo al usuario A salir del ascensor
      • 15.- 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 mejor
        • El OOA está OK por ahora
      • Necesitamos devolvernos al workflow OOA durante el workflow de OOD
    • Extrayendo las clases de frontera y control
      • Cada
        • Pantalla de ingreso
        • Pantalla de salida, y
        • Reporte
      • se modela por sus propias clases de frontera
      • Cada cálculo no trivial se modela por una clase de control