La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


Presentación del tema: "SISTEMAS II UNIDAD N º 1 INTRODUCCION A UML T.U.I. LIC. CONTRERAS, PAMELA."— 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 AlternativosEspiralDesarrollo con prototipado Desarrollo incremental Tradicional Refinamiento sucesivo Cascada Refinamiento sucesivo Cascada

3 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.- Modelo de ciclo de vida en cascada

4 Requerimiento sistema global Requerimiento sistema software Diseño Preliminar Diseño 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 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 A. Requisitos del sistema A. Requisitos del software Diseño Codificación A. Requisitos del software Diseño Codificación 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 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 Modelo de ciclo de vida Prototipo 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 ¿Q UÉ 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 L A 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 L A IMPORTANCIA DE MODELAR Un modelo puede ser estructural, destacando la organización del sistema, o puede ser de comportamiento, resaltando su dinámica.

12 R ECORDANDO 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 ¿Q UÉ ES ENTONCES UN M ODELO ? Un Modelo es una simplificación de la realidad. ¿Q UÉ MODELAMOS ? Hay una razón fundamental… Construimos modelos para comprender mejor el sistema que estamos desarrollando. Cuando los modelos de sistemas son complejos y no podemos comprender el sistema en su totalidad. ¿Por qué modelamos?

14 A TRAVÉS DEL MODELADO … … Se fijaron cuatro objetivos 1. Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema. 2. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema. 3. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema. 4. Los modelos documentan las decisiones que hemos adoptado.

15 M ODELADO 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 P ARA V ISUALIZAR 1. La comunicación entre modelos conceptuales esta sujeta a errores a menos que se hable el mismo lenguaje. 2. Hay cuestiones sobre un SW que no se pueden entender a menos que se construyan modelos que trasciendan el lenguaje de programación. 3. Sino se documenta el código, esa información se perderá.

17 P ARA E SPECIFICAR 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 P ARA C ONSTRUIR 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 P ARA D OCUMENTAR 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 F INALIDADES 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 V ENTAJAS Reutilización de código. Simple de entender. Alta cohesión y bajo acoplamiento. Escalabilidad.

23 L IMITACIONES 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 P ERSPECTIVAS 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 M ODELOS Y D IAGRAMAS 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.

26 M ODELOS Y D IAGRAMAS 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 D IAGRAMAS 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 D IAGRAMAS DE UML Los diagramas expresan gráficamente partes de un modelo Use Case Diagrams Use Case Diagrams Diagramas de Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Distribución State Diagrams State Diagrams Diagramas de Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo

29 M ODELO DE ARQUITECTURA 29 Vista de Implementación Vista de Despliegue Vista de Interacción Vista de Diseño Vista de Caso de Uso Vocabulario Funcionalidad Comportamiento Rendimiento, Escalabilidad, Capacidad de procesamiento Ensamblado del Sistema, gestión de la configuración 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 objetivo El objetivo central del lenguaje es: abstraer cualquier tipo de sistema, sea informático o no, mediante diagramas. diagrama 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.


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

Presentaciones similares


Anuncios Google