Ingeniería de Sotfware

Ingeniería de Sotfware

¿Qué es Ingeniería de Software?
La El término Ingeniería de Software surge a final de los años 60 "Ingeniería del Software es un conjunto de métodos,herramientas y procedimientos para producir software de gran calidad" [R. Pressman] La Ingeniería de Software es la disciplina tecnológica relacionada con la producción sistemática y el mantenimiento de productos software que son desarrollados y modificados en el tiempo previsto y dentro de los costos estimados Por producto software se entiende: - Documentación de requerimientos - Documentación de diseño - Código fuente - Planes de pruebas del sistema - Principios de operación - Instrucciones de instalación - Procedimientos de mantenimiento - Manuales de usuario

¿Cuál es su Objetivo? Su objetivo Producir Producto de Software
Productos Genéricos Productos Personalizados Genérico Personalizados El objetivo de la Ingeniería de Software es producir productos software - Productos software: sistemas de software junto a la documentación que describe como instalar y usar el sistema Los productos software caen en dos categorías: -Productos genéricos: Desarrollados por una organización para un mercado abierto (Microsoft Office) -Productos a medida: Encargados por un cliente (Sistema Facturación Energas) OFFICE Sistema de Compras

¿Por qué Es Importante? "Aunque los computadores han tenido mucho éxito, la experiencia diaria de uso de computadores es asociada muchas veces con dificultad, pena y otras barreras para la mayoría de la gente... La falta de usabilidad del software y un diseño pobre de los programas son una vergüenza secreta de la industria." Mitchell Kapor, Software Design Manifesto, 1990

¿Qué conceptos debemos conocer?
Método Planificación y estimación de proyectos Análisis de requisitos Diseño Codificación Prueba Mantenimiento Herramientas Procedimientos Metódos Ingeniería de Software Los métodos describen cómo construir técnicamente el software Comprende las actividades de: -Planificación y estimación de proyectos -Análisis de requisitos -Diseño -Codificación -Prueba -Mantenimiento Las herramientas dan soporte automático o semiautomático a los métodos Los procedimientos relacionan formalmente los métodos y las herramientas Herramientas Procedimiento

Calidad del Software Internos Corrección Robustez Modificabilidad Reusabilidad Compatibilidad Eficiencia Portabilidad Verificabilidad Integridad Facilidad de uso La calidad de software puede ser descrita mediante una serie de factores: -Externos: observables por los usuarios del producto -Internos: observables por profesionales de la computación Factores de calidad externos: -Corrección: Capacidad de los productos software de ejecutar exactamente sus tareas tal cómo están definidas en su especificación de requerimientos -Robustez: Capacidad de un sistema software para funcionar en situaciones anormales -Modificabilidad: Facilidad de un producto para adaptarse al cambio de especificaciones -Reusabilidad: Facilidad para ser reutilizado en todo o en parte para nuevas aplicaciones -Compatibilidad: Facilidad de los productos software para combinarse unos con otros -Eficiencia: Buen uso de los recursos Software y Hardware disponibles -Portabilidad: Facilidad para adaptarse a otros entornos softwareo hardware -Verificabilidad: Facilidad para preparar procedimientos de aceptación, en particular datos de prueba, para detectar fallos durante las fases de validación y operación -Integridad: Capacidad de un sistema para proteger sus documentos (programas, datos) contra accesos y modificaciones no autorizados -Facilidad de uso: Capacidad de aprender a manejar un sistemasoftware, operar con el, preparar datos de entrada, interpretar resultados, etc.

Calidad del Software Internos Modularidad Legibilidad Factores de calidad internos: Modularidad: Independencia funcional de los componentes del programa Legibilidad: Facilidad de lectura e interpretación del código del programa

