SISTEMAS II UNIDAD Nº 1 INTRODUCCION A UML T.U.I.

Presentación del tema: "SISTEMAS II UNIDAD Nº 1 INTRODUCCION A UML T.U.I."— Transcripción de la presentación:

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 Codificación Prueba Operació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 Visión alternativa del ciclo de vida en Cascada
Requerimiento sistema global sistema software Diseño Preliminar detallado Código Integración software y hardware Prueba del sistema software Integración del software Prueba de componente Prueba de unidad 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 Modelo en cascada en V Requisitos Diseño de sistema Diseño detallada
Implementación / pruebas unitarias Pruebas de componentes Pruebas de integración Pruebas de aceptación Valida requisitos Verifica diseño 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 Diseño Codificación ……… Mantenimiento Modelo incremental 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.-

7 Modelo de ciclo de vida Prototipo
Recolección y refinamiento de requisitos Producto de ingeniería Diseño rápido Construcción del prototipo Evaluación del prototipo por el cliente Refinamiento del prototipo Parada Comienzo 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 (Unified Modeling Language)
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. 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 objetivos de trazabilidad, mantenibilidad o robustez. UML fue concebido para describir modelos de software. UML está fuertemente vinculado a la OO.

24 Perspectivas de UML Razones: Evidencias:
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.. Proveer a los usuarios con un lenguaje visual expresivo para desarrollar e intercambiar modelos comprensibles. Incorporar mecanismos de extensión y especialización para extender los conceptos básicos del lenguaje. Ser independiente de cualquier lenguaje de programación o metodología de desarrollo. Proveer una base formal para entender el lenguaje de modelado. Favorecer el crecimiento del mercado de las herramientas de modelado. (integración vía XMI, XML Metadata Interchange) Soportar conceptos de mayor nivel conceptual, como componentes, colaboraciones, frameworks y patterns. Integrar las mejores prácticas de la industria de la Ingeniería de Software.

25 Modelos y Diagramas Un modelo captura una 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. Paradigma : es sinónimo de enfoque. O sea que, podríamos tener un enfoque estructurado o un enfoque orientado a objetos. Notación: Es la sintaxis, o la forma en que se escribe. Proceso: conjunto de pasos a seguir para resolver un problema dado.  

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. Los diagramas son vistas del modelo Un modelo es una descripción completa de un sistema desde una perspectiva en particular

28 Diagramas de UML Los diagramas expresan gráficamente partes de un modelo Use Case Diagrams Diagramas de Casos de Uso Scenario Colaboración State Componentes Component Distribución Objetos Estados Secuencia Clases Actividad Modelo Comportamiento dinámico Clasificación Estructura Organización del 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 Un sistema de software orientado a objetos
UML Es un lenguaje para: Especificar Construir Visualizar Documentar Un sistema de software orientado a objetos El objetivo central del lenguaje es: abstraer cualquier tipo de sistema, sea informático o no, mediante diagramas. Un diagrama es 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.