Unidad 3. Metodologias de Diseno Para La Generacion de Sistemas Orientados a Objetos
-
Upload
merrysun22 -
Category
Documents
-
view
80 -
download
9
Transcript of 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
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 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.
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é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
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 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.
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.
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.