ACI491: Ingeniería de Software

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

2 ACI491: Ingeniería de Software
Introducción Temática

3 Objetivos del curso Aplicar técnicas formales al proceso de desarrollo de software. Aplicar técnicas de gestión de proyectos de software, incluyendo herramientas de estimación y control de proyectos. Desarrollar proyectos de desarrollo de software basados en los conceptos de garantía de calidad de software. Desarrollar proyectos de software basados en los paradigmas de desarrollo.

4 Objetivos Introducir conceptos de Ingeniería de Sistemas a Ingenieros de Software. Discutir las dificultades de la Ingeniería de Sistemas. Describir el concepto de procuración de sistema y el proceso de Ingeniería del Sistema. Discutir el concepto de confiabilidad en un contexto de sistema.

5 Contenidos Sistemas y su ambiente. Procuración del sistema.
El proceso de Ingeniería de Sistema. Modelado de la Arquitectura del Sistema. Factores Humanos. Ingeniería de la confiabilidad en el sistema

6 Introducción Programar es divertido, pero desarrollar software de calidad es difícil. Entre las ideas espléndidas, los requisitos o la “visión”, y un producto software funcionando hay un gran espacio y tiempo. El Análisis y el Diseño definen cómo solucionar el problema: qué programar. Su resultado debe ser fácil de comunicar, revisar, implementar y evolucionar. Nuestro objetivo estará focalizado en la Ingeniería de Software, entendida como la manera en que se utiliza la tecnología para realizar análisis efectivos que permitan diseños e implementaciones eficientes de buenos sistemas.

7 Software ¿Qué es? Programas de computadoras que cuando se ejecutan
proporcionan la función y el rendimiento esperado de acuerdo a los requerimientos planteados por los usuarios o por los creadores.

8 Software ¿De que está compuesto?
Programas escritos en un lenguaje de programación. Estructuras de datos que permiten a los programas manipular adecuadamente la información. Documentos que describen la operación y uso de programas

9 Software Los requerimientos son las necesidades de los usuarios que representan: Materia prima para la creación de los sistemas

10 Características del Software
Se desarrolla , no se fabrica. No se rompe, se deteriora. La mayoría del software se desarrolla a la medida y con la ayuda de los usuarios. Ahora se puede reutilizar.

11 Evolución del Software
Primera Era: Años Programas con ensamblador Funciones matemáticas Época de transición : 60. Crisis del software Segunda Era : 70’s. Aparición de computadoras más potentes. Software de uso general, fuerte mantenimiento. No existe un conocimiento detallado de la estructura interna de los programas.

12 Evolución del Software
Tercera Era: 80’s Marcada por PCs. Disminución de precios. Programación estructurada. Reducción del mantenimiento. Cuarta ERA Lenguajes de cuarta generación. Prog. concurrente con más de un procesador. Lenguajes orientados a objetos. Mejores herramientas , pero mayor complejidad.

13 Hoy INTERNET REDES DE COMPUTADORES sistemas integrados
plataformas multicapas sistemas integrados SISTEMAS DISTRIBUIDOS TECNOLOGIA JAVA Comercio Electrónico PORTALES ENTORNOS MULTIMEDIA

14 Situación Actual Dedicamos nuestros esfuerzos de hoy a arreglar lo que se hizo mal ayer. Se hacen estimaciones no realistas, hay falta de planificación, la desorganización nos lleva a : Procesos software normalmente improvisados. Si se han especificado, no se siguen rigurosamente. Organización reactiva (resolver crisis inmediatas).

15 ¿Qué se entiende por Proyecto Exitoso?
Se dice que un proceso de desarrollo fue exitoso si: Terminó a tiempo. No quedó nada pendiente. Los requerimientos fueron bien definidos. Los requerimientos fueron bien resueltos. Se utilizó metodologías y estándares. Participación adecuada de todas las partes. Se obtuvo nueva experiencia y recursos para futuros proyectos. La puesta en marcha fue bien hecha. La migración de datos fue exitosa.

16 Proyectos Exitosos y no Exitosos
El sistema o producto construido es exitoso si: Es percibido como útil para la empresa y sus objetivos. Presta los servicios esperados. Es confiable, eficiente y flexible. Es fácil de utilizar y de aprender. No depende de personas claves. Controles y seguridad efectivo. Documentado y auditable. La empresa y su medio ambiente con sus particulares sistemas de referencia están razonablemente satisfechos por lo logrado ( no por lo que queda por lograr )

