ADENDUM A LA UNIDAD 6 MODELOS CONCEPTUALES

Transcripción

1 ADENDUM A LA UNIDAD 6 MODELOS CONCEPTUALES A6. MODELOS ORIENTADOS A PROCESOS... 1 A6.1. INTRODUCCIÓN AL MODELADO CONCEPTUAL... 2 A CONCEPTO DE MODELO... 2 A PROPÓSITO DE LOS MODELOS... 2 A MODELOS CONCEPTUALES VS. MODELOS DEL SISTEMA... 3 A6.2. UTILIDAD DE LOS MODELOS CONCEPTUALES... 6 A6.3. ONTOLOGÍA SUBYACENTE A LOS MODELOS CONCEPTUALES... 7 A6.4. NOTAS FINALES Actualmente, la ciencia y la tecnología utilizan extensamente modelos. La importancia de estos artefactos ha motivado que los modelos y el proceso de modelización se haya formalizado profundamente tanto en las matemáticas como en la filosofía de la ciencia, por lo que se constituyen en una de las disciplinas más complejas y abstractas existentes actualmente. En la presente unidad, se realizará una introducción a un tipo especial de modelos: Los modelos conceptuales. A diferencia de con las matemáticas, los modelos conceptuales, tal y como se entienden en ingeniería del software 1, son un tipo de modelos relativamente poco sofisticados y, por lo tanto, más simples de comprender. Dicho de otro modo: una descripción bastante informal es suficiente para introducir el modelado conceptual. No obstante, existe un problema. Los modelos conceptuales llevan utilizándose muchos años en ingeniería del software, pero con distintos propósitos. Ello ha provocado que el concepto de modelo conceptual esté altamente contaminado y, por consiguiente, que distintos colectivos conciban los modelos conceptuales de modo distinto. Por ejemplo, la confusión más frecuente consiste en suponer que los modelos conceptuales son equivalentes al diseño del software, eliminando de este modo la clara separación existente entre requisitos y diseño. Por ello, la introducción al modelado conceptual que se hará en las secciones siguientes será un poco más extensa de lo habitual, con la finalidad de evitar, en la medida de lo posible, confusiones como la citada anteriormente. Para ello, se describirán en primer lugar los conceptos fundamentales de modelado conceptual para, a continuación, describir la utilidad de los 1 La modelización conceptual es un aspecto muy complejo de la informática, debido a que posee se concibe de forma distinta dependiendo de la disciplina en que se considere. Por citar algún ejemplo, la concepción de los modelos conceptuales en la disciplina de Sistemas de Información es mucho más sofisticada y formalista (aunque en ningún modo incompatible) de lo que se explicará aquí. La descripción que se está aportando en la presente unidad coincide razonablemente bien con la concepción de modelo conceptual en la ingeniería del software. Asignatura: Análisis de Requisitos 1

2 modelos conceptuales para el análisis. El presente adendum finalizará con una discusión específica acerca de la ontología subyacente a los modelos conceptuales, que es precisamente lo que confiere a éstos su utilidad durante el análisis. A6.1. Introducción al modelado conceptual Las siguientes secciones describirán los conceptos fundamentales necesarios para comprender el modelado conceptual. Concretamente, se describirá qué es un modelo, por qué se construyen modelos y qué tipos de modelos se utilizan en la ingeniería del software. A Concepto de modelo El término modelo, en el lenguaje común, es extremadamente polisémico. Como muestra representativa de dicha variedad de acepciones, véanse las definiciones propuestas por el Webster s New Encyclopedic Dictionary: 1. Copia exacta pero a escala de algo. 2. Patrón o figura de algo pendiente de hacerse. 3. Descripción o analogía usada para ayudar a visualizar algo que no puede ser directamente observado. 4. Sistema de asunciones, datos e interfaces usados para describir matemáticamente objetos o situaciones. 5. Proyección teórica de un sistema posible o imaginario. Cada una de las definiciones anteriores, y probablemente cualquier otra que se pudiera proponerse, hacen siempre referencia al mismo hecho: Todos los modelos son un artificio (copia, represtación, sistema matemático) que describe alguna otra cosa (algo ya existente en el mundo real, un sistema a desarrollar en el futuro). La creación y utilización de modelos posee dos grandes ventajas prácticas: Los modelos simplifican lo que describen de diversas formas, permitiendo a su creador centrarse en los aspectos que considera importantes de la cosa modelada. Dicho de otro modo: los modelos son instrumentos de reducción de la complejidad. Los modelos, dependiendo de la fidelidad con que describan a la cosa modelada, permiten simular la manipulación de la cosa y observar resultados reales. Por ejemplo, una maqueta de un edificio permite simular las condiciones de iluminación de las distintas estancias del futuro edificio; o una maqueta de una ala de un avión permite estudiar las características aerodinámicas del ala real. De este modo, un modelo puede ser utilizado en lugar de la cosa modelada cuando ésta no es accesible o no se recomienda su manipulación. A Propósito de los modelos Independientemente de los tipos de modelos existentes o de sus propiedades formales, los modelos se construyen para algo. Típicamente, existen dos motivos para la creación de un modelo: Asignatura: Análisis de Requisitos 2