Ciclo de Vida del Software
Ciclo de vida: "Sucesión de etapas por las que atraviesa un producto software a lo largo de su desarrollo y existencia." Tipos Clásico Clásico con prototipado En espiral Prototipado puro Combinación de estilos, etc. Ciclo de vida: Sucesión de etapas por las que atraviesa un producto software a lo largo de su desarrollo y existencia Existen distintas formas o paradigmas de ciclo de vida: -Clásico -Clásico con prototipado -En espiral -Prototipado puro -Combinación de estilos, etc.

Ciclo de vida clásico (W. Roycea en los años 70) Análisis Diseño Ciclo de vida clásico ideal fue propuesto por W. Roycea principios de los años 70 -Aplicación secuencial de una serie de pasos -Cada paso genera entradas y documentación para el siguiente 1) Análisis 2) Diseño 3)Codificación 4)Puesta en Marcha Críticas al ciclo de vida clásico: -Proyectos raramente siguen el flujo secuencial -Dificultad para establecer los requerimientos al principio del proceso -Errores detectados tardíamente -Mantenimiento por "parcheado" -Corregir según se presenten los problemas Codificación Puesta en Marcha

Prototipado Tipo vertical, horizontal, evolutivo, desechable Construcción Prototipo Diseño Rápido Requerimiento Validación Análisis Diseño Prototipear consiste en construir una versión inicial de un producto sin implementar completamente la funcionalidad del sistema Clases de prototipos: -Vertical: desarrolla completamente algunas de las facetas del producto -Horizontal: desarrolla parcialmente todas las facetas del producto -Evolutivo: la versión final es el producto ya construido -Desechable: se usa sólo para la captación de requerimientos y funcionalidad Observaciones sobre el prototipado: - Facilita la captación de los requerimientos del cliente - Reduce el riesgo de "parcheado" del producto final - La construcción del prototipo supone una inversión adicional - El cliente ve funcionando una versión de lo que será su programa sin asumir que dicha versión no es robusta ni completa

Proceso evolutivo (espiral) El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación. VENTAJAS: - El modelado en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, no terminal cuando se entrega el software. - Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. - Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. - Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos. PROBLEMAS: - Demostrar al cliente "exigente" (bajo contrato) que el enfoque evolutivo es controlable. - Requiere gran habilidad y experiencia para valorar el riesgo y saber cuando detener la evolución

Introducción al Análisis OO
¿Qué es un objeto? Mundo Real Muebles El mundo está lleno de objetos en la naturaleza en entidades hechas por el hombre y en los productos que usamos Pueden ser clasificados, descritos, organizados, combinados, creados y manipulados Es por ello que se utiliza una visión Orientada a Objeto para la creación de SW

¿Qué es un objeto? Muebles Clase (Mayor) Instancia

Las Clases tienen Atributos Métodos Muebles Atributos costo dimensiones color peso ubicación Métodos comprar vender mover pintar describir Un conjunto de atributos genéricos pueden asociarse con cada objeto, en la clase mueble Por ejemplo: Todo mueble tiene un costo, dimensiones, peso, localización y color, entre otros muchos posibles atributos Estos atributos también son aplicables a una mesa o silla, un sofá o un armario , Como silla es miembro de la clase mueble, silla hereda todos los atributos definidos para la clase CLASE

Las Clases tienen Atributos Métodos Mueble costo dimensiones color peso ubicación comprar vender mover pintar describir Muebles Representación UML CLASE

Las Clases tienen Atributos :Un conjunto de atributos genéricos Métodos :Cada una de estas operaciones modificará uno o más atributos del objeto. Atributos :Un conjunto de atributos genéricos Métodos :Cada una de estas operaciones modificará uno o más atributos del objeto. Métodos Atributos comprar vender mover pintar describir costo dimensiones color peso ubicación CLASE Muebles

Disertaciones Temas Sistemas Distribuidos
Capability Maturity Model for Software (CMM) Data Warehousing Data Mining Business Intelligence Licencia GNU/GPL