17 ¿Qué se entiende por Proyecto NO Exitoso?
El proceso de desarrollo NO fue exitoso si: No terminó a tiempo. En realidad, aún no está terminado. Faltó participación. Se solicitaron reiterados gastos por nuevos requerimientos. Hubo serios problemas en la puesta en marcha. Al final, todo era tan apurado que nadie documentó nada. Se trabajó sin metodología ni estándares. No presta los servicios que debiera. No es confiable. Depende de personas claves. No está documentado. No es flexible.

18 Causas Principales de la Falta de éxito
Definiciones vagas y no escritas de los objetivos, las condiciones, las restricciones y los supuestos aplicables junta o separadamente al proyecto y al producto. Carta Gantt insuficiente o inadecuada. Planes no escritos. Estimaciones de plazos y recursos irreales. Continuos cambios en especificaciones y requerimientos. Mal manejo de los cambios.

19 Causas Principales de la Falta de éxito (2)
Ausencia de controles formales y oportunos para asegurar el cumplimiento de los plazos y presupuestos y para mantener actualizados los planes. Incumplimiento de supuestos claves. Falta de participación y/o compromisos de algunos de los participantes del proyecto. Falla o elección inapropiada de recursos humanos y técnicos. Intereses personales. Malas relaciones de los participantes. Ausencia de una forma de comunicación común.

20 Conclusiones Los proyectos no siempre son exitosos
La causa principal es la falla en la dirección. Dirigir es una tarea clave, tanto como construir, pero diferente. Dirigir un proyecto es, esencialmente, atacar las causas de los problemas y estimular los factores que propenden al éxito. Así de simple. (¿tan simple?)

21 ¿Qué es un Sistema ? Un conjunto de componentes interrelacionados trabajando conjuntamente para un fin común. El sistema puede incluir software, dispositivos mecánicos y eléctricos, hardware, y ser operado por gente. Los componentes del sistema son dependientes de otros componentes. Las propiedades y el comportamiento de los componentes del sistema están interrelacionados de forma compleja.

22 Problemas con la Ingeniería de Sistemas
Los sistemas grandes están usualmente diseñados para resolver problemas complejos La Ingeniería de Sistemas requiere un gran esfuerzo de coordinación entre varias disciplinas. Existen combinaciones infinitas para el diseño de software entre componentes. Existe desconfianza mutua y poco entendimiento entre distintas disciplinas. Los sistemas deben diseñarse para que duren varios años en un ambiente con cambios continuos.

23 Ingeniería de Software y Sistemas
La proporción del software en los sistemas esta creciendo. La electrónica esta siendo controlada por software, con lo que se están remplazando los sistemas de propósito específico. Los problemas de la Ingeniería de Sistemas son similares a los de la Ingeniería de Software. El software ha sido visto siempre como un problema dentro de la Ingeniería de Sistemas. Muchos proyectos grandes se han visto retrasados por el software.

24 Los Sistemas y su Ambiente
Los sistemas no son independientes, sino que existen dentro de un ambiente. La función del sistema puede ser la de cambiar su ambiente. Los efectos del ambiente pueden alterar el funcionamiento del sistema. p.ej. la fuente de poder puede afectar al sistema El ambiente físico y organizacional puede ser importante.

25 Jerarquías del Sistema
Ciudad Calle Edificio Sistema de Calefacción Sistema de Potencia Sistema de Agua Sistema de Seguridad Sistema de Alumbrado Sistema de Desperdicios

26 Procuración del Sistema
Es la adquisición de un sistema en una organización, para satisfacer una necesidad. Es necesario especificar el sistema y desarrollar la arquitectura antes de cualquier adquisición. Es necesaria una especificación que permita al contratista desarrollar el sistema. La especificación puede permitir comprar sistemas comerciales existentes, que resulten mas baratos que desarrollar el sistema.

27 Contratistas y Subcontratistas
La adquisición de sistemas de hardware-software muy grandes se hace usualmente a través de un contratista principal. Los subcontratos se hacen para que sean llevados a cabo por otros proveedores de partes del sistema. El cliente contrata el sistema con el contratista principal y no con los subcontratistas.

28 Modelo Contratista/SubContratista
Cliente del Sistema Contratista Principal Sub-Contratista 1 Sub-Contratista 2 Sub-Contratista 3

29 Proceso de Procuración del Sistema
a Desarrollar Adapta Requerimientos Elige Sistema Detalla Requerimientos Elige Proveedores Estudio de Sistemas existentes Envía petición a desarrollador Selecciona Desarrollador Negocia Contrato Contrato de Desarrollo Sistema Comercial

30 El Proceso de Ingeniería de Sistema
Involucra a Ingenieros de diferentes áreas. Existe mucho espacio para malentendidos aquí. Distintas disciplinas utilizan diferente vocabulario y se requiere mucha negociación. Usualmente se sigue el modelo de cascada dada la necesidad de desarrollo en paralelo de distintas partes del sistema. Poco margen para iteración entre fases debido a que los cambios de hardware pueden ser muy costosos. El software tendrá que compensar los problemas de hardware.

