Aspectos Avanzados de la Tecnología de Objetos

Aspectos Avanzados de la Tecnología de Objetos
2. Fundamentos del modelo de objetos 4ta parte: UML – Diagramas de implementación. Paquetes, subsistemas, modelos. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy
Contenidos Ingeniería del software con componentes. Conceptos de objetos. El proceso de desarrollo. El lenguaje unificado de modelado (Unified Modeling Language – UML): Fundamentos de los modelos de casos de uso. Fundamentos de los modelos de clases. Fundamentos de los diagramas de estado y de actividad. Fundamentos de los diagramas de interacción y colaboración. Diagramas de implementación. Paquetes, subsistemas, modelos. Dr. Juan José Aranda Aboy

Objetivos específicos
Definir los conceptos de objeto, clase y componente. Caracterizar el proceso de desarrollo. Conocer y emplear adecuadamente el lenguaje unificado de modelado (UML) Dr. Juan José Aranda Aboy

Introducción Hasta ahora hemos revisado cómo analizar los problemas y diseñar las soluciones utilizando las técnicas de orientación a objetos. El sistema implementado debe ser ejecutado sobre un hardware, cumpliendo requisitos no funcionales tales como la escalabilidad y las prestaciones. UML define dos modelos que describen cómo se implementa un sistema: Dr. Juan José Aranda Aboy

Introducción (2) Modelo de componentes: Muestra las dependencias entre las partes del código. Está dirigido a los diseñadores y a los encargados de mantenimiento del sistema. Forma parte de la vista de desarrollo. Modelo de desarrollo: Muestra la estructura del sistema en tiempo de ejecución: qué partes se ejecutan en cuáles procesadores y cómo se configura el hardware para proporcionar los recursos necesarios. Contribuye tanto a la vista de proceso como a la vista física. Dr. Juan José Aranda Aboy

Componente Según OMG: Un componente representa una parte de un sistema modular, algún elemento físico, que se puede desplegar y que es reemplazable, que encapsula la implementación y expone un conjunto de interfaces. Ejemplos: Código fuente, binario ó ejecutable. Navegadores ó servidores HTTP. Bases de datos. Biblioteca de enlace dinámico (Dynamic Link Library - DLL). Archivos. Dr. Juan José Aranda Aboy

Componentes en UML Dr. Juan José Aranda Aboy

Componentes y subsistemas
La construcción de diseño que se corresponde con un componente es un subsistema. Brinda una especificación, por ejemplo: en función de casos de uso, y una estructura de clase que realiza dicha especificación. Un componente puede verse como la implementación de un subsistema. Aunque UML no fuerza la correspondencia entre subsistemas y componentes, es buena práctica que exista. Dr. Juan José Aranda Aboy

Tipos de componentes Hay varios, correspondiendo con los tipos de dependencia. Teniendo en cuenta el proceso de compilación por ejemplo, un componente puede ser: Código fuente: Archivo que contiene el código de una clase, que depende de cualquier componente, no necesariamente de código fuente, que tiene que estar disponible cuando se compila. Código objeto binario: Por ejemplo, una biblioteca de clases que depende de cualquier código objeto con el que tiene que estar enlazado para formar un programa ejecutable. Aplicación ejecutable: Puede depender de otros programas, e interactuar con ellos durante el tiempo de ejecución. Dr. Juan José Aranda Aboy

Diagrama de componentes que muestra las dependencias en tiempo de compilación Dr. Juan José Aranda Aboy

Tipos e instancias de componentes
La palabra componente se utiliza para designar tanto al tipo como a la instancia de un tipo de componente. Los diagramas de componentes muestran tipos de componentes. Una instancia de componente es una unidad en tiempo de ejecución. Es normal que haya una sola instancia de un tipo de componente dado. El tipo es a la instancia como la clase al objeto. Un componente, como una clase, puede realizar una interfaz proporcionando operaciones. Dr. Juan José Aranda Aboy

Resumen de clasificadores e instancias
Clase Objeto Caso de uso Escenario Actor Tipo de componente Instancia de componente Dr. Juan José Aranda Aboy

