SISTEMAS II

1. SISTEMAS II UNIDAD Nº 1 INTRODUCCION A UML T.U.I. LIC. CONTRERAS, PAMELA

2. Modelos de ciclos de vida Tradicional Desarrollo incremental Desarrollo con prototipado Espiral Alternativos Cascada Refinamiento sucesivo Cascada Refinamiento sucesivo

3. Modelo de ciclo de vida en cascada Requisitos Diseño Prueba Operación Codificación • Características: • Obliga a especificar lo que el sistema debe hacer antes de construir el sistema • Obliga a definir como van a interactuar los componentes. • Permite detectar y resolver desviaciones sobre la planificación inicial • Requiere que el proceso de desarrollo genere una serie de documentos que posteriormente pueden utilizarse para la validación y el mantenimiento del sistema • Ventajas: • Las etapas están organizadas de un modo lógico • Cada etapa incluye cierto proceso de revisión. • Esta organizado de modo que se pase el menor numero de errores de una etapa a la siguiente • El ciclo es interactivo. El flujo básico es de arriba hacia abajo, no obstante, reconoce que los problemas de etapas inferiores afectan a las decisiones de las etapas inferiores.-

4. Integración software y hardware Prueba de unidad Integración del software Requerimiento sistema global Requerimiento sistema software Diseño Preliminar Diseño detallado Código Prueba del sistema software Prueba de componente Visión alternativa del ciclo de vida en Cascada • Los requisitos del sistema global se dividen en requisitos del hw y requisitos del sw • Modelo alternativo que enfatiza en la validación de los productos.

5. Requisitos Pruebas de aceptación Valida requisitos Diseño de sistema Pruebas de integración Verifica diseño Diseño detallada Pruebas de componentes Implementación / pruebas unitarias Modelo en cascada en V Muestra la relación de las actividades de prueba con el análisis y diseño

6. Modelo incremental A. Requisitos del sistema A. Requisitos del software A. Requisitos del software A. Requisitos del software ……… Diseño Diseño Diseño Codificación Codificación Codificación • El desarrollo incremental es el proceso de construir una implementación parcial del sistema global y posteriormente ir aumentando la funcionalidad del sistema. • Ventaja: Facilita la incorporación de nuevos requisitos, por lo tanto el software es fácil de mejorar.- • Desventaja: El equipo de desarrollo sacrifica la etapa de análisis a favor de una obtención rápida de la 1º versión, generando un 1º producto alejado de las necesidades del usuario.- Mantenimiento

7. Modelo de ciclo de vida Prototipo Comienzo Parada Recolección y refinamiento de requisitos Producto de ingeniería Diseño rápido Refinamiento del prototipo Construcción del prototipo Evaluación del prototipo por el cliente Sigue el ciclo de vida tradicional , solo que su tiempo de desarrollo será bastante mas reducido. El usuario, mediante a utilización del prototipo, descubrirá los aspectos o requisitos no captados.

8. El Proceso Unificado Es un proceso configurable aunque un único proceso no es adecuado para todas las organizaciones de desarrollo de software, el UP es adaptable y puede configurarse para cubrir las necesidades de proyectos pequeños y grandes.

9. ¿Qué es UML? UML (UnifiedModelingLanguage) Es un lenguaje gráfico que permite modelar, construir y documentar Los elementos que constituyen un sistema software orientado a objetos. Ofrece un conjunto de modelos estándar utilizados para el diseño de proyectos. Modelo = Representación abstracta de la realidad. UML no describe la implementación de esos modelos.

10. La importancia de modelar Porque… • Proporciona los planos de un sistema. • Los modelos pueden involucrar planos detallados. • Incluyen aquellos elementos que tienen una gran influencia. • Omite aquellos elementos menores que no son relevantes. pueden ser descritos desde diferentes perspectivas.(diferentes modelos). • Es una abstracción cerrada del sistema.

11. La importancia de modelar Un modelo puede ser estructural, destacando la organización del sistema, o puede ser de comportamiento, resaltando su dinámica.

12. Recordando algunas definiciones • Un modelo es la representación de algo que existe en el mundo real. (Existencia física o potencial). • El modelo representa en función de un dominio de estudio. Subdominios del que representa al todo. • Se construye un modelo para aprender más del dominio. • También como forma más económica de estudiar algo del mundo real.