31 Proceso de Ingeniería de Sistemas
Definición de Requerimientos Entrega del Sistema diseño del Sistema Evolución del Sistema Desarrollo de Sub-sistemas Instalación del Sistema Integración del Sistema

32 Desarrollo Interdisciplinario
Ingeniería de Software Ingeniería Electrónica Ingeniería Mecánica Ingeniería de Estructuras Ingeniería de Sistemas Diseño de Interfaces Ingeniería Civil Ingeniería Eléctrica Arquitectura

33 Definición de Requerimientos del Sistema
En esta etapa se definen tres tipos de requerimientos. Requerimientos funcionales finos: Las funciones del sistema son definidas en forma abstracta. Propiedades del sistema: Los requerimientos no-funcionales para el sistema en general son definidos. Características indeseables: Comportamiento inaceptable del sistema es especificado. Se deben definir también los objetivos organizacionales para el sistema.

34 Objetivos del Sistema Objetivos Funcionales.
Proveer un sistema de alarmas e intrusos para un edificio que proveerá alerta interna y externa contra incendios o entradas no-autorizadas. Objetivos Organizacionales. Asegurar el funcionamiento normal del trabajo que se lleva a cabo en el edificio, y que no sea interrumpido por eventos tales como incendios o entradas no-autorizadas.

35 Problemas con los Requerimientos del Sistema
A medida que el sistema está siendo especificado, ocurren cambios. Se deben anticipar los desarrollos de hardware o comunicaciones en el ciclo de vida del sistema. Difícil definir requerimientos no-funcionales del sistema, sin tener una idea clara de un componente específico.

36 Proceso de Diseño del Sistema
Definición de Interfaces de los Sub-Sistema Descomposición de Requerimientos Especificación Funcional de Sub-Sistemas Identificación de Sub-sistemas Asignación de Requerimientos a los Sub-Sistema

37 El Proceso de Diseño del Sistema
Partición de Requerimientos. Organización de requerimientos en grupos relacionados. Identificación de subsistemas. Identificar un conjunto de subsistemas que cumplen con los requerimientos del sistema. Asignación de requerimientos a subsistemas. Especificación de funcionalidad de cada subsistema. Definición de interfaces entre subsistemas. Actividad crítica cuando se desarrolla el sistema el forma paralela.

38 Problemas del Proceso de Diseño del Sistema
La partición de requerimientos de hardware, software y componentes humanos puede involucrar mucha negociación. Con frecuencia se asume que los problemas difíciles de diseño son fácilmente resueltos por software. Las plataformas de software pueden ser inapropiadas para los requerimientos de software, por lo que deben de compensar esto.

39 Desarrollo de Subsistemas
Típicamente se desarrollan en paralelo con distintos grupos de desarrolladores. Falta de comunicación entre grupos de trabajo. Si existen mecanismos burocráticos lentos para proponer cambios en el sistema, provocarán que la planificación se extienda.

40 Integración del Sistema
Es el proceso de conjuntar hardware, software y gente, para llevar a cabo un sistema. Debe de ser llevado a cabo de forma incremental, de forma que los subsistemas sean integrados uno a la vez. En esta etapa, usualmente se encuentran los problemas de interfaces. Puede haber problemas si no se coordina bien la entrega de componentes del sistema.

41 Instalación del Sistema
Puede haber suposiciones incorrectas en el ambiente del sistema. Puede haber resistencia humana a la introducción de un nuevo sistema. El sistema puede tener que co-existir con algún sistema alternativo por algún tiempo. Puede haber problemas físicos en la instalación (por ejemplo: cableado, etc.) Tiene que identificarse el entrenamiento del operador.

42 Operación del Sistema Traerá problemas no contemplados en los requerimientos. Los usuarios podrían usar el sistema de forma no contemplada por los Ingenieros del Sistema. Puede revelar problemas con la interacción con otros sistemas. Problemas físicos por incompatibilidad. Problemas de conversión de datos. Errores frecuentes del operador derivados de interfaces inconsistentes.

43 Evolución del Sistema Los sistemas grandes tienen una larga vida. Pero deben evolucionar para adaptarse a requerimientos cambiantes. La evolución es inherentemente costosa. Los cambios pueden ser vistos desde una perspectiva técnica y de negocio. Los subsistemas interactúan de forma que en el futuro pueden aparecer problemas no contemplados… No existe una racionalidad para justificar el proceso de diseño. La estructura del sistema se corrompe a medida que se le hacen cambios. La mayoría de los sistemas requieren mantenimiento.

