B Uso de modelos para el diseño de programas orientados a objetos

Cada objeto es una instancia de la clase a la que pertenece.

Clase

Una clase es un grupo de objetos con propiedades (atributos) similares,

comportamiento común (operaciones), relaciones comunes entre objetos, y
semántica común (Raumbaugh).

Comunicación por mensajes

Los objetos de un sistema se comunican entre si a través de mensajes. El

mensaje es enviado por un objeto emisor y recibido por un objeto destino o
receptor. Un mensaje invoca una o más operaciones en el objeto receptor.

Principios fundamentales

Abstracción

Encapsulamiento

Mecanismo que permite ocultar los detalles de implementación de un objeto.

Permite empaquetar en una unidad los datos y las funciones que operan
sobre dichos datos.

Herencia

Relación entre clases de objetos que permite incluir (rehusar) los atributos y
operaciones definidas en otra clase más general de la cual se hereda o
deriva.

Polimorfismo

La misma operación es resuelta de diferente forma según el objeto que

recibe el mensaje.

Conceptos Adicionales

Agregación

Composición de un objeto por otros. Es una relación más débil que la que
existe entre el atributo y el objeto al cual pertenece, y más fuerte que una
asociación.
Concurrencia

Propiedad que distingue un objeto activo de otro inactivo. (Booch)

Persistencia

Es la propiedad de un objeto cuya existencia trasciende el tiempo y/o el

espacio (ej. el objeto continua existiendo luego de que su creador deja de
existir / la ubicación de un objeto se mueve a un espacio de direcciones
diferente de aquella donde fue creada).

Visibilidad

capacidad de restringir el acceso a atributos y servicios de un objeto.

Particularmente importante en el diseño e implementación. (ej. C++: público /
protegido / privado)

Modelos utilizados.

Modelo de Estructura de Objetos

El modelo de estructura de Objetos (OSM) es el modelo central. Contiene las

clases de objetos requeridas para construir la aplicación y las relaciones
entre ellas. Se construye a través de un proceso aditivo durante todo el ciclo
de desarrollo del sistema.

Modelo de Secuencias de Transacciones

El modelo de procesos de negocios (BPM) describe los procesos que se

llevan a cabo en la organización. Se lo utiliza para analizar la organización y
comprender sus procesos, parte de los cuales (o todos), serán soportados
por el sistema a desarrollar. El modelo de secuencia de transacciones (TSM)
parte de la especificación de alto nivel del BPM y lo traslada en
requerimientos para la aplicación. El TSM se corresponde conceptualmente
con lo USE-CASEs de Jacobson (OOSE).

Diagramas de Interacción de Objetos

Los diagramas de interacción de objetos muestran las interacciones entre

objetos requeridas para proveer al usuario los servicios descriptos en el
TSM.

Diagramas de Flujo de Actividad

Los diagramas de flujo de actividad son utilizados para analizar y presentar
flujos de actividad complejos en los procesos de negocio y en las
secuencias de transacciones (secuencias, iteraciones, y decisiones).

Modelo de ciclo de vida de objetos

El modelo de ciclo de vida de objetos es utilizado para describir como un

objeto cambia de estados en el tiempo y que eventos producen dichos
cambios de estado.

Modelo global del sistema

El modelo global del sistema es utilizado para dividir el sistema en unidades

de diseño manejables. Es una herramienta para manejar la complejidad de
desarrollo de grandes sistemas. Especifica la interfaces entre las unidades
de diseño.

Modelo de Estructura de Objetos (OSM)

Conceptos y propósito del modelo de estructura de objetos

El OSM es el modelo fundamental que provee un medio uniforme para

modelar el sistema desde la captura de requerimientos en la etapa inicial del
análisis hasta la implementación, atravesando todo el ciclo de desarrollo del
sistema.

Este modelo identifica :

 las clases de objetos en la aplicación

 como las clases de objetos se asocian unas con otras

 como se comunican los objetos

 los detalles de cada clase de objetos, incluyendo atributos y

operaciones

Durante el proceso de análisis y diseño, el OSM es definido en sucesivos

niveles incrementales de detalle, hasta que el nivel necesario para la
implementación es alcanzado.

Todos los demás modelos capturan detalles que alimentan es modelo.

El desarrollo de OSM es un proceso aditivo, diferenciándose esto del
enfoque transformacional característico de otros métodos como el
estructurado, donde los DFD del análisis son transformados en diagramas
de estructura durante el diseño, con los consiguientes problemas que esto
acarrea.

Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo:

 Análisis del Negocio: se reconocen objetos claves del negocio y

generan las abstracciones en las clases apropiadas (objetos entidad).

 Análisis de Requerimientos: se identifican asociaciones estructurales

entre objetos y nuevas clases (entidad).

 Diseño lógico: Se incorporan todas las clases necesarias para la

aplicación incluyendo los objetos de interfaz y de control.

 Diseño Físico: se incorporan todos los detalles remanentes para la

implementación física de cada clase de objetos.

Componentes del modelo de estructura de objetos.

El componente básico del OSM es la clase de objetos.

Se distinguen tres tipos de clases:

 Objetos Entidad

 Objetos de Interfaz

 Objetos de Control.

Para cada clase identificada se describen:

 Operaciones

 Atributos

 Restricciones

Adicionalmente el OSM describe las asociaciones entre objetos o clases de

objetos. Se distinguen los siguientes tipos de asociaciones:
  Relaciones Estáticas

 Herencia

 Agregación

 Comunicación por mensajes

Objetos entidad

Representan algo real o abstracto sobre el cual el sistema necesita

almacenar datos. Representan la memoria esencial del negocio. Los objetos
del negocio (business objects) son normalmente objetos entidad. Ejemplos
de objetos entidad pueden ser empleado, alumno, etc.

Se representan en el diagrama de estructura de objetos con el siguiente

símbolo:

Objetos Interface

Representan lo objetos técnicos requeridos para vincular la aplicación con el

entorno. Representan el vínculo a través del cual el sistema recibe o
suministra datos e información al entorno. Típicamente incluyen interfaces
con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones.

Se representan en el diagrama de estructura de objetos con el siguiente

símbolo:

Objetos de control

Contienen comportamiento que no pertenece naturalmente ni a objetos

entidad ni de interfaz. Son normalmente objetos transitorios, como ser un
controlador de reportes.

Se representan en el diagrama de estructura de objetos con el siguiente

símbolo:

Clases abstractas y concretas

Una clase de la cual pueden generarse instancias particulares (objetos), se

denomina clase concreta.

Una clase abstracta es aquella que no instancias (objetos) propias. Las

clases abstractas son un poderoso mecanismo conceptual para definir
estructuras comunes de atributos, operaciones, y restricciones, reutilizadas
a través de la herencia por múltiples clases concretas.
En el diagrama de estructura de objetos una clase abstracta se representa
con un rectángulo punteado.

Operaciones

Una operación define un servicio ofrecido por un objeto junto con la

información que debe suministrarse cuando es invocado (nombre,
argumentos de entrada/salida).

También puede contener una especificación de método, el cual especifica

una implementación para la operación.

Notación: Durante la etapa de Análisis o Diseño lógico pueden utilizarse

típicamente texto libre o pseudocódigo. Durante el Diseño físico dichas
especificaciones son trasladadas en un lenguaje de programación específico
como ser C++, Java, Visual Basic, etc.

Algunas operaciones pueden asumirse que existen para cada clase de

objetos sin identificarlas formalmente. Estas son llamadas operaciones
implícitas. Las operaciones implícitas más importantes son Crear, Destruir,
Leer, y Actualizar. Una operación implícita debe ser formalmente definida
cuando sus pre y post condiciones no sean triviales.

La identificación y especificación de operaciones es una tarea clave durante

el Diseño Lógico.

Atributos

Son valores de datos asociados a los objetos de una clase al cual describen.

Están fuertemente asociados con la clase de objetos que los contienen, de

tal forma que no tienen existencia independiente o identidad de objeto.

La decisión de cuando un ítem debe considerarse como atributo o como

clase varía de sistema en sistema, dependiendo de su semántica en el
dominio de problema. Lo que en un sistema se modela como atributo en otro
puede modelarse como una clase.

Cada atributo identificado debe ser atómico en el sentido de que debe ser
tratado como una unidad. En tal caso puede ser un valor simple o grupo de
valores tratados siempre como unidad (ej. dirección).

Debe notarse que las clases no se modelan en formas normales. La decisión

sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño
Físico.
Los atributos pueden basarse en definiciones de tipos de atributos, lo cual
provee una definición estándar sobre formato, longitud y dominio de valores
para atributos del mismo tipo.

Restricciones

Las restricciones pueden especificarse sobre los valores que un atributo o

relación pueden tomar.

La implementación de las restricciones puede realizarse de diferentes

formas:

 reglas de validación durante los procesos de entrada de datos (user

inputs)

 database-level triggers

 lógica de control contenida en una o más operaciones.

Relaciones Estáticas

Las relaciones estáticas describen como los objetos se asocian unos con
otros en la misma forma que en el modelo entidad-relación. Identifican así
mismo dependencias entre objetos, cuando un objeto requiere de la
existencia de otro ya sea de la misma clase o de otra.

Las relaciones estáticas se establecen usualmente entre objetos de tipo

Entidad.

Al igual que los atributos, las relaciones modelan información sobre un

objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son
propiedades de un objeto. Los atributos son valores de datos. Las relaciones
son valores que referencian otros objetos.

Una relación estática se representa en el diagrama de estructura de objetos

como una línea sólida entre las clases de objetos, con símbolos de
cardinalidad en sus extremos.

Las relaciones pueden etiquetarse para identificar el propósito de la

asociación. El diseñador puede optar por:

 un nombre para cada dirección de la relación

 un nombre para una dirección de la relación

 un solo nombre que representa ambas direcciones de la relación

  sin nombre

Por cuestiones de simplicidad, las relaciones son modeladas como binarias,

es decir, solo dos clases de objetos, no necesariamente distintas, participan
en la relación.

Es posible que entre el mismo par de clases exista más de una relación.

La cardinalidad identifica el número máximo y mínimo de instancias de una

clase (objetos) que participan en una relación dada, en el mismo sentido que
lo hacen en el modelo entidad-relación.

En el diagrama de estructura de objetos utilizaremos la notación de pata-de-

gallo para especificar cardinalidades, aunque puede utilizarse otras como
ser pares ordenados, flechas (Bachmann), etc.

Pueden observase las siguientes cardinalidades:

Mínimo 1 - Máximo 1.

Mínimo 0 - Máximo 1.

Mínimo 1 - Máximo N.

Mínimo 0 - Máximo N.

Ejemplo:

Herencia

La herencia es el mecanismo a través del cual los atributos, operaciones, y

restricciones definidas para una clase, denominada superclase, pueden ser
heredados (reutilizados) por otras clase denominadas subclases.

La herencia utiliza el principio “es un tipo de ...”.

Una subclase puede redefinir atributos u operaciones heredadas.

Adicionalmente, una subclase puede definir nuevos atributos, operaciones, y
restricciones.

Se distingue entre herencia simple y múltiple. La herencia simple se da

cuando un subclase hereda de una única superclase. En el caso de la
herencia múltiple, una subclase puede heredar de varias superclases. La
decisión de soportar herencia simple o múltiple ha dado lugar a largos
debates conceptuales y metodológicos.
En el actual enfoque, Mainstream Objects de Ed.Yourdon, solo se soporta
Herencia Simple.

En el diagrama de estructura de objetos, la relación de herencia se

representa de la siguiente manera:

Ejemplo

Agregación

La agregación es un tipo de asociación fuerte, donde los objetos de una

clase se componen de objetos de otra(s) clase(s). Se diferencia de las
relaciones estáticas en la fuerza semántica del vínculo. En una relación de
agregación un objeto compone otro. En la relación estática existe un vínculo
pero no una composición.

La agregación es la aplicación del principio “el todo y sus partes ...”.

En el diagrama de estructura de objetos, la relación de agregación se

representa de la siguiente manera:

Ejemplo

Comunicación por mensajes

Las asociaciones por comunicación pueden utilizarse para mostrar que

objetos de una clase se comunican con objetos de otra clase o de la misma.

Una asociación por comunicación corresponde al conjunto de mensajes que

son enviados por los objetos de una clase a los objetos de otra clase o de la
misma.

Típicamente, la asociación por comunicación es la única asociación

existente entre objetos de los tres diferentes tipos.

En el diagrama de estructura de objetos, la asociación por comunicación se

representa de la siguiente manera:

Técnicas Avanzadas de Modelado de Estructura de Objetos

Visibilidad: define que objetos puede acceder y utilizar los atributos y

operaciones de un objeto dado.

Público : todos
Protegido : solo desde el objeto mismo y operaciones definidas en
subclases

Privado : solo desde el objeto mismo

Atributos identificadores: son atributos o grupos de atributos que identifican

unívocamente un objeto de una clase. Se corresponde con el concepto de
claves del modelo E-R.

Atributos derivados: son atributos cuyo valor puede obtenerse a partir de los
valores de otros atributos.

Relaciones derivadas: relaciones transitivas que se derivan de otras

relaciones estáticas.

En el diagrama de estructura de objetos las relaciones derivadas se

representan de la siguiente manera:

Relaciones Ordenadas: los objetos del extremo “muchos” de una relación se

presentan en forma ordenada. Es particularmente útil para especificar que
los objetos componentes de un agregado están ordenados. Por ordenado,
entendemos que los objetos componentes serán accedidos en una
secuencia específica predefinida.

En el diagrama de estructura de objetos las relaciones ordenadas se

representan de la siguiente manera:

Atributos y operaciones de clase: definen el comportamiento de la clase

misma más allá del comportamiento de sus instancias.

Los atributos de clase son utilizados para registrar datos comunes a todos
los objetos (instancias) de una misma clase.

Las operaciones de clase actúan sobre la clase misma como un objeto. El

caso típico son las operaciones Crear y Destruir.

Modelado de Procesos de Negocios y Secuencias de Transacciones.

18.1 Conceptos y propósito del modelo de p. de negocios y sec. de trans.

Los requerimientos para una aplicación de negocios deben basarse en las

actuales actividades del negocio, que la aplicación deberá soportar.

El Modelo de Procesos de Negocios (BPM) es usado durante el análisis del

negocio (análisis del sistema actual) y provee un medio para describir el
negocio.
El Modelo de Secuencia de Transacciones (TSM) es usado durante el análisis
de requerimientos del negocio y provee un medio para describir la funcionalidad
requerida de la aplicaciones para soportar los procesos de negocios.