unidad 3. metodologias de diseno para la generacion de sistemas orientados a objetos

Análisis y diseño orientado a objetos Programa desarrollado

Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 1

Ingeniería en Desarrollo de software

CUATRIMESTRE: 04

Programa de la asignatura:

Análisis y diseño orientado a objetos

Unidad 3. Metodologías de diseño para la

generación de sistemas orientados a objetos

Clave: 160920413 / 150920413



Índice

Unidad 3. Metodologías de diseño para la generación de sistemas orientados a objetos .. 3

Presentación de la unidad .............................................................................................. 3

Propósito ........................................................................................................................ 5

Competencia específica ................................................................................................. 6

3.1. Booch ...................................................................................................................... 6

3.1.1. Introducción .......................................................................................................... 6

3.1.2. Modelos ................................................................................................................ 7

3.2. OOSE .................................................................................................................... 12

3.2.1. Introducción ........................................................................................................ 13

3.2.2. Modelos .............................................................................................................. 15

3.3. OMT ...................................................................................................................... 18

3.3.1. Introducción ........................................................................................................ 19

3.3.2. Modelos .............................................................................................................. 20

Actividad 1. Metodología para la generación de sistemas OO ...................................... 22

3.4. UML ...................................................................................................................... 22

3.4.1. Introducción ........................................................................................................ 23

3.4.2. OCL (Lenguaje de Especificaciones de Objetos) ................................................ 25

Actividad 2. Cuadro comparativo de las diferentes metodologías ................................. 26

Autoevaluación ............................................................................................................. 27

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

Cierre de la unidad ....................................................................................................... 28

Para saber más…. ....................................................................................................... 28

Fuentes de consulta ..................................................................................................... 28



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



Competencia específica

Comparar las metodologías de diseño para la generación de sistemas orientados a

objetos mediante los diagramas con los métodos de modelado Booch, OOSE, OMTy

UML.

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.

Figura 3.3. Utilización

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.


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.




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 1. 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 al foro y genera una nueva entrada.

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.


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 de texto, 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_A2_XXYZ donde XX es apellido(s) .y

YY es tu nombre(s).

4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.

Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta

unidad 3 del curso, es necesario que resuelvas la autoevaluación. Recuerda que es muy

importante leer cuidadosamente los planteamientos indicados y elegir la opción adecuada

para cada uno.

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 en 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 donde XX es tu apellido(s) y

YY tu nombre(s).

5. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.

* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tu

Facilitador(a), podrás enviar una segunda versión de tu actividad.

Autorreflexiones

Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses

al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)



presente, a partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado

DOO_U3_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta

Autorreflexiones.

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.

http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf



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.

unidad 3. metodologias de diseno para la generacion de sistemas orientados a objetos

Documents