Pauta Las disertaciones deben cumplir con el objetivo de Propagar el conocimiento especifico del tema que aborda Introducción al tema a desarrollar. Descripción del tema. Descripción general: ¿Qué aplicaciones tiene? ¿Cuales son sus objetivos? Interrelación:¿Ayuda a otras áreas del conocimiento? modelos matemáticos y métricas asociadas ¿Existen métricas Asociadas? Análisis crítico Relación con el Curso y percepción personal : ¿Qué opinión le merece el tema estudiado y su aporte a la ingeniería de Software? ¿Cuáles son las desventajas encontradas? Conclusiones ¿Cómo resumiría el Tema analizada? ¿Cuándo puede ser usado? ¿Buenas practicas Asociada?

Encapsulamiento de Clases Atributos :Un conjunto de atributos genéricos Métodos :Cada una de estas operaciones modificará uno o más atributos del objeto. Encapsulamiemto En general, los objetos encapsulan datos, operaciones, otros objetos, constantes y otra información relacionada Encapsulamiento Significa que toda la información se encuentra empaquetada en una entidad. Los datos pueden ser accesados exclusivamente por las operaciones definidas en el objeto quedando ocultos para las operaciones de otros objetos no pertenecientes a la misma clase (caja negra) - Un modelo OO de SW computacional debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz - Una clase es un concepto OO que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real (y objetos derivados de una clase) Definición Formal Clases y objetos Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmente aplicables a sistemas desarrollados usando métodos convencionales y orientados a objetos. Por esta razón, un modelo OO de software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una modularidad eficaz. Una clase es un concepto OO que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Puesto de otra manera, una clase es una descripción generalizada (por ejemplo, una plantilla, un patrón o un prototipo) que describe una colección de objetos similares. Por definición, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los atributos. Una superclase es una colección de clases y una subclase es una instancia de una clase. Estas definiciones implican la existencia de una jerarquía de clases en la cual los atributos y operaciones de la superclase son heredados por subclases que pueden añadir, cada una de ellas, atributos «privados» y métodos. Métodos Atributos Estimulo comprar vender mover pintar describir costo dimensiones color peso ubicación CLASE Muebles

CLASES (super clases, subclase) JERARQUIA ATRIBUTOS MENSAJES Mueble (SUPER CLASE) silla mesa escritorio Jerarquia Estas definiciones implican la existencia de una jerarquía de clases en la cual los atributos y operaciones de la superclase son heredados por subclases que pueden añadir, cada una de ellas, atributos «privados» y métodos. Atributos Ya hemos visto que los atributos están asociados a clases y objetos, y que describen la clase o el objeto de alguna manera. Mensajes Los mensajes son el medio a través del cual interactúan los objetos, un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operación. Instancia de silla Sub-clase de la Super-Clase Mueble subclases que pueden añadir atributos "privados" y métodos

Conceptos Propios de la Orientación a Objetos Encapsulamiento Herencia Polimorfismo A B clase Figura Dibujar Encapsulamiento significa definición quedando ocultos los detalles de implementación interna están ocultos al mundo exterior. La Herencia es una de las diferencias clave entre sistemas convencionales y sistemas OO. Una subclase Y hereda todos los atributos y operaciones asociadas con su superclase X. Esto significa que todas las estructuras de datos y algoritmos originalmente diseñados e implementados para X están inmediatamente disponibles para Y. La reutilización se realiza directamente. El polimorfismo es una característica que reduce en gran medida el esfuerzo necesario para extender un sistema OO. Para entender el polimorfismo, considere una aplicación convencional que debe dibujar cuatro tipos diferentes de gráficos. Idealmente, una vez que se han recogido los datos necesarios para un tipo particular de gráfico, el gráfico debe dibujarse él mismo. circulo cuadrado triangulo Dibujar Dibujar Dibujar

Análisis OO Proceso Unificado de Software UML (1997)
Lenguaje de propósito general Permite crear modelos Métodos de Análisis OO Algunos de ellos son el enfoque: Rumbaugh ,Jacobson, Meyer, Harel, Wirfs-Brock, etc… Proseso Unificado de Software Es un proceso de desarrollo de software con orientación a objeto. UML es describir cualquier tipo de sistema en términos de diagramas orientados a objetos, o sea, es crear un modelo. Un modelo es una descripción completa de un sistema desde una perspectiva concreta. "El hábito no hace el monje"

