MODELADO

Y

DISEÑO

ORIENTADO A OBJETOS

Introducción a la Orientación a Objetos

Conceptos fundamentales.

Presentación del método

Beneficios de las técnicas O.O.

Reusabilidad del software

Mayor flexibilidad para realizar mantenimiento y modificaciones del software

Disminuye el gap semántico proveyendo una representación consistente en todo el ciclo de vida

Mejor interacción entre el usuario/analista/diseñador.

Más apropiado para abordar problemas más complejos.

Tres enfoques de organización para comprender el mundo

Diferenciación de la experiencia en Objetos y Atributos

Distinción entre el todo y sus partes

Formación y distinción de clases de objetos.

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.

Principios fundamentales

Abstracción

Encapsulamiento

Mecanismo que permite ocultar los detalles de implementación de un objeto. Permite empaquetar en una unidad los datos y las funciones que operan sobre dichos datos.

Herencia

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

Polimorfismo

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

Conceptos Adicionales

Agregación

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

Concurrencia

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

Persistencia

Es la propiedad de un objeto cuya existencia trasciende el tiempo y/o el espacio (ej. el objeto continua existiendo luego de que su creador deja de existir / la ubicación de un objeto se mueve a un espacio de direcciones diferente de aquella donde fue creada).

Visibilidad

capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente importante en el diseño e implementación. (ej. C++: público / protegido / privado)

Modelos utilizados.

Modelo de Estructura de Objetos

El modelo de estructura de Objetos (OSM) es el modelo central. Contiene las clases de objetos requeridas para construir la aplicación y las relaciones entre ellas. Se construye a través de un proceso aditivo durante todo el ciclo de desarrollo del sistema.

Modelo de Secuencias de Transacciones

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

Diagramas de Interacción de Objetos

Los diagramas de interacción de objetos muestran las interacciones entre objetos requeridas para proveer al usuario los servicios descriptos en el TSM.

Diagramas de Flujo de Actividad

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

Modelo de ciclo de vida de objetos

El modelo de ciclo de vida de objetos es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios de estado.

Modelo global del sistema

El modelo global del sistema es utilizado para dividir el sistema en unidades de diseño manejables. Es una herramienta para manejar la complejidad de desarrollo de grandes sistemas. Especifica la interfaces entre las unidades de diseño.

Modelo de Estructura de Objetos (OSM)

Conceptos y propósito del modelo de estructura de objetos

El OSM es el modelo fundamental que provee un medio uniforme para modelar el sistema desde la captura de requerimientos en la etapa inicial del análisis hasta la implementación, atravesando todo el ciclo de desarrollo del sistema.

Este modelo identifica :

• las clases de objetos en la aplicación

• como las clases de objetos se asocian unas con otras

• como se comunican los objetos

• los detalles de cada clase de objetos, incluyendo atributos y operaciones

Durante el proceso de análisis y diseño, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la implementación es alcanzado.

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

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

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

• Análisis del Negocio: se reconocen objetos claves del negocio y generan las abstracciones en las clases apropiadas (objetos entidad).

• Análisis de Requerimientos: se identifican asociaciones estructurales entre objetos y nuevas clases (entidad).

• Diseño lógico: Se incorporan todas las clases necesarias para la aplicación incluyendo los objetos de interfaz y de control.

• Diseño Físico: se incorporan todos los detalles remanentes para la implementación física de cada clase de objetos.

Componentes del modelo de estructura de objetos.

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

Se distinguen tres tipos de clases:

• Objetos Entidad

• Objetos de Interfaz

• Objetos de Control.

Para cada clase identificada se describen:

• Operaciones

• Atributos

• Restricciones

Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se distinguen los siguientes tipos de asociaciones:

• Relaciones Estáticas

• Herencia

• Agregación

• Comunicación por mensajes

Objetos entidad

Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleado, alumno, etc.

Se representan en el diagrama de estructura de objetos con el siguiente símbolo:

Objetos Interface

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

Se representan en el diagrama de estructura de objetos con el siguiente símbolo:

Objetos de control

Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes.

Se representan en el diagrama de estructura de objetos con el siguiente símbolo:

Clases abstractas y concretas

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

Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a través de la herencia por múltiples clases concretas.

En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.

Operaciones

Una operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida).

También puede contener una especificación de método, el cual especifica una implementación para la operación.

Notación: Durante la etapa de Análisis o Diseño lógico pueden utilizarse típicamente texto libre o pseudocódigo. Durante el Diseño físico dichas especificaciones son trasladadas en un lenguaje de programación específico como ser C++, Java, Visual Basic, etc.

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

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

Atributos

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

Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto.

La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase.

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

Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño Físico.

Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.

Restricciones

Las restricciones pueden especificarse sobre los valores que un atributo o relación pueden tomar.

La implementación de las restricciones puede realizarse de diferentes formas:

• reglas de validación durante los procesos de entrada de datos (user inputs)

• database-level triggers

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

Relaciones Estáticas

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

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

Al igual que los atributos, las relaciones modelan información sobre un objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que referencian otros objetos.

Una relación estática se representa en el diagrama de estructura de objetos como una línea sólida entre las clases de objetos, con símbolos de cardinalidad en sus extremos.

Las relaciones pueden etiquetarse para identificar el propósito de la asociación. El diseñador puede optar por:

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

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

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

• sin nombre

Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en la relación.

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

La cardinalidad identifica el número máximo y mínimo de instancias de una clase (objetos) que participan en una relación dada, en el mismo sentido que lo hacen en el modelo entidad-relación.

En el diagrama de estructura de objetos utilizaremos la notación de pata-de-gallo para especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.

Pueden observase las siguientes cardinalidades:

Mínimo 1 - Máximo 1.

Mínimo 0 - Máximo 1.

Mínimo 1 - Máximo N.

Mínimo 0 - Máximo N.

Ejemplo:

Herencia

La herencia es el mecanismo a través del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otras clase denominadas subclases.

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

Una subclase puede redefinir atributos u operaciones heredadas. Adicionalmente, una subclase puede definir nuevos atributos, operaciones, y restricciones.

Se distingue entre herencia simple y múltiple. La herencia simple se da cuando un subclase hereda de una única superclase. En el caso de la herencia múltiple, una subclase puede heredar de varias superclases. La decisión de soportar herencia simple o múltiple ha dado lugar a largos debates conceptuales y metodológicos.

En el actual enfoque, Mainstream Objects de Ed.Yourdon, solo se soporta Herencia Simple.

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

Ejemplo

Agregación

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

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

En el diagrama de estructura de objetos, la relación de agregación se representa de la siguiente manera:

Ejemplo

Comunicación por mensajes

Las asociaciones por comunicación pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de otra clase o de la misma.

Una asociación por comunicación corresponde al conjunto de mensajes que son enviados por los objetos de una clase a los objetos de otra clase o de la misma.

Típicamente, la asociación por comunicación es la única asociación existente entre objetos de los tres diferentes tipos.

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

Técnicas Avanzadas de Modelado de Estructura de Objetos

Visibilidad: define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado.

Público : todos

Protegido : solo desde el objeto mismo y operaciones definidas en subclases

Privado : solo desde el objeto mismo

Atributos identificadores: son atributos o grupos de atributos que identifican unívocamente un objeto de una clase. Se corresponde con el concepto de claves del modelo E-R.

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

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

En el diagrama de estructura de objetos las relaciones derivadas se representan de la siguiente manera:

Relaciones Ordenadas: los objetos del extremo “muchos” de una relación se presentan en forma ordenada. Es particularmente útil para especificar que los objetos componentes de un agregado están ordenados. Por ordenado, entendemos que los objetos componentes serán accedidos en una secuencia específica predefinida.

En el diagrama de estructura de objetos las relaciones ordenadas se representan de la siguiente manera:

Atributos y operaciones de clase: definen el comportamiento de la clase misma más allá del comportamiento de sus instancias.

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

Las operaciones de clase actúan sobre la clase misma como un objeto. El caso típico son las operaciones Crear y Destruir.

Modelado de Procesos de Negocios y Secuencias de Transacciones.

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

Los requerimientos para una aplicación de negocios deben basarse en las actuales actividades del negocio, que la aplicación deberá soportar.

El Modelo de Procesos de Negocios (BPM) es usado durante el análisis del negocio (análisis del sistema actual) y provee un medio para describir el negocio.

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

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 cliente.

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.

Como identificar y definir procesos de negocio?

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.

Se identifican las entradas y eventos disparadores que inician cada proceso de negocio y se da un nombre a cada PN.

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?

Identificación a través de actores

Identificar los actores que se comunicarán con el sistema.

Para cada actor 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:

2.1 Confeccionar la lista de eventos.

2.2 Asociar una secuencia de transacciones para cada evento identificada.

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:

Diagrama de secuencia de transacciones (TSD)

Descripción textual

Diagrama de Interacción de Objetos (OID)

Diagrama de Flujo de Actividad (AFD)

Diagrama de Secuencia de Transacciones (TSD)

Actores

Borde del sistema

Secuencia de Transacción o Proceso de Negocio

Evento

Comunicación entre Actor y Sec.Trans.

Secuencia 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.

Modelado de Interaccion de Objetos

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.

Herramientas de modelado.

Diagrama de interacción de objetos para un proceso de negocios

Elementos:

Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos como cajas negras.

Una línea vertical asociada a cada actor.

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.

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

Elementos

Barra vertical a la izquierda representa el límite del sistema.

Se acompaña con la descripción narrativa de la secuencia de transacciones a la izquierda.

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.

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.

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

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:

Múltiples objetos de una misma clase

Se representa la clase más de una vez.

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

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.

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.

Modelo de Ciclo de Vida de Objetos

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.

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

Técnicas avanzadas de modelado.

Modelo Global del Sistema

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.

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.

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.

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.

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

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.

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:

• 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.

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)

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.

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:

Determinar objetos del negocio candidatos

Abstraer los objetos candidatos en clases y definir el propósito de cada clase de objetos.

Determinar las relaciones estáticas entre los objetos del negocio.

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.

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:

Determinar cuando debe modelarse el ciclo de vida para una clase de objetos, según lo expuesto en el punto anterior.

Identificar el primer estado del objeto.

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

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.

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.

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

Identificar los procesos de negocio.

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.

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:

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.

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:

Una identificación del evento inicial y del producto(s) o servicio(s) del proceso de negocios.

Una descripción textual de las actividades involucradas en el proceso de negocio.

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.

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.

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:

Definición de secuencias de transacciones basadas en los procesos de negocio.

Expansión o definición del modelo de estructura de objetos para objetos entidad.

Dibujo de diagramas de ciclo de vida para objetos entidad.

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.

Definición de secuencia de transacciones.

El modelado de secuencias de transacciones incluye los siguientes pasos:

Identificación de las secuencias de transacciones requeridas.

Definición del contexto del negocio.

Descripción del camino estándar.

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:

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.

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.

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.

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

Determinar los objetos entidad candidatos y agregarlos al modelo.

Agregar relaciones estáticas entre objetos entidad.

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

Agregar estructuras de herencia para los objetos entidad

Agregar estructuras de agregación para los objetos entidad

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.

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)

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.

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

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.

Identificación de Objetos de interfaces y de Control

Como identificar objetos interfaz

Los objetos interfaz pueden identificarse siguiendo los siguientes pasos:

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.

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).

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.).

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.

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.

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.

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 Emisor de mensaje	Objeto Receptor 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.

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:

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”.

Identificando las interacciones de objetos requeridas para soportar cada secuencia de transacciones, con la asistencia de los diagramas de interacción de objetos.

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.

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.

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.

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:

Establecimiento de la arquitectura del sistema

Implementación de las clases del dominio del problema del sistema

Construcción de la interface de usuario

Diseño e implementación del componente de administración de datos

Diseño de la integración con sistemas existentes (legacy systems)

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:

• 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.

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

Componente de Interacción Humana (HIC)

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:

mapeo de clases persistentes en las estructuras de datos del sistema de administración de datos (p.e. tablas de un RDBMS)

diseño de las clases de objeto para manejar las transformaciones y para interfacear con el DBMS.

diseño detallado de la interacción de objetos necesaria para soportar el almacenamiento y recuperación de objetos persistentes.

Arquitectura del DMC

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:

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.

Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves foráneas en una de las tablas relacionadas.

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:

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.

Cada clase no abstracta en la jerarquía es mapeada a una tabla separada que contiene una columna adicional para cada atributo heredado.

Todas las clases en la jerarquía son mapeadas a un única tabla agregándose columnas para todos los atributos de la jerarquía.

Componente de Interface Externa (EIC)

Componente de Administración de Tareas (TMC)

Componente de Servicios de Utilería (USC)

Definición según Hammer y Champy

Diplomado Ingeniería de Software

MAINSTREAM

OBJECTS

Combina una síntesis de las principales técnicas y enfoques O.O.

Fuentes

Principales

Rumbaugh / Coad / Yourdon:

• Estructura de Objetos

• Ciclo de Vida

Jacobson

• Enfoque Use Case (secuencia de trans, para capturar requerimientos del sistema)

R.Wirfs-Brock

• Responsability-Driven model (como estructurar la funcionalidad de un sistema O.O

Empleado

Consulta X

Empleado

Control X

Subclase 1

Superclase

IH

Subclase 2

conduce

Es conducido

Chofer

Colectivo

Clase Abstracta

Motocicleta

IH

Vehículo

Automóvil

Componente 3

A

Agregado

Componente 1

Componente 2

Rueda

Manubrio

A

Bicicleta

Cuadro

Emisor

Receptor

A

{ordenado}

Modelo Estructural

(Estático)

Modelo de Comportamiento

(Dinámico)

Modelo Funcional

Modelo de Estructura de Objetos (OSM)

Diagrama de Ciclo de Vida de Objetos (OLD)

Diagrama de Interacción de Objetos (OID)

Modelo de Procesos de Negocios (BPM)

Modelo de Secuencia de Transacciones (TSM)

Entradas y/o Eventos

Salidas Menores

Evento

Producto

Proceso de Negocios

Nombre

evento

Común

Nombre

Nombre

Actor 1

Actor 2

Actor 3

Sistema

1

2

Evento 1

Evento 2

Evento 3

Evento 4

Evento 5

Actores

Requerimientos.

Barras: representan a los objetos de la cabecera.

Links con actividades de un diagrama de flujo de actividades.

Objeto 4

Objeto 1

Objeto 2

Objeto 3

Objeto 5

Objetos

Sec.Trans.

Descrip narrativa de la S.T.

1

2

3

Operaciones

Mensajes enviados por y hacia los actores externos al sistema

Límites del sistema

n. Nombre de Actividad

Actividad. El número n provee un vínculo con 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).

Evento [condición de guarda]

Acción

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

Subsistema de reportes

Subsistema de seminario

Subsistema de registración

Subsistema de memos

Componente de Administración de Datos

PDC

HIC

PDC

PDC

HIC

EIC

EIC

USC

DMC

TMC

Análisis

(del Negocio y Requerimientos)

Diseño Lógico

Diseño Físico

Clases de Objetos

HIC

PDC

PDC

PDC

HIC

EIC

EIC

USC

DMC

TMC

Análisis

(del Negocio y Requerimientos)

Diseño Lógico

Diseño Físico

Clases de Objetos

HIC

PDC

DMC

TMC

EIC

USC

PDC

Capa Lógica

Capa de acceso al DBMS

DBMS