13. ¿Qué es entonces un Modelo? Un Modelo es una simplificación de la realidad. ¿Qué modelamos? Hay una razón fundamental… • Construimos modelos para comprender mejor el sistema que estamos desarrollando. ¿Por qué modelamos? • Cuando los modelos de sistemas son complejos y no podemos comprender el sistema en su totalidad.

14. A través del modelado… • …Se fijaron cuatro objetivos • Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema. • Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. • Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. • Los modelos documentan las decisiones que hemos adoptado.

15. Modelado O.O. • De la elección de ver el mundo de una forma O.O. se derivan varias implicaciones: • ¿Cuál es la estructura de una buena arquitectura O.O.? • ¿Qué artefactos debería crear un proyecto? • ¿Quién debería crearlos? • ¿Cómo deberían medirse?

16. Para Visualizar • La comunicación entre modelos conceptuales esta sujeta a errores a menos que se hable el mismo lenguaje. • Hay cuestiones sobre un SW que no se pueden entender a menos que se construyan modelos que trasciendan el lenguaje de programación. • Sino se documenta el código, esa información se perderá.

17. Para Especificar • Construyendo modelos precisos, no ambiguos y completos. • UML, cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de SW.

18. Para Construir • Produce una ingeniería “de ida y vuelta”, entendiendo por esto la posibilidad de trabajar en una vista gráfica o en una textual (código), mientras las herramientas mantienen la consistencia entre ambas.

19. Para Documentar • Requisitos. • Arquitectura. • Diseño. • Código fuente. • Planificación de proyectos. • Pruebas. • Prototipos. • Versiones.

20. ¿Dónde utilizar UML? • Fue utilizado de manera efectiva en diferentes dominios. • Sistemas de información empresariales. • Bancos y servicios financieros. • Transporte. • Ámbito científico. • Etc..

21. Finalidades de UML: Objetivos: • Representar sistemas complejos (más allá de un solo programa) por conceptos de objetos; • Establecer una relación explícita entre los conceptos y los artefactos ejecutables; • Tener en cuenta los factores de escala inherentes a los sistemas complejos y críticos; • Crear un lenguaje de modelado utilizable tanto por los humanos como por las máquinas.

22. Ventajas • Reutilización de código. • Simple de entender. • Alta cohesión y bajo acoplamiento. • Escalabilidad.

23. Limitaciones de UML • UML no es un modelo de proceso de desarrollo de software. • No define un ciclo de vida, ni objetivos, ni actividades. • UML no es una metodología. • No prescribe buenas prácticas, ni heurísticas, ni estrategias para alcanzar los diferentes objetivos. • UML fue concebido para describir modelos de software. • UML está fuertemente vinculado a la OO.

24. Perspectivas de UML • UML será el lenguaje de modelado orientado a objetos estándar predominante los próximos años. Razones: • Participación de metodólogos influyentes. • Participación de importantes empresas. Evidencias: • Crecimiento de herramientas que proveen la notación UML. • “Edición” de libros. • Congresos, cursos, Etc..

25. Modelos y Diagramas • Un modelocapturauna vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. • Diagrama: una representación gráfica de una colección de elementos de modelado.

26. Modelos y Diagramas • Un proceso de desarrollo de SW debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés. • El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren de otros modelos. • Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad (significa capturar las relaciones de implementación y dependencia en el modelo). Por ejemplo, un proceso de negocio requerirá algunas funcionalidades del sistema para implementar las funciones del proceso entre los diferentes modelos

27. Diagramas de UML • Diagrama de Casos de Uso. • Diagrama de Clases. • Diagrama de Objetos. Diagramas de Comportamiento • Diagrama de Estados. • Diagrama de Actividad. Diagramas de Interacción • Diagrama de Secuencia. • Diagrama de Colaboración. • Diagramas de implementación • Diagrama de Componentes. • Diagrama de Despliegue.

28. State Diagrams State Diagrams Diagramas de Clases Use Case Diagrams Use Case Diagrams State Diagrams Diagramas de Casos de Uso State Diagrams Use Case Diagrams Diagramas de Objetos Use Case Diagrams Diagramas de Secuencia Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Diagramas de Componentes Diagramas de Colaboración Modelo Component Diagrams Scenario Diagrams Component Diagrams Scenario Diagrams Diagramas de Distribución Diagramas de Estados Diagramas de Actividad Diagramas de UML Los diagramas expresan gráficamente partes de un modelo