44 Modelado de la Arquitectura del Sistema
El modelo de la arquitectura presenta una visión abstracta de los subsistemas que configuran el sistema. Incluye flujos de información entre subsistemas. Identifica distintos tipos de componentes funcionales del modelo.

45 Arquitectura de un Sistema de Control de Tráfico Aéreo Sistema de
Radar Sistema de Transponder Sistema de Comunicaciones Comunicaciones con el avión Sistema de Telefonía Procesador de Posicionamiento Procesador de Respaldo Procesador de Comunicaciones . Procesador de Respaldo Arquitectura de un Sistema de Control de Tráfico Aéreo Base de Datos de Plan de vuelo Sistema de Simulación del Avión Sistema de mapeo de clima Controlador de la Inf. del Sistema Consolas de Control Caja Negra del Sistema Sistema de reporte de Actividades del Sistema

46 Componentes Funcionales del Sistema
Componentes de censores. Obtiene información del ambiente del sistema, pe.j. radares del sistema de control de tráfico aéreo. Componentes de actuadores. Componentes que causan algún cambio en el ambiente del sistema. Ejemplo: las válvulas en el proceso de control del sistema que incrementan o decrementan el flujo de control de un ducto. Componentes de cómputo. Lleva a cabo cómputo de algunas entradas recibidas para producir salidas. Ejemplo: el procesador de punto flotante del sistema.

47 Componentes Funcionales del Sistema
Componentes de comunicaciones Permiten comunicar distintos componentes del sistema entre sí. p.ej. los enlaces entre un sistema de cómputo distribuido. Componentes de control Coordina la interacción de los componentes del sistema. pej. el planificador en un sistema en tiempo real. Componentes de interfaces. Facilita la interacción entre los componentes del sistema. pej. interfaz del operador. Todos los componentes son usualmente controlados por software.

48 Factores Humanos Todos los sistemas tienen usuarios y son utilizados en un contexto social y organizacional. Es necesaria una interfaz de usuario apropiada para un control de operación efectivo. Los factores humanos son con frecuencia un factor que determina el éxito o el fracaso de un sistema. Cambios en el proceso de trabajo causa problemas. Habilidades de los usuarios. Cambios introducidos en la organización.

49 Resumen Nunca habrá una respuesta fácil en la solución de problemas de desarrollo de sistemas complejos. Los Ingenieros de Software no tienen respuesta a todas las preguntas, pero entienden el funcionamiento del sistema. Se debe de reconocer el papel que juega cada disciplina y cooperar entre todas en el proceso de Ingeniería de Sistemas. La Ingeniería de Sistema involucra a múltiples disciplinas. El Proceso sigue a menudo el modelo de cascada.

50 ¿Qué es un buen sistema? Un buen sistema, de alta calidad, es aquel que cumple las necesidades de sus usuarios: Útil y aprovechable: Resuelve el problema planteado. Hace la vida de los usuarios mas fácil ó mejor. Confiable: Tiene pocos errores. Flexible: Se adapta a los cambios que van apareciendo en las necesidades de los usuarios, permitiendo su mantenimiento. Accesible: Tanto para compra como para mantenimiento. Disponible: Tiene que ejecutarse sobre el hardware y Sistema Operativo disponibles. Debe entregarse a tiempo.

51 ¿Se tienen buenos sistemas?
Los avances del software han revolucionado nuestra vida: la manera en que nos comunicamos, aprendemos ó como nos entretenemos, la banca, los cuidados de salud, etc. Sin embargo, también encontramos fallos, algunos drásticos, como por ejemplo: Explosión de Ariane 5 debido a una serie de fallos de software. Pacientes con sobre dosis de radiaciones producto de un software complejo, mal documentado y poco revisado. (Therac-25) etc... Documentación sobre fallos: Forum On Risks To The Public In Computers And Related Systems

52 Realidades y Promesas Realidades:
Como promedio, los grandes proyectos duran un 50% mas de lo planificado. Las tres cuartas partes de los fallos de un gran proyecto son operativos. La cuarta parte de los grandes proyectos se cancela. Promesas: Las nuevas tecnologías prometen reducir los tiempos de desarrollo y aumentar la tasa de éxito de los proyectos...

53 ¿Cómo son los buenos sistemas?
Hay un límite de cuanto puede entender un ser humano de una sola vez. Debe poderse emprender una tarea de desarrollo ó de mantenimiento sin entender todo el sistema. Es importante controlar la complejidad del sistema: Pensar en el sistema como un conjunto de módulos. Identificar dependencias entre módulos.

