Metodologiasdedisenoparalageneracion de Sistemas Orientadosobjetos

Anlisis y diseo orientado a objetos
Programa desarrollado

Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 1

Ingeniera en Desarrollo de software
CUATRIMESTRE: 04

Programa de la asignatura:
Unidad 3. Metodologas de diseo para la
generacin de sistemas orientados a objetos

Clave: 160920413 / 150920413


ndice

Unidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos .. 3
Presentacin de la unidad .............................................................................................. 3
Propsito ........................................................................................................................ 5
Competencia especfica ................................................................................................. 6
3.1. Booch ...................................................................................................................... 6
3.1.1. Introduccin .......................................................................................................... 6
3.1.2. Modelos ................................................................................................................ 7
3.2. OOSE .................................................................................................................... 12
3.2.1. Introduccin ........................................................................................................ 13
3.2.2. Modelos .............................................................................................................. 15
3.3. OMT ...................................................................................................................... 18
3.3.1. Introduccin ........................................................................................................ 19
3.3.2. Modelos .............................................................................................................. 20
Actividad 1. Metodologa para la generacin de sistemas OO ...................................... 22
3.4. UML ...................................................................................................................... 22
3.4.1. Introduccin ........................................................................................................ 23
3.4.2. OCL (Lenguaje de Especificaciones de Objetos) ................................................ 25
Actividad 2. Cuadro comparativo de las diferentes metodologas ................................. 26
Autoevaluacin ............................................................................................................. 27
Evidencia de aprendizaje. Cuadro comparativo de los mtodos de modelado ............. 27
Cierre de la unidad ....................................................................................................... 28
Para saber ms. ....................................................................................................... 28
Fuentes de consulta ..................................................................................................... 28



Unidad 3. Metodologas de diseo para la generacin de sistemas
orientados a objetos

Presentacin de la unidad

En las metodologas de anlisis y diseo orientado a objetos, se utilizan algunos
conceptos que se definen a continuacin.

Mtodo. Es un conjunto de lineamientos y reglas, incluyendo los siguientes
componentes.
Conceptos de modelado. Permiten la captura de la semntica y el conocimiento
acerca de un problema y su solucin.
Modelo es una representacin formal de un sistema con cierto nivel de
abstraccin. En las etapas de especificacin de requerimientos y anlisis el nivel
de abstraccin normalmente es alto, omitiendo detalles de implementacin.
Meta modelo. Es un modelo que describe otros modelos, describe los conceptos
del mtodo modelo y sus relaciones, define los modelos legales que pueden ser
construidos dentro del mtodo, describe la informacin que debe ser capturada.
Vistas y notaciones. Son tiles en la presentacin fundamental del modelo de
informacin para que los seres humanos puedan comprenderla, examinarla y
modificarla en su caso.
Una vista solo muestra una parte de la semntica del modelo y diferentes vistas
pueden presentar la misma informacin en varias formas.
Notacin. Permite construir, examinar y manipular modelos, el mismo modelo se
puede dibujar de diferentes maneras mediante el uso de diferentes smbolos,
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
construccin e implementacin de modelos. El proceso puede estar distribuido en
varios niveles de detalle, desde el nivel ms alto del proyecto, hasta etapas
especficas para la construccin de modelos de bajo nivel. El proceso indica qu
modelos se debern construir y cmo construirlos.
Proceso. Es la gua 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 iteracin dentro de l. A bajo nivel describe un esqueleto de trabajo
para la produccin de modelos; las etapas para la construccin del modelo,
lineamientos para describir componentes de l, principios de diseo a seguirse,

mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas
rojas para identificar posibles problemas.
Patrn. Es una solucin estndar escrita para resolver un problema, basada en
una secuencia de tiempo. No existen museos de programas donde los nuevos
diseadores puedan aprender, emulando programas que all existen, mas bien,
tratan de captar ideas de los diseadores expertos. Actualmente existe un
Movimiento de Patrones con el propsito de coleccionar, catalogar y explicar
patrones tiles de diseo, de tal forma que otros diseadores puedan aprender de
ellos. Por lo tanto, Los Patrones son resmenes de casos de diseo basados en la
experiencia.
Reglas de Diseo. Son estados o propiedades que debern llevarse a cabo u
omitirse en un diseo o estrategias generales de diseo 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 mtodos AOO/DOO existen dos tipos principales, dividiendo a estos en:

