Unidad 3. Metodologias de Diseno para La Generacion de Sistemas Orientados A Objetos

Anlisis y diseo orientado a objetos
Programa desarrollado
Ingeniera en Desarrollo de software CUATRIMESTRE: 04
Programa de la asignatura: Anlisis y diseo orientado a objetos Unidad 3. Metodologas de diseo para la generacin de sistemas orientados a objetos
Clave: 160920413 / 150920413
Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software

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,
3

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.
Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software 6

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

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).
12

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

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
16

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
17

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

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

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

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

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

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

Unidad 3. Metodologias de Diseno para La Generacion de Sistemas Orientados A Objetos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Unidad 3. Metodologias de Diseno para La Generacion de Sistemas Orientados A Objetos

Caricato da

Copyright:

Formati disponibili

Anlisis y diseo orientado a objetos

Ingeniera en Desarrollo de software CUATRIMESTRE: 04

Clave: 160920413 / 150920413

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Figura 3.2. Conexiones entre clases

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Figura 3.6. Objetos activos Diagramas de mdulos

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

Figura 3.8. Modelo de caso de uso

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

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

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

Actividad 1. Metodologa para la generacin de sistemas OO

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

Anlisis y diseo orientado a objetos

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)

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

Anlisis y diseo orientado a objetos

Actividad 2. Cuadro comparativo de las diferentes metodologas

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

Anlisis y diseo orientado a objetos

Evidencia de aprendizaje. Cuadro comparativo de los mtodos de modelado

Anlisis y diseo orientado a objetos

Para saber ms.

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

Anlisis y diseo orientado a objetos

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

Potrebbero piacerti anche