54 Modularidad Un módulo, en sentido amplio, puede ser cualquier elemento identificable del sistema que tiene sentido por si mismo: Archivos Subrutinas Funciones de biblioteca Clases, en un lenguaje orientado a objetos Programas ó subsistemas con relativa independencia Otras estructuras Identificado un buen módulo, se puede contemplar su reutilización como un componente.

55 Conceptos asociados Dependencia y acoplamiento Cohesión Interfaz
Encapsulamiento Abstracción

56 Dependencia y acoplamiento
El módulo A depende del módulo B si cualquier cambio en el módulo B implica que también haya que modificar al módulo A. Se dice que A es un cliente de B, ó que B actúa como servidor de A. Es común que un mismo módulo sea tanto cliente como servidor, o sea, que dependa de otros módulos y que existan módulos que dependan de él. Incluso es posible una dependencia circular, lo que debe evitarse, ya que impide la reutilización. La dependencia se conoce a veces como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen débil acoplamiento, porque los cambios en una parte del sistema tienen menor probabilidad de propagación a través del mismo.

57 Encapsulamiento Para aprovechar el débil acoplamiento de un sistema es muy importante poder identificar qué módulos están acoplados. También se deben comprobar los cambios en un módulo, lo que pudiera ser caro. Idealmente, debe conocerse con certeza cuáles módulos de un sistema podrían verse afectados por un cambio en un módulo dado. Una vez establecidos los límites entre módulos: ¿Qué suposiciones pueden hacer los clientes de un determinado módulo? ¿Qué servicios se supone que va a proporcionar? ¿Qué módulos son clientes de un módulo dado?

58 Interfaces La Interfaz de un módulo define algunas de sus características, de las que sus clientes pueden depender. El resto del sistema puede utilizar al módulo solamente de las maneras permitidas pos sus interfaces. Por tanto: la interfaz encapsula conocimiento sobre el módulo. Si un módulo cambia internamente sin modificar su interfaz, dicho cambio no conllevará que haya que realizar ningún otro cambio en ninguna otra parte del sistema.

59 Sintaxis y semántica En muchos lenguajes de programación el módulos cliente analiza la dependencia sintáctica: qué tipos de datos tiene declarada la interfaz del módulo servidor. Lo ideal es poder comprobar igualmente la dependencia semántica: si la interfaz documenta fielmente las suposiciones que pueden conjeturarse sobre el módulo, realizaría una especificación del módulo, que explica qué pueden asumir los clientes sobre su comportamiento, no solamente la sintaxis acerca de cómo interactuar con él.

60 Dependencias de contexto
Es útil saber todas las dependencias que existen, además de las dependencias que están documentadas en los módulos del sistema. Este conocimiento clarifica: Cuáles servicios proporciona cada módulo. Cuáles servicios necesitará un módulo para funcionar. Los servicios necesitados por un módulo se denominan dependencias de su contexto, y pueden expresarse en función de interfaces. Las dependencias de contexto de un módulo y la interfaz propia del módulo constituyen un contrato que describe las responsabilidades de dicho módulo: Si el contexto proporciona lo que el módulo necesita, entonces él garantiza proporcionar los servicios descritos en su interfaz.

61 Beneficios La modularidad con interfaces definidas facilita la comprensión del sistema, así como su posible modificación, ya que reduce lo que se necesita saber del mismo: En un desarrollo en equipo, los desarrolladores de código que utilizan un módulo sólo deben comprender su interfaz, no cómo funciona, de manera que sean mas productivos. Se introducen menos errores, ya que los desarrolladores tienden a conocer lo que realmente necesitan saber y pueden ignorar de forma segura otros aspectos del sistema. Los errores son mas fáciles de encontrar tanto en desarrollo como en mantenimiento, debido a que no se examinan módulos irrelevantes. Una vez que exista un módulo con documentación de lo que proporciona y de lo que requiere, es posible pensar en su reutilización.

62 Módulos e interfaces Un módulo puede tener varias interfaces, lo que facilita identificar de la manera mas sencilla posible cuales serían los cambios requeridos si ocurriesen cambios en otros módulos. El empleo de varias interfaces para documentar un módulo permite precisar cuales servicios necesita un determinado cliente. Esta idea es útil tanto para mantenimiento como para reutilización. Conclusión parcial: Un buen sistema está formado por módulos encapsulados.

63 Abstracción: fuerte cohesión
Los módulos correctos tienen la propiedad de que sus interfaces proporcionan una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de implementar. Se dice que este tipo de módulos tiene una fuerte cohesión. La interfaz se abstrae de las cosas que el desarrollador no tiene que conocer para utilizar el módulo. El módulo realiza un conjunto coherente de acciones, pero -dentro de lo posible- el desarrollador del cliente está protegido de la información irrelevante relativa a cómo el módulo cumple sus funciones.

