• Author / Uploaded
• MiguelAlejandroDeLaTorreCentellas

• Categories
• Caso de uso
• Clase (Programación informática)
• Herencia (Programación Orientada a Objetos)
• Lenguaje de modelado unificado
• Objeto (informática)

Citation preview

PARTE II MODELO ESTRUCTURAL

PREPARADO POR EL M.SC. ALDO RAMIRO VALDEZ ALVARADO [email protected]

MODELO ESTRUCTURAL CONTENIDO 1. CLASES. 2. RELACIONES. 3. DIAGRAMAS DE CLASES. 4. PAQUETES. 5. INSTANCIAS. 6. DIAGRAMAS DE OBJETOS.

1. CLASES Las clases son los elementos mas importantes de un sistema OO. Una clase es la descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase puede implementar una o más interfaces. Ejemplo. Información Paciente Nombre paciente ID Sexo Edad Fecha de Nacimiento Alta() Baja() Modificación() Consulta () Informe()

1. CLASES NOMBRE El nombre de la clase es una cadena de texto. Un nombre puede ser simple o puede ser el nombre de camino, este nombre de camino es el nombre de clase precedido del paquete. En UML se puede dibujar la clase solo mostrando el nombre de la clase. Ejemplo. Información Paciente java::awt::rectangle

Alimentos java::io::file

1. CLASES ATRIBUTOS Es una abstracción de un tipo de dato o estado. Es una propiedad que describe un rango de valores. Una clase puede tener cualquier numero de atributos o no tener ninguno. OPERACIONES Es la implementación de un servicio para que muestre un comportamiento. Una operación cambia el estado o los datos del objeto. Un operación es un verbo corto o una expresión verbal que representa un comportamiento de la clase que lo contiene. Una clase puede tener cualquier numero de operaciones o ninguna.

1. CLASES ORGANIZACIÓN DE ATRIBUTOS Y OPERACIONES No es necesario mostrar todos los atributos y operaciones de una clase, se puede abreviar una clase, es decir, se puede decidir mostrar algunos o ningún atributo y/o operación. Para organizar mejor las listas atributos y operaciones se puede usar estereotipos para anteponer a cada grupo una categoría descriptiva. Ejemplo. Información Paciente “Constructor” Nuevo() “Procesos” Alta() Baja() Modificación() “Consultas” Consulta() Informe()

1. CLASES RESPONSABILIDADES Es un contrato o una obligación de una clase. Los atributos y operaciones son las características por medio de las cuales se lleva a cabo las responsabilidades de la clase. Se pueden representar al final del icono de la clase y son en general texto libre. Ejemplo. Información Paciente Responsabilidades **maneja la información relacionada con el paciente.

1. CLASES VISIBILIDAD Uno de los detalles más importantes que se puede especificar paro los atributos y operaciones de un clasificador es su visibilidad. 1.public. Cualquier clasificador externo con visibilidad hacia el clasificador dado puede utilizar la característica; se específica precediéndola del signo +. 2.protected. Cualquier descendiente del clasificador puede utilizar la característica; se especifica precediéndola del signo #. 3.private. Sólo el propio clasificador puede la característica; se especifica precediéndola del signo -..

utilizar

1. CLASES Cuando se especifica la visibilidad de las características de un clasificador, normalmente se desea ocultar los detalles de implementación y mostrar solo aquellas características necesarias para llevar a cabo sus responsabilidades. ELEMENTOS ABSTRACTOS, RAÍCES, HOJAS Y POLIMÓRFICOS. Ciertas clases son abstractas, es decir, no pueden tener instancias directas. En UML este tipo de clases se distingue escribiendo su nombre en cursiva. En contraste una clase concreta es aquélla que puede tener instancias directas. Cuando se usa clase, es probable que se desee heredar características de otras clases mas generales, y también permitir que otras clases mas especificas hereden características de ella.