Modelo de despliegue El diagrama de despliegue (deploy diagram) muestra como se configuran las instancias de los componentes y los procesos para la ejecución en las instancias de los nodos de procesos: Los enlaces de comunicación física entre elementos de hardware tales como computadores, impresoras y otros recursos. Las relaciones entre máquinas físicas y procesos: qué se ejecuta y dónde. Dr. Juan José Aranda Aboy

Diagrama de componentes que muestra las dependencias en tiempo de ejecución Dr. Juan José Aranda Aboy

Capa física Se considera el sistema físico, formado por nodos con asociaciones entre si. Un nodo puede ser un procesador capaz de ejecutar componentes software, u otros dispositivos que proporcionan servicios, como impresoras, etc. Las líneas entre nodos representan conexiones físicas entre los nodos: cables, redes de área local, módems, líneas de teléfono, etc. Tanto los nodos como las conexiones pueden tener estereotipos, así como detalles sobre otras propiedades: potencia de cómputo, velocidad de impresión ó de transmisión, etc. Dr. Juan José Aranda Aboy

Diagrama de despliegue sin software
Dr. Juan José Aranda Aboy

Despliegue del software sobre el hardware
Cuando se añaden los componentes de software, se muestra como opera el sistema en tiempo de ejecución. Dado que se considera un sistema en particular, los componentes en un diagrama de despliegue son instancias de componentes, como puede ser una ejecución particular de una aplicación. Se muestra un componente en tiempo de ejecución dentro de un nodo para representar que el componente se ejecuta en el nodo. También pueden mostrarse objetos individuales tanto dentro de los componentes como de forma separada. Si dos componentes están en diferentes nodos, pero tienen una dependencia de tiempo de ejecución entre ellos tiene que existir un enlace físico entre dichos nodos. Dr. Juan José Aranda Aboy

Diagrama de despliegue con el software
Dr. Juan José Aranda Aboy

El modelo de despliegue en el proyecto
Las decisiones sobre la estructura se toman pronto en el proyecto: El cliente tiene hardware que debe utilizar el sistema. El sistema necesita comunicarse con otros sistemas ya existentes, lo que puede restringir las decisiones. Los requisitos no funcionales pueden determinar ó influir sobre el hardware (Hw) y el software de bajo nivel, como los sistemas operativos (SO). Las decisiones sobre Hw y SO están interrelacionadas con las decisiones sobre lenguajes de programación, bibliotecas de componentes, etc. En un proyecto que utiliza Hw especializado (por ejemplo para adquirir imágenes) puede solicitarse dicho Hw muy pronto en la etapa de diseño para que no exista demora en la entrega del sistema mientras se espera por él. Dr. Juan José Aranda Aboy

Paquetes Un paquete es una colección de elementos del modelo. Algunas razones para empaquetar elementos del modelo son: Conveniencia: Para ocultar detalles irrelevantes en un diagrama. Definición de partes de un sistema: Los diferentes equipos de implementación se concentran en su propio desarrollo, sin profundizar en detalles sobre como funciona el resto del sistema. Los paquetes ayudan a proporcionar control sobre el espacio de nombres. Para especificación y diseño: Se asegura la comprensión sobre las interacciones del componente con el contexto que le rodea: Subsistema. Dr. Juan José Aranda Aboy

Ejemplo de paquete Dr. Juan José Aranda Aboy

Guía para organizar en paquetes
Establecer particiones del modelo del dominio en paquetes que organicen apropiadamente las clases puede hacerse colocando los elementos que: se encuentran en la misma área de interés, y están estrechamente relacionados por conceptos u objetivos. están juntos en una misma jerarquía de clases. participan en los mismos casos de uso. están fuertemente asociados. Dr. Juan José Aranda Aboy

Control del espacio de nombres
Un paquete no tiene significado verdadero por si mismo, ya que todo su comportamiento lo proporcionan los elementos del modelo que se encuentran dentro de él, y no tiene una interfaz. Lo único que puede hacer es definir el espacio de nombres de los elementos que hay dentro de él. En un espacio de nombres no puede haber dos cosas diferentes con el mismo nombre. El ejemplo mas simple de espacio de nombres es una clase: no se espera que haya una operación y un atributo con el mismo nombre. Sin embargo, pueden existir operaciones y atributos en distintas clases con los mismos nombres sin que haya confusión: el nombre de la clase resuelve la ambigüedad. Dr. Juan José Aranda Aboy

Espacio de nombres El espacio de nombres (namespaces) resuelve la ambigüedad, generalizando la idea anterior. Es útil cuando hay varios equipos desarrollando diferentes partes de un problema, ya que pudiera ocurrir que utilicen un mismo nombre para diferentes propósitos. De forma implícita, cada elemento tiene su nombre en un espacio de nombres determinado. Dr. Juan José Aranda Aboy

Importación ó acceso a un paquete
Cada elemento del modelo está en un espacio de nombres. En general, un elemento puede nombrar (conocer) elementos en su propio paquete y elementos que están en otros paquetes vecinos. Sin embargo, un elemento no puede nombrar a otros elementos que están en paquetes que no lo contengan: Las cosas que están fuera de un paquete no pueden verse dentro de éste. Si algún elemento necesita nombrar algún elemento dentro de otro paquete que no lo contiene, deberá importar ó acceder a ese paquete. Dr. Juan José Aranda Aboy

Importación … (2) Esta es una manera útil de controlar las dependencias: Para nombrar algo siempre tiene que depender de él mismo y si una parte del sistema depende de otra se debe hacer explícito. Así se controla que los cambios en una parte no generen cambios inesperados en otras partes. La importación y el acceso al paquete permite almacenar las dependencias de alto nivel de partes de un sistema en otro sin entrar en detalles sobre qué cosas de un paquete dependen de cuáles cosas de otro. Dr. Juan José Aranda Aboy

Visibilidad Los paquetes, al igual que las clases, pueden restringir la visibilidad de los elementos que contienen. Algunos paquetes pueden diseñarse como públicos y otros como privados. Los elementos que acceden ó importan un paquete pueden ver los elementos públicos que están en él, pero no los elementos privados. Existe una tercera categoría: protegido, que incluye elementos disponibles dentro del paquete y para cualquier especialización del mismo. Dr. Juan José Aranda Aboy

Visibilidad de paquete
Paquetes Dr. Juan José Aranda Aboy

Subsistemas (1) Aunque los paquetes son un paso útil hacia la gestión del desarrollo de grandes sistemas, no permiten especificar que parte del sistema debería realizar. Un subsistema es un tipo de paquete que tiene una parte de especificación y otra de realización: colección de objetos relacionados de acuerdo con las relaciones definidas entre sus clases, que pueden realizar los casos de uso en la parte de especificación del subsistema. Proporcionan una manera de utilizar los paquetes de forma efectiva en el desarrollo compartido y en la implementación de componentes. Dr. Juan José Aranda Aboy

Subsistemas (2) Pueden ser instanciables ó no. Si lo son, una instancia del subsistema es una colección de instancias de clases (y de cualquier subsistema mas pequeño) que forman parte de la realización del subsistema. Existe estrecha correspondencia entre componentes y subsistemas: Un componente es una implementación según el diseño dado por la parte de realización de un subsistema. Satisface la especificación dada por la parte de realización de un subsistema. Dr. Juan José Aranda Aboy

Un subsistema Dr. Juan José Aranda Aboy

Modelos y vistas Vista casos de uso: Se obtiene del modelo de casos de uso. Vista lógica: Se obtiene del modelo de clases, de los diagramas de interacción y los diagramas de estado hasta el punto en que se utilizan para especificar el comportamiento lógico del sistema. Vista de proceso: Se obtiene de los diagramas de interacción, de estado y de actividad, hasta el punto que se utilizan para determinar los hilos de control del sistema y de los diagramas de despliegue. Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades. Vista de desarrollo: Se obtiene de los diagramas de componentes, de los paquetes y subsistemas donde aparezcan. Vista física: Se obtiene de los diagramas de despliegue. Dr. Juan José Aranda Aboy