64 Información oculta La información oculta no tiene interés para los programadores del cliente. Precisando: Abstracción: Cuando un cliente de un módulo no necesita saber mas de lo que muestra su interfaz. Encapsulamiento: Cuando un cliente de un módulo no es capaz de saber mas de lo que hay en la interfaz. La situación en que la interfaz proporciona medios de interacción con algunos datos sin revelar su formato interno es normal tanto en el desarrollo orientado a objetos como en el estilo de tipo de datos abstractos.

65 Tipos de datos abstractos
Un tipo de dato abstracto (TDA) o Tipo abstracto de datos (TAD) es un modelo matemático compuesto por una colección de operaciones definidas sobre un conjunto de datos para el modelo. La abstracción de datos consiste en ocultar las características de un objeto y obviarlas, de manera que solamente utilizamos el nombre del objeto en nuestro programa. A esto se le llama ‘Abstracción’ y es un concepto muy útil en la programación, ya que un usuario no necesita mencionar todas las características y funciones de un objeto cada vez que éste se utiliza, sino que son declaradas por separado en el programa y simplemente se utiliza el término abstracto para mencionarlo. Se llama Abstracción de Datos a todo el proceso de definir, implementar y mencionar tipo abstracto de datos.

66 Caracterización de los TDA
Un TDA representa una abstracción: Se destacan los detalles (normalmente pocos) de la especificación (el qué). Se ocultan los detalles (casi siempre numerosos) de la implementación (el cómo). Está caracterizado por un conjunto de operaciones (funciones) denominado usualmente como su interfaz pública que representan el comportamiento del TDA; y una implementación, la parte privada del TDA, que está oculta al programa cliente que lo usa. Todos los lenguajes de alto nivel tienen predefinidos TDA; que son los tipos denominados simples y las estructuras predefinidas, y estos tienen sus interfaces públicas que incluyen las operaciones como la +, -, *, etc.

67 Ejemplos de TDA Algunos ejemplos de utilización de TDAs en programación son: Conjuntos: Implementación de conjuntos con sus operaciones básicas (unión, intersección y diferencia), operaciones de inserción, borrado, búsqueda... Árboles: Implementación de árboles de elementos, utilizados para la representación interna de datos complejos. Pilas y Colas: Implementación de los algoritmos FIFO y LIFO. Vectores y Matrices: Implementación de algoritmos y métodos numéricos.

68 Reutilización Si un módulo de cualquier tamaño y complejidad es una buena abstracción: tiene fuerte cohesión y débil acoplamiento; puede ser factible reutilizarle en sistemas posteriores, ó sustituirle en el sistema existente. Se le considera un componente conectable, aunque también dependerá de la arquitectura en la que se desarrolla el componente y sobre cuál arquitectura será utilizado. Puede pensarse en el desarrollo basado en componentes (Component Based Development - CBD) centrado en la arquitectura:

69 Arquitectura y componentes
Un componente es una unidad de reutilización y sustitución. Entre sus características están: Fuerte cohesión. Débil acoplamiento con el resto del sistema. Interfaz bien definida. Abstracción encapsulada de un elemento bien comprendido. Contexto de desarrollo. Contexto de utilización. La arquitectura del sistema incluye decisiones de alto nivel acerca de la estructura general del sistema que se aplican a mas de un sistema y que se toman para beneficiarse con la reutilización de componentes. Puede incluir otras decisiones respecto a cómo construir el sistema.

70 Desarrollo basado en componentes
La manera ideal de construir un nuevo sistema es tomar algunos componentes ya existentes y conectarlos unos con otros. Los componentes tienen que ser elementos que completen las necesidades del sistema en su totalidad, y deben ser compatibles entre si. Esto depende de la presencia de la arquitectura adecuada. Las decisiones de arquitectura: Se tienen que tomar pronto en el proyecto. Se ven afectadas por la naturaleza de los componentes en la arquitectura. Pueden estar influenciadas por el entorno del proyecto.

71 Procesos ó metodologías de desarrollo
Proceso de desarrollo: Conjunto de reglas que definen cómo debería llevarse a cabo el desarrollo de un proyecto. Puede incluir documentos, modelos de diseño, etc.; así como el orden en que deben producirse. Método [logía] especifica qué herramientas - lenguaje de modelado - deben utilizarse para la descripción del trabajo de análisis y de diseño.

72 Modelos Un modelo es una representación abstracta de una especificación, un diseño ó un sistema desde un punto de vista particular. A menudo se representa mediante un diagrama. Su objetivo es expresar la esencia de algunos aspectos de lo que se está haciendo sin especificar detalles innecesarios. Su propósito es permitir que las personas involucradas en el desarrollo del sistema puedan reflexionar y debatir sobre los problemas y las soluciones sin desviarse de los objetivos. Un modelado tiene que poseer significado preciso y bien entendido. ¡Abstracto NO significa Confuso!