1. CLASES Esta es la semántica normal que se tiene con las clases en UML. Sin embargo se puede especificar que una clase no puede tener hijos, escribiendo la propiedad leaf bajo el nombre de la clase, este tipo de clases se llaman clases hoja, también se puede especificar que una clase no puede tener padres, escribiendo la propiedad root bajo el nombre de la clase, este tipo de clases se llaman clases raíz. Las operaciones tienen propiedades similares, normalmente una operación es polimórfica, lo que significa que se pueden especificar operaciones con la misma signatura en diferentes puntos de una jerarquía de clases. Las operaciones de las clases hija redefinen el comportamiento de las operaciones de las clases padre. Ejemplo.

1. CLASES Icono {root}

Icono rectangular altura: integer Anchura:integer

origen: Punto Mostrar() BotonOK {leaf} Mostrar()

1. CLASES MULTIPLICIDAD Cuando se utiliza una clase, podemos asumir que puede haber cualquier numero de instancias de ella, sin embargo, algunas veces se desea restringir el numero de instancias que una clase puede tener. Lo mas frecuente es que se desee especificar cero instancias (en cuyo caso la clase es una clase de utilidad que hace públicos solo atributos y operaciones con alcance de clase), una única instancia (una clase unitaria o singleton), un numero especifico de instancias o muchas instancias (el valor por omisión). El numero de instancias que puede tener una clase es su multiplicidad. La multiplicidad también se aplica a los atributos, usando una expresión adecuada entre corchetes después del nombre.

1. CLASES CARACTERÍSTICAS AVANZADAS DE LOS ATRIBUTOS Al modelar normalmente se escribe el nombre de cada atributo, normalmente esto es suficiente para entender el modelo, pero como se vio anteriormente se puede especificar la visibilidad, el alcance y la multiplicidad de cada atributo. En su forma completa la sintaxis de un atributo en UML es: [visibilidad] nombre [multiplicidad] [:tipo][= valor inicial] [{propiedades}] Por ejemplo: • +origen: Punto origen: Punto = (0,0) •Nombre [0 … 1]: String •Id: Integer {frozen}

1. CLASES Hay tres propiedades predefinidas que se pueden emplear con los atributos: 1. changeable. No hay restricciones para modificar el valor del atributo. 2. addOnly. Para los atributos con multiplicidad mayor que uno, se pueden añadir valores adicionales, pero una vez creado, un valor no puede ser eliminado o modificado. 3. frozen. El valor del atributo no se puede modificar tras inicializar el objeto.

1. CLASES CARACTERÍSTICAS AVANZADAS DE LAS OPERACIONES Al modelar normalmente se escribe el nombre de cada operación, normalmente esto es suficiente para entender el modelo, pero como se vio anteriormente se puede especificar la visibilidad y el alcance de cada operación. Aún hay más, también se puede especificar los parámetros, el tipo de retorno, la semántica de concurrencia y otras propiedades de cada operación. El nombre de una operación junto a sus parámetros (incluido el tipo de retorno si lo hay) se conoce como signatura de la operación. UML distingue entre operación y método. Una operación específica un servicio que se puede requerir de cualquier objeto de la clase, para influir en su comportamiento.

1. CLASES Un método es una implementación de una operación. Cada operación no abstracta de una clase debe tener un método, el cual proporciona el algoritmo ejecutable como cuerpo. En su forma completa la sintaxis de una operación en UML es: [visibilidad] nombre [{lista de parámetros}] [:tipo de retorno] [{propiedades}] Por ejemplo: • +mostrar • poner (n: Nombre, s: String) • obtenerID (): Integer • reiniciar() {guarded} En la signatura de una operación se pueden proporcionar cero o más parámetros, que tienen la siguiente sintaxis:

1. CLASES [dirección] nombre : tipo [= valor por defecto] Donde dirección puede tomar los siguientes valores: • in. Parámetro de entrada; no se puede modificar. • out. Parámetro de salida; puede modificarse para comunicar información al invocador. • inout. Parámetro de entrada; puede ser modificado. Además hay cinco propiedades definidas que se pueden utilizar en las operaciones. 1. leaf. Operación hoja, esto significa que la operación no es polimórfica y no puede ser redefinida. 2. isQuery. La ejecución de la operación no cambia el estado del sistema. En otras palabras, la operación es una función pura, sin efectos laterales.

1. CLASES 3. guarded. La semántica e integridad del objeto se garantizan en presencia de múltiples flujos de control por medio de la secuenciación de todas las llamadas a todas las operaciones con guardas del objeto. En efecto, se puede invocar exactamente una operación a un mismo tiempo sobre el objeto, reduciendo esto a una semántica secuencial. 4. concurrent. La semántica e integridad del objeto se garantizan en presencia de múltiples flujos de control, tratando la operación como atómica. Pueden ocurrir simultáneamente múltiples llamadas desde diversos flujos de control a cualquier operación concurrente, y todas pueden ejecutarse concurrentemente con semántica correcta.

1. CLASES 5. sequential. Los invocadores deben coordinarse para que en el objeto sólo haya un único flujo al mismo tiempo. En presencia de múltiples flujos de control, la semántica y la integridad del objeto no se pueden garantizar. Las tres últimas propiedades cubren la semántica de concurrencia de una operación. Estas propiedades solo son relevantes en presencia de objetos activos, procesos o hilos. CLASES PLANTILLA (TEMPLATES) Una plantilla es un elemento parametrizado, que permite definir una familia de clases o de funciones. Una plantilla incluye huecos para clases, objetos y valores, donde estos huecos sirven como parámetros para la plantilla.

1. CLASES ELEMENTOS ESTÁNDAR Todos los mecanismos de extensibilidad de UML se aplican a las clases. Lo más frecuente es que se utilicen valores etiquetados para extender las propiedades de la clase (como especificar la versión de la clase) y estereotipos para especificar nuevos tipos de componentes. UMl define cuatro estereotipos estándar que se aplican a las clases: 1. metaclass. Específica un clasificador cuyos objetos son todos clases. 2. powertype. Específica un clasificador cuyos objetos son los hijos de un padre dado. 3. stereotype. Específica que el clasificador es un estereotipo que se puede aplicar a otros elementos.

1. CLASES 4. utility. Específica una clase cuyos atributos y operaciones tienen alcance de clase.

2. RELACIONES Muy pocas clases están solas, la mayoría colaboran con otras de varias maneras. Dentro del modelado OO existen tres tipos de relaciones: las dependencias, las generalizaciones y las asociaciones. En UML la forma en que se conectan las cosas ya sea lógica o físicamente se modela usando relaciones. DEPENDENCIA Es una relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que la utiliza. Se usan cuando se quiere indicar que un elemento utiliza a otro, una clase utiliza a otra como argumento en la signatura de una operación. Ejemplo.

2. RELACIONES PelicualVideo nombre reproducirEn(c: Canal) Iniciar() Para() Rebobinar()

Canal

Una dependencia simple sin adornos suele bastar para la mayoría de las relaciones de uso que aparecen al modelar, sin embargo si se quiere modelar ciertos matices UML define 17 estereotipos agrupados en 6 grupos. De la siguiente manera: Dependencias de las clases y objetos en los diagramas de clases.

2. RELACIONES 1. bind. Especifica que el origen de la dependencia instancia a la plantilla destino con los parámetros reales dados. 2. derive. Especifica que el origen puede calcularse a partir del destino. 3. friend. Especifica que el origen tiene una visibilidad especial en el destino. 4. instanceOf. Especifica que el origen es una instancia del clasificador destino. 5. instantiate. Especifica que el origen crea instancias del destino. 6. powertype. Especifica que el destino es un supratipo del origen; un supratipo es un clasificador cuyos objetos son todos los hijos de un padre dado.

2. RELACIONES 7. refine. Especifica que el origen está a un grado de abstracción mas detallado que el destino. 8. use. Especifica que la semántica del elemento origen depende de la semántica de la parte pública del destino Hay dos estereotipos que se aplican a las dependencias entre paquetes 1. access. Especifica que el paquete origen tiene permiso para referenciar elementos del paquete destino. 2. import. Un tipo de acceso que especifica que los contenidos públicos del paquete destino entran en el espacio de nombres del origen, como si hubiesen sido declarados en el origen. Dos estereotipos se aplican a las relaciones de dependencia entre casos de uso.

2. RELACIONES 1. extend. Especifica que el caso de uso destino extiende el comportamiento del origen.. 2. include. Especifica que caso de uso origen incorpora explícitamente el comportamiento de otro caso de uso en la posición especificada por el origen. Hay tres estereotipos que surgen al modelar interacciones entre objetos. 1. become. Especifica que el destino es el mismo objeto que el origen, pero en un instante posterior y posiblemente con diferentes valores, estados o roles. 2. call. Especifica que la operación origen invoca a la operación destino. 3. copy. Especifica que el objeto destino es una copia exacta, pero independiente del origen.

2. RELACIONES Un estereotipo que aparece en el contexto de las máquinas de estados es: send. Especifica que la operación origen envía el evento destino. Por último, hay un estereotipo que aparecerá en el contexto de la organización de los elementos de un sistema en subsistemas y modelos: trace. Especifica que el destino es un antecesor histórico del origen. GENERALIZACIÓN Es la relación de un elemento general (superclase, clase padre) y un caso mas específico (subclase o clase hija). Es una relación del tipo “es un tipo de”, esto significa que los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa, esto en otras palabras significa que el hijo puede sustituir al padre.

2. RELACIONES Una clase hija hereda las propiedades de sus clases padres, especialmente sus atributos y operaciones, a menudo la clase hija añade atributos y operaciones a los que hereda de sus padres. Una operación de la clase hija con el mismo nombre de la clase padre se conoce como polimorfismo. Una clase puede tener ninguno, uno o mas padres. Una clase sin padres y uno o mas hijos se denomina clase raíz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un único padre se dice que utiliza herencia simple, y una clase con varios padres se dice que utiliza herencia múltiple. Las generalizaciones son muy frecuentes entre clases e interfaces, y entre paquetes. Ejemplo.

2. RELACIONES Figura origen Mover() cambiarTamaño() Dibujar()

Rectángulo esquina: Punto

Círculo radio: Float

Polígono puntos: Lista

Dibujar

Cuadrado

2. RELACIONES Una generalización simple sin adornos suele bastar para la mayoría de las relaciones de herencia que aparecen al modelar, sin embargo si se quiere modelar ciertos matices UML define un estereotipo y cuatro restricciones que pueden aplicarse a las generalizaciones. En primer lugar el estereotipo: implementation. Especifica que el hijo hereda la implementación del padre, pero no hace públicas ni soporta sus interfaces, y por ello viola la semántica de sustitución. Se usará implementation cuando se quiera modelar la herencia privada. A continuación hay cuatro restricciones estándar que se aplican a las relaciones de generalización:

2. RELACIONES 1. complete. Específica que todos los hijos en la generalización se han especificado en el modelo y no se permiten hijos adicionales. 2. incomplete. Específica que no se han especificado todos los hijos en la generalización y que se permiten hijos adicionales. 3. disjoint. Especifica que los objetos del padre no pueden tener mas de uno de los hijos como tipo. 4. overlapping. Especifica que los objetos del padre pueden tener mas de uno de los hijos como tipo.

2. RELACIONES ASOCIACIÓN Es una relación estructural que específica que los objetos de un elemento están conectados con los objetos de otro. Las asociaciones de objetos de la misma clase se denominan unarias, entre dos clases binarias, y n – arias entre varias clases. Las asociaciones se utiliarán cuando se quierán representar relaciones estructurales. Aparte de esta forma básica hay cuatro adornos que se aplican a las asociaciones. Nombre. Una asociación puede tener un nombre, que describe la naturaleza de la asociación. Se puede usar una punta de flecha para indicar el sentido, para que no exista ambigüedad. Ejemplo.

2. RELACIONES Trabaja para Persona

Empresa

Rol. Cuando una clase participa en una asociación, tiene un rol específico que juega en la asociación; un rol es simplemente la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. Ejemplo. Persona

empleado

patrón

Empresa

2. RELACIONES Multiplicidad. A veces es importante señalar cuantos objetos pueden conectarse a través de una instancia de una asociación, a estos cuantos se denomina multiplicidad de la asociación. Cuando se indica una multiplicidad en un extremo de una asociación, se esta especificando que, para cada objeto de la clase en el extremo opuesto debe haber tantos objetos en este extremo. Se puede indicar una multiplicidad de exactamente uno (1) o tres (3), cero o uno (0 … 1), muchos (0 … *), o uno o mas (1 … *). Ejemplo. Persona

1…*

empleado

*

patrón

Empresa

2. RELACIONES Agregación. Una asociación normal entre clases representa una relación estructural entre iguales, sin embargo a veces se quiere modelar el Todo Vs. Partes, este tipo de relación se llama agregación. La agregación es una relación del tipo “tiene un”. Ejemplo. Empresa 1

* Departamentos

2. RELACIONES Para usos avanzados hay otras propiedades que permiten modelar detalles sutiles, como la navegación, visibilidad, calificación y algunas otras como ser: Navegación. Dada una asociación simple, sin adornos, entre dos clases, es posible navegar de los objetos de un tipo a los del otro. A menos que se indique lo contrario. La navegación a través de una asociación es bidireccional Usuario

1

propietario

*

Clave

2. RELACIONES Visibilidad. Dada una asociación entre dos clases, los objetos de una clase pueden ver y navegar hasta los objetos de la otra, a menos que se restrinja por medio de un enunciado explicito de navegación. Calificación. En el contexto de una asociación, uno de los esquemas de modelo mas frecuente tiene que ver con el problema de las búsquedas. Dado un objeto en un extremo de una asociación, ¿Cómo identificar un objeto o conjunto de objetos en el otro extremo?. En UML se modela este esquema con un calificador, que es un atributo de una asociación cuyos valores participan en el conjunto de objetos relacionados con un objeto a través de una asociación. Ejemplo.

2. RELACIONES MesaDeTrabajo

IdTrabajo: int

*

0…1

ArtículoDevuelto

Especificador de Interfaz. En el contexto de una asociación, con otra clase destino, una clase origen puede decidir presentar sólo una parte de su rostro al mundo. Composición. La agregación es un concepto simple con una semántica bastante profunda. La agregación simple es completamente conceptual y no hace más que distinguir un todo de una parte. La agregación simple no cambia el significado de la navegación a través de la asociación entre el todo y sus partes, ni liga las vidas del todo y sus partes.

2. RELACIONES Sin embargo, existe una variación de la agregación simple, la composición, que es una forma de agregación con una fuerte relación de pertenencia y vidas coincidentes de la parte con el todo. Las partes con una multiplicidad no fijada pueden crearse después de la parte compuesta a la que pertenecen, pero una vez creadas viven y mueren con ella. Tales partes también se pueden eliminar explícitamente antes de la eliminación de la parte compuesta. Ejemplo. Puerta 1

* Marco

2. RELACIONES Clases asociación. Es una asociación entre dos clases, la propia asociación puede tener propiedades. En UML esto se modelaría con una clase asociación, la cual es un elemento del modelado tanto con propiedades de asociación como de clase. Ejemplo. Persona

empleado

patrón

Trabajo Descripción fechaContrato salario

Empresa

2. RELACIONES Restricciones. Las propiedades simples y avanzadas que han sido presentadas hasta ahora son suficientes para la mayoría de las relaciones estructurales que aparecerán en el modelado. Sin embargo UML define cinco restricciones si se quiere mostrar ciertos matices, que son: 1. implicit. Especifica que la relación no es manifiesta sino, más bien, es sólo conceptual. 2. ordered. Especifica que el conjunto de objetos en un extremo de una asociación sigue un orden explícito. 3. changeable. Se puede añadir, eliminar y modificar libremente los enlaces entre los objetos. 4. addOnly. Se puede añadir nuevos enlaces desde un objeto del otro extremo de la asocición.

2. RELACIONES 5. frozen. Un enlace una vez añadido desde un objeto del otro extremo de la asociación, no se puede modificar ni eliminar. REALIZACIÓN Una realización es una relación semántica entre clasificadores, en la cual un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Semánticamente la realización es algo así como una mezcla entre dependencia y generalización, y su notación es una combinación de las dos anteriores. La realización se utilizará bajo dos circunstancias: en el contexto de las interfaces y en el contexto de las colaboraciones. Ejemplo.

2. RELACIONES “interface” AgentedeReglas

Forma Canónica ReglasNegocioPedidos

añadirRegla() cambiarRegla() explicarAcción()

Forma Abreviada

reglaPedido.dlll

AgentedeReglas Validar Usuario

Validación VOLVER A INTERFACES

3. DIAGRAMAS DE CLASES DIAGRAMAS DE CLASES Representa un conjunto de clases, interfaces y colaboraciones así como sus relaciones. Se utilizan para modelar el vocabulario del sistema, así como también para modelar colaboraciones o esquemas. Son la base para modelar diagramas de componentes y de despliegue. Los diagramas de clases también pueden contener paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes mas grandes. Cuando se modela la vista de diseño estática de un sistema, normalmente se utilizarán los diagramas de clases de una de estas tres formas: 1. Para modelar el vocabulario de un sistema. 2. Para modelar colaboraciones simples. 3. Para modelar un esquema lógico de base de datos. Ejemplo.

3. DIAGRAMAS DE CLASES Ventana

Abrir() Cerrar() Mover() Dibujar() ManejarEvento()

Ventana Consola

Cuadro de Dialogo

Evento

Control

4. PAQUETES Un paquete es un mecanismo de propósito general para organizar elementos en grupos. Nombre. Un nombre es una cadena de texto, el nombre sólo se denomina nombre simple; y el nombre de camino consta del nombre del paquete precedido por el nombre del paquete en el que se encuentra, si se da el caso. Al igual que las clases se puede dibujar paquetes con adornos que muestran los detalles de lo que contiene el paquete. Ejemplo. Cliente Reglas de Negocio

Sensores::Visión + FormularioDePedido + FormularioDeSeguimiento - Pedido

4. PAQUETES Elementos Contenidos. Un paquete puede contener otros elementos, incluyendo clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes. Estos elementos se declaran en el paquete, si el paquete se destruye el elemento se destruye. Cada elemento pertenece exclusivamente a un único paquete. Se puede tener elementos del mismo tipo y del mismo nombre en diferentes paquetes, eso indica que son diferentes. Se puede tener elementos del mismo nombre en un mismo paquete lo que indica que los elementos son diferentes. Se puede tener paquetes dentro de paquetes, se espera como máximo tres niveles de paquetes anidados. Visibilidad. Se puede controlar la visibilidad de los elementos contenidos en un paquete de la misma forma que se lo hace con los atributos y operaciones de una clase.

4. PAQUETES Importación y Exportación. Se puede tener una clase A dentro de un paquete y una clase B dentro de otro paquete, teniendo cada paquete conocimiento del otro. Supongamos que A y B se declara como públicas en sus respectivos paquetes, aunque A y B son públicas ninguna puede acceder a la otra debido a que sus paquetes forman un muro opaco. Sin embargo si el paquete de A importa al paquete de B, A ahora puede ver a B, pero no a la inversa (relación univoca). En UML una relación de importación se modela como una dependencia con el estereotipo import. Las partes que exporta un paquete son sólo visibles al contenido de aquellos paquetes que lo importan explícitamente. Ejemplo.

4. PAQUETES Cliente + FormularioDePedido + FormularioDeSeguimiento - Pedido Políticas

“import”

+ReglasDePedidos - GUI::Ventana GUI +Ventana +Formulario #GestorEventos

“import”

4. PAQUETES Generalización. Existen dos tipos de relaciones que pueden darse entre paquetes, las dependencias de importación, utilizadas para importar en un paquete los elementos exportados por otro, y las generalizaciones, para especificar familias de paquetes. Todos los mecanismos de extensibilidad de UML se aplican a los paquetes. UML define cinco estereotipos estándar que se aplican a los paquetes: 1. facade. Especifica un paquete que es sólo una vista de algún otro paquete. 2. framework. Especifica un paquete que consta principalmente de patrones. 3. stub. Especifica un paquete que sirve de proxy para el contenido público de otro paquete.

4. PAQUETES 4. subsystem. Especifica un paquete que representa una parte independiente del sistema completo que se está modelando. 5. system. Especifica un paquete que representa el sistema completo que se esta modelando.

5. INSTANCIAS Una instancia es una manifestación concreta de una abstracción a la que se puede aplicar un conjunto de operaciones y que posee un estado que almacena el efecto de las operaciones. Instancia y objeto son en gran parte sinónimos. Gráficamente, una imstancia se representa subrayando su nombre. Ejemplo. teclasPulsadas:Cola :Marco

Abstracciones e instancias. Las instancias no aparecen aisladas, casi siempre están ligadas a una abstracción. Los elementos de UML que tienen instancias son: clases, componentes, nodos, casos de uso y asociaciones.

5. INSTANCIAS Un objeto es algo que ocupa espacio en el mundo real o conceptual, y al que se le pueden hacer cosas. UML modela instancias físicas (clases concretas) y cosas que no son tan concretas (clases abstractas). Cuando se modelan instancias, éstas se colocan en los diagramas de objetos (si se desea visualizar sus detalles estructurales) o en diagramas de interacción y de actividades (si se desea visualizar su participación en situaciones dinámicas). Nombre. Cada instancia debe tener un nombre que las distinga de las otras instancias dentro de su contexto. Normalmente un objeto existe en el contexto de una operación, un componente o un nodo. Un nombre es una cadena de texto, llamada nombre elemental, o puede tener un nombre camino.

5. INSTANCIAS Un nombre camino el cual consta de la abstracción precedido por el nombre del paquete en el que éste se encuentra. Se puede dar nombres explícitos a los objetos, a pesar, que este nombre sólo es conocido por el computador donde existe, por eso se puede representar objetos anónimos. Cuando se modelan grandes colecciones de objetos, resulta incomodo representar esta colección, por eso se usan multiobjetos. t:Transacción

unCliente

:Multimedia::AudioStream

agente:

:códigoClave

5. INSTANCIAS Operaciones. Un objeto no es sólo algo que ocupa espacio en el mundo real, también es algo a lo que se le pueden hacer cosas. Si una clase define una operación lectura, y se tiene un objeto obj, entonces la expresión obj.lectura() significa que sobre obj (el objeto) opera lectura. Estado. Un objeto también tiene un estado, que en este sentido incluye todas las propiedades (normalmente estáticas) del objeto más los valores actuales (normalmente dinámicos) de esas propiedades. Estas propiedades incluyen los atributos del objeto, así como sus partes agregadas. El estado de un objeto es dinámico, de forma que al visualizar su estado, realmente se esta especificando el valor de su estado en un momento dado del tiempo y el espacio, que puede ser representado en un mismo diagrama de interacción.

5. INSTANCIAS El estado puede mostrar una instancia con valores de atributos o una instancia con un estado explícito. Ejemplo. miCliente

id: SSN = „432-89-1783‟

c:Teléfono [Esperando Respuesta]

activo = True

Se puede asociar una máquina de estados con una clase, lo cual es especialmente útil al modelar sistemas dirigidos por eventos o al modelar el tiempo de vida de una clase. Es estos casos también se puede mostrar el estado de esta máquina para un objeto dado en un momento dado. Ya que un objeto puede estar en varios estados simultáneamente, también se puede mostrar una lista de estados actuales

5. INSTANCIAS Elementos estándar. Todos los mecanismos de extensibilidad de UML se aplican a los objetos. Normalmente no se aplica un estereotipo directamente a una instancia, ni se le da un valor etiquetado propio. En vez de eso, el estereotipo y los valores etiquetados derivan del estereotipo y valores etiquetados de su abstracción asociada. UML define dos estereotipos estándar que se aplican a las relaciones de dependencia entre objetos y clases: 1. instanceOf. Especifica que el objeto origen es un instancia del clasificador destino. 2. instantiate. Especifica que la clase origen crea instancias de la clase destino de la dependencia. También hay dos estereotipos relacionados con los objetos que se aplican a los mensajes y transiciones:

5. INSTANCIAS 1. become. Especifica que el destino es el mismo objeto que el origen de la dependencia, pero en un instante posterior y con valores, estados o roles posiblemente diferentes. 2. copy. Especifica que el objeto destino es una copia exacta del origen de la dependencia. UML define una restricción estándar que se aplica a los objetos: • transient. Especifica que una instancia del rol es creada durante la ejecución de la interacción que lo engloba, pero se destruye antes de completar la ejecución.

6. DIAGRAMAS DE OBJETOS Los diagramas de objetos modelan las instancias de los elementos contenidos en los diagramas de las clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento dado. Con UML los diagramas de clases se utilizan para visualizar los aspectos estáticos de los bloques de construcción del sistema. Los diagramas de interacción se utilizan para ver los aspectos dinámicos del sistema, y constan de instancias de estos bloques y mensajes enviados entre ellos. Un diagrama de objetos contiene un conjunto de instancias de los elementos encontrados en un diagrama de clases, por tanto un diagrama de objetos representa la vista estática de una interacción, consistiendo en los objetos que colaboran, pero sin ninguno de los mensajes enviados entre ellos.

6. DIAGRAMAS DE OBJETOS Propiedades comunes. Comparte las propiedades comunes al resto de los diagramas (un nombre y un contenido gráfico que es una proyección de un modelo). Contenidos. Normalmente contienen objetos y enlaces, pueden contener al igual que los otros diagramas notas y restricciones. Los diagramas de objetos también pueden contener paquetes o subsistemas. A veces se colocan clases detrás de los diagramas de objetos, especialmente cuando se quiere mostrar la clase que hay detrás de cada instancia. Usos comunes. Esta vista sustenta principalmente los requisitos funcionales de un sistema (los servicios que debe proporcionar el sistema a sus usuarios finales). Permiten modelar estructuras de datos estáticas. Se usa para modelar estructuras de objetos.

6. DIAGRAMAS DE OBJETOS Esto implica tomar una instantánea de los objetos de un sistema en un momento determinado. Un diagrama de objetos representa una escena estática dentro de la historia representada por un diagrama de interacción. Ejemplo. c:Compañia

d1:Departamento nombre=“Ventas”

d2:Departamento nombre=“I+Ds”

d3:Departamento nombre=“Ventas en USA” P:Persona nombre = “Francisco” ID_empleado = 4362 cargo = “Jefe de Ventas”

:InformacioDeContacto dirección =“Av. Villazon, 2”