3 Ayudar o favorecer la comprensión de algo, tal y como se desprende de las definiciones 1, 3 y 4 indicadas en la sección anterior. Por ejemplo: para comprender el efecto de los choques frontales en la salud de los ocupantes de un vehículo, se construyen modelos en los cuales los coches se lanzan contra obstáculos estáticos (reduciendo de este modo la complejidad) pilotados por dummies (ya que no sería ético manipular personas reales). Proyectar o anticipar la estructura o funcionamiento de algo, tal y como se desprende de las definiciones 2 y 5. Por ejemplo, para evaluar la resistencia aerodinámica de un vehículo, es con frecuencia necesario construir una maqueta del mismo y someterla a pruebas en túneles de viento. En el caso de la ingeniería del software, los modelos se utilizan en las dos vertientes antes indicadas: tanto para ayudar a la comprensión como para anticipar la estructura o funcionamiento del software. No obstante, se trata de dos modelos distintos, usados en distintos momentos del proceso de desarrollo de software: Los modelos que favorecen la comprensión de la necesidad del usuario y los requisitos del software se denominan modelos conceptuales, y son usados durante la actividad de análisis del proceso de requisitos 2. Los modelos que anticipan la estructura o funcionamiento del futuro sistema no tiene un nombre propio, pero habitualmente se denominan modelos de diseño o modelos del sistema. Como su propio nombre indica, se utilizan una vez finalizada la actividad de requisitos, durante el proceso de diseño del software. Los modelos que nos interesarán en este módulo son los modelos conceptuales. No obstante, y debido a la contaminación que lleva asociada esta denominación, en las secciones siguientes se describirán de modo más pormenorizado las diferencias entre los modelos conceptuales y los modelos del sistema. A Modelos conceptuales vs. Modelos del sistema Existen varias diferencias entre los modelos conceptuales y los modelos del sistema. Las diferencias más importantes son las siguientes: Objeto del modelo: Los modelos conceptuales describen el universo de discurso. Los modelos del sistema describen el futuro sistema software. Alcance del modelo: Los modelos conceptuales poseen un alcance variable, superando en muchas ocasiones el ámbito del sistema. Los modelos del sistema, por el contrario, se circunscriben exactamente al ámbito del futuro sistema software. Detalle del modelo. Los modelos conceptuales tienden a ser poco detallados. Los modelos del sistema, sin embargo, deben contener un gran nivel de detalle acerca de cómo implementar el sistema para ser realmente útiles. 2 Otra utilidad de los modelos conceptuales es favorecer la comunicación entre analistas, usuarios y clientes, aunque dicha utilidad no es relevante aquí. Asignatura: Análisis de Requisitos 3

4 Formalidad: Los modelos conceptuales pueden poseer niveles muy variados de formalidad. Los modelos del sistema, para ser útiles, deben ser lo más precisos (y, en consecuencia, formales) posible. Las sub-secciones siguientes describen estas diferencias más en detalle. A Objeto del modelo Por objeto del modelo, debe entenderse la cosa descrita en el modelo. En el caso de los modelos conceptuales, el objeto del modelo es el universo, o dominio, de discurso. Por dominio de discurso, debe entenderse el entorno que rodea al software (y del que éste forma parte), en el cual: El software ejerce su influencia (toma datos, suministra datos) Se realizan las tareas cotidianas (facturar, imprimir, etc.) Existen unas reglas, típicamente denominadas reglas de negocio, que el software debe respetar para funcionar correctamente y proporcionar un trabajo útil. Por ejemplo, reglas tales como que las facturas deben imprimirse mensualmente o que éstas tendrán un formado determinado. Los modelos conceptuales representan, por consiguiente, los aspectos indicados anteriormente (datos, tareas, reglas de negocio, etc.). En el caso del modelo del sistema, el objeto del modelo es el futuro sistema software. Por consiguiente: El modelo del sistema puede contener aspectos del dominio de discurso (tales como las tareas y reglas de negocio), aunque típicamente en menor medida que el modelo conceptual y Sobre todo, el modelo de sistema describirá muchos aspectos acerca de cómo implementar el futuro sistema software, los cuales no están reflejados en el modelo conceptual. Entre dichos aspectos pueden citarse, por ejemplo, los métodos, mensajes, clases, procesos, etc. Gráficamente, la diferencia entre ambos modelos puede representarse como indica la Figura 1. Como puede observarse, el modelo conceptual y el modelo del sistema se solapan en cierta medida, pero ambos modelos son fundamentalmente diferentes. Asignatura: Análisis de Requisitos 4

5 Modelo conceptual Modelo del sistema Figura 1. Relación entre los modelos conceptuales y los modelos del sistema A Alcance del modelo Por alcance del modelo, debe entenderse cuánto éste describe la cosa modelada. El alcance se entiende perfectamente cuando se observa el mapa de una región 3 como, por ejemplo, de Madrid. Obviamente, un mapa que contenga únicamente a Madrid tiene un alcance más reducido que uno que contenga a Madrid y provincias limítrofes, como Ávila o Guadalajara. En el caso de los modelos conceptuales, éstos pueden poseer un mayor alcance que los modelos del sistema. Por ejemplo, supóngase que se deseara desarrollar un sistema de facturación. El modelo conceptual describiría todos los aspectos del dominio de discurso referidos a facturación, pero también podría describir aspectos referidos a pedidos y contabilidad si con ello se favoreciera la comprensión de las necesidades de los usuarios y los requisitos del software 4. Por el contrario, los modelos del sistema son mucho más restringidos, describiendo únicamente los aspectos de facturación que serán implementados en el futuro sistema software. A Detalle del modelo Por detalle de un modelo, debe entenderse cuán extensamente dicho modelo describe la cosa modelada. El ejemplo del mapa también permite ilustrar esto último. Así, un mapa de Madrid que contenga las carreteras secundarias es más detallado que uno que sólo contenga las carreteras principales. Los modelos conceptuales tienden a ser menos detallados que los modelos del sistema. Ello se debe a que los modelos del sistema describen aspectos muy específicos requeridos para implementar el diseño (parámetros, mensajes, etc.), mientras que los modelos conceptuales sólo especifican el detalle preciso para comprender el dominio de discurso. 3 Un mapa es, al fin y al cabo, un modelo de un territorio. 4 En muchas ocasiones, los modelos conceptuales se utilizan para precisar el ámbito, o límites, del futuro sistema software. Esto es: todos los aspectos descritos en el modelo conceptual son los que se implementarán en el futuro sistema software. No obstante, y el alcance del modelo conceptual coincida con el del modelo del sistema, debe quedar claro que se tratan de modelos distintos. Asignatura: Análisis de Requisitos 5

6 A Formalidad del modelo Por formalidad, debe entenderse el grado en que el modelo debe respectar una cierta sintaxis o semántica. Los modelos conceptuales pueden poseer diversos niveles de formalidad, siendo tanto más informales cuanto más simple es el dominio de discurso. Ello se debe a que en dominios sencillos, el analista necesita menos soporte de un modelo para lograr comprender la necesidad del usuario y los requisitos del software. Los modelos del sistema, sin embargo, acostumbran a poseer los mismos niveles de formalidad independientemente de la complejidad del dominio o cualquier otro factor. Ello se debe a que los modelos del sistema describen el futuro sistema software, por que deben ser lo más precisos y formales posible. A6.2. Utilidad de los modelos conceptuales Como ya se ha indicado anteriormente, los modelos conceptuales son utilizados para ayudar al analista a comprender las necesidades del usuario y los requisitos del sistema. Los modelos conceptuales ayudan al analista de dos modos distintos: Los modelos permiten simplificar el estudio del objeto del modelo, favoreciendo de éste modo la comprensión del mismo. Esto se realiza de tres modos distintos 5 : o Mediante abstracción: Por abstracción, debe entenderse el sustituir una cosa, o un conjunto de cosas, por otra que sumariza o resume a las cosas sustituidas. Un ejemplo de abstracción, por ejemplo, consiste en olvidar las diferencias existentes entre un coche Volvo y un Renault, y referirse a ambos bajo el término genérico coche. La abstracción es una técnica muy poderosa de simplificación, ya que permite reducir la multiplicidad de cosas existentes a un conjunto de categorías manejable. o Mediante partición. Por partición, debe entenderse el proceso de dividir un problema o situación complejos en varios subproblemas, más sencillos que el problema original, que se pueden estudiar separadamente 6. o Mediante proyección. Por proyección, debe entenderse el ver un problema o situación desde distintos puntos de vista 7. Un ejemplo simple de proyección ocurre cuando se evalúa el precio de una vivienda, sus metros cuadrados y el confort esperado para decidir la posible compra del inmueble 8. 5 Lo que sigue se denominan técnicas de reducción de la complejidad. No se propondrán ejemplos ilustrativos en la presente sección, debido a que es más aconsejable su realización en las UNIDADES 7, 8 y 9. 6 No todos los modelos conceptuales permiten una simplificación mediante partición. En este módulo, el único modelo conceptual que implementa esta técnica es el Diagrama de Flujo de Datos (DFD). 7 Casi ningún modelo conceptual por separado implementa esta técnica de reducción de la complejidad. Es necesario utilizar diversos modelos conceptuales simultáneamente para implementar la técnica de partición. 8 El problema de la partición es cómo integrar las distintas vistas obtenidas. Afortunadamente, en este módulo la integración de vistas está bien definida. Véanse las UNIDADES 7, 8 y 9. Asignatura: Análisis de Requisitos 6

7 Los modelos permiten identificar errores e inconsistencias en la conceptualización, o comprensión, que el analista tiene del dominio del problema y de los requisitos del sistema. Ello es posible debido a que los modelos conceptuales implementan un lenguaje pseudoformal, u ontología, que permite poner de manifiesto dichos errores e inconsistencias. Obviamente, la referencia a los lenguajes pseudoformales, u ontologías, es sumamente oscuro. Ello se describirá de forma más pormenorizada en la siguiente sección. A6.3. Ontología subyacente a los modelos conceptuales En las secciones anteriores, se ha hablado extensamente del propósito y utilidad de los modelos conceptuales. Sin embargo, no se ha descrito en ningún momento cómo dichos modelos permiten obtener dichos resultados. En otras palabras: Cómo funcionan los modelos conceptuales? La respuesta es compleja 9, aunque en lo que sigue se expondrá una respuesta simplificada. Básicamente, los modelos conceptuales están diseñados para aprehender una parte del dominio de discurso. Dicha parte del dominio de discurso se describe, en el modelo conceptual, con un léxico y sintaxis específicos, que típicamente admite una expresión gráfica. A modo de ejemplo, se diseñará a continuación un modelo conceptual (bastante humorístico) que permite describir automóviles. Este modelo consta del léxico indicado en la Tabla 1. Concepto Representación Carrocería-chasis Puerta Asiento Tabla 1. Léxico del modelo conceptual de descripción de coches 9 El modelado conceptual posee relaciones con la ontología, psicología cognitiva, etc. Todo ello supera ampliamente la presente exposición. Asignatura: Análisis de Requisitos 7

8 Tal y como puede observarse en la Tabla 1, el modelo conceptual deseado consta de tres símbolos o constructores: carrocería-chasis, puerta y asiento. Estos elementos se denominan constructores 10 porque son precisamente los que permiten construir, o crear, el modelo. Además de los constructores, los modelos deben poseer también una sintaxis, la cual gobierna la combinación de los símbolos constructores. Las reglas en el ejemplo utilizado podrían ser las siguientes: Las puertas deben situarse a pares en la carrocería-chasis Debe existir siempre un asiento en el lugar del conductor. El modelo conceptual definido anteriormente permite describir, al menos en parte, el dominio de discurso de los automóviles 11. Se puede, por ejemplo, definir un coche de cuatro puertas tal y como muestra la Figura 2. Figura 2. Coche de cuatro puertas Aunque el ejemplo anterior pueda parecer absurdo, muestra sin embargo todas las características importantes de los modelos conceptuales utilizados en ingeniería del software: En primer lugar, los constructores no son arbitrarios. Muy al contrario, son aspectos que existen muy claramente en el objeto del modelo, esto es, en el coche, y además son los aspectos de éste que más interesan al modelador Los constructores de los modelos conceptuales utilizados en ingeniería del software tienden a ser más abstractos que los aquí indicados. Véanse las UNIDADES 7, 8 y Obviamente, el modelo conceptual propuesto es muy simple y sólo permite describir una muy pequeña parte de un dominio tan complejo como el de los automóviles. 12 Los modelos en general, y los modelos conceptuales en particular, no son independientes de las intenciones del modelador. Muy al contrario, los modelos conceptuales sirven a un propósito, que es comprender mejor el objeto modelado desde el punto de vista de los constructores utilizados. Por ejemplo, si el interés del Asignatura: Análisis de Requisitos 8

9 En segundo lugar, la sintaxis tampoco es arbitraria. Ésta refleja las combinaciones válidas de los constructores en la realidad, de tal modo que cuando un modelo respeta la sintaxis, ello implica que el objeto modelado es válido. Ambos aspectos, léxico y sintaxis, determinan la ontología del modelo o, dicho de otro modo, determinan cómo son, y deben ser, los coches en la realidad: los coches acostumbran a tener puertas pares y asientos para el conductor 13. Por el contrario, cuando el modelo no respeta la sintaxis, algo es incorrecto. Supóngase por un momento que encargásemos a una persona X, que no supiera absolutamente nada de coches, modelar un vehículo. El resultado podría ser algo como lo mostrado en la Figura 3. Figura 3. Modelo incorrecto de un coche X podría darse perfectamente cuenta, al observar el modelo, que hay algo que no es correcto. Concretamente, falta una puerta y el asiento del conductor. Ambos hechos pueden observarse porque representan violaciones de la sintaxis del modelo. Cabe preguntarse, por consiguiente, dónde está el error. La respuesta es simple: Éste está claramente en la comprensión que X tiene del objeto modelado, esto es, del coche. Si todos los coches tienen puertas por pares, entonces el coche modelado DEBE tener dos puertas traseras. Lo mismo podría decirse del vehículo del conductor. Por consiguiente, X debe volver a observar el coche real y cerciorarse de que posee todas las características requeridas por el modelo13. Los modelos conceptuales utilizados en ingeniería del software identifican los errores y omisiones exactamente de la misma forma que se describe aquí. Como ya se ha indicado, dichos modelos poseen una sintaxis bastante bien definida. Cuando dicha sintaxis es violada, entonces se ha localizado un potencial error u omisión que debe ser verificado por el analista en el dominio de discurso. modelador estuviera en las ruedas, y no en las puertas, habría un constructor del modelo que representaría las ruedas, y no habría ningún constructor referido a las puertas. 13 Obviamente, podría haber coches que no poseyeran estas características. En este caso, debería modificarse la sintaxis en consecuencia. Asignatura: Análisis de Requisitos 9

10 A6.4. Notas finales Ya para finalizar, es necesario realizar una advertencia explícita. Se ha mencionado en las secciones anteriores que los modelos conceptuales se confunden con frecuencia con los modelos del sistema. La razón fundamental de que ello ocurra es que, en muchos casos, los constructores y sintaxis de ambos modelos son absolutamente coincidentes. Dicho de otro modo: en ingeniería del software, se utilizan los mismos constructores para describir el dominio de discurso y el sistema software. Y ello con la misma sintaxis. No obstante, ello no debe incitar a confusión, tal y como se ha descrito extensamente en las secciones anteriores. Asignatura: Análisis de Requisitos 10