73 Lenguaje de modelado Manera de expresar los distintos modelos que se producen durante el proceso de desarrollo. Normalmente se centra en los diagramas, aunque puede utilizar texto. Tiene Sintaxis: Reglas que definen cuáles diagramas son legales. Semántica: Normas que determinan que significa un diagrama concreto.

74 ¿Por qué un lenguaje unificado de modelado?
Dada la necesidad de debatir problemas y soluciones implicados en la construcción del sistema. El lenguaje debe ser: Suficientemente expresivo, para que incorpore los aspectos de diseño que será necesario tratar reflejados de manera que tengan sentido. Durante el diseño, los cambios se realizarán en el modelo. Suficientemente fácil de utilizar, para que ayude a tener un conocimiento claro. Inequívoco, para que ayude a resolver malos entendidos. Soportado por herramientas adecuadas, de manera que el esfuerzo de los desarrolladores esté enfocado a los aspectos que requieren su habilidad y no en trabajos rutinarios como crear un diagrama con una herramienta de dibujo. Generalmente utilizado.

75 Ventajas de la generalidad
Cuando un lenguaje de modelado es generalmente utilizado: La incorporación de nuevas personas al proyecto se simplifica si ya conocen el lenguaje de modelado utilizado. Para hacer diseño basado en componentes hay que leer las descripciones de las mismas, y cuanto mas rápido y fácil se pueda hacer es mas barato tener en cuenta un componente. Cuanto mas general sea la utilización de un lenguaje de modelado, mayor es la probabilidad de que sea el mismo utilizado por el escritor de las componentes involucradas.

76 Proceso y calidad Tanto el proceso de desarrollo como el sistema de gestión de calidad tienen como objetivo asegurar que el proceso - y el producto resultante- tenga alta calidad. En general, el proceso de desarrollo especificará aspectos mas técnicos que el sistema de gestión de calidad.

77 El proceso de desarrollo
Proceso en cascada (waterfall): Tiene cinco partes identificables, conocidas como fases del ciclo de vida: Análisis Diseño Implementación Pruebas Mantenimiento Tomado de Stevens, p57

78 Modelo de ciclo de vida (Buchanan)
Tomado de Alonso, p53

79 Gestión de riesgos Tema amplio y extremadamente importante.
Consideremos dos aspectos: Cada vez que se toma una decisión se corre el riesgo de que sea incorrecta. Mala comprensión de los requisitos por parte de los desarrolladores. Se puede tratar de controlar el riesgo descubriendo errores lo antes posible. Cualquier cosa que aumente la confianza en que los requisitos establecidos están correctos, reduce el riesgo.

80 Proceso en espiral Incorpora las dos ideas anteriores. (Boehm)
Esencialmente está formado por cuatro etapas: Analizar riesgos y planificar. Analizar requisitos para esta iteración. Ingeniería, diseño, implementación y pruebas. Evaluación.

81 Un proceso en espiral sencillo
Tomado de Stevens, p58

82 Métodos de desarrollo Algunos métodos de desarrollo orientado a objetos populares son: OOD de Booch – Rational Software OMT de Rumbaugh OOSE y Objectory de Jacobson

83 Procesos a utilizar con UML
Tomar la gestión de riesgos como un concepto central. Permitir que las iteraciones sean un medio para controlar el riesgo. Centrado en la arquitectura y basado en componentes: podría tener como actividades prioritarias el seguimiento y la toma de decisiones de arquitectura correctas y el uso y desarrollo de buenos componentes.

84 Proceso unificado (UP)
Sitúa su espiral principal en su fase de construcción: Inicio: Visión aproximada, análisis del negocio, alcance, estimaciones imprecisas. Finaliza con el compromiso del patrocinador del proyecto de seguir adelante, conocidos el caso de negocios del proyecto, su viabilidad y alcance básicos. Elaboración: Visión refinada, implementación iterativa del núcleo central de la arquitectura. Resolución de los riesgos altos. Identificación de otros requisitos y alcance. Estimaciones mas realistas. Finaliza con La arquitectura básica del sistema en cuestión. Un plan convenido para la construcción Todos los riesgos significativos identificados. Los principales riesgos comprendidos lo suficiente Construcción: Implementación iterativa de los restantes requisitos de menor riesgo y elementos mas fáciles. Preparación para el despliegue. Finaliza con una versión beta del sistema. Transición: Pruebas beta. Proceso de presentación del sistema a sus usuarios. Despliegue.

85 Disciplinas del UP Tomado de Larman, p21