29. Modelo de arquitectura Vista de Implementación Vocabulario Funcionalidad Ensamblado del Sistema, gestión de la configuración Vista de Diseño Vista de Caso de Uso Vista de Interacción Vista de Despliegue Comportamiento Rendimiento, Escalabilidad, Capacidad de procesamiento Topología del Sistema, distribución Entrega, instalación

30. Conceptos Básicos de Orientación a Objetos El modelamiento y el diseño orientado a objetos, es un modo de pensar abstractamente un problema usando conceptos del mundo real en vez de conceptos de computación. • Requiere de un gran esfuerzo intelectual • Surge por los cambios constantes de la realidad. Ej: fecha • Ese cambio genera la necesidad de reusabilidad del software • Revolucionó la forma de desarrollo del software • Necesita de un tiempo de aprendizaje

31. Definiciones Básicas: PROGRAMA: En orientación a Objetos (OO) es una red de objetos cooperantes que interactúan entre si, enviándose mensajes.

32. OBJETO: Es una abstracción de un conjunto de cosas del mundo real que tiene sentido en el problema aplicación Es una entidad que tiene un comportamiento (clave de la OO). Ese comportamiento está expresado por el conjunto de mensajes que el objeto es capaz de responder

33. ENCAPSUL AMIENTO Postula -simplificando- que no hay forma de acceder a las variables del objeto desde el exterior del mismo Conocimiento que tiene un objeto: Características propias del objeto p.e. en una cuenta bancaria característica propia puede ser el sald), características intrínsecas del objeto -que lo distinguen respecto a otro- Parte del objeto un objeto puede tener adentro a otros objetos más pequeños, p.e. en la cuenta bancaria el conjunto de los movimientos que se realizaron. La expresión "dentro del objeto" no quiere decir "físicamente", sino que tiene que ver con la estructura del mismo. conocer otros objetos cooperantes

34. CLASE Una clase es una definición simplificada de las características comunes de un conjunto de objetos semejante. (comparten el mismo comportamiento) . Los objetos con la misma estructura de datos (atributos) y comportamiento (operación) son agrupados en CLASES. Una especificación de clase en un modelo OO básicamente tiene: Interfaz: conjunto de mensajes Estructura: conjunto de atributos Métodos: uno por cada uno de los mensajes definidos en la interfaz.

35. ABSTRACCIÓN La abstracción es la especificación de ciertos aspectos esenciales de un sistema para un propósito particular, aisla los aspectos que son importantes dejando de lado aquellos que no lo son. La abstracción pone énfasis en la vista externa del objeto y la encapsulamiento (acuitamiento de información) previene a los clientes de ver la vista interna del objeto, donde el comportamiento de la abstracción se implementa.

36. HERENCIA La HERENCIA es el compartimiento de atributos y operaciones entre clases, basados en una relación jerárquica.

37. OPERACIONES Y MÉTODOS Una OPERACIÓN es una función que puede ser aplicada a objetos o por objetos de una clase. Un MÉTODO es la implementación de una operación para una clase POLIMORFISMO La misma operación se puede comportar en forma diferente en clases distintas. Esta característica fundamental de la OO se denomina POLIMORFISMO.

38. UML • Es un lenguaje para: • Especificar • Construir • Visualizar • Documentar • Un sistema de software orientado a objetos El objetivocentral del lenguaje es: abstraer cualquier tipo de sistema, sea informático o no, mediante diagramas. Un diagramaes una representación gráfica de una colección de elementos del modelo, que habitualmente toma la forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con otros elementos del modelo.

39. DIAGRAMAS Los diagramas de objetos: que representan los objetos y sus relaciones y corresponden a los diagramas de colaboración simplificados, sin representación de los envíos de mensajes; y diagramas de clases: que representan la estructura estática en términos de clases y relaciones. Diagramas de Casos de Uso: representan las funciones del sistema desde el punto de vista del usuario. Diagramas de Secuencia: son una representación temporal de los objetos y sus interacciones. Diagrama de Colaboración: son una representación espacial de los objetos, enlaces e interacciones. Diagrama de estados: representan el comportamiento de una clase en términos de estados Diagramas de Actividades: representan el comportamiento de una operación en términos de acciones. Diagramas de Implementación: encontramos los diagramas de componentes: representan los componentes físicos de una aplicación; y los diagramas de despliegue: representan la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software, procesos y objetos que se ejecutan en ellos.