3.

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

Presentación de la unidad
En las metodologías de análisis y diseño orientado a objetos, se utilizan algunos conceptos que se definen a continuación.        Método. Es un conjunto de lineamientos y reglas, incluyendo los siguientes componentes. Conceptos de modelado. Permiten la captura de la semántica y el conocimiento acerca de un problema y su solución. Modelo es una representación formal de un sistema con cierto nivel de abstracción. En las etapas de especificación de requerimientos y análisis el nivel de abstracción normalmente es alto, omitiendo detalles de implementación. Meta modelo. Es un modelo que describe otros modelos, describe los conceptos del método modelo y sus relaciones, define los modelos legales que pueden ser construidos dentro del método, describe la información que debe ser capturada. Vistas y notaciones. Son útiles en la presentación fundamental del modelo de información para que los seres humanos puedan comprenderla, examinarla y modificarla en su caso. Una vista solo muestra una parte de la semántica del modelo y diferentes vistas pueden presentar la misma información en varias formas. Notación. Permite construir, examinar y manipular modelos, el mismo modelo se puede dibujar de diferentes maneras mediante el uso de diferentes símbolos, donde algunos de ellos pueden tener el mismo significado. Cada persona puede adoptar su propio formato para describir sus diagramas. Proceso de desarrollo iterativo. Representa una secuencia de pasos para la construcción e implementación de modelos. El proceso puede estar distribuido en varios niveles de detalle, desde el nivel más alto del proyecto, hasta etapas específicas para la construcción de modelos de bajo nivel. El proceso indica qué modelos se deberán construir y cómo construirlos. Proceso. Es la guía que indica como producir un modelo, proporciona un esqueleto de trabajo (frameworks) para el desarrollo, describe los artefactos a ser producidos y las etapas para producirlos. A alto nivel, describe el desarrollo del ciclo de vida y las etapas de iteración dentro de él. A bajo nivel describe un esqueleto de trabajo para la producción de modelos; las etapas para la construcción del modelo, lineamientos para describir componentes de él, principios de diseño a seguirse, mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas rojas para identificar posibles problemas. Patrón. Es una solución estándar escrita para resolver un problema, basada en una secuencia de tiempo. No existen museos de programas donde los nuevos diseñadores puedan aprender, emulando programas que allí existen, mas bien, tratan de captar ideas de los diseñadores expertos. Actualmente existe un Movimiento de Patrones con el propósito de coleccionar, catalogar y explicar patrones útiles de diseño, de tal forma que otros diseñadores puedan aprender de

ellos. Por lo tanto, Los Patrones son resúmenes de casos de diseño basados en la experiencia. Reglas de Diseño. Son estados o propiedades que deberán llevarse a cabo u omitirse en un diseño o estrategias generales de diseño a utilizar. Tips y Reglas de dedo. Son recomendaciones que se aplican donde sea necesario, no se organizan en etapas. Son presentaciones informales de patrones.

En los métodos AOO/DOO existen dos tipos principales, dividiendo a estos en:  Estáticos (enfocados a datos), lo importante es la estructura de datos anexa a los objetos y las operaciones que sobre ella operan.  Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un objeto tiene sentido en estos métodos cuando exhibe un comportamiento diferencial respecto del resto delos objetos.

En la tabla anterior se mezclan métodos de análisis y de diseño porque, pese a lo que anuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño se difumina, aquí presentamos los más utilizados y que dieron origen al que actualmente se utiliza para el ADOO.

relaciones y otras entidades y cada diagrama representa una proyección de estos modelos. . 3. OOSE (Object-Oriented Software Engineering / Ingeniería de software orientado a objetos).Propósito Con el transcurso de esta unidad ubicarás las diferentes metodologías para el diseño de sistemas orientados a objetos: Booch. Booch Es una metodología que se utiliza en el análisis y diseño de software creada por Booch durante su estancia en Rational Software Corporation. En el estado estable. éstos reflejan "toda la verdad" sobre sus clases. soportando el desarrollo iterativo e incremental. Introducción El método cuenta con una notación expresiva y bien definida que le permite al diseñador expresar sus ideas y concentrarse en problemas más serios. Para cada dimensión se definen una serie de diagramas que denotan una vista de los modelos del sistema. El método BOOCH define modelos para describir un sistema. Son necesarias dos dimensiones para especificar la estructura y comportamiento de un sistema orientado a objetos: • • Dimensión uno: Física / Lógica. todos estos diagramas deben ser consistentes con el modelo y también consistentes entre ellos mismos. OMT (Object Modeling Technique / Técnica de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de Modelado) las cuales nos servirán después de hacer un análisis para hacer un buen diseño apoyado con estas técnicas. Dimensión dos: Estática / Dinámica. El método incluye diferentes diagramas según el enfoque que se le dé ya sea:       De clases De objetos De transición de estados De módulos De procesos De interacción 3.1.1.1.

Diagrama de transición de estados: Muestra el comportamiento de cada instancia de una clase.1. utilizada en la etapa de análisis.Dimensión lógica: Describe la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema o para definir la arquitectura del sistema. Dimensión estática: Están formados por los diagramas de: 1. 4. los eventos que provocan una transición de un estado a otro y las acciones que resultan de este cambio de estado. 2. 3. Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el diseño físico de un sistema. en la visión lógica de un sistema. 3. Dimensión física: Describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema. Diagramas de procesos: Muestran la asignación de procesos a procesadores en el diseño físico de un sistema. La figura siguiente muestra el icono que se utiliza para representar una clase en un diagrama de clases. Están en el mismo contexto que los diagramas de objetos. por lo que. Dimensión dinámica: La semántica dinámica de un problema se expresa mediante los siguientes diagramas: 1. Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa de diseño lógico de un sistema. Diagramas de interacción: Muestra el orden temporal en que se suceden los mensajes en un conjunto de objetos que representan un escenario. cada clase puede contar con este tipo de diagrama. Modelos Diagramas de Clases Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. 2. Los dos elementos esenciales de un diagrama de clases son: las clases y sus relaciones básicas. Diagramas de clases: Muestra la existencia de clases y sus relaciones. es útil exponer algunos de los atributos y operaciones asociados con una clase: . En ciertos diagramas de clases.2.

A:C Nombre y clase del atributo. Conexiones entre clases . nombre y parámetros formales (si los hay).1. A Nombre del atributo solamente. R N(Argumento) Clase de retorno de la operación. Las conexiones esenciales entre clases incluyen las siguientes relaciones: Figura 3. C Clase del atributo solamente. N() Nombre de la operación solamente.2. Las relaciones de clase representan una colaboración con otras clases de diversas maneras. Las operaciones denotan algún servicio proporcionado por la clase. durante el diseño expresan una propiedad singular de la clase.Figura 3. se distinguen de los atributos añadiendo paréntesis. Clase Los atributos denotan una parte de un objeto agregado.

Objetos en la figura siguiente muestra el icono que se usa para representar un objeto en un diagrama de objetos. y aparece como una asociación con una cabeza de flecha.La asociación conecta dos clases y denota una conexión semántica. Las relaciones de herencia no pueden llevar indicaciones de cardinalidad. La subclase hereda la estructura y comportamiento de su superclase. La flecha apunta a la superclase. y el extremo opuesto de la asociación designa la subclase. la clase que está en el otro extremo denota la parte cuyas instancias están contenidas por el objeto agregado. . se etiquetan con expresiones sustantivas. Los dos elementos esenciales de un diagrama de objetos son los objetos y sus relaciones. también se pueden especificar algunos atributos del objeto. La Posesión: denota una relación todo / parte (relación <<tiene un>> o agregación). denotando la naturaleza de la relación. La Utilización: denota una relación cliente / servidor y aparece como una asociación con una circunferencia en el extremo que denota al cliente. aparece como una asociación con un círculo relleno en el extremo que señala al agregado. En esta relación de alguna forma el cliente depende del servidor para que éste le proporcione determinados servicios. La herencia denota una relación de generalización / especialización (una relación <<es un>>). Al igual que en el diagrama de clases. Diagramas de Objetos Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema.

al igual que un objeto es una instancia de una clase. Objetos activos . Figura 3.4.6. Objetos activos: son aquellos que incorporan su propio hilo de control.Figura 3. Objeto Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros objetos.5. un enlace es una instancia de una asociación. El mostrar explícitamente la dirección del flujo de datos ayuda a explicar la semántica de un escenario particular. Relaciones entre objetos Flujo de datos: los datos pueden fluir en la misma dirección que un mensaje o en dirección contraria. Figura 3.

Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Conexiones. Cada módulo engloba la declaración o definición de clases. Un solo diagrama de procesos presenta una vista de la estructura de procesos de un sistema. Programa principal: Denota un archivo que contiene la raíz del programa. Especificación y cuerpo: Denotan archivos que contienen la declaración y la definición de las entidades. Elementos del diagrama • • • Procesadores. Las flechas denotan dependencias.Diagramas de módulos Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. . Diagrama de procesos Se usa un diagrama de procesos para mostrar la asignación de procesos a procesadores en el diseño físico de un sistema. Un subsistema es un agregado que contiene otros módulos y otros subsistemas. objetos y otros detalles del lenguaje. Elemento de hardware capaz de ejecutar programas. Dispositivos. Dependencias: la única relación que puede darse entre dos módulos es una dependencia de compilación. Elemento de hardware incapaz de ejecutar un programa. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias. Son líneas no dirigidas para indicar conexiones entre procesadores y/o dispositivos. representada por una línea dirigida que apunta al módulo respecto al cual existe la dependencia. la flecha sale del el icono dependiente.

este modelo de casos de uso sirve como un modelo central para otros modelos. objetos entidad y objetos de control).7. OOSE presenta cinco técnicas para modelar un sistema: • • • • • Modelo de requerimientos: delimita el sistema y define su funcionalidad. Introducción Este método proporciona un soporte para el diseño creativo de productos de software. Es por eso que la relación entre ellos es importante. y es flexible al cambio y al crecimiento. Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de implementación.Figura 3. Consiste de diagramas de interacción y diagramas de transición de estados. inclusive a escala industrial. modelando tres tipos de objetos (objetos de interface. aunque está bastante bien definido como para brindar un proceso predecible y repetible para una organización de software madura. Un proyecto de software bien hecho es aquel en el que el software entregado satisface y posiblemente excede las expectativas del cliente. Modelo de análisis: estructura el sistema. El autor plantea el problema del diseño y construcción de software haciendo una comparación con la industria de la construcción. contemplando las siguientes fases: . Modelo de implementación: consiste en el código fuente de los objetos especificados en el modelo de diseño. OOSE Este método fue desarrollado por Ivar Jacobson OOSE “un enfoque para el manejo de casos de uso”. Este modelo es la base en la etapa de análisis.1. Se ha desarrollado de forma económica. Para ser posible el mantenimiento del sistema es también necesario que los modelos sean tangibles. Modelo de prueba: es llevado a cabo mediante la realización de pruebas al modelo de implementación.2. 3. construcción y prueba. entregado en tiempo. 3.2. Diagrama de procesos El proceso de diseño orientado a objetos no puede describirse mediante reglas. La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas.

consisten en la transformación de un conjunto de requerimientos y nociones vagas. Procesos. Modelo de análisis. Establece de manera explícita los procedimientos etapa por etapa que deben seguirse para aplicar la arquitectura al proyecto. La diferencia radica en que las entradas para cada etapa cambian en cada ciclo de vida. Una industrial del proceso debe por lo tanto saber sobre los cambios del sistema. Construcción.• • • • Herramientas. La primera versión de un sistema representa una pequeña parte de una composición durante el ciclo de vida del sistema. Especifica el comportamiento funcional del sistema bajo prácticamente circunstancias ideales y sin hacer alusión a un ambiente particular de implementación. Una buena estructura del sistema es fácil de entender. La primera actividad en la construcción consiste en la implementación de los detalles que conciernen a la arquitectura y construcción del plan. Las propiedades de la arquitectura son extremadamente importantes y forman la base del método. es considerar explícitamente el proceso de cambio. para convertir los requerimientos dentro de una arquitectura viable para la construcción de un proyecto incluyendo la creación de prototipos. de cambiar y realizar pruebas y mantenimiento. Permite el escalamiento de los métodos. Un aspecto importante durante el desarrollo del sistema. Un sistema normalmente desarrolla cambios incorporándose en nuevas versiones. que es ir de una mayor abstracción a concretizar más el plan. así como el costo del sistema. Métodos. Soportan todos los aspectos de la empresa. de tal forma que puedan ser aplicados a proyectos de forma interactiva y en partes. en un plan estructurado de construcción y un plan de acción para su implementación . Diseño. Arquitectura. métodos y procesos. así como para un sistema totalmente nuevo. Las propiedades del sistema determinan cómo la arquitectura debe ser tratada durante el tiempo de vida. Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva versión de un sistema. desde funciones específicas. Formaliza el modelo de análisis en términos del ambiente de implementación y especifica la identidad de los bloques de construcción. explícitamente las actividades de arquitectura. Consiste en la verificación del trabajo de cada uno de los paquetes de servicio definidos en el modelo de análisis Esta fase tiene lugar en varios niveles. hasta el sistema completo. . Las actividades creativas de un desarrollo. Todos los sistemas cambian durante su ciclo de vida.El diseño creativo tomando como referencia una base arquitectónica es seguir paso a paso los métodos y procesos con la asistencia de herramientas. Diseño creativo. Prueba del sistema. Hoy en día el desarrollo de los nuevos métodos es conocer qué cambios son los principales en la parte global del ciclo de vida.

Para hacer posible el mantenimiento del sistema es también necesario que los modelos sean tangibles. Modelos El sistema de desarrollo es una tarea compleja. El modelo de análisis: El objetivo es dar al sistema una estructura de objetos robusta y flexible a los cambios. Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetos en el ambiente actual de implementación. Es por eso que la relación entre ellos es importante. 3. Se trabaja con 5 modelos: 1.2. Modelo de requerimientos Actores y Casos de Uso La primera transformación hecha de la especificación de requerimientos para el modelo de requerimientos consiste en: Un modelo de caso de uso Descripción de la interface Un modelo en el dominio del problema . El modelo de implementación: Tiene como objetivo implementar el sistema. conviene mejor desarrollar el sistema etapa por etapa. El modelo de requerimientos: El objetivo es la captura de requerimientos funcionales. Este método puede trabajar si todos los requerimientos del sistema son conocidos del conjunto de salida. la construcción y prueba del sistema completo. La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas. En la mayoría de los casos. El modelo de prueba: Su objetivo es verificar el sistema. de esta forma el sistema va creciendo. El desarrollo del sistema es usualmente un proceso el cual toma varios años para su terminación. Se hace hincapié en la discusión entre el proceso de desarrollo y las ideas básicas que hay detrás del método lo que determina la selección de una arquitectura de un universo de arquitecturas. como se va aclarando la comprensión del sistema en cuanto a su funcionalidad se van agregando nuevas funciones. 3. empezando con unas cuantas funciones principales.2. Cuando se desarrolla un sistema grande es importante conocer cómo cada uno de los pasos del método interactúa y cómo ellos compiten dentro del desarrollo del proceso. Sistema de desarrollo y metodología. 5. 4.Desarrollo incremental. La especificación es seguida por el análisis. Algunos aspectos diferentes han sido tomados en consideración. 2.

Los actores representan quienes interactúan con el sistema. mientras que el actor es un rol que el usuario puede jugar. Modelo de análisis Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones del sistema y especificar su comportamiento.Figura 3. Modelo de caso de uso El modelo de caso de uso utiliza actores y caso de uso. Así como describe el estado interno del sistema. La información para este sistema se enfoca en la captura de: • • • Información: Especifica la información de ayuda en el sistema. Representan todas las necesidades de cambio de información con el sistema. Comportamiento: Especifica el comportamiento que adopta el sistema.8. Estos conceptos son usados para definir si existe contacto externo con el sistema (actores). Dado que el actor representa la parte exterior del sistema no se describirán detalles de ellos. Dimensiones del modelo de análisis . Especifica cuándo y cómo el sistema cambia de estado. Figura 3. La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el sistema. y qué debería ser hecho por el sistema (caso de uso). Presentación: Detalla la presentación del sistema al mundo exterior.9. Cuando el modelo de requerimientos ha sido desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema.

10. Dimensiones del modelo de análisis El modelo de diseño El proceso de construcción edifica el sistema usando tanto el modelo de análisis y el modelo de requerimientos. Figura 3. Al inicio del trabajo cuando se desarrolla el modelo de diseño es para adaptarlo a la implementación del ambiente actual. .11. Primero se crea el modelo de diseño que es un refinamiento y formalización del modelo de análisis. sin embargo cada uno de ellos tiene cierta inclinación hacia una de las dimensiones. Tipos de objeto Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis.Existen varios tipos de objetos usados para la estructura del sistema en el modelo de análisis Figura 3.

si recomienda el uso de un lenguaje de programación orientada a objeto.Figura 3. El modelo de requerimientos de nuevo representa una herramienta potente de prueba. desde concepción inicial hasta la construcción. Aquí se especifica la interface década bloque. OMT Un modelo es una abstracción de algo. Consecuencias del ambiente El modelo de Implementación La implementación del modelo consiste de la notación del código.3. La información espacio es la opción del lenguaje de programación que se usa. de se se la de 3. Figura 3. manejado y escrito. . Implementación del ambiente Una diferencia entre el modelo de análisis y el modelo de diseño es que el modelo de análisis debe ser visto como un modelo conceptual o lógico del sistema. La base para la implementación es el modelo diseño. No necesariamente requiere de un lenguaje de programación orientada a objeto. con la finalidad de comprenderlo.13. antes de construirlo. descrita en el modelo de requerimientos. Describe simplemente el estado de resultados de la prueba. el modelo de requerimientos es la base de verificado para el modelo de prueba. con todo lo anterior. que manejar la entidad original. sin embargo. por lo cual el modelo de diseño deberá ser una representación de la manera como el código fuente es estructurado. De manera simular se verifica la interface de usuario.12. se verifica que los objetos se comuniquen correctamente en dicho caso de uso. y el modelo de diseño contiene el código. El modelo de prueba El modelo de prueba es el último modelo a construir. al probar cada caso de uso. es más sencillo manejarlos. ya que un modelo omite los detalles no esenciales.

3. Cada modelo describe un aspecto del sistema pero contiene referencias a los demás modelos. así como sus atributos y operaciones. Diseño de objetos: Refinar y optimizar el modelo de análisis. lo que representa la estructura estática del sistema.1. ya que toma en cuenta tres puntos de vista: modelo de objetos modelo dinámico y modelo funcional. Proceso de desarrollo orientado a objetos Cada paso del proceso transforma algunas entradas para generar una salida diferente. Dicha información puede ser extraída de los casos de uso y del dominio del problema. 3. Comienza identificando las necesidades desde el punto de vista de los usuarios. Representa los aspectos temporales de comportamiento "de control del sistema. ya que en él se identifican las clases dentro del sistema junto con sus relaciones. Figura 3. El modelo funcional.Esta técnica es trilateral. Análisis: Entender y modelar el problema en el dominio de la aplicación.14. mediante la transformación de valores de los datos. Pasos del proceso de desarrollo orientado a objetos: Conceptualización: Se describen los requerimientos para la solución del sistema. Diseño del sistema: Determinar la arquitectura del sistema en términos de subsistemas. El modelo dinámico. Representa los aspectos transformacionales "de función" del sistema. Código: Implementar las clases de objetos en un lenguaje de programación. comenzando en un alto nivel de abstracción hasta llevarlo a un nivel de detalle que finalmente representa la solución del problema. Introducción El modelo de objetos. El modelo de objetos se representa mediante un diagrama de clases. mediante la secuencia de operaciones en el tiempo. Pruebas: se realizan para verificar el comportamiento de las clases y objetos que se encuentran descritos en los escenarios. Es el modelo más importante. Lo cual indica que los tres no son totalmente independientes. Se representa mediante un diagrama de flujo. . agregando conceptos de programación.

Modelo de objetos = Diagrama de modelo de objetos + diccionario de datos. en la primer parte se coloca el Nombre de la clase. 7. Identificación de objetos y/o clases. 4. pero sino se desea agregar ninguno de ellos. 8. . es porque no son tan importantes para la comprensión del sistema.2. Organización y simplificación de las clases empleando herencia.3.15. Figura 3. Identificación de atributos y enlaces. Escenario: Es la representación escrita de los casos de uso y de la interacción de los actores con ellos para especificar el propósito del sistema. entonces el rectángulo solo se queda con el nombre de la clase. Además se especifican los atributos y operaciones que distinguen a cada una de las clases y las relaciones con las que podemos conocer su responsabilidad en el sistema. Realizar las iteraciones necesarias para el refinamiento del modelo. Modelos Los pasos para construir el modelo de objetos son los siguientes: 1.3. Agrupar las clases en módulos. 2. Verificación de las vías de acceso necesarias para llevar a cabo las probables consultas. 6. Modelo dinámico = Diagrama de estados + diagrama global de flujo de sucesos. en la segunda y tercera parte se pueden agregar los atributos y las operaciones. 5. Crear un diccionario de datos. Nombre Clase Dentro del diagrama de clases. Identificación de las asociaciones y agregaciones entre los objetos. una clase se representa mediante un rectángulo donde pueden existir tres separaciones. Diagrama de clases En él se describen las clases que se descubrieron para el sistema analizado en términos del dominio del problema. 3.

después del nombre de la transición. si dicha condición no se cumple inclusive podría pasar a otro estado mediante otra transición o quedarse en el estado receptor hasta que la condición se cumpla. especificando solamente entradas y salidas de los valores. Modelo Funcional = Diagrama de flujo de datos + restricciones. lo cual indica que no deben de existir sucesos duplicados dentro de un estado. Transiciones: Se representan mediante flechas que salen del estado receptor hasta él y el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha transición. Un diagrama de estados se representa mediante estados. condiciones y acciones. Mediante el modelo funcional se puede observar los resultados que se tienen de un cálculo de valores. Estados: Los estados representan las respuestas de los objetos a varios sucesos en determinado tiempo dentro del sistema. Escenario Diagramas de estados: Relaciona sucesos y estados. Los diagramas de flujo están compuestos de: Procesos Flujos de datos Actores Almacenes . Se representan mediante cuadros redondeados que contienen un nombre.16. El modelo funcional consta básicamente de diagramas de flujo de datos. Condiciones: Una condición se puede pensar como una protección en las transiciones. Dicha respuesta puede cambiar el estado del objeto.Figura 3. Acción: Es una operación que va asociada a un suceso y se representa mediante una barra “/” y el nombre de la acción. mas no como son calculados estos. debido a que si se cumple dicha condición la transición se dará y podrá pasar el objeto de un estado a otro. transiciones. Los diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a través de procesos los cuales modifican dichos valores para transformarlos en otros. cada transición que sale de un estado corresponde a un suceso distinto.

Actividad 7. 2. autor del método OMT e Ivar Jacobson. La versión 1. autor de los métodos OOSE y Objectory. realizar la composición de un agregado y así como su inverso. 3. UML UML es una técnica desde en 1994 abarca aspectos de todos los métodos de diseño los antecesores de UML son Grady Booch. los cuales serán transformados.Procesos: se representan mediante una elipse. 4. la cual puede llevar el nombre o el tipo de dato. Ingresa a blog de tu equipo y publica con tus compañeros.3. la metodología más adecuada para diseñar un programa Orientado a Objetos. 5. cuál es. Con base en las aportaciones de tus compañeros(as). Identifica las metodologías y los modelos para diseñar con base en la Orientación a Objetos. los procesos tienen como entrada datos.0 . 3. decide. 3.4. Proceso Flujo de datos: un flujo de datos conecta la salida de un proceso a la entrada de otro. OOSE y 3. OMT. cuál de las herramientas vistas hasta ahora. Metodología para la generación de sistemas OO La presente actividad tiene como propósito que reflexiones acerca de las metodologías vistas hasta ahora cuál de ellas te parece la más adecuada a diseños orientado a objetos. autor del método Booch. los flujos de datos pueden usarse para copiar un valor. James Rumbaugh. Booch. por lo cual un proceso es visto como un método de una operación aplicada a una clase de objetos. Figura 3. 1. es la más adecuada.17. Retoma las lecturas de los temas 3. desde tu punto de vista.1. Contribuye con algún comentario sobre la importancia de cubrir los requerimientos.2. Además de trasladar los datos a otros procesos. Se representa en el diagrama por medio de una flecha.

OMT y OOSE). Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica. Proporcionar mecanismos de extensibilidad y especialización para ampliar los conceptos básicos. se realiza con métodos existentes. El UML da la idea que lo que se está haciendo. es necesario tener mejores técnicas de modelado. bancos. Establecer conceptos y artefactos ejecutables. Es un conjunto preciso que consiste en la definición de la semántica y notación del UML. Al conjuntar los métodos de Booch. Esta especificación representa la convergencia de las mejores prácticas en la tecnología de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos derivado de las tres metodologías. 3. construir y documentar un sistema de software. finanzas. Modelar sistemas orientados a objetos. Integración en una mejor práctica. visualizar. y en cuanto más complejos se vuelven los sistemas. OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de éstos y otros métodos. Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. Proporcionar bases formales para la comprensión del Lenguaje de Modelado. análisis y diseño. Mejor soporte a la planeación y al control de proyectos.1. aeronáutica. las cuales se expresan en términos de mecanismos de extensión.4. (Booch. Los objetivos que se fijaron al desarrollar el UML fueron los siguientes: • • • • • Proporcionar a los usuarios un Lenguaje de Modelado Visual de tal forma que sea posible intercambiar información de los modelos. etc. El contar con una metodología universal para el desarrollo de sistemas de software es de gran beneficio en la construcción de todo tipo de sistemas. Los principales beneficios de UML son: • • • • • • • Mejores tiempos totales de desarrollo (de 50 % o más). Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas complejos. Introducción El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con objetos. Ser independiente de un lenguaje en particular y del proceso de desarrollo. Alta reutilización y minimización de costos. comunicaciones. con una buena consistencia del lenguaje para especificar. . definiendo también cómo se maneja el Lenguaje de Especificación de Objetos.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. El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el consenso de los conceptos de modelado básico y permite desviaciones.

pueden existir como un elemento dentro de un símbolo o dentro de un compartimiento de un símbolo. o como un elemento estándar dentro de un diagrama. Cadenas. con cuáles rutas se maneja y cómo trabaja una estructura conectada con otra estructura dentro de un mismo diagrama. etc. Símbolos de 2 dimensiones. Cada capítulo está subdividido por los elementos que conforman el diagrama. Representan conceptos. Uniones. Notación: Explica la representación dotacional de la semántica mediante un diagrama. El documento describe los mecanismos de la notación para la representación visual del UML. Obviamente para cada caso se utilizan un diagrama diferente que proporciona la identificación de la semántica del grafo especificado. El documento está dividido en varios capítulos de acuerdo a los conceptos semánticos. en la terminación de una unión. y ya convertido en un estándar. Son de tamaño variable. uniones y cadenas. Dando así el sentido de saber interpretar la notación que se presenta y con qué fin es utilizada.Disponer de buenos modelos facilita la comunicación entre equipos de trabajo en un gran proyecto. Es decir qué tipo de diagrama se utiliza. Mapeo: Indica cómo la notación puede ser representada como información semántica. es la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la tecnología Orientada a Objetos. símbolos de 2 dimensiones. En . pueden contener listas de cadenas u otros símbolos. Es una figura gráfica de tamaño y forma definida. o por los diferentes tipos de diagramas. Icono. iconos. éstos pueden aparecer dentro del área de los símbolos. Son segmentos de línea con sus extremos terminados en algún símbolo de 2 dimensiones. Existen básicamente cuatro constructores gráficos usados en la notación del UML. como etiquetas de un símbolo o unión. como elementos de una lista. y para cada elemento se cuenta con las siguientes secciones: El nombre de la notación a describir Semántica Notación Mapeo Opciones de presentación Cada punto cuenta con su propia descripción: Nombre de la notación: Especifica el nombre de la notación Semántica: Es un breve resumen de la semántica para dicho elemento. Opciones de presentación: Son herramientas que pueden ser utilizadas para dar más énfasis a la notación cuando ésta lo requiera dejándola más completa y estructurada. El UML es un Lenguaje de Modelado Visual riguroso. Las uniones se conectan a los símbolos de 2 dimensiones como terminación de la unión sobre alguna parte del contorno de dicho símbolo.

OCL). toda consideración de implementación está fuera de su alcance. Para especificar características estáticas de tipo para Estereotipos. Por lo tanto. El OCL no es un lenguaje de programación. aun cuando una expresión OCL puede usarse para especificar un cambio de estado. es un lenguaje formal para expresar restricciones libres de efectos colaterales. El OCL puede ser usado con distintos propósitos:      Para especificar características estáticas sobre clases y tipos en un modelo de clases. incluyendo todos los enlaces.2. El OCL no pretende reemplazar lenguajes formales existentes como VDM y Z. pueden usar el OCL para especificar restricciones y otras expresiones incluidas en sus modelos. no puede cambiar nada en el modelo. Dado que el OCL es un lenguaje de modelado en primer lugar. Para especificar restricciones sobre operaciones: Dentro del documento Semántica del UML. Para especificar pre y post-condiciones sobre Operaciones y Métodos. es posible que haya cosas en él que no sean directamente ejecutables. No es posible invocar procesos o activar operaciones que no sean consultas en OCL. no cambiarán. simplemente devuelve un valor. en una post-condición.varios elementos esta sección no se presenta debido a que no tiene opciones de presentación. el OCL es usado en la sección reglas bien formuladas. El estado de los objetos en el sistema no puede variar durante la evaluación. OCL es un lenguaje formal donde todos los constructores tienen un significado formalmente definido. no es posible escribir lógica de programa o flujo de control en OCL. que son tomadas en cuenta en la formación de reglas. En varios lugares también es usado para definir operaciones „adicionales‟.4. OCL (Lenguaje de Especificaciones de Objetos) El Lenguaje de Especificación de Objetos (Object Constraint Language. cuando una expresión OCL es evaluada. de todos los objetos. . garantiza que una expresión OCL no tendrá efectos colaterales. la especificación del OCL es parte del UML. como constantes estáticas sobre la meta-clase en la sintaxis abstracta. Como el OCL es un lenguaje de modelado. Como lenguaje de navegación. Los usuarios del Lenguaje Unificado para Modelado (UML) y de otros lenguajes. por lo tanto. Todos los valores. y no puede ser expresada en el lenguaje OCL. El OCL es un lenguaje de expresión puro. 3. de un lenguaje de modelado y de un lenguaje formal. cada expresión OCL es atómica. Conceptualmente. Esto significa que el estado del sistema no cambiará nunca como consecuencia de una expresión OCL. El OCL tiene características de un lenguaje de expresión. por ejemplo.

Cuadro comparativo de las diferentes metodologías La presente actividad tiene la finalidad de que apliques cada uno de los conceptos básicos de las metodologías de diseño vistas hasta ahora y además. de clase y de gráfico de estado. secuencial. en dichos diagramas se manejarán casos de uso. Guarda la Actividad con el nombre ADOO_U3_A7_XXYZ. A lo largo de ésta se recordaron las metodologías de diseño para la generación de Sistemas Orientados a Objetos. Por último el origen de la metodología UML. ya estás preparado(a) para seguir con la unidad 4. 4.Las expresiones OCL pueden ser parte de pre-condiciones o post-condiciones. 3. que investigues las fechas en las que implementaron dichas metodologías. Investiga las fechas en que fueron implementadas las metodologías OO. Cierre de la unidad Has concluido la unidad 3 del curso. Todo ello con el fin de obtener el prototipo final al terminar el curso de Análisis y Diseño Orientado a Objetos. 4. de no ser este tu caso. Al final del documento. diagramas de actividades. en cada uno de ellos se vio una breve introducción y su modelo. la cual fue a través del OCL. Es aconsejable que revises nuevamente la unidad en caso de que los temas que se acaban de mencionar no te sean familiares. En un archivo elabora un cuadro comparativo donde incluyas las características de cada una de las metodologías OO y la fecha en que fueron implementadas. En un archivo de texto elabora un cuadro comparativo de los diagramas que son utilizados en cada uno de los modelos revisados a lo largo de la unidad. Evidencia de aprendizaje. Guarda la evidencia con el nombre DOO_U3_EA_XXYY. 5. 2. Las pre-condiciones o post-condiciones se aplican tanto a Métodos como a Operaciones. Envía el archivo al correo electrónico de tu profesor para recibir retroalimentación. . lleva a cabo la siguiente actividad cuyo propósito es conceptuar el proceso. 1. escenarios del caso de uso. tales como: Boosh. Consulta la Escala de Evaluación. redacta una conclusión donde expreses cuáles serían los modelos más adecuados a utilizar en cada caso. que son Restricciones estereotipadas con «pre-condition» y «post-condition» respectivamente. en donde continuarás con El diseño orientado a objetos con UML. 2. a través de la representación de objetos y clases con diagramas y documentación para el diseño del software con UML. Cuadro comparativo de los métodos de modelado Como parte de la evaluación de esta unidad. Envía el archivo al correo electrónico de tu profesor para recibir retroalimentación. 1. 3. o no los recuerdes. Actividad 2. OOSE. OMT.

I. Larman. Quatrani. (1992) Object-Oriented Software Engineering A Use Case Driven Aproach México: Addison-Wesley James. R. (1999) UML GOTA A GOTA México: Addison Wesley Graham.. I. (2002) Métodos Orientados a Objetos México: Addison Wesley/Díaz de Santos. México: Pretince Hall.edu. (1997) Visual Modeling with Rational Rose and UML México: Addison Wesley Wirfs. M. Jacobson. M. México: Pretice Hall. (1990) Object Oriented Modeling and Design. (1990) Análisis y Diseño Orientado a Objetos México: Prentice Hall Iberoamericana. Designing Object Oriented Softwarem. & James. J. T.ec/bitstream/15000/3823/1/CD-3595. (1990).. Fowler. R. En el siguiente documento encontrarás un ejemplo real de análisis aplicado al diseño de un sistema escolar:  Desarrollo de un sistema de administración escolar académica para la escuela “Cristóbal Colón” bajo plataforma web: http://bibdigital.Para saber más…. K. (2004) Applying UML and Patterns An Introduction to object-Oriented Analysis and Design México: Prentice Hall Martin. & Odell. & Scott. W. & Eddym. & Wiener. .pdf Fuentes de consulta          Booch-Grady (2009) Análisis y Diseño Orientado a Objetos con aplicaciones. México: Pearson Educación.epn. L. R. J. C. Blaha. Premerlani. F.

b. a. formato No hay errores de puntuación u ortografía Coherencia en imagen-Texto-Concepto Total de puntos Total de puntos obtenidos por el estudiante 5 3 4 100 5 5 5 5 12 8 8 8 8 8 8 8 8 8 . c.ESCALA DE EVALUACIÓN Carreras: Sistemas Computacionales Cuatrimestre: Séptimo Asignatura: Análisis y diseño de Sistemas II Unidad: 3. 2. c. d. 3. títulos centrados. a. h. c. b. Comparación modelo BOOCH Comparación modelo OOSE Comparación OMT Comparación UML (OCL) El conceptos de BOOCH es el adecuado El conceptos de OOSE es el adecuado El conceptos de OMT es el adecuado El conceptos de UML(OCL) es el adecuado General Conclusión de cada modelo Expresa el modelo más adecuado en cada caso Creación Estructura Incluye Definiciones texto Contenido visual Creatividad Calidad Alineación . Básica a. 4. f. b. e. d. DIMENSIONES O CRITERIOS A EVALUAR PUNTOS POR PUNTOS OBSERVACIONES CRITERIO OBTENIDOS 1. e. Metodologías de diseños para la generación de sistemas orientados a objetos Evidencia Cuadro comparativo de los métodos de modelado Instrucciones: Anote en cada casilla los puntos obtenidos por el estudiante en cada criterio por evaluar. f. g.

Sign up to vote on this title
UsefulNot useful