Unidad 2: Programacin orientada a objetos- Actividad N 2

Lenguaje Unificado de Modelado:

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Estandarizacin de UML:
Desde el ao 1995, UML es un estndar aprobado por la ISO como ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML) Versin 1.4.2. Uno de los diagramas ms conocidos es el diagrama del tipo arcano y el del sistema fotovoltaico; el cual esta compuesto por interacciones arcaicas moderadamente complejas en talentos de ramas logsticas que abarcan el emparejamiento esttico irreversible.

Criticas:
A pesar de su estatus de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Sin embargo, UML s acepta la creacin de nuestros propios componentes para este tipo de modelado.

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Historia:
Antes de UML 1.x: Despus de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compaa se convirti en la fuente de los dos esquemas de modelado orientado a objetos ms populares de la poca: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para anlisis orientado a objetos, y el Mtodo Booch de Grady Booch, que era mejor para el diseo orientado a objetos. Poco despus se les uni Ivar Jacobson, el creador del mtodo de ingenier de software orientado a objetos. Jacobson se uni a Rational en 1995, despus de que su compaa Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prcticas metodolgicas. En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba alentando la adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consult con representantes de compaas competidoras en el rea de la tecnologa de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notacin de Booch que utilizaba smbolos de nubes. Bajo la direccin tcnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificacin UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners form una Fuerza de Tarea Semntica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x: Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de Booch, si se adopt la capacidad de Booch para especificar detalles de diseo en los niveles inferiores. La notacin de Casos de Uso del Objectory y la notacin de componentes de Booch fueron integrados al resto de la notacin, pero la integracin semntica era relativamente dbil en UML 1.1, y no se arregl realmente hasta la revisin mayor de UML 2.0. Conceptos de muchos otros mtodos OO fueron integrados superficialmente en UML con el propsito de hacerlo compatible con todos los mtodos OO. Adems el grupo tom en cuenta muchos otros mtodos de la poca, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es til en una variedad de problemas de ingeniera, desde procesos sencillos y aplicaciones de un slo usuario a sistemas concurrentes y distribuidos.

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Diagramas UML
Diagrama de Caso de Uso: En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso. Diagramas de Casos de Uso UML La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes y consistentes promueven una imagen fcil de comprender del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo. Es prctica comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseo como: rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares. Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona. Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin: Inclusin (include o use) Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones son importantes, ellos forman parte de la documentacin de un caso de uso --un propsito para el que el actor puede usar el sistema. La notacin es de una flecha de punta abierta con lnea discontinua desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Este uso se asemeja a una expansin de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno. Aqui tambin podemos decir que ste va de padre a hijo. Extensin (Extend) Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin . "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos."

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2 Generalizacin "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Diagrama de clases
Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro.

Representacin de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseo en una arquitectura - Componentes de software orientados a objetos Definiciones

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Propiedades tambin llamados atributos o caractersticas, son valores que corresponden a un objeto, como color, material, cantidad, ubicacin. Generalmente se conoce como la informacin detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades seran: la marca, tamao, color y peso. Operaciones comnmente llamados mtodos, son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operacin se escribe con minsculas si consta de una sola palabra. Si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc. Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mnimos del objeto. Hace referencia a polimorfismo. Herencia se define como la reutilizacin de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos bsicos como una persona, pero adems cada uno tendr informacin adicional que depende del tipo de persona, como saldo del cliente, total de inversin del accionista, salario del empleado, etc.

Al disear una clase se debe pensar en cmo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se disea. Durante el proceso del diseo de las clases se toman las propiedades que identifican como nico al objeto y otras propiedades adicionales como datos que corresponden al objeto. Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases: Ejemplo 1: Una persona tiene nmero de documento de identificacin, nombres, apellidos, fecha de nacimiento, gnero, direccin postal, posiblemente tambin tenga nmero de telfono de casa, del mvil, FAX y correo electrnico. Ejemplo 2: Un sistema informtico puede permitir administrar la cuenta bancaria de una persona, por lo que tendr un nmero de cuenta, nmero de identificacin del propietario de la cuenta, saldo actual, moneda en la que se maneja la cuenta. Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta", dnde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarn realizando diferentes operaciones que en el diagrama de clases de balurdes slo se representan como operaciones, que pueden ser:

Abrir Cerrar Depsito Retiro

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Acreditar Intereses

Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lgica de negocio, dependiendo de quin disee el sistema se pueden unir los datos con las operaciones. El diagrama de clases incluye mucha ms informacin como la relacin entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz grfica.

Diagrama de Objetos:
Los diagramas de objetos son utilizados durante el proceso de Anlisis y Diseo de los sistemas informticos en la metodologa UML. Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase. Por ejemplo, Miguel: Persona.

Diagramas de Secuencia:

El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence diagram", "eventtrace diagrams", "event scenarios" o "timing diagrams"1

Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2 Utilidad Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. Tipos de mensajes: Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrnicos terminan inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia. Se representan con flechas con la cabeza abierta. Tambin se representa la respuesta a un mensaje con una flecha discontinua. Pueden ser usados en dos formas: De instancia: describe un escenario especifico (un escenario es una instancia de la ejecucin de un caso de uso).

Genrico: describe la interaccin para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura: Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la clase instanciada por el objeto en la recepcin final del mensaje. Diagramas de Estados: Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones. Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso. Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

Diagramas de Colaboracin:
Un diagrama de colaboracin en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboracion, tambin llamados diagramas de comunicacin, muestran explcitamente las relaciones de los roles. Por otra parte, un diagrama de comunicacin no muestra el tiempo como una dimensin aparte, por lo que resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementacin es llamada "enlace".

Un diagrama de comunicacin es tambin un diagrama de clases que contiene roles de clasificador y roles de asociacin en lugar de slo clasificadores y asociaciones. Los roles de clasificador y los de asociacin describen la configuracin de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicacin. Cuando se instancia una comunicacin, los objetos estn ligados a los roles de clasificador y los enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces temporales. Usos: Un uso de un diagrama de colaboracin es mostrar la implementacin de una operacin. La comunicacin muestra los parmetros y las variables locales de la operacin, as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de seales del programa. Un diagrama de secuencia muestra secuencias en el tiempo como dimensin geomtrica, pero las relaciones son implcitas. Un diagrama de comunicacin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales estn menos claras. Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2

Tipos: Es til marcar los objetos en cuatro grupos: los que existen con la interaccin entera; los creados durante la interaccin (restriccin {new}); los destruidos durante la interaccin (restriccin {destroyed}); y los que se crean y se destruyen durante la interaccin (restriccin {transient}). Aunque las comunicaciones muestran directamente la implementacin de una operacin, pueden tambin mostrar la realizacin de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles mltiples que los objetos pueden desempear en varias operaciones. No hay ejemplos de los diagramas, diferentes casos o sistemas UML modela el negocio area o empresa asi como los sistemas que requieren ? Mensajes Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un nmero de secuencia, una lista opcional de mensajes precedentes, una condicin opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explcita. Flujos Generalmente, un diagrama de comunicacin contiene un smbolo para un objeto durante una operacin completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explcitos. Por ejemplo, un objeto pudo cambiar de localizacin o sus asociaciones pudieron diferenciarse. Los diferentes smbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transicin, a partir de un estado de un objeto a otro. Se dibuja como una flecha de lnea discontinua con el estereotipo "become" o "conversin" y puede ser etiquetado con un nmero de serie para mostrar cuando ocurre. Un flujo de conversin tambin se utiliza para mostrar la migracin de un objeto a partir de una localizacin a otra distinta para otro lugar tambin se deben marcar con el numero en secuencias. Cambios en versiones recientes de UML En versiones recientes de UML este diagrama ha sido reemplazado por el diagrama de comunicacin.

Diagrama de Componentes:
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos Scairon Garca Encarnacin Curso: Experto en Programacin Java

Unidad 2: Programacin orientada a objetos- Actividad N 2 incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que los diagramas de componentes son ms parecidos a los diagramas de casos de usos, stos son utilizados para modelar la vista esttica y dinamica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En l se situarn libreras, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qu componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Scairon Garca Encarnacin Curso: Experto en Programacin Java