Unidad_3 _Metodologias_de_diseno_para_la_generacion_de_sistemas_orientados_a_objetos

Vista previa del material en texto

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 
 
 
 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 2 
Í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 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 3 
 
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, 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 4 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 5 
 
 
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 origenal 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. 
 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 6 
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. 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 7 
 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 8 
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 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 9 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 10 
 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 11 
 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 12 
 
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). 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 13 
 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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 14 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 15 
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étodolo 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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 16 
 
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 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 17 
 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 18 
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. 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 19 
 
 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 20 
 
3.3.2. Modelos 
 
Los pasos paraconstruir 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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 21 
 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 22 
 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 23 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 24 
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 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 25 
 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 26 
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. 
 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 27 
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) 
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 28 
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
Análisis y diseño orientado a objetos 
Programa desarrollado 
 
 
Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 29 
 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.