86 Disciplinas y fases del UP
Las disciplinas (flujos de trabajo) del UP son el conjunto de actividades y artefactos (productos del trabajo: códigos, gráficos Web, esquema de base de datos, documentos de texto, diagramas, modelos, etc.) relacionados en un área determinada. Modelado del negocio: Consiste en modelar los objetos del dominio. A gran escala, referencia el modelado de los procesos de negocio de toda la empresa. Requisitos: Análisis de los requerimientos para una aplicación: escritura de casos de uso e identificación de requisitos no funcionales. Diseño: Todos los aspectos, incluyendo arquitectura global, objetos, bases de datos, comunicación en red, etc. Tomado de Larman, p21

87 Sistema, diseño, modelo, diagrama
Cualquier proceso de desarrollo pretende producir un sistema. El diseño, y especialmente la arquitectura del sistema, incorporan las decisiones importantes sobre cómo construirlo, abstrayéndose de muchos detalles. Se construirán diferentes modelos del diseño utilizando diagramas en un lenguaje de modelado: Modelo de casos de uso: describe el sistema requerido desde el punto de vista del usuario. Modelo estático: describe los elementos del sistema y sus relaciones. Modelo dinámico: describe el comportamiento del sistema a lo largo del tiempo.

88 Vistas Lógica: ¿qué partes teóricamente están juntas? ¿cuáles son las clases? ¿cómo están relacionadas? Se modela para comprobar los requisitos funcionales. De proceso: ¿qué hilos de control existen? ¿qué cosas pueden darse concurrentemente? ¿Cuándo sincronizar? Ayuda a asegura que se cumplan los requisitos no funcionales tales como la disponibilidad y las prestaciones. De desarrollo: ¿qué partes puede desarrollar el mismo equipo de personas? ¿qué puede reutilizarse? Ayuda a gestionar el proyecto. Física: ¿qué partes se ejecutarán sobre el mismo computador? Ayuda a asegurar que se cumplan los requisitos no funcionales. Es una vista mas concreta que la vista de proceso.

89 ¿Cómo se construye un buen sistema?
Realizando una aproximación técnica primaria, para construir un buen sistema: Se utiliza un proceso definido, con fases claras, cada una de las cuales tiene un producto final: documentos, algún código funcionando ... Se relaciona con encontrar tan pronto como sea posible un claro conjunto de requisitos cuidadosamente definidos. Se consideran los formularios de verificación y validación tales como pruebas elementos esenciales para la construcción del producto en si. Se utiliza un almacenamiento de conocimientos, arquitecturas y componentes relevantes. Se hace un uso coherente de las herramientas.

90 Preguntas ¿Cuáles son las mejores y las peores experiencias que ha tenido recientemente producto de sistemas basados en software? ¿Cómo se identifica el acoplamiento? ¿Cómo se mide? ¿Qué puede documentarse en las interfaces a los módulos? ¿Cuántas comprobaciones son automáticas? ¿Cuál es el resultado de seleccionar mal los módulos? Ejemplifique interfaces que conozca. Comente las ventajas y mencione las desventajas de tener un lenguaje unificado de modelado. ¿Bajo que circunstancias vale la pena utilizar un proceso de desarrollo en cascada?

91 Preguntas (2) Para gestionar el riesgo de una mala decisión, se acostumbra a posponerla cuanto se pueda. ¿Es una buena idea? ¿Depende del tipo de decisión? ¿Por qué? Busque información sobre los siguientes procesos y métodos de desarrollo: El Proceso Unificado de Rational (RUP) Catalysis Proceso Orientado a Objeto, Entorno y Notación: OPEN Programación Extrema (XP) de Beck Bazaar (método empleado para desarrollar Linux) SCRUM Modelo de Desarrollo de Sistemas Dinámico (DSDM)

92 Referencias Stevens, P. “Utilización de UML en Ingeniería del Software con Objetos y Componentes”, Addison Wesley, 2002 (en inglés: “Using UML: software engineering with objects and components”) Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004 Alonso,A. et al “Ingeniería del Conocimiento: Aspectos Metodológicos”, Pearson, 2004 Wikipedia: Diseño de Software Desarrollo en cascada Metodología OMT Lenguaje Unificado de Modelado Proceso Unificado de Desarrollo Software Tipo de dato abstracto

93 Tópicos de interés en Internet
Catalysis (Rational) Unified Process; Proceso Unificado de Rational Fusion Extreme Programming; Programación Extrema The Cathedral and the Bazaar SCRUM DSDM OPEN Enlaces de Cetus sobre métodos de A/D OO Descripción resumida de los ciclos de vida en el desarrollo de software, incluyendo el modelo de Forsberg Vee; así como información adicional sobre el modelo V.