Apunte OO

Universidad Tecnológica Nacional
Facultad Regional Resistencia
Diseño de Sistemas
Profesor: A.U.S. Gustavo Marcelo Torossi
Análisis y Diseño Universidad Tecnológica Nacional
Orientado a Objetos F.R.R.
MODELADO Y DISEÑO ORIENTADO A OBJETOS
Tabla de contenidos
Unidad 16: Introducción a la Orientación a Objetos ...................................................... 6

16.1 Conceptos fundamentales. ................................................................................. 6
Presentación del método........................................................................................ 6
Beneficios de las técnicas O.O. ............................................................................. 6
Tres enfoques de organización para comprender el mundo.................................... 6
16.2 Concepto de Objeto y Clase. ............................................................................. 7
Objeto................................................................................................................... 7
Clase..................................................................................................................... 7
Comunicación por mensajes.................................................................................. 7
16.3 Principios fundamentales................................................................................... 7
Abstracción........................................................................................................... 7
Encapsulamiento................................................................................................... 7
Herencia ............................................................................................................... 7
Polimorfismo ........................................................................................................ 7
16.4 Conceptos Adicionales ...................................................................................... 8
Agregación ........................................................................................................... 8
Concurrencia......................................................................................................... 8
Persistencia ........................................................................................................... 8
Visibilidad ............................................................................................................ 8
16.5 Modelos utilizados. ........................................................................................... 8
Modelo de Estructura de Objetos .......................................................................... 8
Modelo de Secuencias de Transacciones ............................................................... 8
Diagramas de Interacción de Objetos .................................................................... 8
Diagramas de Flujo de Actividad .......................................................................... 8
Modelo de ciclo de vida de objetos........................................................................ 8
Modelo global del sistema..................................................................................... 9
Unidad 17: Modelo de Estructura de Objetos (OSM) .................................................. 10
17.1 Conceptos y propósito del modelo de estructura de objetos ............................. 10
17.2 Componentes del modelo de estructura de objetos........................................... 10
Objetos entidad ................................................................................................... 11
Objetos Interface................................................................................................. 11
Objetos de control ............................................................................................... 11
Clases abstractas y concretas............................................................................... 11
Operaciones ........................................................................................................ 12
Atributos............................................................................................................. 12
Restricciones....................................................................................................... 13
Relaciones Estáticas............................................................................................ 13
Herencia ............................................................................................................. 14
Ejemplo .......................................................................................................... 15
Agregación ......................................................................................................... 15
Ejemplo .......................................................................................................... 16
Comunicación por mensajes................................................................................ 16
Técnicas Avanzadas de Modelado de Estructura de Objetos................................ 16
Unidad 18: Modelado de Procesos de Negocios y Secuencias de Transacciones.......... 18
18.1 Conceptos y propósito del modelo de p. de negocios y sec. de trans. ............... 18
Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 2 de 61

Proceso de Negocio............................................................................................. 18
Como identificar y definir procesos de negocio? ................................................. 19
Secuencia de Transacciones ................................................................................ 19
Como identificar y definir secuencias de transacciones?...................................... 19
18.2 Componentes y Herramientas de modelado de procesos de negocios y
secuencias de transacciones .................................................................................... 20
18.3 Diagrama de Secuencia de Transacciones (TSD) ............................................. 20
Evento............................................................................................................. 21
Comunicación entre Actor y Sec.Trans................................................................ 21
Secuencia común ............................................................................................ 21
Descripción Textual: componentes...................................................................... 21
3) Camino estándar y alternativo ..................................................................... 21
4) Actores ........................................................................................................... 22
Subdivisión de procesos de negocios................................................................... 22
Unidad 19: Modelado de Interaccion de Objetos ......................................................... 23
19.1 Conceptos y propósito del modelado de interacción de objetos. ...................... 23
Utilización del modelado de interacción de objetos ............................................. 23
19.2 Herramientas de modelado. ............................................................................. 24
Diagrama de interacción de objetos para un proceso de negocios ........................ 24
Diagrama de interacción de objetos para una secuencia de transacciones............. 25
Elementos ....................................................................................................... 25
Casos Especiales ............................................................................................. 26
Diagrama de flujo de actividad............................................................................ 26
Simbología de los diagramas de flujo de actividad .......................................... 27
Observaciones................................................................................................. 28
19.3 Técnicas avanzadas de modelado. ................................................................... 28
Usando AFD para modelar operaciones del sistema ............................................ 28
Diagramas de interacción de objetos, secuencias de transacciones y escenarios... 28
Unidad 20: Modelo de Ciclo de Vida de Objetos ........................................................ 29
20.1 Conceptos y propósito del modelo de ciclo de vida de objetos. ....................... 29
Utilización del modelo de ciclo de vida de objetos .............................................. 29
20.2 Herramientas de modelado. Diagrama de ciclo de vida de objetos. .................. 29
Componentes del OLD........................................................................................ 30
Ejemplo: PILA.................................................................................................... 31
20.3 Técnicas avanzadas de modelado. ................................................................... 31
Unidad 21: Modelo Global del Sistema....................................................................... 32
21.1 Conceptos y propósito del modelo del modelo global del sistema. .................. 32
Conceptos ............................................................................................................... 32
El espacio del problema y sus componentes ........................................................ 32
Definición del alcance de un subsistema ............................................................. 33
Servicios ............................................................................................................. 33
Particiones verticales y horizontales.................................................................... 33
21.2 Diagrama de Modelo Global del Sistema......................................................... 34
Componentes del diagrama ................................................................................. 34
21.3 Conceptos avanzados ...................................................................................... 35
Uso de Clases de Objetos para encapsular subsistemas........................................ 35
Unidad 22: Ciclo de Desarrollo Orientado a Objetos................................................... 36
22.1 Fases del ciclo de desarrollo O.O. ................................................................... 36
22.2 Uso de los distintos modelos. .......................................................................... 37
Análisis del Negocio ........................................................................................... 37

Análisis de Requerimientos................................................................................. 37
Diseño Lógico..................................................................................................... 38
Diseño Físico ...................................................................................................... 38
El rol de las versiones en un proceso de desarrollo aditivo .................................. 39
22.3 Arquitectura de Seis Componentes .................................................................. 39
Unidad 23: Análisis del Negocio................................................................................. 40
23.1 Actividades del Análisis del Negocio .............................................................. 40
23.2 Modelado de Objetos del Negocio................................................................... 40
Pasos en el modelado de objetos de negocio........................................................ 41
Qué modelar?...................................................................................................... 41
23.3 Modelado de Ciclo de Vida de Objetos ........................................................... 41
Cuando modelar ciclos de vida? .......................................................................... 41
Como modelar ciclos de vida de objetos.............................................................. 41
23.4 Modelado de Procesos de Negocio. ................................................................. 42
Pasos del modelado de procesos de negocio ........................................................ 42
Identificación de procesos de negocio ................................................................. 42
Como describir procesos de negocio ................................................................... 42
23.5 Chequeo del modelo de análisis del negocio.................................................... 43
Unidad 24: Análisis de Requerimientos ...................................................................... 44
Actividades del Análisis de Requerimientos........................................................ 44
24.1 Definición de secuencia de transacciones. ....................................................... 45
Identificación de secuencias de transacciones...................................................... 45
Relación entre actores y eventos externos............................................................ 45
Uso de Diagramas de Secuencias de Transacciones............................................. 45
Alcance de una secuencia de transacciones ......................................................... 46
24.2 Descripción de caminos estándar y alternativos ............................................... 46
Identificación y definición de secuencias comunes.............................................. 47
Jerarquías de actores ........................................................................................... 47
Modelando interfaces de usuario e interfaces externas......................................... 47
24.3 Expandiendo el modelo de estructura de objetos.............................................. 47
Pasos en el modelado de estructura de objetos para el análisis de requerimientos 47
Definición de ciclos de vida de objetos................................................................ 48
24.4 Uso de diagramas de modelo global ................................................................ 48
24.4 Chequeo del modelo de análisis de requerimientos .......................................... 48
Unidad 25: Diseño lógico ........................................................................................... 49
25.1 Relaciones entre el diseño lógico y físico ........................................................ 49
25.2 Actividades realizadas durante el diseño lógico ............................................... 49
25.3 Identificación de Objetos de interface y de Control ......................................... 49
Como identificar objetos interfaz ........................................................................ 49
Como identificar objetos de control..................................................................... 50
Asociaciones posibles entre los distintos tipos de objetos .................................... 51
25.4 Identificando y definiendo operaciones ........................................................... 52
Notación de punto............................................................................................... 52
Como identificar operaciones.............................................................................. 52
Método de identificación 1: considerando roles y responsabilidades para cada clase
de objetos............................................................................................................ 53
Método de identificación 2: Interacción de objetos requerida para soportar cada
secuencia de transacciones .................................................................................. 53
Método de identificación 3: Analizando ciclos de vida de objetos ....................... 54
Especificación de la semántica y sintaxis de las operaciones ............................... 54

Operaciones de clase........................................................................................... 55
Herencia de operaciones...................................................................................... 55
Operaciones concretas, abstractas, y templados ............................................... 55
Redefiniendo operaciones heredadas ............................................................... 55
25.5 Redefiniendo el modelo de estructura de objetos ............................................. 55
Adición y remoción de clases de objetos ............................................................. 55
Identificación de Atributos.................................................................................. 56
Definición de persistencia de atributos ................................................................ 56
25.8 Subsistemas .................................................................................................... 56
25.9 Chequeo del modelo de diseño lógico ............................................................. 56
Unidad 26: Diseño Físico............................................................................................ 57
26.1 Arquitectura del sistema. ................................................................................. 57
26.2 Componente Dominio de Problema (PDC) ...................................................... 59
26.3 Componente de Interacción Humana (HIC)..................................................... 59
26.4 Componente de Administración de Datos (DMC)............................................ 59
Arquitectura del DMC......................................................................................... 60
Diseño de base de datos relacional ...................................................................... 60
26.5 Componente de Interface Externa (EIC) .......................................................... 61
26.6 Componente de Administración de Tareas (TMC)........................................... 61
26.7 Componente de Servicios de Utilería (USC).................................................... 61
26.8 Chequeo del modelo de diseño físico............................................................... 61

Unidad 16: Introducción a la Orientación a Objetos
16.1 Conceptos fundamentales.
Presentación del método
MAINSTREAM Combina una síntesis de las principales

OBJECTS técnicas y enfoques O.O.
Rumbaugh / Coad / Yourdon:

- Estructura de Objetos
- Ciclo de Vida
Jacobson
Fuentes - Enfoque Use Case (secuencia de
Principales trans, para capturar requerimientos
del sistema)
R.Wirfs-Brock
- Responsability-Driven model (como
estructurar la funcionalidad de un
sistema O.O
Beneficios de las técnicas O.O.

1) Reusabilidad del software
2) Mayor flexibilidad para realizar mantenimiento y modificaciones del software
3) Disminuye el gap semántico proveyendo una representación consistente en todo el
ciclo de vida
4) Mejor interacción entre el usuario/analista/diseñador.
5) Más apropiado para abordar problemas más complejos.
Tres enfoques de organización para comprender el mundo

1) Diferenciación de la experiencia en Objetos y Atributos

2) Distinción entre el todo y sus partes

3) Formación y distinción de clases de objetos.
16.2 Concepto de Objeto y Clase.
Objeto
Definición 1: Un objeto es algo real o abstracto acerca del cual almacenamos datos y
métodos que manipulan dichos datos (Martín/Odell)
Definición 2: Encapsulado de datos, operaciones que tratan dichos datos, y que observa
un estado interno, que posee identidad (se distingue por su existencia misma y no por
sus atributos).
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.
16.3 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.

16.4 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)
16.5 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 Estructural Modelo de Estructura

(Estático) de Objetos (OSM)
Diagrama de Ciclo de Vida de

Objetos (OLD)
Modelo de Comportamiento
(Dinámico)
Diagrama de Interacción de
Objetos (OID)
Modelo de Procesos de
Negocios (BPM)
Modelo Funcional
Modelo de Secuencia de
Transacciones (TSM)

Unidad 17: Modelo de Estructura de Objetos (OSM)
17.1 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.
17.2 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:
Empleado
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.
Consulta X
Empleado
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.
Control X
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.
Clase Abstracta
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:
Es conducido
Colectivo Chofer
conduce
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:
Superclase
IH
Subclase 1 Subclase 2

Ejemplo
Vehículo
IH
Automóvil Motocicleta
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:
Agregado
Componente 1 Componente 2 Componente 3

Ejemplo
Bicicleta
Cuadro Rueda Manubrio
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:
Emisor Receptor
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:
{ordenado}
A
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.

Unidad 18: 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.
El enfoque en los procesos de negocio durante el análisis del negocio provee el punto de
partida para determinar qué se requiere de la aplicación.
Durante el análisis de requerimientos decidimos qué parte de los procesos de negocio
deben computarizarse y describimos dichos requerimientos usando una o más
secuencias de transacción (determinación de las fronteras de automatización).
Las secuencias de transacciones modelan que es lo que el usuario requiere de la

aplicación (su contenido funcional).
Las secuencias de transacciones proveen la navegabilidad desde lo requerimientos del
usuario a los objetos y operaciones que implementan dicha funcionalidad.
Las secuencias de transacciones proveen también un medio adecuado para comunicarse
con el usuario en un leguaje y nivel de abstracción que él pueda comprender con
facilidad.
Como parte del proceso de Diseño Lógico, las secuencias de transacciones son
analizadas para identificar como los objetos y sus operaciones proveen la funcionalidad
requerida por una secuencia de transacciones.
Posteriormente, durante el proceso de testeo de la aplicación, sirven de base para definir
casos de testeos.
Proceso de Negocio
Un proceso de negocios es una colección de actividades que toman uno o más tipos de
entrada, y crea una salida de valor para el cliente1.
Un proceso de negocios describe desde el comienzo al fin la secuencia de eventos
requeridos para producir un resultado de negocio significativo.
El cliente puede ser externo o interno a la organización.
Los procesos de negocio típicamente atraviesan los límites de la organización y de sus
departamentos internos, evitando la clásica visión de compartimentos estancos. Por este
motivo, cualquier modificación drástica a un proceso de negocio implica un cambio en
la estructura organizacional.
1
Definición según Hammer y Champy

Entradas y/o Eventos
Evento Producto
Proceso de Negocios
Salidas Menores
Como identificar y definir procesos de negocio?

1) Se identifican los productos/servicios significantes de los que es responsable el
negocio y se asocia cada uno de ellos a uno o más procesos de negocios.
2) Se identifican las entradas y eventos disparadores que inician cada proceso de
negocio y se da un nombre a cada PN.
3) Cada PN se describe especificando las actividades de alto nivel que se requieren
para producir los productos y servicios.
Secuencia de Transacciones
El concepto de secuencia de transacciones es muy similar al concepto de Caso de Uso
introducido por Jacobson en su metodología OOSE y de amplia difusión actualmente.
Una secuencia de transacciones es conceptualmente similar a un proceso de negocio. La

diferencia radica en su alcance. El proceso de negocio se utiliza para comprender y
modelar el funcionamiento de la empresa (negocio). Las secuencias de transacciones se
utilizan para modelar los requerimientos funcionales de la aplicación que soportará
determinados procesos de negocios.
Los procesos de negocio son trasladados en secuencias de transacciones durante el
análisis de requerimientos.
El alcance de una secuencia de transacciones es el mismo de un proceso de negocios o
de un subproceso muy significativo.
Una secuencia de transacciones puede implicar más de un usuario y función y puede
extenderse en el tiempo, esto es no tener resolución inmediata.
El proceso de identificar requerimientos del usuario y secuencias de transacciones

puede asistirse con la prototipación de interfaces.
Como identificar y definir secuencias de transacciones?

1) Identificación a través de actores
1.1 Identificar los actores que se comunicarán con el sistema.

1.2 Para cada actor considerar:

1.2.1 Cuales son las principales tareas del actor
1.2.2 Qué accesos (lectura o escritura) requiere el actor del sistema
1.2.3 Cuando el actor informará al sistema acerca de cambios fuera del sistema
1.2.4 Cuando el actor será informado de cambios a través del sistema
2) Identificación a través de eventos

Consiste en identificar a que eventos externos o temporales debe ser capaz de responder
el sistema:
2.1 Confeccionar la lista de eventos.
2.2 Asociar una secuencia de transacciones para cada evento identificada.
18.2 Componentes y Herramientas de modelado de procesos de

negocios y secuencias de transacciones
Para modelar y documentar procesos de negocios y secuencias de transacciones se
utilizan los mismos diagramas y documentos:
1) Diagrama de secuencia de transacciones (TSD)

2) Descripción textual
3) Diagrama de Interacción de Objetos (OID)
4) Diagrama de Flujo de Actividad (AFD)
18.3 Diagrama de Secuencia de Transacciones (TSD)
Actores
Borde del sistema
Secuencia de Transacción o Proceso de Negocio
Nombre

Evento
evento
Comunicación entre Actor y Sec.Trans.
Secuencia común
Nombre Nombre
Común
Descripción Textual: componentes

1) Abstracto: breve descripción del proceso de negocios o secuencia de transacciones.
2) Contexto del Negocio: Especifica

- el resultado de la ST o PN. (productos/servicios)
- el cliente de la ST o PN
- el valor que gana el cliente con la ST o PN
- el evento que inicia la ST o PN
- entradas requeridas por la ST o PN
- descripción de alto nivel de la ST o PN
- requerimientos especiales que controlan la ejecución de la ST o PN
3) Camino estándar y alternativo

Es una descripción secuencial de todas las actividades que deben realizarse para
alcanzar el resultado.
No se describe el proceso de excepciones.
Para una ST describe las actividades de los actores y que debe hacer la aplicación en
orden de servir dichas actividades.
Para un PN describe las actividades de alto nivel del proceso y quién las realiza.

Los caminos alternativos se describen separadamente pero pertenecen a la misma ST o

PN. Describen casos inusuales de procesamiento y manejos de excepciones o errores.
Esta separación se realiza para facilitar el modelado y lectura de los caminos estándar.
Para modelar y diagramar los caminos estándar y alternativos se utilizan los diagramas
de interacción de objetos (OID) y los diagramas de flujo de actividad (AFD).
4) Actores
En el BPM representan los profesionales del negocio y sistemas de computación
involucrados en producir un producto o servicio.
En el TSM representan agentes externos que interactúan con la aplicación. Pueden
representar usuarios humanos o interfaces con otros sistemas.
Cada actor es usado para modelar un rol. Un rol puede ser desempeñando por un
usuario individual o grupo de usuarios.
Subdivisión de procesos de negocios

Los PN pueden ser subdivididos en subprocesos. Las dos formas principales para
realizar esto son:
- Especialización: del PN en distintos tipos que producen el mismo resultado pero
tienen diferentes conjuntos de actividades.
- Particionamiento: del PN a lo largo del eje de tiempo en una secuencia de
subprocesos.

Unidad 19: Modelado de Interaccion de Objetos
19.1 Conceptos y propósito del modelado de interacción de objetos.

Objetivo: El modelo de interacción de objetos modela la manera en que colaboran los
objetos de un sistema para proveer la funcionalidad descrita en una secuencia de
transacciones.
Su utilidad primaria se da durante la etapa de diseño lógico.
Interacción de Objetos: se produce cuando un objeto envía un mensaje a otro con el

objetivo de utilizar (requerir) la funcionalidad de la operación invocada por el objeto
receptor del mensaje.
El modelo de interacción de objetos provee el enlace las descripciones de las secuencias

de transacciones y las especificaciones de operaciones elementales a nivel de objetos.
Asisten en la identificación de clases de objetos y operaciones requeridas, considerando

como una determinada funcionalidad debe distribuirse en operaciones de diferentes
clases de objetos (responsabilidades de objetos), y como los objetos deben colaborar
para proveer la funcionalidad descrita en las secuencias de transacciones.
La herramienta de modelado fundamental para el modelado de interacción de objetos es

el diagrama de interacción de objetos (OID). Normalmente se usa un OID para cada
secuencia de transacciones concentrándose en el camino estándar.
Utilización del modelado de interacción de objetos

- Modelado de Procesos de Negocios: es una técnica adicional que puede utilizarse
para comprender un proceso de negocios en particular. Se considera al sistema como
una “caja negra”. Se lo representa como un actor (interface de máquina).
- Análisis de Requerimientos: No es muy utilizado. El propósito de esta etapa es

definir requerimientos, no diseñar.
- Diseño lógico: Se utiliza un OID para cada secuencia de transacciones definida en el

análisis de requerimientos, para determinar con claridad que clases, operaciones y
responsabilidades se necesitan. Se mira dentro de la “caja negra” (tal como se la ve
en el modelo de proceso de negocio) y se determina que objetos participan para
implementar la funcionalidad requerida del sistema.

19.2 Herramientas de modelado.
Diagrama de interacción de objetos para un proceso de negocios
Actores
Actor 1 Actor 2 Actor 3 Sistema
Evento 1
Evento 2
1 Evento 3
Requeri
Evento 4 mientos.
2
Evento 5 Barras: representan a los
objetos de la cabecera.
Links con actividades

de un diagrama de
flujo de actividades.
Elementos:
1) Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos
como cajas negras.
2) Una línea vertical asociada a cada actor.
3) Requerimientos o eventos enviados por un actor a otro. Se representan por flechas.
Se utilizada una sola flecha para representar el estímulo y la respuestra implícita.
4) Etiquetas en el márgen izquierdo representando links a actividades de un diagrama
de flujo de actividades.

Diagrama de interacción de objetos para una secuencia de transacciones
Objetos
Objeto 1 Objeto 2 Objeto 3 Objeto 4 Objeto 5
Sec.Trans.
Descrip
1 narrativa
de la S.T. Operaciones
3 Mensajes enviados por y hacia los

actores externos al sistema
Límites del sistema
Elementos
1) Barra vertical a la izquierda representa el límite del sistema.
2) Se acompaña con la descripción narrativa de la secuencia de transacciones a la
izquierda.
3) Una flecha proveniente desde el límite representa un requerimiento externo
generado por un actor. Es conveniente que los requerimientos / respuestas de este
tipo se representen por flechas individuales.
4) Operaciones: se representan por rectángulos alargados sobre los ejes
correspondientes a los objetos que las realizan. Permite visualizar que mensajes
dispara una operación. La longitud de la barra no representa duración.
5) Actividades: bloques de eventos que siempre ocurren en una determinada secuencia.
Dichas actividades que pueden ocurrir en paralelo, condicional, o iterativamente,
pueden modelarse con un diagrama de flujo de actividad asociado.

Casos Especiales
1) Invocación de Operaciones “in-self”
A menudo una operación de un objeto invoca a otra operación de la misma clase. Esto
puede representarse de la siguiente forma:
2) Múltiples objetos de una misma clase

Se representa la clase más de una vez.
3) Secuencias comunes
Usualmente se dibujan diagramas por separado para las secuencias comunes y su
invocación se representa con una flecha punteada.
Diagrama de flujo de actividad.

Los OID no muestran decisiones, iteraciones, o la posibilidad de que partes del
procesamiento puedan realizarse en secuencias aleatorias o concurrentemente. Una
manera de describir esto es con descripciones textuales en el margen izquierdo del OID,
o utilizando diagramas de flujo de actividad (AFD). Los AFD son un tipo particular de
los clásicos flowcharts.
Actividad: es una secuencia de interacciones entre objetos

El alcance de una actividad queda normalmente definido por el hecho de que una
secuencia de interacciones dada es condicional, iterativa, o pueda ocurrir antes o
después de otras secuencias de interacciones.
Simbología de los diagramas de flujo de actividad
n. Nombre Actividad. El número n provee un vínculo con

de Actividad el OID asociado.
Flujo entre una actividad y la siguiente.
División del flujo de actividades que pueden

ocurrir en paralelo, o en una secuencia
aleatoria.
Decisión: división del flujo de actividades

según una condición.
Sincronización.
Iteración
Terminación (fin).

Observaciones
- Una AFD puede incluir actividades que no estén en un camino estándar pero que
aparezcan en un camino alternativo.
- Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar
la lógica del flujo.
- Puede utilizarse un AFD sin OID asociado simplemente para describir la lógica del
flujo en un camino estándar/alternativo.
19.3 Técnicas avanzadas de modelado.

Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es
posible más de un OID por secuencia de transacciones y se describen a continuación dos
enfoques alternativos:
Usando AFD para modelar operaciones del sistema

Los AFD pueden ser utilizados en combinación con los OID. En un AFD cada bloque
normalmente representa un grupo de eventos que ocurren siempre en la misma
secuencia. Otra opción es mostrar un bloque en un AFD para representar cada posible
estímulo externo para una secuencia de transacciones. Tal estímulo externo (u operación
del sistema) puede ocurrir a menudo en secuencias aleatorias o en secuencias
alternativas. Un OID puede desarrollarse para cada uno de tales bloques u operaciones
del sistema.
Sin embargo se recomienda utilizar un OID simple para toda la secuencia de
transacciones siempre que sea posible, debido a que esto brinda una visión general para
todo el proceso requerido.
Diagramas de interacción de objetos, secuencias de transacciones y escenarios

Generalmente se desarrolla un solo OID por cada secuencia de transacciones. Este
diagrama muestra un caso general omitiendo caminos alternativos inusuales. No
muestra un escenario de ejecución que pueda ocurrir en una ocasión específica. En
casos complicados, puede ser útil desarrollar OIDs alternativos representando los
caminos alternativos típicos.

Unidad 20: Modelo de Ciclo de Vida de Objetos
20.1 Conceptos y propósito del modelo de ciclo de vida de objetos.

El modelo de ciclo de vida de objetos se utiliza para describir los aspectos dinámicos de
los objetos.
El modelo de ciclo de vida de objetos modela lo que ocurre dentro de los objetos de una
clase: estados, cambios de estado, y eventos que producen dichos cambios de estado.
El estado de un objeto de una clase está dado por el conjunto de valores de sus atributos
en un instante dado de tiempo.
Durante su ciclo de vida, desde que son creados hasta que son destruidos, los objetos
atraviesan por diferentes estados.
La importancia de estudiar el ciclo de vida de los objetos y de sus estados, se debe a que
muchos objetos exhiben comportamientos estado-dependientes.
Es especialmente importante reconocer comportamientos de objetos que son

dependientes del tiempo y del estado previo, ya que pueden agregar una complejidad
considerable a la aplicación.
Ciertas operaciones y/o atributos pueden ser válidos solo en ciertos estados.
Sólo deben modelarse los estados de un objeto que son relevantes al dominio de
problema que se está modelando.
Las transiciones de estados de un objeto son causadas por la recepción de un evento

interno o externo al sistema.
El estado que asume un objeto luego de recibir un evento depende del estado actual, del
evento recibido, y opcionalmente del valor de una condición de guarda.
Cuando un objeto recibe un evento ejecuta una acción (que corresponde con una
operación) asociada con una transición.
Al fin o durante la ejecución de dicha acción, el objeto produce el cambio de estado.
Puede darse que el estado final sea el mismo que el inicial.
Utilización del modelo de ciclo de vida de objetos

Siempre que se agrega una nueva clase al OSM es importante examinar se la misma
presenta estados significantes para los objetos de la misma. Si es así puede utilizarse el
modelo de ciclo de vida en orden de comprender correctamente el ciclo de vida de
dichos objetos.
El modelo de ciclo de vida es útil en las etapas de análisis del negocio y de
requerimientos para obtener una clara comprensión del ciclo de vida de los objetos
claves descubiertos y de los caminos estándar y alternativos involucrados.
20.2 Herramientas de modelado. Diagrama de ciclo de vida de objetos.

La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de
ciclo de vida de objetos (OLD). Un OLD se aplica solo a una clase de objetos.

El OLD representa:
- como los objetos son creados
- como los objetos son destruidos
- como los objetos cambian a través del tiempo
- que estados típicamente asume un objeto
- que eventos causan cambios de estado
- que acciones realiza un objeto cuando recibe un evento que produce un cambio de
estado.
Componentes del OLD
Punto de entrada: Instante previo a la creación de un

objeto.
Punto de salida: momento en el que deja de existir un

objeto.
Estado: Conjunto de valores de los atributos de un objeto

en un instante de tiempo.
Transición o cambio de estado

Evento [condición de guarda]
Acción

Ejemplo: PILA
20.3 Técnicas avanzadas de modelado.

Unidad 21: Modelo Global del Sistema
21.1 Conceptos y propósito del modelo del modelo global del sistema.
El modelo global del sistema posibilita tener una visión general del modelo de
estructura de objetos del sistema, asistiendo en el manejo de la complejidad.
Las principales razones para utilizar un modelo global del sistema son:
- Posibilita el particionamiento de una tarea de análisis o desarrollo. Para grandes
sistemas, subsistemas pueden ser asignados a diferentes equipos o subproyectos.
- Puede utilizarse para definir unidades de entrega, p.e., unidades funcionales
(módulos) que deban entregarse al usuario en sucesivas fechas de liberación, o
componentes de producto.
- Puede utilizarse para definir unidades distribuibles.
- Puede utilizarse para validar el diseño de un sistema y asegurar que está bien
diseñado para soportar el cambio.
- Incluye un diagrama (el diagrama de visión general del sistema) que puede utilizarse
para producir una visión general de un modelo del análisis o de un subsistema,
asistiendo con la presentación de un modelo o subsistema a un nivel de visión
general.
Una característica importante del modelo global es que permite el modelado de

interfaces entre subsistemas. Esto se logra modelando los servicios que un subsistema
ofrece para ser utilizados por otro subsistema.
Conceptos
El modelo global implica la subdivisión del espacio de problema en componentes. En
un enfoque de desarrollo orientado a objetos, esto se alcanza agrupando clases de
objetos. El modelado orientado a objetos difiere aquí de las técnicas estructuradas, en
que en estas, los subsistemas usualmente agrupan funciones, no objetos.
Las secuencias de transacciones no necesariamente residen en un único subsistema.

Pueden requerir el soporte de objetos pertenecientes a más de un subsistema o
componente.
El espacio del problema y sus componentes

Durante la etapa de análisis del negocio, el espacio del problema es el dominio del
negocio, y podemos optar por dividir dicho dominio en áreas sujetos. Cada área sujeto
contiene clases de objetos semánticamente relacionadas unas a otras, vinculadas con el
mismo sujeto.
Durante el desarrollo, el espacio del problema es el sistema o subsistema que se

construye. Esto también puede ser subdividido en submodelos o subsistemas.
Los submodelos son utilizados principalmente con propósitos de presentación.
Los subsistemas son definidos por razones técnicas como ser: definición de unidades de
distribución, y definición de módulos, importante para validar y preservar la
mantenibilidad del sistema.

Otro uso del particionamiento es la subdivisión arquitectural, la cual es particularmente

importante durante el diseño físico. Se recomienda la división de todo sistema en seis
subsistemas arquitecturales:
• El componente dominio de problema: es el más importante y en el cual nos
concentramos durante el análisis de requerimientos y el diseño lógico.
• El componente de interfaz humana: introducido en el diseño lógico.
• El componente de interfaz externa: introducido durante el diseño lógico.
• El componente de administración de datos: introducido durante el diseño físico.
• El componente de administración de tareas: introducido durante el diseño físico.
• El componente de servicio de utilidades: introducido durante el diseño físico.
Definición del alcance de un subsistema

Básicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven
a un propósito común, deben asignarse al mismo subsistema.
Usualmente, jerarquías de herencia y agregación, deben ser asignadas completamente a
un subsistema.
Debe notarse que si existen objetos que son requeridos por diferentes subsistemas,
entonces dichos objetos no deben asignarse a un subsistema.
Servicios
Un subsistema provee sus servicios vía una interface, la cual es un conjunto de
operaciones que los clientes de un subsistema pueden utilizar.
Es útil estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas
que tienen un propósito común, por ejemplo, dibujar figuras, manejo de e-mail, etc.
Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse

determinando que comunicaciones son posibles entre subsistemas, y agrupar estas en
servicios. Es conveniente que esto se realice durante el diseño lógico, cuando las
operaciones han sido definidas.
Los subsistemas pueden vincularse en relaciones cliente-servidor o compañero-a-

compañero. En este último caso, un subsistema puede ser cliente y servidor a la vez.
Particiones verticales y horizontales

Un sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las
particiones verticales son usadas para subdividir la funcionalidad de la aplicación,
mientras que las particiones horizontales son particularmente útiles para aislar las
aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases
de datos o hardware. Este enfoque por capas (layers) asegura la portabilidad de una
aplicación.

En el siguiente ejemplo el dominio de problema se divide en cuatro particiones

verticales. El componente de administración de datos es una partición horizontal, la cual
existe para aislar a la aplicación del software de base de datos utilizada.
Subsiste Subsiste Subsiste Subsiste

ma de ma de ma de ma de
reportes seminari registrac memos
Componenteode Administración
ión de Datos
21.2 Diagrama de Modelo Global del Sistema
Componentes del diagrama
Actor: personas que interactúan con el subsistema o interfaces con otros subsistemas.
Bordes del sistema: se representan con un rectángulo en línea gruesa. Los actores se
dibujan fuera del rectángulo, y los subsistemas dentro.
Subsistema: se representan con un rectángulo redondeado.
Servicios: se representan como semicírculos dentro del rectángulo correspondiente al

subsistema.

Actor usando un servicio: se representa como una flecha que vincula al actor con el
servicio que usa.
21.3 Conceptos avanzados
Uso de Clases de Objetos para encapsular subsistemas

Es posible encapsular la funcionalidad de un sistema utilizando object wrapper
(envoltura). Esto puede ser muy útil para permitir la utilización de un sistema no
orientado a objetos desde un sistema orientado a objetos. Esto se realiza definiendo un
objeto interface el cual puede llamarse para invocar las funciones provistas por el
sistema encapsulado. Solo dicho objeto interface necesita conocer el funcionamiento
interno del sistema que encapsula.
También es posible utilizar una clase de objetos para encapsular el acceso a un sistema
orientado a objetos. Si no se utiliza esto, todos los mensajes provenientes del exterior
del subsistema, deben dirigirse directamente a la clase de objetos correspondiente dentro
del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del
subsistema, deban conocer la estructura interna del mismo.
Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es
posible definir una interfaz sencilla para los clientes externos.

Unidad 22: Ciclo de Desarrollo Orientado a Objetos

En los capítulos anteriores se introdujeron los conceptos fundamentales del paradigma
de orientación a objetos, como así también los modelos fundamentales que se utilizarán
en la presente metodología de OOAD.
En los próximos capítulos se examinará el proceso de desarrollo orientado a objetos, es
decir que actividades deben llevarse a cabo, que tareas deben realizarse, y que
entregables deben producirse en cada etapa.
En esta unidad se realiza una presentación a nivel general que se desarrolla en detalle en
las unidades siguientes.
22.1 Fases del ciclo de desarrollo O.O.

Este enfoque un ciclo de vida tradicional compuesto por las siguientes etapas:
• Definición del proyecto y planificación: aquí es donde se define el alcance y límites

del proyecto. Se realizan los estudios de factibilidad y relaciones costo/beneficio.
• Análisis
- Análisis del Negocio: aquí es donde se modela el negocio o parte del mismo en
orden de comprender la naturaleza del mismo, como se realizan actualmente las
actividades, y como los usuarios desean que se realicen en el futuro. Provee una
comprensión preliminar de áreas específicas del negocio a ser informatizadas.
Esta etapa también es conocida como estudio del sistema actual en otras
metologías.
- Análisis de requerimientos del sistema: aquí es donde se establece con claridad

las capacidades requeridas para el nuevo sistema a ser desarrollado. Estas
capacidades son documentadas de modo tal que los desarrolladores tengan una
especificación clara sobre la que trabajar y para validar los resultados obtenidos.
• Diseño
- Diseño Lógico: aquí es donde los desarrolladores del sistema identifican los
componentes de software/hardware necesarios para satisfacer los
requerimientos, como así también especifican las relaciones arquitecturales entre
dichos componentes. El diseño lógico debe evitar detalles técnicos específicos
requeridos para mapear el diseño en un entorno de implementación específico.
- Diseño Físico: aquí es donde se toman decisiones técnicas considerando

arquitecturas de hardware específicas, sistemas de bases de datos, lenguajes de
programación, utilización de paquetes de middleware o paquetes GUI, etc. Aquí
también se toman decisiones con respecto a características de implementación
como ser arquitectura cliente/servidor, distribución de objetos, etc.
• Construcción

- Desarrollo: aquí es donde un diseño físico es implementado en un lenguaje de

programación, o entorno específico de desarrollo.
- Prueba: se realizan testes del software para validar su correcto funcionamiento y

detectar fallas que deban ser depuradas.
- Documentación: desarrollo de documentación técnica sobre la aplicación,

manuales de usuario, manuales de procedimiento, etc.
• Aprobación
• Operación y Mantenimiento
22.2 Uso de los distintos modelos.

A continuación se sumariza el uso de los distintos modelos en las diferentes etapas del
ciclo de desarrollo:
Análisis del Negocio

• Modelo de Estructura de Objetos: es utilizado para identificar y modelar los objetos
del dominio del negocio (objetos entidad). Preguntas fundamentales son: “Qué
objetos necesitamos en orden de realizar los procesos de negocio identificados?”,
“Qué deben conocer estos objetos, y que deben ser capaces de realizar?”, “Cómo
interactúan estos objetos entre si?”.
• Modelo de procesos de negocios y secuencias de transacciones: pueden utilizarse

para describir los procesos del negocio en una forma compatible con la descripción
de secuencias de transacciones de la siguiente fase de análisis de requerimientos.
• Modelo de Ciclo de Vida de Objetos: pueden proveer una mayor comprensión sobre
el comportamiento dinámico de los objetos del negocio, durante su vida. Su
utilización dependerá de la complejidad de los objetos del negocio en estudio, y en
algunos casos puede ser innecesaria su utilización.
Análisis de Requerimientos
• Modelo de estructura de Objetos: contiene únicamente objetos entidad, y se agrega
mayor detalle al modelo describiendo relaciones, herencia, agregación, atributos y
restricciones aplicables a las clases de objeto entidad identificados.
• Secuencias de Transacción: son utilizadas para describir la funcionalidad esperada

del sistema.

• Modelo de Ciclo de Vida de Objetos: se utiliza para aquellos objetos con ciclos de
vida complejos.
• Modelo Global del Sistema: es utilizado para sistemas grandes cuando se necesite
particionar en subsistemas.
Diseño Lógico
• Secuencias de Transacciones: definidas en la etapa anterior, son examinadas aquí
para determinar objetos interfaz y de control donde es apropiado.
• Diagramas de Interacción de Objetos: se dibuja uno por cada secuencia de

transacción describiendo eventos e interacciones entre objetos necesarios para
soportar la secuencia de transacción.
• Operaciones: son definidas con descripciones informales de su comportamiento.
• Diagramas de Ciclo de Vida: son creados y extendidos donde sean necesarios.
• Modelo Global: se definen subsistemas y se dibujan diagramas globales donde sea

requerido con propósitos organizacionales, manejo de complejidad, y presentación.
Diseño Físico
Durante la etapa de diseño físico se llevan a cabo las siguientes actividades:
• El entorno para el sistema debe ser determinado, y las decisiones tomadas
inicialmente deben finalizarse. Esto incluye determinación de lenguaje de
programación, sistema operativo, Dbms, s.o. de red, hardware, tipo de interface de
usuario, librerías de clases, frameworks, y patrones de diseño.
• La administración de tareas y distribución de objetos/funciones debe finalizarse.
• La definición de tipos de atributos debe finalizarse.
• Se implementan las relaciones (p.e. en forma de punteros)
• Decisiones relativas a implementación de restricciones debe finalizar, dependiendo

del lenguaje de programación, GUI-builder, y/o Dbms utilizados.
• Debe finalizarse la interface de usuario.
• Deben tomarse decisiones sobre el manejo de persistencia de objetos, involucrando

posiblemente un mapeo entre objetos y Dbms relacionales. Esto puede implicar la
implementación de una “capa de acceso” en el sistema, o bien puede manejarse con
un producto comercial.
• Se desarrollan objects wrappers para todos los componentes no orientados a objetos

que serán utilizados por la aplicación.

• Se realiza la codificación de todas las operaciones que deban realizarse.
El rol de las versiones en un proceso de desarrollo aditivo

El proceso de OOAD descripto aquí es aditivo, esto significa que los resultados de cada
fase son utilizados como entrada para la siguiente fase, donde se realizan
actualizaciones y extensiones. Esto contrasta con otros enfoques como el estructurado
que es carácter transformacional, donde los DFD del análisis son transformados en
Diagramas de Estructura durante el diseño.
Debido a esta naturaleza aditiva del proceso, es técnicamente innecesario retener

versiones de resultados de las primeras fases del desarrollo. Sin embargo muchas veces
por cuestiones contractuales u organizacionales se retienen copias de los modelos del
análisis de requerimientos. A menudo, este modelo representa un contrato entre los
usuarios y los desarrolladores. El modelo se retiene en orden de proveer un mecanismo
para validar que el sistema entregado cumple con las especificaciones iniciales.
22.3 Arquitectura de Seis Componentes

Como se ha mencionado, es útil y común dividir sistemas grandes y complejos en
subsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de
cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son
específicamente relevantes durante la fase de diseño físico de la aplicación.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente
arquitectura de seis componentes:
Análisis
(del Negocio y Requerimientos) PDC
Diseño Lógico PDC EIC

HIC
TMC
Diseño Físico USC HIC PDC EIC DMC
Clases de Objetos
• Componente Dominio de Problema (PDC)

• Componente de Interacción Humana (HIC)
• Componente de Interfaces Externas (EIC)
• Componente de Administración de Datos (DMC)
• Componente de Administración de Tareas (TMC)
• Componente de Servicio de Utilidades (USC)

En la unidad de Diseño Físico se discuten en detalle cada uno de estos componentes.
Unidad 23: Análisis del Negocio

El análisis del negocio es utilizado para modelar parte o toda la empresa, en orden de
comprender la naturaleza del negocio y como se llevan a cabo sus procesos.
El análisis del negocio se concentra en dos aspectos:

• Modelado de lo Objetos que soportan el negocio (business objects)
• Modelado de los Procesos del Negocio (business processes)
23.1 Actividades del Análisis del Negocio

Las siguientes actividades son llevadas a cabo durante el análisis del negocio:
• Identificación de los Objetos del Negocio. Son los objetos más importante del tipo
entidad. Otros objetos entidad adicionales son agregados durante el análisis de
requerimientos y durante el diseño lógico.
• Modelado del ciclo de vida para cada objeto del negocio que tenga un ciclo de vida
complejo relevante al problema a manejar.
• Modelado de los procesos de negocio. Implica la identificación de los procesos de

negocio y la obtención de una comprensión de alto nivel de los flujos de trabajo
(workflows: secuencias de actividades y eventos) de dichos procesos, y de los
agentes (humanos o máquinas) que interactúan para alcanzar un resultado
significativo.
• Chequeo de consistencia y validación del modelo producido.
El alcance del análisis del negocio (dominio del negocio o dominio del problema)
normalmente se determina durante la fase de definición del proyecto.
23.2 Modelado de Objetos del Negocio

El modelado de objetos del negocio es la primera definición del modelo de estructura de
objetos para la aplicación.
El modelado de objetos puede realizarse en simultáneo con el modelado de procesos de
negocios. Sin embargo se recomienda comenzar modelando los objetos ya que son la
esencia de este enfoque.
El modelo de estructura de objetos producido en esta fase será extendido en fases

subsiguientes. Sin embargo es muy similar al de la fase de análisis de requerimientos.
Las principales diferencias residen en:
• El alcance de los objetos del negocio suele ser mayor, pues puede involucrar objetos
de negocio que no son relevante al sistema computarizado.

• El modelo de objetos del negocio suele ser menos detallado. Usualmente solo
objetos del la realidad son modelados. Durante el análisis de requerimientos, objetos
menos obvios (p.e. clases que representan eventos) son identificados.
• En el análisis del negocio, el modelo contiene los objetos del negocio, sus
principales atributos y relaciones estáticas relevantes. Durante el análisis de
requerimientos, pueden agregarse objetos entidad adicionales, con un conjunto de
atributos más detallado y las operaciones básicas para los objetos del modelo.
• La definición de jerarquías de herencia y estructuras de agregación se difieren hasta
el análisis de requerimientos.
Pasos en el modelado de objetos de negocio

El modelado de objetos de negocio incluye los siguientes pasos:
1. Determinar objetos del negocio candidatos
2. Abstraer los objetos candidatos en clases y definir el propósito de cada clase de
objetos.
3. Determinar las relaciones estáticas entre los objetos del negocio.
4. Nominar dichas relaciones y asignar cardinalidades.
Qué modelar?
Los objetos pueden ser identificados respondiendo la pregunta: “Qué cosas (reales o
abstractas) considera la empresa y sobre la que guarda datos?”.
El énfasis en esta etapa es identificar objetos de la realidad (personas, lugares, cosas o
eventos) que están dentro del dominio del negocio.
23.3 Modelado de Ciclo de Vida de Objetos

El principal propósito del modelado de ciclo de vida de objetos es asistir en la
comprensión de objetos con ciclos de vida complejos.
Es importante reconocer cualquier comportamiento del objeto que sea dependiente del
tiempo y del estado del mismo, ya que esto agrega complejidad a la aplicación.
El uso de diagramas de ciclo de vida facilita la comprensión y comunicación con

usuarios.
Cuando modelar ciclos de vida?

Debe dibujarse diagramas de ciclos de vida solo para objetos que poseen
comportamientos dependientes del tiempo y de su estado interno. Para determinar esto,
debe tomarse cada clase de objetos y analizarla por separado. Deben identificarse los
eventos que pueden afectar a un objeto de la clase y determinar si la reacción a dichos
eventos puede variar según el estado interno del objeto.
Como modelar ciclos de vida de objetos

El modelado de ciclos de vida incluye los siguientes pasos:
1. Determinar cuando debe modelarse el ciclo de vida para una clase de objetos, según
lo expuesto en el punto anterior.
2. Identificar el primer estado del objeto.

3. Identificar que evento lleva a un objeto a su estado inicial (usualmente la creación

del mismo).
4. Identificar los eventos que pueden causar transiciones de estado desde el primer
estado, y a que otros estados puede cambiar el objeto. Identificar que actividades se
llevan a cabo durante la transición de estado.
5. Identificar el estado final del objeto.
Básicamente el alcance del modelado de ciclo de vida de objetos es el mismo para la

actividad de análisis del negocio como para el análisis de requerimientos.
23.4 Modelado de Procesos de Negocio.

El modelado de procesos de negocio es usado para comprender y documentar las
actividades de alto nivel realizadas por los profesionales del negocio para alcanzar los
objetivos del dominio del negocio.
Esta comprensión de alto nivel de cómo trabaja la empresa es necesaria como un paso
preliminar para asegurar que las parte del negocio afectada por la aplicación en
desarrollo es comprendida antes de que el análisis de requerimientos sea llevada a cabo.
Pasos del modelado de procesos de negocio

1. Identificar los procesos de negocio.
2. Subdivisión de los procesos de negocio. Los procesos de negocio pueden
subdividirse identificando especializaciones o particionándolos a lo largo del tiempo
en subprocesos.
3. Descripción de los procesos de negocio. La descripción de un proceso de negocio
implica la descripción de la naturaleza del mismo como de las actividades que lo
constituyen.
Identificación de procesos de negocio

Los procesos de negocio pueden identificarse de dos maneras:
1. Considerar Quién es el Cliente, y Qué productos o servicios requiere. Verificar que
dichos productos/servicios sean de valor para el cliente. La producción de dichos
productos/servicios implicarán uno o más procesos de negocio.
2. Considerar que eventos la empresa debe ser capaz de tratar, y que procesos implican
el tratamiento de dichos eventos.
Como describir procesos de negocio

Los siguientes mecanismos pueden utilizarse para describir procesos de negocio:
1. Una identificación del evento inicial y del producto(s) o servicio(s) del proceso de
negocios.
2. Una descripción textual de las actividades involucradas en el proceso de negocio.
3. Una descripción de la secuencia de interacciones entre agentes (humanos o
máquinas) que es requerida para producir el producto/servicio requerido. Para esta
descripción pueden utilizarse diagramas de interacción de objetos.
4. Una descripción de los caminos de ejecución involucrados en el proceso, mostrando
los puntos en los cuales se inician dichos caminos: alternativos, actividades
paralelas, e iteraciones. Para esto se pueden utilizar diagramas de flujo de actividad.

23.5 Chequeo del modelo de análisis del negocio.

Unidad 24: Análisis de Requerimientos

El proceso de análisis de requerimientos debe producir una definición clara de los
requerimientos para el nuevo sistema desde la cual puedan trabajar los desarrolladores y
contra la cual puedan validarse los resultados.
Durante el análisis del negocio se producen un modelo de la forma en que actualmente
funciona la empresa. Durante el análisis de requerimientos, se modela cómo la empresa
operará utilizando el nuevo sistema.
Un objetivo adicional del análisis de requerimientos es proveer a los profesionales del

negocio de la oportunidad de cambiar la manera en que actualmente funciona la
empresa.
El punto de arranque el análisis de requerimientos depende del contexto en el cual una

aplicación es desarrollada. Cuando el dominio del negocio para la aplicación es pequeño
y bien comprendido, entonces la fase de análisis del negocio es muy breve. El análisis
de requerimientos parte de los modelos del análisis del negocio que contienen muy poco
detalle. En este caso es casi como partir desde cero
Cuando se ha realizado un análisis del negocio extenso, entonces los modelos obtenidos
constituyen la base sobre la cual se continua trabajando realizando los agregados y
extensiones pertinentes.
Actividades del Análisis de Requerimientos

Durante el análisis de requerimientos se llevan a cabo las siguientes actividades:
1. Definición de secuencias de transacciones basadas en los procesos de negocio.
2. Expansión o definición del modelo de estructura de objetos para objetos entidad.
3. Dibujo de diagramas de ciclo de vida para objetos entidad.
4. Particionamiento del espacio de problema.
El proceso de producción de la especificación de requerimientos comprende dos

corrientes principales:
- El análisis de la funcionalidad requerida del nuevo sistema. Esto se documenta
utilizando secuencias de transacción.
- El análisis de la estructura de objetos entidad para soportar dicha funcionalidad.
Esto es documentado utilizando el modelo de objetos.
Estas dos actividades pueden realizarse en paralelo, y no existe un criterio estricto sobre
que modelo debe desarrollarse antes.
Para sistemas “intensivos en datos”, el modelado de las relaciones de objetos y atributos
es particularmente importante.
Para sistemas “algorítmicamente intensivos” o en proyectos de reingeniería de negocios,
el modelado de la funcionalidad, representado por secuencias de transacción en
combinación con un modelo de objetos, puede ser más importante.

24.1 Definición de secuencia de transacciones.

El modelado de secuencias de transacciones incluye los siguientes pasos:
1. Identificación de las secuencias de transacciones requeridas.
2. Definición del contexto del negocio.
3. Descripción del camino estándar.
4. Descripción de caminos alternativos.
Identificación de secuencias de transacciones

Identificación a través de actores
• Identificar los actores que se comunicarán con el sistema. Los actores pueden ser
personas humanas o interfaces con otros sistemas.
• Para cada actor identificado considerar que es lo que actor realizará con el sistema,
utilizando secuencias de transacciones para describir esto. Tal como lo sugiere
Jacobson es útil considerar:
- Cuales son las principales tareas del actor
- Qué accesos (lectura o escritura) requiere el actor del sistema
- Cuando el actor informará al sistema acerca de cambios fuera del sistema
- Cuando el actor será informado de cambios a través del sistema
Identificación a través de eventos

Consiste en identificar a que eventos externos o temporales debe ser capaz de responder
el sistema. Para ello se siguen los siguientes pasos:
• Confeccionar la lista de eventos. Cada evento externo al cual el sistema debe
responder es listado, incluyendo eventos temporales.
• Asociar una secuencia de transacciones para cada evento identificado. Inicialmente
se asocia una secuencia de transacción por cada evento. Puede haber más de una
respuesta para un evento. En tal caso se requiere una secuencia de transacciones
para cada respuesta.
Relación entre actores y eventos externos

El enfoque de particionamiento por eventos describe eventos del negocio los cuales se
originan a menudo fuera de la compañía. El generador de dichos eventos, a menudo no
se comunica en forma directa con el sistema, sino que lo hace a través de un actor que
hace de agente o intermediario. Por lo tanto, el actor que inicia una secuencia de
transacciones lo hace en respuesta a un evento, no es él quién lo origina.
Sin embargo hay casos, como los cajeros automáticos, en los cuales el actor es quién
origina el evento.
Uso de Diagramas de Secuencias de Transacciones

Los actores y secuencias de transacciones identificados pueden documentarse utilizando
diagramas de secuencias de transacciones. Estos diagramas muestran el actor que inicia
la interacción con el sistema.

Alcance de una secuencia de transacciones

Una secuencia de transacciones debe cubrir una secuencia de eventos lógica u cohesiva.
Es posible que dicho flujo de eventos se extienda en el tiempo por varios días.
Para decidir el alcance de una secuencia de transacciones pueden seguirse los siguientes
criterios:
1. La secuencia de transacciones debe tener el alcance tan grande como sea posible
manejarla (en orden de asegurarnos de que la secuencia de procesamiento completa
es manejada satisfactoriamente). El proceso de negocios completo es el alcance por
defecto para la secuencia de transacciones.
2. Cuando se necesite subdividir la secuencia de transacciones para poder tener
unidades razonables para manejar, debemos elegir unidades que el usuario acepte y
perciba como realizando un objetivo de interés desde el punto de vista del negocio.
Estas unidades pueden corresponderse con las mayores opciones del menú de la
aplicación o comandos del sistema.
El alcance de una secuencia de transacciones debe realizar una tarea la cual el

profesional del negocio la reconozca como una unidad cohesiva. Esto difiere de la
perspectiva funcional donde las acciones son empaquetadas en comandos del sistema u
opciones de menú pero sin referenciar la secuencia en la que deben utilizarse dichas
opciones.
Una secuencia de transacciones describe acciones en la secuencia en que se usan, sin
especificar si estas acciones deben empaquetarse en una única función del sistema o en
varias.
24.2 Descripción de caminos estándar y alternativos

Los caminos estándar y alternativos son descritos utilizando descripciones las
descripciones textuales explicadas en el capítulo dedicado al modelado de procesos de
negocios y secuencias de transacciones.
En la secuencia de transacciones se describe que es lo que el sistema debe hacer, como
interactuará con los actores, y cual es el contexto del negocio para dicha interacción. La
secuencia de transacciones como se logra esto dentro del sistema. Esto es descripto en el
modelo de estructura de objetos donde se especifican operaciones elementales a nivel de
objeto.
Los caminos alternativos son descriptos separadamente por un número de razones. Una
razón es que esto permite que se lea en camino estándar sin distracciones por los
detalles de casos inusuales o manejo de errores. Otra razón es que la separación del
camino estándar de los alternativos ayuda al desarrollador a concentrarse en los
tratamientos principales del procesamiento normal de las transacciones.
Ejemplos de funcionalidad que puede ser descripta como caminos alternativos son:
• Partes opcionales de la secuencia de transacciones
• Cursos alternativos de eventos que rara vez ocurren
• Sub-cursos separados que solo se ejecutan en ciertos casos
• Manejo de errores

Identificación y definición de secuencias comunes

Secuencias que son comunes a varias secuencias de transacciones pueden ser
identificadas y descriptas como secuencias de transacciones separadas, llamadas
secuencias comunes. Tanto las secuencias de transacciones y las secuencias comunes
pueden utilizar secuencias comunes, para describir caminos estándar como alternativos.
A menudo las secuencias comunes se asocian con jerarquías de herencia, tanto de clases
de objetos como de actores. A menudo las secuencias de transacciones individuales
describen lógica que se aplica a las subclases de objetos mientras que la secuencia
común describe lógica que se aplica al nivel de superclase y por lo tanto es común a
todas las subclases.
Jerarquías de actores
Los actores representan roles de usuarios. En casos donde diferentes tipos de actores
comparten capacidades comunes, puede ser útil definir jerarquías de actores. Por
ejemplo, un administrador y un usuario normal del sistema pueden tener ciertas
capacidades comunes las que pueden modelarse utilizando una superclase de actor.
Cada actor hereda de la superclase actor.
Las jerarquías de actores son necesarias cuando se encuentra lógica común en dos
secuencias de transacciones distintas que se comunican con dos actores diferentes.
Cuando se separa esta lógica común en una secuencia común, ésta necesita comunicarse
con los dos diferentes actores. Dichos actores juegan un rol idéntico con respecto a la
secuencia común, y puede considerarse como un único actor frente a esta secuencia
común. En este caso es conveniente definir una superclase actor desde la que los dos
actores originales heredan y con quienes la secuencia común se comunica.
Modelando interfaces de usuario e interfaces externas

En los puntos donde los actores inician o se comunican con secuencias de transacciones,
existe a menudo intercambio de datos. El actor suministra datos al sistema, o el sistema
brinda datos al actor.
Es importante identificar que datos son pasados. Estos datos pueden ser descriptos
utilizando clases de objetos interface (que se corresponde con pantallas, ventanas,
reportes, etc.). Es necesario identificar clases de objetos interfaces cuyos datos son
suministrados a los actores o recibidos desde ellos.
El proceso de definición de interfaces puede asistirse con el modelado de prototipos. Sin
embargo debe aclararse que el modelado final de los objetos interfaces debe posponerse
hasta la etapa de diseño lógico.
24.3 Expandiendo el modelo de estructura de objetos

El principal objetivo del modelado de estructura de objetos en esta fase es producir un
modelo completo de objetos entidad. Dependiendo en cuan detallado fue el análisis del
negocio, puede que solo sea necesario expandir y refinar el modelo de estructura de
objetos.
Pasos en el modelado de estructura de objetos para el análisis de requerimientos

1. Determinar los objetos entidad candidatos y agregarlos al modelo.

2. Agregar relaciones estáticas entre objetos entidad.

3. Completar la definición básica para cada objeto entidad:
- Definiendo el conjunto básico de atributos
- Definiendo atributos de identificación
- Definiendo restricciones
- Identificando operaciones donde se requieran
4. Agregar estructuras de herencia para los objetos entidad
5. Agregar estructuras de agregación para los objetos entidad
6. Refinar las relaciones estáticas tomando en cuenta las estructuras de herencia y
agregación.
Definición de ciclos de vida de objetos

Cada vez que se agrega una nueva clase al modelo de estructura de objetos, debe
examinarse si no es necesario dibujar un diagrama de ciclo de vida para dicha clase.
24.4 Uso de diagramas de modelo global

Los diagramas de modelado global tienen dos usos durante el análisis de
requerimientos, ambos vinculados con el manejo de la complejidad:
- particionamiento del espacio de problema para sistemas muy grandes

- representación de requerimientos del sistema a un nivel general (diagrama de
contexto)
24.4 Chequeo del modelo de análisis de requerimientos

Unidad 25: Diseño lógico

El propósito del diseño lógico es producir un modelo de diseño completo para el sistema
relativamente libre de restricciones detalladas de implementación.
25.1 Relaciones entre el diseño lógico y físico

El objetivo del diseño lógico es producir un diseño que requiera pequeños cambios
durante el diseño físico para ser implementado. El objetivo de esto es obtener un
modelo de implementación “portable” a diferentes escenarios de implementación
(estilos de interfaces, lenguajes, dbms, sistemas operativos, hardware, etc.).
Sin embargo se recomienda que antes de empezar el diseño lógico se tomen ciertas
decisiones estratégicas incluyendo:
- Sistema de computación a utilizar
- Base de datos
- Interface de usuario
- Lenguaje de programación
- Librería de clases a utilizar
- Trabajos planeados para ejecutar en modo batch
- Criterios de performance
- Estrategias con respecto al manejo de errores, administración de memoria (garbaje
collection)
- Requerimientos de distribución esperados
25.2 Actividades realizadas durante el diseño lógico

Las siguientes actividades se llevan a cabo durante el diseño lógico:
- Identificación de objetos interface y de control
- Identificación de operaciones
- Uso de diagramas de interacción de objetos para validar el diseño
- Refinado del modelo de estructura de objetos
- Refinado del modelo de ciclo de vida de objetos
- Definición de subsistemas
Muchas actividades del diseño lógico toman las secuencias de transacciones como
punto de partida. El análisis de las secuencias de transacciones es utilizado para
identificar que objetos de interfaz y de control deben agregarse al modelo de objetos.
Dibujando diagramas de interacción de objetos individuales para cada secuencia de
transacciones se asiste en la identificación de operaciones de las clases de objetos.
25.3 Identificación de Objetos de interface y de Control
Como identificar objetos interfaz

Los objetos interfaz pueden identificarse siguiendo los siguientes pasos:
1. Asignar un objeto interfaz central por cada combinación secuencia de transacción /
actor / dispositivo. Por ejemplo un supervisor de almacén puede utilizar una

interface GUI para controlar movimientos de stock y una impresora para imprimir
detalles de movimientos. Para estas actividades se pueden identificar dos objetos
interfaz.
2. Para una interfaz GUI, asignar un objeto interfaz por ventana. Los objetos interface
se comunican con el objeto interface central identificado en el punto 1. No es
conveniente identificar objetos interfaz para cada componente individual de la
ventana (botones, listas, etc.), ya que esto es manejado normalmente por lo
constructores de interfaces (ej., Visual Basic).
3. Para otro tipo de dispositivos, puede ser útil identificar un objeto interface central el
cual maneja el tipo particular de salida, y definir objetos interfaz adicionales para
variantes específicas. Por ejemplo puede definirse un objeto interfaz central para
manejar todos los requerimientos de impresión, con objetos interfaz asociados para
tipos individuales de impresoras (de matriz, láser, etc.).
4. Objetos interfaz pueden modelar protocolos de comunicación por capas como el
modelo ISO. Un objeto interfaz se define por cada capa, el cual se comunica solo
con objetos de la capa superior e inferior inmediata.
5. La agregación puede utilizarse con los objetos interfaz. Por ejemplo, algunos
dispositivos son mejor considerados como compuestos. Un ejemplo es un cajero
automático compuesto de una lectora de tarjeta magnética, una pantalla, un
dispensador de dinero, y una impresora.
6. Puede definirse herencia para objetos interfaz. Esto puede ser útil en casos donde un
actor tiene un conjunto de capacidades que es un superconjunto de capacidades de
otro actor.
7. Una vez que los objetos interface han sido definidos, los objetos interface centrales
pueden revisarse para detectar similitudes en, en cuyo caso pueden combinarse.
Una vez que los objetos interfaces han sido identificados, es necesario considerar que
atributos y operaciones los objetos requieren. El tipo de comportamiento asignado a los
objetos interface son los que:
- requieren información desde el exterior del sistema
- presentan información al exterior del sistema
- cambia si el comportamiento del usuario cambia
- es dependiente del tipo de dispositivo
A menudo existe objetos interfaz con ciclos de vida complejos en orden de manejar
ingresos de datos alternativos, o diferentes secuencias de navegación. En tales casos es
conveniente utilizar diagramas de ciclo de vida.
Los detalles de cómo la interface de usuario debe aparecer se finaliza durante el diseño
lógico usando un constructor GUI y objetos interfaz en combinación.
Como identificar objetos de control

Los objetos de control contienen comportamiento que no pertenece naturalmente ni a
objetos entidad ni a objetos interfaz. Son por lo tanto identificados luego que estos dos
tipos de objetos.
Los objetos de control son generalmente temporales y su duración se extiende solo
durante la secuencia de transacciones.
La lógica contenida en un objeto de control puede ser lógica de control de sistema,
requerida si se está desarrollando un sistema de computación. También puede ser lógica

de la aplicación. A menudo es útil utilizar objetos de control para encapsular la lógica

de control de secuencias de transacciones.
Los objetos de control pueden identificarse inicialmente asignando un objeto de control

por cada secuencia de transacción. Luego que se ha asignado el comportamiento a los
objetos entidad e interfaz, puede darse que todo el comportamiento haya sido
satisfactoriamente asignado, sin dejar requerimientos para el objeto de control. Pero si
existe comportamiento que no pertenece naturalmente ni a los objetos entidad ni de
control, este debe permanecer en el objeto de control.
El tipo de comportamiento que puede ser asignado a un objeto de control puede ser:
- comportamiento que no cambia si el vecindario del objeto cambia
- comportamiento que no cambia sustancialmente si el comportamiento de los objetos
entidad varía
- comportamiento que afecta a más de un objeto entidad
- lógica dependiente del estado
- lógica de control para una secuencia de transacciones
Los objetos de control se vinculan con los actores a través de objetos interfaz. Los
objetos de control a menudo actúan como un conjunto de buffers entre los objetos
entidad y los de control.
Los objetos de control que son demasiado complejos y de baja cohesión funcional
deben dividirse. En contraposición si existe varios objetos de control que tiene alta
cohesión funcional entre ellos, deben combinarse.
Los objetos de control pueden tener asociados atributos, que normalmente son privados.
La decisión de cuando considerar algunos objetos que contienen cálculos requeridos en
el dominio de problema (p.e. cálculo de impuestos, índices, etc.) como objetos de
control o entidad puede ser arbitraria. Como regla se puede tomar, que aquellos objetos
que tienen atributos y deben ser persistentes, deben considerarse del tipo entidad. Los
que no contienen atributos y son temporales, se consideran como de control.
Debe tenerse la precaución de no utilizar objetos de control para separar funciones de
datos, ya que esto va en contra del principio de encapsulamiento de la orientación a
objetos.
Asociaciones posibles entre los distintos tipos de objetos

Usualmente solo los siguientes tipos de asociaciones pueden existir entre objetos de
diferentes tipos:
Objeto Objeto Receptor de mensaje

Emisor de mensaje Entidad Interface Control
Entidad CO RE HE AG CO CO
Interface CO RE CO RE HE AG CO
Control CO RE CO CO HE AG
Referencias:
CO: comunicación por mensajes (enlace dinámico)
RE: relación estática
HE: herencia

AG: agregación
Las letras itálicas indican asociaciones que pueden ocurrir pero que rara vez se dan.
Normalmente los actores se comunican con objetos interface, no con objetos entidad ni
de control.
Las relaciones estáticas normalmente solo son modeladas para objetos entidad. Para los
objetos interface y de control usualmente solo son relevantes las asociaciones por
comunicación.
Las relaciones de herencia y de agregación solo se dan entre clases de objetos del
mismo tipo.
25.4 Identificando y definiendo operaciones

Una operación es un proceso que puede requerirse como una unidad a un objeto. Una
misma operación puede estar disponible para objetos de diferentes clases.
Una operación define un servicio que es ofrecido. Esta definición incluye una
descripción de la semántica de la operación, y una descripción de la sintaxis (como debe
ser invocado el servicio). La semántica central de una operación debe ser siempre la
misma independientemente de la clase de objeto que la implemente. La sintaxis indica
la información que debe suministrarse en orden de invocar la operación, esto es el
nombre y sus parámetros de entra/salida.
Un método es una implementación de una operación para una clase específica, y puede
variar para cada clase.
Notación de punto
Tanto para especificar atributos como operaciones durante el diseño lógico puede
utilizarse la siguiente notación de punto:
objeto.atributo u objeto.operación
Ejemplos:
Documento.Autor Especifica el atributo autor del objeto documento
Auto.Conductor.Nombre Especifica el nombre de la persona que conduce el auto.
Aquí Conductor identifica la relación entre las clases Auto
y Persona.
Como identificar operaciones

Existen tres posibles maneras de identificar operaciones:
1. Considerando el rol y responsabilidades de cada clase de objetos, usando los
enfoques basados en el análisis de las secuencias de transacciones o en el enfoque de
“lista de compras”.
2. Identificando las interacciones de objetos requeridas para soportar cada secuencia de
transacciones, con la asistencia de los diagramas de interacción de objetos.
3. Analizando los ciclos de vida de objetos y determinando las operaciones que ellos
implican.

Los tres enfoques son valiosos y pueden ser utilizados en combinación.

Cualquiera sea el enfoque utilizado los puntos clave a considerar son:
- como puede una funcionalidad dividirse entre operaciones?
- Qué clase de objeto es responsable de una determinada operación?
Método de identificación 1: considerando roles y responsabilidades para cada clase

de objetos
Acorde con Wirfs-Brock, cada clase de objetos debe tener un rol o función simple y
coherente claramente definido. En soporte de dicho rol, un objeto toma ciertas
responsabilidades y comportamiento que es lógico que otros objetos esperen de él. Las
operaciones que un objeto tiene le permiten cumplir con sus responsabilidades.
Las responsabilidades y por lo tanto las operaciones, son identificadas analizando los
requerimientos del sistema representados en las secuencias de transacciones.
Habiendo identificado los primeros objetos entidad, interface, y control, podemos ahora
considerar cada secuencia de transacciones en orden de identificar que operaciones
deben asignarse a cada clase de objetos.
Para realizar esto es conveniente utilizar un diagrama de estructura de objetos que
contenga las clases relevantes a la secuencia de transacciones que se analiza.
Alternativamente, las responsabilidades pueden identificarse utilizando el enfoque

llamado de “lista de compra”. Usando este enfoque, el analista identifica operaciones
considerando cada clase de objetos de una en vez y considerando “¿de qué es
responsable este objeto, y qué deseo realizar con estos datos?”.
Cuando una clase de objetos es claramente responsable de un comportamiento en

particular requerido por una secuencia de transacciones, la operación debe asignarse a
dicha clase. Cuando no existe una clara responsabilidad perteneciente a una clase en
particular se puede hacer lo siguiente:
- Asignar la responsabilidad a la clase que más se adecue
- Distribuir la responsabilidad en más de una clase
- Introducir un objeto de control y asignar la operación al objeto de control
Cuál es la mejor opción depende del contexto y del juicio del diseñador. La asignación
correcta de operaciones es un factor clave en un sistema bien diseñado y mantenible.
Método de identificación 2: Interacción de objetos requerida para soportar cada

secuencia de transacciones
Las interacciones de objetos requeridas para soportar una secuencia de transacciones
puede modelarse usando diagramas de interacción de objetos. Normalmente se utiliza
un diagrama de interacción de objetos por cada secuencia de transacción o por cada
camino (estándar o alternativo) de la secuencia de transacción.
El punto de entrada para el desarrollo de un diagrama de interacción de objetos se extrae

del diagrama de estructura de objetos. Esto debe incluir todos los objetos entidad
relevantes para la secuencia de transacciones y los objetos interfaz y de control que se
asignan a la secuencia de transacción.

El primer paso es considerar que interacción de objetos se requiere para describir la

funcionalidad de la secuencia de transacción. Estas interacciones de objetos son
llamadas eventos.
Una secuencia de transacciones es iniciada por un evento. Un evento puede ser externo
o temporal. Los eventos externos son generados por actores. Los eventos temporales
son disparados cuando se alcanza un instante de tiempo determinado (fecha, hora,
proceso periódico).
Si para identificar las secuencias de transacciones se utiliza el enfoque de

particionamiento por eventos, entonces los eventos de negocio ya se tienen disponibles.
Si el generador del evento de negocio interactúa directamente con el sistema (como en
un cajero automático), entonces este evento, su generador, y el objeto que recibe
inicialmente el evento, pueden introducirse en el diagrama de interacción. Si el
generador del evento de negocio no interactúa directamente con el sistema, entonces el
evento que inicia la secuencia de transacciones es el evento en el cual un actor interno a
la empresa reacciona al evento de negocio iniciando una interacción con el sistema.
Siguiendo el evento inicial, eventos internos son agregados al diagrama de interacción

de objetos para representar la comunicación entre objetos que se requiere para soportar
la secuencia de transacciones. Un evento interno es un mensaje por un objeto a otro
invocando la ejecución de una operación.
Otros eventos pueden ser enviados o recibidos desde los actores que interactúan con la
secuencia de transacciones.
Método de identificación 3: Analizando ciclos de vida de objetos

Los diagramas de ciclo de vida deben revisarse para identificar operaciones. Cada
evento mostrado en un diagrama de ciclo de vida causa la invocación de una operación
en el objeto que recibe el evento. La revisión de los diagramas de ciclo de vida no
revelan todas las operaciones, ya que en estos diagramas normalmente solo se modelan
los eventos que producen cambios de estado.
Especificación de la semántica y sintaxis de las operaciones

Debe definirse la semántica de cada operación identificada. El nombre, la sintaxis, y la
semántica deben proveer toda la información que un usuario de la operación necesito
para decidir cuando utilizarla o no.
La especificación de la semántica puede expresarse en forma de texto, tablas de
decisión, pseudocódigo, etc. Deben especificarse las precondiciones y postcondiciones
de las operaciones como parte de la definición.
También debe especificarse la sintaxis de la operación, los argumentos de entrada /
salida requeridos. Puede definirse el tipo y dominio de cada argumento, como así
también si es opcional o mandatorio.

Operaciones de clase
Una operación puede ser definida como operación de clase. Una operación de clase es
una operación que es invocada por la clase misma no por las instancias. Tales
operaciones pueden por ejemplo retornar información estadística sobre los objetos
instanciados de dicha clase (promedios, totales, etc.). Un objeto particular puede ser
creado durante el diseño físico si el lenguaje utilizado no soporta operaciones de clase.
Herencia de operaciones
Operaciones concretas, abstractas, y templados
En cualquier clase concreta, las operaciones definidas deben siempre tener una
implementación. Sin embargo, en las clases abstractas (de las cuales no se generan
instancias) la implementación de una operación no es obligatoria, ya que las mismas
pueden ser implementadas en las subclases.
Los siguientes tipos de operación pueden especificarse para clases abstractas:
• Operación abstracta: Una operación abstracta no tiene un método de
implementación. Solo se definen la sintaxis y semántica de la operación.
• Operación templado: Una operación templado es una operación concreta que se
implementa en términos de una o más operaciones abstractas.
• Operación concreta: Una operación concreta es aquella para la que se especifica
completamente su implementación.
Redefiniendo operaciones heredadas

Cuando una clase de objetos hereda una operación concreta de una superclase y la
utiliza sin modificarla, no debe agregarse ninguna definición para la operación en la
subclase.
Normalmente solo debería necesitarse especificaciones adicionales en la subclase en los
siguientes casos:
• Adición de una implementación para una operación abstracta.
• Extensión de una operación para agregar comportamientos específicos de la
subclase.
• Redefinición de los tipos de argumentos y dominio de los mismos.
• Optimización del código de la operación.
25.5 Redefiniendo el modelo de estructura de objetos
Adición y remoción de clases de objetos

Las clases de objetos descubiertas durante el análisis de requerimientos son llevadas al
diseño lógico y objetos de control e interfaz adicionales son agregados.
En aplicaciones complejas puede necesitarse cambiar el nivel de abstracción en que las
clases de objetos son vistas. Por ejemplo, desde el punto de vista del análisis de
requerimientos, puede ser claro que un número de objetos similares son requeridos y
que cada uno debe ser descripto como una subclase de una superclase. Desde el punto
de vista del diseño lógico, puede determinarse que solo es necesario la superclase en el
diseño final.

Identificación de Atributos
Durante el diseño lógico, los atributos para cada clase de objetos deben ser
completamente identificados. Se especifican las restricciones de acceso determinado
atributos públicos, protegidos, y privados. También aquí se determinan atributos
derivados.
Definición de persistencia de atributos

Los objetos entidad son usualmente persistentes mientras que los interface o de control
no. Deben identificarse objetos entidad que no son persistentes, y los interface y control
que si lo son.
25.8 Subsistemas
Subsistemas pueden haber sido definidos en etapas previas o pueden definirse durante el
diseño lógico. En el caso en que ya hayan sido definidos con anterioridad, igualmente es
conveniente revisarlos en esta etapa luego de que las clases han sido convenientemente
definidas, para verificar que los subsistemas definidos en verdad representan unidades
coherentes.
Durante el diseño lógico las principales razones para definir subsistemas son:
• Para definir unidades de entrega, unidades funcionales que se entregarán al usuario
en diferentes momentos.
• Para definir unidades de distribución.
• Para definir módulos que garanticen la robustez del diseño del sistema.
• Con propósitos de validación, para chequear la calidad del diseño del sistema.
• Con propósitos de presentación.
25.9 Chequeo del modelo de diseño lógico

Unidad 26: Diseño Físico

El propósito del diseño físico es agregar los detalles técnicos dependientes de la
plataforma requeridos para construir el sistema a partir del diseño lógico.
Las principales actividades del diseño físico son:

1. Establecimiento de la arquitectura del sistema
2. Implementación de las clases del dominio del problema del sistema
3. Construcción de la interface de usuario
4. Diseño e implementación del componente de administración de datos
5. Diseño de la integración con sistemas existentes (legacy systems)
26.1 Arquitectura del sistema.

La arquitectura del sistema es la organización general del sistema en componentes (o
subsistemas).
Como se ha mencionado, es útil y común dividir sistemas grandes y complejos en
subsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de
cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son
específicamente relevantes durante la fase de diseño físico de la aplicación.
Un sistema puede particionarse vertical y horizontalmente (en capas). Las particiones

verticales son utilizadas para subdividir la funcionalidad de la funcionalidad, en tanto
que las particiones horizontales son utilizadas particularmente para aislar dependencias
del sistema operativo, base de datos, o hardware. La subdivisión en capas horizontales
asiste en el salvaguardo de la portabilidad del sistema.
Las particiones verticales deben estar débilmente acopladas y trabajar en configuración

cliente/servidor o peer-to-peer. Las capas horizontales están en una relación cliente-
servidor, donde las capas mas bajas (servidores) suministran servicios a las capas
superiores (clientes).
La arquitectura del sistema puede diagramarse utilizando diagramas de visión general.

Estos diagramas muestran subsistemas y los servicios que se proveen mutuamente.
El presente enfoque de desarrollo orientado a objetos recomienda la siguiente

arquitectura de seis componentes:
Análisis
(del Negocio y Requerimientos) PDC
Diseño Lógico PDC EIC

HIC
TMC
Diseño Físico USC HIC PDC EIC DMC
Clases de Objetos

• Componente Dominio de Problema (PDC)

Representa la parte del sistema que corresponde con el dominio del problema
(mundo real). Consiste de todos los objetos entidad y de control identificados
durante las fases previas.
• Componente de Interacción Humana (HIC)

Consiste de todos los objetos requeridos para la implementación de la interface de
usuario. Se corresponde con los objetos intefaz con usuarios humanos
identificados durante las fases previas.
• Componente de Interfaces Externas (EIC)

Consiste de todos los objetos intefaz con usuarios no humanos, como ser sistemas
externos, dispositivos, impresoras, etc.
• Componente de Administración de Datos (DMC)

Provee la infraestructura para el almacenamiento y recuperación de los objetos
persistentes en algún medio de almacenamiento.
• Componente de Administración de Tareas (TMC)

Se encarga de administrar concurrencia cuando es necesaria. La utilización de este
componente es muy rara en sistemas administrativos, siendo de utilidad solo en
algunos sistemas en tiempo real.
• Componente de Servicio de Utilidades (USC)

Provee servicios de utilidad general que pueden ser requeridos por todos los demás
componentes.
HIC
EIC
USC PDC
TMC
DMC

26.2 Componente Dominio de Problema (PDC)

Este componente representa la parte del mundo real (dominio de problema) del sistema.
Este componente no debe ser afectado por dependencias del harware, sistema operativo,
sistema de interfaz, o base de datos.
Este componente comprende todas clases de objetos entidad y control definidas durante
las fases previas, pudiéndose extender con clases específicas de la implementación.
El diseño físico implica la implementación de las clases y la especificación formal de

las operaciones. Para esto es conveniente trabajar con lenguajes orientados a objetos que
soportan todas las características y permiten una traslación directa de las clases a las
construcciones del lenguaje.
Los principales puntos a considerar durante la implementación de las clases del PDC
son:
- elección de tipos y estructuras de datos
- implementación de relaciones
- implementación de ciclos de vida
- implementación de restricciones
- implementación de atributos y relaciones derivadas
- manejo de errores
26.3 Componente de Interacción Humana (HIC)
26.4 Componente de Administración de Datos (DMC)

Las clases del DMC proveen la infraestructura para el almacenamiento y recuperación
de objetos en un sistema de manejo de datos (DBMS o sistema de archivos). La
separación de estas clases en un componente específico permite aislar al sistema de la
dependencia de un sistema de manejo de datos específico.
La implementación en bases de datos puede contemplar diferentes tecnologías, sin
embargo las más importantes son las relacionales (RDBMS) y las orientadas a objetos
(ODBMS). Los RDBMS no permiten almacenar en forma directa objetos lo cual obliga
a realizar una capa de traslación, sin embargo actualmente para aplicaciones con
grandes volúmnes de datos son los más maduros y robustos. Por otro lado la tecnológia
de ODBMS si bien se integra mejor a un sistema orientado a objetos, todavía se
encuentra en evolución y es considerada por algunos inmadura para soportar
aplicaciones críticas.
Los principales pasos en la construcción del DMC son:

1. mapeo de clases persistentes en las estructuras de datos del sistema de
administración de datos (p.e. tablas de un RDBMS)
2. diseño de las clases de objeto para manejar las transformaciones y para interfacear
con el DBMS.
3. diseño detallado de la interacción de objetos necesaria para soportar el
almacenamiento y recuperación de objetos persistentes.

Arquitectura del DMC
PDC
Capa Lógica
Capa de acceso al DBMS

DBMS
Diseño de base de datos relacional

Para cada objeto persistente debe identificarse un identificador unívoco (object ID)
(clave primaria). La aplicación misma es responsable de la generación y administración
de este object ID. Para la generación de este object ID pueden utilizarse atributos de
identificación definidos durante el diseño lógico.
Los atributos compuestos deben separarse en sus componentes atómicos.
Las relaciones estáticas entre clases pueden realizarse atravez de la implementación de

claves foráneas.
En general, se tienen tres alternativas para el mapeo de relaciones:
1. Cualquier relación (cualquiera sea su cardinalidad) puede siempre mapearse como
una tabla separada en la cual cada fila contiene un par de object IDs y se
corresponde con una instancia de la relación.
2. Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves
foráneas en una de las tablas relacionadas.
3. Para relaciones uno-a-uno existe una tercera alternativa que consiste en combinar las
tablas relacionadas en una sola.
Para el mapeo de agregaciones, se aplican las mismas reglas que para las relaciones
estáticas, ya que en realidad son un caso particular de las mismas.
Para el mapeo de jerarquías de herencia existen tres alternativas:

1. Cada clase de la jerarquía es mapeada a una tabla separada. Todas comparten un
mismo object ID, y tienen una columna para cada atributo propio de la clase.
2. Cada clase no abstracta en la jerarquía es mapeada a una tabla separada que contiene
una columna adicional para cada atributo heredado.
3. Todas las clases en la jerarquía son mapeadas a un única tabla agregándose
columnas para todos los atributos de la jerarquía.

26.5 Componente de Interface Externa (EIC)
26.6 Componente de Administración de Tareas (TMC)
26.7 Componente de Servicios de Utilería (USC)
26.8 Chequeo del modelo de diseño físico

Apunte OO

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apunte OO

Cargado por

Copyright:

Formatos disponibles

Universidad Tecnológica Nacional

Facultad Regional Resistencia

MODELADO Y DISEÑO ORIENTADO A OBJETOS

Unidad 16: Introducción a la Orientación a Objetos ...................................................... 6

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 2 de 61

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 3 de 61

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 4 de 61

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 5 de 61

Unidad 16: Introducción a la Orientación a Objetos

16.1 Conceptos fundamentales.

Presentación del método

MAINSTREAM Combina una síntesis de las principales

Rumbaugh / Coad / Yourdon:

Beneficios de las técnicas O.O.

Tres enfoques de organización para comprender el mundo

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 6 de 61

2) Distinción entre el todo y sus partes

16.2 Concepto de Objeto y Clase.

Comunicación por mensajes

16.3 Principios fundamentales

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 7 de 61

16.4 Conceptos Adicionales

16.5 Modelos utilizados.

Modelo de Estructura de Objetos

Modelo de Secuencias de Transacciones

Diagramas de Interacción de Objetos

Diagramas de Flujo de Actividad

Modelo de ciclo de vida de objetos

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 8 de 61

Modelo global del sistema

Modelo Estructural Modelo de Estructura

Diagrama de Ciclo de Vida de

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 9 de 61

Unidad 17: Modelo de Estructura de Objetos (OSM)

17.1 Conceptos y propósito del modelo de estructura de objetos

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

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

17.2 Componentes del modelo de estructura de objetos.

Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 10 de 61

Clases abstractas y concretas

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 11 de 61

En el diagrama de estructura de objetos una clase abstracta se representa con un

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

La identificación y especificación de operaciones es una tarea clave durante el Diseño

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 12 de 61

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

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

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 13 de 61

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

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

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 14 de 61

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

Componente 1 Componente 2 Componente 3

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 15 de 61

Cuadro Rueda Manubrio

Comunicación por mensajes

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

Técnicas Avanzadas de Modelado de Estructura de Objetos

Prof. A.U.S. Gustavo Torossi PRELIMINAR Página 16 de 61

Atributos identificadores: son atributos o grupos de atributos que identifican

Relaciones derivadas: relaciones transitivas que se derivan de otras relaciones estáticas.