Ingeniería de software

1. Unidad II Ingeniería de Software Orientado a Objetos Ingeniería de software Semana 8 Tema Análisis Orientado a Objetos

2. Objetivos Generales: • Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software. • Desarrollar una cultura de ingeniería de software.

3. Objetivos Específicos: • Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad. • Utilizar herramientas para el modelado y gestión de proyectos de software. • Utilizar metodologías agiles en el desarrollo de software.

4. Objetivos Instruccionales: • Comprender los conceptos relacionados al análisis orientado a objetos • Establecer la interrelación entre los objetos en el proceso orientado a objetos.

6. Tareas del AOO • Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero del software. • Deben identificarse las clases (es decir, definir atributos y métodos). • Especifique la jerarquía de la clase. • Represente las relaciones objeto a objeto . • Modelar el comportamiento del objeto. • Repetir iterativamente las tareas del 1 al 5 hasta que el modelo esté completo. Panorama del Análisis OO

7. Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditions Panorama del Análisis OO Shlaer-Mellor AOO Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Responsabilities Fusion Operation descriptions, message numbering

8. El método de Booch Abarca un “microproceso de desarrollo” y un “macroproceso de desarrollo”. • Microproceso • Identifica las clases y objetos a un nivel dado de abstracción • Identifica la semántica de estas clases y objetos • Identifica las relaciones entre clases y objetos • Especificar el interfaz y después de la implementación de estas clases y objetos. • Macroproceso • Establece los requisitos centrales para el software • Desarrollar un modelo del comportamiento deseado del sistema • Crear una arquitectura para la implementación • Transformar la implementación mediante refinamiento sucesivo • Gestionar el mantenimiento Panorama del Análisis OO

9. El método de Rumbaugh • Desarrolla la técnica de modelado de objetos (OMT) para el análisis, diseño del sistema y diseño a nivel de objetos. • Crea 3 modelos: • El modelo de objetos (objetos, clases, jerarquías y relaciones) • El modelo dinámico (comportamiento del sistema y los objetos) • El modelo funcional (representación a alto nivel del flujo de información, similar a DFD) Panorama del Análisis OO

10. El método de Jacobson Se diferencia de los otros porque da mas importancia al caso de uso. Caso de uso: Es una descripción o escenario que describe como el usuario interactúa con el producto o sistema Panorama del Análisis OO

11. Etapas genéricas del AOO • Obtener los requisitos del cliente para el sistema. • Identificar escenarios o casos de uso. • Seleccionar clases y objetos usando los requisitos básicos como guías. • Identificar atributos y operaciones para cada objeto del sistema. • Definir estructuras y jerarquías que organicen las clases. • Construir un modelo objeto-relación. • Construir un modelo objeto-comportamiento. • Revisar el modelo de análisis OO con relación a los casos de uso/escenarios. Panorama del Análisis OO

12. Enfoque unificado para el AOO Representa el sistema desde la perspectiva de los usuarios. El caso de uso se emplea para modelar esta vista. VISTA DEL USUARIO Los datos y funcionalidad se muestran desde dentro del sistema, es decir modela la estructura estática (clases, objetos y relaciones). VISTA ESTRUCTURAL Panorama del Análisis OO VISTA DEL COMPORTAMIENTO Representa los aspectos dinámicos o de comportamiento del sistema. VISTA DEL IMPLEMENTACION Los aspectos estructurales y de comportamiento se representan aquí tal como van a ser implementados. Aspectos estructurales y de comportamiento en el que el sistema a implementar se representa. VISTA DEL ENTORNO

13. Proceso de análisis del dominio Entrada y salida para el análisis del dominio Literatura técnica Análisis del dominio Modelo del análisis del dominio Fuentes de dominio del conocimiento Taxonomía de clases Aplicaciones existentes Estándar de reusabilidad Análisis del Dominio Recursos del cliente Consejo de experto Modelos funcionales Requisitos actuales / futuros Lenguajes del dominio

14. Fases del proceso de análisis del dominio Análisis del Dominio

15. Fases del proceso de análisis del dominio Definir el dominio a investigar • Aislar el área de negocio, tipo de sistema o categoría del producto de interés. • Se debe extraer los elementos: • “OO” : Incluyen especificaciones, diseños y código para clases de aplicaciones OO ya existentes. Clases de soporte, biblioteca de componentes comerciales ya desarrolladas. • no “OO” : Abarcan políticas, procedimientos, planes, estándares y guías; partes de aplicaciones no OO, métricas. Análisis del Dominio

16. Fases del proceso de análisis del dominio Clasificar los elementos extraídos del dominio • Los elementos extraídos se organizan en categorías y se establecen las características generales que definen la categoría. • Se propone un esquema de clasificación para las categorías y se definen convenciones para la nomenclatura de cada elemento. • Se establecen jerarquías de clasificación en caso de ser necesario. Análisis del Dominio

17. Fases del proceso de análisis del dominio Redactar una muestra representativa de aplicaciones del dominio • El analista debe asegurar que la aplicación en cuestión tiene elementos que caen dentro de las categorías ya definidas. • En las primeras etapas de uso de la tecnología de objetos, una organización del software tendrá muy pocas. • Debido a esto, el analista de dominio debe “identificar los objetos conceptuales (opuestos a los físicos) en cada aplicación no OO” Análisis del Dominio

18. Fases del proceso de análisis del dominio Analizar cada aplicación dentro de la muestra • Identificar objetos candidatos reutilizables. • Indicar las razones que hacen que el objeto haya sido identificado como reutilizable. • Definir adaptaciones al objeto que también pueden ser reutilizables. • Estimar el porcentaje de aplicaciones en el dominio que pueden reutilizar el código. • Identificar los objetos por nombre. Análisis del Dominio

19. Fases del proceso de análisis del dominio Desarrollar un modelo de análisis para los objetos Sirve como base para el diseño y construcción de los objetos del dominio. Análisis del Dominio

20. Componentes genéricos del modelo de análisis OO Vista estática de clases semánticas Clases identificadas del modelo de análisis Vista estática de los atributos Describen la clases y ayudan a pensar en el funcionamiento Componentes del modelo Vista estática de las relaciones Representa las relaciones de tal manera que permite identificar las operaciones Vista estática de los comportamientos Definen una secuencia de operaciones Vista dinámica de la comunicación Basadas en mensajes que causan transición entre estados Vista dinámica de control y manejo del tiempo Describe la naturaleza y duración de los sucesos que provocan transiciones

21. Modelado CRC Estructuras y jerarquías Casos de uso Subsistemas El proceso OO Sistemas Personas Procesos

22. Casos de uso • Definir los requisitos funcionales y operacionales de sistema, diseñando un escenario de uso acordado por el usuario final y el equipo de desarrollo. • Proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema. • Proporcionar una base para la validación de las pruebas. El proceso OO MAQUINA DISPENSADORA DE CAFE

23. Modelado de clases-responsabilidades-colaboraciones Clases Identifica y organiza las clases relevantes al sistema El proceso OO Responsabilidades Son los atributos y operaciones relevantes para la clase Son aquellas clases necesarias que proveen a una clase información para completar una responsabilidad Colaboraciones

24. Modelado de clases-responsabilidades-colaboraciones Clases de objetos Se examina el planteamiento del problema o realizando un “análisis sintáctico gramatical” en la narrativa del sistema que se va a construir. Los objetos se determinan subrayando cada nombre. El proceso OO • Características de selección: • Información retenida, • Servicios necesarios, • Atributos múltiples, • Atributos comunes, • Operaciones comunes, • Requisitos esenciales. • Se manifiestan como: • Entidades externas (otros sistemas, dispositivos, personas, etc), • Cosas (informes, presentaciones, etc), • Ocurrencias o sucesos (movimiento en un robot), • Papeles o roles (director, vendedor, ingeniero), • Estructuras (sensores, computadoras), • Unidades organizacionales (división, grupo, equipo). Para ser considerado un objeto valido a incluir en el modelo de requisitos, debe satisfacer todas o casi todas las características.

25. Modelado de clases-responsabilidades-colaboraciones Responsabilidades • De atributos • Los atributos describen un objeto que ha sido seleccionado para ser incluido en el modelo de análisis. • En esencia son los atributos los que definen al objeto, los que clarifican lo que representa el objeto en el contexto del espacio del problema. • De operaciones • Definen el comportamiento de un objeto y cambian de alguna manera, los atributos de dicho objeto. • Manipulan datos. • Realizan cálculos. • Monitorizan objetos a la ocurrencia de un suceso de control. El proceso OO • Pautas para asignar responsabilidades a las clases • La inteligencia del sistema debe distribuirse de manera igualitaria • Cada responsabilidad debe establecerse lo mas general posible • La información y el comportamiento asociado a ella debe encontrarse dentro de la misma clase • La información sobre un elemento debe estar localizada dentro de una clase, no distribuida a través de varias clases • Compartir responsabilidades entre clases relacionadas cuando sea apropiado

26. Modelado de clases-responsabilidades-colaboraciones Colaboraciones • Un objeto (servidor) colabora con otro, si para ejecutar una responsabilidad necesita enviar cualquier mensaje al otro (cliente). Relaciones genéricas: El proceso OO • es-parte-de (cuando las clases forman parte de una clase agregada) • tiene-conocimiento-sobre (cuando una clase obtiene información de otra) • depende-de (implica que dos clases poseen una dependencia no realizable, a través de tiene-conocimiento-sobre o es-parte-de.

27. Definición de estructuras y jerarquías vehículo • Debe crearse una estructura de generalización-especialización para las clases identificadas. • 2. En otros casos, un objeto puede estar compuesto realmente de un numero de partes las cuales pueden definirse a su vez como objetos. carga pasajero El proceso OO Panel de control teclado pantalla

28. Definición de subsistemas Se denomina subsistema (paquete) a un subconjunto de clases que colaboran entre si para llevar a cabo un conjunto de responsabilidades cohesionadas. El proceso OO Capturar datos Sistema Mostrar Resultados

29. Conexión entre clases: • Comprender la responsabilidad de cada clase. • Definir aquellas clases colaboradoras que ayudan en la realización de cada responsabilidad. • Cada relación debe ser nombrada • Se evalúa cada extremo para determinar la cardinalidad. Modelo Objeto – Relación • Opciones: • 0 a 1 • 1 a 1 • 0 a muchos • 1 a muchos 0 1 0 1 1 1 * *

30. Indica como responderá un sistema OO a sucesos externos o estímulos. Para crear un modelo se deben ejecutar los siguientes pasos: • Evaluar todos los casos de uso para comprender totalmente la secuencia de interacción dentro del sistema • Identificar sucesos que dirigen la secuencia de interacción y comprender como estos sucesos se relacionan con objetos específicos. • Crear una traza de de sucesos para cada caso de uso • Construir un diagrama de transición de estados para el sistema • Revisar el modelo objeto-comportamiento para verificar exactitud y consistencia Modelo Objeto – Comportamiento

31. IDENTIFICACION DE SUCESOS CON CASOS DE USO • En general, un suceso ocurre cada vez que un sistema OO y un actor intercambian información. • Un suceso no es la información que se intercambia, es el hecho de que la información ha sido intercambiada. • Un caso de uso se examina por puntos de intercambio de información. • Una vez que los sucesos han sido identificados, se asocian a los objetos incluidos. • Los actores y objetos pueden responsabilizarse de la generación de sucesos o reconociendo sucesos que han ocurrido en otra parte. Modelo Objeto – Comportamiento

32. REPRESENTACION DE TRANSICION DE ESTADOS • Caracterización de estados: • El estado de cada objeto cuando el sistema ejecuta su función • El estado del sistema observado desde el exterior cuando este ejecuta su función. Modelo Objeto – Comportamiento Comparar contraseña (Incorrecta) Volver a entrar Comparar contraseña (Incorrecta) Se introduce la contraseña En reposo Comparando Seleccionando Activación correcta Comparar contraseña (Correcta)

33. REPRESENTACION DE TRAZA DE SUCESOS Propietario Panel de control Sistema Sistema listo Introducir contraseña Iniciar sonido Sonido Preparado para Activación/desactivación Modelo Objeto – Comportamiento Seleccionar Permanecer/salir Activar/desactivar sensores Sensores activados/desactivados Petición de luz roja Luz roja encendida Preparado para nueva acción

34. Resumen • El modelo de AOO está compuesto de representaciones gráficas y textos que definen los atributos de la clase, relaciones, conductas, y comunicación entre las clases. • Empieza con la descripción de guiones (casos de uso) de cómo actores (las personas, las máquinas, los sistemas) en el espacio del problema actúan recíprocamente con el producto a ser construido . • El planificador traduce la información del caso de uso en las representaciones de clases y sus colaboraciones. • Un modelo de objeto-relación puede construirse de la red del colaborador. • El modelo de objeto-comportamiento usa un diagrama de transición para su representación.

35. Unidad II Ingeniería de Software Orientado a Objetos Ingeniería de software Semana 8 Tema Análisis Orientado a Objetos