Estticos (enfocados a datos), lo importante es la estructura de datos anexa a los
objetos y las operaciones que sobre ella operan.
Dinmicos (enfocados a comportamientos o enfocados a responsabilidades): un
objeto tiene sentido en estos mtodos cuando exhibe un comportamiento
diferencial respecto del resto delos objetos.



En la tabla anterior se mezclan mtodos de anlisis y de diseo porque, pese a lo que
anuncien sus autores o aun su mismo nombre, la distincin entre anlisis y diseo se
difumina, aqu presentamos los ms utilizados y que dieron origen al que actualmente se
utiliza para el ADOO.

Propsito

Con el transcurso de esta unidad ubicars las diferentes metodologas para el diseo de
sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /
Ingeniera de software orientado a objetos), OMT (Object Modeling Technique / Tcnica
de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de
Modelado) las cuales nos servirn despus de hacer un anlisis para hacer un buen
diseo apoyado con estas tcnicas.


Competencia especfica

Comparar las metodologas de diseo para la generacin de sistemas orientados a
objetos mediante los diagramas con los mtodos de modelado Booch, OOSE, OMTy
UML.

3.1. Booch

Es una metodologa que se utiliza en el anlisis y diseo de software creada por Booch
durante su estancia en Rational Software Corporation.

El mtodo BOOCH define modelos para describir un sistema, soportando el desarrollo
iterativo e incremental. El mtodo incluye diferentes diagramas segn el enfoque que se
le d ya sea:
De clases
De objetos
De transicin de estados
De mdulos
De procesos
De interaccin

3.1.1. Introduccin

El mtodo cuenta con una notacin expresiva y bien definida que le permite al diseador
expresar sus ideas y concentrarse en problemas ms serios.

Son necesarias dos dimensiones para especificar la estructura y comportamiento de un
sistema orientado a objetos:

Dimensin uno: Fsica / Lgica.
Dimensin dos: Esttica / Dinmica.

Para cada dimensin 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 proyeccin de estos modelos. En el estado
estable, todos estos diagramas deben ser consistentes con el modelo y tambin
consistentes entre ellos mismos.


Dimensin lgica: 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.

Dimensin fsica: Describe la composicin concreta en cuanto a hardware y software del
contexto o implantacin del sistema.

Dimensin esttica: Estn formados por los diagramas de:

1.- Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visin
lgica de un sistema, utilizada en la etapa de anlisis.
2.- Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa
de diseo lgico de un sistema.
3.- Diagramas de mdulos: Muestran la asignacin de clases y objetos a mdulos en el
diseo fsico de un sistema.
4.- Diagramas de procesos: Muestran la asignacin de procesos a procesadores en el
diseo fsico de un sistema.

Dimensin dinmica: La semntica dinmica de un problema se expresa mediante los
siguientes diagramas:

1.-Diagrama de transicin de estados: Muestra el comportamiento de cada instancia de
una clase, los eventos que provocan una transicin 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 interaccin: Muestra el orden temporal en que se suceden los mensajes
en un conjunto de objetos que representan un escenario. Estn 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 visin lgica de un sistema. Los dos elementos esenciales de un diagrama de clases
son: las clases y sus relaciones bsicas.


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 diseo 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 algn servicio proporcionado por la clase, se distinguen de los
atributos aadiendo parntesis.
N() Nombre de la operacin solamente.
R N(Argumento) Clase de retorno de la operacin, nombre y parmetros formales (si los
hay).

Las relaciones de clase representan una colaboracin con otras clases de diversas
maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Figura 3.2. Conexiones entre clases


La asociacin conecta dos clases y denota una conexin semntica, se etiquetan con
expresiones sustantivas, denotando la naturaleza de la relacin.

La herencia denota una relacin de generalizacin / especializacin (una relacin <<es
un>>), y aparece como una asociacin con una cabeza de flecha. La flecha apunta a la
superclase, y el extremo opuesto de la asociacin designa la subclase. La subclase
hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no
pueden llevar indicaciones de cardinalidad.

La Posesin: denota una relacin todo / parte (relacin <<tiene un>> o agregacin),
aparece como una asociacin con un crculo relleno en el extremo que seala al
agregado, la clase que est en el otro extremo denota la parte cuyas instancias estn
contenidas por el objeto agregado.

La Utilizacin: denota una relacin cliente / servidor y aparece como una asociacin con
una circunferencia en el extremo que denota al cliente. En esta relacin de alguna forma
el cliente depende del servidor para que ste le proporcione determinados servicios.

Figura 3.3. Utilizacin

Diagramas de Objetos

Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones
en el diseo lgico 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, tambin se pueden
especificar algunos atributos del objeto.



Figura 3.4. Objeto

Relaciones entre objetos: los objetos interaccionan a travs de sus enlaces con otros
objetos, un enlace es una instancia de una asociacin, 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 direccin que un mensaje o en
direccin contraria. El mostrar explcitamente la direccin del flujo de datos ayuda a
explicar la semntica de un escenario particular.

Objetos activos: son aquellos que incorporan su propio hilo de control.

Figura 3.6. Objetos activos

Diagramas de mdulos


Se utiliza un diagrama de mdulos para mostrar la asignacin de clases y objetos a
mdulos en el diseo fsico de un sistema. Un solo diagrama de mdulos representa una
vista de la estructura de mdulos de un sistema. Los dos elementos esenciales de un
diagrama de mdulos son los mdulos y sus dependencias.

Programa principal: Denota un archivo que contiene la raz del programa.

Especificacin y cuerpo: Denotan archivos que contienen la declaracin y la definicin de
las entidades.

Subsistema: Los subsistemas sirven para modularizar el modelo fsico de un sistema. Un
subsistema es un agregado que contiene otros mdulos y otros subsistemas. Cada
mdulo engloba la declaracin o definicin de clases, objetos y otros detalles del lenguaje.

Dependencias: la nica relacin que puede darse entre dos mdulos es una dependencia
de compilacin, representada por una lnea dirigida que apunta al mdulo 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 asignacin de procesos a procesadores
en el diseo fsico 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 lneas no dirigidas para indicar conexiones entre procesadores y/o
dispositivos.



Figura 3.7. Diagrama de procesos

El proceso de diseo orientado a objetos no puede describirse mediante reglas, aunque
est bastante bien definido como para brindar un proceso predecible y repetible para una
organizacin 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
econmica, entregado en tiempo, y es flexible al cambio y al crecimiento.

3.2. OOSE

Este mtodo 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 anlisis, construccin y prueba.

OOSE presenta cinco tcnicas para modelar un sistema:

Modelo de requerimientos: delimita el sistema y define su funcionalidad.
Modelo de anlisis: estructura el sistema, modelando tres tipos de objetos (objetos
de interface, objetos entidad y objetos de control).

Modelo de diseo: refina el modelo de anlisis y lo adapta a un ambiente de
implementacin. Consiste de diagramas de interaccin y diagramas de transicin
de estados.
Modelo de implementacin: consiste en el cdigo fuente de los objetos
especificados en el modelo de diseo.
Modelo de prueba: es llevado a cabo mediante la realizacin de pruebas al modelo
de implementacin.

La idea bsica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relacin entre ellos
es importante. Para ser posible el mantenimiento del sistema es tambin necesario que
los modelos sean tangibles.

3.2.1. Introduccin

Este mtodo proporciona un soporte para el diseo creativo de productos de software,
inclusive a escala industrial. El autor plantea el problema del diseo y construccin de
software haciendo una comparacin con la industria de la construccin, contemplando las
siguientes fases:

Herramientas. Soportan todos los aspectos de la empresa, explcitamente las
actividades de arquitectura, mtodos y procesos.
Procesos. Permite el escalamiento de los mtodos, de tal forma que puedan ser
aplicados a proyectos de forma interactiva y en partes.
Mtodos. Establece de manera explcita los procedimientos etapa por etapa que
deben seguirse para aplicar la arquitectura al proyecto.
Arquitectura. Una buena estructura del sistema es fcil de entender, de cambiar y
realizar pruebas y mantenimiento. Las propiedades del sistema determinan cmo
la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la
arquitectura son extremadamente importantes y forman la base del mtodo.

Diseo creativo. Las actividades creativas de un desarrollo, consisten en la
transformacin de un conjunto de requerimientos y nociones vagas, en un plan
estructurado de construccin y un plan de accin para su implementacin .El diseo
creativo tomando como referencia una base arquitectnica es seguir paso a paso los
mtodos y procesos con la asistencia de herramientas, para convertir los requerimientos
dentro de una arquitectura viable para la construccin de un proyecto incluyendo la
creacin de prototipos.


Un aspecto importante durante el desarrollo del sistema, es considerar explcitamente el
proceso de cambio.

Todos los sistemas cambian durante su ciclo de vida. Hoy en da el desarrollo de los
nuevos mtodos 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
incorporndose en nuevas versiones.

La primera versin de un sistema representa una pequea parte de una composicin
durante el ciclo de vida del sistema.

Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva
versin 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 anlisis. Especifica el comportamiento funcional del sistema bajo
prcticamente circunstancias ideales y sin hacer alusin a un ambiente particular de
implementacin.

Construccin. La primera actividad en la construccin consiste en la implementacin de
los detalles que conciernen a la arquitectura y construccin del plan, que es ir de una
mayor abstraccin a concretizar ms el plan.

Diseo. Formaliza el modelo de anlisis en trminos del ambiente de implementacin y
especifica la identidad de los bloques de construccin.

Prueba del sistema. Consiste en la verificacin del trabajo de cada uno de los paquetes
de servicio definidos en el modelo de anlisis Esta fase tiene lugar en varios niveles,
desde funciones especficas, hasta el sistema completo.

Desarrollo incremental. El desarrollo del sistema es usualmente un proceso el cual toma
varios aos para su terminacin. La especificacin es seguida por el anlisis, la
construccin y prueba del sistema completo. Este mtodo puede trabajar si todos los
requerimientos del sistema son conocidos del conjunto de salida.

En la mayora de los casos, conviene mejor desarrollar el sistema etapa por etapa,
empezando con unas cuantas funciones principales, como se va aclarando la
comprensin del sistema en cuanto a su funcionalidad se van agregando nuevas
funciones, de esta forma el sistema va creciendo.
Sistema de desarrollo y metodologa. Cuando se desarrolla un sistema grande es
importante conocer cmo cada uno de los pasos del mtodo interacta y cmo ellos

compiten dentro del desarrollo del proceso. Se hace hincapi en la discusin entre el
proceso de desarrollo y las ideas bsicas que hay detrs del mtodo lo que determina la
seleccin 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 consideracin. Se trabaja con 5 modelos:

1. El modelo de requerimientos: El objetivo es la captura de requerimientos
funcionales.
2. El modelo de anlisis: El objetivo es dar al sistema una estructura de objetos
robusta y flexible a los cambios.
3. Modelo de diseo: Tiene como objetivo adoptar y refinar la estructura de objetos
en el ambiente actual de implementacin.
4. El modelo de implementacin: Tiene como objetivo implementar el sistema.
5. El modelo de prueba: Su objetivo es verificar el sistema.

La idea bsica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la relacin entre ellos
es importante. Para hacer posible el mantenimiento del sistema es tambin necesario que
los modelos sean tangibles.

Modelo de requerimientos
Actores y Casos de Uso
La primera transformacin hecha de la especificacin de requerimientos para el modelo
de requerimientos consiste en:

Un modelo de caso de uso
Descripcin de la interface
Un modelo en el dominio del problema

Figura 3.8. Modelo de caso de uso


El modelo de caso de uso utiliza actores y caso de uso. Estos conceptos son usados para
definir si existe contacto externo con el sistema (actores), y qu debera ser hecho por el
sistema (caso de uso).

Los actores representan quienes interactan con el sistema. Representan todas las
necesidades de cambio de informacin con el sistema. Dado que el actor representa la
parte exterior del sistema no se describirn 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 anlisis

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 informacin para este sistema se enfoca en la captura de:

Informacin: Especifica la informacin de ayuda en el sistema. As como describe
el estado interno del sistema.
Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica
cundo y cmo el sistema cambia de estado.
Presentacin: Detalla la presentacin del sistema al mundo exterior.

Figura 3.9. Dimensiones del modelo de anlisis

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



Figura 3.10. Tipos de objeto

Cada objeto al menos captura dos de las tres dimensiones del modelo de anlisis, sin
embargo cada uno de ellos tiene cierta inclinacin hacia una de las dimensiones.

Figura 3.11. Dimensiones del modelo de anlisis

El modelo de diseo

El proceso de construccin edifica el sistema usando tanto el modelo de anlisis y el
modelo de requerimientos. Primero se crea el modelo de diseo que es un refinamiento y
formalizacin del modelo de anlisis. Al inicio del trabajo cuando se desarrolla el modelo
de diseo es para adaptarlo a la implementacin del ambiente actual.

Figura 3.12. Implementacin del ambiente

Una diferencia entre el modelo de anlisis y el modelo de diseo es que el modelo de
anlisis debe ser visto como un modelo conceptual o lgico del sistema, y el modelo de

diseo contiene el cdigo, por lo cual el modelo de diseo deber ser una representacin
de la manera como el cdigo fuente es estructurado, manejado y escrito.

Figura 3.13. Consecuencias del ambiente

El modelo de Implementacin

La implementacin del modelo consiste de la notacin del cdigo. La informacin de
espacio es la opcin del lenguaje de programacin que se usa. No necesariamente se
requiere de un lenguaje de programacin orientada a objeto, sin embargo, si se
recomienda el uso de un lenguaje de programacin orientada a objeto, desde la
concepcin inicial hasta la construccin. La base para la implementacin es el modelo de
diseo. Aqu se especifica la interface dcada 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 abstraccin de algo, con la finalidad de comprenderlo, antes de
construirlo, ya que un modelo omite los detalles no esenciales, es ms sencillo
manejarlos, que manejar la entidad original.

Esta tcnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos
modelo dinmico y modelo funcional.


3.3.1. Introduccin

El modelo de objetos. Es el modelo ms 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 esttica del sistema. El modelo de objetos se representa
mediante un diagrama de clases.

El modelo dinmico. 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 funcin" del
sistema, mediante la transformacin de valores de los datos. Se representa mediante un
diagrama de flujo.

Cada modelo describe un aspecto del sistema pero contiene referencias a los dems
modelos. Lo cual indica que los tres no son totalmente independientes.

Pasos del proceso de desarrollo orientado a objetos:
Conceptualizacin: Se describen los requerimientos para la solucin del sistema.
Comienza identificando las necesidades desde el punto de vista de los usuarios. Dicha
informacin puede ser extrada de los casos de uso y del dominio del problema.

Anlisis: Entender y modelar el problema en el dominio de la aplicacin.
Diseo del sistema: Determinar la arquitectura del sistema en trminos de subsistemas.
Diseo de objetos: Refinar y optimizar el modelo de anlisis, agregando conceptos de
programacin.
Cdigo: Implementar las clases de objetos en un lenguaje de programacin.
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 abstraccin hasta llevarlo a un nivel de detalle que
finalmente representa la solucin del problema.



3.3.2. Modelos

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

1. Identificacin de objetos y/o clases.
2. Crear un diccionario de datos.
3. Identificacin de las asociaciones y agregaciones entre los objetos.
4. Identificacin de atributos y enlaces.
5. Organizacin y simplificacin de las clases empleando herencia.
6. Verificacin de las vas 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 mdulos.

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 trminos
del dominio del problema. Adems 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 rectngulo 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 comprensin
del sistema, entonces el rectngulo solo se queda con el nombre de la clase.

Modelo dinmico = Diagrama de estados + diagrama global de flujo de sucesos.
Escenario:
Es la representacin escrita de los casos de uso y de la interaccin de los actores con
ellos para especificar el propsito del sistema.



Figura 3.16. Escenario

Diagramas de estados: Relaciona sucesos y estados. Un diagrama de estados se
representa mediante estados, transiciones, condiciones y acciones.

Estados: Los estados representan las respuestas de los objetos a varios sucesos en
determinado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado del
objeto. Se representan mediante cuadros redondeados que contienen un nombre.

Transiciones: Se representan mediante flechas que salen del estado receptor hasta l y
el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha
transicin, cada transicin 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 condicin se puede pensar como una proteccin en las transiciones,
debido a que si se cumple dicha condicin la transicin se dar y podr pasar el objeto de
un estado a otro, si dicha condicin no se cumple inclusive podra pasar a otro estado
mediante otra transicin o quedarse en el estado receptor hasta que la condicin se
cumpla.

Accin: Es una operacin que va asociada a un suceso y se representa mediante una
barra / y el nombre de la accin, despus del nombre de la transicin.

Modelo Funcional = Diagrama de flujo de datos + restricciones. Mediante el modelo
funcional se puede observar los resultados que se tienen de un clculo de valores,
especificando solamente entradas y salidas de los valores, mas no como son calculados
estos. El modelo funcional consta bsicamente de diagramas de flujo de datos. Los
diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a travs
de procesos los cuales modifican dichos valores para transformarlos en otros. Los
diagramas de flujo estn compuestos de:
Procesos
Flujos de datos
Actores
Almacenes


Procesos: se representan mediante una elipse, los procesos tienen como entrada datos,
los cuales sern transformados, por lo cual un proceso es visto como un mtodo de una
operacin 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. Adems de trasladar los datos a otros procesos, los flujos de datos pueden
usarse para copiar un valor, realizar la composicin de un agregado y as como su
inverso.

Actividad 1. Metodologa para la generacin de sistemas OO

La presente actividad tiene como propsito que reflexiones acerca de las metodologas
vistas hasta ahora cul de ellas te parece la ms adecuada a diseos orientado a objetos.

1. Retoma las lecturas de los temas 3.1. Booch, 3.2. OOSE y 3.3. OMT.

2. Identifica las metodologas y los modelos para disear con base en la Orientacin a
Objetos.

3. Ingresa al foro y genera una nueva entrada.

3.4. UML

UML es una tcnica desde en 1994 abarca aspectos de todos los mtodos de diseo los
antecesores de UML son Grady Booch, autor del mtodo Booch; James Rumbaugh, autor

del mtodo OMT e Ivar Jacobson, autor de los mtodos OOSE y Objectory. La versin 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, aeronutica, finanzas, etc.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.

3.4.1. Introduccin

El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con
objetos, anlisis y diseo, con una buena consistencia del lenguaje para especificar,
visualizar, construir y documentar un sistema de software.

Esta especificacin representa la convergencia de las mejores prcticas en la tecnologa
de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos
derivado de las tres metodologas; (Booch, OMT y OOSE). Al conjuntar los mtodos de
Booch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de stos
y otros mtodos.

El UML da la idea que lo que se est haciendo, se realiza con mtodos 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 informacin de los modelos.
Proporcionar mecanismos de extensibilidad y especializacin para ampliar los
conceptos bsicos.
Ser independiente de un lenguaje en particular y del proceso de desarrollo.
Proporcionar bases formales para la comprensin del Lenguaje de Modelado.
Integracin en una mejor prctica.

El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el
consenso de los conceptos de modelado bsico y permite desviaciones, las cuales se

expresan en trminos de mecanismos de extensin. Es un conjunto preciso que consiste
en la definicin de la semntica y notacin del UML, definiendo tambin cmo se maneja
el Lenguaje de Especificacin de Objetos.

Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas
complejos, y en cuanto ms complejos se vuelven los sistemas, es necesario tener
mejores tcnicas de modelado. El contar con una metodologa universal para el desarrollo
de sistemas de software es de gran beneficio en la construccin de todo tipo de sistemas.
Disponer de buenos modelos facilita la comunicacin entre equipos de trabajo en un gran
proyecto.

El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estndar, es
la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la
tecnologa Orientada a Objetos.

El documento describe los mecanismos de la notacin para la representacin visual del
UML.

Existen bsicamente cuatro constructores grficos usados en la notacin del UML; iconos,
smbolos de 2 dimensiones, uniones y cadenas.

Icono. Es una figura grfica de tamao y forma definida, stos pueden aparecer dentro del
rea de los smbolos, en la terminacin de una unin, etc.
Smbolos de 2 dimensiones. Son de tamao variable, pueden contener listas de cadenas
u otros smbolos. Las uniones se conectan a los smbolos de 2 dimensiones como
terminacin de la unin sobre alguna parte del contorno de dicho smbolo.
Uniones. Son segmentos de lnea con sus extremos terminados en algn smbolo de 2
dimensiones.
Cadenas. Representan conceptos, pueden existir como un elemento dentro de un smbolo
o dentro de un compartimiento de un smbolo, como elementos de una lista, como
etiquetas de un smbolo o unin, o como un elemento estndar dentro de un diagrama.

El documento est dividido en varios captulos de acuerdo a los conceptos semnticos, o
por los diferentes tipos de diagramas. Cada captulo est subdividido por los elementos
que conforman el diagrama, y para cada elemento se cuenta con las siguientes
secciones:

El nombre de la notacin a describir
Semntica
Notacin
Mapeo
Opciones de presentacin


Cada punto cuenta con su propia descripcin:

Nombre de la notacin: Especifica el nombre de la notacin
Semntica: Es un breve resumen de la semntica para dicho elemento.
Notacin: Explica la representacin dotacional de la semntica mediante un diagrama.
Obviamente para cada caso se utilizan un diagrama diferente que proporciona la
identificacin de la semntica del grafo especificado.
Mapeo: Indica cmo la notacin puede ser representada como informacin semntica. Es
decir qu tipo de diagrama se utiliza, con cules rutas se maneja y cmo trabaja una
estructura conectada con otra estructura dentro de un mismo diagrama. Dando as el
sentido de saber interpretar la notacin que se presenta y con qu fin es utilizada.
Opciones de presentacin: Son herramientas que pueden ser utilizadas para dar ms
nfasis a la notacin cuando sta lo requiera dejndola ms completa y estructurada. En
varios elementos esta seccin no se presenta debido a que no tiene opciones de
presentacin.

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)

El Lenguaje de Especificacin 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
caractersticas de un lenguaje de expresin, de un lenguaje de modelado y de un lenguaje
formal.

El OCL es un lenguaje de expresin puro. Por lo tanto, garantiza que una expresin 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 expresin OCL, aun
cuando una expresin OCL puede usarse para especificar un cambio de estado, por
ejemplo, en una post-condicin.

Todos los valores, de todos los objetos, incluyendo todos los enlaces, no cambiarn,
cuando una expresin OCL es evaluada, simplemente devuelve un valor.

El OCL no es un lenguaje de programacin, por lo tanto, no es posible escribir lgica de
programa o flujo de control en OCL. No es posible invocar procesos o activar operaciones
que no sean consultas en OCL. Dado que el OCL es un lenguaje de modelado en primer
lugar, es posible que haya cosas en l que no sean directamente ejecutables.


Como el OCL es un lenguaje de modelado, toda consideracin de implementacin est
fuera de su alcance, y no puede ser expresada en el lenguaje OCL. Conceptualmente,
cada expresin OCL es atmica. El estado de los objetos en el sistema no puede variar
durante la evaluacin.

OCL es un lenguaje formal donde todos los constructores tienen un significado
formalmente definido, la especificacin 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 propsitos:

Para especificar caractersticas estticas sobre clases y tipos en un modelo de
clases.
Para especificar caractersticas estticas de tipo para Estereotipos.
Para especificar pre y post-condiciones sobre Operaciones y Mtodos.
Como lenguaje de navegacin.
Para especificar restricciones sobre operaciones:
Dentro del documento Semntica del UML, el OCL es usado en la seccin
reglas bien formuladas, como constantes estticas sobre la meta-clase en la
sintaxis abstracta. En varios lugares tambin es usado para definir
operaciones adicionales, que son tomadas en cuenta en la formacin 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 Mtodos como a Operaciones.

Actividad 2. Cuadro comparativo de las diferentes metodologas

La presente actividad tiene la finalidad de que apliques cada uno de los conceptos
bsicos de las metodologas de diseo vistas hasta ahora y adems, que investigues las
fechas en las que implementaron dichas metodologas.

1. Investiga las fechas en que fueron implementadas las metodologas OO.

2. En un archivo de texto, elabora un cuadro comparativo donde incluyas las
caractersticas de cada una de las metodologas OO y la fecha en que fueron
implementadas.


3. Guarda la Actividad con el nombre ADOO_U3_A2_XXYZ donde XX es apellido(s) .y
YY es tu nombre(s).

4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
unidad 3 del curso, es necesario que resuelvas la autoevaluacin. Recuerda que es muy
importante leer cuidadosamente los planteamientos indicados y elegir la opcin adecuada
para cada uno.

Evidencia de aprendizaje. Cuadro comparativo de los mtodos de
modelado

Como parte de la evaluacin de esta unidad, lleva a cabo la siguiente actividad cuyo
propsito 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 conclusin donde expreses cules seran los
modelos ms adecuados a utilizar en cada caso.

3. Consulta la Escala de Evaluacin.

4. Guarda la evidencia con el nombre DOO_U3_EA_XXYY donde XX es tu apellido(s) y
YY tu nombre(s).

5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tu
Facilitador(a), podrs enviar una segunda versin de tu actividad.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a)

presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado
DOO_U3_ATR_XXYZ. Posteriormente enva 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 metodologas de
diseo para la generacin de Sistemas Orientados a Objetos, tales como: Boosh, OOSE,
OMT, en cada uno de ellos se vio una breve introduccin y su modelo. Por ltimo el origen
de la metodologa UML, la cual fue a travs 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
ests preparado(a) para seguir con la unidad 4, en donde continuars con El diseo
orientado a objetos con UML, a travs de la representacin de objetos y clases con
diagramas y documentacin para el diseo del software con UML, en dichos diagramas se
manejarn casos de uso, escenarios del caso de uso, diagramas de actividades,
secuencial, de clase y de grfico de estado. Todo ello con el fin de obtener el prototipo
final al terminar el curso de Anlisis y Diseo Orientado a Objetos.

Para saber ms.

En el siguiente documento encontrars un ejemplo real de anlisis aplicado al diseo de
un sistema escolar:

Desarrollo de un sistema de administracin escolar acadmica para la escuela
Cristbal Coln bajo plataforma web:
http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf

Fuentes de consulta

Booch-Grady (2009) Anlisis y Diseo Orientado a Objetos con aplicaciones.
Mxico: Pearson Educacin.
Fowler, M. & Scott, K. (1999) UML GOTA A GOTA Mxico: Addison Wesley
Graham, I. (2002) Mtodos Orientados a Objetos Mxico: Addison Wesley/Daz de
Santos.

Jacobson, I. (1992) Object-Oriented Software Engineering A Use Case Driven
Aproach Mxico: Addison-Wesley
James, R., Blaha, M., Premerlani, W. & Eddym, F. (1990) Object Oriented
Modeling and Design. Mxico: Pretice Hall.
Larman, C. (2004) Applying UML and Patterns An Introduction to object-Oriented
Analysis and Design Mxico: Prentice Hall
Martin, J. & Odell, J. (1990) Anlisis y Diseo Orientado a Objetos Mxico:
Prentice Hall Iberoamericana.
Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML
Mxico: Addison Wesley
Wirfs, R. & Wiener, L. (1990). Designing Object Oriented Softwarem. Mxico:
Pretince Hall.

Metodologiasdedisenoparalageneracion de Sistemas Orientadosobjetos

Cargado por

Copyright:

Formatos disponibles

También podría gustarte

Metodologiasdedisenoparalageneracion de Sistemas Orientadosobjetos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologiasdedisenoparalageneracion de Sistemas Orientadosobjetos

Cargado por

Copyright:

Formatos disponibles

Anlisis y diseo orientado a objetos

También podría gustarte