Comentarios La Vista UML, conocida como vista 4+1 de un sistema (ver presentación AATO_U2_Fundamentos_UML.ppt, diapositiva 13) no queda exactamente organizada por los diversos modelos UML, aunque éstos cubren los aspectos necesarios. En cada caso, el modelo incluye algunos elementos, pero otros no. Por ejemplo, el modelo de casos de uso incluye actores y sus relaciones, pero no incluye clases y sus asociaciones. Formalmente, UML define un modelo como un paquete que contiene elementos y que construye una vista particular del sistema que está siendo modelado. Un modelo para un sistema ó subsistema tiene que representar al sistema completo ó subsistema tal y como se ve desde el punto de vista elegido. Un modelo que describe sólo parte de un sistema pertenece a un paquete de dicho subsistema. Dr. Juan José Aranda Aboy

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 Grady Booch, James Rumbaugh, Ivar Jacobson “The Unified Modeling Language User Guide”, Addison Wesley, 1998 OMG Unified Modeling Language Specification, Version 1.3, June 1999 Kruchten, P. “The Rational Unified Process”, Addison Wesley, 2000 Dr. Juan José Aranda Aboy

Referencias en Internet
Desarrollo Orientado a Objetos con UML Tutorial de UML DCC UChile (versión ZIP) Introducción a UML UML con ArgoUML y Poseidon UML® Resource Page TOUR POR UML Programación: Ingeniería de Software: ¿Qué es UML? UML: Análisis y Diseño Orientado a Objetos UML Guía Visual Base de Datos y UML Dr. Juan José Aranda Aboy

Referencias en Internet (en inglés)
The Object Oriented Programming Web The Object Management Group (OMG) Introducing UML: Object-Oriented Analysis and Design Architecture & Design: Overview Computer programming/Object oriented programming Topic: Object-Oriented Programming Dr. Juan José Aranda Aboy

Referencias de Microsoft
MSDN Domain-Specific Language Tools MSDN Software Factories Microsoft patterns & practices Developer Center patterns & practices: Web Applications MSDN Solution Architecture Center Dr. Juan José Aranda Aboy

Referencias sobre herramientas para UML (en inglés)
ArgoUML Tutorial ArgoUML: Building a Use Case Diagram NetBeans 5.5 UML Modeling Documentation EclipseUML Free Edition MyEclipse UML (comercial) Poseidon for UML (comercial) Rational software (comercial) Visual Paradigm for UML (comercial) MagicDraw UML (comercial) Borland® Together® Visual Modeling for Software Architecture Design (comercial) Enterprise Architect Modelado avanzado con UML 2.1 (comercial) (versión demostrativa) (Recursos) Objects by design: UML Products by Price Dr. Juan José Aranda Aboy

Literatura presente ya en Internet
Booch G Software Architecture and the UML. Presentación disponible en: como arch.zip. Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc. 22-Mar-1999 Disponible en: Jacobson, I "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en como UMLconf.zip Microsoft y Rational A White Paper on the Benefits of Integrating Microsoft Solutions Framework and The Rational Process. Rational Software Corporation y Microsoft Corporation. Documento msfratprocs.doc Disponible en Object Management Group OMG Unified Modeling Language Specification (Draft). Versión 1.3. alfa R5, marzo de Disponible en: Dr. Juan José Aranda Aboy

Literatura aún ausente de Internet
Booch, G Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb pp Cota A "Ingeniería de Software". Soluciones Avanzadas. Julio de pp Greiff W. R. Paradigma vs Metodología; El Caso de la POO (Parte II). Soluciones Avanzadas. Ene-Feb pp Jacobson, I. et. al Object-Oriented Software Engineering; A Use Case Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp Lewis G "What is Software Engineering?" DataPro (4015). Feb pp [Microsoft 1997] Microsoft Microsoft Solutions Framework 1.0. Microsoft Corporation. USA. Dr. Juan José Aranda Aboy

Aspectos Avanzados de la Tecnología de Objetos

Presentaciones similares

Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Aspectos Avanzados de la Tecnología de Objetos

Presentaciones similares

Presentación del tema: "Aspectos Avanzados de la Tecnología de Objetos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback