3. Metodologías de diseño para la generación de sistemas

orientados a objetos

Presentación de la unidad En las metodologías de análisis y diseño orientado a objetos, se utilizan algunos conceptos que se definen a continuación.

Método. Es un conjunto de lineamientos y reglas, incluyendo los siguientes componentes.

Conceptos de modelado. Permiten la captura de la semántica y el conocimiento acerca de un problema y su solución.

Modelo es una representación formal de un sistema con cierto nivel de abstracción. En las etapas de especificación de requerimientos y análisis el nivel de abstracción normalmente es alto, omitiendo detalles de implementación.

Meta modelo. Es un modelo que describe otros modelos, describe los conceptos del método modelo y sus relaciones, define los modelos legales que pueden ser construidos dentro del método, describe la información que debe ser capturada.

Vistas y notaciones. Son útiles en la presentación fundamental del modelo de información para que los seres humanos puedan comprenderla, examinarla y modificarla en su caso.

Una vista solo muestra una parte de la semántica del modelo y diferentes vistas pueden presentar la misma información en varias formas.

Notación. Permite construir, examinar y manipular modelos, el mismo modelo se puede dibujar de diferentes maneras mediante el uso de diferentes símbolos, donde algunos de ellos pueden tener el mismo significado. Cada persona puede adoptar su propio formato para describir sus diagramas.

Proceso de desarrollo iterativo. Representa una secuencia de pasos para la construcción e implementación de modelos. El proceso puede estar distribuido en varios niveles de detalle, desde el nivel más alto del proyecto, hasta etapas específicas para la construcción de modelos de bajo nivel. El proceso indica qué modelos se deberán construir y cómo construirlos.

Proceso. Es la guía que indica como producir un modelo, proporciona un

esqueleto de trabajo (frameworks) para el desarrollo, describe los artefactos a ser

producidos y las etapas para producirlos. A alto nivel, describe el desarrollo del

ciclo de vida y las etapas de iteración dentro de él. A bajo nivel describe un

esqueleto de trabajo para la producción de modelos; las etapas para la

construcción del modelo, lineamientos para describir componentes de él, principios

de diseño a seguirse, mediciones de calidad, referencias cruzadas, reglas de

consistencia y banderas rojas para identificar posibles problemas.

Patrón. Es una solución estándar escrita para resolver un problema, basada en una secuencia de tiempo. No existen museos de programas donde los nuevos diseñadores puedan aprender, emulando programas que allí existen, mas bien, tratan de captar ideas de los diseñadores expertos. Actualmente existe un Movimiento de Patrones con el propósito de coleccionar, catalogar y explicar patrones útiles de diseño, de tal forma que otros diseñadores puedan aprender de

ellos. Por lo tanto, Los Patrones son resúmenes de casos de diseño basados en la experiencia.

Reglas de Diseño. Son estados o propiedades que deberán llevarse a cabo u omitirse en un diseño o estrategias generales de diseño a utilizar. Tips y Reglas de dedo. Son recomendaciones que se aplican donde sea necesario, no se organizan en etapas. Son presentaciones informales de patrones.

En los métodos AOO/DOO existen dos tipos principales, dividiendo a estos en:

Estáticos (enfocados a datos), lo importante es la estructura de datos anexa a los objetos y las operaciones que sobre ella operan.

Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un

objeto tiene sentido en estos métodos cuando exhibe un comportamiento

diferencial respecto del resto delos objetos.

En la tabla anterior se mezclan métodos de análisis y de diseño porque, pese a lo que anuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño se difumina, aquí presentamos los más utilizados y que dieron origen al que actualmente se utiliza para el ADOO.

Propósito

Con el transcurso de esta unidad ubicarás las diferentes metodologías para el diseño de

sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /

Ingeniería de software orientado a objetos), OMT (Object Modeling Technique / Técnica

de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de

Modelado) las cuales nos servirán después de hacer un análisis para hacer un buen

diseño apoyado con estas técnicas.

3.1. Booch Es una metodología que se utiliza en el análisis y diseño de software creada por Booch durante su estancia en Rational Software Corporation. El método BOOCH define modelos para describir un sistema, soportando el desarrollo iterativo e incremental. El método incluye diferentes diagramas según el enfoque que se le dé ya sea:

De clases

De objetos

De transición de estados

De módulos

De procesos

De interacción

3.1.1. Introducción El método cuenta con una notación expresiva y bien definida que le permite al diseñador expresar sus ideas y concentrarse en problemas más serios. Son necesarias dos dimensiones para especificar la estructura y comportamiento de un sistema orientado a objetos:

• Dimensión uno: Física / Lógica. • Dimensión dos: Estática / Dinámica.

Para cada dimensión se definen una serie de diagramas que denotan una vista de los

modelos del sistema, éstos reflejan "toda la verdad" sobre sus clases, relaciones y otras

entidades y cada diagrama representa una proyección de estos modelos. En el estado

estable, todos estos diagramas deben ser consistentes con el modelo y también

consistentes entre ellos mismos.

Dimensión lógica: Describe la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema o para definir la arquitectura del sistema. Dimensión física: Describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema. Dimensión estática: Están formados por los diagramas de:

1. Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visión lógica de un sistema, utilizada en la etapa de análisis.

2. Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa de diseño lógico de un sistema.

3. Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el diseño físico de un sistema.

4. Diagramas de procesos: Muestran la asignación de procesos a procesadores en el diseño físico de un sistema.

Dimensión dinámica: La semántica dinámica de un problema se expresa mediante los siguientes diagramas:

1. Diagrama de transición de estados: Muestra el comportamiento de cada instancia de una clase, los eventos que provocan una transición de un estado a otro y las acciones que resultan de este cambio de estado, por lo que, cada clase puede contar con este tipo de diagrama.

2. Diagramas de interacción: Muestra el orden temporal en que se suceden los mensajes en un conjunto de objetos que representan un escenario. Están en el mismo contexto que los diagramas de objetos.

3.1.2. Modelos Diagramas de Clases

Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones

en la visión lógica de un sistema. Los dos elementos esenciales de un diagrama de clases

son: las clases y sus relaciones básicas.

La figura siguiente muestra el icono que se utiliza para representar una clase en un

diagrama de clases. En ciertos diagramas de clases, es útil exponer algunos de los

atributos y operaciones asociados con una clase:

Figura 3.1. Clase

Los atributos denotan una parte de un objeto agregado, durante el diseño expresan una propiedad singular de la clase.

A Nombre del atributo solamente. C Clase del atributo solamente. A:C Nombre y clase del atributo.

Las operaciones denotan algún servicio proporcionado por la clase, se distinguen de los atributos añadiendo paréntesis.

N() Nombre de la operación solamente. R N(Argumento) Clase de retorno de la operación, nombre y parámetros formales

(si los hay).

Las relaciones de clase representan una colaboración con otras clases de diversas

maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Figura 3.2. Conexiones entre clases

La asociación conecta dos clases y denota una conexión semántica, se etiquetan con expresiones sustantivas, denotando la naturaleza de la relación. La herencia denota una relación de generalización / especialización (una relación <<es un>>), y aparece como una asociación con una cabeza de flecha. La flecha apunta a la superclase, y el extremo opuesto de la asociación designa la subclase. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones de cardinalidad. La Posesión: denota una relación todo / parte (relación <<tiene un>> o agregación), aparece como una asociación con un círculo relleno en el extremo que señala al agregado, la clase que está en el otro extremo denota la parte cuyas instancias están contenidas por el objeto agregado. La Utilización: denota una relación cliente / servidor y aparece como una asociación con

una circunferencia en el extremo que denota al cliente. En esta relación de alguna forma

el cliente depende del servidor para que éste le proporcione determinados servicios.

Diagramas de Objetos Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema. Los dos elementos esenciales de un diagrama de objetos son los objetos y sus relaciones. Objetos en la figura siguiente muestra el icono que se usa para representar un objeto en

un diagrama de objetos. Al igual que en el diagrama de clases, también se pueden

especificar algunos atributos del objeto.

Figura 3.4. Objeto

Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros

objetos, un enlace es una instancia de una asociación, al igual que un objeto es una

instancia de una clase.

Figura 3.5. Relaciones entre objetos

Flujo de datos: los datos pueden fluir en la misma dirección que un mensaje o en dirección contraria. El mostrar explícitamente la dirección del flujo de datos ayuda a explicar la semántica de un escenario particular. Objetos activos: son aquellos que incorporan su propio hilo de control.

Figura 3.6. Objetos activos

Diagramas de módulos

Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias. Programa principal: Denota un archivo que contiene la raíz del programa. Especificación y cuerpo: Denotan archivos que contienen la declaración y la definición de las entidades. Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Un subsistema es un agregado que contiene otros módulos y otros subsistemas. Cada módulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje. Dependencias: la única relación que puede darse entre dos módulos es una dependencia de compilación, representada por una línea dirigida que apunta al módulo respecto al cual existe la dependencia. Las flechas denotan dependencias, la flecha sale del el icono dependiente. Diagrama de procesos Se usa un diagrama de procesos para mostrar la asignación de procesos a procesadores en el diseño físico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura de procesos de un sistema. Elementos del diagrama

• Procesadores. Elemento de hardware capaz de ejecutar programas. • Dispositivos. Elemento de hardware incapaz de ejecutar un programa. • Conexiones. Son líneas no dirigidas para indicar conexiones entre procesadores

y/o dispositivos.

Figura 3.7. Diagrama de procesos

El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunque está bastante bien definido como para brindar un proceso predecible y repetible para una organización de software madura. Un proyecto de software bien hecho es aquel en el que el software entregado satisface y posiblemente excede las expectativas del cliente. Se ha desarrollado de forma económica, entregado en tiempo, y es flexible al cambio y al crecimiento.

3.2. OOSE Este método fue desarrollado por Ivar Jacobson OOSE “un enfoque para el manejo de casos de uso”, este modelo de casos de uso sirve como un modelo central para otros modelos. Este modelo es la base en la etapa de análisis, construcción y prueba. OOSE presenta cinco técnicas para modelar un sistema:

• Modelo de requerimientos: delimita el sistema y define su funcionalidad. • Modelo de análisis: estructura el sistema, modelando tres tipos de objetos (objetos

de interface, objetos entidad y objetos de control).

• Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de implementación. Consiste de diagramas de interacción y diagramas de transición de estados.

• Modelo de implementación: consiste en el código fuente de los objetos especificados en el modelo de diseño.

• Modelo de prueba: es llevado a cabo mediante la realización de pruebas al modelo de implementación.

La idea básica de estos modelos es capturar el concepto inicial de todos los

requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos

es importante. Para ser posible el mantenimiento del sistema es también necesario que

los modelos sean tangibles.

3.2.1. Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial. El autor plantea el problema del diseño y construcción de software haciendo una comparación con la industria de la construcción, contemplando las siguientes fases:

• Herramientas. Soportan todos los aspectos de la empresa, explícitamente las actividades de arquitectura, métodos y procesos.

• Procesos. Permite el escalamiento de los métodos, de tal forma que puedan ser aplicados a proyectos de forma interactiva y en partes.

• Métodos. Establece de manera explícita los procedimientos etapa por etapa que deben seguirse para aplicar la arquitectura al proyecto.

• Arquitectura. Una buena estructura del sistema es fácil de entender, de cambiar y realizar pruebas y mantenimiento. Las propiedades del sistema determinan cómo la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la arquitectura son extremadamente importantes y forman la base del método.

Diseño creativo. Las actividades creativas de un desarrollo, consisten en la

transformación de un conjunto de requerimientos y nociones vagas, en un plan

estructurado de construcción y un plan de acción para su implementación .El diseño

creativo tomando como referencia una base arquitectónica es seguir paso a paso los

métodos y procesos con la asistencia de herramientas, para convertir los requerimientos

dentro de una arquitectura viable para la construcción de un proyecto incluyendo la

creación de prototipos.

Un aspecto importante durante el desarrollo del sistema, es considerar explícitamente el proceso de cambio. Todos los sistemas cambian durante su ciclo de vida. Hoy en día el desarrollo de los nuevos métodos es conocer qué cambios son los principales en la parte global del ciclo de vida, así como el costo del sistema. Una industrial del proceso debe por lo tanto saber sobre los cambios del sistema. Un sistema normalmente desarrolla cambios incorporándose en nuevas versiones. La primera versión de un sistema representa una pequeña parte de una composición durante el ciclo de vida del sistema. Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva versión de un sistema, así como para un sistema totalmente nuevo. La diferencia radica en que las entradas para cada etapa cambian en cada ciclo de vida. Modelo de análisis. Especifica el comportamiento funcional del sistema bajo prácticamente circunstancias ideales y sin hacer alusión a un ambiente particular de implementación. Construcción. La primera actividad en la construcción consiste en la implementación de los detalles que conciernen a la arquitectura y construcción del plan, que es ir de una mayor abstracción a concretizar más el plan. Diseño. Formaliza el modelo de análisis en términos del ambiente de implementación y especifica la identidad de los bloques de construcción. Prueba del sistema. Consiste en la verificación del trabajo de cada uno de los paquetes de servicio definidos en el modelo de análisis Esta fase tiene lugar en varios niveles, desde funciones específicas, hasta el sistema completo.

Desarrollo incremental. El desarrollo del sistema es usualmente un proceso el cual toma varios años para su terminación. La especificación es seguida por el análisis, la construcción y prueba del sistema completo. Este método puede trabajar si todos los requerimientos del sistema son conocidos del conjunto de salida. En la mayoría de los casos, conviene mejor desarrollar el sistema etapa por etapa, empezando con unas cuantas funciones principales, como se va aclarando la comprensión del sistema en cuanto a su funcionalidad se van agregando nuevas funciones, de esta forma el sistema va creciendo. Sistema de desarrollo y metodología. Cuando se desarrolla un sistema grande es

importante conocer cómo cada uno de los pasos del método interactúa y cómo ellos

compiten dentro del desarrollo del proceso. Se hace hincapié en la discusión entre el

proceso de desarrollo y las ideas básicas que hay detrás del método lo que determina la

selección de una arquitectura de un universo de arquitecturas.

3.2.2. Modelos El sistema de desarrollo es una tarea compleja. Algunos aspectos diferentes han sido tomados en consideración. Se trabaja con 5 modelos:

1. El modelo de requerimientos: El objetivo es la captura de requerimientos funcionales.

2. El modelo de análisis: El objetivo es dar al sistema una estructura de objetos robusta y flexible a los cambios.

3. Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetos en el ambiente actual de implementación.

4. El modelo de implementación: Tiene como objetivo implementar el sistema. 5. El modelo de prueba: Su objetivo es verificar el sistema.

La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos es importante. Para hacer posible el mantenimiento del sistema es también necesario que los modelos sean tangibles. Modelo de requerimientos Actores y Casos de Uso La primera transformación hecha de la especificación de requerimientos para el modelo de requerimientos consiste en: Un modelo de caso de uso Descripción de la interface Un modelo en el dominio del problema

Figura 3.8. Modelo de caso de uso

El modelo de caso de uso utiliza actores y caso de uso. Estos conceptos son usados para definir si existe contacto externo con el sistema (actores), y qué debería ser hecho por el sistema (caso de uso). Los actores representan quienes interactúan con el sistema. Representan todas las necesidades de cambio de información con el sistema. Dado que el actor representa la parte exterior del sistema no se describirán detalles de ellos. La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el sistema, mientras que el actor es un rol que el usuario puede jugar. Modelo de análisis Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones del sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha sido desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema. La información para este sistema se enfoca en la captura de:

• Información: Especifica la información de ayuda en el sistema. Así como describe el estado interno del sistema.

• Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica cuándo y cómo el sistema cambia de estado.

• Presentación: Detalla la presentación del sistema al mundo exterior.

Figura 3.9. Dimensiones del modelo de análisis

Existen varios tipos de objetos usados para la estructura del sistema en el modelo de

análisis

Figura 3.10. Tipos de objeto

Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis, sin

embargo cada uno de ellos tiene cierta inclinación hacia una de las dimensiones.

Figura 3.11. Dimensiones del modelo de análisis El modelo de diseño

El proceso de construcción edifica el sistema usando tanto el modelo de análisis y el

modelo de requerimientos. Primero se crea el modelo de diseño que es un refinamiento y

formalización del modelo de análisis. Al inicio del trabajo cuando se desarrolla el modelo

de diseño es para adaptarlo a la implementación del ambiente actual.

Figura 3.12. Implementación del ambiente

Una diferencia entre el modelo de análisis y el modelo de diseño es que el modelo de

análisis debe ser visto como un modelo conceptual o lógico del sistema, y el modelo de

diseño contiene el código, por lo cual el modelo de diseño deberá ser una representación

de la manera como el código fuente es estructurado, manejado y escrito.

Figura 3.13. Consecuencias del ambiente El modelo de Implementación La implementación del modelo consiste de la notación del código. La información de espacio es la opción del lenguaje de programación que se usa. No necesariamente se requiere de un lenguaje de programación orientada a objeto, sin embargo, si se recomienda el uso de un lenguaje de programación orientada a objeto, desde la concepción inicial hasta la construcción. La base para la implementación es el modelo de diseño. Aquí se especifica la interface década bloque. El modelo de prueba El modelo de prueba es el último modelo a construir. Describe simplemente el estado de

resultados de la prueba. El modelo de requerimientos de nuevo representa una

herramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos se

comuniquen correctamente en dicho caso de uso. De manera simular se verifica la

interface de usuario, descrita en el modelo de requerimientos, con todo lo anterior, el

modelo de requerimientos es la base de verificado para el modelo de prueba.

3.3. OMT Un modelo es una abstracción de algo, con la finalidad de comprenderlo, antes de construirlo, ya que un modelo omite los detalles no esenciales, es más sencillo manejarlos, que manejar la entidad original.

Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos

modelo dinámico y modelo funcional.

3.3.1. Introducción El modelo de objetos. Es el modelo más importante, ya que en él se identifican las clases dentro del sistema junto con sus relaciones, así como sus atributos y operaciones, lo que representa la estructura estática del sistema. El modelo de objetos se representa mediante un diagrama de clases. El modelo dinámico. Representa los aspectos temporales de comportamiento "de control del sistema, mediante la secuencia de operaciones en el tiempo. El modelo funcional. Representa los aspectos transformacionales "de función" del sistema, mediante la transformación de valores de los datos. Se representa mediante un diagrama de flujo. Cada modelo describe un aspecto del sistema pero contiene referencias a los demás modelos. Lo cual indica que los tres no son totalmente independientes. Pasos del proceso de desarrollo orientado a objetos: Conceptualización: Se describen los requerimientos para la solución del sistema. Comienza identificando las necesidades desde el punto de vista de los usuarios. Dicha información puede ser extraída de los casos de uso y del dominio del problema. Análisis: Entender y modelar el problema en el dominio de la aplicación. Diseño del sistema: Determinar la arquitectura del sistema en términos de subsistemas. Diseño de objetos: Refinar y optimizar el modelo de análisis, agregando conceptos de programación. Código: Implementar las clases de objetos en un lenguaje de programación. Pruebas: se realizan para verificar el comportamiento de las clases y objetos que se

encuentran descritos en los escenarios.

Figura 3.14. Proceso de desarrollo orientado a objetos

Cada paso del proceso transforma algunas entradas para generar una salida diferente,

comenzando en un alto nivel de abstracción hasta llevarlo a un nivel de detalle que

finalmente representa la solución del problema.

3.3.2. Modelos Los pasos para construir el modelo de objetos son los siguientes:

1. Identificación de objetos y/o clases. 2. Crear un diccionario de datos. 3. Identificación de las asociaciones y agregaciones entre los objetos. 4. Identificación de atributos y enlaces. 5. Organización y simplificación de las clases empleando herencia. 6. Verificación de las vías de acceso necesarias para llevar a cabo las probables

consultas. 7. Realizar las iteraciones necesarias para el refinamiento del modelo. 8. Agrupar las clases en módulos.

Modelo de objetos = Diagrama de modelo de objetos + diccionario de datos. Diagrama de clases En él se describen las clases que se descubrieron para el sistema analizado en términos

del dominio del problema. Además se especifican los atributos y operaciones que

distinguen a cada una de las clases y las relaciones con las que podemos conocer su

responsabilidad en el sistema.

Figura 3.15. Nombre Clase

Dentro del diagrama de clases, una clase se representa mediante un rectángulo donde pueden existir tres separaciones, en la primer parte se coloca el Nombre de la clase, en la segunda y tercera parte se pueden agregar los atributos y las operaciones, pero sino se desea agregar ninguno de ellos, es porque no son tan importantes para la comprensión del sistema, entonces el rectángulo solo se queda con el nombre de la clase. Modelo dinámico = Diagrama de estados + diagrama global de flujo de sucesos. Escenario: Es la representación escrita de los casos de uso y de la interacción de los actores con

ellos para especificar el propósito del sistema.

Figura 3.16. Escenario

Diagramas de estados: Relaciona sucesos y estados. Un diagrama de estados se representa mediante estados, transiciones, condiciones y acciones. Estados: Los estados representan las respuestas de los objetos a varios sucesos en determinado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado del objeto. Se representan mediante cuadros redondeados que contienen un nombre. Transiciones: Se representan mediante flechas que salen del estado receptor hasta él y el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha transición, cada transición que sale de un estado corresponde a un suceso distinto, lo cual indica que no deben de existir sucesos duplicados dentro de un estado. Condiciones: Una condición se puede pensar como una protección en las transiciones, debido a que si se cumple dicha condición la transición se dará y podrá pasar el objeto de un estado a otro, si dicha condición no se cumple inclusive podría pasar a otro estado mediante otra transición o quedarse en el estado receptor hasta que la condición se cumpla. Acción: Es una operación que va asociada a un suceso y se representa mediante una barra “/” y el nombre de la acción, después del nombre de la transición. Modelo Funcional = Diagrama de flujo de datos + restricciones. Mediante el modelo funcional se puede observar los resultados que se tienen de un cálculo de valores, especificando solamente entradas y salidas de los valores, mas no como son calculados estos. El modelo funcional consta básicamente de diagramas de flujo de datos. Los diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a través de procesos los cuales modifican dichos valores para transformarlos en otros. Los diagramas de flujo están compuestos de: Procesos Flujos de datos Actores Almacenes

Procesos: se representan mediante una elipse, los procesos tienen como entrada datos,

los cuales serán transformados, por lo cual un proceso es visto como un método de una

operación aplicada a una clase de objetos.

Figura 3.17. Proceso

Flujo de datos: un flujo de datos conecta la salida de un proceso a la entrada de otro. Se

representa en el diagrama por medio de una flecha, la cual puede llevar el nombre o el

tipo de dato. Además de trasladar los datos a otros procesos, los flujos de datos pueden

usarse para copiar un valor, realizar la composición de un agregado y así como su

inverso.

Actividad 7. Metodología para la generación de sistemas OO La presente actividad tiene como propósito que reflexiones acerca de las metodologías vistas hasta ahora cuál de ellas te parece la más adecuada a diseños orientado a objetos.

1. Retoma las lecturas de los temas 3.1. Booch, 3.2. OOSE y 3.3. OMT. 2. Identifica las metodologías y los modelos para diseñar con base en la

Orientación a Objetos. 3. Ingresa a blog de tu equipo y publica con tus compañeros, cuál es, desde tu

punto de vista, la metodología más adecuada para diseñar un programa Orientado a Objetos.

4. Contribuye con algún comentario sobre la importancia de cubrir los requerimientos.

5. Con base en las aportaciones de tus compañeros(as), decide, cuál de las herramientas vistas hasta ahora, es la más adecuada.

3.4. UML UML es una técnica desde en 1994 abarca aspectos de todos los métodos de diseño los

antecesores de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor

del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0

de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas

construidos para toda clase de industrias alrededor del mundo: hospitales, bancos,

comunicaciones, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más). • Modelar sistemas orientados a objetos. • Establecer conceptos y artefactos ejecutables. • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica. • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. • Mejor soporte a la planeación y al control de proyectos. • Alta reutilización y minimización de costos.

3.4.1. Introducción El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con objetos, análisis y diseño, con una buena consistencia del lenguaje para especificar, visualizar, construir y documentar un sistema de software. Esta especificación representa la convergencia de las mejores prácticas en la tecnología de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos derivado de las tres metodologías; (Booch, OMT y OOSE). Al conjuntar los métodos de Booch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de éstos y otros métodos. El UML da la idea que lo que se está haciendo, se realiza con métodos existentes. Los objetivos que se fijaron al desarrollar el UML fueron los siguientes:

• Proporcionar a los usuarios un Lenguaje de Modelado Visual de tal forma que sea posible intercambiar información de los modelos.

• Proporcionar mecanismos de extensibilidad y especialización para ampliar los conceptos básicos.

• Ser independiente de un lenguaje en particular y del proceso de desarrollo. • Proporcionar bases formales para la comprensión del Lenguaje de Modelado. • Integración en una mejor práctica.

El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el

consenso de los conceptos de modelado básico y permite desviaciones, las cuales se

expresan en términos de mecanismos de extensión. Es un conjunto preciso que consiste

en la definición de la semántica y notación del UML, definiendo también cómo se maneja

el Lenguaje de Especificación de Objetos.

Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas complejos, y en cuanto más complejos se vuelven los sistemas, es necesario tener mejores técnicas de modelado. El contar con una metodología universal para el desarrollo de sistemas de software es de gran beneficio en la construcción de todo tipo de sistemas.

Disponer de buenos modelos facilita la comunicación entre equipos de trabajo en un gran proyecto. El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estándar, es la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la tecnología Orientada a Objetos. El documento describe los mecanismos de la notación para la representación visual del UML. Existen básicamente cuatro constructores gráficos usados en la notación del UML; iconos, símbolos de 2 dimensiones, uniones y cadenas. Icono. Es una figura gráfica de tamaño y forma definida, éstos pueden aparecer dentro del área de los símbolos, en la terminación de una unión, etc. Símbolos de 2 dimensiones. Son de tamaño variable, pueden contener listas de cadenas u otros símbolos. Las uniones se conectan a los símbolos de 2 dimensiones como terminación de la unión sobre alguna parte del contorno de dicho símbolo. Uniones. Son segmentos de línea con sus extremos terminados en algún símbolo de 2 dimensiones. Cadenas. Representan conceptos, pueden existir como un elemento dentro de un símbolo o dentro de un compartimiento de un símbolo, como elementos de una lista, como etiquetas de un símbolo o unión, o como un elemento estándar dentro de un diagrama. El documento está dividido en varios capítulos de acuerdo a los conceptos semánticos, o por los diferentes tipos de diagramas. Cada capítulo está subdividido por los elementos que conforman el diagrama, y para cada elemento se cuenta con las siguientes secciones:

El nombre de la notación a describir Semántica Notación Mapeo Opciones de presentación

Cada punto cuenta con su propia descripción: Nombre de la notación: Especifica el nombre de la notación Semántica: Es un breve resumen de la semántica para dicho elemento. Notación: Explica la representación dotacional de la semántica mediante un diagrama. Obviamente para cada caso se utilizan un diagrama diferente que proporciona la identificación de la semántica del grafo especificado. Mapeo: Indica cómo la notación puede ser representada como información semántica. Es decir qué tipo de diagrama se utiliza, con cuáles rutas se maneja y cómo trabaja una estructura conectada con otra estructura dentro de un mismo diagrama. Dando así el sentido de saber interpretar la notación que se presenta y con qué fin es utilizada. Opciones de presentación: Son herramientas que pueden ser utilizadas para dar más

énfasis a la notación cuando ésta lo requiera dejándola más completa y estructurada. En

varios elementos esta sección no se presenta debido a que no tiene opciones de

presentación.

3.4.2. OCL (Lenguaje de Especificaciones de Objetos) El Lenguaje de Especificación de Objetos (Object Constraint Language, OCL), es un lenguaje formal para expresar restricciones libres de efectos colaterales. Los usuarios del Lenguaje Unificado para Modelado (UML) y de otros lenguajes, pueden usar el OCL para especificar restricciones y otras expresiones incluidas en sus modelos. El OCL tiene características de un lenguaje de expresión, de un lenguaje de modelado y de un lenguaje formal. El OCL es un lenguaje de expresión puro. Por lo tanto, garantiza que una expresión OCL no tendrá efectos colaterales; no puede cambiar nada en el modelo. Esto significa que el estado del sistema no cambiará nunca como consecuencia de una expresión OCL, aun cuando una expresión OCL puede usarse para especificar un cambio de estado, por ejemplo, en una post-condición. Todos los valores, de todos los objetos, incluyendo todos los enlaces, no cambiarán, cuando una expresión OCL es evaluada, simplemente devuelve un valor. El OCL no es un lenguaje de programación, por lo tanto, no es posible escribir lógica de

programa o flujo de control en OCL. No es posible invocar procesos o activar operaciones

que no sean consultas en OCL. Dado que el OCL es un lenguaje de modelado en primer

lugar, es posible que haya cosas en él que no sean directamente ejecutables.

Como el OCL es un lenguaje de modelado, toda consideración de implementación está fuera de su alcance, y no puede ser expresada en el lenguaje OCL. Conceptualmente, cada expresión OCL es atómica. El estado de los objetos en el sistema no puede variar durante la evaluación. OCL es un lenguaje formal donde todos los constructores tienen un significado formalmente definido, la especificación del OCL es parte del UML. El OCL no pretende reemplazar lenguajes formales existentes como VDM y Z. El OCL puede ser usado con distintos propósitos:

Para especificar características estáticas sobre clases y tipos en un modelo de clases.

Para especificar características estáticas de tipo para Estereotipos.

Para especificar pre y post-condiciones sobre Operaciones y Métodos.

Como lenguaje de navegación.

Para especificar restricciones sobre operaciones: Dentro del documento Semántica del UML, el OCL es usado en la sección reglas bien formuladas, como constantes estáticas sobre la meta-clase en la sintaxis abstracta. En varios lugares también es usado para definir operaciones „adicionales‟, que son tomadas en cuenta en la formación de reglas.

Las expresiones OCL pueden ser parte de pre-condiciones o post-condiciones, que son Restricciones estereotipadas con «pre-condition» y «post-condition» respectivamente. Las pre-condiciones o post-condiciones se aplican tanto a Métodos como a Operaciones.

Actividad 2. Cuadro comparativo de las diferentes metodologías La presente actividad tiene la finalidad de que apliques cada uno de los conceptos básicos de las metodologías de diseño vistas hasta ahora y además, que investigues las fechas en las que implementaron dichas metodologías. 1. Investiga las fechas en que fueron implementadas las metodologías OO. 2. En un archivo elabora un cuadro comparativo donde incluyas las características de cada una de las metodologías OO y la fecha en que fueron implementadas. 3. Guarda la Actividad con el nombre ADOO_U3_A7_XXYZ. 4. Envía el archivo al correo electrónico de tu profesor para recibir retroalimentación.

Evidencia de aprendizaje. Cuadro comparativo de los métodos de modelado

Como parte de la evaluación de esta unidad, lleva a cabo la siguiente actividad cuyo propósito es conceptuar el proceso. 1. En un archivo de texto elabora un cuadro comparativo de los diagramas que son utilizados en cada uno de los modelos revisados a lo largo de la unidad. 2. Al final del documento, redacta una conclusión donde expreses cuáles serían los modelos más adecuados a utilizar en cada caso. 3. Consulta la Escala de Evaluación. 4. Guarda la evidencia con el nombre DOO_U3_EA_XXYY. 5. Envía el archivo al correo electrónico de tu profesor para recibir retroalimentación.

Cierre de la unidad Has concluido la unidad 3 del curso. A lo largo de ésta se recordaron las metodologías de diseño para la generación de Sistemas Orientados a Objetos, tales como: Boosh, OOSE, OMT, en cada uno de ellos se vio una breve introducción y su modelo. Por último el origen de la metodología UML, la cual fue a través del OCL. Es aconsejable que revises nuevamente la unidad en caso de que los temas que se

acaban de mencionar no te sean familiares, o no los recuerdes, de no ser este tu caso, ya

estás preparado(a) para seguir con la unidad 4, en donde continuarás con El diseño

orientado a objetos con UML, a través de la representación de objetos y clases con

diagramas y documentación para el diseño del software con UML, en dichos diagramas se

manejarán casos de uso, escenarios del caso de uso, diagramas de actividades,

secuencial, de clase y de gráfico de estado. Todo ello con el fin de obtener el prototipo

final al terminar el curso de Análisis y Diseño Orientado a Objetos.

Para saber más…. En el siguiente documento encontrarás un ejemplo real de análisis

aplicado al diseño de un sistema escolar:

Desarrollo de un sistema de administración escolar académica para la escuela “Cristóbal Colón” bajo plataforma web: http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf

Fuentes de consulta

Booch-Grady (2009) Análisis y Diseño Orientado a Objetos con aplicaciones. México: Pearson Educación.

Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: Addison Wesley

Graham, I. (2002) Métodos Orientados a Objetos México: Addison Wesley/Díaz

de Santos.

Jacobson, I. (1992) Object-Oriented Software Engineering A Use Case Driven Aproach México: Addison-Wesley

James, R., Blaha, M., Premerlani, W. & Eddym, F. (1990) Object Oriented Modeling and Design. México: Pretice Hall.

Larman, C. (2004) Applying UML and Patterns An Introduction to object-Oriented Analysis and Design México: Prentice Hall

Martin, J. & Odell, J. (1990) Análisis y Diseño Orientado a Objetos México: Prentice Hall Iberoamericana.

Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML México: Addison Wesley

Wirfs, R. & Wiener, L. (1990). Designing Object Oriented Softwarem. México:

Pretince Hall.

ESCALA DE EVALUACIÓN Carreras: Sistemas Computacionales

Cuatrimestre: Séptimo

Asignatura: Análisis y diseño de Sistemas II Unidad: 3. Metodologías de diseños para la generación de sistemas orientados a objetos

Evidencia Cuadro comparativo de los métodos de modelado

Instrucciones: Anote en cada casilla los puntos obtenidos por el estudiante en cada criterio por evaluar.

DIMENSIONES O CRITERIOS A EVALUAR

PUNTOS POR CRITERIO

PUNTOS OBTENIDOS

OBSERVACIONES

1. Básica

a. Comparación modelo BOOCH 8

b. Comparación modelo OOSE 8

c. Comparación OMT 8

d. Comparación UML (OCL) 8

e. El conceptos de BOOCH es el adecuado 8

f. El conceptos de OOSE es el adecuado 8

g. El conceptos de OMT es el adecuado 8

h. El conceptos de UML(OCL) es el adecuado 8

2. General

a. Conclusión de cada modelo 12

b. Expresa el modelo más adecuado en cada caso 8

3. Creación

c. Estructura 5

d. Incluye Definiciones texto 5

e. Contenido visual 5

f. Creatividad 5

4. Calidad

a. Alineación , títulos centrados, formato 5

b. No hay errores de puntuación u ortografía 3

c. Coherencia en imagen-Texto-Concepto 4

Total de puntos 100

Total de puntos obtenidos por el estudiante