El Modelado Orientado a Objetos y los diagramas UML en Informática

Metodologías de Análisis y Diseño de Sistemas de Información

Introducción a las Metodologías de Resolución de Problemas

Las metodologías o formas de resolución de problemas se asocian con un paradigma de sistema particular o con la forma de pensar y las más utilizadas son el SAAD (diseño estructurado) o el OAAD (orientado a objetos). Además,se fomenta el uso del MBSE (ingeniería de sistemas basada en modelos). Las metodologías OOAD, contrariamente a la SAAD, tienen un enfoque principalmente de abajo hacia arriba y se centra en las entidades que forman un sistema, en lugar de las funciones. En el dominio de los Sistemas de Información, donde nacieron estas metodologías, los datos y las funciones están altamente relacionados. En la Orientación a Objetos (OO) el énfasis está centrado en la abstracción de datos. Se piensa de forma natural, la especificación de los objetos, con sus datos, se mapean/vinculan a entidades del mundo real o de las ideas. UML es un estándar (norma) desarrollado bajo la OMG (Grupo de Gestión de Objetos).

Metodología SAAD

Las metodologías y lenguajes SAAD son independientes, pero comparten que: · Se centran en la actividad · Comunican funcionalidad de los sistemas con actividades, control o datos. En el dominio de los IS (Sistemas de Información) se indica que este modelo se masa en la Función/Dato, lo que supone que las funciones dependen de la estructura de datos y que las personas no piensan en términos de estas estructuras: expresan la funcionalidad del sistema, no como se estructura. En el SAAD se usan lenguajes descriptivos para modelado funcional (Diagramas de Flujo de Datos (DFD), IDEF0 o Diagrama de Bloques de Flujo Funcional (FFBD)), para modelar estructuras de datos (Entidad-Relación, IDEF1X) y para modelar aspectos de comportamiento temporal (IDEF3). A continuación, se adjuntan imágenes de los diagramas E/S, DFD e IDEF0: Flujo datos Almacen datos I Find Cool Coroner Función Productor/Consumido r datos

El Análisis y el Diseño Orientado a Objetos (OOAD)

Introducción al OOAD

Tras el SAAD surge el Análisis y el Diseño Orientado a Objetos. Este se centra principalmente de abajo hacia arriba y se enfoca en las entidades que forman un sistema, no en sus funciones. En el dominio de IS los datos y funciones están altamente relacionados. El énfasis está centrado enla abstracción de datos. Se piensa de forma natural, la especificación de los objetos, con sus datos, se mapean/vinculan a entidades del mundo real o de las ideas. El lenguaje de modelado utilizado es el UML. A continuación, se observa la diferencia entre el SAAD y el OOAD. En el primero el coche se conceptualiza como bloques de funciones, mientras que en el segundo se ve tanto los objetos que lo forman como sus interacciones. Ersice Dedai Saop Whoels Accelerator Dedal CAR Ergine Ignition system Power Steering wheel Sweering Braking system Ignition key

Principios Básicos del OOAD

El OOAD se fundamenta en el descubrimiento de abstracciones y mecanismos comunes para facilitar la comprensión de un sistema complejo. La forma canónica de ver un sistema en la OO se basa en descomponer en jerarquías este, que pueden ser estructurales (parte de) o de tipos (es un). Esta última captura las propiedades de determinados objetos en un solo lugar para posibilitar su comprensión. Por otra parte, ver cada nivel de estructura supone un nuevo nivel de complejidad. Ambas estructuras no son independientes del todo y juntas conforman la arquitectura del sistema. El papel de la descomposición es vital para trabajar y estudiar sistemas complejos. Divide el todo en partes más pequeñas para poder analizarlas independientemente. Se admite que para entender un nivel determinado basta con entender solo unas pocas partes a la vez. Esta descomposición puede ...

• Ser de varias formas, y la que se verá es la orientada a objetos, que interpreta estos como entidades autónomas que colaboran para llevar a cabo un comportamiento de nivel superior. En esta descomposición los objetos son resaltados como entidades que provocan acciones o que están sujetos a estas.
• Usarse para reutilizar mecanismos comunes, logrando una forma más económica de expresión.
• Ser una herramienta muy potente para enfrentarse a la complejidad, permitiendo no entrar en sus detalles no esenciales y crear un modelo generalizado e idealizado del objeto (encapsulación).

Por último, puede reconocerse el rol de la jerarquía objetos-clases como una forma de aumentar el contenido semántico de los bloques de información. La estructura "parte-de" de los objetos muestran la colaboración de los objetos gracias a distintos mecanismos. La estructura "es un tipo de" en cambio se vincula a las clases y resalta la estructura y comportamiento común del sistema. Un tipo es una caracterización precisa de las propiedades estructurales o de comportamiento que comparten una serie de entidades. Las clases implementan a los tipos, es decir, NO SON LO MISMO.

Objetos vs Clases

Objeto: entidad tangible o visible, comprensible intelectualmente, autónoma que colaboran para llevar a cabo algún comportamiento de nivel superior, que muestra un comportamiento bien definido. Los objetos son entidades que provocan acciones o que son sujetos de estas acciones. Modela una parte de la realidad, algo que existe en un tiempo y espacio. Pero también existen los abstractos, que son aquellos que surgen del proceso de diseño. Son entidades identificables que contribuyen al comportamiento del sistema colaborando entre ellas. Su comportamiento es la forma de actuar y realizar operaciones (acciones sobre otros objetos). Tienen estado, forma e identidad y el comportamiento de objetos similares se definen en su clase común. Clase: estrechamente ligado al concepto de objeto. Una clase representa sólo una abstracción, la esencia de un conjunto de objetos, que representa las características comunes de todos los objetos que pertenecen a una clase. Las clases representan a un conjunto de objetos que comparten una estructura y un comportamiento común. Por tanto, puede decirse que un objeto es una ejemplificación/instancia de una clase. Por tanto, los términos instancia y objeto suelen ser intercambiables. La clase es el contrato que vincula a una abstracción con todos sus clientes. Con esta visión de la programación se distingue:

• Interfaz o visión externa: proporciona la visión externa de una clase y por tanto enfatiza la abstracción que a la vez oculta su estructura y comportamiento. Son las operaciones aplicables que tienen los objetos de esta clase.
• Implementación o visión interna: engloba los secretos del comportamiento del sistema. Implementa todas las operaciones definidas en el interfaz de la propia clase.

El Lenguaje de Modelado Unificado (UML)

UML: Lenguaje de Modelo Unificado

Lenguaje de Modelo Unificado es un lenguaje descriptivo (con notación gráfica). Lenguaje visual de propósito general, desarrollado para proporcionar herramientas para el análisis, diseño e implementación de sistemas basados en software, así como para el modelado de procesos de negocio y similares. Está impulsado por la OMG y es el resultado de la unificación de varios métodos de modelado orientado a objetos. OORA 1990 COA OCA Methodo- logías Ction Goldberg Goed Yourdon Fusion COSE H Boish DOPNA HUM ORY Práctica SOMA MOREN 1997 Fusion OPENIOMI United RUP. OEP Estanda- rización UML 12 LIML 1.4 2005 2004 VNL 20 Difusión y Maduración 300UML 2.1.2 OPMN 1.1 No posee metodología propia. Puede ser utilizado por cualquier metodología de análisis y diseño orientado a objetos para expresar los diseños. UML está basado en un meta-lenguaje (meta-meta-modelo) llamado MOF (Meta Object Facility).

Modelos UML de Sistemas

1995Un modelo UML de un sistema formado por:

• Un conjunto de elementos y relaciones (construcciones) de modelado, que definen la estructura, el comportamiento y la funcionalidad del sistema y que se agrupan en una base de datos única.
• La visualización de esos elementos se realiza a través de múltiples diagramas con el fin de introducirlos, editarlos y hacerlos comprensibles. Los diagramas pueden agruparse en vistas, cada una de ellas enfocada en un aspecto particular del sistema.

captura Modelo Funcionalidad del sistema Estructura del sistema (caracteristicas estáticas) Comportamiento del sistema (caracteristicas dinámicas) organizado en visualizadas en Vistas Arquitecturales Diagramas ·Vista de Casos de Uso (Funcionalidad) ·Vista de Diseño (Arquitectura interna) ·Vista de Interacción (Concurrencia y sincronización) ·Diagramas de Casos de Uso ·Diagramas de Clases ·Diagramas de Objetos -Vista de Implementación (Arquitectura externa) -Diagramas de Secuencia ·Diagramas de Colaboración ·Diagramas de Estado ·Diagramas de Actividad ·Diagramas de Componentes El modelo hace algunas declaraciones de interés sobre ese sistema, haciendo abstracción de todos los detalles del sistema que posiblemente podrían describirse, desde un cierto punto de vista y para un cierto propósito. Para un sistema existente, el modelado puede ser una representación para un análisis de las propiedades y del comportamiento del sistema. Para un sistema planificado, el modelo puede representar una especificación de cómo debe construirse y comportarse el sistema. Un modelo UML consta de tres categorías principales de elementos del modelo, cada uno de los cuales se puede usar para hacer declaraciones sobre diferentes tipos de elementos individuales dentro del sistema que se está modelando (Individuos). Estas categorías son:

• Clasificadores: describen un conjunto de objetos, un objeto es un individuo con un estado (identifica los valores para ese objeto de las propiedades del clasificador del objeto) y relaciones con otros objetos.
• Eventos: describen un conjunto de posibles ocurrencias (Algo que sucede que tiene alguna consecuencia con respecto al sistema).
• Comportamientos: describen un conjunto de posibles ejecuciones (Realización de un conjunto de acciones).

Los modelos UML no contienen objetos, ocurrencias o ejecuciones, ya que estos son parte de la realidad que se está modelando, no el contenido de los modelos en sí. Los elementos del modelo poseen una representación simbólica, nodos y relaciones, visibles en los diagramas. Pero un modelo es más que un montón de símbolos gráficos. Detrás de cada símbolo existe una especificación bien definida que explica la sintaxis (abstracta) y la semántica del mismo. ·Vista de Despliegue (Plataforma y distribución)