Análisis OO Diagramas Usados UML Diagramas de estructura
Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de despliegue Diagrama de paquetes Diagramas de comportamiento Diagrama de actividades Diagrama de casos de uso Diagrama de estados Diagramas de Interacción Diagrama de secuencia Diagrama de comunicación Diagramas de estructura enfatizan en los elementos que deben existir en el sistema modelado: Diagramas de comportamiento enfatizan en lo que debe suceder en el sistema modelado Diagramas de Interacción un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado

Análisis OO ¿Qué son análisis y diseño? Una definición general seria:
Análisis Centrado en la investigación del Problema Diseño Como el sistema va a cumplir con los requerimientos ¿Definición Análisis y diseño General? El análisis se centra en la investigación del problema, no en la manera de definir la solución. - Por ejemplo, si se necesita un nuevo sistema de biblioteca, ¿Cuáles procesos de la institución se relacionan con su uso? El diseño pone de relieve una solución lógica: cómo el sistema cumple con los requerimientos ¿De qué manera el sistema de la biblioteca capturará y registrar á los prestamos de libros? La esencia de estas actividades consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos.

Análisis OO ¿Qué son análisis y diseño? Una definición OO seria:
Análisis Identifica los Objetos del dominio del problema Diseño Se definen los objetos lógicos de software ¿Qué son análisis y diseño con Orientación a Objeto? Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos – o conceptos – dentro del dominio del problema Durante el diseño orientado a objetos, se procura definir objetos lógicos del software - Finalmente, durante la construcción o programación orientada a objetos, se implementan los componentes de diseño Mueble public Mueble{ …. } Analista Diseño Implementación

Análisis OO Identificar un Objeto o Clase Entidades externas Cosas
Sucesos Roles Lugares Estructurales ¿ Como Identificar un Objeto? entidades externas (por ejemplo: otros sistemas, dispositivos, personas) que producen o consumen información a usar por un sistemas computacional. Cosas (por ejemplo: informes, presentaciones, cartas, señales) que son parte del dominio de información del problema; ocurrencias o sucesos (por ejemplo: una transferencia de propiedad o la terminación de una serie de movimientos en un robot) que ocurren dentro del contexto de una operación del sistema Papeles o roles desempeñados por personas que interactúan con el sistema. por ejemplo: director, ingeniero, vendedor Unidades organizacionales que son relevantes en una aplicación. por ejemplo: división, grupo, equipo Lugares que establecen el contexto del problema y la función general del sistema. (por ejemplo: planta de producción o muelle de carga) Estructuras que definen una clase de objetos o, en casos extremos, clases relacionadas de objetos. (por ejemplo: sensores, vehículos de cuatro ruedas o computadoras) 26

Análisis OO ¿Cómo saber si el objeto es correcto? Información retenida
Servicio necesario Atributos múltiples Atributos Comunes Operaciones comunes Requisitos esenciales Definición Coad y Yourdon Información retenida: el objeto potencial será deutilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funcione. Servicios necesarios el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos. Atributos múltiples durante el análisis de requisitos,se debe centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser Útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis); Atributos comunes puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto. Operaciones comunes puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto; Requisitos esenciales entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos. 27

Análisis OO Diagramas Básicos Diagramas a Definir
diagramas de diseño de clases Definir diagramas colaboración el modelo conceptual casos de uso 28

Análisis OO Diagramas Básicos > Diagrama Caso de USO
diagramas de diseño de clases Juego de Dados Diagrama de casos: El diagrama de casos de uso muestra actores, casos de uso y relaciones entre ellos Jugador Pagar Juego 29

Análisis OO Diagramas Básicos > Caso de USO Caso de uso Alto Nivel
Caso de uso Extendido Caso se Uso Una técnica excelente que permite mejorar la comprensión de los requerimientos es la creación de Casos de Uso, es decir, descripciones narrativas de los procesos del dominio. Los Casos de Uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema, en teoría expresados en el documento donde se especifican. El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen tácitamente los requerimientos en las historias que narran. JugarDados (Comienzan con un verbo) Jugador

Análisis OO Caso de USO No son los Requisitos
Descripción narrativa de Procesos Describe secuencia de acciones de un actor ¿Cómo el uso del sistema provee un valor observable para un usuario, o como satisface sus necesidades? Ejemplo Retiro de dinero desde un cajero La comprar un articulo Juego de datos Caso se Uso Casos de uso de caja negra son los más comunes y recomendados, los cuales no describen el funcionamiento interno del sistema, sus componentes o diseño Se recomienda escribir los casos de uso, enfocándose en las metas del usuario y no en la interfaz JugarDados 31

Análisis OO Caso de USO Enunciado del ejemplo juego de datos
Juego de Dados el jugador puede realizar todas las jugadas que desee el jugador ganara si al hacer rodar los dos dados obtiene un puntaje igual a 7 de lo contrario con cualquier otro puntaje perderá 32

Caso de uso Alto Nivel 1 REF. Caso de Uso Juego de Dados Actores Jugador Este caso de uso comienza cuando el jugador recoge y hace rodar los dados. Si los puntos suman siete gana y pierde si suman cualquier otro número. Descripción Casos de uso Alto nivel Conviene comenzar con los casos de uso de alto nivel para lograr rápidamente entender los principales procesos globales. 33

Caso de uso Expandido REF. Numero de referencia Caso de Uso Nombre del caso de uso Actores Lista de actores quién inicial el caso de uso. Intención del caso de uso. Propósito resumen Repetición del caso de uso de alto nivel o alguna síntesis similar. Casos de uso Alto nivel Conviene comenzar con los casos de uso de alto nivel para lograr rápidamente entender los principales procesos globales. Casos de uso primarios, secundarios y opcionales Los casos primarios de uso representan procesos comunes más importantes. Los casos secundarios de uso representan procesos menores o raros. Los casos opcionales de uso representan procesos que pueden no abordarse. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstracción. Por el contrario, un caso de uso real describe concretamente el proceso en términos del diseño real, de la solución específica que se va a llevar a cabo. Se ajusta a un tipo de interfaz específica, y se baja a detalles como pantallas y objetos en las mismas. 1. Primario, secundario u opcional. 2. Esencial o real. Tipo Evento Sistema Ref. Cruzada: 34

Análisis OO Diagramas Básicos > Diagrama Conceptual
Jugador Dados 1 Lanza 2 Nombre valorMostrado 1 2 Juega Un modelo conceptual Este modelo muestra gráficamente los conceptos (clases de objetos) los atributos y las asociaciones más importantes del dominio del problema. Definición Modelo Conceptual Una parte de la investigación sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Estática de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software. El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algún concepto importante. Identificación de Conceptos Para identificar conceptos hay que basarse en el documento de Especificación de Requisitos y en el conocimiento general acerca del dominio del problema. En la Tabla 1 se muestran algunas categorías típicas, junto con ejemplos pertenecientes al dominio de los supermercados y al de la reserva de billetes de avión: Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, más concretamente, en la descripción de los casos de uso. No es un método infalible, pero puede servir de guía para empezar. Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo, resumida en los siguientes tres puntos: • Usar los nombres existentes en el territorio: Hay que usar el vocabulario del dominio para nombrar conceptos y atributos. • Excluir características irrelevantes: Al igual que el cartógrafo elimina características no relevantes según la finalidad del mapa (por ejemplo datos de población en un mapa de carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son pertinentes en base a los requisitos. • No añadir cosas que no están ahí: Si algo no pertenece al dominio del problema no se añade al modelo. Creación del Modelo Conceptual Para crear el Modelo Conceptual se siguen los siguientes pasos: 1. Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos de la Tabla 1 y la búsqueda de sustantivos relacionados con los requisitos en consideración en este ciclo. 2. Representarlos en un diagrama. 3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer. 4. Añadir los atributos necesarios para contener toda la información que se necesite conocer de cada concepto. Jugada 1 consta 35

Análisis OO Diagramas Básicos > Diagrama Colaboración
Jugar() 1:r1:=lanzar :jugador d1:Dado Diagrama de Colaboración Diagrama de interacción Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato Hay dos clases de Diagramas de Interacción: 1. Diagramas de Colaboración. 2. Diagramas de Secuencia. De entre ambos tipos, los Diagramas de Colaboración tienen una mayor expresividad y mayor economía espacial (una interacción compleja puede ser muy larga en un Diagrama de Secuencia), sin embargo en ellos la secuencia de interacción entre objetos es más difícil de seguir que en un Diagrama de Secuencia. Ambos tipos de diagramas expresan la misma información, por lo que se puede usar cualquiera de los dos para expresar la interacción entre los objetos del sistema. La creación de los Diagramas de Interacción de un sistema es una de las actividades más importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creación de estos diagramas, por tanto, debería ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero. Creación de Diagramas de Interacción Para crear los Diagramas de Colaboración o de Secuencia se pueden seguir los siguientes consejos: • Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de desarrollo actual. - Para cada evento del sistema, hacer un diagrama con él como mensaje inicial. • Usando los apartados de responsabilidades y de post-condiciones del contrato de operación, y la descripción del caso de uso como punto de partida, diseñar un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. • Si el diagrama se complica, dividirlo en dos diagramas más pequeños. Para ello se termina la secuencia de mensajes en un mensaje determinado, y en el segundo diagrama se comienza con el mensaje que terminó el primero. Debe indicarse en el primer diagrama que el resto de la interacción se detalla en el segundo. El comportamiento dinámico del sistema que se describe en un Diagrama de Interacción debe ser acorde con la estructura estática del sistema que se refleja en el Diagrama de Clases de Diseño. Es aconsejable realizar un Diagrama de Clases de Diseño borrador antes de comenzar con los Diagramas de Interacción. La capacidad de realizar una buena asignación de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo según aumenta la experiencia en el desarrollo orientado a objetos. Responsabilidad es como un contrato u obligación de una clase o tipo. Las responsabilidades están ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Básicamente, estas responsabilidades pueden ser de tipo Conocer o de tipo Hacer: • Conocer: - Conocer datos privados encapsulados. - Conocer los objetos relacionados. - Conocer las cosas que puede calcular o derivar. • Hacer: - Hacer algo él mismo. - Iniciar una acción en otros objetos. - Controlar y coordinar actividades en otros objetos. Por ejemplo, puedo decir que "un Recibo es responsable de calcular el total" (tipo hacer), o que "una Transacción es responsable de saber su fecha" (tipo conocer). Las responsabilidades de tipo "conocer" se pueden inferir normalmente del Modelo Conceptual. Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para satisfacer responsabilidades. 2:r2:=lanzar d2:Dado 36

Análisis OO Diagramas Básicos > Diagrama diseño de clases
Jugador Dados 1 Lanza 2 Nombre valorMostrado Lanzar() Juegar() 1 2 Diagrama de diseño de clases Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación. Incluye la siguiente información: • Clases, asociaciones y atributos. • Interfaces, con sus operaciones y constantes. • Métodos. • Navegabilidad. • Dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de entidades software más que conceptos del mundo real. Construcción de un Diagrama de Clases de Diseño Normalmente se tiene una idea de un Diagrama de Clases, con una asignación de responsabilidades inicial. En caso de que no se tenga dicho Diagrama de Clases Borrador, puede seguirse la siguiente estrategia: 1. Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción. 2. Representarlas en un diagrama de clases. 3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. 4. Añadir los métodos, según aparecen en los Diagramas de Interacción. 5. Añadir información de tipo a los atributos y métodos. 6. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. 7. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. 8. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. Algunos de estos pasos se van realizando según se vayan completando los Diagramas de Interacción correspondientes. No existe precedencia entre la realización del Diagrama de Clases de Diseño y los Diagramas de Interacción. Ambos tipos de diagramas se realizan en paralelo, y unas veces se trabaja primero más en el de clases y otras veces se trabaja primero más en los de interacción. No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el Diagrama de Clases de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño del sistema. No hay, por tanto, un transición directa entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensión de un dominio, y el segundo en una solución software. En el Diagrama de Clases de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán en el lenguaje de implementación escogido 1 consta Jugada Nombre Iniciar() 37

Análisis OO ejemplo: Sistema de Proyecto
Requerimientos Casos de usos Alto Nivel Casos de usos Expandidos Diagrama de Secuencia Contratos Diagrama conceptual Diagrama de Clases 38

Requerimientos Informe 1.- Informe de movimiento 2.- Informe etapa y actividades Almacenamiento 3.- Guardar información movimiento proyecto etapa actividades responsable 4.- Guardar información de los datos responsables 5.- Guardar información de proyectos 6.- Guardar información de las etapas 7.- Guardar información de actividades Procesamiento 8.- Calculo porcentual de cada etapa 9.- Calculo porcentual de cada etapa 39

Casos de usos alto Nivel Caso de Uso MantenedorProyecto ID 05 Actor Responsable Descripción Este caso se encarga de mantener la información de los proyectos que son ingresados por el responsable. 40

Análisis OO (Ej.) Sistema de Proyecto
Casos de usos Expandido Caso de Uso MantenedorProyecto ID 05 Actor Responsable Propósito Mantener actualizada la información del proyecto Resumen Este caso se encarga de mantener la información de los proyectos que son ingresados por el responsable. Tipo Primario y esencial Referencias Cruz. Curso Normal de los Eventos EVENTO SISTEMA Este caso comienza cuando el responsable solicita ver los proyectos 3. El responsable solicita “crear un nuevo Proyecto” 5. El responsable solicita “modificar proyecto" 2. El sistema despliega una lista con todos los proyectos. 4. El sistema informa al usuario del estado de creación 6.-El sistema informa del estado de la modificación Curso Alternativo Linea 5 : no ingreso el responsable el identificador del proyecto, se muestra un mensaje de error 41

Diagrama de Secuencia :Sistema 1.- Este caso comienza cuando el responsable solicita ver los proyectos 3. El responsable solicita “crear un nuevo Proyecto” 5. El responsable solicita “modificar proyecto" verListaProyecto() crearProyecto() Se crea un proyecto ver caso de uso ??? modificarProyecto() 42

Contratos Nombre VerListadoProyecto () Responsabilidad Obtener de la base de datos un listado de proyectos. Referencia Caso de uso “mantenedorDeproyecto” Pre-Condicion Que exista una instancia de responsable Post-Condicion Se creo una instancia de proyecto 43

Diseño OO (Ej.) Sistema de Proyecto
Diagrama de colaboración List listaProyecto= VerListadoProyecto ():List Controlador 1: List listaProyecto= RecuperarProyectos ():List :Proyecto 2: List listaProyecto= RecuperarProyectos ():List :fachada 44

Diagrama Conceptual 1 crea 1..n Proyecto Etapas 1 0..n crea crea 0..n Actividades crea 1 0..n genera Responsable 1 0..n Movimiento 45

Diseño OO (Ej.) Sistema de Proyecto
Diagrama Clases Proyecto Etapas Nombre ingresarProyecto() ModificarProyecto() EliminarProyecto() Nombre ingresarEtapa() ModificarEtapa() EliminarEtapa() 1 crea 1..n 1 0..n crea crea 0..n Actividades crea 1 0..n genera Responsable Movimiento 1 0..n 46

Ingeniería de Sotfware

Presentaciones similares

Presentación del tema: "Ingeniería de Sotfware"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Sotfware

Presentaciones similares

Presentación del tema: "Ingeniería de Sotfware"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback