UNIDAD II

TECNICAS BASICAS DE MODELADO DE OBJETOS

2.1 DEFINICIÓN DE CLASES, ATRIBUTOS, MÉTODOS Y OBJETOS

Clases.

El elemento básico de la programación orientada a objetos en Java es la clase. Una clase

define la forma y comportamiento de un objeto.

Una clase es la unidad básica que encapsula toda la información de un Objeto (un objeto
es una instancia de una clase).

Para crear una clase sólo se necesita un archivo fuente que contenga la palabra clave
reservada class seguida de un identificador legal y un bloque delimitado por dos llaves
para el cuerpo de la clase

class MiPunto
{
…
}
Un archivo de Java debe tener el mismo nombre que la clase que contiene, y se les suele
asignar la extensión ".java". Por ejemplo la clase MiPunto se guardaría en un fichero que
se llamase MiPunto.java. Hay que tener presente que en Java se diferencia entre
mayúsculas y minúsculas; el nombre de la clase y el de archivo fuente han de ser
exactamente iguales.

Aunque la clase MiPunto es sintácticamente correcta, es lo que se viene a llamar una clase
vacía, es decir, una clase que no hace nada. Las clases típicas de Java incluirán variables y
métodos de instancia las cuales mencionaremos en temas posteriores.

Atributos.

Los datos se encapsulan dentro de una clase declarando variables entre las llaves de
apertura y cierre de la declaración de la clase, variables que se conocen como atributos.
Se declaran igual que las variables locales de un método en concreto.

Por ejemplo, este es un programa que declara una clase MiPunto, con dos atributos
enteros
Llamados x e y.
class MiPunto
{
int x, y;
}
Los atributos se pueden declarar con dos clases de tipos: un tipo simple Java, o el nombre
de una clase.
Cuando se realiza una instancia de una clase (creación de un objeto) se reservará en la
memoria un espacio para un conjunto de datos como el que definen los atributos de una
clase. A este conjunto de variables se le denomina variables de instancia.

Métodos.

Los métodos de una clase son funciones ó procedimientos propios de la clase que pueden
tener acceso a los atributos de la misma para realizar las operaciones para los que son
programados.
Cada método recibe ciertos parámetros y retorna su resultado en un dato de cierto tipo,
dependiendo de estos parámetros que recibe el método y el tipo del dato que retorna,
podemos tener métodos con el mismo nombre y serán diferenciados por el tipo de sus
parámetros (polimorfismo).
Los métodos especifican la forma en que se controlan los datos de un objeto. Los métodos
en un tipo de objeto solo hacen referencia a las estructuras de datos de ese tipo de
objeto. No deben tener acceso directo a las estructuras de datos de otros objetos. Para
utilizar la estructura de datos de otro objeto, deben enviar un mensaje a éste. El tipo de
objeto empaca juntos los tipos de datos y los métodos.

En la declaración de los métodos se define el tipo de valor que devuelven y a una lista
formal de parámetros de entrada, de sintaxis tipo identificador separadas por comas. La
forma general de una declaración de método es:
tipo_devuelto nombre_de_método (lista-formal-de-parámetros)
{
cuerpo_del_método;
}

Los métodos son llamados indicando una instancia individual de la clase, que tendrá su
propio conjunto único de variables de instancia, por lo que los métodos se pueden referir
directamente a ellas.

La instanción de las clases: los objetos.

Los tipos simples de Java describían el tamaño y los valores de las variables. Cada vez que
se crea una clase se añade otro tipo de dato que se puede utilizar igual que uno de los
tipos simples. Por ello al declarar una nueva variable, se puede utilizar un nombre de clase
como tipo. A estas variables se las conoce como referencias a objeto. Todas las referencias
a objeto son compatibles también con las instancias de subclases de su tipo. Del mismo
modo que es correcto asignar un byte a una variable declarada como int, se puede
declarar que una variable es del tipo MiClase y guardar una referencia a una instancia de
este tipo de clase:
MiPunto p;
Esta es una declaración de una variable p que es una referencia a un objeto de la clase
MiPunto, de momento con un valor por defecto de null. La referencia null es una
referencia a un objeto de la clase Object, y se podrá convertir a una referencia a cualquier
otro objeto porque todos los objetos son hijos de la clase Object.

2.2 EL MODELO COMO RESULTADO DE LA ABSTRACCIÓN

Existen una serie de principios fundamentales para comprender cómo se modeliza la

realidad al crear un programa bajo el paradigma de la orientación a objetos, uno de los
principales es la abstracción.
Mediante la abstracción la mente humana modeliza la realidad en forma de objetos. Para
ello busca parecidos entre la realidad y la posible implementación de objetos del
programa que simulen el funcionamiento de los objetos reales.

Los seres humanos no pensamos en las cosas como un conjunto de cosas menores; por
ejemplo, no vemos un cuerpo humano como un conjunto de células. Los humanos
entendemos la realidad como objetos con comportamientos bien definidos. No
necesitamos conocer los detalles de porqué, ni cómo funcionan las cosas; simplemente
solicitamos determinadas acciones en espera de una respuesta; cuando una persona
desea desplazarse, su cuerpo le responde comenzando a caminar.

Pero la abstracción humana se gestiona de una manera jerárquica, dividiendo

sucesivamente sistemas complejos en conjuntos de subsistemas más triviales, para así
entender más fácilmente la realidad. Esta es la forma de pensar que la orientación a
objeto intenta cubrir.

2.3 EL UML COMO UNA HERRAMIENTA DE MODELADO DE OBJETOS

El lenguaje unificado de modelado o UML (Unified Modeling Language) es un lenguaje de

modelado, y no un método. La mayor parte de los métodos consisten, al menos en
principio, en un lenguaje y en un proceso para modelar. El lenguaje de modelado es la
notación (principalmente gráfica) de que se valen los métodos para expresar los diseños.
El proceso es la orientación que nos dan sobre los pasos a seguir para hacer el diseño.

UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es
decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase
de diseño de problemas de la estructura, al propagar errores o de las partes que necesitan
ser sincronizadas, así como del estado de cada una de las instancias en cada momento. En
resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien.

UML permite la modificación de todos sus miembros mediante estereotipos y

restricciones.
Un estereotipo nos permite indicar especificaciones del lenguaje al que se refiere el
diagrama de UML. Una restricción identifica un comportamiento forzado de una clase o
relación, es decir mediante la restricción estamos forzando el comportamiento que debe
tener el objeto al que se le aplica.

UML es una especificación de notación orientada a objetos. Divide cada proyecto en un

número de diagramas que representan las diferentes vistas y arquitectura del proyecto. Se
dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y
los que dan una visión dinámica.

2.4 PLANTEAMIENTO DEL PROBLEMA

Cualquier investigación se origina en una duda, inquietud o pregunta, sobre un tema que
interese al investigador, o bien porque hay un problema que no puede ser resuelto con los
elementos científicos actuales. Este primer paso no es más que el cuestionamiento a la
existencia de un fenómeno determinado, que consiste en establecer los requisitos. Esto se
aplica tanto a la investigación de primera línea como a programas sencillos y personales,
así como a los esfuerzos realizados por grandes equipos. Cuando se tiene una idea vaga
del objetivo, lo único que se está haciendo es posponer las decisiones a una etapa en la
cual los cambios serán mucho más costosos.

La definición del problema debería indicar lo que hay que hacer, y no cómo hay que
hacerlo. Debe ser una exposición de nuestras necesidades, y no una propuesta de
solución. El solicitante debería indicar qué características son obligatorias, así como las
que sean opcionales, para evitar restringir en demasía las decisiones de diseño y evitar
describir las características internas del sistema, por cuanto esto le resta flexibilidad a la
implementación. Los estándares de ingeniería del software, tal como una construcción
modular, un diseño adecuado para las pruebas, y la previsión de futuras extensiones, son
también adecuados.
El analista debe separar los requisitos verdaderos de las decisiones de diseño y de
implementación disfrazadas de requisitos y atacar a estos pseudorequisitos, porque
restringen la flexibilidad. La definición de un problema puede tener un grado mayor o
menor de detalle. La mayoría de las definiciones de problema son ambiguas, están
incompletas, y no son ni siquiera congruentes. Hay algunos requisitos que están,
simplemente, mal. Algunos de ellos, aun cuando se hayan expuesto con precisión, tendrán
consecuencias desagradables para el comportamiento del sistema, o bien impondrían
unos costes de implementación irracionales. Otros parecen razonables en primera
aproximación, pero no funcionan tan bien como podría pensar el solicitante. La definición
del problema es solamente un punto inicial para comprenderlo, y no un documento
inmutable. El propósito del análisis subsiguiente es comprender en su totalidad el
problema y sus implicaciones. No hay razón para esperar que la definición de problema
que se haya preparado sin un análisis completo sea la correcta.

2.4.1 Analizar El Enunciado Del Problema

Es el punto mas importante en la redacción del planteamiento, ya que en forma

declarativa o interrogativa comunica lo que será investigado y delimita o especifica el
problema. Cuando se expresa a través de una o mas preguntas, hay que cuidar la
ambigüedad y la indefinición de algunos adverbios interrogativos. Véase, por ejemplo, el
siguiente enunciado: cualquier respuesta que eluda la forma, circunstancia o cualidad,
sería una respuesta pertinente y todas serían distintas
Es necesario analizar determinadamente el problema que se piense investigar, antes de
acometer cualquier otra acción que acarree gastos, tiempo, o esfuerzo personal.

• Resoluble: la naturaleza del problema debe ser tal, que permita llegar a una solución.
Para resolverlo es preciso analizar los siguientes puntos.
•Los datos o resultados que se esperan.
•Los datos de entrada que nos suministran.
•El proceso al que se requiere someter esos datos a fin de obtener los resultados
esperados.
•Áreas de trabajo, fórmulas y otros recursos necesarios.

Delimitado: para poder llevar a cabo un estudio, hay que saber con precisión hasta donde
se extenderán sus conclusiones, y cuales factores serán tomados en consideración. Un
problema muy amplio o que aborde muchas variables, impide prácticamente su análisis.

• Relevante: aunque el investigador debe sentirse libre al momento de seleccionar el

problema, en el sentido de que éste debe ser su gusto, y preferencia para poder dedicarse
a él con entusiasmo y constancia, debe valorar, no obstante, la importancia que el mismo
posee. La relevancia afirma que el problema debe poseer un valor significativo
o Relevancia científica: aporte de nuevos conocimientos.
o Relevancia humana: mejoramiento de la vida social.
o Relevancia contemporánea: solución de problemas actuales.
Una recomendación muy práctica es el que nos pongamos en el lugar del usuario final del
sistema, y analizar que es necesario que me ordenen y en que secuencia, para poder
producir los resultados esperados.

2.4.2 Identificar Funciones Del Sistema

Los investigadores han identificado los problemas y sus causas y han desarrollado reglas y
procedimientos para resolverlos. Cada método de análisis tiene una notación y un punto
de vista únicos. Sin embargo, todos los métodos de análisis están relacionados por un
conjunto de principios fundamentales:

1. Representar y comprender el ámbito de información del problema

2. Desarrollar los modelos que representen la información, función y el comportamiento
del sistema
3. Subdividir los modelos (y el problema) de forma que se descubra los detalles de una
manera progresiva (o jerárquica).
4. El proceso de análisis debe ir de la información esencial hacia el detalle de la
implementación.
Aplicando estos principios, el analista enfoca el problema sistemáticamente. El ámbito de
información se examina para poder comprender completamente la función. Los modelos
se utilizan para poder comunicar la información de forma compacta. La partición se aplica
para reducir la complejidad. Los planteamientos esencial y de implementación del
software son necesarios para acomodar las ligaduras lógicas impuestas por los requisitos
de procesamiento y las ligaduras físicas impuestas por otros elementos del sistema.

2.5 ANALISIS

El análisis es una actividad que engloba la mayoría de las tareas que hemos llamado
colectivamente Ingeniería de sistemas basados en computadora. Este se realiza teniendo
presentes los siguientes objetivos: (1) identificar las necesidades, (2) evaluar la viabilidad
del sistema (3) realizar un análisis técnico (4) asignar funciones, (5) establecer
restricciones de costo y tiempo, (6) crear una definición del sistema que sea la base para
todo el trabajo posterior de la aplicación.

Consta de los siguientes pasos:

• Identificar objetos y clases
• Identificar atributos de objetos y relaciones
• Identificar y depurar relaciones (métodos)
¿Por qué es tan difícil el análisis? Principalmente se trata de una transformación de un
concepto dudoso en un conjunto concreto de elementos tangibles. Debido a que durante
el análisis la comunicación es excepcionalmente densa, abundan las oportunidades de mal
entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepción del
sistema puede cambiar a medida que avanza la actividad invalidando, de esta manera, un
análisis anterior.
2.5.1 Descubrir Objetos En El Dominio Del Problema

Los objetos son las unidades básicas de construcción, para conceptualización, diseño o
programación, son instancias organizadas en clases con características comunes. Estas
características comprenden los atributos y procedimientos, denominados operaciones o
métodos.
Estos objetos deben estar basados, hasta donde sea posible, en entidades del mundo real
y en conceptos de la aplicación o dominio.
Hay que identificar objetos potenciales que formaran el diseño y es tan fácil como buscar
sustantivos (nombres, cosas). A veces no resulta tan obvio ya que los objetos pueden
manifestarse de diversas maneras:
• Cosas
• Entidades externas (personas, maquinas o incluso otros desarrollos)
• Eventos
• Roles
• Lugares
• Organizaciones (departamento, división)

Debemos delimitar los objetos en un dominio cerrado y ser capaces de identificar lo que
esos objetos son, saben y hacen. Partiendo de la identificación de objetos se puede ir
desarrollando un diseño de clases usando símbolos o lenguajes unificados.
Para identificar objetos y clases es necesario realizar la aplicación de los siguientes pasos:
• Seleccionar nombres en los requisitos
• Añadir clases adicionales procedentes de nuestro conocimiento del tema
• Eliminar redundancias
• Eliminar clases irrelevantes
• Eliminar clases vagas
• Separar atributos
• Separar métodos
• Eliminar objetos de diseño
El resultado de identificar correctamente los objetos y las clases para una aplicación, nos
llevará más fácil a la solución del problema.

2.5.2 Identificar Los Atributos De Los Objetos

Los atributos son propiedades o características de objetos individuales, como el nombre,

velocidad o color. Los atributos no deben ser objetos. Los atributos suelen corresponderse
con nombres seguidos por frases posesivas, tal como "el color del coche" o "la posición del
cursor".
Los adjetivos suelen representar valores de atributos específicos, como pueden ser rojo,
encendido o caducado. A diferencia de las clases y de las asociaciones, es menos probable
que los atributos se describan por completo en la definición del problema.

No exagere el descubrimiento de atributos. Se deben considerar solamente aquellos que

estén relacionados directamente con una aplicación particular. Hay que tomar primero los
atributos más importantes; los detalles finos se pueden añadir posteriormente. Durante el
análisis, hay que evitar aquellos que sean solamente para la implementación. Asegúrese
de que se da a cada atributo un nombre significativo.

Los atributos derivados deben ser omitidos o bien deben ser marcados claramente. Por
ejemplo, edad se ha derivado de fecha de nacimiento y de fecha actual (que es una
propiedad del entorno). Los atributos derivados, pueden resultar útiles para abstraer
propiedades significativas de una aplicación, pero deberían distinguirse claramente de los
atributos básicos, que definen el estado del objeto. Los atributos derivados no deben
expresarse como operaciones, tal como preguntar-edad, aun cuando eventualmente
puedan llegar a implementarse de esta manera.

Hay que eliminar los atributos innecesarios e incorrectos mediante los criterios siguientes:

• Objetos: Si es importante la existencia independiente de una entidad, y no solo su valor,

se trata de un objeto. Por ejemplo, en una lista de correos Ciudad se podría considerar
como atributo, mientras que en un censo Ciudad sería un objeto. Una entidad que tiene
características propias dentro de la aplicación dada es un objeto.

• Cualificadores. Si el valor de un atributo depende de un contexto particular, hay que

pensar en recalificar al atributo como cualificador. Por ejemplo, número de empleado no
es una propiedad única para una persona que tenga dos trabajos; lo que hace es cualificar
la asociación Compañía emplea a persona.

• Nombres. Los nombres suelen modelarse mejor como cualificadores que como atributos
de objeto. Comprobación: ¿Selecciona el nombre uno de los objetos de un conjunto?
¿Puede un objeto del conjunto tener más de un nombre? En caso afirmativo, el nombre
cualifica a una asociación. Si el nombre parece ser único, quizá hayamos pasado por alto la
clase de objetos que está siendo cualificada. Por ejemplo, nombre de departamento
puede ser algo único dentro de una compañía aunque eventualmente es posible que el
programa necesite tratar con más de una compañía.

Un nombre es un atributo de un objeto cuando no depende el contexto, y sobre todo

cuando no necesita ser único. Los nombres de las personas, a diferencia de los nombres
de las compañías, se pueden duplicar, y por lo que son atributos de objetos.
• Identificadores. Los lenguajes orientados a objetos contienen la noción de identificador
de objetos para hacer alusión no ambigua a un objeto. Estos identificadores de objetos no
deben enumerarse en los modelos de objetos, por cuanto que en éstos los identificadores
de objetos son implícitos. Solo hay que enumerar aquellos atributos que existen en el
dominio de la aplicación. Por ejemplo, código de cuenta es un atributo genuino; los
Bancos asignan los códigos de cuenta. Por contraste, ID_transacción no debería
enumerarse como atributo, aún cuando pueda ser conveniente generar uno durante la
implementación.

• Valores internos. Si un atributo describe el estado interno de un objeto que es invisible

fuera del objeto, entonces hay que eliminarlo del análisis.

• Detalles finos. Omita aquellos atributos menores que tengan pocas probabilidades de
afectar a la mayoría de las operaciones.

2.5.3 Identificar Métodos En Los Objetos

Los métodos son subrutinas que definen la interfaz de una clase, sus capacidades y
comportamiento. Un método ha de tener por nombre cualquier identificador legal distinto
de los ya utilizados por los nombres de la clase en que está definido. Los métodos se
declaran al mismo nivel que las variables de instancia dentro de una definición de clase.
Los métodos permiten al programador modularizar sus programas. Todas las variables
declaradas en las definiciones de métodos son variables locales: sólo se conocen en el
método en el que se definen. Casi todos los métodos tienen una lista de parámetros que
permiten comunicar información entre métodos. Los parámetros de un método también
son variables locales.

Hay varios motivos para modularizar los programas con métodos. El enfoque de "divide y
vencerás" hace más manejable la tarea de desarrollo de los programas. Otra motivación
es la reutilidad del software: usar métodos ya existentes para crear programas nuevos. Si
nombramos y definimos métodos adecuadamente, podremos crear programas a partir de
métodos estandarizados, en lugar de construirlos empleando código escrito
especialmente para la tarea.

Una tercera motivación es evitar la repetición de código en un programa. Si empacamos el

código en un método, podremos ejecutarlo desde varios puntos de un programa con sólo
invocarlo.

Para identificar y depurar los métodos de un objeto es necesario aplicarlos los siguientes
pasos:
• Seleccionar verbos relacionales en los requisitos
• Añadir relaciones adicionales procedentes de nuestro conocimiento del tema
• Eliminar relaciones de diseño o entre clases eliminadas
• Eliminar eventos transitorios
• Reducir relaciones ternarias
• Eliminar relaciones redundantes o derivadas
• Añadir relaciones olvidadas
• Definir la multiplicidad de cada relación

2.6 INTRODUCCIÓN AL DISEÑO DE LA SOLUCIÓN

El diseño es una actividad en la que se toman decisiones importantes, frecuentemente de

una naturaleza estructural. Con la programación, comparte los aspectos relativos a la
abstracción de la representación de la información y de las secuencias de procesamiento,
pero el nivel de detalle es muy diferente en ambos casos. El diseño construye
representaciones coherentes y bien planificadas de los programas, centrándose en las
interrelaciones de los componentes de mayor nivel y en las operaciones lógicas implicadas
en los niveles inferiores.

2.6.1 Representación
Representación Grafica De Una Clase

El objetivo básico de un gráfico es transmitir la información de forma tal que pueda ser
captada rápidamente, de un golpe de vista. Luego, un gráfico debe ser ante todo sencillo y
claro, a pesar de su aspecto artístico, ya que se elabora para ser incluido en un trabajo
científico.
Encontramos muy útil representar de forma grafica los objetos que conforman nuestra
aplicación, cada clase se representa por una caja en la que se realizan tres divisiones.
• En la superior se especifica el nombre del objeto.
• En la intermedia se incluyen las propiedades del objeto.
• En la inferior se indican las operaciones que realiza el objeto

2.6.2 Diagramas De Interacción Entre La Aplicación Y Una Clase

Para la elaboración de un diagrama de interacción es necesario tomar en cuenta lo

siguiente:
Las clases son estáticas, forman parte del texto del programa y no cambian durante su
ejecución y los objetos por el contrario son totalmente dinámicos, se crean, cambian su
estado y se destruyen. A continuación exponemos los diagramas estáticos

Diagrama de Casos de Uso.

Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola
clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama
de uso es muy útil para definir como debería ser el comportamiento de una parte del
sistema, ya que solo especifica como deben comportarse y no como están implementadas
las partes que define.
En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas
relaciones entre ellas:
• Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que
indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de
uso. Sus relaciones son:
o Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como
un caso de uso, el de totalizar el coste incluye a dos casos de uso.
o Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de
uso B implementa la funcionalidad del caso de uso A.
o Generalization: Es la típica relación de herencia.
• Actores: se representan por un muñeco. Sus relaciones son:
o Communicates: Comunica un actor con un caso de uso, o con otro actor.
• Parte del sistema (System boundary): Representado por un cuadro, identifica las
diferentes partes del sistema y contiene los casos de uso que la forman.

Diagrama de Clases.
En el diagrama de clases definiremos las características de cada una de las clases,
interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es
donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos,
definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.
La Clase.
Una clase esta representada por un rectángulo que dispone de tres apartados, el primero
para indicar el nombre, el segundo para los atributos y el tercero para los métodos. Cada
clase debe tener un nombre único, que las diferencie de las otras.
Un atributo representa alguna propiedad de la clase que se encuentra en todas las
instancias de la clase. Los atributos pueden representarse solo mostrando su nombre,
mostrando su nombre y su tipo, e incluso su valor por defecto.
Un método u operación es la implementación de un servicio de la clase, que muestra un
comportamiento común a todos los objetos. En resumen es una función que le indica a las
instancias de la clase que hagan algo.
Existen tres relaciones diferentes entre clases, Dependencias, Generalización y Asociación.
En las relaciones se habla de una clase destino y de una clase origen. Una clase origen es
desde la que se realiza la acción de relacionar. Es decir desde la que parte la flecha, y la
clase destino es la que recibe la flecha.

Diagrama Objetos.
El Diagrama de Objetos forma parte de la vista estática del sistema, en éste se modelan las
instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones,
pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces;
también se pueden incorporar clases, para mostrar la clase de la que es un objeto
representado.
Para realizar el diagrama de objetos primero se debe decidir que situación queremos
representar del sistema.
Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un
determinado instante de tiempo que posee un valor específico (Un objeto puede
caracterizar una entidad física -coche-) y como un poseedor de identidad que tiene
distintos valores a lo largo del tiempo (abstracta -ecuación matemática-).
Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a él mediante
una denominación exclusiva que permite accederle. El Modelado de Objetos permite
representar el ciclo de vida de los objetos a través de sus interacciones. En UML, un objeto
se representa por un rectángulo con un nombre subrayado.

• Objeto = Identidad + Estado + Comportamiento

• El estado está representado por los valores de los atributos.
• Un atributo toma un valor en un dominio concreto.
La regla general para la notación de instancias consiste en utilizar el mismo símbolo
geométrico que el descriptor. En la instancia se muestran los posibles valores pero las
propiedades compartidas sólo se ponen de manifiesto en el descriptor. La notación
canónica es un rectángulo con tres compartimientos. En el primero va el nombre del
objeto, en el segundo sus atributos y en el tercero sus operaciones. Este último puede ser
omitido si así se prefiere.

Diagramas de componentes
Un diagrama de componentes muestra la organización 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 el situaremos librerías, tablas archivos, ejecutables y
documentos que formen parte del sistema.
Uno de los usos principales es que puede servir para ver que componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.

Diagramas de despliegue
En el diagrama de despliegue se indica la situación física de los componentes lógicos
desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada Hardware
se representa como un nodo.

Diagramas de Secuencia
En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza
un diagrama para cada llamada a representar. Es imposible representar en un solo
diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un
punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia,
estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al
que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta
línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el
foco del sistema, es decir cuando él esta activo.

Diagrama de Actividades
Un diagrama de actividades es provechoso para entender el comportamiento de alto nivel
de la ejecución de un sistema, sin profundizar en los detalles internos de los mensajes. Los
parámetros de entrada y salida de una acción se pueden mostrar usando las relaciones de
flujo que conectan la acción y un estado de flujo de objeto.

Un grafo de actividades contiene estados de actividad que representa la ejecución de una

secuencia en un procedimiento, o el funcionamiento de una actividad en un flujo de
trabajo Un estado de actividad se representa como una caja con los extremos
redondeados que contiene una descripción de actividad. Las transacciones simples de
terminación se muestran como flechas. Las ramas se muestran como condiciones de
guarda en transiciones o como diamantes con múltiples flechas de salida etiquetadas. Una
división o una unión de control se representan con múltiples flechas que entran o salen de
la barra gruesa de sincronización. Cuando es necesario incluir eventos externos, la
recepción de un evento se puede mostrar como un disparador en una transición, o como
un símbolo especial que denota la espera de una señal.

2.6.3 Diagramas De Estado

Estado De Una Clase

Un diagramas de estado representa la secuencia de estados por los que un objeto o una
interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos
(eventos) recibidos.
La elaboración de un diagrama de estados para que las clases de objetos tengan un
comportamiento dinámico no trivial, deberá mostrar los sucesos enviados y recibidos por
el objeto. Cada rama del flujo de control es representada por un estado con más de una
transición de salida.
Un estado identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto
está esperando alguna operación, tiene cierto estado característico o puede recibir cierto
tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados,
que puede tener tres compartimientos: uno para el nombre, otro para el valor
característico de los atributos del objeto en ese estado y otro para las acciones que se
realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente)