Post on 16-Jan-2017
transcript
REPÚBLICA BOLIVARIANA DE VENEZUELA
LA UNIVERSIDAD DEL ZULIA
FACULTAD EXPERIMENTAL DE CIENCIAS
DEPARTAMENTO DE COMPUTACIÓN
UNIDAD ACADEMICA DE TECNOLOGÍAS,
SISTEMAS DE INFORMACIÓN Y BASES DE DATOS
Lenguaje de Modelado Unificado -UML-
Un análisis comparativo para la diagramación de software
Trabajo de ascenso presentado por la MSc. Yaskelly Yedra para optar a la categoría de
Profesor Agregado
Maracaibo, mayo de 2007
Lenguaje de Modelado Unificado -UML-
Un análisis comparativo para la diagramación de software
Yedra Hernández, Yaskelly Yubisay
C.I. 13.008.524
Teléfono: 0261-7597747
yyedra@fec.luz.edu.ve
Maracaibo, 08 de mayo de 2007
LENGUAJE DE MODELADO UNIFICADO -UML-
ANÁLISIS COMPARATIVO PARA LA DIAGRAMACIÓN DE SOFTWARE
RESUMEN
El propósito de este trabajo es realizar un análisis comparativo entre el Lenguaje de
Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a
objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como
surgió, evolucionó y se consolidó el UML como herramienta para la construcción de
software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y
orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas
similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las
semejanzas y diferencias de los distintos métodos cuando se construye software. Como
conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite
a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de
modelación estándar que además de ser consistente es soportado directamente por las
mejores herramientas de software en una forma unificada.
Palabras clave: análisis comparativo, lenguaje de modelado unificado (UML), desarrollo
estructurado, métodos orientados a objetos, bloque de construcción.
UNIFIED MODELING LANGUAGE -UML-
COMPARATIVE ANALYSIS TO DIAGRAM SOFTWARE
ABSTRACT
The purpose of this work is to realize a comparative analysis among the Unified Modeling
Language (UML) with the structured development and the object-oriented methods, from
the blocks of UML's construction, with the purpose of observing since how it arose,
evolved and consolidated UML as tool for the construction of software. The blocks of
UML's construction and the methods of structured development and orientated to objects
conform with: elements, relations and diagrams. From these similarities, this work uses the
method of comparative analysis to discover the similarities and differences of the different
methods when software is constructed. As conclusion of the analysis, it has that UML does
not guarantee the success of a project, but it allows to the engineers to centre on the
delivery of a product, using a language of standard modeling that beside being consistent is
supported directly by the best tools of software in a unified form.
Keywords: comparative analysis, Unified Modeling Language (UML), structured
development, methods orientated to objects, block of construction.
Índice de Contenido
pp
VEREDICTO………………………………………………………………………. 4
RESUMEN…………………………………………………………………………. 5
ABSTRACT………………………………………………………………………... 6
INDICE DE CONTENIDO………………………………………………………… 7
INDICE DE FIGURAS…………………………………………………………….. 11
INDICE DE CUADROS…………………………………………………………… 15
INTRODUCCIÓN…………………………………………………………………. 16
CAPITULO I: Modelado Conceptual en el Desarrollo de Software 20
1.1. Modelado y modelamiento…………………………………………………….. 20
1.2. Herramientas para el desarrollo de software…………………………………... 23
1.3. Requerimientos, análisis y diseño de software………………………………... 24
1.3.1. Requerimientos de software…………………………………………… 24
1.3.2. Análisis de software…………………………………………………… 26
1.3.3. Diseño de software…………………………………………………….. 27
1.4. Propuesta de investigación…………………………………………………….. 29
1.5. Objetivos de la investigación………………………………………………….. 29
1.5.1. Objetivo general……………………………………………………….. 29
1.5.2. Objetivos específicos………………………………………………….. 30
1.6. Marco metodológico…………………………………………………………... 30
CAPÍTULO II: Desarrollo Estructurado 33
2.1. Programación estructurada…………………………………………………….. 34
2.1.1. Diagrama de flujo o flujograma………………………………………… 37
2.1.2. Diagrama de Nassi-Schederman (N-S)...……………………………….. 43
2.2. Diseño estructurado……………………………………………………………. 45
2.2.1. Diagrama de flujo de datos (DFD)……………………………………... 45
Componentes de un diagrama de flujo……………………………….. 46
Método de Yourdon /DeMarco………………………………………. 50
Método de SSAM…………………………………………………….. 51
Método de Gane/Sarson……………………………………………… 54
2.3. Diagramas de estructura de datos (DED)……………………………………… 56
2.4. Diagrama de transición de estados (DTE)…………………………………….. 62
2.5. Modelo relacional……………………………………………………………… 68
2.6. Diagrama entidad relación (DER)……………………………………………... 76
2.7. Otros métodos estructurados..…………………………………………………. 83
2.7.1. Método de Warnier/Orr……………………………………………….. 83
2.7.2. Método de Jackson…………………………………………………….. 85
2.7.3. Diagramas HIPO………………………………………………………. 87
CAPÍTULO III: Desarrollo Orientado a Objetos 92
3.1. Conceptos básicos del desarrollo OO..………………………………………... 93
3.1.1. Estructura conceptual de un objeto.………………………………..…… 96
3.2. Métodos de análisis orientados a objetos (AOO)……………………………… 97
3.2.1. Método OOSA de Shlaer/Mellor…………………………………..…… 97
3.2.2. Método de Coad/Yourdon……………………………………………… 98
3.2.3. Método OMT de Rumbaugh……………………………………………. 99
3.2.4. Método de Wirfs-Brock (DOOS).……………………………………… 111
3.3. Métodos de diseño orientados a objetos (DOO)………………………………. 112
3.3.1. Método de Booch……………………………………………………….. 112
3.3.2. Método de Good………………………………………………………... 115
3.3.3. Método de Hood………………………………………………………... 115
3.3.4. Método de OOSD………………………………………………………. 117
3.3.5. Método de JSD y OOJSD………………………………………………. 118
3.3.6. Método de OODLE……………………………………………………... 119
3.4. Otros métodos…………………………………………………………………. 119
3.4.1. Método de Jacobson (OOSE)…………………………………………... 119
3.4.2. Método de Graham (SOMA)…………………………………………… 122
3.4.3. Método de Fusión………………………………………………………. 122
3.4.4. Método de Martin/Odell (OOAD)……………………………………… 122
CAPITULO IV: Lenguaje de Modelado Unificado (UML) 125
4.1. Introducción al UML…………………………………………………………... 125
4.1.1. UML 2.0……………………………………………………………….. 129
4.1.2. Modelo conceptual de UML…………………………………………... 130
4.1.3. Diagramas en UML…………………………………………………… 134
4.2. Diagramas de estructura o estáticos…………………………………………… 135
4.2.1. Diagrama de clases……………………………………………………... 135
4.2.2. Diagrama de componentes……………………………………………… 136
4.2.3. Diagrama de estructuras compuestas…………………………………… 137
4.2.4. Diagrama de despliegue………………………………………………… 138
4.2.5. Diagrama de objetos……………………………………………………. 140
4.2.6. Diagrama de paquetes…………………………………………………... 142
4.3. Diagramas de comportamiento o dinámicos…………………………………... 144
4.3.1. Diagramas de actividad…………………………………………………. 144
4.3.2. Diagramas de casos de uso……………………………………………... 153
4.3.3. Diagrama de máquina de estado………………………………………... 155
4.3.4. Diagramas de interacción……………………………………………….. 157
Diagrama de secuencia………………………………………………. 157
Diagrama de colaboración…………………………………………… 159
Diagramas de visualización de interacción…………………………... 162
Diagramas de tiempo………………………………………………… 163
165
CAPÍTULO V: Análisis de los Resultados
5.1. Análisis comparativo entre los elementos de UML y los de programación
estructurada y los métodos OO.
165
5.1.1. Elementos básicos de la programación estructurada…………………... 165
5.1.2. Elementos de los métodos OO………………………………………… 166
5.1.3. Elementos en UML……………………………………………………. 167
5.1.4. Análisis comparativo entre los elementos de UML y los de
programación estructura y los métodos OO……………………………
169
5.2. Análisis comparativo entre las relaciones de UML y las relaciones de la
programación estructurada y los métodos OO.
170
5.2.1. Relaciones existentes en el desarrollo estructurado…………………… 171
5.2.2. Relaciones existentes en los métodos OO……………………………... 175
Relaciones entre clases y objetos según la notación de OMT……… 176
Relaciones entre clases y objetos según la notación de Booch…….. 182
5.2.3. Relaciones existente en UML………………………………………….. 186
Relaciones existentes entre clases y objetos………………………... 186
Relaciones existentes en los diagramas de casos de uso…………… 199
Relaciones existentes en los diagramas de paquetes……………….. 200
Relaciones existentes en los diagramas de despliegue……………... 202
5.2.4. Análisis comparativo entre las relaciones que se dan en los diagramas
de clases y de objeto de los métodos OO y los de UML…………........
204
Asociación………………………………………………………….. 204
Agregación…………………………………………………………. 206
Composición……………………………………………………….. 207
Herencia y generalización………………………………………….. 207
5.3. Análisis comparativo entre los diagramas de UML y los diagramas de la
programación estructurada y los métodos OO.
209
5.3.1. Análisis comparativo entre los diagramas de flujo y los diagramas de
actividad de UML………………………………………………………
209
5.3.2. Análisis comparativo entre los DFD y los diagramas de casos de uso
de UML.
211
5.3.3. Análisis comparativo entre los diagrama entidad - relación y los
diagramas de clase de UML……………………………………………
213
5.3.4. Análisis comparativo entre los diagramas estados de los MOO y los de
UML……………………………………………………………………
216
5.3.5. Análisis comparativo entre los diagramas de objetos de los MOO y los
diagramas de colaboración de UML……………………………………
219
5.3.6. Análisis comparativos entre las clases de los métodos OO y las clases
de UML………………………………………………………………...
220
5.3.7. Análisis comparativo entre los diagramas de secuencia de los MOO y
los de UML……………………………………………………………..
223
5.3.8. Análisis comparativo entre los casos de uso de los MOO y los de
UML……………………………………………………………………
226
5.3.9. Análisis comparativo entre los diagramas de objetos de los MOO y los
de UML………………………………………………………………...
229
CONCLUSIONES…………………………………………………………………. 239
BIBLIOGRAFÍA…………….……………………………………………………... 240
Índice de Figuras
Figuras pp
2.1 Diseño top-down………………………………………………………….. 35
2.2 Ejemplo de diagrama de flujo…………………………………………….. 35
2.3 Estructura secuencial……………………………………………………… 39
2.4 Estructura alternativa simple……………………………………………… 40
2.5 Estructura alternativa doble……………………………………………….. 40
2.6 Estructura alternativa múltiple……………………………………………. 41
2.7 Estructura “para o for”……………………………………………………. 41
2.8 Estructura “mientras o while”…………………………………………….. 42
2.9 Estructura “hasta o until”…………………………………………………. 42
2.10 Ejemplo de diagrama N-S………………………………………………… 43
2.11 Estructura secuencial de un diagrama N-S………………………………... 44
2.12 Estructura de decisión de un diagrama N-S………………………………. 44
2.13 Estructuras de iteración…………………………………………………… 45
2.14 Diferentes procesos de un DFD…………………………………………... 47
2.15 Dirección de los flujos de datos……………………………...…………… 48
2.16 Diferentes de flujo de datos……………………………………………….. 48
2.17 Representación de los almacenes de datos………………………………... 49
2.18 Representación de las entidades externas………………………………… 50
2.19 Ejemplo de un DFD con el método Yourdon/DeMarco………………….. 50
2.20 Modelos de datos lógicos…………………………………………………. 51
2.21 Modelos de flujo de datos………………………………………………… 52
2.22 Modelo de comportamiento de las entidades……………………………... 52
2.23 Ejemplo de un DFD con el método SSADM……………………………... 53
2.24 Ejemplo de un DFD con el método Gane & Sarson……………………… 54
2.25 Enfoque de análisis estructurado clásico………………………………….. 55
2.26 Niveles de los DFD……………………………………………………….. 56
2.27 Ejemplo de un diagrama de estructura de datos…………………………... 57
2.28 Ejemplo de invocaciones………………………………………………….. 59
2.29 Ejemplos de invocaciones con cuplas…………………………………….. 60
2.30 Estructura condicional…………………………………………………….. 61
2.31 Estructura iterativa…….………………………………………………….. 62
2.32 Ejemplo de un diagrama de transición de estados………………………... 63
2.33 Cambios de estado en un DTE……………………………………………. 64
2.34 Estados inicial y final en DTE……………………………………………. 65
2.35 Estados finales múltiples de N sistemas…………………………………... 65
2.36 Condiciones y acciones de un DTE………………………………………. 66
2.37 DTE particionado para un cajero automático……………………………... 67
2.38 Relación entre un DFD y un DTE………………………………………… 68
2.39 Estructura de datos relacionales…………………………………………... 72
2.40 Ejemplo de un modelo entidad relación…………………………………... 78
2.41 Ejemplo de entidades y conjuntos de entidades…………………………... 78
2.42 Representación de la entidad: “persona”………………………………….. 79
Figuras pp
2.43 Entidad débil……………………………………………………………… 79
2.44 Ejemplo de relación (a)…………………………………………………… 80
2.45 Ejemplo de relación (b)…………………………………………………… 80
2.46 Ejemplo de roles en las relaciones…………………………...…………… 81
2.47 Estructura de un programa – Warnier…………………………………….. 84
2.48 Estructura secuencial y alternativa – Warnier…………………………….. 84
2.49 Estructuras repetitivas – Warnier…………………………………………. 85
2.50 Estructura de un programa – Jackson……………………………………... 86
2.51 Estructura secuencial y alternativa – Jackson…………………………….. 86
2.52 Estructuras repetitivas – Jackson…………………………………………. 87
2.53 Tabla de contenido – HIPO……………………………………………….. 88
2.54 Ejemplo de un diagrama general HIPO…………………………………... 89
2.55 Ejemplo de un diagrama detallado HIPO…………………………………. 89
3.1 Ejemplo de una relación de objeto.……………………………………….. 96
3.2 Ejemplo de una clase……………………………………………………… 97
3.3 Ejemplo de propiedades de un objeto……………………………………. 97
3.4 Ciclo de vida OMT ……………………...……………………………….. 100
3.5 Ejemplo de representación de una clase…………………………………... 102
3.6 Ejemplo de asociaciones………………………………………………….. 102
3.7 Ejemplo de un agregación………………………………………………… 103
3.8 Ejemplo de un diagrama HOOD para una compañía……………………... 117
3.9 Manejo de casos de uso…………………………………………………… 120
3.10 Metodología OOSE……………………………………………………….. 120
4.1 Influencia de métodos de desarrollo de software y UML………………… 126
4.2 Evolución de UML………………………………………………………... 127
4.3 Modelo conceptual de UML……………………………………………… 133
4.4 Diagramas en UML 2.0…………………………………………………… 134
4.5 Ejemplo de un diagrama de clases………………………………………... 136
4.6 Ejemplo de un diagrama de componentes………………………………… 137
4.7 Ejemplo de un diagrama de estructura……………………………………. 138
4.8 Ejemplo de un diagrama de despliegue…………………………………… 139
4.9 Ejemplo de un diagrama de objetos………………………………………. 141
4.10 Ejemplo de un diagrama de paquetes……………………………………... 144
4.11 Ejemplo de un diagrama de actividades…………………………………... 146
4.12 Ejemplo de una acción……………………………………………………. 146
4.13 Notación de diferentes tipos de nodos……………………………………. 148
4.14 Ejemplos de flujos y limites………………………………………………. 149
4.15 Regiones de expansión……………………………………………………. 150
4.16 Señales en un diagrama de actividades…………………………………… 151
4.17 Envío y recepción de señales……………………………………………... 151
4.18 Ejemplo de particiones en un diagrama de actividades…………………... 152
4.19 Relaciones en un diagrama de casos de uso………………………………. 154
4.20 Ejemplo de un diagrama de casos de uso…………………………………. 155
4.21 Ejemplo de un diagrama de estado………………………………………... 156
4.22 Ejemplo de un diagrama de secuencias…………………………………… 158
Figuras pp
4.23 Ejemplo de un diagrama de colaboración………………………………… 160
4.24 Ejemplo de un diagrama de visualización de interacción………………… 162
4.25 Ejemplo de un diagrama de tiempo……………………………………….. 163
5.1 Diferentes flujos de datos…………………………………………………. 171
5.2 Ejemplo de invocaciones………………………………………………….. 171
5.3 Ejemplo de invocaciones con cuplas……………………………………… 172
5.4 Ejemplo de relación (a)…………………………………………………… 174
5.5 Ejemplo de relación (b)…………………………………………………… 174
5.6 Ejemplo de roles de las relaciones………………………………………... 175
5.7 Ejemplo de enlaces y asociaciones……………………………………….. 176
5.8 Representación de la multiplicidad en OMT……………………………... 177
5.9 Ejemplo de multiplicidad en un diagrama de clases……………………… 177
5.10 Ejemplo de atributo en un enlace…………………………………………. 178
5.11 Ejemplo de una asociación como una clase………………………………. 178
5.12 Ejemplo de un rol en una asociación……………………………………… 179
5.13 Ejemplo de una asociación calificada…………………………………….. 179
5.14 Ejemplo de una relación de agregación…………………………………... 180
5.15 Ejemplo de superclases y subclases………………………………………. 181
5.16 Ejemplo de los tipos de agregación……………………………………….. 182
5.17 Representación grafica de las agregaciones………………………………. 183
5.18 Representación grafica de las relaciones en el método Booch…………… 184
5.19 Ejemplo de las relaciones en un diagrama de clases……………………… 184
5.20 Representación grafica de Metaclases e Instanciaciones…………………. 185
5.21 Ejemplo de una relación de asociación…………………………………… 186
5.22 Ejemplo de los roles en una relación de asociación………………………. 187
5.23 Ejemplo de multiplicidad…………………………………………………. 187
5.24 Ejemplo de navegabilidad………………………………………………… 188
5.25 Ejemplo de navegabilidad con restricción………………………………... 189
5.26 Ejemplo del uso del calificador en una relación de asociación…………… 189
5.27 Representación de una asociación binaria………………………………… 190
5.28 Representación de una asociación n-arias………………………………… 190
5.29 Ejemplo de una asociación derivada……………………………………… 191
5.30 Ejemplo de una asociación reflexiva……………………………………… 191
5.31 Ejemplo de una asociación restringida……………………………………. 191
5.32 Ejemplo de una clase asociada……………………………………………. 192
5.33 Representación de una relación de agregación…………………………… 193
5.34 Representación de una relación de composición…………………………. 193
5.35 Representación de una relación de generalización………………………... 194
5.36 Representación de una relación de dependencia………………………….. 196
5.37 Representación de una relación de dependencia modelada a través de una
interfaz……………………………………………………………………..
196
5.38 Representación de una relación de realización…………………………… 197
5.39 Representación grafica de la relación de realización……………………... 198
5.40 Representación de la relación de realización de manera resumida……….. 198
Figuras pp
5.41 Representación de la relación de realización donde una clase satisface
varias interfaces……………………………………………………………
199
5.42 Relaciones en un diagrama de casos de uso………………………………. 200
5.43 Ejemplo de una dependencia…………………............................................ 201
5.44 Ejemplo de una dependencia cunado un paquete contiene otro paquete..... 202
5.45 Representación de una relación de dependencia en un diagrama de
despliegue………………………………………………………………….
202
5.46 Representación de una relación de asociación en un diagrama de
despliegue……………………………………………………………….....
203
5.47 Representación de la relación de asociación en UML, Booch y OMT…… 204
5.48 Representación de la relación de agregación en UML, Booch y OMT…... 206
5.49 Representación de la relación de composición en UML y Booch………... 207
5.50 Ejemplo de un diagrama de actividades…………………………………... 211
5.51 Situación actual del desarrollo de software……………………………….. 215
5.52 Ejemplo de un diagrama de transición de estados (Notación Booch)…….. 217
5.53 Ejemplo de un diagrama de estado de la clase ajedrez (Notación OMT)… 218
5.54 Ejemplo de un Diagrama de Estado en UML…………………………….. 219
5.55 Representación de una clase con el método Booch………………………. 221
5.56 Representación de una clase en OMT…………………………………….. 222
5.57 Representación de una clase en UML…………………………………….. 223
5.58 Ejemplo de un diagrama de interacción (Notación Booch)………………. 224
5.59 Ejemplo de un diagrama de seguimientos de sucesos (Notación OMT)…. 225
5.60 Ejemplo de un diagrama de secuencia UML……………………………... 226
5.61 Ejemplo de un diagrama de caso de uso………………………………….. 227
5.62 Ejemplo de un diagrama de objeto (Notación Booch)……………………. 231
5.63 Ejemplo de flujo de datos…………………………………………………. 231
5.64 Ejemplo de visibilidad……………………………………………………. 232
5.65 Ejemplo de sincronismo…………………………………………………... 233
5.66 Representación de tiempos en un diagrama de objetos…………………… 233
5.67 Ejemplo de un diagrama de objetos en UML…………………………….. 235
Índice de Cuadros
Cuadro pp
2.1 Tipos de invocaciones…………………………………………………… 59
2.2 Tipos de cuplas………………………………………………………….. 60
2.3 Evolución del modelo relacional………………………………………... 70
2.4 Grados de normalización………………………………………………... 73
5.1 Tipos de invocaciones…………………………………………………… 172
5.2 Tipos de cuplas………………………………………………………….. 173
Introducción
El presente trabajo de investigación está enmarcado dentro del área de la ingeniería de software,
disciplina que se ocupa del establecimiento y uso de principios de ingeniería para obtener
software que sea fiable, económico y funcione eficientemente cuando sea requerido. La
ingeniería de software se ocupa de la definición de requerimientos, análisis, diseño, construcción,
prueba, puesta a punto y operación; para realizar esas tareas, esta disciplina propone métodos que
disciplinen el desarrollo de aplicaciones de software, con el objetivo de hacer los productos, más
predecibles y eficientes. Los métodos de desarrollo de software definen y describen el camino del
cómo modelar y construir un sistema de software de una forma confiable y reproducible.
Los diversos métodos de especificación permiten la construcción de modelos conceptuales que
son de gran utilidad para desarrollar software. En general, independientemente de la metodología
que se siga, el proceso de creación de modelos es conocido con el nombre de modelado
conceptual, que corresponde a una etapa muy importante dentro del análisis y diseño del software
Con la evolución de la computación se ha desarrollado un gran número de métodos para la
especificación de sistemas de software. Los métodos orientados al enfoque estructurado fueron
ampliamente utilizados por mucho tiempo. El desarrollo de software orientado a objetos desplegó
nuevos métodos para la elaboración de programas que usan “objetos” para diseñar aplicaciones, a
través de diversas técnicas que incluyen herencia, modularidad, polimorfismo y
encapsulamiento.
Todo este proceso histórico llevó a la búsqueda de un estándar en cuanto al modelado conceptual
del desarrollo de software, y en los últimos años, ese estándar se representó a través de un
lenguaje formal de especificación usado en las Ciencias de la Computación y que se denomina
Lenguaje de Modelado Unificado (UML), que fue creado por la OMG (Grupo de Gestión de
Objetos) para ser compatible con los métodos del desarrollo orientado de objetos y que ha sido
reconocido como un avance en la evolución de técnicas de modelamiento UML es un lenguaje
para hacer modelos y es independiente de los métodos de análisis y diseño.
.
17
Los métodos definen una representación gráfica a través de diagramas a fin de facilitar la
manipulación de modelos, y la comunicación e intercambio de información entre todas las partes
involucradas. Estas representaciones gráficas han estado presentes en los métodos de desarrollo
estructurado, los orientados a objetos y en particular en el UML que son usados para crear un
modelo abstracto del sistema a desarrollar. Para Eriksson y Penker (1997) “el método le dice al
usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son
utilizados para describir algo y comunicar los resultados del uso del método”. Es importante
distinguir entre el modelo UML y el conjunto de diagramas, que sólo son representaciones
gráficas de un modelo de sistema. Un modelo es expresado en un lenguaje consistente de vistas,
diagramas, símbolos y un conjunto de mecanismos generales o reglas que indican cómo utilizar
los elementos.
Propósito de la investigación
Hacer un análisis comparativo entre los bloques de construcción de gráficos utilizados por el
UML para desarrollar aplicaciones y diagramas y demás notaciones gráficas usados por el
método estructurado y los métodos orientados a objetos, es el propósito principal de este trabajo
de investigación. Para ello es necesario, primero definir cada uno de estos enfoques, y luego
hacer comparaciones con el fin de observar la influencia de los modelos en el estándar UML.
De manera que este trabajo de investigación se compone de las siguientes partes: Capitulo 1 que
aborda el tema del modelo conceptual de desarrollo de software, que sirve de introducción al
trabajo y se expones la parte metodológica y los objetivos de la investigación.
El Capítulo 2 que trata sobre el desarrollo estructurado. Allí se explican los diagramas más
utilizados de este enfoque, donde el elemento principal es el flujo de información y de datos.
En el Capítulo 3, se estudian los métodos orientados a objetos en particular el análisis y diseño de
software, así como otros métodos menos relevantes.
En el Capítulo 4, se realiza una introducción al concepto de UML, para luego describir de manera
general cada uno de los diagramas que conforman la parte estática y dinámica del UML.
18
En el Capítulo 5, se presentan los resultados de la investigación, se realiza un análisis
comparativo entre el estándar UML con el desarrollo estructurado y los métodos orientados a
objetos tomando como directriz los bloque básicos de construcción del UML.
Por último, se exponen las conclusiones, los resultados de la investigación y se destacan la forma
cómo los diferentes enfoques de desarrollo de software han contribuido a unificar criterios para la
creación y estandarización del UML.
Modelo Conceptual de
Desarrollo de Software
CAPITULO
Modelado Conceptual de
Desarrollo de Software
En esta capítulo se analizan los modelos conceptuales para desarrollar software surgidos en la
evolución de la Ingeniería de Software específicamente con la programación estructurada, con los
métodos orientados a objetos y últimamente con en el lenguaje de modelado unificado -UML.
1.1. Modelo y modelamientos
Los modelos se utilizan en todas las ciencias. Su finalidad es la de simbolizar una parte del
mundo real de forma que sea más fácil de manipular. El modelado conceptual de desarrollo de
software, lo compone el diseño y análisis del mismo, con base en los requerimientos del software,
dejando, de lado la puesta en marcha y operación.
El modelo conceptual de desarrollo software, surge como una manera de modelar la realidad,
puesto que de este modo se puede percibir y entender mejor qué es lo que se pretende desarrollar.
Piattini (1939), en el libro Concepción y Diseño de Bases de Datos del Modelo E/R al Modelo
Relacional, dice: “que un modelo es un conjunto de conceptos que permiten construir una
representación más o menos razonable de alguna realidad cualquiera”, agrega que: “modelar
consiste en definir un mundo abstracto y teórico tal que las conclusiones que se puedan sacar de
él coincidan con las manifestaciones aparentes del mundo real”. Se puede decir, que el
modelamiento es hoy una herramienta de gestión y comunicación usada por todas las disciplinas
humanas que permite desarrollar diseños para estudiar los comportamientos que van desde los
objetos físicos hasta los procesos o sistemas complejos donde intervienen recursos de diferentes
naturaleza.
Según Sommerville (2005), un modelo es una descripción de un proceso del software que se
presenta desde una perspectiva particular. Por su naturaleza, los modelos son simplificaciones,
21
por lo tanto un modelo de procesos del software es una abstracción de un proceso real. Cada
modelo de proceso representa una perspectiva particular, por lo que sólo provee información
parcial acerca de ese proceso. Estos modelos incluyen actividades que son parte de los procesos y
productos de software así como el papel desempeñado por la gente que está involucrada, es decir,
que el modelado es una parte central de todas las actividades que conducen a la programación de
un buen software. Se construyen modelos para comunicar la estructura deseada y el
comportamiento del sistema.
En este trabajo definiremos un modelo como un esquema mental (conceptual) en el que se
intentan reproducir las características de una realidad específica. Así, los modelos presentan un
marco conceptual donde se reflejan las teorías, se plasman las propiedades y se establecen los
principios del diseño de los sistemas. Su importancia radica en que permiten identificar, organizar
y realizar razonamientos sobre los componentes y comportamiento del sistema, a fin de visualizar
y controlar la arquitectura que sirve de guía para el proceso de diseño del software y pueden
usarse como una referencia para evaluar un diseño particular o para razonar sobre el posible
espacio de soluciones planteadas.
Según Yourdon (1989) gran parte de la labor que desempeña un desarrollador de software
involucra el modelado de software que el usuario desea. Este tipo de modelado son
representaciones abstractas de lo que al final será una combinación de hardware y software de
computadoras. Existen diferentes tipos de modelos: mapas, globos terráqueos, diagramas, dibujos
arquitectónicos y partiduras musicales. Sin embargo, existen muchos tipos de modelos que se
pueden construir para el usuario: modelos narrativos, modelos de prototipos, modelos gráficos
(diagramas), etc.
Por su naturaleza los modelos deben ser expresivos, fáciles de usar y completos. Los modelos
conceptuales, en algunos casos, se pueden representar mediante una ontología1 de conceptos y
relaciones que suceden en el sistema; otras veces, se puede optar por métodos formales o
notaciones ampliamente usadas y conocidas para representar los conceptos más relevantes.
1 El término ontología en informática hace referencia al intento de formular un exhaustivo y riguroso esquema conceptual dentro de un dominio
dado, con la finalidad de facilitar la comunicación y la compartición de la información entre diferentes sistemas.
22
A través del modelado (Booch, Rumbaugh y Jacobson, 2002), se consiguen los siguientes
propósitos:
1. Especificaciones abstractas de la estructura esencial de un sistema.
2. Especificaciones completas de un sistema final.
3. Ejemplos de sistemas típicos o posibles.
4. Descripciones completas o parciales de sistemas.
Existe una serie de principios básicos que permiten el modelado del software (Booch et al., 2002).
El primero de ellos es tener en cuenta que la elección de los modelos a crear tiene una profunda
influencia sobre cómo plantea un problema y cómo se forma una solución. Por lo tanto, los
modelos adecuados arrojan luz sobre problemas complicados, y ofrecen una comprensión amplia
en el espectro de soluciones. Los modelos elegidos pueden afectar mucho la visión del mundo. Si
se construye un sistema con la mirada de un analista con perspectiva estructurada, probablemente
se obtendrán modelos centrados en los algoritmos, con datos fluyendo de proceso en proceso. Si
se construye, en cambio, con la mirada de un desarrollador orientado a objetos, se obtendrá un
sistema cuya arquitectura se centra en una gran cantidad de clases y patrones de interacción que
gobiernan el cómo se trabajan esas clases. Por lo tanto, cada visión del mundo conduce a un tipo
de sistema diferente, con diferentes costes y beneficios.
El segundo principio básico (Booch et al., 2002) del modelado dice que todo modelo puede ser
expresado a diferentes niveles de precisión. Por ejemplo, un usuario final se centrará en el qué; y
un desarrollador de software se centrará en el cómo. En cualquier caso, los mejores tipos de
modelos son aquéllos que permiten elegir el grado de detalle, dependiendo de quién está viendo
el sistema y por qué necesita verlo.
Finalmente el tercer principio (Booch et al., 2002) establece que los mejores modelos están
ligados a la realidad. En el desarrollo de software, la falla de las técnicas de análisis estructurado
es la existencia de una desconexión básica entre el modelo de análisis y el modelo de diseño del
sistema. No poder salvar este abismo hace que el sistema concebido y el sistema construido
diverjan con el paso del tiempo. Aunque, en los sistemas orientados a objetos es posible conectar
todas las vistas casi independientes de un sistema en un todo semántico.
23
Por lo general, los modelos se segmentan en forma descendente, permitiendo mostrar un software
por partes; esto no es importante para sistemas pequeños, pues de ellos se puede decir todo lo
necesario en una o dos páginas, y cualquiera que necesite conocer algún aspecto del sistema, bien
puede conocerlo en su totalidad. Pero para los grandes sistemas es muy importante el principio de
descomposición ya que permite ir del modelo general al más específico, y en caso de error este se
puede modificar con facilidad.
La mayoría de los softwares requieren de múltiples modelos: cada modelo se enfoca a un número
limitado de aspectos del software, a la vez que minimiza o ignora otros de sus aspectos que para
el momento no son importantes. Esto ocurre sobre todo en muchos software, pues tienen
características funcionales, estructuras de datos complejas, y consideraciones complejas.
1.2. Herramientas para el desarrollo de software
Para Yourdon (1989), el analista hace uso de herramientas de modelado para:
Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar
atención a otras menos importantes.
Discutir cambios y correcciones de los requerimientos del usuario, a bajo costo y con el
riesgo mínimo.
Verificar que el analista comprenda correctamente el ambiente del usuario y que lo haya
respaldado con información documental para que los diseñadores de sistemas y los
programadores puedan construir el sistema.
En el proceso de desarrollo de software se pueden utilizar diversos tipos de herramientas que
facilitan el proceso. Entre ellos están aquellos herramientas que facilitan a los programadores el
desarrollo de código (editores, compiladores, linkers, entornos de desarrollo integrado –IDE’s) y
las herramientas de gestión y control de proyectos. Sin embargo, cualquiera de estas herramientas
que se use debe tener las siguientes características:
Debe ser gráfica, con detalles textuales de apoyo apropiados.
Debe permitir que el sistema sea visto en segmentos, en forma descendente.
Debe ser no redundante.
24
Debe ayudar al lector a predecir el comportamiento del sistema.
Debe ser transparente para el lector.
Cabe afirmar que, los modelos gráficos, conocidos como diagramas de desarrollo de software,
ofrecen una ventaja visual al desarrollo de software; el viejo adagio de que “una imagen vale más
que mil palabras” es cierto porque los diagramas reflejan de manera clara una explicación de lo
que se quiere del software a desarrollar, contrario a lo que se alcanzaría con una narración. Así,
diagramas bien desarrollados pueden transmitir de manera concisa y compacta una gran cantidad
de información.
Para Gagliardi (2003) al obtener el modelo conceptual de un software se pueden considerar dos
etapas:
1. Etapa análisis de requisitos: esta es la etapa de percepción, identificación y descripción
de los fenómenos y componentes del mundo real a analizar. Aquí es donde debemos
preguntarnos ¿qué representar?. Entonces, mediante el estudio de las reglas que lo rigen,
la recopilación documental y entrevistas a los usuarios de distintos niveles, llegamos a
elaborar un esquema descriptivo de la realidad.
2. Etapa de conceptualización: en esta etapa se refina el esquema descriptivo,
estructurándolo para que de esta forma respondamos la pregunta ¿cómo representar? Y es
aquí donde se presenta un modelo de datos expresado en términos matemáticos,
satisfaciendo propiedades tales como coherencia, plenitud, no redundancia, simplicidad,
fidelidad, exactitud, etc.
1.3. Requerimientos, análisis y diseño de software
Como ya se mencionó anteriormente, el modelo conceptual esta conformado por dos grandes
componentes, el análisis y el diseño de software, pero antes de realizar el análisis se deben tener
muy claros cuáles son los requerimientos de software, con el fin de que la persona que desarrolla
el software tenga los elementos necesarios para interpretar la realidad.
25
1.3.1. Requerimientos de software
Extraer los requerimientos de software forma parte de la Ingeniería de Requisitos que se ocupa de
la primera etapa en el proceso de desarrollo del software: la comprensión y formalización de las
necesidades que debe satisfacer un sistema informático (Locopoulos, 1995). Dentro de esta
especialidad se encuentran los requerimientos funcionales y no funcionales. Los requerimientos
provienen de los aspectos del software existente, de los usuarios que van a hacer uso del
software, del entorno de la organización, del entorno físico que la rodea, del conocimiento del
dominio de la aplicación y de los objetivos que se quieren alcanzar con el software a desarrollar.
Requerimientos funcionales
Son aquellos que describen los servicios (funciones) que se esperan que el software proveerá en
cuanto a:
Funciones de actualización de datos.
Entrada y salida de datos.
Funciones de consulta.
Informes proporcionados.
Datos manejados.
Interacción con otros sistemas.
Ejemplo de estos requisitos pueden ser que el software acepte o rechace alguna función intrínseca
al sistema.
Requerimientos no funcionales
Son los requisitos que indican las necesidades no relacionadas directamente con lo que el
software hace, sino cómo lo hace, se podía decir que describen los atributos del sistema y sus
restricciones en cuanto a:
Rendimiento.
Frecuencia del tratamiento.
Requisitos de seguridad, donde se tratar aspectos como: control de accesos,
procedimientos de copias de respaldo y recuperación e integridad de la información.
Un ejemplo puede ser que en las aplicaciones del software se requiera una respuesta en un
tiempo determinado o un grado de seguridad determinada. En los requerimientos no
26
funcionales se incluyen: la portabilidad, la seguridad, la eficiencia, la reutilización, el
entorno de desarrollo, la usabilidad, la disponibilidad, la fiabilidad, el tiempo de respuesta,
la capacidad de almacenamiento, la capacidad de los dispositivos de entrada/salida, y la
representación de datos que se utiliza en las interfaces del sistema, etc.
1.3.2. Análisis de software
Después de saber cuáles son los requerimientos de software y de haber sido éstos aprobados por
parte de los usuarios del sistema o clientes, se puede iniciar su desarrollo con el modelo de
análisis que toma como punto de partida la especificación de requisitos y tiene como meta
construir una arquitectura capaz de resolver el problema bajo condiciones ideales para el sistema.
Esto significa que se busca desarrollar una estructura lógica del sistema, que debe ser funcional,
confiable, usable, eficiente, mantenible y portable; todas enmarcadas dentro de las características
de calidad que debe tener un software (Losavio, Chirinos y Lévy., 2003). El análisis de software
se enfoca en qué debe hacer el sistema, en lugar de cómo se supone que lo hará. El alcance del
modelo de análisis está directamente relacionado con la naturaleza de los conceptos del modelo.
El analista de software, trata básicamente de determinar los objetivos y límites del sistema a
analizar, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar
los objetivos propuestos y evaluar sus consecuencias.
Por lo general, se pueden agrupar las tareas que constituyen el análisis en una serie de etapas que
se suceden de forma iterativa hasta validar el proceso completo:
Análisis de conceptos: referente a obtener información de alto nivel del sistema,
identificando sus elementos básicos y las relaciones de éstos entre sí y con el entorno.
Especificaciones funcionales: es el cconjunto de especificaciones formales que describan
la funcionalidad del sistema, estableciendo los subsistemas en que se descompondrá,
definiendo los datos que utilizará y las interfaces de usuario.
Análisis de condiciones: refleja todas aquellas limitaciones impuestas al sistema que
restringen el margen de las soluciones posibles.
27
Construcción de modelos: en esta etapa se procede a construir un prototipo del modelo
en definitiva.
Validación del análisis: a fin de comprobar que el análisis efectuado es correcto y evitar
la propagación de errores a la siguiente fase, es necesario proceder a la validación del
mismo, para esto se debe comprobar que el análisis sea consistente y completo.
1.3.3. Diseño de software
El diseño de software se ocupa de desarrollar las directrices propuestas durante el análisis en
términos de una configuración que tenga más posibilidades de satisfacer los objetivos planteados,
tanto desde el punto de vista funcional como del no funcional (las condiciones).
El propósito del modelo de diseño (Weitzenfeld, 2004) es extender la arquitectura general
desarrollada en el análisis. Este refinamiento se debe a dos razones principales:
El modelo de análisis no es suficientemente formal, por lo que, para poder llegar al código
final conviene refinar las estructuras de la arquitectura general. Se debe especificar las
operaciones a utilizar como: la comunicación entre componentes, los eventos, etc. Este
aspecto es conocido como el diseño de estructuras o de manera general como el diseño de
objetos en el caso de arquitecturas orientadas a objetos.
Durante el análisis se asume un mundo ideal para el sistema. En la realidad este mundo
ideal debe adaptarse al ambiente donde se implementará el sistema. Entre otros aspectos,
se deben considerar los requisitos de rendimiento, aspectos de tiempo real, concurrencia,
propiedades del lenguaje de programación, el sistema de manejo de base de datos, etc.
Ello es conocido como el diseño de sistema.
La razón para no incluir estos aspectos durante el modelo de análisis se debe a que los aspectos
anteriores no influencian la arquitectura del sistema. En general, la propia aplicación controla la
arquitectura y no las circunstancias existentes durante su implementación. Desde otra perspectiva,
el modelo de análisis debe ser visto como un modelo conceptual y lógico del sistema, mientras
que el modelo de diseño debe acercarse más a la solución final. Esto significa que se cambia el
punto de vista del modelo de diseño a una abstracción del código fuente a ser escrito. Por lo tanto,
es esencial guardar y congelar el modelo de análisis para un mantenimiento futuro incluso
después de terminar el diseño (Weitzenfeld, 2004).
28
Dentro del proceso de diseño de software hay que tener en cuenta los efectos que puede producir
la introducción de un nuevo software sobre el entorno en el que va funcionar, adecuando los
criterios de diseño a las características de este entorno.
El proceso de diseño de un software complejo se suele realizar de forma descendente:
Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos
complejos).
Diseño e implementación de cada uno de los subsistemas:
Especificación consistente y completa del subsistema de acuerdo con los objetivos
establecidos en el análisis.
Desarrollo según la especificación.
Prueba.
Integración de todos los subsistemas.
Validación del diseño.
Existen herramientas que ayudan al proceso de diseño de un software, facilitando la tarea de este
proceso, estás herramientas serán analizadas con detalle en los capítulos siguientes.
Principios básicos de diseño
Díaz (2007) desglosa en ocho los principios básicos de diseño:
El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de
análisis y debe acomodar todos los requisitos implícitos que desee el cliente.
El diseño debe ser una guía que puedan leer y entender los que construyan el código y los
que prueban y mantienen el software.
El diseño debe proporcionar una completa idea de lo que es el software, enfocando los
dominios de datos, funcional y de comportamiento desde la perspectiva de la
implementación.
El diseñador debe considerar enfoques alternativos juzgando a cada uno en base a los
requisitos del problema, los resultados disponibles y los criterios de calidad interna.
Se deberían poder seguir los pasos de diseño hasta el modelo de análisis.
El diseño debería presentar uniformidad e integración.
29
Debe estructurarse para admitir cambios.
Se debe valorar la calidad del diseño mientras se crea, no después de terminado.
1.4. Propuesta de investigación
Una vez estudiados las partes involucradas del modelado, el análisis y diseño de software,
contamos con los basamentos teóricos para realizar la investigación del análisis comparativo de
los diagramas UML con otros enfoques utilizados para el desarrollo de software.
En esta investigación se analizan los diferentes tipos de diagramas usados para el diseño y
análisis de software. El modelado de estos diagramas nos permite comunicarnos con el usuario,
sin distraer la atención con asuntos y características ajenas al software. Una ventaja del modelado
es que si nuestra comprensión de los requerimientos del usuario no fue la correcta (o que el
usuario cambió de parecer acerca de sus requerimientos), podemos hacer cambios en el modelado
o desecharlo y hacer uno nuevo de ser necesario, sin que eso signifique mayores costos en la
implementación.
1.5. Objetivos de la investigación
1.5.1. Objetivo general
Analizar los enfoques utilizados para el desarrollo de software que han surgido hasta la aparición
de los diagramas UML.
1.5.2. Objetivos específicos
Presentar un marco de referencia sobre la aplicación y definición de los modelos
conceptuales de desarrollo de software en general.
Presentar un estudio de los diagramas más utilizados en el modelado de software.
Introducir las técnicas de modelado mediante UML.
Describir las diferencias y semejanzas entre los diagramas utilizados en la programación
estructurada y el método orientado a objeto con los diagramas UML.
30
1.6. Marco metodológico
La investigación esta orientada a identificar y describir los distintos enfoques utilizados para el
modelado de software desde la aparición de la programación estructurada hasta el Lenguaje de
Modelado Unificado – UML; con el propósito de entender cómo el desarrollo de los primeros
enfoques influyeron en la creación de un solo lenguaje de modelado.
El estudio se realiza en el ámbito teórico, por lo que, para recoger los datos se recurrirá a la
revisión documental. Dicha revisión permitirá describir, interpretar y explicar los eventos de
estudio de esta investigación.
El procedimiento de recolección de información será el siguiente:
1. Lectura general del material relacionado con los eventos de estudio: enfoques de modelado de
desarrollo de software.
2. Selección de las fuentes apropiadas para recoger datos relevantes.
3. Validación de las fuentes seleccionadas.
4. Lectura detallada de las fuentes seleccionadas, relacionada con los eventos de estudio.
5. Localización del material relevante.
6. Organización del material según el esquema de investigación.
7. Redacción y construcción de las teorías que describen y explican los eventos.
8. Establecimiento y descripción de las categorías de los eventos de estudio para los cuales se
pretende identificar relaciones.
9. Análisis comparativo de los datos aportados por las teorías seleccionadas, en relación con los
eventos de estudio, a través de la clasificación y descripción de los mismos.
10. Construcción de la propuesta de investigación a partir del análisis de los datos obtenidos, para
responder al objetivo general de la misma.
Desarrollo
Estructurado
CAPITULO
Desarrollo Estructurado
Con este capítulo se da inicio al estudio del desarrollo estructural comenzando con una pequeña
reseña histórica sobre la forma de programar y su evolución hasta llegar al diseño top down.
En los primeros años de la computación, los programadores enviaban instrucciones binarias a una
computadora, manipulando directamente interruptores en sus paneles de control. En la década de
los cincuenta, los únicos mecanismos de programación eran los lenguajes de máquina y el
lenguaje ensamblador (lenguajes de bajo nivel). Luego de los lenguajes ensamblador aparecieron
los lenguajes de programación de alto nivel, que supusieron un nuevo estilo de programación.
Los lenguajes de programación de alto nivel permitieron a los programadores distanciarse de las
características arquitectónicas específicas de una computadora ya que cada instrucción en un
lenguaje de alto nivel podía invocar varias instrucciones de máquina, dependiendo de la
computadora donde se compilara el programa. Con el nacimiento de estos lenguajes de
programación surge la programación estructurada, con sus métodos de análisis. La programación
estructurada, aparece en la década de los 60 en el ámbito científico y en la década de los 70 pasa
al ámbito empresarial. Tiene como punto de partida el establecimiento y uso de normas para la
aplicación de estructuras de datos y control.
En los setenta, el enfoque estructurado, se extiende de la fase de análisis a la fase de diseño y las
técnicas estructuradas se dirigen tanto a los aspectos técnicos como los relacionados con la
gestión en la construcción de software. Myers (1975), Yourdon y Constantine (1975) y Page-
Jones (1980), en sus publicaciones, definen al módulo del programa como el componente básico
de la construcción software, pasando luego a la normalización de la estructura los módulos de
programa y al refinamiento posterior. Es este período comienzan a aplicarse medidas de calidad
de los programas.
34
La base de la programación y el diseño estructurados, es un análisis del problema usando el
diseño top-down o descendente, con énfasis en las especificaciones funcionales. Se intentó dotar
a las especificaciones funcionales de componentes gráficos como los diagramas que facilitarían la
comprensión, la descomposición del problema y buscar la mínima redundancia, de modo que los
cambios sólo afectaran a partes independientes del proyecto.
Este capítulo trata sobre el estudio del desarrollo estructurado que se apoya esencialmente en el
uso de la programación estructurada y en el diseño modular en donde se analizan los diagramas
más utilizados en el análisis y diseño de software.
2.1. Programación estructurada
En un inicio, la programación estructurada fue desarrollada por Edsgar W. Dijkstra en sus Notes
on Structured Programming y se basa en el denominado Teorema de la Estructura desarrollado
en 1966 por Bömh y Jacopini, que se ratificó con los trabajos de Charlan D. Mills.
En la actualidad existen diversas definiciones de estos diagramas, pero todas ellas giran alrededor
del teorema de estructura que, Bömh y Jacopini que inician con la técnica de programación a
través de módulos o bloques.
La característica fundamental de la programación estructurada es que se basa en el uso único de
tres estructuras de control. Para ello se apoya en las siguientes filosofías: (1) diseño descendente
(top – down), (2) recursos abstractos y (3) estructuras básicas de control.
Diseño top - down
Los programas se diseñan de lo general a lo particular por medio de sucesivos refinamientos o
descomposiciones que nos van acercando a las instrucciones finales del programa. En la Figura
2.1 se puede observar como un problema inicial se va desglosando de lo general a lo particular.
35
Figura 2.1
Diseño top-down
Fuente: Joyanes (1992)
Se trata de ir descomponiendo el problema en niveles o pasos cada vez más sencillos, de manera
que la salida de una etapa va a servir como entrada de la siguiente. En las primeras etapas
tomamos el punto de vista externo, es decir, se conoce que entradas hay y que salidas hay, y a
medida que se va bajando de nivel, se va observando de manera interna (como lo hace por
dentro).
Cuando se realiza esta descomposición debe tenerse en cuenta que: cada subproblema está en un
mismo nivel de detalle, que cada uno se puede resolver independientemente de los demás y que
las soluciones de estos subproblemas pueden combinarse para resolver el problema original. La
solución a cada uno de estos subproblemas se denomina módulo.
La programación modular es uno de los métodos de diseño más flexibles y potentes que existen
para mejorar la productividad de un programa. La descomposición de un programa en módulos
independientes más simples se conoce también como el método de “divide y vencerás”. Se diseña
cada módulo con independencia de los demás y, siguiendo un método descendente, se llega hasta
la descomposición final del problema en módulos en forma jerárquica.
Dado que los módulos son independientes, diferentes programadores pueden trabajar
simultáneamente en distintas partes de un mismo programa. Esto reduce el tiempo de diseño del
algoritmo y posteriormente la codificación del programa. Además, un módulo se puede modificar
radicalmente sin afectar a otros módulos.
PROBLEMA INICIAL
SUBPROBLEMA 1 SUBPROBLEMA 2 SUBPROBLEMA 3
PRIMER
REFINAMIENTO
SEGUNDO
REFINAMIENTO
1. 1 1. 2 3. 21. 3 3. 12. 32. 22. 1
.... . . ...
TOP
DOWN....
PROBLEMA INICIAL
SUBPROBLEMA 1 SUBPROBLEMA 2 SUBPROBLEMA 3
PRIMER
REFINAMIENTO
SEGUNDO
REFINAMIENTO
1. 1 1. 2 3. 21. 3 3. 12. 32. 22. 1
.... . . ...
TOP
DOWN....
36
Las ventajas más importantes de este tipo de diseño son:
Facilita el desarrollo de los programas, al descomponerlos en módulos o segmentos que
resultan más sencillos de programar.
Facilita el desarrollo de los módulos, al tener que aplicar en ellos las tres estructuras
básicas de control (secuencial, alternativa y repetitiva).
Facilita el mantenimiento de los programas, ya que resulta fácil indicar el módulo que hay
que modificar.
Permite localizar fácilmente los errores del programa y además hace que el programador
cometa menos errores.
Utilización de recursos abstractos
Es el complemento perfecto para el diseño TOP – DOWN donde se utiliza el concepto de
abstracción: es decir, en cada descomposición se supone que todas las partes resultantes están
resueltas, dejando su realización para el siguiente refinamiento y considerando que todas ellas
pueden llegar a estar definidas en instrucciones y estructuras disponibles en los lenguajes de
programación.
Estructuras básicas de control
Como se indicó anteriormente, el teorema de la estructura dice que toda acción se puede realizar
utilizando tres estructuras básicas de control, la estructura secuencial, alternativa y repetitiva.
Con ello interpretaremos que una determinada acción representada en una de las tres estructuras
puede estar compuesta por una o más estructuras en su interior.
Dentro de estas estructuras básicas se encuentran los diagramas de flujo y los diagramas de
Nassi-Shneiderman (N-S) y el pseudocódigo, este último no será explicado ya que no es tema de
esta investigación.
37
2.1.1 Diagramas de flujo o flujograma
Un diagrama de flujo (flowchart) o flujograma como también se le dice es la representación
gráfica de los pasos que deben seguirse para resolver un problema. Según Joyanes (1990) un
diagrama de flujo es un diagrama que utiliza símbolos para poder representar la solución de un
algoritmo.
Los diagramas de flujo generalmente especifican los procesos de un sistema en forma funcional;
cada diagrama describe las entradas, los pasos de proceso y las salidas para la función en
cuestión; un diagrama general puede indicar la localización de los diagramas de detalles
subordinados necesarios.
En la elaboración de éstos, la simbología juega un papel muy importante, ya que debe estar
adecuada a ciertos estándares, con el fin de que sea entendida por cualquier persona dedicada al
campo de la programación.
En los diagramas de flujo se utilizan símbolos o cajas unidas por flechas, denominadas líneas de
flujo. Cada una de estos símbolos representa una etapa en la solución del problema; dentro de
ellas se anotan indicaciones. Las líneas señalan el flujo de la información.
En la actualidad se emplean poco, pero resultan muy útiles cuando se comienza en el estudio de
la programación. El problema con los diagramas de flujo es que a medida que crece la
complejidad de las proposiciones, también crece el detalle con el que hay que dibujarlas. Esto
llegaba a convertirlos en figuras fraccionadas (pues de otro modo no cabrían en la hoja), y
difíciles de seguir y entender.
Los diagramas de flujo estructurados difieren de los diagramas tradicionales en que los primeros
tienen restricción en cuanto a las formas de uso; con esto se obtiene que la gráfica obtenida sea
un equivalente gráfico de la descripción por medio del pseudocódigo estructurado que desarrollan
de acuerdo a la tendencia de la programación modular.
38
Los diagramas de flujo estructurados poseen una entrada única y una salida única; así estas
formas pueden ser anidadas dentro de otras formas hasta el nivel deseado de anidamiento,
manteniendo el principio del teorema de la estructura.
Los símbolos utilizados han sido normalizados por el Instituto Norteamericano de Normalización
(ANSI) y los más frecuentes utilizados son:
Inicio o fin de proceso: Indica el inicio o el fin de un
Diagrama de Flujo. Dentro de la figura se debe escribir
"inicio" o fin; según sea el caso.
Acciones u operaciones: Se utiliza para señalar las
actividades, los pasos o las instrucciones en forma secuencial.
Entrada/Salida de información: Representa la entrada y
salida de datos en la computadora.
Decisión: Indica una ccondición. Sirve para representar
estructuras selectivas y repetitivas y lo que se hace al
encontrar ese signo es evaluar la condición que hay dentro tal
que según la condición sea verdadera o falsa se ira por
caminos distintos.
Líneas de flujo: Indican el sentido o dirección que lleva el
diagrama de flujo desde su inicio hasta su fin.
Conector: Indica la continuidad del Diagrama De Flujo en
una misma página. Dentro de la circunferencia se anota un
número o una letra.
Conector de página: Indica la continuación del diagrama de
flujo de una página a otra. Se debe especificar con letra o
número esta secuencia.
Subprograma: Dentro se coloca el nombre del subprograma
al que se llama.
Pantalla: Cuando una salida es por pantalla.
Teclado: Para representar una entrada por teclado.
Impresora: Salida por impresora
39
Entrada/Salida por disco
Reglas básicas de un diagrama de flujo
1. Todo diagrama debe tener un inicio y un fin.
2. Las líneas de conexión o de flujo deben ser siempre rectas, si es posible verticales y
horizontales nunca cruzadas o inclinadas; para conseguir lo anterior es necesario apoyarse
en conectores.
3. Las líneas que enlazan los símbolos entre sí deben estar todas conectadas.
4. Se deben dibujar todos los símbolos de modo que se pueda seguir el proceso visualmente
de arriba abajo (diseño de top-down) y de izquierda a derecha.
5. Realizar un gráfico claro y equilibrado.
6. Evitar la terminología de un lenguaje de programación o máquina.
7. Utilizar comentarios ya sea al margen o mediante el símbolo gráfico comentarios para que
éste sea entendible por cualquier persona que lo consulte.
8. A cada bloque o símbolo se accede por arriba y/o por la izquierda y se sale por abajo y/o
por la derecha.
9. Si el diagrama abarca más de una hoja es conveniente enumerarlo e identificar de donde
viene y a donde se dirige.
En la Figura 2.2 se muestra un ejemplo de un diagrama de flujo.
Figura 2.2
Ejemplo de diagrama de flujo
Fuente: Joyanes (1992)
S
N
inicio
A
X1
IMP
fin
F
G
S
N
inicio
A
X1
IMP
fin
F
G
40
Estructuras básicas de los diagramas de flujo
Los diagramas de flujo estructurados, como su nombre menciona, es actualmente caracterizado
como una herramienta de la programación estructurada. Debido a la características propias de la
programación estructurada se puede interpretar cada acción de un programa y representarlo
gráficamente (en un diagrama estructurado) con la debida estructura (simple o compuesta) de la
diagramación estructurada.
1. Estructura Secuencial. Es una estructura con una entrada y una salida en la cual figuran
una serie de acciones cuya ejecución es lineal y en el orden en que aparecen. A su vez.
Todas las acciones tienen una única entrada y salida. En la Figura 2.3 se muestra un
ejemplo de esta estructura.
Figura 2.3
Estructura secuencial
Fuente: Joyanes (1992)
2. Estructura alternativa. Es una estructura con una sola entrada y una sola salida en la cual
se realiza una acción de entre varias, según una condición o se realiza una acción según el
cumplimiento o no de una determinada condición. Esta condición puede ser simple o
compuesta. Las estructuras alternativas pueden ser: simples (Ver Figura 2.4), dobles (Ver
Figura 2.5) y múltiples (Ver Figura 2.6).
A
B
C
A
B
C
COND
.
AN
SCOND
.
AN
S
COND
.
BA
NS COND
.
BA
NS
Figura 2.4
Estructura “alternativa simple”
Figura 2.5
Estructura “alternativa doble”
Fuente: Joyanes (1992)
41
3. Estructura repetitiva. Es una estructura con una entrada y una salida en la cual se repite
una acción un número determinado o indeterminado de veces, dependiendo en este caso
del cumplimiento de una condición. Las estructuras repetitivas pueden ser: (a) estructura
“para o for”, (b) estructura “mientras o while” y (c) estructura “hasta o until”.
(a) Estructura “para o for”. En esta estructura se repite una acción un número fijo de veces
representado normalmente por N. En la Figura 2.7 se muestra un ejemplo de esta
estructura.
Fuente: Joyanes (1992)
COND
.
A B C D
COND
.
A B C D
Ni := X
Si Ni > Nf
Ni=Ni+1
A
S
N
Ni := X
Si Ni > Nf
Ni=Ni+1
A
S
N
Figura 2.6
Estructura “alternativa múltiple”
Fuente: Joyanes (1992)
Figura 2.7
Estructura “para o for”
42
(b) Estructura “mientras o while”. En esta estructura se repite una acción mientras se cumpla la
condición que controla el bucle. La característica principal de esta estructura es la de que la
condición es evaluada siempre antes de cada repetición. En la Figura 2.8 se muestra un ejemplo
de esta estructura.
Figura 2.8
Estructura “mientras o while”
Fuente: Joyanes (1992)
El número de repeticiones oscila entre cero e infinito, dependiendo de la evaluación de la
condición, cuyos argumentos en los casos de repetición, al menos una vez, deberán modificarse
dentro del bucle, pues de no ser así el número de repeticiones será infinito y nos encontraremos
en un bucle sin salida.
(c)Estructura “hasta o until”. En esta estructura se repite una acción hasta que se cumpla la
condición que controla el bucle, la cual se evalúa después de cada ejecución del mismo. El
número de repeticiones oscila entre 1 e infinito, dependiendo de la evaluación de la condición,
cuyos argumentos en los casos de repetición, al menos dos veces, deberán modificarse dentro del
bucle, pues de no ser así el número de repeticiones será infinito y nos encontraremos en un bucle
sin salida. En la Figura 2.9 se muestra un ejemplo de esta estructura.
Figura 2.9
Estructura “hasta o until”
Fuente: Joyanes (1992)
S
condición
N
A
S
condición
N
A
S
condiciónN
A
S
condiciónN
A
43
2.1.2 Diagrama de Nassi−Schederman (N-S)
El modelo de diagramas fue desarrollado por Isaac Nassi y Ben Shneiderman, publicándose en el
año 1973. Corresponden a las normas DIN 66261 e ISO/IEC 8631:1989. Dado que muestran las
estructuras de un programa, también se denominan “estructogramas”.
Los diagramas estructurados N-S también conocido como diagrama de chapin son como los
diagrama de flujo con la diferencia que en estos diagramas se omiten las flechas de unión y las
cajas son contiguas. Un enfoque más estructurado, pero menos visual, para el diseño y la
documentación de estos diagramas.
Los diagramas NS tienen tres símbolos principales: el primero es un cuadro que sirve para
representar cualquier proceso en el programa; el segundo símbolo es una decisión; y el tercero es
un cuadro dentro de otro cuadro que se utiliza para indicar que se lleva a cabo una interacción.
Las acciones sucesivas se pueden escribir en cajas sucesivas y como en los diagramas de flujo, se
pueden escribir diferentes acciones en una caja.
Una de las ventajas de estos diagramas es que adopta la filosofía de la programación estructurada,
que utiliza un enfoque descendente, utiliza un número limitado de símbolos de tal forma que el
diagrama de flujo ocupa menos espacio y puede leerse con cierta finalidad. Estos diagramas
deben estar completos y ser muy claros, con el fin de que se entiendan. En la Figura 2.10 se
muestra la estructura de estos diagramas.
Figura 2.10
Ejemplo de diagrama N-S
Fuente: Martin y McClure (1985)
44
Estructuras básicas de los diagramas N-S
Secuencia: Sucesión de dos o más operaciones cuya ejecución coincide con el orden de aparición
de las instrucciones. En la Figura 2.11 se muestra un ejemplo de esta estructura.
Figura 2.11
Estructura secuencial de un diagrama N-S
Fuente: Martin y McClure (1985)
Decisión (si condicional): Bifurcación entre dos alternativas condicionada por los datos del
problema. La instrucción evalúa una condición y ejecuta el conjunto de instrucciones que
corresponda al valor de verdad retornado. En la Figura 2.12 se muestra un ejemplo de esta
estructura.
Figura 2.12
Estructura de decisión de un diagrama N-S
Fuente: Martin y McClure (1985)
Iteración: Repetición de un conjunto de instrucciones mientras se cumpla una condición. En la
Figura 2.13 se muestra las diferentes estructuras de interacción: mientras, repetir y para o hasta.
NOMBRE DEL ALGORITMO
<ACCIÓN 1>
<ACCIÓN 2>
<ACCIÓN 3>
…
FIN
NOSI
CONDICIÓN
<ACCIÓN 1> <ACCIÓN 2>
NOSI
CONDICIÓN
<ACCIÓN 1> <ACCIÓN 2>
45
Figura 2.13
Estructuras de iteración
“mientras” “repetir” “para o hasta”
Fuente: Martin y McClure (1985)
Estos tres tipos de estructuras lógicas de control pueden ser combinadas para producir programas
que manejen cualquier tarea de procesamiento de información.
2.2 Diseño estructurado
2.2.1 Diagrama de flujo de datos (DFD)
La creación de Diagramas de Flujo de Datos (también en inglés: Data Flow Diagram) es una
actividad de construcción de modelos que utiliza una notación propia del método de análisis
estructurado con los que se crean modelos que reflejan el flujo y el contenido de la información
(datos y control), estableciendo lo que se debe construir mediante una división funcional del
sistema.
Para Yourdon (1989), el diagrama de flujo de datos (DFD, en adelante) es una de las
herramientas más comúnmente usadas, sobre todo por sistemas operacional en los cuales las
funciones del sistema son de gran importancia y son más complejas que los datos que éste maneja.
Los DFD se utilizaron por primera vez en la ingeniería de software como notación para el estudio
del diseño de sistemas (por ejemplo, en los libros y artículos de diseño de diseño estructurado
tales como (Stevens, Myers y Constantlne, 1974), (Yourdon y Constantine, 1975), (Myers, 1975),
y otros). A su vez, la notación se tomó prestada de artículos anteriores sobre teoría de gráficas, y
continúa siendo utilizada por los ingenieros de software que trabajan en la implantación directa
de modelos de los requerimientos del usuario.
MIENTRAS <COND>
<ACCIONES>
MIENTRAS <COND>
<ACCIONES>
REPETIR HASTA <COND>
<ACCIONES>
REPETIR HASTA <COND>
<ACCIONES>
DESDE VI=V1 HASTA VN
<ACCIONES>
DESDE VI=V1 HASTA VN
<ACCIONES>
46
Objetivos de los DFD
Describir el contexto del sistema, determinando lo que ocurrirá en cada una de
las áreas de la empresa, denominadas Entidades externas, que participen de este
sistema.
Detallar los procesos a ser realizados; en cada uno de los procesos o módulos
del sistema.
Enumerar los archivos de datos necesarios, en cada proceso.
Definir los flujos de datos, que participen en el procedimiento.
Para analizar los DFD es necesario conocer sus componentes básicos: el proceso, el flujo de datos,
el almacén de datos y las entidades externas. Se analizará los métodos más comunes como:
Yordon & DeMarco, el de Gane & Sarson y SSADM, pero básicamente todos estos métodos
funcionan de la misma manera, lo que cambia es su estructura física.
Componentes de un DFD
Procesos: representa una función que transforma los flujos de datos de entrada en uno o varios
flujos de datos de salida, también llamado burbuja, función o transformación. El proceso debe ser
capaz de generar los flujos de datos de salida a partir de los flujos de datos de entrada más alguna
información local. Se debe cumplir la denominada “Regla de conservación de la información”:
Cuando un flujo de datos o un componente suyo llega a un proceso y no es utilizado, hay una
pérdida de Información.
Para Yourdon (1989), el proceso se representa gráficamente como un circulo que es la notación
más conocida, como se muestra en la Figura 2.14 (Yourdon/DeMarco). Algunos analistas
prefieren usar un óvalo como Gane/Sarson o un rectángulo (SSADM/METRICA) como se
muestra en las Figuras 2.14 respectivamente.
47
Yourdon/DeMarco Gane/Sarson SSADM
Fuente: Yourdon (1989)
Las diferencias entre estas tres formas son puramente cosméticas, la función es la misma, aunque
obviamente es importante usar la misma forma de manera consistente para representar todas las
funciones de un sistema.
El nombre del proceso describirá lo que hace, un buen nombre generalmente consiste en una
frase verbo-objeto como por ejemplo Validar-Entrada. En algunos casos, el proceso contendrá el
nombre de una persona o un grupo (por ejemplo, un departamento o una división de una
organización), o de una computadora o un aparato mecánico. Es decir el proceso a veces describe
quién o qué lo está efectuando, más que describir el proceso mismo. La numeración de los
procesos se hace de forma jerárquica.
Flujo de datos: según Yourdon (1989), un flujo se representa gráficamente por medio de una
flecha que entra o sale de un proceso. El flujo se usa para describir el movimiento de bloques o
paquetes de información de una parte del sistema a otra. Por ello, los flujos representan datos en
movimiento, la flecha indica la dirección de la información.
En la mayoría de los sistemas que se modele como analista, los flujos realmente representarán
datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de
información con los que las computadoras pueden tratar. Pero los DFD también pueden utilizarse
para modelar otros sistemas aparte los automatizados y computarizados; pudiera escogerse, por
ejemplo, usar un modelo de DFD para modelar una línea de ensamblado en la que no haya
componentes computarizados.
Figura 2.14
Diferentes procesos de un DFD
48
Los nombres de los flujos de datos representa el significado del paquete que se mueve a lo largo
del flujo. Nótese también que los flujos muestran la dirección: una cabeza de flecha en cualquier
extremo (o posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo
hacia adentro o hacia afuera de un proceso (o ambas cosas), como se observa en la Figura 2.15.
Fuente: Yourdon (1989)
Tipos de flujo de datos
Los tipos de DFD atendiendo a su cometido son los siguientes:
Flujo de consulta: Muestra la utilización de la información del almacén por el proceso
para utilizar los valores de uno o más atributos de una ocurrencia y comprobar si los
atributos seleccionados cumplen unas condiciones, su representación se muestra en la
Figura 2.16 (a).
Flujo de actualización: Indica que el proceso va a alterar la información mantenida en el
almacén para: crear una nueva ocurrencia en el almacén, borrar una o más ocurrencias y
modificar el valor de un atributo su representación se muestra en la Figura 2.16 (b).
Flujo de diálogo: Representa un flujo de consulta y un flujo de actualización que no
tienen relación directa, su representación se muestra en la Figura 2.16 (c).
Flujo de Consulta (a) Flujo de Actualización (b) Flujo de Díalogo (c)
Fuente: Yourdon (1989)
Figura 2.15
Dirección de los flujos de datos
Figura 2.16
Diferentes flujos de datos
49
También puede aparecer entre procesos. En este caso se denomina Par de Diálogo. Se utilizan
cuando un flujo es una respuesta inmediata a otro. Deben aparecer los nombres de los dos flujos
representados. Sirve para simplificar el gráfico.
Almacenes de datos: según Yourdon (1989), el almacén de datos se utiliza para modelar una
colección de paquetes de datos en reposo o información del sistema almacenada de forma
temporal. Son independientes del dispositivo. Se denota por dos líneas paralelas
(Yourdon/DeMarco), una alternativa de notación es la Gane/Sarson y otra es la de
SSADM/METRICA como se pude apreciar en la Figura 2.17. De modo característico el nombre
que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que
entran y salen del almacén por medio de flujos.
Yourdon/DeMarco Gane/Sarson SSADM
Fuente: Yourdon (1989)
Terminadores o entidades externas
Yourdon (1989), los terminadores representan entidades externas con las cuales el sistema se
comunica. Comúnmente, un terminador es una persona o un grupo, por ejemplo, una
organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de
la misma compañía u organización, pero fuera del control del sistema que se está modelando, En
algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con
el cual se comunica éste.
Consideraciones a tomar en cuenta para las Entidades Externas:
Los flujos que parten o llegan a ellas definen la interfaz entre el sistema y el mundo
exterior.
Las relaciones existentes entre las entidades externas no se representan.
Figura 2.17
Representación de los almacenes de datos
50
Pueden aparecer varias veces en el DFD para ayudar a clarificar. Las entidades repetidas
se indican con un asterisco ‘*’.
Normalmente sólo aparecen en el DFD de mayor nivel.
En la Figura 2.18 se muestan las diferentes representaciones de las entidades externas según
Yourdon/DeMarco, Gane/Sarson y SSADM.
Fuente: Yourdon (1989)
Método Yourdon/DeMarco
Un estilo DFD de Yourdon/DeMarco se demuestra en la Figura 2.19. Incluye datos y flujo de
control como se requiere en los sistemas, usados típicamente en el análisis y diseño de sistemas.
Yourdon/DeMarco Gane/Sarson SSADM
Entidades Externas
Entidades Externas
Procesos
Almacenes de Datos
Flujo de datos
Procesos
Procesos
Procesos
Almacenes de Datos
Procesos
Entidades Externas
Entidades Externas
Procesos
Almacenes de Datos
Flujo de datos
Procesos
Procesos
Procesos
Almacenes de Datos
Procesos
Figura 2.18
Representación de las entidades externas
Figura 2.19
Ejemplo de un DFD con el método Yourdon/DeMarco
Fuente: Gacitúa (2003)
51
Método SSADM
Los sistemas estructurados de análisis y el método de diseño (también conocido comúnmente
como SSADM - Structured Systems Analysis and Design Method) es un método usado para el
análisis y el diseño de desarrollo de sistemas.
SSADM es un método de cascada, esto significa que es un método que consiste en etapas, sólo se
puede continuar a la etapa siguiente si se culmina la anterior. Los métodos como éstos se hacen
típicamente para hacer el desarrollo de software más fácil, rápido y eficaz.
SSADM utiliza una combinación de tres técnicas:
Modelo de datos lógicos (logical data modeling): este es el proceso de identificar, modelar y
documentar los requisitos de los datos del sistema que se esta diseñando. Los datos se separan en
las entidades (las cosas sobre las cuales un negocio necesita la información de registro) y las
relaciones (las asociaciones entre las entidades). En la Figura 2.20 se muestra un ejemplo del
modelo de datos lógicos.
Fuente: Hutchings (1997)
Modelo de flujo de datos (data flow modeling): este es el proceso de identificar, de modelar y
de documentar cómo los datos se mueven alrededor de un sistema de información. Los datos de
flujo modelado examinan los procesos (las actividades que transforman datos a partir de una
forma a otra), los almacenes de los datos (las áreas que sostienen para los datos), las entidades
externas (qué envían datos en un sistema o reciben datos de un sistema, y flujos de datos (rutas
Figura 2.20
Modelos de datos lógicos
Customer
Order
Order Line
Part
Customer
Order
Order Line
Part
52
por las cuales los datos pueden fluir). En la Figura 2.21 se muestra un ejemplo del modelo de
flujo de datos.
Fuente: Hutchings (1997)
Modelo de comportamiento de las entidades (entity behavior modeling): este es el proceso de
identificar, de modelar y de documentar los acontecimientos que afectan cada entidad y la
secuencia en las cuales estos acontecimientos ocurren. Un modelo de Entity/Behavior consiste en
la historia de la vida de la entidad (una para cada entidad) y se apropia de la documentación de
soporte. En la Figura 2.22 se muestra un ejemplo del modelo de comportamiento de las entidades.
Fuente: Hutchings (1997)
Figura 2.21
Modelos de flujo de datos
Figura 2.22
Modelo de comportamiento de las entidades
Customer
Accounts1
D1
Check customer
Detaild and
Create orde
Ordes
Customer
Accounts1
D1
Check customer
Detaild and
Create orde
Ordes
Customer
First Order
Placed
My life
Cy ole Outstanding
Balance =0
And o ordes
For 6 mths
Detail changesBalance Changs
Balance Change *
Pymnt O
Made
Order o
Acept
Detail change *
Nam O Addr O Tel O
Customer
First Order
Placed
My life
Cy ole Outstanding
Balance =0
And o ordes
For 6 mths
Detail changesBalance Changs
Balance Change *
Pymnt O
Made
Order o
Acept
Detail change *
Nam O Addr O Tel O
53
Cada uno de estos tres modelos del sistema proporciona un punto de vista del mismo sistema, y
cada punto de vista se requiere para formar un modelo completo del sistema que se está
diseñando.
Los proyectos desarrollados bajo SSADM se dividen en cinco (5) módulos:
Estudio de viabilidad: se analiza el área comercial para determinarse si un sistema puede contar
con la eficacia de los requisitos del negocio.
Análisis de requisitos: para ser convertido los requisitos del sistema es necesario que se
identifique y se modele el ambiente de negocio actual en los términos de procesos realizados y de
las estructuras de datos implicadas.
Especificación de requisitos: en este módulo se identifican los requisitos funcionales y no
funcionales detallados y las nuevas técnicas se introducen para definir las estructuras requeridas
del proceso y de los datos.
Especificación de sistema lógica: se producen las opciones técnicas de los sistemas y el diseño
lógico de los diálogos de la actualización, del proceso y del sistema de la investigación.
Diseño físico: un diseño de base de datos físico y un sistema de especificaciones del programa se
crean usando la especificación de sistema lógico y las especificaciones del sistema.
SSADM construye cada paso del proyecto prescrito en el paso anterior sin la desviación del
modelo.
Entidades
Externas
Entidades
Externas
Procesos
Procesos
Procesos
Almacenes
de Datos
Almacenes
de Datos
Entidades
Externas
Entidades
Externas
Procesos
Procesos
Procesos
Almacenes
de Datos
Almacenes
de Datos
Figura 2.23
Ejemplo de un DFD con el método SSADM
u
Fuente: Gacitúa (2003)
54
Método Gane y Sarson
Gane y Sarson (1978), cambiaron levemente la notación de los diagramas de flujo de datos que
popularizaron Yourdon y DeMarco. Fueron diseñados para el análisis y el diseño estructurado.
Demostración cómo los datos se mueven a partir de un proceso a otro, así como su almacenaje
lógico. En la siguiente Figura 2.24 se muestra un ejemplo de un DFD usando la notación de Gane
y Sarson.
Fuente: Gacitúa (2003)
Niveles de los DFD
El DFD se basa en descomposiciones llamadas niveles. El primer nivel es una representación
muy general. Aumentan los detalles en la medida en que se alcancen niveles más bajos
(subniveles) en la descomposición. Un sistema se modela mediante un conjunto de DFD
nivelados en el que los niveles superiores definen las funciones del sistema de forma general y
los niveles inferiores (niveles más bajos) definen las funciones de forma más detalladas.
Se comienza por el nivel más alto de la jerarquía mediante un DFD denominado “diagrama de
contexto”. En este diagrama sólo hay un proceso que representa el sistema completo. Este
proceso se descompone en otro DFD (que se denomina “diagrama de sistema”) en el que se
representa las funciones principales o subsistemas. Luego se descompone cada uno de los
Entidades
ExternasEntidades
Externas
Procesos
Procesos
Almacenes
de Datos
Almacenes
de Datos
Flujo de Datos
Entidades
ExternasEntidades
Externas
Procesos
Procesos
Almacenes
de Datos
Almacenes
de Datos
Flujo de Datos
Figura 2.24
Ejemplo de un DFD con el método Gane & Sarson
55
procesos en nuevos diagramas que representan funciones más simples. Se procede de la misma
manera hasta que todas las funciones estén lo suficientemente detalladas como para que no sea
necesaria la creación de nuevos DFD.
Por lo tanto un conjunto de DFD queda definido por:
Diagrama de Contexto, único y en la parte superior.
Niveles Medios (Diagrama de Sistema), formado por el resto de diagramas.
Funciones Primitivas, son las que están presentes tanto en los niveles intermedios como
en los últimos niveles de la jerarquía y que se corresponden con procesos que no explotan
en nuevos DFD.
Los diagramas de flujos deben ser trazados en forma sistemática, con la ayuda de la
programación top-down. Se comienza haciendo un diagrama muy general y luego se va bajando
por niveles y se va detallando cada vez más a medida que va bajando de nivel, es decir se toma
cada proceso y se produce el desarrollo, esto significa que el proceso se subdivide en sub-
procesos para llegar a un gráfico con más nivel de detalle. En la Figura 2.25 se puede observar de
manera grafica en enfoque de análisis estructurado clásico.
Fuente: DeMarco (1979)
En la Figura 2.26 se muestra un ejemplo de los distintos niveles que puede tener un DFD.
Figura 2.25
Enfoque de análisis estructurado clásico
Diagrama de
Contexto
Sin estrategia que asista
en el criterio de participación
DFD de Primer nivel
nivel o nivel 0
División top-down de
Cada proceso
Diagrama de
Contexto
Sin estrategia que asista
en el criterio de participación
DFD de Primer nivel
nivel o nivel 0
División top-down de
Cada proceso
56
Fuente: DeMarco (1979)
2.3 Diagrama de estructura de datos (DED)
Los diagramas de estructuras de datos (DED) son una notación gráfica que representa la
estructura de un conjunto de módulos de un programa, existe una relación jerárquica con cada
uno de los módulos. Estos diagramas no informan sobre el orden de ejecución de los módulos ni
el número de veces que se ejecuta. Debido a su notación suele parecerse a la representación de
los DFD, pero no son iguales.
En los diagrama de estructura de datos cada rectángulo representa un módulo, las flechas que
conectan los rectángulos representan invocaciones de módulos (por ejemplo llamado de sub-
rutinas). El diagrama también muestra parámetros de entrada que se le dan a cada módulo
invocado y parámetros de salida devueltos por cada módulo cuando termina su tarea y devuelve
el control al que lo llama.
Figura 2.26
Niveles de los DFD
57
Este diagrama es una herramienta excelente para los diseñadores de sistemas, pero no es el tipo
de modelo que normalmente se mostrará al usuario, pues modela un aspecto de la implantación
del sistema, no de sus requerimientos.
Los diagramas de estructura de datos sirven para el modelado top-down de la estructura de
control de un programa descrito a través de un árbol de invocación de módulos. Fueron
presentados en la década de los 70 como la principal herramienta utilizada en los diseños
estructurados, por autores como Constantine y Yourdon (1978). La Figura 2.27, muestra un
ejemplo:
Fuente: Martin y McClure (1985)
Un diagrama de estructura de datos permite modelar un programa como una jerarquía de módulos.
Cada nivel de la jerarquía representa una descomposición más detallada del módulo del nivel
superior. La notación usada se compone básicamente de tres símbolos: módulos, invocaciones y
cuplas.
Módulos
Para Yourdon y Constantine. (1978) un módulo es un conjunto de instrucciones que ejecutan
alguna actividad, desde un punto de vista práctico, un módulo es una colección de instrucciones
de un programa con cuatro características básicas:
Recibir
muestra
Comprobar
cliente
Alta
cliente
Alta
muestra
Comprobar
animal
Alta
animal
NumClienteNumCliente,
NumAnimal
NumAnimal
NumAnimalNumCliente
Recibir
muestra
Comprobar
cliente
Alta
cliente
Alta
muestra
Comprobar
animal
Alta
animal
NumClienteNumCliente,
NumAnimal
NumAnimal
NumAnimalNumCliente
Figura 2.27
Ejemplo de un diagrama de estructura de datos
58
1. Entradas y Salidas: lo que un módulo recibe en una invocación y lo que retorna como
resultado.
2. Función: las actividades que un módulo hace con la entrada para producir la salida.
3. Lógica Interna: por la cual se ejecuta la función.
4. Estado Interno: su área de datos privada, datos para los cuales sólo el módulo hace referencia.
Las entradas y salidas son, respectivamente, datos que un módulo necesita y produce. Una
función es la actividad que hace un módulo para producir la salida. Las Entradas, salidas y
funciones proveen una visión externa del módulo. La lógica interna son los algoritmos que
ejecutan una función, esto es, junto con su estado interno representan la visión interna del módulo.
Un módulo esta diseñado como una caja, su función es representada por un nombre en el interior
y las entradas y salidas de un módulo son representadas por pequeñas flechas que entran y salen
del módulo. Existen diferentes tipos de módulos: según el flujo de datos, su función y sus
conexiones.
• Según el flujo de datos:
– Aferentes (o de entrada): transfiere información desde los módulos inferiores a los
superiores.
– Eferentes (o de salida): transfiere información desde los módulos superiores a los
inferiores.
– De transformación: sirven para transformar datos a otro formato.
– Coordinación: manejan el flujo de datos entre sus sucesores, es decir, el flujo pasa
a través de él y se trasfiere de una rama a otra. Coordina y gestiona otros módulos
• Según su función:
– Ejecutivos: llaman a módulos subordinados y realizan las decisiones del sistema.
– Atómicos: realizan trabajos concretos.
• Según las conexiones:
– Mínimamente conectados: transmisión de datos y control a través de parámetros.
Un solo punto de entrada al módulo.
– Normalmente conectados: varios puntos de entrada (baja cohesión)
– Patológicamente conectados: transferencias de control al interior o datos globales.
59
Relaciones entre módulos
Los diagramas de estructura de datos muestran las invocaciones que un módulo hace a otros
módulos. Estas invocaciones son diseñadas como una flecha que sale del módulo llamador y
apunta al módulo llamado. La Figura 2.28, muestra un ejemplo:
Fuente: Yourdon y Constantine (1978)
En el ejemplo de la Figura 2.28 el módulo A invoca (o llama) a los módulos B, C y D. La
interpretación de las invocaciones provee información de la estructura interna del módulo
llamador. Los diagramas de estructura no tienen especificado el orden de invocación de los
módulos invocados. El orden de la figura de los módulos B, C, y D (de izquierda a derecha) no
debe ser interpretado como el orden de invocaciones ejecutado por el módulo A. Una invocación,
representa la idea de invocación a funciones o procedimientos en los lenguajes de programación
convencionales. En un diagrama de estructura de datos se pueden modelar varios tipos de
invocaciones, en el Cuadro 2.1 se explican y se representan gráficamente:
Cuadro 2.1
Tipos de invocaciones
Invocación
Estándar
El módulo A invoca al módulo B con la semántica de invocación
de procedimientos o funciones en los lenguajes de programación
convencionales (C, Pascal, etc.).
Invocación
Concurrente
El módulo A comienza dos tareas concurrentes, B y C.
Invocación
Co-rutina
El módulo A invoca al módulo B con una semántica de
transferencia de control al punto de entrada de una co-rutina.
A
B
A
B C
A
B C D
Modulo Llamador
Invocación
Modulo Llamado
A
B C D
Modulo Llamador
Invocación
Modulo Llamado
A BA B
Figura 2.28
Ejemplo de invocaciones
60
Transferencia
de Control
El módulo A hace una transferencia de control al interior del
módulo B.
Transferencia
de Datos
El módulo A hace referencia a un área de datos local del módulo B.
Fuente: Yourdon y Constantine (1978)
Comunicación entre módulos (cuplas)
Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, comúnmente
un conjunto de argumentos es comunicado y, en el caso de las funciones, también se espera que
retorne un resultado. Estos datos comunicados en una invocación son modelados por medio de
flechas, sobre el símbolo de invocación, llamadas cuplas, en la Figura 2.29 se muestra un ejemplo.
Como se muestra en el Cuadro 2.2, existen varios tipos de cuplas, basado en lo que ellas pueden
producir en el módulo receptor, las cuales se describen a continuación:
Cuadro 2.2
Tipos de cuplas
Cupla de
Datos
Una cupla de datos transporta datos “puros” a un módulo. No es necesario
conocer la lógica interna del módulo receptor, para determinar los valores
válidos de la cupla (ej.: número de cuenta, saldo, tabla de movimientos).
Cupla
Modificada
Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se
especifica un argumento enviado a un módulo que deberá modificar su valor,
fijando un nuevo valor disponible para el módulo llamador (en la
implementación, se precisará que el lenguaje posea un mecanismo de pasaje de
parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un
archivo).
B
A
B
A
A
B C D
Cúpula de Datos
Cúpula sin tipo
(o de datos o de
control o hibrida)
Z
X
YZ W
F
H
Cúpula Modificada
Cúpula de control
flag
Cúpula Hibrida
(datos y control)
A
B C D
Cúpula de Datos
Cúpula sin tipo
(o de datos o de
control o hibrida)
Z
X
YZ W
F
H
Cúpula Modificada
Cúpula de control
flag
Cúpula Hibrida
(datos y control)
Figura 2.29
Ejemplos de invocaciones con cuplas
Fuente: Yourdon y Constantine (1978)
61
Cupla de
Control
Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se
especifica un argumento enviado a un módulo que deberá modificar su valor,
fijando un nuevo valor disponible para el módulo llamador (en la
implementación, se precisará que el lenguaje posea un mecanismo de pasaje de
parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un
archivo).
Cupla
Híbrida
Una cupla que para algunos módulos transporta datos “puros” y para otros
transporta un flag de control es denominada cupla híbrida. Esta cupla
representa un híbrido entre una cupla de datos y una cupla de control. La
identificación de ellas depende de la lógica definida por el algoritmo de
implementación del módulo invocado.
Cupla sin
Tipo
Se utiliza para representar que hasta el momento no esta definida o se tienen
dudas con respecto a la interpretación que el módulo invocado hace de ella.
Fuente: Yourdon y Constantine, 1978
Estructura de control
Los diagramas de estructura también definen símbolos que posibilitan el modelamiento de
estructuras de control como repetición o alternativa:
Estructura condicional
Un rombo incluyendo una o más invocaciones especifica la ejecución condicional de ellas. En la
Figura 2.30 se muestra un ejemplo de esta estructura.
Puede que se llame a B o que no se
llame
Puede que se llame a alguno de entre B, C o D
Fuente: Martin y McClure (1985)
A
B
A
B C D
Figura 2.30
Estructura condicional
62
Estructura iterativa
Una flecha circular, abarcando un número de invocaciones, especifica que las invocaciones que
abarca son ejecutadas repetidamente. En la Figura 2.31 se muestra un ejemplo de esta estructura.
Puede llamarse a B varias veces
Puede llamarse a B, C y D varias veces
Fuente: Martin y McClure (1985)
2.4. Diagramas de transición de estados (DTE)
Según Yourdon (1989), el diagrama de transición de estado, también conocido como DTE
enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo
importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como ejemplo
de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas
de captura de datos de alta velocidad y sistemas de control y mando militares. Algunos de estos
sistemas son pasivos, en el sentido de que no buscan controlar el ambiente que los rodea, sino
más bien reaccionan a él o capturan datos que le atañen.
Para sistemas enfocados a los negocios no se veían demasiado importante, sin embargo en
sistemas grandes y complejos enfocados a negocios que si tienen aspectos de comportamiento de
tiempo real. Por ejemplo si el sistema maneja entradas de miles de terminales y entradas de alta
velocidad de otros sistemas, pueden entonces surgir aspectos de comportamiento dependientes
del tiempo, del tipo que surgen en un sistema típico de tiempo real. Por esto aunque no se
apliquen en todos los sistemas es conveniente estar familiarizado con herramientas de modelado
para el comportamiento dependiente del tiempo
A
B
A
B C D
Figura 2.31
Estructura iterativa
63
En la Figura 2.32 se muestra un DTE típico. Este diagrama muestra el comportamiento de una
máquina contestadora de teléfono normal. Los principales componentes del diagrama son estados,
y flechas que representan los cambios de estado.
Fuente: Yourdon (1989)
Notación de los diagramas de transición de estados
Existe una variada notación pero lo más común es representar a los estados mediante rectángulos
o mediante círculos, esta última forma puede llegar a parecerse con los DFD; por lo tanto es
mejor representarlos mediante rectángulos.
Estados del sistema
Cada rectángulo representa un estado en el que se puede encontrar el sistema. El New World
Díctíonary de Webster define un “estado” de la siguiente manera: “Un conjunto de circunstancias
o atributos que caracterizan a una persona o cosa en un tiempo dado; forma de ser; condición. Por
tanto, los estados típicos de un sistema pueden ser: esperar a que el usuario dé su contraseña,
calentar una mezcla de sustancias químicas, esperar la siguiente orden, acelerar el motor, mezclar
los ingredientes, esperar los datos del instrumento, llenar el tanque, aguardar en reposo, entre
otros.
Estos ejemplos implican que el sistema está esperando a que algo ocurra, no se expresan en
términos de que la computadora este haciendo algo porque el DTE se usa para desarrollar un
Figura 2.32
Ejemplo de un diagrama de transición de estados
EN REPOSO
ESPERANDO
UNA
LLAMADA
RESPONDIENDO
A LLAMADA
GRABANDO
MENSAJEREBOBINADO
DEJANDO EL
MENSAJE
EN REPOSO
ESPERANDO
UNA
LLAMADA
RESPONDIENDO
A LLAMADA
GRABANDO
MENSAJEREBOBINADO
DEJANDO EL
MENSAJE
64
modelo esencial del sistema, un modelo de cómo se comportaría el sistema si hubiera tecnología
perfecta; es decir, tecnología perfecta se entiende como que cualquier proceso, calculo o acción
que debiera hacer la computadora se hiciera en cero momentos. Así, cualquier estado observable
en el que el sistema se puede encontrar sólo puede corresponder a periodos en los que 1) está
esperando que algo ocurra en el ambiente externo o, 2) está esperando a que alguna actividad que
se esté dando en ese momento en el ambiente (como mezclar, lavar, llenar, acelerar, etc.) cambie
a otra. Un estado representa algún comportamiento del sistema que es observable y que perdura
durante algún periodo finito.
Cambios de estado
Para Yourdon (1989) los cambios de estados válidos en un DTE se muestran conectando pares
relevantes de estado con una flecha. Es muy común que cualquier estado pueda llevar a un
número arbitrario de estados sucesores. Así, la Figura 2.33 muestra que el sistema puede ir del
estado 1 al estado 2. También muestra que cuando el sistema se encuentra en el estado 2 puede ir
al estado 3 o regresar al 1.
Fuente: Yourdon (1989)
La mayoría de los sistemas tendrán un estado inicial reconocible y un estado final reconocible. El
estado inicial típicamente suele ser el que se dibuja en la parte superior del sistema, aunque no es
obligatorio; lo que realmente identifica al estado 1 en la Figura 2.34 Como inicial es la flecha que
no está conectada a ningún otro estado. De igual forma, el estado final suele dibujarse en la parte
inferior, pero tampoco es obligatorio; lo que realmente identifica al estado 5 como final es la
ausencia de una flecha que salga de él, por lo tanto una vez que se llega al estado 5 no se puede ir
a otra parte (Yourdon, 1989). Normalmente el sistema tendrá sólo un estado inicial, pero puede
tener múltiples estados finales como se puede observar en la Figura 2.35. Los estados finales son
Figura 2.33
Cambios de estado en un DTE
ESTADO 1
ESTADO 2
ESTADO 3
ESTADO 1
ESTADO 2
ESTADO 3
65
mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna
ejecución del sistema.
En la Figura 2.35 se muestra un diagrama de transición de estado con múltiples estados finales.
Fuente: Yourdon (1989)
Condiciones y acciones
Para completar el DTE necesitamos agregar dos cosas: las condiciones que causan un cambio de
estado y las acciones que el sistema toma cuando cambia de estado. Como se señala en la Figura
2.36, las condiciones y acciones se muestran junto a la flecha que conecta los dos estados
relacionados.
Figura 2.34
Estados inicial y final en DTE
Figura 2.35
Estados finales múltiples de N Sistemas
ESTADO 1
ESTADO 2
ESTADO 4 ESTADO 5ESTADO 6
ESTADO 3
ESTADO 1
ESTADO 2
ESTADO 4 ESTADO 5ESTADO 6
ESTADO 3
ESTADO 1
ESTADO 2
ESTADO 3
ESTADO 4
ESTADO 5
ESTADO 1
ESTADO 2
ESTADO 3
ESTADO 4
ESTADO 5
Fuente: Yourdon (1989)
66
Fuente: Yourdon (1989)
Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar;
típicamente es una señal, una interrupción o la llegada de un paquete de datos.
Esto usualmente hace que el sistema cambie de un estado de espera X a un estado de espera Y o,
de realizar una actividad X a realizar una actividad Y.
Como parte del cambio de estado el sistema con frecuencia hará una o más acciones. Por ejemplo
producirá una salida, realizará un cálculo, etc. Entonces, las acciones que se muestran en un DTE
son respuestas regresadas al ambiente externo o bien cálculos que el sistema recuerda para poder
responder a algún acontecimiento futuro.
Diagramas particionados
En un sistema complejo puede haber docenas de estados distintos de un sistema, tratar de
colocarlos todos en un solo diagrama es difícil. Por esto, como se usan niveles y particiones en
los DFD pueden usarse particiones en los DTE. La Figura 2.37 muestra un ejemplo de DTE para
un cajero automático.
Figura 2.36
Condiciones y acciones de un DTE
ESTADO 1
ESTADO 2
CONDICION
ACCION
ESTADO 1
ESTADO 2
CONDICION
ACCION
67
Fuente: Yourdon, (1989).
Cualquier estado individual de un diagrama de mayor nivel puede convertirse en un estado inicial
para un diagrama de un nivel inferior que describe más a fondo ese estado de mayor nivel; y el o
los estados finales en un diagrama de nivel inferior corresponden a las condiciones de salida en el
estado asociado de nivel superior.
Construcción del diagrama de transición de estados
Luego de ver la notación para los DTE, se puede observar dos enfoques que pueden aplicarse
para su construcción.
Puede comenzarse con la identificación de todos los posibles estados del sistema y
representar cada uno en una caja separada. Luego puede explorar todas las conexiones
con significado (cambios de estado) entre las cajas.
Figura 2.37
DTE particionado para un cajero automático
ENREPOSO
ESPERANDO
RESPUESTA
ESPERNADO
CONTRASEÑA
ESPERANDO
ELECCION
DESPLIEGA
ESTADO DE
CUENTA
DEPOSITA
FONDO
TRANFIERE
FONDODA EFECTIVO
Se presiono “inicio”
despliega mensaje de inserte tarjeta
tarjeta insertada
despliega “introducir contraseña”
Contraseña ingresada
despliega “selección de función”
“da efectivo” “transfiere fondos”
“se presiono reinicio”
Borrar pantalla
Se presiono reinicio
o contraseña errónea
“se presiono reinicio”
ENREPOSO
ESPERANDO
RESPUESTA
ESPERNADO
CONTRASEÑA
ESPERANDO
ELECCION
DESPLIEGA
ESTADO DE
CUENTA
DEPOSITA
FONDO
TRANFIERE
FONDODA EFECTIVO
Se presiono “inicio”
despliega mensaje de inserte tarjeta
tarjeta insertada
despliega “introducir contraseña”
Contraseña ingresada
despliega “selección de función”
“da efectivo” “transfiere fondos”
“se presiono reinicio”
Borrar pantalla
Se presiono reinicio
o contraseña errónea
“se presiono reinicio”
Esperando
Entrada
Dando
Efectivo
Esperando
El retiro
Del efectivo
Despliega “¿cuando desea?”
Cliente ingresa cantidad deseada
Efectivo disponible en cajero
Despliega “Favor esperar, dando efectivo”
Despliega “Favor retirar su efectivo”
Regresa al estado de ESPERANDO
ELECCIÓN en la figura superior
Esperando
Entrada
Dando
Efectivo
Esperando
El retiro
Del efectivo
Despliega “¿cuando desea?”
Cliente ingresa cantidad deseada
Efectivo disponible en cajero
Despliega “Favor esperar, dando efectivo”
Despliega “Favor retirar su efectivo”
Regresa al estado de ESPERANDO
ELECCIÓN en la figura superior
Fuente: Yourdon (1989)
68
Otra alternativa es comenzar por el estado inicial y luego metodológicamente ir siguiendo
un camino hasta el o los estados restantes; luego del o los estados secundarios; seguir con
los terciarios, etc.
El enfoque lo determinará, en la mayoría de los casos, el nivel de conocimiento del usuario que
colabora en la construcción del modelo de comportamiento dependiente del tiempo del sistema.
Relación del DTE con los demás componentes del modelo
El DTE puede usarse por si solo como herramienta de modelado; pero debería ser utilizado en
conjunto con otras herramientas.
Generalmente, el DTE representa una especificación de proceso para una burbuja de control en
un DFD. Esto se muestra en la Figura 2.38, las condiciones en un DTE corresponden a los flujos
de control entrantes en un DFD, y las acciones en el DTE corresponden a los flujos de control de
salida en el DFD. Como herramienta de modelado de alto nivel el DTE puede servir incluso
como especificación de proceso para todo el sistema. Si se representa todo el sistema con un
diagrama de contexto, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.
Fuente: Yourdon (1989)
2.5. Modelo relacional
El Modelo Relacional fue propuesto por Edgar Codd en 1970 (E. Codd era entonces un
investigador del Centro de IBM en San José - California y publicó su propuesta en un artículo
Figura 2.38
Relación entre un DFD y un DTE
ESTADO 1
ESTADO 2
Señal X
Activar burbuja 2
ESTADO 3
Señal Y
Activar burbuja 3
1
2 3
4
X
Y
ESTADO 1
ESTADO 2
Señal X
Activar burbuja 2
ESTADO 3
Señal Y
Activar burbuja 3
1
2 3
4
X
Y
69
fundamental que obtuvo el ACM Award correspondiente al Congreso VLDB de 1970,
proponiendo un nuevo modelo de datos que tenía como objetivo fundamental aislar al usuario de
las estructuras físicas de los datos, consiguiendo así la independencia de las aplicaciones
respecto de los datos.
Este objetivo fundamental es expresado explícitamente por Codd: "... se propone un modelo
relacional de datos como una base para proteger a los usuarios de sistemas de datos
formateados de los cambios que potencialmente pueden alterar la representación de los datos,
causados por el crecimiento del banco de datos y por los cambios en los caminos de acceso“.
Es un modelo lógico que se conoce como “esquema de la base de datos” (database schema) a
partir del cual se podrá realizar el modelado físico en el DBMS, es importante mencionar que es
un paso necesario, no se puede partir de un modelo conceptual para realizar un físico.
El modelo relacional se basa en la teoría matemática de las relaciones, los datos se estructuran
lógicamente en forma de relaciones, esta estructura lógica es muy parecida al concepto de tabla
que representa las relaciones entre los datos.
El trabajo de Codd en 1970 perseguía una serie de objetivos:
Independencia física: El modo cómo se almacenan los datos no debe influir en su manipulación
lógica y, por tanto, los usuarios que acceden a esos datos no han de modificar sus programas por
cambios en el almacenamiento físico.
Independencia lógica: Añadir, eliminar o modificar cualquier elemento de la BD no debe
repercutir en los programas y/o usuarios que están accediendo a subconjuntos parciales de los
mismos (vistas).
Flexibilidad: Ofrecer a cada usuario los datos de la forma más adecuada a la correspondiente
aplicación.
Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme (tablas), lo que
facilita la concepción y manipulación de la BD por parte de los usuarios.
Sencillez: Las características anteriores, así como unos lenguajes de usuario muy sencillos,
producen como resultado que el modelo relacional (MR) sea fácil de comprender y de utilizar por
parte del usuario final.
70
Evolución del modelo relacional
El Cuadro 2.3 hace una síntesis de la evolución del Modelo Relacional, desde su surgimiento a
fines de la década del sesenta hasta la actualidad.
Cuadro 2.3
Evolución del modelo relacional
Años Sucesos
1968-1970 Surge el Modelo Relacional (Codd). Aparece el concepto de
relación: tabla.
1970... Desarrollo teóricos: ej: álgebra relacional (Codd, 1972).
1973-1978 Prototipos (Ingres, Sistema R, etc.)
1979 Oracle
1981 SQL
1982 Sybase, Informix
1984 SQL/ANS
1986 SQL ISO
1990 Modelo Relacional versión 2 (RM/V2) Codd. Nulos
1992 SQL2 estándar.
1994 SQL3 Aun no estandarizado BDOO Fuente: Sánchez (2004)
Estructura del modelo relacional
Las estructuras de datos que se manejan en el modelo relacional corresponden a los conceptos de
relación, entidad, atributo, dominio y tupla (Dorantes, Magariños, Jury 2001).
Entidad: es una unidad de datos en una relación con un conjunto finito de atributos. Es también
conocido como n-ada, a raíz de que consiste de n-valores, uno por cada atributo (Dorantes,
Magariños, Jury 2001).
Relación: se entiende por relación una colección o grupo de objetos que tienen en común un
conjunto de características o atributos, es la estructura básica del modelo relacional. Es capaz de
recoger interrelaciones de cardinalidad múltiple (Dorantes, Magariños, Jury 2001).
Atributo: son las propiedades de la relación. Un atributo, necesariamente ha de definirse sobre un
dominio Se representan mediante columnas en las tablas. También llamado característica, cada
atributo de una relación tiene asociado un dominio en el cual toma sus valores (Dorantes,
Magariños, Jury 2001).
71
• Un atributo está siempre asociado a una relación, mientras que un dominio tiene existencia
propia con independencia de las relaciones que existan en el modelo.
• Un atributo representa una propiedad de una relación.
• Un atributo toma valores de un dominio.
• Varios atributos distintos (de la misma o de diferentes relaciones) pueden tomar sus valores
del mismo dominio.
Dominio:
Es el conjunto válido de valores de referencia para definir propiedades o atributos. Un dominio es
un conjunto nominado y homogéneo de valores. Cada dominio puede definirse de dos maneras:
Por extensión (enumeración de sus elementos):
días de la semana = {lunes, martes, miércoles, jueves, viernes, sábado, domingo}
Por intensión (mediante una propiedad que recoja el recorrido de sus valores
admisibles): edad: entero /. 0 ≤ edad ≤ 200.
Un dominio compuesto se puede definir como una combinación de dominios simples a la que se
puede aplicar ciertas restricciones.
Ej.: el dominio compuesto denominado Fecha se construye de los dominios simples Día, Mes y
Año, incorporando las restricciones a fin de que no aparezcan valores inválidos como: 29/2/2003,
31/4/2004.
Tupla: Es una ocurrencia o instancia dentro de una relación. Una tupla permite referenciar una
instancia de una entidad en el universo o la interrelación específica o concreta entre instancias de
entidades. Su representación es una fila. Una relación tiene un “conjunto” de tuplas. La relación
es el elemento fundamental del modelo relacional.
Clave
En el modelo relacional existen varios tipos de claves que funcionan como identificadores dentro
de las relaciones como las claves candidatas, las primarias, las alternativas y las foráneas.
Una clave candidata de una relación es un conjunto no vacío de atributos que identifican unívoca
y mínimamente cada tupla.
72
Clave primaria: es aquella clave candidata que el usuario elegirá, por consideraciones ajenas al
modelo relacional, para identificar las tuplas de la relación. El modelo relacional no incluye este
concepto de elegir una clave como primaria, cuando hay varias candidatas.
Clave alternativas: Son aquellas claves candidatas que no han sido escogidas como claves
primarias.
Clave ajena o foránea: de una relación R2 es un conjunto no vacío de atributos cuyos valores han
de coincidir con los valores de la clave primaria de una relación R1 (R1 y R2 no son
necesariamente distintas).
Grado: Se define como el número de atributos.
Cardinalidad: Se define como el número de tuplas de la relación.
En la Figura 2.39 se pueden observar los diferentes elementos que integra un modelo relacional
Fuente: Mercedes (2004)
Restricciones
Las restricciones son estructuras no permitidas. Hay dos tipos: inherentes y del usuario. Las
inherentes al modelo, tal como no tener tuplas repetidas y las del usuario que validan las
instancias de la relaciones.
Clave primariaClave primaria
Figura 2.39
Estructura de datos relacionales
73
Restricciones inherentes
Son aquellas que además de las derivadas por el concepto de relación, existe la llamada “regla de
integridad de entidad”, que serán explicadas más adelante. Esta restricción tiene como norma que
“ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo”
ya que nulo significa desconocido o inexistente. Esta restricción debería aplicarse a las claves
alternativas, pero el modelo no lo exige.
Restricciones de usuario
Se pueden definir como un predicado sobre un conjunto de atributos, de tuplas o de dominios,
que debe ser verificado para que constituya una ocurrencia válida del esquema.
Normalización
La normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar
un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede.
La normalización también se puede definir como "el proceso mediante el cual se transforman
datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más
simples y más estables, son más fáciles de mantener"
Grados de normalización
Existen varios niveles de normalización, sin embargo son tres los niveles básicos: Primera Forma
Normal (1FN), Segunda Forma Normal (2FN) y Tercera Forma Normal (3FN). Cada una de estas
formas tiene sus propias reglas. En el Cuadro 2.4 se muestran los grados de normalización.
Cuadro 2.4
Grados de normalización
Forma Normal Descripción
Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.
Segunda Forma Normal (2FN) Asegura que todas las columnas que no son llave sean
completamente dependientes de la llave primaria (PK).
Tercera Forma Normal (3FN) Elimina cualquier dependencia transitiva. Una
dependencia transitiva es aquella en la cual las
columnas que no son llave son dependientes de otras
columnas que tampoco son llave.
Forma Normal Boyce-Codd
(FNBC)
Una relación esta en FNBC si y solo si todas las
dependencias funcionales son completas y todos los
atributos determinantes son claves candidatas Fuente: Codd (1971)
74
Reglas de integridad
Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de
integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son
correctos.
Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de valores
permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de
dominios. Hay además dos reglas de integridad muy importantes que son restricciones que se
deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las
reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la
regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo.
Reglas de integridad: restricción que debe cumplirse sobre una BD en todos sus estados. Existen
dos reglas de integridad generales: de identidades y referenciales; y una específica que es de
negocios.
Regla de integridad de entidades (amiga de las claves primarias). Ningún atributo de una llave
primaria puede tener el valor nulo.(NULL).
La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de
los atributos que componen la clave primaria puede ser nulo.
Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de
modo único las tuplas. Que es irreducible significa que ningún subconjunto de la clave primaria
sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea
nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo
que se contradice la irreducibilidad.
Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias, no a las claves
alternativas.
Regla de integridad referencial (amiga de las claves ajenas). Debido a que las llaves foráneas
referencian llaves primarias, es esencial que el valor de una llave foránea coincida con el valor
de alguna llave primaria.
75
La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave
ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o
bien, deben ser completamente nulos.
La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo
que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en
un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal?
Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones
adicionales compensatorias que conduzcan a un estado legal.
Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas:
Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?
Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave
ajena?
o Restringir: no se permite borrar la tupla referenciada.
o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la
referencian mediante la clave ajena.
o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a
nulo la clave ajena (sólo si acepta nulos).
Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria
de la tupla referenciada por la clave ajena?
o Restringir: no se permite modificar el valor de la clave primaria de la tupla
referenciada.
o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se
propaga la modificación a las tuplas que la referencian mediante la clave ajena.
Reglas de negocio: reglas de integridad específica de cada base de datos
Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la base
de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de
negocio.
76
Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte
empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe
hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya
tiene los veinte permitidos.
Hoy en día aún existen SGBD relacionales que no permiten definir este tipo de restricciones ni
las hacen respetar.
Además existen las restricciones de dominios: al definir cada atributo sobre un dominio, se
impone una restricción sobre el conjunto de valores permitidos para cada atributo.
Dinámica relacional
La última parte del Modelo Relacional es su componente dinámica, que se divide en dos partes:
álgebra relacional y cálculo relacional.
El álgebra relacional se basa en un conjunto de operadores que operan sobre relaciones. El
cálculo relacional se basa en predicados que definen un estado objetivo de la base de datos, y
tenemos el cálculo relacional orientado a la tupla y el cálculo relacional orientado al dominio.
2.6 Diagramas de entidad-relación (DER)
Para Chen (1976): “El enfoque entidad-relación provee una metodología comprehensiva y fácil
de entender para un diseño lógico de la base de datos independiente del almacenamiento o
consideraciones de eficiencia”.
El diagrama de entidad-relación (también conocido como DER) es un modelo conceptual de red
que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.
Es muy diferente del DFD, que modela las funciones que lleva a cabo un sistema; y es diferente
del diagrama de transición de estados, que modela el comportamiento dependiente del tiempo de
un sistema.
También se le llama modelo E/R e incluso EI (Entidad / Interrelación). Sus siglas más populares
son las E/R por que sirven para el inglés y el español. Fue creado por Peter Chen en los años
77
1976 y 1977 a través de dos artículos. Se trata de un modelo que sirve para crear esquemas
conceptuales de bases de datos. De hecho es prácticamente un estándar para crear esta tarea. El
propósito de este modelo es simplificar el diseño de bases de datos a partir de descripciones
textuales de los requerimientos, es una técnica de representación grafica que incorpora
información relativa a los datos y a la relación existente entre ellos para darnos una visión del
mundo real.
Inicialmente en la propuesta de Chen (1976), sólo se incluían los conceptos de entidad, relación y
atributos. Después se añadieron otras propuestas (atributos compuestos, generalizaciones, etc.)
que forman el llamado modelo “entidad relación extendido” (se conoce con las siglas ERE).
El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la
realidad mediante un conjunto de representaciones gráficas y lingüísticas. Estos conceptos, se
representa por un conjunto de entidades que presentan ciertas propiedades llamadas atributos,
definidos sobre un cierto dominio de datos. Las entidades se vinculan mediante relaciones que, en
ciertas variantes de la notación, pueden también tener sus propios atributos.
Las características principales son
1.- Refleja únicamente la existencia de los datos no lo que hace con ellos.
2.- El modelo E-R no esta orientado a aplicaciones particulares.
3.- Es independiente de las bases de datos y de los sistemas operativos concretos.
4.- A la hora de su confección no debemos considerar aspectos como espacio,
almacenamiento, ni tiempo de ejecución.
5.- Debe estar abierto a la evolución del sistema de tal forma que admita las posibles
incorporaciones que se produzcan o las variaciones de algunos elementos existentes.
El modelo E-R va a consistir en un conjunto de objetos básicos denominados entidades, así como
las relaciones existentes entre ellos. Las entidades vendrán representadas mediante un rectángulo
y las relaciones mediante un rombo. En la Figura 2.40 se muestra un ejemplo de un modelo de
entidad relación.
78
Fuente: Yourdon (1989)
Componentes de un DER
Entidades
Según Peter Chen una entidad (objeto) es una “cosa” que puede ser identificada distintamente.
Una persona, una compañía, o un acontecimiento específico pueden ser ejemplo de una entidad.
Una relación es una asociación entre entidades. Por ejemplo, el "padre-hijo" es una relación entre
dos entidades.
Las entidades que poseen las mismas propiedades forman conjuntos de entidades. Ejemplos de
conjuntos de entidades son los conjuntos: personas, facturas, coches, etc., un ejemplo de esto se
puede observar en la Figura 2.41.
Fuente: Yourdon (1989)
Figura 2.41
Ejemplos de entidades y conjunto de entidades
Figura 2.40
Ejemplo de un modelo de entidad relación
Alumno Profesor
Asignatura
Tiene
ImparteMatriculado
Alumno Profesor
Asignatura
Tiene
ImparteMatriculado
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Entidades
Personas
Conjunto de
entidades
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Entidades
Personas
Conjunto de
entidades
79
En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como un conjunto
de entidades. De este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona
en concreto sería una ocurrencia o un ejemplar de la entidad persona.
En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro
del cual se escribe el nombre de la entidad, en la Figura 2.42 se muestra un ejemplo de la entidad
“persona”.
Fuente: Chen (1976)
Tipos de entidades
Fuerte o Regulares. Son las entidades normales que tienen existencia por sí mismas sin
depender de otras. Su representación gráfica es la indicada arriba.
Débiles. Su existencia depende de otras. Por ejemplo, en la Figura 2.43 la entidad “tareas
laborales” sólo podrá tener existencia si existe la entidad trabajo. Las entidades débiles se
representan de esta forma:
Fuente: Chen (1976)
Relaciones
Representan asociaciones entre entidades, puede haber más de una relación entre dos entidades.
Es el elemento del modelo que permite relacionar en sí los datos del modelo. Por ejemplo (Ver
Figura 2.44), en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se
realizan ya que las personas trabajan y los trabajos son realizados por personas.
PERSONA
Figura 2.42
Representación de la entidad: “persona”
Figura 2.43
Entidad débil
TAREAS LABORALES
80
Fuente: Yourdon (1989)
La representación gráfica de las relaciones se realiza con un rombo al que se le unen líneas que se
dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo de la
Figura 2.45 podría usarse como nombre de relación, trabajar.
Fuente: Chen (1976)
Grado de la relación
Número de entidades que pueden participar en una relación
Unitarias (misma entidad).
Binarias (2 entidades)
N-arias (N entidades)
Cardinalidad de las relaciones
La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están
relacionadas con cuántas entidades del conjunto del otro extremo. Estas pueden ser de “una a
Figura 2.44
Ejemplo de relación (a)
Figura 2.45
Ejemplo de relación (b)
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Fontanero
Electricista
Peluquero
Administrativo
Personas Trabajos
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Fontanero
Electricista
Peluquero
Administrativo
Personas Trabajos
Personas Trabajar TrabajosPersonas Trabajar Trabajos
Figura 2.44
Ejemplo de relación (a)
81
una” (1:1), de “una a muchas” (1:N), de “muchas a una” (N:1). y de “muchas a muchas” (N:N). Se
anota en términos de:
Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá
cada ejemplar de la entidad (el valor que se anota es de cero o uno)
Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer
cada ejemplar de la entidad (puede ser uno o muchos)
Roles en las relaciones
A veces en las líneas de la relación se indican roles. Los roles representan el papel que juega una
entidad en una determinada relación. En la Figura 2.46 se muestra un ejemplo de los roles en las
relaciones.
Fuente: Yourdon (1989)
Atributos
Las distintas propiedades o características de una entidad o de una relación, se denomina Atributo.
Los atributos toman valores de uno o varios dominios. Así, el conjunto de posibles valores que
puede tomar una cierta propiedad se denomina dominio para tal propiedad. Por ejemplo,
propiedades de Profesores pueden ser su nombre y apellido, DNI, domicilio, etc.; de Cursos,
pueden ser nombre del curso, duración, requisitos, etc. y los dominios serán aquellos conjuntos
de los cuales podemos obtener esos valores “Sr. Sánchez”, 25657789, etc.
Tipos de atributos
Existen cuatro tipos de atributos:
1. simples o compuestos: Los atributos simples no están divididos en subpartes, mientras
que los compuestos sí pueden dividirse en varios atributos. Por ejemplo el atributo
nombre_completo podría dividirse en tres atributos: nombre, apellido1 y apellido2.
La diferencia entre un atributo compuesto y uno simple es que en los compuestos se
Figura 2.46
Ejemplo de roles en las relaciones
Trabajador Trabaja
Empleado
Jefe
Trabajador Trabaja
Empleado
Jefe
82
puede referir a cada componente de forma separada. En general ayudan a hacer los
modelos más claros pues agrupan atributos relacionados.
2. monovalorados y multivalorados: Los atributos univalorados sólo pueden tener un
valor para una entidad concreta. Por ejemplo una persona sólo puede tener un número
de DNI, y un préstamo tiene un único número de identificación. Hay que destacar que
esto es diferente de tener un valor único y distinto del resto de las entidades; un
atributo univalorado simplemente indica que un atributo de una entidad sólo tendrá un
valor. Los atributos multivalorados por el contrario pueden tener un conjunto de
valores para una entidad específica. El teléfono de un cliente es un buen ejemplo de
atributo multivalorado, ya que un cliente puede tener varios números de teléfono (fijo,
móvil, móvil de la empresa, etc.).
3. nulos: Un valor nulo se usa cuando una entidad no tiene un valor para ese atributo, ya
sea porque no se necesita o bien porque su valor se desconoce en ese momento. Por
ejemplo una entidad trabajador con un atributo subordinado, en el caso de que una
persona no tenga a otras a su cargo el atributo subordinado será nulo.
4. derivados: El valor para este tipo de atributo se puede obtener de los valores de otros
atributos o entidades. Por ejemplo en un conjunto de entidades cliente, el atributo
total_de_préstamos puede obtenerse contando el número de entidades préstamo
asociadas a dicho cliente.
Clave
Una clave nos sirve para identificar una entidad de forma inequívoca, ya que la diferencia sólo
puede expresarse en términos de sus atributos. Una superclave es un conjunto de uno o más
atributos que tomados colectivamente permiten identificar de forma única una entidad en el
conjunto de entidades. Se trata de uno o más campos cuyos valores son únicos en cada ejemplar
de una entidad. Se indican subrayando el nombre del identificador.
Para que un atributo sea considerado un buen identificador tiene que cumplir:
1. Deben distinguir a cada ejemplar teniendo en cuenta las entidades que utiliza el modelo.
No tiene que ser un identificador absoluto.
2. Todos los ejemplares de una entidad deben tener el mismo identificador.
3. Cuando un atributo es importante aun cuando no tenga una entidad concreta asociada,
entonces se trata de una entidad y no de un atributo.
83
2.7 Otros métodos estructurados
2.7.1 Método de Warnier/Orr
Los diagramas de Warnier/Orr (también conocidos como construcción lógica de programas)
fueron desarrollados inicialmente en Francia por Jean Dominique Warnier y en los Estados
Unidos por Kenneth Orr (Martin & McClure, 1985). Este método ayuda al diseño de estructuras
de programas identificando la salida y resultado del procedimiento. Los sencillos métodos
gráficos usados en los diagramas de Warnier/Orr hacen evidentes los niveles en un sistema y más
claros los movimientos de los datos en dichos niveles.
Los diagramas de Warnier/Orr muestran los procesos y la secuencia en que se realizan, cada uno
de estos procesos se define de una manera jerárquica; es decir, consta de conjuntos de
subprocesos que lo definen, en cada nivel, el proceso se muestra en una llave que agrupa a sus
componentes. Puesto que un proceso puede tener muchos subprocesos distintos, un diagrama de
Warnier/Orr usa un conjunto de llaves para mostrar cada nivel del sistema.
En los diagramas Wranier/Orr se trabaja hacia atrás, es decir, se comienza con la salida del
sistema y usando un análisis orientado hacia la salida. En el papel el desarrollo se mueve de
izquierda a derecha. En primer lugar, se definen la salida o resultados esperados del
procedimiento. En el nivel siguiente, mostrado mediante la inclusión por medio de una llave, se
definen los pasos necesarios para producir la salida. A su vez, cada paso se define un poco más.
Las llaves adicionales agrupan los procesos requeridos para producir el resultado en el siguiente
nivel (Martin & McClure, 1985).
Los diagramas de Warnier/Orr ofrecen la ventaja de ser simples en apariencia y fáciles de
entender tienen además, la ventaja de mostrar agrupaciones de procesos y los datos que deben
transferirse de nivel a nivel. Además, la secuencia del trabajo hacia atrás garantiza que el sistema
estará orientado hacia el resultado.
La representación de un algoritmo se basa en los siguientes puntos:
84
Un programa se representa por un solo diagrama en el cual se hallan todas las operaciones.
Las operaciones se colocan secuencialmente a la derecha de una llave, en cuya parte
izquierda esta el nombre del proceso, en la parte superior de la llave se halla la palabra
INICIO, y en la parte inferior la palabra FIN.
Los sucesivos procesos se hacen en forma similar. Cada nivel de descomposición viene
definido por el conjunto de procesos que en él se ejecutan.
En la Figura 2.47 se muestra un ejemplo de la estructura de un programa de Warnier.
Fuente: Martin y McClure (1985).
Estructuras de control
Estructura secuencial: En esta estructura las acciones se sitúan a la derecha de la llave y desde
arriba hacia abajo. En la Figura 2.48 se muestra un ejemplo de esta estructura.
Estructura alternativa: En esta estructura se ejecutara una acción dependiendo de la condición.
Si la acción es nula se representa mediante un guión (-). En la Figura 2.48 se muestra un ejemplo
de esta estructura.
Fuente: Martin y McClure (1985)
Estructura repetitiva: Se hallan también las formas PARA, MIENTRAS QUE, HASTA QUE,
ITERAR. En la Figura 2.49 se muestra un ejemplo de estas estructuras.
A
B
C
Cond.SI
NO
A
BExpre.
=V1
=V2
=V3
=V4
A
B
C
D
Secuencial Alternativa
A
B
C
Cond.SI
NO
A
BExpre.
=V1
=V2
=V3
=V4
A
B
C
D
Expre.
=V1
=V2
=V3
=V4
AA
B
C
D
Secuencial Alternativa
Programa
uno
inicio
A
B
C
D
E
F
fin
Programa
uno
inicio
A
B
C
D
E
F
fin
Figura 2.47
Estructura de un programa - Warnier
Figura 2.48
Estructura secuencial y alternativa - Warnier
85
Fuente: Martin y McClure (1985)
2.7.3 Método de Jackson
En 1957 Michael A. Jackson. Describe el método de programación estructurada de Jackson (JSP-
Jackson Structured Programing), como método de diseño de programas con aplicación a la
mayoría de los lenguajes de programación.
La metodología de Jackson es un proceso sistemático para la realización de un programa,
utilizando la técnica del diseño descendente (top-down), cuyo producto final es el programa
escrito en el pseudocódigo propio del método, de tal forma que su codificaci6n posterior en
cualquier lenguaje de programaci6n es relativamente sencilla, bien manualmente o de forma
automática.
Jackson se ayuda con la implementación de módulos, siguiendo un orden jerárquico de acuerdo a
los diferentes niveles en que se encuentra. Cada módulo se convierte en un dato o en un conjunto
de datos.
Este método se basa en la estructura lógica de la programación modular. La representación de los
programas se realiza por medio de un árbol que se denomina diagrama arborescente de Jackson.
Un diagrama de Jackson consta de: definición detallada de los datos de entrada y salida
incluyendo los archivos lógicos utilizados y representación del algoritmo. En la Figura 2.50 se
muestra un ejemplo de la estructura de un programa de Jackson.
A
CA
condición
B
B
PARA
Vi,Vf(,in)
MQ
Condición
HQ
Condición
LOOP
A
CA
condición
B
B
PARA
Vi,Vf(,in)
MQ
Condición
HQ
Condición
LOOP
Figura 2.49
Estructuras repetitivas - Warnier
86
Fuente: Martin y McClure (1985)
Cada árbol se lee: nodo raíz, nodo izquierdo, nodo derecho hermano, nodo derecho hermano.
La representación del algoritmo se basa en los siguientes puntos:
todo programa (operaciones) se representa en un solo diagrama.
todo diagrama comienza con un rectángulo en cuyo interior se halla el nombre del
programa.
para tener una clara interpretación es necesario realizarlo de la forma más simétrica
posible.
Estructuras de control
Estructura secuencial: En esta estructura se realizan las acciones de izquierda a derecha. Los
módulos en un número determinado se ejecutan una sola vez, respetando un orden jerárquico
preestablecido. En la Figura 2.51 se muestra un ejemplo de esta estructura.
Fuente: Martin y McClure (1985)
Proceso
B C DA
Proceso
B C DA
P1
Y XX
Secuencial
P2
SI O
A
Alternativo
NO O
B
P1
Y XX
Secuencial
P2
SI O
A
Alternativo
NO O
B
Figura 2.50
Estructura de un programa - Jackson
Figura 2.51
Estructura secuencial y alternativa - Jackson
87
Estructura alternativa: Se ejecuta una acción entre varias, según la evaluación de una condición.
El proceso se indica por medio de la letra O.
Estructura repetitiva: Se repiten operaciones dependiendo de una condición. Los módulos son
ejecutados desde cero hasta n veces. Cuando existe un proceso repetitivo, se indica con un
asterisco (*). En la Figura 2.52 se muestra un ejemplo de esta estructura.
Fuente: Martin y McClure (1985)
2.7.3 Diagramas HIPO
HIPO es una abreviatura del nombre en inglés (Hierarchy-Input-Process-Output), en español,
Entrada-Proceso-Salida-Jerárquica, fueron desarrollados por IBM como esquemas de
representación para un desarrollo jerárquico de arriba abajo y como una ayuda de documentación
para productos comercializados. Los diagramas HIPO muestran lo que el sistema hace pero no
cómo lo hace. (Martin y McClure, 1985).
Este método fue creado con el propósito de ayudar a los diseñadores a no perder la pista de
alguna función dentro de un sistema grande, ésta es su principal ventaja con la que cuenta con
respecto a otras notaciones, ya que este método permite tener una vista panorámica de las
entradas, procesos y salidas de datos. Esto lo hace una herramienta útil para la documentación de
programas, además de que le puede facilitar al analista de un programa el recordar lo que hace el
sistema después de cierto tiempo.
Para
Proceso
A
Vc=Vi,V,i
*
Proceso
A
MQ cond.
*
Proceso
A
HQ cond.
*
Mientras Que Hasta QuePara
Proceso
A
Vc=Vi,V,i
*
Proceso
A
MQ cond.
*
Proceso
A
HQ cond.
*
Mientras Que Hasta Que
Figura 2.52
Estructuras repetitivas - Jackson
88
Sin embargo HIPO también cuenta con ciertas desventajas, una de ellas es que utilizan una gran
cantidad de papel para mostrar todo el diagrama de un sistema por lo que puede ocasionar que el
lector navegue entre hojas y se le dificulte el seguimiento del flujo de éste.
Existen tres clases de diagramas HIPO: tabla de contenido visual, los diagramas generales y los
detallados.
Los diagramas HIPO están conformados por tres (3) clases de diagramas: tabla de contenido, los
diagramas generales y los diagramas de detalles.
La tabla de contenido (Ver Figura 2.53).es el nivel superior del diagrama de HIPO. Es una
estructura en forma de árbol que muestra los componentes generales de un sistema. No ofrece
información de control ni describe los datos en el sistema.
Fuente: Martin y McClure (1985)
Figura 2.53
Tabla de contenido - HIPO
PROCESO
DE
SUBSCRIPCIÓN
OBTENER UN
ARTICULO
VALIDO
LEER UN
ARTICULO
VALIDAR UN
ARTICULO
PROCESAR UN
ARTICULO
VALIDO
PROCESAR
UNA NUEVA
SUBSCRIPCIÓN
PROCESAR
CANCELACION
PROCESAR
RENOVACION
ADICIONAR
UN RECORD CREAR UNA
FACTURA
CREAR UN
REDCORD DE
FACTURA
1.0
3.02.0
2.1 2.2
3.1.1 3.1.2
3.1
3.1.3
3.2 3.3
PROCESO
DE
SUBSCRIPCIÓN
OBTENER UN
ARTICULO
VALIDO
LEER UN
ARTICULO
VALIDAR UN
ARTICULO
PROCESAR UN
ARTICULO
VALIDO
PROCESAR
UNA NUEVA
SUBSCRIPCIÓN
PROCESAR
CANCELACION
PROCESAR
RENOVACION
ADICIONAR
UN RECORD CREAR UNA
FACTURA
CREAR UN
REDCORD DE
FACTURA
1.0
3.02.0
2.1 2.2
3.1.1 3.1.2
3.1
3.1.3
3.2 3.3
89
Los diagramas generales (Ver Figura 2.54) especifican los procesos de un sistema en forma
funcional; cada diagrama describe las entradas, los pasos de proceso y las salidas de los
componentes principales del sistema; un diagrama general puede indicar la localización de los
diagramas de detalles subordinados necesarios. El propósito es “proveer de un conocimiento
general de una función”.
Fuente: Martin y McClure (1985)
Los diagramas detallados (Ver Figura 2.55) proveen de la información necesaria para entender
cuales son las entradas, los procesos llevados a cabo y las salidas de un componente funcional.
(Martin y McClure, 1985).
SISTEMA DE SUBCRIPCIONES
Diagrama 1.0 SUBCRIPCIONES
ENTRADA PROCESO SALIDA
SUBCRIPCIONES
ARCHIVO DE CLIENTES
ARCIVO MAESTRO
ACTUALIZADO
FACTURAS/ RECLAMOS
Para todas las transacciones
de subscriciones:
1. Obtener un articulo valido
2. Si es una nueva subscrición
proceso una nueva
subscrición
3. Si es una renovación proceso
renovaciones
4. Si es una cancelación
proceso cancelaciones
SISTEMA DE SUBCRIPCIONES
Diagrama 1.0 SUBCRIPCIONES
ENTRADA PROCESO SALIDA
SUBCRIPCIONES
ARCHIVO DE CLIENTES
ARCIVO MAESTRO
ACTUALIZADO
FACTURAS/ RECLAMOS
Para todas las transacciones
de subscriciones:
1. Obtener un articulo valido
2. Si es una nueva subscrición
proceso una nueva
subscrición
3. Si es una renovación proceso
renovaciones
4. Si es una cancelación
proceso cancelaciones
Figura 2.54
Ejemplo de un diagrama general HIPO
90
Fuente: Martin y McClure (1985)
Ambos tipos de diagramas los generales y detallados se parecen en el formato utilizado. Este
consiste en tres cajas o rectángulos identificados de la siguiente forma: entrada, proceso y salida.
En los diagramas la parte identificada como entrada se encuentra a mano derecha y muestra los
datos ya sean documentos, tablas, arreglos, archivos y otros que son necesarios para el proceso.
En el centro se encuentra la porción del diagrama que se utiliza para los procesos donde se
describen la serie de pasos utilizados para transformar los datos. A la izquierda del diagrama se
encuentra la salida que muestra lo que produjo el proceso. Cada caja o rectángulo esta conectado
por flechas que muestra que insumo o producto esta asociado con cada proceso (Martin y
McClure, 1985).
1. Reset error flags
2. Validate name street, zip,
and payment
a . if errors,
set flags
a . if errors
set flags
NEW-SUB-IN
INPUT
NEW-NAME
NEW-STR
NEW-CITY
NEW-ST
NEW-ZIP
NEW-PMT
NEW-TERMS
VALID-TERMS
VALID TERMS TABLE
NEW-SUB-IN
PROCESS OUTPUT
Validate
indicators2.2.2.1Validate terms
Reference number referring to more
detailed HIPO diagram which
expands step 3
1. Reset error flags
2. Validate name street, zip,
and payment
a . if errors,
set flags
a . if errors
set flags
NEW-SUB-IN
INPUT
NEW-NAME
NEW-STR
NEW-CITY
NEW-ST
NEW-ZIP
NEW-PMT
NEW-TERMS
VALID-TERMS
VALID TERMS TABLE
NEW-SUB-IN
PROCESS OUTPUT
Validate
indicators2.2.2.1Validate terms
Reference number referring to more
detailed HIPO diagram which
expands step 3
Figura 2.55
Ejemplo de un diagrama detallado HIPO
Desarrollo
Orientado a Objetos
CAPITULO
Desarrollo Orientado a Objetos
En este capítulo se hará un estudio documental sobre el desarrollo orientado a objetos, pero antes
de comenzar hablar de esto hay que explicar un poco cómo se dio su origen, comenzando con una
breve reseña histórica.
En la década de 1980, los métodos de desarrollo estructurado demostraron no escalar lo suficiente
y dieron paso a un nuevo paradigma, el de la programación orientada a objetos. El auge de este
paradigma, donde procesos y datos son tratados de forma conjunta conformando unidades de
trabajo coherentes llamadas objetos, supuso un cambio tan radical que implicó la existencia de
una metodología propia. Al igual que ocurrió con el paradigma estructurado, fue la creación de
lenguajes de programación orientados a objetos lo que fomentó un cambio en la forma de diseñar
y analizar. Los métodos orientados a objetos se utilizan en proyectos con unas características muy
concretas, coexistiendo en la actualidad con las técnicas estructuradas.
Con el análisis orientado a objetos, la forma de modelar la realidad difiere del análisis
convencional, se modela el mundo en términos de tipos de objetos y lo que le ocurre a éstos, esto
implica también diseñar y construir sistemas de forma orientada a objetos.
Los modelos que se construyen en el análisis orientado a objetos (OO, de ahora en adelante)
reflejan la realidad de modo más natural que los del análisis tradicional de sistemas. Después de
todo, la realidad consta de objetos y eventos que cambian el estado de dichos objetos. Mediante
las técnicas OO, construimos software que modela más fielmente el mundo real. Cuando el
mundo real cambia, nuestro software es más fácil de cambiar, lo que es una ventaja real.
93
3.1. Conceptos básicos del desarrollo OO
Se hará mención a los conceptos generales más utilizados en el modelo orientado a objetos, los
cuales son: abstracción, encapsulación y modularidad. Y con respecto a programación, son:
objeto, clase, método, envío y recepción de mensajes, herencia y polimorfismo.
Abstracción
Abstracción consiste en aislar un elemento de su contexto o del resto de los elementos que lo
acompañan. En programación, el término se refiere al énfasis en el "¿qué hace?" más que en el
"¿cómo lo hace?". Para Murillo (2002) es una descripción o especificación simplificada de un
sistema que hace énfasis en algunos detalles significativos y suprime los irrelevantes. La
abstracción se puede definir como la capacidad de examinar algo sin preocuparse de los detalles
internos.
El común denominador en la evolución de los lenguajes de programación, desde los clásicos o
imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del que cada uno de
ellos hace uso. La abstracción encarada desde el punto de vista de la programación orientada a
objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los
demás. Por ello, en OO lo más importante es que la abstracción debe enfocarse más en lo qué es
un objeto y lo qué hace, antes de pensar en la implementación. Por ejemplo, un automóvil puede
abstraerse como un objeto que sirve para desplazarse a mayor velocidad, sin importar cómo lo
haga.
Encapsulamiento
La información acerca de un objeto está encapsulada por su comportamiento. Esto significa que
un objeto mantiene datos acerca de cosas del mundo real a las que representa en su sentido
verdadero. Típicamente a un objeto se le debe “pedir” o “decir” que cambie sus propios datos con
un mensaje, en vez de esperar que tales datos de procesos extremos cambien la naturaleza de un
objeto (Murillo, 2002).
La encapsulación separa las características esenciales de las no esenciales dentro de un objeto. Al
encapsular u ocultar información, se separan los aspectos externos de un objeto (los accesibles
94
para todos) de los detalles de implementación (los accesibles para nadie). Con esto se trata de
lograr que al tener algún cambio en la implementación de un objeto no se tengan que modificar
los programas que utilizan tal objeto (Murillo, 2002).
Modularidad
La modularidad según Murillo (2002) consiste en dividir un programa en partes llamadas
módulos, los cuales pueden trabajarse por separado. En términos de programación, los módulos
pueden compilarse por separado y la división no depende de cierto número de líneas sino es una
división en términos de integrar en un módulo un conjunto de procedimientos relacionados entre
sí, junto con los datos que son manipulados por tales procedimientos. El objetivo de la
modularidad es reducir el costo de elaboración de programas al poder dividir el trabajo entre
varios programadores.
Objeto
Según Murillo (2002) un objeto es un elemento real o abstracto que tiene un estado, un
comportamiento y una identidad. Es un elemento independiente de un programa de
computadora, que representa un grupo asociado de características y está diseñado para realizar
tareas específicas. También se les conoce como instancias. Dicho en otras palabras es algo que es
identificable. Por ejemplo una silla, un libro o un lápiz.
Estado: el estado viene determinado por el conjunto de propiedades o atributos
que tiene el objeto junto con los valores que pueden asumir cada uno de esos
atributos. El hecho de que un objeto tenga un estado implica que ocupa un espacio,
exista durante un tiempo, cambie el valor de sus atributos, y sea creado o destruido
(Murillo,2002).
El comportamiento de un objeto viene determinado por la forma de actuar al
recibir un mensaje para que realice una acción. Un mensaje es una orden que se
manda a un objeto para que realice una operación con un propósito específico;
viene definido por tres componentes: el objeto receptor del mensaje, el selector del
mensaje, que es la acción que se quiere que realice el objeto y los argumentos, que
son los valores que se transmiten con el selector y que, en muchos casos, pueden
ser nulos (Murillo, 2002).
95
La identidad de un objeto es la propiedad característica que tiene ese objeto que
le distingue de todos los demás (Murillo, 2002).
Clase
Las clases son aquellas que permite crear objetos de la misma estructura y comportamiento. Las
clases igual que los objetos que salen de ellos están formadas por dos partes:
Una la constituyen las variables de la clase. Estas variables son los elementos que
definen los atributos de los objetos.
La otra parte son los métodos de la clase que van a ser los servicios que
proporcionan los objetos.
Herencia
Cuando se crean objetos derivados de otros, éstos heredan los atributos y los servicios de sus
clases base. Esta herencia puede ser sencilla o múltiple, en el primer caso, cada subclase tiene una
única superclase de la que es derivada. Mientras que en la herencia múltiple, una clase hereda a la
vez de varias superclases. Mediante la herencia se puede reutilizar el código.
Polimorfismo
El polimorfismo es capacidad de tener métodos con el mismo nombre pero que su
implementación sea diferente. En la vida diaria se presenta el siguiente ejemplo de polimorfismo:
al tratar de frenar un vehículo siempre se debe oprimir el pedal del lado izquierdo y el vehículo se
detendrá sin importar si los frenos son de tambor o de disco.
3.1.1. Estructura conceptual de un objeto
Un objeto puede considerarse como una especie de cápsula dividida en tres partes: (1) relaciones,
(2) propiedades y (3) métodos. Cada uno de estos componentes desempeña un papel totalmente
independiente:
96
Las relaciones como se observan en la Figura 3.1 permiten que el objeto se inserte en la
organización y están formadas esencialmente por punteros a otros objetos. Las relaciones pueden
ser de tipo: asociativas, de agregación y especialización.
Fuente: Díaz (2007)
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma
organización y tienen valores que dependen de la propiedad de que se trate. Las propiedades de
un objeto pueden ser heredadas a sus descendientes en la organización. En la Figura 3.2 las
propiedades de directivos son: nombre, edad, categoría y sueldo bruto.
Fuente: Díaz (2007)
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán
incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también
pone a disposición de sus descendientes a través de la herencia. Los métodos aplicados a
empleado en la Figura 3.3 son “mostrarDatos y “calcularSalario”
Figura 3.2
Ejemplo de propiedades de un objeto
Figura 3.1
Ejemplo de una relación de objetos
97
Fuente: Díaz (2007)
3.2. Métodos de análisis orientados a objetos (AOO)
Los métodos OO suelen, según muchos autores hacer la distinción entre análisis y diseño, pero,
pese a lo que anuncien sus autores o aún su mismo nombre, la distinción entre análisis y diseño se
difumina ya que esto depende de las necesidades del software que se este modelando, muchas
veces se mezclan estos métodos, pero sin embargo en esta investigación se estudian de forma
separada el análisis del diseño según sus creadores.
3.2.1. Método OOSA de Shlaer/Mellor
El primer paso del método de Shaler y Mellor (1988) es la definición de objetos y de sus
atributos. La notación de modelado de entidades desciende de la notación de Ward/Mellor. Este
método se puede clasificar como trilateral, y se desarrolla creando un modelo de información (o
de datos) que muestran los objetos, atributos y relaciones. Este método recibe un apoyo parcial de
la herramienta CASE, llamada teamwork. Es un método utilizado para diseñar sistemas de tiempo
real.
3.2.2. Método Coad /Yourdon
Coad y Yourdon publicaron libros prácticos y razonablemente completos en OOAD (Análisis
Orientado a Objetos y Diseño Orientado a Objeto, Prentice-Hall, 1990 y 1991, respectivamente).
Su metodología se centra en el análisis de los problemas de negocio, y utiliza una notación más
amistosa que el de Booch, Shlaer y Mellor, o los otros autores que se centran más en diseño.
Figura 3.3
Ejemplo de los métodos en un objeto
98
Existe una aproximación que surgió de Yourdon y se debe mucho a la tradición de modelado de
entidades y relaciones, esta aproximación se resume en Coad/Yourdon y resultó especialmente
interesante al ser la primera descripción ampliamente difundida de un método de análisis y una
notación de apoyo razonablemente completo, práctico, orientado a objetos y adecuados para
proyectos comerciales. Coad/Yourdon presenta una notación menos torpe que la que se encuentra
en Booch, Shlaer/Mellor o en la mayoría de las aproximaciones de diseño orientado a objetos.
Una de las características más notables de las notaciones de Shlaer/Mellor y Coad/Yourdon es
que los atributos resultan completamente explícitos. Coad/Yourdon (1991), sugiere que el análisis
se produce en cinco fases a las que dan los nombres siguientes:
Temas: estos son similares a los niveles del diagrama del flujo de datos y deben contener
cinco a nueve objetos aproximadamente.
Objetos: se identifican los objetos con detalle.
Estructuras: se identifican dos estructuras completamente distintas.
Estructuras de clasificación: corresponden a la relación de la herencia entre las
clases.
Estructuras de composición: definen los otros tipos de relaciones entre las clases.
Atributos: los atributos son detallados y se especifican las relaciones de modalidad y de
multiplicidad.
Servicios: esta es la palabra que emplea Coad Yourdon para las operaciones.
En diseño, estas cinco actividades se suplantan y se refinan en cuatro componentes:
Componente del dominio del problema: son las clases que se ocupan del dominio del
problema; por ejemplo, clases de cliente y clases de la orden
Componente humano de la interacción: clases de usuario-interfaz tales como las clases de
una ventana.
Componente de la gerencia de tarea: clases de la gestión de sistema tales como clases de
error y clases de seguridad.
Componente de la gerencia de datos: clases del método de acceso de base de datos y
similares Aunque la metodología de Coad y de Yourdon es quizás una de las
99
metodologías más fáciles de aprender del método OO y debido a su simplicidad no
conveniente aplicarla a proyectos grandes.
3.2.3. Método OMT de Rumbaugh
La metodología OMT (Object Modeling Technique/Técnica de Modelado de Objetos) fue creada
por James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy y William Lorensen
en 1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric.
Esta metodología fue creada como método para desarrollar sistemas orientados a objeto y para
apoyar la programación orientada al objeto.
OMT es considerado ampliamente como uno de los sistemas de análisis orientados a objetos más
completos que se han publicado hasta el momento. OMT describe el análisis y diseño orientado a
objetos como una forma de organizar software dentro de una correlación de objetos discretos que
incorporan tanto comportamiento como estructuras de datos. La esencia del desarrollo orientado a
objetos en OMT es la identificación y organización de conceptos en el dominio del problema.
En su libro de Modelación y Diseño Orientado a Objetos, Rumbaugh señala con respecto a su
metodología OMT que: “La metodología consiste en construir un modelo de un dominio de
aplicación añadiéndosele detalles de implementación durante el diseño del sistema. Esta
aproximación se denomina Técnica de Modelado de Objetos (OMT) y consta de las siguientes
fases: Análisis, Diseño de Sistema, Diseño de Objetos e Implementación” (Rumbaugh, 1991).
El análisis presupone que existe una especificación de los requisitos y se desarrolla construyendo
tres modelos distintos mediante el uso de tres notaciones diferentes: modelo objeto, modelo
dinámico y modelo funcional. Cada modelo describe un aspecto del sistema pero contiene
referencias a los demás modelos. Lo cual indica que los tres no son totalmente independientes.
El diseño de sistemas se realiza organizando los objetos en subsistemas identificando la
concurrencia a partir del modelo dinámico (DM), asignando subsistemas a procesadores o tareas,
diciendo si los datos deben o no estar almacenados en archivos, en memoria o en un sistema de
administración de base de datos, diciendo el uso de periféricos, y recursos globales. El diseño de
objetos implica transformar la información del DM y del modelo funcional (FM) en operaciones
100
de modelo objeto (OM). En la fase de implementación se codifica lo ya diseñado. En la Figura
3.4 se puede observar el ciclo de vida o la metodología que utiliza OMT para desarrollar software.
Fuente: Rumbaugh (1991)
Fase de análisis
Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en
términos de objetos y de relaciones entre ellos, flujo dinámico de control y las transformaciones
funcionales.
Los pasos a seguir en el análisis son:
1. Obtener y escribir una descripción inicial del problema: se concentra en entender el
problema, se construye un modelo de la situación del mundo real que muestra las
propiedades más importantes. Dicho analista debe trabajar con quien hace la solicitud
para comprender el problema porque las definiciones del mismo no suelen ser completas
ni correctas. El modelo de análisis es una abstracción resumida y precisa de lo qué debe
hacer el sistema deseado y no de la forma (el cómo) en que se hará. Los objetos del
Figura 3.4
Ciclo de vida de OMT
Descripción del problema
Modelo del objeto
Modelo dinámico
Modelo funcional
Diseño de sistema
Diseño de objetos
Implementación
Análisis de Objetos
Diseño
Descripción del problema
Modelo del objeto
Modelo dinámico
Modelo funcional
Diseño de sistema
Diseño de objetos
Implementación
Análisis de Objetos
Diseño
101
modelo deberán ser conceptos del dominio de la aplicación y no conceptos de
implementación de la computadora tales como estructuras de datos. Un buen modelo
podrá ser comprendido y criticado por expertos de la aplicación que no sean
programadores (Rossi, Britos y García, 1998).
2. Construir un modelo de objeto y sus relaciones
Describe la estructura estática (de datos), de los objetos del sistema (identidad, atributos y
operaciones) y también sus relaciones. El modelo de objetos contiene diagramas de objetos. Un
diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones
entre las clases. El diagrama contiene clases de objetos organizados en jerarquías que
comparten una estructura y comportamiento comunes y que están asociadas a otras clases. Estas
clases definen los atributos que lleva cada instancia de objeto y las operaciones que efectúe o
sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos (Rossi et
al, 1998).
Para Rossi (1998) los pasos que se llevan a cabo para el modelo de objetos son:
Identificar las clases (y objetos): se seleccionan los sustantivos de la descripción del
problema como posibles clases candidatas y se construye una lista. Se eliminan las clases
redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de
implementación.
Las clases se representan (Ver Figura 3.5) por rectángulos con tres compartimientos, en el
primero se pone el nombre de la clase, en el segundo los atributos y en el tercero las
operaciones o métodos.
Fuente: Oktaba (1999)
Figura 3.5
Ejemplo de representación de una clase
Juez
Nombre
DaCalif()
Juez
Nombre
DaCalif()
102
Preparar un diccionario de datos que contengan descripciones de las clases, sus atributos y
sus asociaciones: es muy importante definir que se entiende con mayor detalle por cada
clase que quedó en la lista anterior.
Añadir las asociaciones y agregaciones entre las clases (y objetos): una asociación es una
dependencia entre dos o más clases, en la Figura 3.6 se muestra un ejemplo. Las
asociaciones, se representan por líneas que unen a las clases sobre las cuales se puede
escribir el nombre de la asociación.
Fuente: Oktaba (1999)
A estos diagramas se les agrega la multiplicidad correcta. Puede ser “uno a uno”; “uno a muchos”
representada por una bolita rellena del lado de los “muchos”; o “muchos a muchos” representada
por bolitas rellenas a ambos extremos de la línea (Rossi et al, 1998).
También se puede representar la relación “es parte de” o agregación que indica que el objeto está
compuesto por objetos de las clases asociadas, un ejemplo sencillo es el que se muestra en la
Figura 3.7. Se denota un pequeño diamante del lado de la clase que agrega y puede incluir
multiplicidades (Rossi et al, 1998).
Figura 3.6
Ejemplo de asociaciones
Concursante
Nombre
Edad
Equipo
CalifEvento
Promedio Eventos
Equipo
Nombre
Categoría
Concursante
Nombre
Edad
Equipo
CalifEvento
Promedio Eventos
Equipo
Nombre
Categoría
103
Fuente: Oktaba (1999)
El documento que genera el modelo de objetos es el siguiente:
3. Se desarrolla el modelo dinámico
Describe los aspectos de comportamiento (de control) de un sistema que cambian con el
tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos del control
del sistema. Los modelos dinámicos contienen diagramas de estados. Un diagrama de estados
es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por
sucesos o eventos (Rossi et al, 1998).
Se especifican en este modelo la temporización y secuencia de operaciones (sucesos que
marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos),
y la organización de sucesos y de estados. El modelo dinámico captura el control, aquel
aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en
cuanta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estén
implementadas. Las acciones de los diagramas de estado se corresponden con funciones
Modelo de objetos = diagrama del modelo de objetos + diccionario de datos
Figura 3.7
Ejemplo de una agregación
Estación
Nombre
Ubicación
Juez
Nombre
Da Calif()
Estación
Nombre
Ubicación
Juez
Nombre
Da Calif()
104
procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser
operaciones que se aplican a objetos dentro del modelo de objetos (Rossi et al, 1998).
Los pasos que se siguen en el modelo dinámico son:
Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y el
sistema.
Identificar los eventos que se dan entre objetos y preparar una traza de eventos para cada
escenario.
Construir los diagramas de estados: El estado de un objeto es un conjunto de valores
para sus atributos, en un cierto momento, el cual cambia al recibir un estímulo llamado
evento. Un diagrama de estados es una gráfica de estados representados por círculos y
eventos representados por flechas.
Chequear la consistencia de los eventos que aparecen en los diagramas.
El documento que genera el modelo dinámico es:
4. Se construye el modelo funcional
Describe las transformaciones (de función), de valores de datos que ocurren dentro del sistema,
captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se
haga. El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es
un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias
entre los valores y el cálculo de valores de salida a partir de los de entrada y de funciones, sin
considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se
invocan como acciones en el modelo dinámico y se muestran como operaciones que afectan a
objetos en el modelo de objetos (Rossi et al, 1998).
Para Rossi (1998) los pasos que se llevan a cabo para el modelo funcional son:
Se identifican los valores de entrada y salida
Modelo dinámico = diagramas de estados + diagrama global de trazado de eventos
105
Se utilizan diagramas de flujo de datos para mostrar las dependencias funcionales.
Describir qué hace cada función
Se identifican las restricciones
Se especifica los criterios de optimización
El documento que genera el modelo funcional es:
5. Se verifican, iteran y refinan los tres modelos
Para Rossi (1998) los pasos que se deben seguir para verificar, iterar y refinar son los
siguientes:
Añadir las operaciones claves que fueron descubiertas durante la preparación del modelo
funcional al modelo objeto. No mostrar todas las operaciones durante el análisis, sólo
mostrar las más importantes.
Verificar que las clases, asociaciones, atributos y operaciones son consistentes y
completas al nivel elegido de abstracción. Compara los tres modelos con la definición del
problema y probar los modelos mediante el uso de escenarios.
Desarrollar escenarios más detallados (incluyendo condiciones que den errores) como
variaciones de los escenarios básicos. Usar estos escenarios para verificar en el futuro los
tres modelos.
Iterar los pasos anteriores cuanto sea necesario para completar el análisis.
El documento que genera el análisis contiene:
Diseño del sistema
Se define la arquitectura del sistema y se toman las decisiones estratégicas. Durante el diseño, el
sistema de destino se organiza en subsistemas basados tanto en la estructura del análisis como en
la arquitectura propuesta. El diseñador de sistemas deberá decidir qué características de
Documento de análisis = definición del problema + modelo de objetos + modelo
dinámico + modelo funcional.
Modelo funcional = diagramas de flujo de datos + restricciones
106
rendimiento hay que optimizar. Seleccionando una estrategia para atacar el problema y
efectuando las reservas de recursos tentativas (Rossi et al, 1998).
Según Rossi (1998) los pasos que se llevan acabo son:
1. Se organiza el sistema en subsistemas.
2. Se identifica la concurrencia inherente en el problema.
3. Se asignan los subsistemas a procesadores y a tareas.
4. Se selecciona la estrategia para implementar y administrar los almacenes de datos
(archivos o bases de datos).
5. Selección de la implementación del control del software.
6. Se consideran las condiciones de límite o contorno.
7. Se establecen las prioridades.
El documento que nos proporciona el diseño del sistema es:
Diseño de objetos
Su objetivo es refinar el modelo del análisis y proporcionar una base detallada para la
implementación tomando en cuenta el ambiente en que se implementará. El diseñador añade
detalles al modelo de acuerdo con la estrategia establecida durante el diseño del sistema. El foco
de atención del diseño de objetos son las estructuras de datos y los algoritmos necesarios para
implementar cada una de las clases. Las clases de objetos procedentes del análisis siguen siendo
significativas pero se aumentan con estructuras de datos y algoritmos del dominio de la
computadora seleccionados para optimizar medidas importantes de rendimiento (Rossi et al,
1998).
Para Rossi (1998) los pasos que se realizan en el diseño de objetos son los siguientes:
Documento de diseño del sistema = estructura de la arquitectura básica del sistema +
decisiones estratégicas de alto nivel.
107
1. Se refinan las operaciones para el modelo de objetos a partir de los demás modelos:
2. Se diseñan algoritmos para implementar las operaciones y las estructuras de datos
3. Se optimizan las vías de acceso a los datos.
4. Se implementa el control del software completando la aproximación propuesta en el
diseño del sistema.
5. Se ajusta la estructura de clases incrementando la herencia.
6. Se diseña la implementación de las asociaciones.
7. Se determina la representación exacta de los atributos de los objetos.
8. Se empaquetan las clases y las asociaciones en módulos.
El documento que se genera el diseño de objetos es:
Implementación
Las clases de objetos y las relaciones desarrolladas durante su diseño se traducen finalmente a un
lenguaje de programación concreto, a una base de datos o a una implementación en hardware. La
programación debería ser una parte relativamente pequeña del ciclo de desarrollo y
fundamentalmente mecánica porque todas las decisiones importantes deberán hacerse durante el
diseño. El lenguaje de destino influye en cierta medida sobre las decisiones de diseño pero éste
no debería depender de la estructura final de un lenguaje de programación. Durante la
implementación es importante respetar las ideas de la ingeniería del software, de tal manera que
el seguimiento hasta el diseño sea sencillo y de tal forma que el sistema implementado siga
siendo flexible y extensible (Rossi et al, 1998).
Es posible aplicar conceptos orientados a objetos a lo largo del todo el ciclo de vida de desarrollo
del sistema, desde el análisis hasta la implementación pasando por el diseño. Se pueden traspasar
las mismas clases de una etapa a otra sin modificar la notación aunque ganarán detalles
adicionales de implementación en las etapas posteriores. Siendo el punto de vista de análisis y el
de implementación de ‘‘Ventana’’ correctos tienen propósitos distintos y representan grados de
Documento de diseño de objetos = modelo de objetos detallado + modelo dinámico
detallado + modelo funcional detallado.
108
abstracción. Los mismos conceptos orientados a objetos de identidad, clasificación, polimorfismo
y herencia son aplicables a todo el ciclo de desarrollo completo.
Algunas clases no forman parte del análisis sino que se presentan como parte del diseño o de la
implementación. Por ejemplo, las estructuras de datos tales como árboles, tablas de dispersión y
listas enlazadas no suelen estar presentes en el mundo real. Se presentan para que presten su
apoyo a algoritmos concretos durante el diseño. Estos objetos de estructuras de datos se utilizan
para implementar objetos del mundo real dentro de la computadora y no derivan directamente sus
propiedades del mundo real.
OMT 22
En 1994 una revisión de OMT apareció con la introducción formal de los casos de uso. OMT2
declara que los casos de uso están limitados a la etapa de análisis de OMT. Esto requiere una
extensión sobre que está definido en OMT añadiendo 2 nuevos modelos a la etapa de análisis:
Modelo de dominio. Este modelo es creado explorando el dominio general y
adquiriendo conocimiento de las tareas que serán efectuadas.
Modelo de aplicación. Este modelo es construido sobre el modelo de dominio
examinando los casos de uso del dominio.
En esta revisión, los casos de uso son un método para examinar las interacciones de los actores
del sistema desde el punto de vista de un usuario.
Además OMT 2 introduce cambios en el modelo de objetos para hacerlo compatible con UML.:
Notación de objetos: Objeto como un rectángulo con la siguiente sintaxis
nombreObjeto : nombreClase
Multiplicidad: La multiplicidad muchos añade información al símbolo de círculo relleno,
incorporando información textual adicional
Atributos de la relación: Un atributo de la relación es un caso particular de la clase
asociación.
2 OMT 2 está publicado en las páginas blancas de www.rational.com
109
Clase asociación: La notación es ahora una línea discontinua que une la clase asociación
con la asociación.
Generalización: La representación aquí es una flecha cuyo extremo “toca” la clase más
+genérica. Puede organizarse en árbol.
Símbolo de cruce: Se introduce para evitar ambigüedades.
3.2.4 Método de Wirfs-Brock - Designing object oriented software (DOOS)
El Método de Wirfs-Brock (1990), cubre principalmente la fase de análisis del ciclo de vida del
desarrollo de los sistemas, pero no hace una distinción clara entre el análisis y el diseño. Dos
conceptos importantes, abstracción y encapsulación, se utilizan para manejar la complejidad del
mundo real. La metodología de DOOS describe el dominio del problema como sistema de objetos
de colaboración. Un sistema se desarrolla en dos fases. Durante los objetos exploratorios iniciales
de la fase, se identifican sus responsabilidades y las colaboraciones necesarias para satisfacer
estas responsabilidades. Dos técnicas gráficas se introducen para la segunda fase. Una técnica es
demostrar que las clases y las estructuras de clase y la otra es representar las clases, subsistemas y
relaciones del servidor de cliente.
Las tareas propuestas en este método son:
Evaluar la especificación del cliente.
Usar un análisis gramatical para extraer las clases candidatas de la especificación.
Agrupar las clases en un intento de determinar superclases.
Definir responsabilidades para cada clase.
Asignar responsabilidades a cada clase.
Identificar relaciones entre clases.
Definir colaboraciones entre clases basándose en sus responsabilidades.
Construir representaciones jerárquicas de clases para mostrar relaciones de herencia.
Construir un grafo de colaboraciones para el sistema.
110
3.3. Métodos de diseño orientados a objetos (DOO)
Los métodos de diseño orientados a objetos comparten los siguientes pasos básicos de diseño,
aunque los detalles varíen mucho.
Se identifican los objetos y sus atributos, así como los nombres de los métodos.
Se establece la visibilidad de cada objeto en relación con los demás objetos.
Se establece la interfaz de cada objeto y el tratamiento de excepciones.
Se realizan y comprueban los objetos.
3.3.1. Método de Booch - Diseño orientados a objetos con aplicaciones (OODA)
Grady Booch, en su libro Análisis y Diseño Orientado a Objetos con Aplicaciones da a conocer
su método de diseño (Booch, 1991) que se amplió a la fase de análisis (Booch, 1996), señala las
notaciones y métodos utilizados para el desarrollo de sistemas de software complejos que consta
de 4 actividades principales y 6 notaciones. Las actividades están comprendidas en: estructura
lógica, estructura física, dinámica de clases y dinámica de instancias; los primeros dos pasos
tratan los aspectos estáticos del sistema, tanto en su aspecto lógico (dominio del problema) como
en su aspecto físico; y los dos últimos tratan los aspectos dinámicos del sistema. Las notaciones
están contenidas en cada una de estás actividades.
Estructura 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.
Diagramas de clases: Se usa para mostrar la existencia de clases y sus relaciones en la
visión lógica de un sistema. Un solo diagrama de clases representa una vista de la
estructura de clases de un sistema. Durante el análisis, se utilizan diagramas de clases para
indicar las misiones y responsabilidades comunes de las entidades que caracterizan el
comportamiento de un sistema. Durante el diseño, se utilizan diagramas de clases para
plasmar la estructura de las clases que forman la arquitectura del sistema.
111
Diagramas de objetos: Se usa para mostrar la existencia de objetos y sus relaciones en el
diseño lógico de un sistema, es decir, un diagrama de objetos representa una instantánea
en el tiempo de una corriente de eventos sobre una cierta configuración de objetos.
Estructura física: Describe la composición concreta en cuanto a hardware y software del
contexto o implantación del sistema.
Diagramas de módulos: Se usa para mostrar la asignación de clases y objetos a módulos
en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la
estructura de módulos de un sistema. Representa segmentos del sistema (paquetes o
funciones).
Diagramas de procesos: Representan los diagramas de bloques que muestran las
relaciones de comunicación entre dispositivos físicos y procesadores. Un solo diagrama
de procesos representa una vista de la estructura de procesos de un sistema.
Dinámica de clases
Diagramas de transición de estados: Se usa para mostrar el espacio de estados de una
clase determinada, los eventos que provocan una transición de un estado a otro, y las
acciones que resultan de ese cambio de estado. Muestran la dinámica a nivel de clases y
se centran en aquellos estados que den lugar a cambios en los datos o que sean
significativos
Dinámica de instancias
Diagramas de interacción: Se usa para realizar una traza de la ejecución de un escenario
en el mismo contexto que un diagrama de objetos. Muestran el comienzo y la terminación
de los métodos de cada instancia en relación con otros.
Booch (1996) en esencia plantea que para trabajar con su método es conveniente trabajar en dos
partes fundamentales: un micro-proceso y un macro-proceso, que se define a continuación:
Macro-procesos: engloba las ideas generales del sistema.
Primero se establecen los requisitos principales (conceptualización).
112
Luego se desarrolla un modelo de comportamiento deseado (análisis).
Se crea una arquitectura (diseño).
Proceso de evolución de la implementación (evolución).
Administra la evolución posterior a la entrega (mantenimiento).
Micro-procesos: se ocupa de los pequeños detalles de los macroprocesos, define un conjunto de
tareas de análisis que se reaplican en cada etapa en el macro proceso, por esto, mantiene un
enfoque evolutivo.
Identificación de las clases y de los objetos en un nivel de abstracción dado.
Identificación de la semántica de dichas clases y objetos.
Identificación de las relaciones entre estas clases y objetos.
Especificar las interfaces y después la implementación de éstas.
3.3.2. Método Good
El método de diseño general orientado a objetos (GOOD) fue desarrollado en la NASA por
Seidewitz y Stark (1983). Trata tanto la especificación de requisitos como el diseño de proyectos
en Ada. El método se desarrolla, al igual que sucede con el de Booch, partiendo de un conjunto
preliminar de diagramas de flujo por capas, llegando hasta la identificación de los objetos
implicados. En estos DFD se buscan objetos externos, depósitos de datos, interfaces de control y
depósitos de control.
3.3.3. Método Hood
La noción de la jerarquía de prioridades es aprovechada también por otro método, HOOD. La
“H” de HOOD quiere decir jerárquico. Este método también esta muy orientado al desarrollo en
Ada y fue desarrollado en la agencia espacial europea. Sufrió la influencia directa de GOOD, y
también se basa en el método de maquinas abstractas. En HOOD los objetos son pasivos o
activos. Los objetos pasivos solamente son capaces de utilizar los objetos de otros objetos pasivos,
pero los activos pueden utilizar los servicios de cualquier objeto. HOOD es un método de
113
refinamiento progresivo que se basa en la descomposición de un objeto del máximo nivel y,
posteriormente, en la descomposición de los objetos así resultantes.
El método HOOD utiliza un cierto número de pasos para descomponer cada objeto, comenzando
por un paso de diseño básico que podría implicar técnicas de realización de diagramas de
procedentes de otros métodos de análisis y diseño estructurado. El paso siguiente consiste en
generar una estrategia informal de soluciones. Esto se descompone en un cierto número de tareas:
un esbozo del lenguaje natural, diagramas HOOD de primera mano y una descripción del nivel
actual de abstracción. El tercer paso consiste en formalizar la estrategia de solución. Esto se hace
por fases, identificando y describiendo los objetos y sus operaciones.
Para Robinson (1992), las fases pueden ser resumidas como sigue:
1. Definición de problema. Se indica el contexto del objeto que se diseña, con la meta de
organizar y de estructurar los datos a partir de la fase de análisis de requisito.
1.1 Declaración del problema: el diseñador indica el problema, da una definición clara y
exacta del mismo, se diseña el contexto del sistema.
1.2 Análisis y estructuración de los datos de requisito: se recolecta toda la información
relevante al problema, incluyendo el ambiente del sistema que se diseñará.
2. Desarrollo de la estrategia de la solución. La solución del contexto del problema indicado
arriba se describe en términos de objetos en un alto nivel de la abstracción.
3. Formalización de la estrategia. Se definen los objetos y sus operaciones asociadas. Se diseña
un diagrama de HOOD de la propuesta, permitiendo la visualización fácil de los conceptos y de
la formalización posterior. Hay cinco sub-fases en la formalización de la estrategia:
3.1 Identificación del objeto.
3.2 Identificación de la operación.
3.3 Agrupar los objetos y las operaciones (tabla de la operación del objeto).
3.4 Descripción gráfica.
3.5 Justificación de las decisiones del diseño.
114
4. Formalización de la solución. La solución se formaliza a través de la definición formal de los
interfaces proporcionadas por los objetos, la descripción formal de las estructuras de control de
objeto y de la operación.
Notación del diagrama de HOOD
La notación del diagrama principal usado para describir la estructura de un sistema es el diagrama
del objeto de HOOD, que muestra una vista estática de la estructura en el diseño orientado a
objeto jerárquico.
En la Figura 3.8 se puede observar un ejemplo de un diagrama de HOOD para una compañía.
Fuente: Biggs (1999)
Análisis del método
Jacobson et al. opina que (1992): “el método da el paso básico hacia el diseño, pero no da
ninguna ayuda en encontrar la estructura apropiada del objeto. HOOD da realmente la ayuda
fuerte para las estructuras de contención, pero no para otras estructuras tales como estructuras de
uso o de la herencia”. Una de las críticas principales de HOOD es su carencia de la ayuda para
algunas de las técnicas más orientadas al objeto disponibles. La ayuda para la herencia es muy
pobre, según lo evidenciado por la carencia de cualquier notación para representarla gráficamente.
Figura 3.8
Ejemplo de un diagrama HOOD para una compañía
Estructura Alternativa Múltiple
115
3.3.4. Método OOSD
El diseño estructurado orientado a objetos (OOSD), que fuera presentado por Wasserman, Picher
y Muller (1990). Hablando estrictamente OOSD no es un método sino una notación a la cual se
pueden agregar reglas metodológicas. Esta notación es probablemente la que más próxima se
encuentra al espíritu de la orientación a objetos. OOSD es una notación no propietaria para el
diseño arquitectónico, que cambia el diseño por refinamiento progresivo estructurado y el diseño
orientado a objetos. Una vez más OOSD emplea una notación que se deriva de la de Booch, pero,
también tiene influencia de los diagramas estructurales.
OOSD no es tanto un método como una notación para apoyar los métodos de diseño orientado a
objetos en general. Los usuarios de OOSD pueden añadir reglas de diseño según cual sea el
método concreto que esté utilizando.
Otros puntos importantes de OOSD son la facilidad con la que es aceptado por los
desarrolladores que ya están familiarizados con el diseño estructurado así como lo adecuado que
resulta para los sistemas de tiempo real.
OOSD es una de las notaciones de diseño más avanzadas híbrido orientado a objetos de bajo
nivel. Parece improbable que sea posible extenderla hasta una notación de análisis congruente,
como consecuencia de la dificultad que surge al tratar un gran numero de métodos y como
consecuencia también de la ausencia de una forma en la que se puedan tratar estructuras y
atributos de datos muy complejos. Por otra parte, resulta mas adecuada para el diseño
arquitectónico o lógico que para el diseño físico.
3.3.5. Método JSD y OOJSD
El diseño estructurado de Jackson (JSD) es un método basado en objetos más que un método
completamente orientado a objetos. Los modelos JSD se descomponen en términos de sucesos o
de acciones y de sus dependencias temporales. Dentro de estos sucesos la aproximación JSD
define, en primer lugar los objetos. El paso siguiente construye una especificación en términos de
procesos secuenciales que se comunican, y que pueden acceder los unos al estado de los otros. El
116
método puede resultar útil si el diseño orientado a objetos debe realizarse en un lenguaje
convencional.
Es posible identificar un cierto número de similitudes entre JSD y los métodos de diseño
orientados a objetos. JSD contiene técnicas útiles para la identificación de entidades y de métodos
dentro de su fase de modelado. Además, la técnica de análisis por ordenación temporal de JSD y
el diseño orientado a objetos utilizan el concepto de los objetos de forma similar, aun cuando sus
terminologías son distintas.
3.3.6. Método OODLE
El OODLE (lenguaje de diseño orientado a objetos) es un componente específico de diseño del
método Shlaer/Mellor (1988), cuya aproximación al análisis orientado a objetos, prescribe 4 tipos
de diagramas, interrelacionados mediante un esquema de capas que ayuda con la documentación
y con un potencial de apoyo automático. Los tipos de diagramas son los siguientes:
Diagramas de dependencia, que muestran relaciones de utilización (cliente/servidor) y de
amigos entre clases.
Diagramas de clases, que muestran el aspecto externo de la clase de forma similar a
Booch.
Diagramas de estructuras de clases que muestran la estructura de los métodos de la clase,
y el flujo de datos y de control
Diagramas de herencia, que representan la herencia
3.4. Otros métodos
3.4.1. Método de Jacobson - Ingeniería de software orientado a objetos (OOSE)
El método de Ivar Jacobson conocido también por OOSE (ISWOO), es una simplificación de
Objectory, también de Jacobson. Se diferencia de los demás por la importancia que le da al caso
de uso que describe como el usuario interactúa con el producto o sistema.
117
En su libro de Ingeniería del Software Orientada a Objetos, Jacobson plantea con respecto a su
metodología que: "La primera transformación hecha es, de la especificación de los
requerimientos, al modelo de requerimientos. El modelo de requerimientos consiste de: un
modelo de casos de usos, la descripción de las interfaces y un modelo del dominio del problema".
El método desarrollado por Ivar Jacobson OOSE ha sido llamado “un enfoque para el manejo de
casos de uso”, en este enfoque el modelo de casos de uso sirve como un modelo central del cual
todos los otros modelos son derivados. Un modelo de casos de uso describe la funcionalidad
completa del sistema, identificando como, todo lo que esta fuera del sistema, interactúa con él.
Como se puede observar en la siguiente Figura 3.9 del modelo de casos de usos se derivan los
modelos: de requerimientos, análisis, diseño, implementación y prueba.
Fuente: Morales (2003)
Metodología OOSE
El modelo de casos de uso de acuerdo con Jacobson (1992), es la base en la etapa de análisis,
construcción y prueba, esto se puede apreciar mejor en la Figura 3.10 donde se puede apreciar
mejor en qué parte de estas etapas se aplican los diferentes modelos utilizados.
Figura 3.9
Manejo de casos de uso
Clases
SI
SI
SI
Modelo de casos de uso
Expresado en términos de
Estructurado por
Realizado por
Implementado por
Probado en
Modelo de
requerimientos
Modelo de
Análisis
Modelo de
diseño
Modelo de
implementación
Modelo de
prueba
Clases
SI
SI
SI
Modelo de casos de uso
Expresado en términos de
Estructurado por
Realizado por
Implementado por
Probado en
Modelo de
requerimientos
Modelo de
Análisis
Modelo de
diseño
Modelo de
implementación
Modelo de
prueba
118
Fuente: Morales (2003)
OOSE presenta cinco técnicas para modelar un sistema:
Modelo de requerimientos: delimita el sistema y define su funcionalidad. El
objetivo es la captura de requerimientos funcionales
Definir los actores y sus responsabilidades.
Identificar los casos de uso para cada actor.
Preparar una visión inicial de los objetos del sistema y sus relaciones.
Revisar el modelo usando los casos de uso como escenarios, para
determinar su validez.
Modelo de análisis: estructura el sistema, modelando tres tipos de objetos (objetos
de interfase, objetos entidad y objetos de control). El objetivo es dar al sistema una
estructura de objetos robusta y flexible a los cambios.
Identificar objetos de interfaz, usando información del tipo actor-
interacción.
Crear vistas estructurales de los objetos de interfaz.
Representar el comportamiento del objeto.
Aislar subsistemas y modelos para cada uno.
Revisar el modelo usando los casos de uso como escenarios, para
determinar su validez.
Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de
implementación. Consiste de diagramas de interacción y diagramas de transición
de estados.
Figura 3.10
Metodología OOSE
Análisis Contracción
Modelo de Requerimientos
Modelos de análisis
Prueba
Modelo de diseño
Modelos de implementación Modelo de Prueba
SistemaRequerimientos
Análisis Contracción
Modelo de Requerimientos
Modelos de análisis
Prueba
Modelo de diseño
Modelos de implementación Modelo de Prueba
SistemaRequerimientos
119
Modelo de implementación: consiste en el código fuente de los objetos
especificados en el modelo de diseño. Tiene como objetivo implementar el sistema.
Modelo de prueba: es llevado acabo mediante la realización de pruebas al modelo
de implementación. Su objetivo es verificar el sistema.
La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos
funcionales y usar sus perspectivas. Es por eso que la relación entre ellos es importante. Para ser
posible el mantenimiento del sistema es también necesario que los modelos sean tangibles.
3.4.2. Método de Graham. - Semantic Object Model Approach (SOMA)
Este método surgió en 1994 su creador por Graham, el cual propuso combinar una notación única
para el análisis OO con unas reglas del estilo de los sistemas basados en el conocimiento, está
conformado por las siguientes actividades:
Identificar capas: Forma de descomponer el dominio del problema.
Identificar objetos.
Identificar estructuras: de clasificación y composición.
Definir la semántica de los datos y asociaciones: Relaciones estructurales entre clases.
Añadir atributos y operaciones a los objetos.
Añadir la semántica declarativa de objetos: Reglas para resolver conflictos.
3.4.3. Método de fusion
En 1990, Derek Coleman de Hewlett-Packard condujo un equipo en el Reino Unido a desarrollar
un sistema de los requisitos para OOAD, este equipo buscaba crear una metodología simple con
una notación sencilla de manejar. El resultado era la fusión, que Coleman y otros desarrollaron
adaptando ideas de otras metodologías, como las de Booch, de Jacobson, de Rumbaugh, y
rechazaron explícitamente muchas ideas de estas metodologías. Coleman no utilizó algunos de
los componentes principales de Rumbaugh y Shlaer y Mellor en la fusion, porque los
componentes no son encontrados debido a que no fueron útiles en las prácticas.
120
3.4.4. Método de Martin/Odell - Object oriented analysis and design (OOAD)
Esta metodología toma ventaja de la teoría determinada y la lógica. Esta metodología se basa en
describir el comportamiento de objetos. Hay muchas técnicas desarrolladas para especificar
objetos y sus relaciones para describir el comportamiento dinámico de los objetos y la capturar de
los procesos del negocio. (Martin, 1992).
Este método realiza un análisis independiente de la estructura estática y la dinámica de los
objetos, se lleva a cabo de la siguiente manera:
Análisis de los requisitos del cliente.
Identificación de la estructura estática del objeto.
Modelación del análisis de la estructura del objeto.
Identificación de la estructura dinámica de los objetos.
Modelación del análisis del comportamiento de los objetos.
Lenguaje de
Modelado Unificado
CAPITULO
Lenguaje de Modelado Unificado
(UML)
El siguiente capítulo se hace un estudio documental sobre el origen y la evolución del Lenguaje
de Modelado Unificado, conocido por sus siglas como UML. Este lenguaje gráfico se usa para
visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de
software; integra una serie de diagramas que son utilizados para el análisis y diseño de software,
para modelar lo conceptual (procesos de negocio y funciones de sistema), además de cosas
concretas como lo son escribir las clases en un lenguaje determinado, esquemas de base de datos
y componentes de software reusables.
4.1. Introducción al UML
Una vez que el paradigma orientado a objetos (OO) fue adoptado como el más adecuado para
producir software de calidad, a principios de los noventa, emergió un buen número de métodos de
desarrollo de software OO. Diversos autores atravesaron por el problema de desarrollar
metodologías diversas, cada uno con sus métodos y hasta sus propios enfoques.
En julio de 1993, Jacobson criticó lo que él denominaba guerra de métodos y planteó la necesidad
de llegar a una notación estándar de modelado, para evitar la confusión reinante (por la falta de
estándares) y favorecer el uso de los métodos de software OO. A finales de 1994 se inició un
esfuerzo de unificación por parte de los creadores de los tres principales métodos: Booch,
Rumbaugh y Jacobson.
Así surgió el Lenguaje de Modelado Unificado (UML, Unified Modeling Language) que es el
resultado de cohesionar en un solo estándar, los mecanismos para desarrollar software, y ello
gracias a los esfuerzos de diversos autores (Ver Figura 4.1) que entendieron que el desarrollo de
126
un estándar era una prioridad en el diseño de software. Según sus creadores, UML (Lenguaje
Unificado de Modelado) es un lenguaje gráfico que sirve para visualizar, especificar, construir y
documentar los componentes de un sistema software.
Fuente: Letelier (1996)
Luego de diversas etapas de evolución, el UML fue adoptado en noviembre de 1997 por la OMG
(Object Management Group) como parte de sus requerimientos, y desde entonces se ha
convertido en un estándar para visualizar, especificar, construir y documentar los modelos que se
crean durante la aplicación de un proceso software. En la Figura 4.2 se puede observar la
evolución de UML hasta los actuales momentos.
Debido a que UML evolucionó a partir de varios métodos orientados a objetos de segunda
generación (en cuanto a nivel de notación), mayoritariamente se cree que sólo es aplicable a
sistemas de software orientados a objeto cuando, realmente, UML no es simplemente un lenguaje
para modelado orientado a objeto de tercera generación, sino un “lenguaje para modelado
unificado” relativo a sistemas en general.
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cyclesUML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles
Figura 4.1
Influencia de métodos de desarrollo de software y UML
127
Fuente: Letelier (1996)
El lenguaje de modelado unificado sirve para especificar, visualizar y documentar esquemas de
sistemas de software. UML no es un método de desarrollo, lo que significa que no sirve para
determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que le ayuda a visualizar el
diseño y a hacerlo más accesible para otros. Al ser un lenguaje de modelado gráfico y no un
método, consiste en una notación que cualquier método puede emplear para expresar su diseño.
UML permite tanto la especificación conceptual de un sistema como la especificación de
elementos concretos, como pueden ser el diseño de clases o el de una base de datos.
Según su definición, los objetivos de UML son los siguientes:
Visualizar, UML permite representar mediante su simbología el contenido y la estructura de un
sistema software. La notación UML permite definir modelos que serán claramente comprensibles
por otros desarrolladores facilitando así el mantenimiento del sistema que describe. Especificar,
UML permite especificar los procesos de análisis, diseño y codificación de un sistema software.
Figura 4.2
Evolución de UML
Otros métodos Booch’91 OMT-1 (Rumbaugh) OOSE (Jacobson)
Booch’93 OMT-2
OOPSLA’95 Método Unificado 0.8
Junio 96 y Octubre 1996 en la Web
UML 1.0Publicación de UML 1.0
Enero 1997
UML 1.1OMG lo adopta como estándar
Noviembre 1997
Colaboradores y
expertos
Do
cum
ento
s P
ub
lica
do
s
Fragmentación
Unificación
Estandarización
UML 1.3Junio 1999, OMG
diciembre 2004, OMG
UML 1.4
UML 1.5
UML 2.0UML 2.0
Industrializaciónmayo 2001, OMG
marzo 2003, OMG
UML 0.9 & 0.91
Otros métodos Booch’91 OMT-1 (Rumbaugh) OOSE (Jacobson)
Booch’93 OMT-2
OOPSLA’95 Método Unificado 0.8
Junio 96 y Octubre 1996 en la Web
UML 1.0Publicación de UML 1.0
Enero 1997
UML 1.1OMG lo adopta como estándar
Noviembre 1997
Colaboradores y
expertos
Do
cum
ento
s P
ub
lica
do
s
Fragmentación
Unificación
Estandarización
UML 1.3Junio 1999, OMG
diciembre 2004, OMG
UML 1.4
UML 1.5
UML 2.0UML 2.0
Industrializaciónmayo 2001, OMG
marzo 2003, OMG
UML 0.9 & 0.91
128
También permite determinar modelos precisos, sin ambigüedades, detallando las partes
esenciales de los mismos.
Especificar, UML permite especificar cuáles son las características de un sistema antes de su
construcción.
Construir, Las anteriores características permiten que UML pueda generar código en distintos
lenguajes de programación y tablas en una base de datos a partir de modelos UML. Además
permite simular el comportamiento de sistemas software.
Documentar, Como ya se comentó antes, UML permite especificar los procesos de análisis,
diseño y codificación y también permite documentar los mismos, dejando clara la arquitectura del
sistema.
En resumen, UML posibilita la captura y comunicación del conocimiento y facilita la adaptación
al posible aumento de complejidad o cambio. Este lenguaje para modelado (estandarizado en
ciertas industrias), no es un lenguaje cerrado, sino más bien, un lenguaje abierto y totalmente
extensible.
4.1.1. UML 2.0
La versión 2.0 de UML viene acompañada de nuevas versiones de los estándares MOF (Meta
Object Facility), XMI (XML Metadata Interchage) y OCL (Object Constraint Language). Es un
intento de coordinación general de varios estándares para dar un soporte más formal y completo a
la filosofía general de MDA (Model Driven Arquitectura). MOF 2.0 da soporte al núcleo de
UML y permite la creación formal de un número indeterminado de niveles de abstracción. XMI
2.0 permite la serialización automática de los modelos UML en forma de ficheros XML y de los
metamodelos en forma de XML Schemas. Está recomendado su uso para el intercambio estándar
de información entre herramientas UML y para el almacenamiento de los modelos en repositorios
XML.
129
Mientras que UML 1.4 tenía como objetivo principal la respuesta a las necesidades clásicas de la
industria del SW, UML 2.0 se plantea cubrir otros campos como el modelado de negocio, de
sistemas de tiempo real, basado en componentes, etc. El mecanismo estándar para extender las
capacidades de UML a cada uno de estos campos específicos es el de los perfiles y este
mecanismo se ve mejorado en la nueva versión. En general, se mejora la escalabilidad y
usabilidad del lenguaje en todos los ámbitos.
Características generales de UML 2.0:
Simplificación de la sintaxis y semántica del lenguaje.
Alineación formal con MOF.
Soporte del modelado de la arquitectura SW y del modelado basado en componentes, lo
que conlleva el uso de una nueva semántica:
Además de la semántica de comportamiento y datos propia de la orientación a objetos,
se expresan servicios e interfaces para desarrollar entidades autónomas.
Concepto de puerto (punto de interacción entre clases) y de puerto de comportamiento
(configuración inicial de una clase, capacidad para crear y borrar partes).
Descomposición jerárquica (bloques que se ensamblan formando bloques mayores)
Se refina el modelo de desarrollo y el de proceso, gracias a la mejora de los diagramas de
actividad, de interacciones y máquinas de estados.
Nuevo mecanismo de extensión para añadir metaclases propias y mejorar así la definición
de perfiles.
Soporte de arquitecturas en tiempo de ejecución para modelar flujo de datos y objetos
entre diferentes partes del sistema.
Mejor representación de las relaciones.
Mejor modelado de comportamiento con encapsulado y escalabilidad.
Modelos ejecutables (nueva semántica de acción):
130
Capacidad para definir puntos de entrada y salida de un estado compuesto.
Capacidad para expresar un bloque de acción.
Semánticas de acciones de ejecución (el modelo es independiente del lenguaje
destino). OCL (Object Constraint Language) refinado para dotar de semántica de
comportamiento (acción) a UML (aparte de la estructural).
UML 2.0 hace innecesario el uso de extensiones de su metamodelo para tratar los problemas
específicos de dominios específicos.
4.1.2. Modelo conceptual de UML
Según Booch, Rumbaugh y Jacobson (2002), el modelo conceptual de UML esta constituido por
tres grandes elementos:
1. Los bloques básicos de construcción de UML.
2. Las reglas semánticas que definen como se pueden combinar dichos bloques.
3. Mecanismos comunes de aplicación general.
Bloques de construcción de UML
Los bloques de construcción están subdivididos en elementos, relaciones y diagramas; los
elementos son las abstracciones de un modelo, pueden ser de algún componente o aspecto del
sistema modelado; las relaciones ligan estos elementos entre sí; los diagramas agrupan elementos
y relaciones.
Reglas de UML
Los bloques de construcción se deben combinar siguiendo las reglas que establece UML. UML
establece una serie de normas sobre cómo nombrar a los elementos, relaciones y diagramas; la
131
visibilidad y alcance de dichos nombres y sobre su integridad (cómo diseñar relaciones
consistentes). Podremos decir que un modelo está bien formado cuando cumpla estas reglas.
Las reglas semánticas se aplican a:
Los nombres: cómo llamar a los elementos, relaciones y diagramas
Ámbito o Alcance: contexto que da un significado específico a un nombre.
Visibilidad: cómo se pueden ver y utilizar estos nombres por otros.
Integridad: cómo se relacionan unos elementos con otros.
Ejecución: significado de simular o ejecutar un modelo dinámico
Las reglas de UML se aplican en las fases de análisis, diseño e implementación con el fin de
obtener un sistema eficiente y bien formado.
Mecanismos comunes de aplicación general
Bajo una serie de mecanismos que se aplican durante todo el proceso de desarrollo de modelos en
UML, se consiguen diseños simples y eficientes. UML utiliza cuatro mecanismos comunes
aplicados de forma consistente al sistema.
1. Especificaciones. Proporcionan una explicación textual de la sintaxis y la semántica de un
bloque de construcción.
Ejemplo: cuando se define una clase, detrás de ella hay una especificación que proporciona toda
la información acerca de sus atributos, operaciones y comportamiento. Un icono de la clase
puede mostrar una pequeña parte de su especificación. También se pueden generar vistas de la
clase que contengan elementos totalmente diferentes pero que están relacionados con las
especificaciones dadas a la clase inicial.
La notación gráfica de UML se utiliza para visualizar un sistema, la especificación de UML se
utiliza para enunciar los detalles del sistema. Se puede construir un modelo dibujando primero los
diagramas y luego añadir la semántica a las especificaciones o generar los diagramas a partir de
las especificaciones establecidas.
132
2. Apariencia o Adornos. Son los detalles de la especificación de un elemento que se añade
a su notación gráfica básica, incluye aspectos como el nombre, sus atributos y operaciones.
La especificación de una clase puede incluir detalles como si es abstracta o la visibilidad
de sus atributos y operaciones. Estos detalles se pueden incluir como adornos.
3. Categorizaciones o Divisiones Comunes: Cuando se modelan sistemas orientados a
objetos el mundo puede dividirse de varias formas. División entre clase y objeto,
separación entre interfaz e implementación, imagen interfaz e implementación
4. Mecanismos de Extensibilidad: Ya que un lenguaje cerrado no siempre es útil para la
representación de los matices de los modelos en todos los dominios y en todos los
momentos, UML es abierto permitiendo extender el lenguaje de manera controlada. Los
mecanismos de extensión incluyen:
o Estereotipos: Extiende el vocabulario de UML permitiendo crear nuevos tipos de
bloques de construcción que deriven de los existentes y que sean específicos a un
problema.
o Valores Etiquetados: Extiende las propiedades de un bloque de construcción de
UML, permitiendo añadir nueva información a la especificación del elemento.
Ejemplo: Cuando se trabaja con un producto que atraviesa muchas versiones a lo largo del tiempo,
se querrá registrar la versión y el autor. Para ello, estos datos pueden ser añadidos a cualquier
bloque de construcción, como una clase introduciendo nuevos valores etiquetados.
o Restricciones. Extiende la semántica de un bloque de construcción de UML,
permitiendo añadir nuevas reglas o modificar las existentes
En la Figura 4.3 se muestran los conceptos que maneja UML, organizados en un cuadro sinóptico
hecho a partir del modelo conceptual de UML que se enuncia en el libro de The Unified
Modeling Language Users Guide (Booch, Rumbaugh y Jacobson, 1999).
133
4.1.3. Diagramas en UML 2.0
UML en su versión 2.0 describe un total de trece (13) diagramas distintos. La particularidad de
UML es que no mantiene una relación estricta entre los diagramas y los elementos que éstos
contienen, sino que es posible el empleo de símbolos en principio asociados a un determinado
Figura 4.3
Modelo conceptual de UML
Fuente: Booch, Rumbaugh
y Jacobson (1999)
134
tipo de diagrama en otro distinto si de esta forma se clarifica el diseño del sistema que se está
modelando.
Los diagramas UML definen los modelos que manejan el lenguaje de modelado y se clasifican en
estáticos o de estructura y de comportamiento, como se observan en la Figura 4.4.
Figura 4.4
Diagramas en UML 2.0
Fuente: Fowler (2003)
135
4.2. Diagramas de estructura o estáticos
Son los diagramas que reflejan la estructura estática del sistema. Se centran en la identificación y
descripción de los elementos y componentes que forman parte del mismo, y de la forma que
tienen éstos de relacionarse entre sí.
4.2.1. Diagrama de clases
El diagrama de clases como se ve en la Figura 4.5 describe los tipos de objetos del sistema, y las
distintas relaciones estáticas que se dan entre ellos. Los diagramas de clases muestran también las
propiedades y operaciones de una clase, y las restricciones que se deben aplicar a la hora de
relacionar objetos
Las propiedades representan los rasgos estructurales de una clase. En una primera aproximación,
se corresponderían los atributos de la clase.
Las operaciones son las acciones que una clase puede llevar a cabo. Estas se corresponden con
los métodos de la clase. Normalmente no todas las operaciones son representadas en el diagrama
de clases, sólo las más representativas.
Las relaciones permiten representar las colaboraciones entre clases que se van a dar en el sistema.
UML contempla diferentes formas de relación entre clases, como las asociaciones y las
generalizaciones.
136
Fuente: Fowler (2003)
4.2.2. Diagrama de componentes
Un diagrama de componentes (Ver Figura 4.6) muestra las organizaciones y dependencias lógicas
entre componentes del software, sean éstos componentes de código fuente, binarios o ejecutables.
Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos
relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las
restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el
desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán
componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de componentes, ya
Figura 4.5
Ejemplo de un diagrama de clases
137
que las instancias específicas de cada tipo se encuentran especificadas en el diagrama de
despliegue.
Dado que los diagramas de componentes muestran los componentes de software que constituyen
una parte reutilizable, sus interfaces, y sus interrelaciones, en muchos aspectos se puede
considerar que un diagrama de componentes es un diagrama de clases a gran escala. Cada
componente en el diagrama debe ser documentado con un diagrama de componentes más
detallado, un diagrama de clases, o un diagrama de casos de uso.
Un paquete en un diagrama de componentes representa una división física del sistema. Los
paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida.
Fuente: Fowler (2003)
4.2.3. Diagramas de estructuras compuestas
Los diagramas de estructura compuesta como se observa en la Figura 4.7 permiten descomponer
una clase en su estructura interna (Fowler, 2003), de esta forma, es posible desgranar en partes
los objetos complejos del sistema.
Figura 4.6
Ejemplo de un diagrama de componentes
138
Los diagramas de estructuras compuestas son similares a los diagramas de paquetes, con la
salvedad de que estos últimos referencian agrupaciones dadas en tiempo de compilación,
mientras que los primeros muestran agrupaciones que sedan en tiempo de ejecución.
Fuente: Fowler (2003)
4.2.4. Diagrama de despliegues
Un diagrama de despliegue como se observa en la Figura 4.8 muestra las relaciones físicas entre
los componentes hardware y software en el sistema final, es decir, la configuración de los
elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y
objetos que se ejecutan en ellos). Están formados por instancias de los componentes de software
que representan manifestaciones del código en tiempo de ejecución (los componentes que sólo
sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes).
Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un
nodo puede contener instancias de componentes de software, objetos, procesos (caso particular de
un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a
un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de
dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).
Figura 4.7
Ejemplo de un diagrama de estructura compuesta
139
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional,
generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o
tipos de nodos que se representa como un cubo 3D en los diagramas de implementación.
Las instancias de componentes de software muestran unidades de software en tiempo de
ejecución y generalmente ayudan a identificar sus dependencias y su localización en nodos.
Pueden mostrar también qué interfaces implementan y qué objetos contienen.
Los diagramas de despliegue muestran la configuración en funcionamiento del sistema,
incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se
deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de
respuesta requerido, etc.
Fuente: Fowler (2003)
La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la
topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son
fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema.
Aunque UML no es un lenguaje para especificar hardware de propósito general, se ha diseñado
para modelar muchos de estos aspectos a nivel básico, que sirven para que un ingeniero de
Figura 4.8
Ejemplo de un diagrama de despliegue
140
software pueda especificar la plataforma sobre la que se ejecuta el software del sistema y para
que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se
trata de una relación de conexión o comunicación. Los diagramas de despliegue sirven para
razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software.
Esta vista cubre principalmente la distribución, entrega e instalación de las partes que configuran
un sistema físico. Los diagramas de despliegue se suelen utilizar para modelar:
Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran
cantidad de software que interactúa con el mundo físico. Los sistemas empotrados
involucran software que controla dispositivo (motores, periféricos) que a su vez están
controlados por estímulos externos como sensores.
Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de
los sistemas distribuidos. Requieren tomar decisiones sobre la conectividad de red de los
clientes a los servidores, y sobre la distribución física de los componentes software del
sistema a través de los nodos.
Sistemas completamente distribuidos: son aquellos sistemas que son ampliamente o
totalmente distribuidos y que normalmente incluyen varios niveles de servidores, tales
sistemas contienen a menudo varias versiones de componentes software, alguno de los
cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere
tomar decisiones que permitan un cambio continuo de la topología del sistema.
4.2.5. Diagramas de objetos
Los diagramas de objetos modelan las instancias de elementos contenidos en los diagrama s de
clases. Un diagrama de objetos (Ver Figura 4.9) muestra un conjunto de objetos y sus relaciones
en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos
estáticos del sistema, mientras que los diagramas de interacción se utilizan para ver los aspectos
dinámicos del mismo. Estos cuentan con instancias de los elementos del diagrama de clases y
mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos,
que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases,
141
representando sólo la parte estática de un interacción, consistiendo en los objetos que colaboran
pero sin ninguno de los mensajes intercambiados entre ellos.
Los diagramas de objetos se emplean para modelar la vista de diseño estática o la vista de
procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la
perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos
funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos
estáticas.
En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que
implica tomar una instancia de los objetos de un sistema en un cierto momento. Un diagrama de
objetos representa una escena estática representada por un diagrama de interacción. Los
diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia
de ciertas instancias en el sistema, junto a las relaciones entre ellas.
Los diagramas de objetos son especialmente útiles para modelar estructuras de datos complejas.
Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un
conjunto de clases con varias relaciones entre ellas, pueden existir muchas más configuraciones
posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar
significativamente conjuntos interesantes de objetos concretos o prototipos.
desde el diagrama de clases
Fuente: Matteo (2005)
Figura 4.9
Ejemplo de un diagrama de objetos
Juan:Usuario
Nombre: “Juan L”
Edad: 22
Lisiu:Ordenador
Marca: “Sun”
UsaJuan:Usuario
Nombre: “Juan L”
Edad: 22
Juan:Usuario
Nombre: “Juan L”
Edad: 22
Lisiu:Ordenador
Marca: “Sun”
Usa
Ordenador
Marca: String
Usuario
Nombre: String
Edad: Integer
Usa0…* 1…*
Ordenador
Marca: String
Usuario
Nombre: String
Edad: Integer
Usa0…* 1…*
142
4.2.6. Diagrama de paquetes
Según la página web wikipedia3 un diagrama de paquetes muestra como un sistema está dividido
en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que
normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran
una descomposición de la jerarquía lógica de un sistema.
Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Para
ser funcional, la asignación debe seguir un cierto principio racional, tal como funcionalidad
común, implementación relacionada y punto de vista común. UML no impone una regla para
componer los paquetes.
Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas
agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del
modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los
modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión
de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del
modelo.
Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete.
Los paquetes contienen elementos del modelo al más alto nivel, tales como clases y sus
relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones.
Atributos, operaciones, estados, líneas de vida y mensajes están contenidos en otros elementos y
no aparecen como contenido directo de los paquetes.
Las dependencias que se presentan entre los elementos individuales, pero en un sistema de
cualquier tamaño, deben ser vistas en un nivel más alto. Cuando las dependencias se dan entre
paquetes, resumen dependencias entre los elementos internos a ellos, es decir, las dependencias
del paquete son derivables a partir de las dependencias entre los elementos individuales.
La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente
(una declaración de existencia), o que se permite que exista más adelante en un enfoque
descendente (una restricción que limita cualquier otra relación), por lo menos un elemento de
3 http://es.wikipedia.org/wiki/Diagrama_de_paquetes
143
relación con el tipo de dependencia indicado entre elementos individuales dentro de los paquetes
correspondientes.
Las dependencias múltiples del mismo tipo entre elementos individuales se agregan a una sola
dependencia entre los paquetes que contienen los elementos. Si las dependencias entre elementos
contienen estereotipos, éste puede ser omitido en la dependencia del paquete, para dar una sola
dependencia de alto nivel.
Una clase de un paquete puede aparecer en otro paquete por la importación a través de una
relación de dependencia entre paquetes. Todas las clases no son necesariamente visibles desde el
exterior del paquete, es decir, un paquete encapsula a la vez que agrupa.
En general, un paquete no puede tener acceso al contenido de otro paquete. Los paquetes son
cerrados, a menos que sean abiertos por una dependencia de acceso o de importación. La
dependencia de acceso indica que el contenido del paquete del proveedor puede aparecer en
referencias efectuadas por los elementos del paquete cliente. En general, un paquete puede ver
solamente los elementos de otros paquetes que tienen visibilidad pública. Los elementos con
visibilidad protegida pueden ser vistos únicamente por los paquetes que son descendientes del
paquete contenedor de dichos elementos. Los elementos con visibilidad privada sólo son vistos
por su paquete contenedor y anidados. La visibilidad también se aplica a las clases. El permiso de
acceso y visibilidad son necesarios para hacer referencia a un elemento.
La dependencia de acceso no modifica el espacio de nombres del cliente no crea las referencias
automáticamente, simplemente concede permiso para establecer referencias. La dependencia de
importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como
sinónimos de los caminos completos.
Los paquetes se dibujan como rectángulos con pestañas, y las dependencias se muestran como
flechas con líneas discontinuas. El operador: permite designar una clase definida en un contexto
distinto del actual, en la Figura 4.10 se muestra que el paquete “yyedra” contiene una
presentación y se relaciona con el paquete “util”.
144
Fuente: Fowler (2003)
4.3. Diagramas de comportamiento o dinámicos
Los diagramas dinámicos reflejan el comportamiento del sistema y de sus componentes. Tratan
de representar aspectos ligados al tiempo, mostrando como interactúan las distintas partes del
sistema.
4.3.1. Diagramas de actividades
Para Fowler (2003), los diagramas de actividades son una técnica para describir lógica de
procedimientos, procesos de negocios, y flujo de trabajo. En muchos modos juegan un papel
similar al de los diagramas de flujo, pero la principal diferencia entre ellos y la notación de los
diagramas de flujo es que ellos soportan el comportamiento paralelo. Un diagrama de actividad
representa el comportamiento mediante un modelo de flujo de datos y flujo de control
El ejemplo tomado del libro UML Distilled nos muestra un simple diagrama de actividades (Ver
Figura 4.11). Donde se comienza la acción en el nodo inicial y entonces hacemos que la acción
reciba órdenes. Hecho esto, encontramos un tenedor (nodo fork). Un tenedor tiene un flujo
entrante y varios flujos concurrentes salientes.
En la Figura 4.11 se muestra que llenar la orden, enviar la factura y las acciones subsecuentes
ocurren en paralelo. Esencialmente, esto significa que la secuencia entre ellas es irrelevante. Se
yyedra
presentación
utilyyedra
presentación
yyedra
presentación
utilutil
Figura 4.10
Ejemplo de un diagrama de paquetes
145
podría llenar la orden, enviar la factura, entregar y recibir el pago; o podría enviar la factura,
recibir el pago, llenar la orden y luego entregar.
También se podría llevar a cabo estas acciones por individual (interleaving). Se toma el primer
ítem de línea de los depósitos, escribo la factura, tomo el segundo ítem de línea, pongo la factura
en un sobre, y así sucesivamente. O podría ejecutar varias de estas simultáneamente: escribo la
factura con una mano mientras busco en mis depósitos con la otra. Cualquiera de estas secuencias
es correcta de acuerdo al diagrama.
El diagrama de actividades permite que cualquiera que este ejecutando el proceso pueda escoger
el orden en el cual desee hacer las cosas. En otras palabras, el diagrama simplemente declara las
reglas esenciales de secuencia que debe seguir. Esto es importante en el modelado de negocios
porque aquí los procesos usualmente ocurren en paralelo. También es útil para algoritmos
concurrentes, en los cuales los hilos independientes pueden hacer cosas en paralelo.
Cuando existe procesos en paralelo se deben sincronizar, por ejemplo, no se cerrará la orden
hasta que sea entregada y pagada. Se muestra esto unido antes de la acción de Cerrar Orden. Con
una unión, el flujo saliente es tomado solo cuando todos los flujos entrantes alcanzan la unión. De
modo que solo puedes cerrar la orden cuando has recibido el pago y entregado.
Se puede observar que los nodos sobre un diagrama de actividades son llamados acciones, no
actividades. Una actividad se refiere estrictamente a una secuencia de acciones, de modo que el
diagrama muestra una actividad hecha de acciones.
En la Figura 4.11, después de que la orden es llenada hay una decisión. Si tienen una orden
urgente, hacen una entrega nocturna; de otro modo hacen una entrega regular.
Una fusión tiene múltiples flujos de entrada y un único saliente. Un nodo merge marca el fin del
comportamiento condicional empezado por una decisión.
146
Fuente: Fowler (2003)
Acciones
En un diagrama de actividad una acción es un nodo de actividad ejecutable.
Una acción representa una unidad fundamental de funcionalidad ejecutable en una actividad. En
la Figura 4.12 se puede observar un ejemplo de una acción.
Fuente: Matteo (2005)
Figura 4.11
Ejemplo de un diagrama de actividades
Figura 4.12
Ejemplo de una “acción”
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
Llenar
orden
Entregar
de noche
Entregar
regular
actividad final
joinnodo merge
acción
decisión
[sino]
nodo inicial
nodo fork
flujo
[prioridad]
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
Llenar
orden
Entregar
de noche
Entregar
regular
actividad final
joinnodo merge
acción
decisión
[sino]
nodo inicial
nodo fork
flujo
[prioridad]
Enviar fichero PostScript
a la impresora
Crear fichero PostScrptMostrar mensaje
“imprimiendo”
Flujo de ControlAcción
Nodo final de actividad
Nodo inicial
Eliminar mensajeEnviar fichero PostScript
a la impresora
Crear fichero PostScrptMostrar mensaje
“imprimiendo”
Flujo de ControlAcción
Nodo final de actividad
Nodo inicial
Eliminar mensaje
147
Expresiones resguardadas (guard expressions)
Una expresión resguardada es utilizada para indicar una descripción explicita acerca de una
transición. Este tipo de expresión es representada mediante corchetes ([...] y es colocada sobre la
línea de transición.
Actividades
Una actividad representa un comportamiento compuesto de elementos individuales que son las
acciones. El flujo de ejecución se modela con nodos de actividad conectados por arcos de
actividad.
Los nodos incluyen:
Acciones de varios tipos: funciones primitivas, invocación de comportamiento, acciones de
comunicación (señales) y manipulación de objetos.
Objetos: nodos que proporcionan y aceptan objetos y datos.
Constructores de control de flujo: sincronización, decisión y control de concurrencia
Tipos de nodos
• Nodo de decisión: nodo con un arco de entrada y varios arcos de salida
• Nodo de fusión (merge): nodo de control al que llegan varios flujos alternativos
• Nodo tenedor (fork): Nodo de control que divide un flujo en múltiples flujos
concurrentes.
• Nodo unión (join): nodo que tiene como arcos de entrada múltiples flujos concurrentes y
un solo arco de salida.
• Nodo inicial: nodo de control en el que comienza el flujo cuando se invoca una actividad
• Nodo final:
- De actividad: nodo que detiene todos los flujos de una actividad
- De flujo: nodo que detiene un flujo
En la Figura 4.13 se pueden observar todos los tipos de nodos mencionados anteriormente.
148
Fuente: Matteo (2005)
Flujos y límites
UML usa los términos flujo y límite como sinónimos para describir las conexiones entre dos
acciones. El tipo más simple de límite es la flecha simple entre dos acciones. Le pueden dar un
nombre a un límite si eso desean, pero la mayor parte del tiempo, una simple flecha será
suficiente.
Si están teniendo problemas guiando las líneas, pueden usar conectores, los cuales simplemente
le ahorrarán el trabajo de tener que dibujar una línea para toda la distancia. Cuando se usan
conectores, se deben usar en pares: uno con el flujo entrante, uno con un flujo saliente y ambos
con el mismo tipo de etiqueta.
Los límites más simples pasan un token que no tiene ningún significado más que controlar el
flujo. Sin embargo, pueden también pasar objetos a lo largo de límites; luego los objetos juegan
el papel de tokens mientras llevan datos. Si están pasando un objeto a lo largo de un límite,
pueden mostrar eso poniendo una casilla de clase en el límite, o pueden usar pines sobre las
acciones.
Figura 4.13
Notación de diferentes tipos de nodos
Nodo final de flujoNodo inicial Nodo final de actividad
Nodo de decisión Nodo Fork
Nodo joinNodo merge
Nodo de decisión con
comportamiento
Nodo final de flujoNodo inicial Nodo final de actividad
Nodo de decisión Nodo Fork
Nodo joinNodo merge
Nodo de decisión con
comportamiento
149
Todos los estilos mostrados en la Figura 4.14 son equivalentes; deben usar cualquiera que
transmita mejor lo que intentan comunicar. La mayoría de las veces una simple flecha es
totalmente suficiente
Fuente: Fowler (2003)
Regiones de expansión
Con los diagramas de actividad, usualmente se encuentran en situaciones en las cuales la salida
de una acción activa múltiples invocaciones de otra acción. Hay muchas maneras de mostrar esto,
pero la mejor manera es usar una región de expansión. Una región de expansión marca un área
del diagrama de actividad donde las acciones ocurren una vez por cada ítem en un grupo.
En la Figura 4.15, la acción “elegir tópico” genera una lista de tópicos así como su salida.
Entonces cada elemento de esta lista se convierte en un token para la entrada a la acción de
“escribir artículo”. Igualmente, cada acción “revisar artículo” genera un único artículo que es
añadido a la lista de salida de la región de expansión. Cuando todos los tokens en la región de
expansión terminan en el grupo de salida, la región genera un único token para la lista que es
pasado a “publicar artículo”.
En este caso, tienen la misma cantidad de ítem tanto en el grupo de salida como en el de entrada.
Sin embargo, pueden tener menos, en cuyo caso la región de expansión actúa como un filtro.
Figura 4.14
Ejemplos de flujos y límites
Cuatro modos de mostrar un límite
Recibir
factura
Recibir
factura
Recibir
factura
Recibir
factura
Realizar
pago
Realizar
pago
Realizar
pago
Realizar
pago
Orden
A A
pin
orden orden
nodo objeto
(1)
(4)
(3)
(2)
conector
Cuatro modos de mostrar un límite
Recibir
factura
Recibir
factura
Recibir
factura
Recibir
factura
Realizar
pago
Realizar
pago
Realizar
pago
Realizar
pago
Orden
A A
pin
orden orden
nodo objeto
(1)
(4)
(3)
(2)
conector
Recibir
factura
Recibir
factura
Recibir
factura
Recibir
factura
Realizar
pago
Realizar
pago
Realizar
pago
Realizar
pago
Orden
A A
pin
orden orden
nodo objeto
(1)
(4)
(3)
(2)
conector
150
En la Figura 4.15 todos los artículos son escritos y revisados en paralelo, lo cual es señalado con
la palabra clave concurrent. También puede haber una región de expansión iterativa. Las regiones
iterativas deben procesar completamente cada elemento de entrada uno a la vez.
Fuente: Fowler (2003)
Señales
Señales en un diagrama de actividades
Una señal de tiempo ocurre cuando transcurre algún tiempo. Dichas señales pueden indicar el
final de un mes en período financiero o cada micro segundo en un controlador de tiempo real.
La Figura 4.16 muestra una actividad que recibe dos señales. Una señal indica que la actividad
recibe un evento de un proceso externo. Esto indica que la actividad constantemente presta
atención a esas señales, y el diagrama define como reacciona la actividad.
En el caso de la Figura 4.16, dos (2) horas antes de que el vuelo despegue se debe empezar a
empacar el equipaje. Aún si el equipaje estuviera listo, no se puede ir al aeropuerto si el taxi no
llega. Si el taxi llega antes de que termine de alistar el equipaje, debe esperar a que termine antes
de irnos.
Elegir
tópico
Escribir
artículo
región de expansiónlista de tópicos
Revisar
artículos
Publicar el
artículo
Palabra clave
Pin_ caja de lista
<<concurrent>>
Elegir
tópico
Escribir
artículo
región de expansiónlista de tópicos
Revisar
artículos
Publicar el
artículo
Palabra clave
Pin_ caja de lista
<<concurrent>>
Figura 4.15
Regiones de expansión
151
Fuente: Fowler (2003)
Envío y recepción de señal
Así como recibimos señales, podemos enviarlas. Esto es útil cuando tenemos que enviar un
mensaje y luego esperar una respuesta antes de continuar. La figura 4.17 muestra un buen
ejemplo de esto con un idioma común de timing out o pausa. Se puede observar que los dos flujos
se hallan en una carrera: El primero en alcanzar el estado final ganará y acabará con el otro flujo.
Aunque las admisiones esta generalmente esperando por un evento externo, también se puede
mostrar un flujo entrando a ellas. Eso indica que no comenzamos a percibir las señales hasta que
el flujo active la admisión.
Fuente: Fowler (2003)
Particiones
Los diagramas de actividad (Fowler, 2003), les dice que pasa, pero no les dice quién hace qué. En
programación, esto significa que el diagrama no transmite cuál clase es responsable por cada
Figura 4.16
Señales en un diagrama de actividades
Figura 4.17
Envío y recepción de señales
Empacar
equipaje
señal de tiempo
Llega el taxi
Ir al
aeropuerto
aceptar la señal
2 hrs. antes del
vuelo
Empacar
equipaje
señal de tiempo
Llega el taxi
Ir al
aeropuerto
aceptar la señal
2 hrs. antes del
vuelo
Confirmar
itinerario
Esperar 48 horas
aceptar la señal
Enviar la señal
Itinerario
de libros
Cancelar
itinerario
Reservar
itinerario
Enviar
itinerario
Confirmar
itinerario
Esperar 48 horas
aceptar la señal
Enviar la señal
Itinerario
de libros
Cancelar
itinerario
Reservar
itinerario
Enviar
itinerario
152
acción. En el modelado de procesos de negocios, éste no transmite cual parte de una organización
lleva a cabo cual acción. Esto no es necesariamente un problema; generalmente tiene sentido
concentrarse en lo que se ha hecho en lugar de quién hace que partes del comportamiento.
Si quieren mostrar quién hace qué, pueden dividir un diagrama de actividades en particiones, las
cuales muestran las acciones que llevan a cabo una clase o unidad de organización. La Figura
4.18 muestra un ejemplo simple de esto, mostrando como las acciones involucradas en el
procesamiento de órdenes pueden ser separadas en varios departamentos.
La fragmentación de la Figura 4.18 es una simple partición unidimensional. Este estilo es
generalmente llamado carriles de nado, por razones obvias, y fue el único formato usado en UML
1.x. En UML 2, pueden usar una red bidimensional, de modo que el sentido metafórico del carril
de nado se pierde. También se puede tomar cada dimensión y dividir las filas y las columnas
jerárquicamente.
Fuente: Fowler (2003)
Figura 4.18
Ejemplo de particiones en un diagrama de actividades
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
FinanzasCumplimiento Servicio al Cliente
Llenar
orden
Entregar
orden
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
FinanzasCumplimiento Servicio al Cliente
Llenar
orden
Entregar
orden
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
FinanzasCumplimiento Servicio al Cliente
Llenar
orden
Entregar
orden
Llenar
orden
Entregar
orden
153
4.3.2. Diagramas de casos de uso
Un diagrama de casos de Uso muestra la relación entre los actores y los casos de uso del sistema.
Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Un
caso del uso especifica el comportamiento de un sistema o de una parte de este y describe las
secuencias de las acciones
Booch (2002) afirma que los diagramas de casos de uso se pueden utilizar para representar el
comportamiento deseado de un sistema, sin la necesidad de especificar cómo este
comportamiento se pone en ejecución. Los diagramas de casos de uso proveen una manera que
los desarrolladores, los especialistas finales del dominio y los usuarios tienen una comprensión
común del problema. Un caso de uso representa un requisito funcional del sistema en su totalidad.
Los diagramas de casos describe un conjunto de secuencias, cada una representa una interacción
de los actores externos. Este comportamiento, en la realidad son funciones utilizadas a nivel de
sistema para visualizar, especificar, construir y colocar el comportamiento previsto del sistema
durante el análisis de requisitos.
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son actores, casos de uso y
relaciones entre casos de uso.
Actores: un actor es una entidad externa al sistema que realiza algún tipo de interacción
con el mismo. Se representa mediante una figura humana dibujada con líneas. Esta
representación sirve tanto para actores que son personas como para otro tipo de actores
(otros sistemas, sensores, etc.).
Casos de uso: un caso de uso es una descripción de la secuencia de interacciones que se
producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una
tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el
Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su
interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea
llevar a cabo usando el sistema.
154
Relaciones en un diagrama de casos de uso:
Las relaciones que se dan en un diagrama de casos de uso son de asociación, generalización y
dependencia, en la figura 4.19 se muestra su notación.
Asociación: es la partición de un actor en un caso de uso, la instancia de un actor se comunican
con instancias de un caso de uso
Generalización: Relación taxonómica entre un caso de uso más general y otro más específico
(también entre actores)
Dependencia:
<<extend>>: Relación que define un curso alterno opcional (dependiendo de una
condición) de otro caso de uso
<<include>>: Relación que define una instancia de un caso de uso como un curso
obligatorio en otro caso de uso.
Figura 4.19
Relaciones en un diagrama de casos de uso
Asociación
Generalización
Dependencia <<extend>>
<<include>>
Fuente: Fowler (2003)
Como se puede observar en la Figura 4.20 un diagrama de casos de uso se puede representar
como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la
caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que
participa mediante una línea.
155
Fuente: Fowler (2003)
4.3.3. Diagrama de máquina de estado
Un diagrama de estados muestra la secuencia de estados por los que pasa un caso de uso o un
objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles
son las respuestas y acciones que genera. La Figura 4.21 muestra su representación, un diagrama
de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones
etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada
con el nombre del estado en su interior. Una transición se representa como una flecha desde el
estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el
primer compartimiento aparece el nombre del estado. El segundo compartimiento es opcional, y
en él pueden aparecer acciones de entrada, de salida y acciones internas.
Figura 4.20
Ejemplo de un diagrama de casos de uso
156
Fuente: Fowler (2003)
Una acción de entrada aparece en la forma entrada/acción asociada donde acción asociada es el
nombre que se le da a la acción que realiza al entrar en ese estado. Cada vez que se entra al
estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece
en la forma salida/acción asociada. Cada vez que sale del estado por una transición de salida la
acción de salida se ejecuta.
Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese
estado, pero que no causa una transición a otro estado. Se indica en la forma nombre de
evento/acción asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay
un estado inicial de creación y un estado final de destrucción (del caso de uso o del objeto). El
estado inicial se representa con un círculo sólido y el estado final como un círculo sólido rodeado
de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no
puede permanecer en esos estados, pero nos sirven para saber cuál es la transición inicial y
final(es).
Figura 4.21
Ejemplo de un diagrama de estado
157
4.3.4. Diagramas de interacción
Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo
que conlleva a modelar instancias concretas o prototipos de clases, interfaces, componentes y
nodos, junto con los mensajes enviados entre ellos, y todo en el contexto de un escenario que
ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de
objetos colaboran para proveer un comportamiento. Mientras que un diagrama de casos de uso
presenta una visión externa del sistema, la funcionalidad de dichos casos de uso se recoge como
un flujo de eventos utilizando para ello interacciones entre sociedades de objetos.
Cada caso de uso es una composición de escenarios primarios (flujo normal del caso de uso) y
secundarios (flujos excepcionales y alternativos). Por tanto, para un caso de uso podemos definir
diferentes instancias (escenarios) que nos ayudan a la identificación de objetos, clases e
interacciones entre objetos necesarios para llevar a cabo la parte de funcionalidad que especifica
el caso de uso. Los escenarios documentan el reparto de las responsabilidades que se especifican
en el caso de uso.
El flujo de eventos de un caso de uso puede recogerse en una especificación texto acompañada de
distintos escenarios especificados mediante diagramas de interacción, donde cada diagrama será
una visión gráfica de un escenario. Existen cuatro (4) tipos de diagramas de interacción:
1. Diagrama de secuencia
Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia
temporal. La Figura 4.22 muestra los objetos que se encuentran en el escenario y la secuencia de
mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el
escenario. En aplicaciones grandes además de los objetos se muestran también los componentes y
los de casos de uso. En este sentido mostrar los componentes tiene sentido ya que se trata de
objetos reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como
objetos cuyo rol es encapsular lo definido en el caso de uso.
158
Fuente: Fowler (2003)
Para mostrar la interacción con el usuario o con otro sistema se introducen en los diagramas de
secuencia las boundary classes. En las primeras fases de diseño el propósito de introducir estas
clases es capturar y documentar los requisitos de interfaz, pero no el mostrar como se va a
implementar dicha interfaz.
Los diagramas de secuencia, también llamados diagramas de traza de eventos o de interacción de
objetos, se utilizan con frecuencia para validar los casos de uso. Documentan el diseño desde el
punto de vista de los casos de uso, observando qué mensajes se envían a los objetos,
componentes o casos de uso y viendo cuánto tiempo consume el método invocado. Los
diagramas de secuencia nos ayudan a comprender los cuellos de botella potenciales, para así
poder eliminarlos. A la hora de documentar un diagrama de secuencia resulta importante
mantener los enlaces de los mensajes a los métodos apropiados del diagrama de clases. Los
conceptos más importantes relacionados con los diagramas de secuencia son:
Línea de vida de un objeto (lifeline): La línea de vida de un objeto representa la vida del
objeto durante la interacción. En un diagrama de secuencia un objeto se representa como
Figura 4.22
Ejemplo de un diagrama de secuencias
159
una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de
la línea principal que denotan la ejecución de métodos (activación). El rectángulo de
encabezado contiene el nombre del objeto y el de su clase, en un formato nombreObjeto:
nombreClase.
Activación: Muestra el período de tiempo en el cual el objeto se encuentra desarrollando
alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus
atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.
Mensaje: El envío de mensajes entre objetos se denota mediante una línea sólida dirigida,
desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Tiempos de transición: En un entorno de objetos concurrentes o de demoras en la
recepción de mensajes, es útil agregar nombres a los tiempos de salida y llegada de
mensajes.
Caminos alternativos de ejecución y concurrencia: En algunos casos sencillos los
caminos alternativos pueden expresarse en un diagrama de secuencias alternativas de
ejecución. Estas alternativas pueden representar condiciones en la ejecución o diferentes
hilos de ejecución (threads).
Destrucción de un objeto: Se representa como una X al final de la línea de ejecución del
objeto.
Métodos recursivos: Es un rectángulo adyacente a la activación principal y con líneas de
llamada de mensajes, que indican la entrada y salida de la recursión.
2. Diagrama de colaboración
Un diagrama de colaboración es una forma alternativa de mostrar el escenario que se da en un
diagrama de secuencia. Este tipo de diagrama muestra las interacciones entre objetos organizadas
entorno a los objetos y los enlaces entre ellos.
160
Los diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal
(qué pasa primero, qué pasa después). Los clientes entienden fácilmente este tipo de diagramas,
por lo que resultan útiles en las primeras fases de análisis. Por el contrario los diagramas de
colaboración como se muestra en la Figura 4.23 proporcionan la representación principal de un
escenario, ya que las colaboraciones se organizan entorno a los enlaces de unos objetos con otros.
Este tipo de diagramas se utilizan más frecuentemente en la fase de diseño, es decir, cuando se
diseña la implementación de las relaciones.
Fuente: Fowler (2003)
A diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en
el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de
colaboración. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por
esto que los diagramas de colaboración se deben crear en paralelo con los diagramas de clases.
Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboración
numerando los mensajes, aunque esto no se suele hacer, ya que para este propósito son mejores
los diagramas de secuencia.
A continuación se enumeran los conceptos fundamentales de un diagrama de colaboración:
Objeto: Se representa con un rectángulo que contiene el nombre y la clase del objeto en
un formato nombreObjeto: nombreClase.
Figura 4.23
Ejemplo de un diagrama de colaboración
161
Enlaces: Un enlace es una instancia de una asociación en un diagrama de clases. Se
representa como una línea continua que une a dos objetos, acompañada por un número
que indica el orden dentro de la interacción. Pueden darse varios niveles de subíndices
para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el
objeto que recibe el mensaje es un atributo, un parámetro de un mensaje anterior, si es un
objeto local o global.
Flujo de mensajes: Expresa el envío de un mensaje. Se representa mediante una flecha
dirigida cerca de un enlace.
Marcadores de creación y destrucción de objetos: Puede mostrarse en la gráfica qué
objetos son creados y destruidos, agregando una restricción con la palabra new o delete
respectivamente.
Objeto compuesto: Es una representación alternativa de un objeto y sus atributos. En
esta representación se muestran los objetos contenidos dentro del rectángulo que
representa al objeto que los contiene.
Patrón de diseño: Un diagrama de colaboración puede especificar un contrato entre
objetos, parte esencial para la descripción de un patrón de diseño. Este diagrama contiene
todos los elementos citados de un diagrama de colaboración, dejando libres posiblemente
los tipos exactos de algunos objetos o con nombres genéricos para los mensajes. Una
“instanciación” del patrón se representa como una elipse unida mediante flechas
punteadas a los objetos o clases que participan realmente en el patrón. Estas flechas
pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón.
Contexto: Un contexto es una vista de uno o más elementos dentro del modelo que
colaboran en el desarrollo de una acción. Se usa para separar los demás elementos en el
modelo de este problema en particular y darle énfasis. Puede mostrar sólo los detalles
relevantes de las clases u objetos que contiene, para resaltar su utilidad.
Objeto activo: Un objeto activo es el que contiene su propio flujo de control, a diferencia
de un objeto pasivo que encapsula datos y sólo reacciona al enviarle mensajes. Un objeto
activo se representa con un rectángulo de bordes gruesos. Puede contener otros objetos
pasivos o activos.
162
3. Diagramas de visualización de interacción
Los diagramas de visualización de interacción han sido incorporados en la versión 2.0 de UML.
Son la combinación gráfica de los diagramas de actividad con los de secuencia. Pueden
concebirse como diagramas de actividad en los cuales las actividades son reemplazadas por
pequeños diagramas de secuencia, o bien como diagramas de secuencia unidos mediante la
notación de los diagramas de actividad empleada para representar el control de flujo en el sistema
(Fowler03b), en la Figura 4.24 se muestra un ejemplo de este tipo de diagrama.
Fuente: Fowler (2003)
Dada su reciente aparición, aún no está clara la efectividad del alcance de estos diagramas en
aplicaciones reales.
Figura 4.24
Ejemplo de un diagrama de visualización de interacción
163
4. Diagramas de tiempo
Los diagramas de tiempo (Ver Figura 4.25) han sido incorporados a UML como una nuevo tipo
de diagrama de interacción, donde el elemento principal son las restricciones de tiempo. Son muy
útiles para representar restricciones temporales que afectan a cambios de estado de diferentes
objetos. Este tipo de diagrama se ha heredado de ámbitos relacionados con sistemas electrónicos
(microprocesadores, microcontroladores, etc.).
Fuente: Fowler (2003)
Figura 4.25
Ejemplo de un diagrama de tiempo
Análisis de los
Resultados
CAPITULO
Análisis de los Resultados
Diferencias y Semejanzas
El siguiente capítulo tiene como propósito hacer un análisis comparativo entre las diferencias y
semejazas que existen en UML con respecto a la programación estructurada y los métodos OO.
Para realizar este análisis se parte de los “bloques de construcción” que componen a UML, estos
son: sus elementos, relaciones y diagramas; de manera que se logra comparar los bloques de
construcción que se dan en UML con los que han surgido tanto en la programación estructurada
como en los métodos OO.
5.1. Análisis comparativo entre los elementos de UML y los de programación
estructurada y los métodos OO.
5.1.1. Elementos básicos en la programación estructurada
Tipos de Datos Primitivos
Palabras Reservadas
Variables
Constantes
Expresiones
Jerarquía de Operadores
Operadores Aritméticos
Operadores Relacionales
Operadores Lógicos o Booleanos (and, or, not, xor)
Estructuras de Control
166
Elementos estructurales de un módulo:
InterfazDatos de entrada
Datos de salida
Descripción funcionalidad
Implementación
Datos locales
Secuencia de instrucciones
Sintaxis del lenguaje:
Organización del código en bloques de instrucciones, se definen las funciones y los
procedimientos.
Extensión del lenguaje con nuevas operaciones y llamadas a nuevas funciones y
procedimientos
5.1.2. Elementos en los métodos OO
En los métodos OO las propiedades estáticas de los objetos se representan mediante elementos
estructurales, es decir, las entidades abstractas, las relaciones entre ellas, y otros elementos
complementarios. Y las propiedades dinámicas, que expresan el comportamiento de los elementos
estructurales y del sistema global, se representan mediante elementos dinámicos, como estados,
actividades, interacciones y las construcciones que los agrupan. A continuación se describen los
elementos más importantes nombrados por Castells (2002):
Objetos: atributos y métodos
Métodos: operaciones sobre los objetos
Clases: categorías de objetos con propiedades y operaciones comunes
Jerarquías de clases
En algunos lenguajes las clases son objetos, en otros no
Relaciones, objetos compuestos
167
5.1.3. Elementos en UML
Los elementos en UML se dividen en estructurales, de comportamiento, de agrupamiento y de
anotación.
Elementos estructurales: son aquellos elementos que pertenecen a la parte estática de un modelo,
representan partes materiales o conceptuales del sistema. Los elementos estructurales principales
de UML son la clase, la interfaz, la colaboración, el caso de uso, los componentes y los nodos.
Casos de uso: Describe un conjunto de secuencias de
acciones que un sistema ejecuta, para producir un
resultado observable de interés. Se emplea para
estructurar los aspectos de comportamiento de un
modelo.
Actor: Es algo o alguien que puede interaccionar con el
sistema que se está desarrollando
Clases: Describe un conjunto de objetos que comparten
los mismos atributos, métodos, relaciones y semántica.
Las clases implementan una o más interfaces.
Interfaces: Agrupación de métodos u operaciones que
especifican un servicio de una clase o componente,
describiendo su comportamiento, completo o parcial,
externamente visible. UML permite emplear un círculo
para representar las interfaces, aunque lo más normal es
emplear la clase con el nombre en cursiva.
Colaboraciones: Define una interacción entre
elementos que cooperan para proporcionar un
comportamiento mayor que la suma de los
comportamientos de sus elementos.
Componentes: Parte física y por tanto reemplazable de
un modelo, que agrupa un conjunto de interfaces,
archivos de código fuente, clases, colaboraciones y
proporciona la implementación de dichos elementos.
Nodos: Elemento físico que existe en tiempo de
ejecución y representa un recurso computacional con
capacidad de procesar.
168
Elementos de comportamiento: son aquellos elementos que pertenecen a la parte dinámica de un
modelo. Los elementos de comportamiento básico son las interacciones (que comprende un
conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto
particular, para alcanzar un propósito específico) y la máquina de estados (que especifica las
secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a
eventos, junto con sus reacciones a estos eventos).
Interacción: Conjunto de mensajes
intercambiados entre un conjunto de objetos
con un propósito particular.
de objetos con un propósito particular.
Máquina de estado: Secuencia de estados por
las que pasa un objeto durante su vida en
respuesta a eventos.
Elementos de agrupamiento: son aquellos elementos que pertenecen a la parte de organización
de los modelos de UML. Los elementos de agrupación de UML son los paquetes, y sirven para
organizar otros elementos de los modelos UML (pudiendo incluir incluso otros paquetes). Un
paquete es un mecanismo conceptual de propósito general para organizar elementos en grupos.
Por ejemplo, se pueden incluir en un paquete varias clases y luego asignar ese paquete a un
componente (con lo que, realmente, lo que estamos asignado al componente son todas las clases
que el paquete incluye). Gráficamente, un paquete se visualiza como una carpeta, incluyendo su
nombre y, a veces, su contenido.
Paquete, modelo y subsistema: Se
emplea para organizar otros elementos en
grupos.
Elementos de anotación: son aquellos elementos que pertenecen a la parte explicita de los
modelos UML. Son comentarios que se pueden aplicar para describir, clarificar o hacer
observaciones sobre cualquier elemento de un modelo. Aunque la mayoría de herramientas del
tipo Racional Rose permiten añadir un texto (o incluso un fichero o una dirección web)
comentando o documentando cada elemento, con las anotaciones este texto se ve de forma
explícita en el diagrama, de forma que resalta a primera vista.
169
Nota: Partes explicativa de UML, que puede describir
textualmente cualquier aspecto del modelo de objetos con
un propósito particular.
5.1.4. Análisis comparativo entre los elementos de UML y los de programación estructura y los
métodos OO.
Los elementos básicos que se presentan en el desarrollo estructural son de tipo condicional que
cambian según los requerimientos del sistema, se analizan los problemas mediante los diagramas
de flujo de datos, para luego programar una solución, es decir se desarrolla el sistema haciendo
uso de los datos, el diagrama de entidad relación se utiliza para el desarrollo básicamente de las
bases de datos. Se puede decir que en el desarrollo estructural lo que varía más que todo son las
diferentes notaciones que se presentan para diseñar los diagramas de flujo de datos donde tres
autores proponen notaciones distintas, pero igual significan lo mismo.
Los elementos que se presentan en los métodos orientados a objetos lo hacen con la finalidad de
representar objetos y sus clases utilizando diversos diagramas, unos más completos que otros.
Algunas estructuras se adaptan tanto a procesos estáticos como dinámicos como es el ejemplo de
la metodología OMT, hay otros métodos que sólo son estáticos, a decir verdad existe mucha
variedad y opiniones encontradas en cuanto a qué diagrama usar para desarrollar software.
Los elementos estructurales que se presentan en UML son heredados de los elementos
estructurales utilizados en los métodos orientados a objetos, estos se mantienen constantes en el
tiempo, desde que UML fue adoptado en noviembre de 1997 por la OMG como una de sus
especificaciones se ha convertido en un estándar que sirve para visualizar, especificar, construir y
documentar los modelos que se crean durante la aplicación de un proceso de software. Estas
estructuras varían muy poco con las versiones de UML, y las nuevas versiones que van surgiendo
lo hacen con el objetivo de mejorar lo anterior. Entre las fortalezas de UML se encuentra que los
elementos estructurales que manejan sirven para modelar tanto procesos estáticos como
dinámicos.
170
5.2. Análisis comparativo entre las relaciones de UML y las relaciones de la
programación estructurada y los métodos OO.
5.2.1. Relaciones existentes en el desarrollo estructurado
Básicamente las relaciones que se dan en los diagramas que se presentan en el desarrollo
estructurado son los “flujos de datos” que llevan información de un lado a otro y están
representados por medio de una flecha.
En los Diagramas de Flujo de Datos (DFD) los flujos de información están representados
gráficamente por medio de una flecha que entran o salen de un proceso. Este flujo se usa para
describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por
ello, los flujos representan datos en movimiento, la flecha indica la dirección de la información,
representarán datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos
tipos de información con los que las computadoras pueden tratar.
Los flujos de datos llevan nombres que representan el significado del paquete que se mueve a lo
largo del flujo, también llevan una dirección: una cabeza de flecha en cualquier extremo (o
posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o
hacia afuera de un proceso (o ambas cosas).
Tipos de Flujos de Datos que se dan en un DFD:
Flujo de consulta: Muestra la utilización de la información del almacén por el proceso
para utilizar los valores de uno o más atributos de una ocurrencia y comprobar si los
atributos seleccionados cumplen unas condiciones, su representación se muestra en la
Figura 5.1 (a).
Flujo de actualización: Indica que el proceso va a alterar la información mantenida en el
almacén para: crear una nueva ocurrencia en el almacén, borrar una o más ocurrencias y
modificar el valor de un atributo, su representación se muestra en la Figura 5.1 (b).
Flujo de diálogo: Representa un flujo de consulta y un flujo de actualización que no
tienen relación directa, su representación se muestra en la Figura 5.1 (c).
171
Flujo de consulta (a) Flujo de actualización (b) Flujo de dialogo (c)
Fuente: Yourdon (1989)
En los Diagramas de Estructura de Datos (DED) las relaciones que se dan entre los módulos se
representan por medio de invocaciones.
Los diagramas de estructura de datos muestran las invocaciones que un módulo hace a otros
módulos. Estas invocaciones son diseñadas como una flecha que sale del módulo llamador y
apunta al módulo llamado en la Figura 5.2, se muestra un ejemplo:
Fuente: Yourdon y Constantine (1978)
En el ejemplo de la Figura 5.2 el módulo A invoca (o llama) a los módulos B, C y D. La
interpretación de las invocaciones provee información de la estructura interna del módulo
llamador. Los diagramas de estructura no tienen especificado el orden de invocación de los
módulos invocados. El orden de la figura de los módulos B, C, y D (de izquierda a derecha) no
debe ser interpretado como el orden de invocaciones ejecutado por el módulo A. Una invocación,
representa la idea de invocación a funciones o procedimientos en los lenguajes de programación
Figura 5.1
Diferentes flujos de datos
A
B C D
Modulo Llamador
Invocación
Modulo Llamado
A
B C D
Modulo Llamador
Invocación
Modulo Llamado
Figura 5.2
Ejemplo de invocaciones
172
convencionales. En un diagrama de estructura de datos se pueden modelar varios tipos de
invocaciones, en el Cuadro 5.1 se explican y se representan gráficamente:
Cuadro 5.1
Tipos de invocaciones
Invocación
Estándar
El módulo A invoca al módulo B con la semántica de invocación
de procedimientos o funciones en los lenguajes de programación
convencionales (C, Pascal, etc.).
Invocación
Concurrente
El módulo A comienza dos tareas concurrentes, B y C.
Invocación
Co-rutina
El módulo A invoca al módulo B con una semántica de
transferencia de control al punto de entrada de una co-rutina.
Transferencia
de Control
El módulo A hace una transferencia de control al interior del
módulo B.
Transferencia
de Datos
El módulo A hace referencia a un área de datos local del módulo B.
Fuente: Yourdon y Constantine (1978)
Comunicación entre módulos (cuplas)
Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, comúnmente
un conjunto de argumentos es comunicado y, en el caso de las funciones, también se espera que
retorne un resultado. Estos datos comunicados en una invocación son modelados por medio de
flechas, sobre el símbolo de invocación, llamadas cuplas, en la Figura 5.3 se muestra un ejemplo.
A
B
A
B C
B
A
B
A
A BA B
A
B C D
Cúpula de Datos
Cúpula sin tipo
(o de datos o de
control o hibrida)
Z
X
YZ W
F
H
Cúpula Modificada
Cúpula de control
flag
Cúpula Hibrida
(datos y control)
A
B C D
Cúpula de Datos
Cúpula sin tipo
(o de datos o de
control o hibrida)
Z
X
YZ W
F
H
Cúpula Modificada
Cúpula de control
flag
Cúpula Hibrida
(datos y control)
Figura 5.3
Ejemplos de invocaciones con cuplas
Fuente: Yourdon y Constantine (1978)
173
Como se muestra en el Cuadro 5.2, existen varios tipos de cuplas, basado en lo que ellas pueden
producir en el módulo receptor, las cuales se describen a continuación:
Cuadro5.2
Tipos de cuplas
Cupla de
Datos
Una cupla de datos transporta datos “puros” a un módulo. No es necesario
conocer la lógica interna del módulo receptor, para determinar los valores
válidos de la cupla (ej.: número de cuenta, saldo, tabla de movimientos).
Cupla
Modificada
Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se
especifica un argumento enviado a un módulo que deberá modificar su valor,
fijando un nuevo valor disponible para el módulo llamador (en la
implementación, se precisará que el lenguaje posea un mecanismo de pasaje de
parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un
archivo).
Cupla de
Control
Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se
especifica un argumento enviado a un módulo que deberá modificar su valor,
fijando un nuevo valor disponible para el módulo llamador (en la
implementación, se precisará que el lenguaje posea un mecanismo de pasaje de
parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un
archivo).
Cupla
Híbrida
Una cupla que para algunos módulos transporta datos “puros” y para otros
transporta un flag de control es denominada cupla híbrida. Esta cupla
representa un híbrido entre una cupla de datos y una cupla de control. La
identificación de ellas depende de la lógica definida por el algoritmo de
implementación del módulo invocado.
Cupla sin
Tipo
Se utiliza para representar que hasta el momento no esta definida o se tienen
dudas con respecto a la interpretación que el módulo invocado hace de ella.
Fuente: Yourdon y Constantine (1978)
En los Diagramas de Transición de Estado (DTE) no existe una relación como tal, ya que en
estos diagramas se muestran los cambios de estados, que se representan por medio de flechas.
En el Modelo relacional las relaciones se representan mediante tablas, formadas por sus
columnas y filas que contienen cardinalidad, atributos, claves, entidades, dominio, tuplas y grado.
En los Diagramas de Entidad Relación (DER) las relaciones se representan mediante
asociaciones entre entidades. Puede haber más de una relación entre dos entidades. Es el
elemento del modelo que permite relacionar en sí los datos del modelo. Por ejemplo, en la Figura
5.4 se muestra una entidad personas y otra entidad trabajos. Ambas se realizan ya que las
personas trabajan y los trabajos son realizados por personas:
174
Fuente: Yourdon (1989)
La representación gráfica de las relaciones se realiza con un rombo (Ver Figura 5.5) al que se le
unen líneas que se dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo).
En el ejemplo anterior podría usarse como nombre de relación, trabajar:
Fuente: Chen (1976)
Grado de relación: es el número de entidades que pueden participar en una relación, pueden ser:
unitarias (misma entidad), binarias (2 entidades) y n-arias (N entidades).
Cardinalidad de las relaciones: La cardinalidad expresa cuántas del conjunto de entidades de un
extremo de la relación están relacionadas con cuántas entidades del conjunto del otro extremo.
Estas pueden ser de “una a una” (1:1), de “una a muchas” (1:N), de “muchas a una” (N:1). y de
“muchas a muchas” (N:N). Se anota en términos de:
Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá
cada ejemplar de la entidad (el valor que se anota es de cero o uno)
Figura 5.4
Ejemplo de relación (a)
Figura 5.5
Ejemplo de relación (b)
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Fontanero
Electricista
Peluquero
Administrativo
Personas Trabajos
Pedro
Ana
José
Maria
Consuelo
Jaime
Lourdes
Fontanero
Electricista
Peluquero
Administrativo
Personas Trabajos
Personas Trabajar TrabajosPersonas Trabajar Trabajos
175
Cardinalidad máxima. Indica el número máximo de relaciones en las que puede
aparecer cada ejemplar de la entidad (puede ser uno o muchos)
Roles de las relaciones: A veces en las líneas de la relación se indican roles. Estos roles
representan el papel que juega una entidad en una determinada relación. Un ejemplo de esto se
muestra en la Figura 5.6.
Fuente: Yourdon (1989)
Síntesis
Diagramas Tipos de relaciones
Diagrama de Flujo de Datos Flujo de Datos. Se representan mediante
flechas
Diagrama de Estructura de Datos Llamadas a Invocaciones. Se
representan mediante flechas
Diagrama de Transición de Estado Flechas que Representan los Cambios de
Estado
Modelo Relacional Se representa utilizando relaciones, que
contienen cardinalidad, atributos, claves,
entidades, dominio, tuplas y grado
Diagrama de Entidad Relación Asociaciones. Se representan mediante
rombos
5.2.2. Relaciones existentes en los métodos OO
Las relaciones que se analizan en este apartado son las que más influyeron en UML como son la
notación de OMT y la de Booch.
Figura 5.6
Ejemplo de roles de las relaciones
Trabajador Trabaja
Empleado
Jefe
Trabajador Trabaja
Empleado
Jefe
176
Relaciones entre clases y objetos según la notación de Rumbaugh (OMT)
Las relaciones que se dan entre clases y los objetos son de asociación, agregación, generalización
y herencia.
Enlaces y asociaciones
Los enlaces y asociaciones en la metodología OMT son los medios para establecer relaciones
entre objetos y clases. Un enlace (Rumbaugh, 1999) es una conexión física o conceptual entre
instancias de objetos. Una asociación describe un grupo de enlaces con estructura y semántica
comunes. Las asociaciones son inherentemente bidireccionales. Las asociaciones pueden ser
binarias, ternarias (Ver Figura 5.7) o de órdenes superiores y los nombres de las asociaciones son
opcionales en la notación (se escriben en cursiva). El nombre de una asociación binaria suele
leerse en un solo sentido. Cada asociación en el diagrama de clase corresponde a un conjunto de
enlaces en el diagrama de instancias. Los nombres de las asociaciones (o de los enlaces) se
escriben en cursivas y comienza con mayúsculas como se muestra en la Figura 5.7.
Fuente: Vallejos (2001)
Multiplicidad
La multiplicidad especifica la cantidad de instancias que pueden estar relacionadas con una única
instancia de una clase asociada. Limita el número de objetos relacionados. Según la notación
Figura 5.7
Ejemplo de enlaces y asociaciones
177
OMT, se puede especificar multiplicidad mediante un número entero positivo o mediante un
conjunto de intervalos. Por ejemplo: “1”, “1+”, “3-5”, “2, 8, 15”. Existen terminadores especiales
que indican ciertos valores frecuentes de multiplicidad.
Un círculo negro indica multiplicidad de “muchos”, es decir cero o más. Un círculo blanco
denota “opcional”, es decir cero o uno. Cuando una asociación no tiene terminadores ni valores
de multiplicidad se asume uno a uno, en la Figura 5.8 se muestran todos los tipos de multiplicidad
que se dan en la notación OMT.
Fuente: Vallejos (2001)
En la Figura 5.9 se presenta un ejemplo de multiplicidad en un diagrama de clases:
Fuente: Vallejos (2001)
Figura 5.9
Ejemplo de multiplicidad en un diagrama de clases
Figura 5.8
Representación de la multiplicidad en OMT
178
Los atributos de un enlace
Son propiedades de los enlaces de una asociación. Todo atributo de enlace tiene un valor para
cada enlace. La notación OMT para un atributo de enlace es un cuadro de diálogo ligado a la
asociación mediante un lazo, en la Figura 5.10 se muestra un ejemplo de esto, tanto en un
diagrama de clases como de objetos o instancias.
Fuente: Vallejos (2001)
Asociación como una clase
En algunas ocasiones resulta adecuado modelar las asociaciones como clase. Es útil modelar las
asociaciones como clases cuando los enlaces pueden participar en asociaciones con otros objetos
o cuando están sometidos a operaciones. Un ejemplo de esto se puede observar en la Figura 5.11.
Fuente: Vallejos (2001)
Figura 5.10
Ejemplo de atributo en un enlace
Figura 5.11
Ejemplo de una asociación como una clase
179
Rol de una asociación
Los roles se colocan en uno de los extremos de una asociación. Una asociación binaria posee dos
roles (Ver Figura 5.2), cada uno de los cuales se puede identificar con un nombre de rol. El
nombre de rol es un atributo derivado cuyo valor es un conjunto de objetos relacionados. Los
roles suelen aparecer como sustantivos en las descripciones de un problema.
Fuente: Vallejos (2001)
Los nombre de roles son necesarios para asociaciones entre dos objetos de la misma clase.
También son útiles para distinguir dos asociaciones entre un mismo par de clases.
Cualificación
Una asociación cualificada o calificada relaciona dos clases de objetos y un calificador. El
calificador es un atributo especial que reduce la multiplicidad efectiva de una asociación. Una
asociación cualificada también puede considerarse como una forma de relación ternaria. La
cualificación mejora la precisión semántica e incrementa la visibilidad de las vías de navegación.
En la Figura 5.13 se puede observar un ejemplo de esta asociación.
Fuente: Vallejos (2001)
Figura 5.13
Ejemplo de una asociación calificada
Figura 5.12
Ejemplo de un rol en una asociación
180
Agregación
Rumbaugh (1999) afirma que una agregación representa la relación “parte-todo” o “una parte de”
en la cual los objetos componentes de algo se asocian a un objeto que representa el ensamblaje
completo. La agregación es una forma fuertemente acoplada de asociación, con semántica
adicional. Propiedades de la agregación: transitividad, antisimetría. La existencia de una parte
puede o no depender de la existencia del todo. Se representa por medio de una asociación que en
su extremo posee un rombo en blanco (superclase), en la Figura 5.14 se muestra un ejemplo de su
representación.
Fuente: Vallejos (2001)
Generalización y herencia
La generalización y la herencia son mecanismos de abstracciones que sirven para compartir
similitudes entre las clases mientras estas preservan sus diferencias.
La generalización en OMT es una relación entre una clase (superclase) y una o más clases
(subclases) las cuales son refinamientos o especializaciones de la misma. Los atributos y las
operaciones comunes de un grupo de clases son vinculados a una superclase. Cada subclases se
dice que hereda las características de una superclase. La generalización es llamada “relación es-
uno/a”, debido a que cada instancia de una subclase es una instancia de la superclase también. En
la Figura 5.15 se puede observar un ejemplo de las superclase y las subclases.
Figura 5.14
Ejemplo de una relación de agregación
181
Fuente: Vallejos (2001)
La generalización y la herencia son relaciones transitivas. Una instancia de una clase es
simultáneamente una instancia de sus “ancestros”. El estado de una instancia incluye un valor
para cada uno de los atributos de sus ancestros, y cualquier operación de un ancestro puede ser
solicitada a la instancia. Cada subclase no sólo hereda las características de sus ancestros, sino
que puede agregar sus propios atributos y operaciones.
En la generalización, algunas veces se hace uso de un discriminador que funciona como un
atributo de tipo enumerado que indica que propiedad de un objeto está siendo abstraída por una
relación de generalización. El discriminador es simplemente un nombre para la base de la
generalización.
Usos de la generalización y la herencia
La generalización es un mecanismo utilizado tanto en el modelamiento como en la
implementación. La generalización facilita el modelado mediante el estructurado de clases, a
través de la abstracción de las características comunes y diferentes de las clases. La herencia es
un mecanismo de definición en la implementación, posibilitando el reuso de código.
Para concluir se puede decir que la generalización y especificación se refiere a la relación entre
clases. La generalización indica que una superclase generaliza las subclases y la especificación:
se refiere al refinamiento de una superclase en una subclase, la herencia, se refiere a un
mecanismo para compartir atributos y operaciones.
Figura 5.15
Ejemplo de superclases y subclases
182
Diferencias entre agregación y generalización
Una agregación es una relación entre instancias en donde están implicados dos objetos diferentes
de modo que uno es parte del otro. La generalización en una relación entre clases, y es una forma
de estructurar la descripción de un objeto único. Mediante la generalización un objeto es, a la vez,
una instancia de la superclase y una instancia de la subclase.
Tipos de agregación:
Una agregación puede ser:
Simple o Fija: el número y tipo de componentes esta predeterminado.
Variable: número finito de niveles, pero el número de partes puede variar.
Recursiva: una agregación puede tener, directa o indirectamente, una instancia de la
misma clase agregada como parte.
Los diferentes tipos de agregación se muestran en la Figura 5.16.
Fuente: Vallejos (2001)
Relaciones entre clases y objetos según la notación de Booch
Las relaciones más usadas en la notación Booch son: agregación, asociación, uso y la herencia.
Figura 5.16
Ejemplo de los tipos de agregación
183
Agregación
Denota una relación todo/parte (relación “tiene un” o agregación), aparece como una asociación
con un círculo relleno en el extremo que señala al agregado, la clase que está en el otro extremo
denota la parte cuyas instancias están contenidas por el objeto agregado, su representación gráfica
se puede ver en la Figura 5.17 (a).
Cuando la clase contenida no existe independientemente (Macías del Campo, 2006) de la clase
que la contiene se denomina agregación por valor (Ver Figura 5.17 b) y además implica
contenido físico, mientras que si existe independientemente y se accede a ella indirectamente, es
agregación por referencia (Ver Figura 5.17 c).
Agregación (a) Agregación por valor (b) Agregación por referencia (c)
Fuente: Cruzado (2006)
Asociación
Conecta dos clases y denota una conexión semántica, se etiquetan con expresiones sustantivas,
denotando la naturaleza de la relación. Las asociaciones se pueden etiquetar con un nombre o
frase, su representación se puede ver en la Figura 5.18 (a). Una clase puede asociarse consigo
misma, lo cual se denomina asociación reflexiva. La cardinalidad o multiplicidad especifica el
número de asociaciones entre dos clases. Si no se indica se considera sin especificar
– 1 (exactamente uno)
– N (cero o más)
– 1..N (uno o más)
– 3..7 (rango especificado)
– 7 (número exacto)
Figura 5.17
Representación grafica de las agregaciones
184
Uso o utilización
Los objetos de una clase usan servicios de objetos de otra clase. Denota una relación
cliente/servidor y aparece como una asociación con una circunferencia en el extremo que denota
al cliente. En esta relación de alguna forma el cliente depende del servidor para que éste le
proporcione determinados servicios. Su representación se puede ver en la Figura 5.18 (b).
Herencia
Para Booch (1996) la herencia es una relación entre clases, en la que una clase comparte la
estructura o comportamiento definido en otra (herencia simple) u otras (herencia múltiples)
clases. La herencia representa una jerarquía de abstracciones donde una subclase hereda de una o
más superclases. La subclase hereda la estructura y comportamiento de su superclase. Las
relaciones de herencia no pueden llevar indicaciones de cardinalidad. La notación consiste en una
flecha que apunta de la subclase a la superclase, como se observa en la Figura 5.18 (c).
Asociación (a) Uso o utilización (b) Herencia (c)
Fuente: Cruzado (2006)
En la Figura 5.19 se pueden observar un diagrama de clases donde se dan las relaciones de:
asociación, herencia, agregación y uso
Otras dos (2) relaciones que no
Figura 5.19
Ejemplo de las Relaciones en un diagrama de clases
Figura 5.18
Representación grafica de las relaciones en el método Booch
Fuente: Cruzado (2006)
185
son muy populares son: instanciación y metaclase
Metaclase: es una clase cuyas instancias son a su vez clases. Su representación se puede observar
en la Figura 5.20 (a).
Instanciación (templates): se refiere al hecho de ir creando las instancias de las clases. Se usa en
lenguajes que soportan genericidad (declaración de clases parametrizadas y argumentos tipo
template). Representa las relaciones entre las clases parametrizadas, que admiten parámetros
formales, y las clases obtenidas cuando se concretan estos parámetros formales. Su
representación se puede observar en la Figura 5.20 (b).
Metaclase (a) Instanciación (templates) (b)
Fuente: Cruzado (2006)
A continuación se presenta una pequeña síntesis de los distintos diagramas con sus respectivas
relaciones.
Síntesis
Diagramas Tipos de Relaciones
Diagrama de Clases y
Objeto Notación de Rumbaugh (OMT)
Asociaciones
Agregaciones
Generalización y Herencia
Diagrama de Clase Notación de Booch
Herencia
Agregaciones
Asociación
Uso
Diagrama de Objeto Notación de Booch
Las relaciones entre los objetos se dan a través de sus
enlaces con otros objetos, representados por mensajes/valor,
rol, llave y restricciones. Un enlace es una instancia de una
asociación, al igual que un objeto es una instancia de una
clase.
Figura 5.20
Representaciones graficas de Metaclases e Instanciaciones
186
5.2.3. Relaciones Existente en UML
Relaciones entre Clases y Objetos según la notación de UML
Una relación es una conexión semántica entre elementos, en UML las relaciones que más se
utilizan son las que se aplican a las clases. Básicamente se distinguen cuatro tipos de relaciones
estáticas: asociaciones, generalizaciones, dependencia y realización.
Asociación
Es la relación estructural entre abstracciones que implican interconexiones o enlaces entre los
objetos representados por las abstracciones (instancias de clases). Las asociaciones están
compuestas por un nombre, roles, multiplicida y navegabilidad. La representación básica es una
línea enlazando las clases.
Nombre de la asociación: es un nombre descriptivo que indica la naturaleza de la asociación.
Opcionalmente se puede añadir un pequeño triángulo que indique el sentido en que se debe
interpretar.
En la Figura 5.21, se expresa que las personas trabajan para las compañías. Téngase en cuenta
que el sentido del nombre de la asociación no restringe la navegabilidad. Es posible indicar el
estereotipo de la asociación encima del nombre, siendo también posible indicar una cadena de
propiedades a la derecha del nombre o debajo.
Fuente: Pickin (2005)
Roles
Se puede indicar el rol que desempeña una o ambas clases en la asociación. Los roles describen el
papel específico que una clase juega en una asociación. Una clase puede jugar distintos roles en
diferentes asociaciones. Cada asociación tiene dos roles. Cada rol es una dirección en la relación,
Figura 5.21
Ejemplo de una relación de asociación
187
por ejemplo, si C1 está asociado con C2, la relación de C1 con C2 tiene un rol de C1 a C2 y otro
de C2 a C1 (Insfrán, 2001).
Los roles poseen un nombre (si no se indica un nombre de rol, el nombre del rol es el nombre de
la clase destino). Además un rol tiene una mutiplicidad que indica cuántos objetos pueden
participar en una relación dada (límite inferior y límite superior). Cuando el límite superior es
mayor a 1, se conoce como rol multivaluado. La convención usual es que este rol multivaluado
sea un conjunto. En el ejemplo de la Figura 5.22 se muestra un ejemplo de los roles en las
asociaciones.
Fuente: Pickin (2005)
Multiplicidad
La multiplicidad tiene por finalidad indicar cuántas instancias (objetos) de una clase podrán estar
asociadas a una instancia (objeto) de la otra. Estas pueden ser: uno (1), cero o uno (0..1), desde m
hasta n entero naturales (m..n), tres (3), muchos (*), cero a muchos (0..*), uno a muchos-al menos
uno (1..*), dos, cuatro o cinco (2,4,5). En el ejemplo de la Figura 5.23 se puede observa que de 0
a muchas compañías tiene una a muchas personas.
Fuente: Pickin (2005)
En este caso, para una compañía podrán trabajar una o más personas, y una persona podrá
trabajar en cero (que representaría el caso de estar desempleada) o más compañías.
Figura 5.22
Ejemplo de los roles en una relación de asociación
Figura 5.23
Ejemplo de multiplicidad
188
En multiplicidad se dan varios términos (Fowler, 2003), como: opcional (optional) que implica
un límite más bajo de cero, obligatorio (mandatory) que implica un límite más bajo de 1 o
posiblemente más, solo-valorado (single-valued) que implica un límite superior de 1 y
multivaluado (multivalued) que implica un límite superior de más de 1, usualmente *.
Navegabilidad
Otra propiedad de las asociaciones permite especificar la navegabilidad de la relación, esta indica
la posibilidad de ir desde el objeto fuente al objeto destino. La navegabilidad indica que los
objetos de la clase podrán hacer uso de las propiedades de los objetos de la clase relacionada en
la dirección indicada por la navegabilidad exclusivamente.
Si la navegabilidad existe sólo en un sentido se llama asociación unidireccional, y si existe en los
dos sentidos asociación bidireccional. La asociación sin navegabilidad puede considerarse como
bidireccional o no especificada. La asociación bidireccional añade la restricción de que los dos
roles son invertibles uno con otro.
Por ejemplo la asociación de la Figura 5.24 significa que la clase Compañía puede acceder a los
atributos y operaciones públicas de la clase Persona y que, de forma similar, la clase Persona
puede acceder a los atributos y operaciones públicas de la clase Compañía.
Fuente: Pickin (2005)
También se puede restringir la navegabilidad de la asociación, añadiendo una flecha que indique
el sentido de dicha asociación, en la siguiente Figura 5.25 se da un ejemplo:
Figura 5.24
Ejemplo de navegabilidad
189
Fuente: Pickin (2005)
En este caso, Compañía puede acceder a los atributos y operaciones públicas de la clase Persona,
pero Persona no puede acceder a Compañía.
Calificador
Es el particionamiento de un conjunto de objetos relacionados con otro objeto mediante un
atributo de la asociación (calificador). Dado un objeto origen y un valor determinado para el
calificador, se obtendrá un objeto destino (si la multiplicidad del destino es a lo más uno) o un
conjunto de objetos destino (si la multiplicidad del destino es muchos). Por ejemplo en la Figura
5.26 se puede observar que dado un banco y un número de cuenta, obtendremos una persona (el
titular de la cuenta). Téngase en cuenta que el calificador pertenece a la asociación y no es un
atributo ni del banco ni de la persona.
Fuente: Pickin (2005)
Es significativo el extremo de la asociación en el que se pone el calificador. Por ejemplo, si el
No. de cuenta lo representáramos nada más que con los dígitos finales (eliminando los dígitos
iniciales, que son los que especifican el banco), tal y como está el ejemplo, para un banco y un
número de cuenta obtendríamos un solo titular. Pero si pusiéramos el No. de cuenta en el extremo
de Persona, dado un titular y un No. de cuenta obtendríamos uno o más bancos.
Figura 5.26
Ejemplo del uso del calificador en una relación de asociación
Figura 5.25
Ejemplo de navegabilidad con restricción
190
El uso de calificadores restringe el entorno de la asociación y es útil, por ejemplo, para realizar
búsquedas.
Tipos de Asociaciones
Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es
decir, no se exige dependencia existencial ni encapsulamiento). Se indica como una línea
sólida que une dos clases como se observa en la Figura 5.27.
Fuente: Pickin (2005)
Asociación n-arias: Es una asociación entre tres (asociación ternaria) o más clases. Se
representa como un diamante del cual salen líneas de asociación a las clases como se observa
en la Figura 5.28.
Fuente: Pickin (2005)
Asociación Derivada: es una asociación redundante que se puede obtener como combinación
de otras relaciones del modelo. Un elemento derivado puede ser determinado a partir de otros.
Los atributos y las asociaciones son los elementos comunes para ser derivados. En UML un
elemento derivado se representa anteponiendo una “/” al nombre del elemento. En el
Figura 5.27
Representación de una asociación binaria
Figura 5.28
Representación de una asociación n-arias
191
diagrama de clases de la Figura 5.29 se puede observar una asociación derivada entre la clase
Profesor – Alumno.
Fuente: Insfrán (2001)
Asociaciones Reflexivas o Recursiva: una clase puede relacionarse consigo misma, es decir,
pueden modelarse asociaciones reflexivas. Las agregaciones pueden también ser reflexivas.
En la Figura 5.30 se puede observar que la clase Persona se relaciona consigo misma.
Fuente: Pickin (2005)
Asociación Restringida: Una restricción es un texto que especifica una o varias reglas que
sigue la clase, se indica mediante un texto libre encerrado entre llaves {}. Existe el OCL
(Object Constraint Language) que define de manera formal las restricciones en UML. En la
Figura 5.31 se puede observar un ejemplo de la asociación restringida.
Fuente: Pickin (2005)
Figura 5.29
Ejemplo de una asociación derivada
Figura 5.30
Ejemplo de una asociación reflexiva
Figura 5.31
Ejemplo de asociación restringida
192
Clase Asociación: Designa a una asociación que tiene propiedades de clase, tales como
atributos, operaciones y/o otras asociaciones. Siempre es representada junto a la asociación a
la que corresponde, y unida a ella mediante una línea discontinua. Ya que clase y asociación
forman un todo, el nombre de ambas es igual, pudiéndose especificarse en cualquiera de ellas
o en ambas. Una clase asociativa se representa como una clase colgada del símbolo de la
asociación por medio de una línea discontinua. En este caso, no puede haber relaciones de
agregación ni composición. En el ejemplo de la Figura 5.32 se puede observa la clase
asociada Trabajo.
Fuente: Pickin (2005)
Nótese que Trabajo, al pertenecer a la asociación, está ligado tanto a Compañía como a Persona,
y es ese conjunto el que tiene significado. Véase que este diagrama permite modelar que una
persona p1 fuera jefe de otra persona p2 en una compañía c1, y que simultáneamente p2 fuera
jefe de p1 en una compañía c2.
Casos Particulares de asociaciones
Existen dos casos particulares de la asociación, que son: agregación y composición.
Agregación
La agregación es la relación “es parte de”, que expresa un acoplamiento fuerte entre clases. Una
de las clases actúa como compuesta y la otra como componente y por defecto representa una
Figura 5.32
Ejemplo de una clase asociada
193
relación transitiva, asimétrica y reflexiva. Este concepto de agregación es una noción puramente
lógica, completamente independiente de las opciones de representación adoptadas. La agregación
se representa como una asociación con un rombo vacío en el lado de la clase todo, en la Figura
5.33 se muestra un ejemplo.
Fuente: Pickin (2005).
En la figura anterior, se muestra que un coche (el todo) tiene cuatro ruedas (la parte). Se ha
modelado como una agregación porque la rueda puede existir antes que el coche como entidad
propia o incluso después (se desguaza el coche y de dejan las ruedas) e incluso se puede cambiar
alguna de las ruedas de un coche a otro.
Composición
Si la relación de agregación es más fuerte, de tal forma que los componentes no pueden existir
independientemente, se denomina composición. En la composición, el “objeto parte” puede
pertenecer sólo a un “todo” y no puede ser cambiado (cualquier borrado del “todo” se considera
un borrado en cascada de sus “partes”, aunque esta restricción también puede expresarse
mediante un rol con mutiplicidad 1:1). La composición se representa como una asociación con un
rombo lleno en el lado de la clase todo, en la Figura 5.34 se muestra un ejemplo.
Fuente: Pickin (2005)
Figura 5.34
Representación de una relación de composición
Figura 5.33
Representación de una relación de Agregación
194
En la figura anterior se muestra un formulario (el todo) puede contener cero o más botones (la
parte). Un botón sólo puede existir dentro de un formulario, por lo que la vida del botón estará
restringida a la vida del formulario que lo posee. Un botón pertenece a uno y sólo un formulario.
Generalización
Alarcón (2000) la define como una relación entre un elemento general (llamado superclase o
padre) y un caso más específico de ese elemento (llamado subclase o hijo). La generalización a
veces es llamada relación “es-un-tipo-de”, ósea, un elemento (por ejemplo, una clase
Rectángulo) es-un-tipo-de un elemento más general (por ejemplo, la clase figura). La
generalización implica que los objetos hijo se pueden utilizar en cualquier lugar donde aparece el
padre, pero no a la inversa. La clase hijo siempre hereda todos los atributos y métodos de sus
clases padre y a menudo (no siempre) el hijo extiende los atributos y operaciones del padre. Una
operación de un hijo puede tener la misma signatura que en el padre pero la operación puede ser
redefinida por el hijo; esto es lo que se conoce como polimorfismo. Gráficamente viene dada por
una línea acabada en punta de flecha vacía que va del elemento especializado (llamado subclase o
hijo) al general (llamado superclase o padre), en la Figura 5.35 se muestra un ejemplo.
Fuente: Pickin (2005)
Una clase puede tener ninguno, uno o varios padres. Una clase sin padres y uno o más hijos se
denomina clase raíz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un
único padre se dice que utiliza herencia simple y una clase con varios padres se dice que utiliza
herencia múltiple. UML utiliza las relaciones de generalización para el modelado de clases e
Figura 5.35
Representación de una relación de generalización
195
interfaces, pero también se utilizan para establecer generalizaciones entre otros elementos como
por ejemplo los paquetes.
Una clase puede especializarse según ciertos criterios. Cada criterio de la generalización se indica
asociando un discriminador a la relación de generalización. Dicho discriminador es el nombre de
una partición de los subtipos de la superclase. Este discriminador puede ser un atributo de la clase
generalizada o el nombre de la partición. La generalización puede aplicarse a clases o a
asociaciones (aunque en este último caso es preferible representar la asociación como una clase
de asociación).
Pueden aplicarse diferentes restricciones a las relaciones de generalización para distinguir
diversas formas de generalización, en principio por defecto la generalización simboliza una
descomposición disjunta.
Pueden representarse grupos de generalizaciones semánticamente relacionados como árboles con
un segmento compartido. Si se añade una etiqueta a este segmento compartido (como nombre de
la partición) se aplica a todo el grupo de generalización.
Dependencia
Una dependencia es una relación entre un elemento dependiente (el cliente) y un elemento
independiente (el suministrador del servicio requerido). El elemento dependiente (cliente)
requiere conocer al elemento independiente (suministrador) y que éste esté presente. Las
dependencias se usan para modelar relaciones en la cual un cambio en el elemento independiente
(el suministrador) puede requerir cambios en el elemento dependiente (el cliente).
Es un tipo de relación unidireccional, ya que el elemento dependiente debe conocer al
independiente, pero el independiente desconoce la existencia del elemento dependiente.
Gráficamente se muestra como una línea discontinua acabada en flecha que va del elemento
dependiente al independiente (esto es, el elemento dependiente señala al elemento del que
depende) como se muestra en la Figura 5.36.
196
Fuente: Pickin (2005)
En este caso, la clase Cliente (dependiente) dependerá de servicios proporcionados por la clase
Servidor (independiente), y un cambio en la clase Servidor puede ocasionar que la clase Cliente
necesite ser adaptada. Un cambio en la clase Cliente no tiene ningún efecto sobre la clase
Servidor, ya que esta última es independiente de la primera (no la necesita).
Para que la clase dependiente tenga acceso a la clase independiente, la clase independiente debe
tener visibilidad global, ser pasada como parámetro a una operación o ser instanciada como
variable local en una operación de la clase dependiente.
Cuando una clase usa los servicios de otra a través de un interface, también se modela como
dependencia (depende del interface, un cambio en el interface requeriría un cambio en la clase
dependiente) esto se puede observa en la Figura 5.37.
Fuente: Alarcón (2000)
Nótese que la ClaseDependiente depende de Interface, no de la ClaseImplementadoraInterface.
De hecho un cambio en la ClaseImplementadoraInterface no tendría ninguna consecuencia sobre
la ClaseDependiente, ya que el interface aísla de posibles cambios en la clase implementadota
(Alarcón, 2000).
Figura 5.37
Representación de una relación de dependencia modelada a través
de una interfaz
Figura 5.36
Representación de una relación de dependencia
197
Realización
Es la relación semántica entre clases en la que una especifica un contrato que la otra clase se
compromete a cumplir. Es el mecanismo de separación entre la especificación de un servicio o
contrato y su implementación. Generalmente se emplea la realización para especificar una
relación entre una interfaz y la clase o componente que implementa las operaciones especificadas
en dicha interfaz. Existen dos casos en que se utiliza: en interfaz y clase o componente que la
implementa y en los caso de uso y colaboración que lo realiza
Gráficamente, una interfaz se muestra como una clase con el estereotipo «interface» y sus
operaciones, o en forma resumida como un círculo y debajo el nombre del interface como se
muestra en la Figura 5.38. En este caso, el interface Mensurable especifica dos operaciones,
peso() y volumen().
Fuente: Alarcón (2000)
Para indicar que una clase realiza una interfaz, se muestra una línea discontinua acabada en
flecha vacía que va de la clase que implementa el interfaz a la interfaz, en la Figura 5.39 se
muestra un ejemplo.
Figura 5.38
Representación de una relación de realización
198
Fuente: Alarcón (2000)
Se puede observar que tanto Saco como Automovil “realizan” el interface Mensurable, es decir,
ambas implementan las operaciones indicadas en la interfaz.
En el caso de usar la notación resumida, se unirá la interfaz a la clase que lo implementa por una
línea continua como se observa en la Figura 5.40.
Fuente: Alarcón (2000)
Cuando una clase realiza un interface, debe implementar todas las operaciones indicadas en dicha
interface y, posiblemente, otras exclusivas de la clase.
Figura 5.39
Representación grafica de la relación de realización
Figura 5.40
Representación de la relación de realización de
manera resumida
199
Varias clases pueden satisfacer una interfaz (como en el ejemplo anterior), y una clase puede
satisfacer varias interfaces como se observa en la siguiente Figura 5.41.
Fuente: Alarcón (2000)
Las interfaces pueden evitar en ciertos casos el uso de herencia múltiple. Son muy útiles para
independizar la implementación de sistemas o utilidades de los servicios u operaciones que
proporcionan (esto es, se puede cambiar la implementación sin que sea necesario modificar las
llamadas, ya que no se ha modificado el interface), fomentando la reutilización. Los interfaces
son soportados por lenguajes como Java.
Relaciones existentes en los diagramas de casos de uso
Cuando se implementa un caso de uso, su funcionamiento se basa en la colaboración entre clases.
Una clase puede participar en múltiples colaboraciones y por tanto, en múltiples casos de uso,
dando paso a relaciones entre los casos de uso (Fowler, 2003). Las relaciones que se dan en los
diagramas de caso de uso son: asociación, generalización y dependencia.
Asociación: es la participación de un actor en un caso de uso, la instancia de un actor se
comunican con instancias de un caso de uso; la relación entre los actores y los casos de uso se
representarán como una asociación, indicando la comunicación bidireccional entre usuarios y
sistema.
Generalización: Relación taxonómica entre un caso de uso más general y otro más específico
(también entre actores).
Figura 5.41
Representación de la relación de realización donde una clase
satisface varias interfaces
200
Dependencia:
<<extend>>: Relación que define un curso alterno opcional (dependiendo de una
condición) de otro caso de uso.
<<include>>: Relación que define una instancia de un caso de uso como un curso
obligatorio en otro caso de uso.
En la Figura 5.42 se muestra la representación grafica de todas las relaciones que se dan en un
diagrama de caso de uso.
Figura 5.42
Relaciones en un diagrama de casos de uso
Fuente: Fowler (2003)
En UML, la relación entre los actores y los casos de uso se representarán como una asociación,
indicando la comunicación bidireccional entre usuarios y sistema.
Relación existente en los diagramas de paquetes
En los diagramas de paquetes existe la relaciones de dependencia, la misma a parte de usarse en
otros tipos de diagramas, también se utilizan para mostrar la dependencia entre paquetes. Tal y
como se dijo, las clases se suelen agrupar en paquetes. Para agrupar las clases en paquetes, se
pueden utilizar varios criterios. Un criterio puede ser el agrupar las clases por estereotipos (en
este caso habría un paquete para las clases frontera, otro para las de control y otro para las de
entidad). También es posible agrupar las clases por su funcionalidad (podría haber un paquete
con clases que se encargaran del control de acceso, otras de la gestión informes, otra de errores,
etc.). Como los paquetes pueden contener a su vez otros paquetes, una tercera posibilidad
Asociación
Generalización
Dependencia <<extend>>
<<include>>
201
consiste en agrupar las clases por funcionalidades y dentro de cada grupo de funcionalidad,
volver a agrupar por estereotipo.
Una relación de dependencia entre un paquete A y un paquete B indica que alguna clase del
paquete A tiene una relación unidireccional con alguna clase del paquete B y, por tanto, el
paquete A necesita tener acceso al paquete B. Las relaciones de dependencia entre paquetes deben
ser calificadas con el estereotipo «access» o «import». Con ambos estereotipos se tiene acceso a
los elementos públicos del paquete independiente, pero con «access» es necesario preceder
dichos elementos por el nombre del paquete que los contiene mientras que con «import» no (en
este caso, es necesario que ningún nombre de un elemento del paquete dependiente coincida con
un nombre de elemento del paquete independiente). Un ejemplo de esto se muestra en la Figura
5.43.
Fuente: Fowler (2003)
Esta dependencia tiene implicaciones en la reutilización. El paquete B es fácilmente reutilizable
(es independiente), mientras que el paquete A no lo es, ya es dependiente del B y para reutilizar el
paquete A habría que usar también el B. Se deben evitar en lo posible referencias circulares.
Los paquetes contenidos en otros paquetes pueden acceder a todos los elementos del paquete que
los contiene. Sin embargo, las dependencias no son transitivas, tal y como se muestra en la Figura
5.44.
El paquete A puede acceder al paquete B y al paquete C. El paquete B y el paquete C pueden
acceder al paquete D. El paquete A no puede acceder al paquete D. Si se deseara que A accediera
a D, habría que añadir una dependencia de A a D.
Figura 5.43
Ejemplo de una dependencia
202
Fuente: Fowler (2003)
Relación existente en los diagramas de despliegue
Las instancias de cada uno de los componentes que integran los diagramas de componentes se
encuentran especificadas en los diagramas de despliegue mediante los nodos. Estos nodos son los
elementos donde se encuentran o ejecutan las instancias de los componentes en tiempo de
ejecución. Para mostrar que una instancia de un componente reside o se ejecuta en un nodo, es
decir, que el nodo soporta una instancia de ese componente, se relaciona al nodo con la instancia
mediante una dependencia estereotipada como «support», tal y como se muestra en la Figura
5.45.
Fuente: Fowler (2003)
Figura 5.44
Ejemplo de una dependencia cuando un paquete contiene otro paquete
Figura 5.45
Representación de una relación de dependencia en un diagrama
de despliegue
203
Los nodos están relacionados entre sí por asociaciones, que indican caminos de comunicación.
Una asociación se representa gráficamente como una línea entre los nodos que se comunica como
se muestra en la Figura 5.46. Es común estereotipar las asociaciones para indicar su tecnología.
Fuente: Fowler (2003)
Síntesis
Diagramas Tipos de Relaciones
Diagrama de Caso de Uso Asociación
Dependencia
Generalización
Diagrama de Clases y Diagrama de
Objetos Asociación
Generalización
Dependencia
Realización
Diagrama de Paquetes Dependencia
Diagrama de Despliegue Dependencia
Asociación
Figura 5.46
Representación de una relación de asociación en un diagrama de despliegue
204
5.2.4. Análisis comparativo entre las relaciones que se dan en los diagramas de clases y de
objeto de los métodos OO y los de UML
En este apartado se analizan cuáles son las características comunes y diferentes que se encuentran
entre los Métodos OO y en UML referentes a la semántica de las relaciones entre clases y objetos.
Asociación
En la Notación de Booch la asociación conecta dos clases y denota una conexión semántica, se
etiquetan con expresiones sustantivas, denotando la naturaleza de la relación. Las asociaciones se
pueden etiquetar con un nombre o frase.
En la Notación de OMT los enlaces y asociaciones son los medios para establecer relaciones entre
objetos y clases. Un enlace es una conexión física o conceptual entre instancias de objetos. Una
asociación describe un grupo de enlaces con estructura y semántica comunes.
En UML una asociación es una conexión entre dos o más objetos/clase. Dependiendo de la
semántica asociada a dicha conexión, puede clasificarse nuevamente en: asociación (en el caso
general), agregación (caso específico de la relación parte-de de los modelos semánticos) y
composición (una agregación donde la relación existente entre los objetos involucrados es más
fuerte).
Como se puede observar en la Figura 5.47 la representación grafica de la relación de asociación en
UML, Booch y OMT son iguales.
UML Notación Booch Notación OMT
Figura 5.47
Representación de la relación de asociación en UML, Booch y OMT
205
Tipos de Asociaciones
En la notación de OMT se da la clase asociada, que no es más que modelar la relación de
asociación como una clase, esto es útil cuando los enlaces pueden participar en asociaciones con
otros objetos o cuando están sometidos a operaciones, esta clase asociada se corresponde con la
utilizada en UML, sólo se diferencia en su notación.
La asociación calificada en UML es una asociación con un calificador. El calificador está
definido por un conjunto de atributos que pertenecen a la asociación (estos atributos no
pertenecen a la signatura de ninguna de las dos clases que participan en la asociación) y se
encuentra en un extremo de la asociación binaria. Esta asociación calificada se utiliza para
seleccionar exactamente una partición del conjunto de objetos asociados en el otro extremo de la
asociación.
En la notación OMT una asociación calificada relaciona dos clases de objetos y un calificador. El
calificador es un atributo especial que reduce la multiplicidad efectiva de una asociación. Una
asociación calificada también puede considerarse como una forma de relación ternaria. La
calificación mejora la precisión semántica e incrementa la visibilidad de las vías de navegación.
Las asociaciones derivadas de UML representan información sobre relaciones ya existentes en el
modelo, se muestran sólo a efectos expresivos; en el modelo subyacente a los Métodos OO esta
información está disponible aunque no tiene representación gráfica. En UML un elemento
derivado puede ser determinado a partir de otros. Los atributos y las asociaciones son los
elementos comunes para ser derivados. En UML un elemento derivado se representa anteponiendo
una “/” al nombre del elemento.
En la notación de Booch no se observa ningún tipo de asociación relevante para ser comparada.
Multiplicidad
La multiplicidad en UML o en los Métodos OO especifica el número de asociaciones entre dos
clases. Si no se indica se considera sin especificar. La multiplicidad en la notación de OMT se
señala por medio de terminadores (en el extremo de la asociación) que especifica la cantidad de
instancias que pueden estar relacionadas con una única instancia de una clase asociada. En UML
206
se indica la multiplicidad con un número entero positivo o mediante un conjunto de intervalos
números enteros que se colocan en el extremo de la asociación.
Agregación
En el caso de UML la agregación forma parte de la asociación como un caso particular. La
agregación en este caso es la relación “es parte de”, que expresa un acoplamiento fuerte entre
clases. Una de las clases actúa como compuesta y la otra como componente y por defecto
representa una relación transitiva, asimétrica y reflexiva. Se representa como una asociación con
un rombo vacío en el lado de la clase todo/parte como se muestra en la Figura 5.48 (a).
En la notación de Booch denota una relación todo/parte (relación “tiene un” o agregación),
aparece como una asociación con un círculo relleno en el extremo que señala al agregado como se
muestra en la Figura 5.48 (b), la clase que esta en el otro extremo denota la parte cuyas instancias
están contenidas por el objeto agregado.
Una agregación en la notación OMT representa la relación todo/parte o “una parte de” en la cual
los objetos componentes de algo se asocian a un objeto que representa el ensamblaje completo. La
agregación es una forma fuertemente acoplada de asociación, con semántica adicional. Las
propiedades de la agregación son: transitividad y antisimetría. La existencia de una parte puede o
no depender de la existencia del todo. La agregación se representa como una asociación con un
rombo vacío en el lado de la clase todo/parte como se muestra en la Figura 5.48 (c).
UML (a) Notación Booch (b) Notación OMT (c)
Tipos de Agregación
En la notación OMT se observa tres (3) tipos de agregación:(1) la simple o Fija, cuyo número y
tipo de componentes esta predeterminado; (2) la variable, donde el número de niveles es finito,
pero el número de partes puede variar; y (3) la recursiva, donde una agregación puede tener,
directa o indirectamente, una instancia de la misma clase agregada como parte.
Figura 5.48
Representación de la relación de agregación en UML, Booch y OMT
207
En la notación de Booch se observan dos (2) tipos de agregación: por valor y por regencia.
Cuando una clase contenida no existe independientemente de la clase que la contiene se denomina
agregación por valor y además implica contenido físico, mientras que si existe
independientemente y se accede a ella indirectamente, es agregación por referencia.
En UML existe solo una clase de agregación que existe como un caso particular de la relación de
asociación cuyo concepto se explicó con anterioridad.
Composición
La composición de UML se corresponde directamente en los Métodos OO con la agregación por
valor de la notación de Booch
En la composición, el “objeto parte” puede pertenecer sólo a un “todo” y no puede ser cambiado
(cualquier borrado del “todo” se considera un borrado en cascada de sus “partes”, aunque esta
restricción también puede expresarse mediante un rol con mutiplicidad 1:1). La composición se
representa como una asociación con un rombo lleno en el lado de la clase todo, como se muestra
en la Figura 5.49 (a).
En la notación de Booch cuando una clase contenida no existe independientemente de la clase que
la contiene se denomina agregación por valor y su representación grafica se muestra en la Figura
5.49 (b).
Herencia y generalización
La herencia, para Booch (1996), es una relación entre clases, en la que una clase comparte la
estructura o comportamiento definido en otra (herencia simple) u otras clases (herencia múltiple).
La herencia representa una jerarquía de abstracciones donde una subclase hereda de una o más
superclases. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones
UML (a) Notación de Booch (b)
Figura 5.49
Representación de la relación de composición en UML y Booch
208
de herencia no pueden llevar indicaciones de cardinalidad. La notación consiste en una flecha que
apunta de la subclase a la superclase.
En la Notación OMT se habla de generalización y especificación, esta se refiere a la relación entre
clases. La generalización indica que una superclase generaliza las subclases y la especificación: se
refiere al refinamiento de una superclase en una subclase. La herencia: se refiere a un mecanismo
para compartir atributos y operaciones.
UML utiliza un único concepto (generalización) para tratar la herencia en forma amplia como la
relación entre una clase más general y otra más específica. En los Método OO se categoriza la
herencia de acuerdo a su naturaleza, y puede ser la herencia descendente/simple o especialización
(subclase) o la herencia ascendente/múltiple o generalización (superclase).
Dada una relación de generalización entre dos clases4 en UML, el discriminador proporciona un
criterio para particionar las subclases de la superclase. Este discriminador puede ser un atributo de
la clase generalizada o el nombre de la partición. En los Métodos OO algunas veces se hace uso
de un discriminador que funciona como un atributo de tipo enumerado que indica que propiedad
de un objeto está siendo abstraída por una relación de generalización. El discriminador es
simplemente un nombre para la base de la generalización.
La generalización se utiliza para modelar la herencia en los lenguajes orientados a objetos. Una de
las características de la herencia es que permite simplificar la construcción de clases relacionadas,
ya que gracias a ella es posible agrupar las características comunes de un conjunto de clases en
una clase padre (superclase) y hacer que todas ellas hereden de la superclase (Pastor, 1997).
Todos los lenguajes orientados a objetos permiten la herencia simple (una clase puede descender a
lo sumo de otra), aunque algunos lenguajes, como C++, permiten la herencia múltiple (una clase
puede descender de varias clases padre). Aunque la descendencia múltiple puede ser muy
conveniente en algunos casos, no se debe abusar de ella (ya que puede resultar compleja su
utilización).
4 En UML también es posible definir un árbol de generalización (para herencia simple) para un conjunto de subclases, en este caso
es común que el discriminador de especialización sea común para todas las particiones definidas.
209
Como conclusión se puede decir que algunos aspectos presentes en los diagramas de UML no se
encuentran explícitamente en los Métodos OO (Notación Booch y OMT), aunque éstos en general
representan información orientada más bien a aspectos de diseño físico o implementación que a
nociones de modelado.
5.3. Análisis comparativo entre los diagramas de UML y los diagramas de la
programación estructurada y los métodos OO.
En este apartado se hace un análisis comparativo de los diagramas de UML con los diagramas que
se dan en el desarrollo estructurado y con los diagramas usados en los métodos orientados a
objetos (OO). Cabe destacar que los diagramas que se seleccionaron fueron aquellos que tenían
semejanzas con el estándar UML.
5.3.1. Análisis comparativo entre los diagramas de flujo y los diagramas de actividad de UML
Los diagramas de actividad muchas veces juegan un papel similar al de los diagramas de flujo, la
principal diferencia entre estos dos diagramas, es que los diagramas de actividad soportan tanto el
comportamiento paralelo (parallel processing) como secuencial. Esto es importante cuando se
usan diagramas de actividad para modelar procesos de negocios, algunos de los cuales pueden
actuar en paralelo, y para modelar varios hilos en los programas concurrentes. El hecho de que
los diagramas de flujo sólo soporten procesos secuenciales se vuelve muchas veces una
desventaja ya que en ciertas ocasiones se requieren tomar varias decisiones a la vez.
Otra diferencia que se puede apreciar es que en los diagramas de actividades, las actividades
están claramente unidas a objetos y en un diagrama de flujo muchas se presentan en forma de
condiciones que se deben cumplir. Los diagramas de actividad siempre están asociados a una
clase, a una operación o a un caso de uso.
Como se mencionó anteriormente los diagramas de actividad soportan actividades tanto
secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de
210
fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas
(pueden ser ejecutadas simultáneamente o una detrás de otra).
En la Figura 5.50 se muestra un ejemplo de cómo en un diagrama de actividades se dan procesos
paralelos, se observa que existen nodos (nodo fork) que tiene un flujo entrante y varios flujos
concurrentes salientes, de esta manera se pueden dar dos actividades a la vez, es decir, de forma
paralela, lo cual no poseen los diagramas de flujo. Así, que llenar la orden, enviar la factura y las
acciones subsecuentes ocurren en paralelo. Esencialmente, esto significa que la secuencia entre
ellas es irrelevante. Se podría llenar la orden, enviar la factura, entregar y recibir el pago; o podría
enviar la factura, recibir el pago, llenar la orden y luego entregar.
También podría llevar a cabo estas acciones por individual. Se toma el primer ítem de línea de los
depósitos, escribo la factura, tomo el segundo ítem de línea, pongo la factura en un sobre, y así
sucesivamente. O podría ejecutar varias de estas simultáneamente: escribo la factura con una
mano mientras busco en mis depósitos con la otra. Cualquiera de estas secuencias es correcta de
acuerdo al diagrama.
El diagrama de actividades permite que cualquiera que esta ejecutando el proceso escoger el
orden en el cual hacer las cosas. En otras palabras, el diagrama simplemente declara las reglas
esenciales de secuencia que debo seguir. Esto es importante en el modelado de negocios porque
aquí los procesos usualmente ocurren en paralelo. También es útil para algoritmos concurrentes,
en los cuales los hilos independientes pueden hacer cosas en paralelo.
Cuando tengan paralelismo tendrán que sincronizar. No se cerrara orden hasta que es entregada y
pagada. Mostramos esto unido antes de la acción de “cerrar orden”. Con una unión, el flujo
saliente es tomado sólo cuando todos los flujos entrantes alcanzan la unión. De modo que sólo
puede cerrar la orden cuando has recibido el pago y entregado.
211
Fuente: Fowler (2003)
Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un
diagrama de flujo (típicamente asociado en el diseño de software), éstos no son lo mismo. Un
diagrama de actividad es utilizado en conjunción de un diagrama de casos de uso para auxiliar a
los miembros del equipo de desarrollo a entender cómo es utilizado el sistema y cómo reacciona
en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un
programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera
considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo
describe la solución.
5.3.2. Análisis comparativo entre los DFD y los diagramas de casos de uso de UML
Según Larman (2004) el propósito del diagrama de los casos de uso es representar un tipo de
diagrama donde se refleje el contexto, con lo cual puede ser entendido rápidamente cuáles son los
agentes externos a un sistema y cómo los utiliza.
Figura 5.50
Ejemplo de un diagrama de actividades
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
Llenar
orden
Entregar
de noche
Entregar
regular
actividad final
joinnodo merge
acción
decisión
[sino]
nodo inicial
nodo fork
flujo
[prioridad]
Recibir
orden
Cerrar
orden
Recibir
pago
Enviar
factura
Llenar
orden
Entregar
de noche
Entregar
regular
actividad final
joinnodo merge
acción
decisión
[sino]
nodo inicial
nodo fork
flujo
[prioridad]
212
En el caso de los DFD, las entidades externas (categorías lógicas de cosas o personas que
representan una fuente o destinación de la información) son el origen y/o destinación de la
información (Gane, 1988). Por lo tanto el uso de los DFD en comparación con los diagramas de
casos de uso implican el modelado del contexto del sistema, de esta manera las entidades
externas y los agentes externos respectivamente funcionan recíprocamente igual.
Se podría entender que un proceso definitivo del diagrama de flujo de datos (representa una
función) de un sistema se puede considerar como diagrama de casos de uso y que las entidades
externas del diagrama de flujo de datos pueden directamente ser mapeadas5 como agentes en un
diagrama de casos de uso.
Tanto el diagrama de flujo de datos como los diagramas de casos de uso hacen posible la visión
de los aspectos funcionales del sistema.
Para Pressman (2001) los DFD hacen posible que se desarrollen simultáneamente los modelos del
dominio de la información y del dominio funcional. Cuando los DFD están muy bien a nivel de
detalles, el analista ejecuta implícitamente una descomposición funcional. Al mismo tiempo, el
refinamiento de los DFD dan lugar a un refinamiento de los datos a medida que se ponen en
movimiento con los procesos.
La descomposición de los DFD en niveles inferiores de detalles es similar a la creación de
algunos diagramas de casos de uso, los datos en un diagrama de casos de uso se utilizan para
crear y para refinar un sistema de requisitos y por otro lado, se podría decir que en ambos
diagramas se eliminan la complejidad y los problemas de inconsistencia.
Los DFD por sí solos no son lo suficientes completos como para modelar todo un sistema y se
deben utilizar en sistemas con ayudas de otras herramientas, como los diagramas de entidad-
relación, para modelar los datos; los diagramas de estados, para modelar el comportamiento del
sistema, o el diccionario de datos, que contiene los datos.
5 Localizar y representar gráficamente la distribución relativa de las partes de un todo. Trasladar a un mapa sistemas
o estructuras conceptuales.
213
Semejantemente, un diagrama de casos de uso no es suficientemente poderoso como para
modelar sistemas orientados a objetos en su totalidad, teniendo una relación estrecha con los
diagramas de secuencia y de colaboración, entre otros.
Los DFD y los diagramas de casos de uso utilizan textos narrativos como ayuda para especificar
sus procesos.
Una de las críticas relacionadas a los DFD, es como abordan el diseño top down exigido para su
construcción y mantenimiento. Para Pressman (2001) los DFD se deben presentar a los usuarios
en la modalidad de top down, sin embargo, no es necesario que el analista de sistemas deba
desarrollar los diagramas del flujo de datos según esta modalidad. La subdivisión de un DFD
puede estar hacia arriba (crear DFD de niveles más altos) y hacia abajo (crear DFD de niveles
inferiores).
Para Booch et al. (2002) un diagrama de caso de uso describe lo que un sistema hace (o un
subsistema, o una clase, o interfaz), sin especificar cómo lo hace, captura el comportamiento del
sistema en desarrollo, sin necesidad de especificar cómo este comportamiento se pone en
ejecución Esto es un factor importante para el análisis (comportamiento del sistema) de aspectos
referentes a la puesta en marcha (ejecución del comportamiento).
En los DFD, aunque algunos aspectos físicos de la puesta en práctica pueden ser visualizados, no
se estimulan.
3.3.3. Análisis comparativo entre los diagramas de E-R y los diagramas de clases de UML
En UML existe la carencia de medios para representar los diagramas de entidad relación y pese a
que el área de la ingeniería de software cada día hay más avances en cuando al desarrollo del
software, las bases de datos relacionales no han podido ser suplidas por otro tipo de repositorios
que no choquen con el paradigma OO.
214
En consecuencia, la realidad sigue siendo que detrás de un modelo de software orientado a
objetos se encuentran habitualmente un repositorio de datos relacionales. Esto, desde el punto de
vista del desarrollo, obliga a las clases responsables de la gestión de la persistencia de las
entidades del sistema a adaptar ambos paradigmas. Por otro lado, y de forma evidente, obliga a
diseñador del sistema a modelar esa base de datos por medio de las herramientas oportunas. La
más adecuada es sin duda el modelo entidad relación, modelo no contemplado por UML. El
lenguaje de modelado que nos ocupa propone el empleo de los diagramas de clases para el
modelado de la base de datos relacional. No obstante, esta forma de trabajo no ha resultado
exitosa debido, entre otras cosas, a que el diagrama de clases del sistema no tiene porqué
coincidir con el modelo entidad relación en cuanto a entidades y sobre todo a relaciones se
refiere. Esto, unido a la confianza que las herramientas de modelado de bases de datos
relacionales clásica aportan a los responsables del diseño, hacen que en la mayoría de los casos se
opte por incorporar a los diseños UML diagramas de entidad relación clásicos.
En la Figura 5.51 se puede observar la situación actual del desarrollo de software, se presentan
las tres (3) etapas básicas de todo proyecto y se muestra como a pesar del avance de la ingeniería
del software de alguna manera siempre están presentes los modelos relacionales que son
diseñados para implementar las bases de datos que muchas veces son partes de los proyectos a
desarrollar.
En los diagramas entidad relación y los diagramas de clases pueden darse casos particulares en
donde coincidan de alguna forma las clases con las entidades, pero esto no tiene porque ser
necesariamente así. Por otra parte, hay que recordar que las clases tienen características que no se
consideran en las entidades como: atributos privados/protegidos/públicos y los métodos
(operaciones/comportamientos), las entidades sólo muestran de estás características los atributos
y las mismas relaciones que se dan en un diagrama de clases ya abarcan conceptos que no se
consideran en los diagramas E-R (p.ej. composición).
215
Fuente: Pérez (2002), adaptación por Yedra (2007)
Las clases, sus atributos, y sus relaciones pueden ser implementadas directamente en una base de
datos orientada a objetos. Pero aún así, en el entorno de desarrollo actual, la base de datos
relacional es el método más usado para el almacenamiento de datos. El diagrama de clase de
UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero
no cubre toda la semántica involucrada en el modelado relacional, como por ejemplo la notación
de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar este tipo de
información, se implementa el diagrama de entidad relación como extensión de los diagramas de
clase de UML, de esta manera se puede llegar a realizar un buen modelado de datos, ya que hay
detalles de semánticas de las bases de datos que UML no contempla en sus especificaciones.
Los diagramas de clase se pueden usar para modelar la estructura lógica de la base de datos,
independientemente de si es orientada a objetos o relacional, con clases representando tablas, y
atributos de clase representando columnas. Si una base de datos relacional es el método de
ANÁLISIS DISEÑO IMPLEMENTACIÓN
Desarrollo
Estructurado
Método Orientado
a Objetos
UML
DFD
E-R
DE
Modelo
Relacional
Entornos de
Programación
Entornos de Programación Orientada a Objetos
Bases de Datos Relacionales
Diagramas de Casos de Uso
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración
Diagramas de Interacción
Diagramas de Clases
Diagramas de Estados
Diagramas de Actividad
Modelo
Relacional
Métodos de Booch,
Good, Hood,
OODLE, JSD y
OOJSD, OOSD
Métodos de Shlaer/Mellor,
Coad/Yourdon, OMT de
Rumbaugh, Wirfs-Brock
ANÁLISIS DISEÑO IMPLEMENTACIÓN
Desarrollo
Estructurado
Método Orientado
a Objetos
UML
DFD
E-R
DE
Modelo
Relacional
Entornos de
Programación
Entornos de Programación Orientada a Objetos
Bases de Datos Relacionales
Diagramas de Casos de Uso
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración
Diagramas de Interacción
Diagramas de Clases
Diagramas de Estados
Diagramas de Actividad
Modelo
Relacional
Métodos de Booch,
Good, Hood,
OODLE, JSD y
OOJSD, OOSD
Métodos de Shlaer/Mellor,
Coad/Yourdon, OMT de
Rumbaugh, Wirfs-Brock
Figura 5.51
Situación actual del desarrollo de software
216
implementación escogido, entonces el diagrama de clase puede ser referenciado a un diagrama de
entidad relación lógico. Las clases persistentes y sus atributos hacen referencia directamente a las
entidades lógicas y a sus atributos; el desarrollador dispone de varias opciones sobre cómo inferir
asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas
directamente a super-sub relaciones entre entidades en un diagrama de entidad relación.
Como conclusión, se tiene que los diagramas de clase representan las abstracciones de los objetos
y son utilizados en el desarrollo de software que no necesariamente tienen que tener bases de
datos. Los diagramas de entidad relación representan modelos de datos y muestran la parte
conceptual (nivel conceptual) de las bases de datos al contrario de lo que hacen los diagramas de
clases que muestran el lado práctico (nivel práctico). Se podría decir que la utilización de estos
dos diagramas forma una herramienta de modelado poderosa a la hora de diseñar bases de datos
5.3.4. Análisis comparativos entre los diagramas de estados de los métodos OO y los de UML
En los Métodos OO lo que se conoce como diagramas de transición de estados (Booch), y
diagramas de estados (OMT), se le denominan diagramas de estados en UML. En los diagramas
de estados se muestran la secuencia de estados por los que pasa un objeto durante su vida y que
se corresponden con los estímulos recibidos, junto con sus respuestas y acciones. Cada diagrama
de estados se corresponde con una clase o con un método.
Diagramas de transición de estados (Notación Booch)
Un diagrama de transición de estados (Ver Figura 5.52) muestra el espacio de estados de una
clase determinada, los eventos que provocan una transición de un estado a otro y las acciones que
resultan de ese cambio de estado. El estado de un objeto representa los resultados acumulados de
su comportamiento, cada estado necesita un nombre, por otro lado, se pueden poner las acciones
asociadas a cada estado. Siempre hay un estado inicial por defecto pero puede haber o no estado
final o de parada. Un evento es algún suceso que puede causar un cambio de estado en el sistema
y puede disparar una acción. La máquina de estados deja de existir cuando se destruye el objeto
que la contiene
217
Se pueden asociar acciones a los estados indicando la acción que ocurre cuando se entra o sale
del estado, ejemplo de esto es: en el estado Calentando, la entrada Calentador: activar y la salida
Calentador: desactivar.
Se pueden representar transiciones de estado condicionales (o vigiladas) por medio de una
expresión booleana entre llaves, ejemplo de esto es: en la transición Demasiado-frio [tiempo de
encendido>=5 minutos].
Se pueden detallar los estados utilizando estados anidados, por ejemplo
– Los estados continentes se llaman superestados
– Los estados anidados se llaman subestados
– Las transiciones desde y hacia subestados dentro de un superestado se hacen utilizando
flechas romas, un ejemplo es Transición de Encendido a Preparado. En la figura 5.52 se
puede observar este tipo de transición.
Fuente: Cueva (1999)
Diagramas de estados (Notación OMT)
Un diagrama de estados según la notación OMT (Ver Figura 5.53) relaciona sucesos y estados.
Cuando se recibe un suceso, el estado siguiente depende del actual, así como del suceso; un
cambio de estado causado por un suceso es lo que se llama una transición. Un diagrama de
estados es un grafo cuyos nodos son estados, y cuyos arcos dirigidos son transiciones rotuladas
con nombres de sucesos.
Figura 5.52
Ejemplo de un diagrama de transición de estados (Notación Booch)
218
El diagrama de estados especifica la secuencia de estados que causa una cierta secuencia de
sucesos. Si un objeto se encuentra en un cierto estado y se produce un suceso cuyo nombre
corresponda al de una de sus transiciones, entonces el objeto pasa al estado que se encuentra en el
extremo de destino de la transición. Se dice que la transición se dispara. Si hay más de una
transición que sale de un estado, entonces el primer suceso que se produzca dará lugar a que se
dispare la transición correspondiente.
Si se produce un suceso que no tiene ninguna transición que salga del estado actual, entonces el
suceso se ignora. Una secuencia de sucesos se corresponde con un camino a través del grafo.
Un diagrama de estados describe el comportamiento de una sola clase de objetos, como se
observa en la Figura 5.53. Dado que todas las instancias de una clase tienen el mismo
comportamiento, todas ellas comparten el mismo diagrama de estados, por cuanto todas ellas
comparten las mismas características de clase. Pero dado que todo objeto posee sus propios
valores de atributos, cada objeto posee su propio estado, que es el resultado de la especial
secuencia de sucesos que haya recibido. Todo objeto es independiente de los demás objetos, y
procede a su paso.
Fuente: Cueva (1999)
Los diagramas de estados pueden representar ciclos vitales únicos o bien bucles continuos. Los
diagramas de un solo uso representan objetos de duración finita y tienen estados iniciales y
finales. Se entra en el estado inicial al crear el objeto; al entrar en el estado final estamos
implicando la destrucción del objeto. Los diagramas de un solo uso son una subrutina del
Figura 5.53
Ejemplo de un diagrama de estado de la clase ajedrez
(Notación OMT)
219
diagrama de estados, a la cual se puede hacer alusión desde distintos lugares en un diagrama de
alto nivel.
Diagramas de estado en UML
Un diagrama de estados en UML (Ver Figura 5.54) muestra la secuencia de estados por los que
pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de
un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación,
un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son
transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja
redondeada con el nombre del estado en su interior. Una transición se representa como una flecha
desde el estado origen al estado destino. La caja de un estado puede tener cero o dos
compartimentos. En el primer compartimiento aparece el nombre del estado. El segundo
compartimiento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones
internas.
Fuente: Fowler (2003)
5.3.5. Análisis comparativos entre los diagramas de objetos de los métodos OO y los diagramas
de colaboración de UML
En los Métodos OO lo que se conoce como diagramas de objetos (Booch) se le denominan
diagramas de colaboración en UML, lo cual permiten profundizar el nivel de detalle de los
Figura 5.54
Ejemplo de un Diagrama de Estado en UML
220
diagramas de secuencia, los diagramas de colaboración permiten expresar en tiempos de
ejecución las colaboraciones de los objetos.
Diagramas de objetos (Notación de Booch)
Los diagramas de objetos muestra la existencia de objetos y sus relaciones en la vista lógica de un
sistema. En la fase de análisis estos diagramas se usan para indicar la semántica de los escenarios
primarios y secundarios que proporcionan la traza del comportamiento del sistema y en la fase de
diseño se utilizan para ilustrar la semántica de los mecanismos del diseño lógico. Cada objeto del
diagrama se denota con su nombre y opcionalmente con sus atributos, estos interaccionan a través
de enlaces con otros objetos. El objeto cliente es el objeto que invoca una operación y el objeto
servidor es el objeto que suministra la operación. La relación entre objetos viene dada por medio
de una flecha que indica la dirección de la invocación, así como la operación, y un número de
orden (opcional).
Diagramas de colaboración de UML
Un diagrama de colaboración es una forma alternativa de mostrar el escenario que se da en un
diagrama de secuencia. Este tipo de diagrama muestra las interacciones entre objetos organizadas
entorno a los objetos y los enlaces entre ellos. Un diagrama de colaboraciones muestra las
relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. En los
diagramas de colaboración de UML se separa el comportamiento de la clase, a diferencia de otras
notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases.
Los diagramas de colaboración enfatizan la organización estructural de los objetos que envían y
reciben mensajes.
5.3.6. Análisis comparativos entre las clases de los métodos OO y las clases de UML
Las “clases” en los métodos orientados a objetos
Para Booch (1996) una clase es un conjunto de objetos que comparten una estructura común y un
comportamiento común. Los términos clase y tipo son generalmente (pero no siempre)
intercambiables; y una clase es un concepto levemente distinto a tipo, en el hecho que acentúa la
importancia de jerarquías de clases.
221
Booch representa las clases por una nube con contorno discontinuo, colocándose en su
interior el nombre de la clase y separados por una línea están los atributos, las operaciones,
las restricciones y los adornos
La nube significa que las fronteras de una abstracción no son nítidas
Las líneas discontinuas indican que los clientes sólo operan sobre objetos y no sobre la clase
Los atributos y las operaciones pueden ser visibles o no según el detalle deseado
Un atributo es un dato que se almacenará en los objetos que son instancias de la clase
Un método es la implementación de una operación para la clase
Un adorno de clase es una propiedad por ejemplo indicar que la clase es abstracta (no puede
tener instancias, sólo se puede heredar de ella)
En la Figura 5.55 se muestra una clase según la notación de Booch, contienen el nombre de la
clase y sus atributos.
Fuente: Booch (1996)
Para Coad y Yourdon (1991) una descripción de uno o más objetos forman un conjunto uniforme
de cualidades y de servicios, incluyendo una descripción de cómo crear nuevos objetos en la
clase. Para ellos la relación Clase-Objeto significa “una clase y los objetos en esa clase”.
Para Martin y Odell (1992) una clase es una implementación de un concepto o de un tipo de
objeto. En lenguajes de programación OO, los tipos de datos abstractos se llaman clases.
Para Rumbaugh (1999) una clase del objeto describe un grupo de objetos con las características
similares (cualidades), el comportamiento común (operaciones), relaciones comunes a otros
objetos, y la semántica común. La persona, la compañía, el animal, el proceso, y la ventana son
Figura 5.55
Representación de una clase con el método Booch
222
todas las clases del objeto. En la Figura 5.56 se muestra una clase según la notación de OMT,
contienen el nombre de la clase, sus atributos y métodos.
Fuente: Rumbaugh (1999)
Shlaer y Mellor (1992) no mencionan ninguna definición explicita de “clase”, sólo hacen una
aproximación de lo que sería una clase.
Para Wrifs-Brock (1999) los objetos que comparten el mismo comportamiento se dice que
pertenecen a la misma clase. Una clase es una especificación genérica para un número arbitrario
de objetos similares. Se puede pensar en una clase como plantilla para una clase específica de
objeto.
Las “clases” en UML
Según Fowler las clases en UML pueden ser representadas de tres (3) maneras:
– Sin detalle
– Detalles a nivel de análisis y diseño
– Detalle a nivel de implementación
Y los atributos pueden describirse como:
visibilidad : tipo = valor-inicial { propiedad }, donde visibilidad puede ser:
– + publico
– # protegido
– - privado
En la Figura 5.57 se muestra una clase según el estándar UML, contienen el nombre de la clase y
sus atributos.
Figura 5.56
Representación de una clase en OMT
223
Fuente: Fowler (2003)
5.3.7. Análisis comparativos entre los diagramas de secuencia de los métodos OO y los de
UML.
En los Métodos OO lo que se conoce como diagramas de interacción (Booch), y diagramas de
seguimientos de sucesos (OMT), se le denominan diagramas de secuencias en UML. En los
diagramas de secuencia por cada escenario que se presenta se construye un diagrama. En las fases
de iniciales de análisis y diseño de un proyecto estos diagramas permite razonar más en detalle
como es el comportamiento de un escenario y de esta manera se pueden obtener nuevas clases y
objetos en el escenario (enriquecimiento del diccionario de datos), además de permitir detectar
cuáles son los métodos de las clases, al observar como se relacionan los objetos entre sí para
llevar a cabo la tarea encomendada en el escenario. Y en la fase de prueba del desarrollo de un
software los diagramas de secuencia se utilizan para validar el código.
Diagramas de interacción (Notación Booch)
Para Booch (1991) un diagrama de interacciones se usa para realizar una traza de la ejecución de
un escenario en el mismo contexto que un diagrama de objetos de la notación Booch. Los
diagramas de interacción toman los elementos esenciales de los diagramas de objetos y los
Figura 5.57
Representación de una clase en UML
224
reestructuran para enfocarlos a la lectura de los mensajes en orden. El orden se indica mediante
la posición vertical, siendo el primer mensaje el de la parte superior y el último el de la parte
inferior. Por tanto no necesitan números de secuencia. Los diagramas de interacción son mejores
que los diagramas de objetos para capturar la semántica de los escenarios en un momento
temprano del ciclo de desarrollo.
Guiones y centros de control
Un guión son las instrucciones generales de cada mensaje del diagrama de interacción.
Los guiones se escriben a la izquierda del diagrama de interacción en lenguaje natural
(español) o en un lenguaje de programación.
Ni los diagramas de objetos ni los diagramas de interacción indican por sí solos el centro de
control a medida que pasan los mensajes.
En el diagrama de interacción se utilizan rectángulos en las líneas verticales de cada objeto
para indicar el tiempo relativo durante el cual el flujo de control está centrado en ese objeto.
En la Figura 5.58 se muestra un ejemplo de un diagrama de interacción según la notación de
Booch.
Fuente: Booch (1991)
Escenarios y seguimientos de sucesos (Notación de OMT)
Un escenario es una secuencia de sucesos que se produce durante una ejecución concreta de un
sistema. El ámbito de un escenario es variable; puede incluir todos los sucesos del sistema, o que
sean generados por ellos. Todo suceso transmite información de un objeto a otro. El primer paso
Figura 5.58
Ejemplo de un diagrama de interacción (Notación Booch)
225
para la construcción de escenario es identificar los objetos emisores y receptores de cada suceso.
La secuencia de sucesos y los objetos que intercambian sucesos se pueden mostrar ambos en un
escenario mejorado que se denomina seguimiento de traza de sucesos. El tiempo aumenta desde
arriba hacia abajo, aunque en el seguimiento de sucesos no importa la temporización exacta, sino
que importa la secuencia de los procesos. Algunos de los pasos para construir un diagrama de
seguimientos de sucesos son los siguientes:
Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y el
sistema.
Identificar los eventos que se dan entre objetos y preparar una traza de eventos para cada
escenario.
En la Figura 5.59 se muestra un ejemplo de un diagrama de seguimiento de sucesos.
Fuente: Rumbaugh (1999)
Diagramas de secuencias en UML
Un diagrama de secuencia como se observa en la Figura 5.60 muestra las interacciones entre
objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y
Figura 5.59
Ejemplo de un diagrama de seguimiento de sucesos
(Notación OMT)
226
la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad
descrita por el escenario. En aplicaciones grandes además de los objetos se muestran también los
componentes y los de casos de uso. En este sentido mostrar los componentes tiene sentido ya que
se trata de objetos reutilizables, en cuanto a los casos de uso hay que recordar que se
implementan como objetos cuyo rol es encapsular lo definido en el caso de uso. Los diagramas de
secuencia enfatizan el orden de tiempo de los mensajes. A diferencia de los anteriores diagramas
estos se corresponden con los escenarios y subescenarios con mucho más detalles y siguen la
misma codificación que los escenarios y subescenarios.
Fuente: Fowler (2003)
5.3.8. Análisis comparativo entre los casos de uso de los métodos OO y los de UML
Diagramas de casos de uso en los métodos OO
El modelo de casos de uso fue desarrollado por Ivar Jacobson cuando desarrollo el método
conocido como OOSE (Ingeniería de Software Orientado a Objetos-ISWOO) para ser utilizado
específicamente en el desarrollo de software orientado a objetos. En este método el modelo de
casos de uso sirve como un modelo central del cual todos los otros modelos son derivados.
Según Jacobson (1992) un caso de uso utilizado en el desarrollo de software orientado a objeto es
una técnica de modelado utilizada para describir lo que un nuevo sistema debe hacer o lo que un
sistema existente ya hace y se construye mediante un proceso iterativo durante las reuniones entre
Figura 5.60
Ejemplo de un diagrama de secuencia UML
227
los desarrolladores del sistema y los clientes (y/o los usuarios finales) conduciendo a una
especificación de requisitos sobre la que todos coinciden. Por otro parte captura algunas de las
acciones y comportamientos del sistema y de los actores.
En cuanto al escenario: a veces se utilizan como sinónimos de casos de uso, sin embargo en
UML un escenario se refiere a los pasos que se desarrollan dentro de un caso de uso
Semejanzas
El sistema que se desea modelar se representa encerrado en un rectángulo.
Los actores son los que interactúan con el sistema. Estos representan lo que necesite
intercambiar con el sistema. Un actor funciona como una clase.
Se diferenciará entre actores y usuarios: el primero representa el papel (rol) que una persona
desempeña y el segundo es una persona que utiliza el sistema. Por ejemplo una persona puede
ser usuario y administrador en un sistema, unas veces actuará como usuario y otras como
administrador, pero deben contemplarse ambos actores.
Los casos de uso es un camino específico para utilizar el sistema.
Para cada caso de uso, Actor y Sistema se realiza una descripción detallada.
Los casos de uso tan sólo indican opciones generales.
El diagrama de casos de uso (Ver Figura 5.61) es un diagrama sencillo que tiene como finalidad
dar una visión global de toda la aplicación de forma que se pueda entender de una forma rápida
y gráfica tanto por usuarios como por desarrolladores.
Fuente: Cueva (1999)
Figura 5.61
Ejemplo de un diagrama de caso de uso
228
Diagramas de casos de uso en UML
Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción
externa. Un caso del uso especifica el comportamiento de un sistema o de una parte de éste y
describe las secuencias de las acciones
Booch et al. (2002) afirma que los diagramas de casos de uso se pueden utilizar para representar
el comportamiento deseado de un sistema, sin la necesidad de especificar cómo este
comportamiento se pone en ejecución. Los diagramas de casos de uso proveen una manera que
los desarrolladores, los especialistas finales del dominio y los usuarios tienen una comprensión
común del problema. Un caso de uso representa un requisito funcional del sistema en su
totalidad.
El diagrama de casos de uso es parte de UML.
Un caso de uso es la típica interacción entre un usuario y un sistema informático.
Un actor es el papel que el usuario juega con respecto al sistema. Un actor no tiene que ser un
humano, puede ser por ejemplo otro sistema externo que pide información al sistema actual
La relación <<extiende>> se utiliza cuando un caso de uso es similar a otro caso de uso pero
se le añade alguna característica nueva.
La relación <<include >> se utiliza cuando se tiene una parte del comportamiento común a
más de un caso de uso, y no se desea almacenar una copia en cada caso de uso de la
descripción de este comportamiento.
Los diagramas de casos describe un conjunto de secuencias, cada una representa una interacción
de los actores externos. Este comportamiento, en la realidad son funciones utilizadas a nivel de
sistema para visualizar, especificar, construir y colocar el comportamiento previsto del sistema
durante el análisis de requisitos.
Análisis a nivel de escenario
Se enumeran escenarios fundamentales para el funcionamiento del sistema.
Se estudia cada escenario utilizando guiones como los que se usan en el cine.
229
Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, así
como los mecanismos que relacionan los objetos.
De los escenarios iniciales se puede pasar a otros escenarios secundarios.
Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas.
El estudio de los escenarios con detalle permite ir enriqueciendo el diccionario de datos.
No es necesario hacer todos los escenarios y sub-escenarios posibles si se observa que no
enriquecen el diccionario de datos.
Los Casos de Uso de UML cubren la carencia existente en los métodos previos (OMT, Booch) en
cuanto a la determinación de requisitos.
5.3.9. Análisis comparativo entre los diagramas de objeto de los métodos OO y los de UML.
Diagrama de objeto (Notación OMT)
El uso de los diagramas de objetos se aplica en la construcción del modelado de objeto. Este
diagrama describe la estructura estática (de datos), de los objetos del sistema (identidad, atributos
y operaciones) y también sus relaciones. El modelo de objetos contiene diagramas de objetos. Un
diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones
entre las clases. El diagrama contiene clases de objetos organizados en jerarquías que comparten
una estructura y comportamiento comunes y que están asociadas a otras clases. Estas clases
definen los atributos que lleva cada instancia de objeto y las operaciones que efectúe o sufre cada
uno. En cada instancia de la clase se guardan los valores de esos atributos.
Los pasos que se llevan a cabo para el modelo de objetos son:
Identificar las clases (y objetos): se seleccionan los sustantivos de la descripción del
problema como posibles clases candidatas y se construye una lista. Se eliminan las clases
redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de
implementación. Las clases se representan por rectángulos con tres compartimientos, en el
primero se pone el nombre de la clase, en el segundo los atributos y en el tercero las
operaciones o métodos.
230
Se añaden las asociaciones y agregaciones entre las clases (y objetos): una asociación es
una dependencia entre dos o más clases. Las asociaciones, se representan por líneas que
unen a las clases sobre las cuales se puede escribir el nombre de la asociación.
Se añaden los atributos de los objetos y sus uniones: los atributos son propiedades de los
objetos tales como nombre, peso, velocidad, etc.
Se organizan y simplifican las clases usando herencia: la herencia se puede usar para
generalizar los aspectos comunes de las clases existentes construyendo una superclase, o
para refinar una clase en subclases especializadas. La notación de OMT para la herencia
es un triángulo debajo de la superclase.
Verificar que existan trayectorias en el modelo de objetos, usando escenarios e iterando
los pasos siguientes como sea necesario.
Agrupar las clases en módulos, basándose en su proximidad y función.
Iterar y refinar el modelo.
Diagrama de objeto (Notación de Booch)
Los diagramas de objeto de la notación de Booch (Ver Figura 5.62) se utilizan como parte de la
estructura lógica de su método, estos diagramas muestra la existencia de objetos y sus relaciones
en la vista lógica de un sistema. En la fase de análisis estos diagramas se usan para indicar la
semántica de los escenarios primarios y secundarios que proporcionan la traza del
comportamiento del sistema y en la fase de diseño se utilizan para ilustrar la semántica de los
mecanismos del diseño lógico. Cada objeto del diagrama se denota con su nombre y
opcionalmente con sus atributos, estos interaccionan a través de enlaces con otros objetos. El
objeto cliente es el objeto que invoca una operación y el objeto servidor es el objeto que
suministra la operación. La relación entre objetos viene dada por medio de una flecha que indica
la dirección de la invocación, así como la operación, y un número de orden (opcional). En la
Figura 5.62 se muestra un ejemplo de un diagrama de objeto según la notación de Booch.
231
Fuente: Booch (1991)
Papeles (roles) y flujo de datos
• Se pueden especificar los papeles (roles) del diagrama de clases en el diagrama de objetos.
• Se pueden indicar también las claves y restricciones del diagrama de clases en el diagrama de
objetos.
• Se muestra explícitamente la dirección del flujo de datos que ayuda a explicar la semántica de
un escenario particular.
• Se indica la dirección del flujo de datos con una flecha y un círculo.
• Se puede usar tanto un objeto como un valor para el flujo de datos.
En la Figura 5.63 se muestran los roles y flujos de datos de un diagrama de objetos.
Fuente: Booch (1991)
Figura 5.63
Ejemplo de flujo de datos
Figura 5.62
Ejemplo de un diagrama de objeto (Notación Booch)
232
Visibilidad de enlace
• En ciertos escenarios es útil reflejar la forma exacta en que un objeto tiene visibilidad sobre otro
• Las marcas de visibilidad son
G - El objeto servidor es global al cliente
P - El objeto servidor es parámetro de alguna operación del cliente
F - El objeto servidor es parte del cliente (field, campo)
L - El objeto servidor es un objeto declarado local en el ámbito del diagrama de objetos
• La ausencia del adorno de visibilidad indica que está sin especificar
En el diagrama de objetos de la Figura 5.64 se muestran los diferentes tipos de visibilidad sobre
un objeto.
Fuente: Booch (1991)
Objetos activos y sincronizados
• Los objetos son activos si incorporan su propio hilo de control
• Todos los objetos son secuenciales a menos de que se diga lo contrario
– sincronismo simple: sólo hay un único hilo de control
• Se puede indicar el estilo de concurrencia de un objeto:
– Síncrono: el cliente espera hasta que el servidor acepte el mensaje
Figura 5.64
Ejemplo de visibilidad
233
– Paso de mensajes con abandono inmediato: el cliente abandona el mensaje si el
servidor no lo atiende inmediatamente
– Sincronización de intervalo (de espera o timeout): el cliente abandona el mensaje si el
servidor no puede atenderlo dentro de un espacio de tiempo determinado.
– Asíncrono: el cliente envía el evento al servidor para que lo procese, el servidor pone
el mensaje en una cola, y el cliente continúa su actividad sin esperar al servidor
En el diagrama de objetos de la Figura 5.65 se muestran los diferentes tipos de sincronismo.
Presupuestos de tiempo y especificaciones
• Para aplicaciones críticas respecto al tiempo se pueden trazar escenarios indicando tiempos
exactos. Se usan valores de tiempo en vez de números de secuencia que indican tiempo relativo
(por ejemplo en segundos) con el signo más delante. En la Figura 5.66 se muestra un diagrama de
objetos donde los tiempos son en segundos.
• Especificaciones. Al igual que para los diagramas de clases cada entidad del diagrama de
objetos puede tener su especificación en texto.
Figura 5.66
Representación de tiempos en un diagrama de objetos
Figura 5.65
Ejemplo de sincronismo
Fuente: Booch (1991)
Fuente: Matteo (2005)
234
Diagramas de objetos (Notación UML)
Los diagramas de objetos de UML (Ver Figura 5.67) modelan las instancias de elementos
contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y
sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para
visualizar los aspectos estáticos del sistema, mientras que los diagramas de interacción se utilizan
para ver los aspectos dinámicos del mismo. Estos cuentan con instancias de los elementos del
diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los
diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el
diagrama de clases, representando sólo la parte estática de un interacción, consistiendo en los
objetos que colaboran pero sin ninguno de los mensajes intercambiados entre ellos.
Los diagramas de objetos se emplean para modelar la vista de diseño estática o la vista de
procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la
perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos
funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos
estáticas.
En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que
implica tomar una instancia de los objetos de un sistema en un cierto momento. Un diagrama de
objetos representa una escena estática representada por un diagrama de interacción. Los
diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia
de ciertas instancias en el sistema, junto a las relaciones entre ellas.
Los diagramas de objetos son especialmente útiles para modelar estructuras de datos complejas.
Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un
conjunto de clases con varias relaciones entre ellas, pueden existir muchas más configuraciones
posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar
significativamente conjuntos interesantes de objetos concretos o prototipos. En la Figura 5.67 se
observa un ejemplo de un diagrama de objetos en UML.
235
desde el diagrama de clases
Fuente: Matteo (2005)
La principal diferencia entre estos diagramas es el uso de mensajes entre objetos, el rol, el uso de
lleves y restricciones, el sincronismo y visibilidad de los enlaces.
Figura 5.67
Ejemplo de un diagrama de objetos en UML
Juan:Usuario
Nombre: “Juan L”
Edad: 22
Lisiu:Ordenador
Marca: “Sun”
UsaJuan:Usuario
Nombre: “Juan L”
Edad: 22
Juan:Usuario
Nombre: “Juan L”
Edad: 22
Lisiu:Ordenador
Marca: “Sun”
Usa
Ordenador
Marca: String
Usuario
Nombre: String
Edad: Integer
Usa0…* 1…*
Ordenador
Marca: String
Usuario
Nombre: String
Edad: Integer
Usa0…* 1…*
Conclusiones
Conclusiones
Para finalizar se puede decir que dentro del área de la computación el desarrollo de software es
importante, pero más importante que esto, es el planteamiento de un proyecto de software que se
le quiere dar solución con sistematización técnica, ya que podría caerse en un error al pensar que
sin el uso de técnicas y métodos se puede llegar fácilmente a la elaboración correcta y eficiente
de un software, lo cual sería posible si se tratase de programas sencillos y pequeños, pero cuando
se tienen que elaborar sistemas de grandes dimensiones y con alto grado de complejidad, se
presentan problemas para su diseño; como alternativa, se debe seguir un orden y aplicar unas
técnicas que deben ser tomadas en consideración para el diseño y la estructura general de un
programa.
La mayoría de los sistemas a desarrollar son complejos, por lo tanto, es necesario descomponerlo
o dividirlo en partes, de manera que sea posible su comprensión. Cada una de esas partes se
pueden representar como modelos que abstraen y describen los aspectos esenciales del sistema.
Por eso, es importante crear, durante la construcción del software, modelos que organicen y
comuniquen los detalles del mundo real con el sistema que son relacionados, así como del
sistema ya construido.
El primer enfoque que se utilizó para descomponer un problema en partes, fue el del análisis
estructurado basado en funciones y procesos, teniendo como resultado una descomposición
jerárquica de los componentes de los procesos en sub-procesos, ello hace posible la construcción
de modelos que representan el flujo y el contenido de la información. El siguiente enfoque fue el
del análisis orientado a objetos, que acentúa la descomposición de un problema, pero desde la
perspectiva de los objetos, clases, cualidades y operaciones como componentes principales a
modelar. Por último, con el surgimiento del UML se siguió el enfoque de descomposición de los
problemas en partes, para una mejor comprensión, pero ahora utilizando diferentes diagramas que
se dividen en estáticos y dinámicos, pero utilizando como base los objetos y las clases.
En esta investigación se ha realizado un análisis comparativo en cuanto a los elementos
estructurales, de relación y entre los diferentes diagramas que se presentan en la programación
estructurada y orientada a objeto con el fin de compararlo con los de UML.
238
En cuanto a los elementos básicos que se presentan en el desarrollo estructural son de tipo
condicional que cambian según los requerimientos del sistema. Se analizan los problemas
mediante los diagramas de flujo de datos, para luego programar una solución, es decir se
desarrolla el sistema haciendo uso de los datos, en este caso, los diagramas de entidad relación se
utilizan para el desarrollo de bases de datos. Los elementos que se presentan en los métodos
orientados a objetos lo hacen con la finalidad de representar objetos y sus clases utilizando
diversos diagramas, unos más completos que otros.
Los elementos estructurales que se presentan en UML son heredados de los elementos
estructurales utilizados en los métodos orientados a objetos, éstos se mantienen constantes en el
tiempo. Estas estructuran varían muy poco en las distintas versiones de UML.
Entre las fortalezas de UML se encuentra que los elementos estructurales que manejan sirven para
modelar tanto procesos estáticos como dinámicos.
Respecto a las relaciones que existen entre los métodos OO y los de UML, muchas de las
relaciones que surgieron en los métodos orientados a objetos fueron adaptadas por UML sin
cambios dramáticos en su teoría. Una crítica generalizada a UML es su generosidad y falta de
semántica precisa para muchos aspectos que se han presentado, y todo esto por su orientación a
ser un estándar notacional para la modelización de cualquier tipo de sistema orientado a objetos.
Sin embargo esto tiene su lado positivo, puede ser adoptado con cierta facilidad a modelos
suficientemente formales y semánticamente ricos. Este es el caso de los métodos OO que tienen
su propia notación gráfica.
En lo referente a los diagramas se puede mencionar muchas diferencias cuando se realiza las
comparaciones respectivas, cada una de estás se reflejan en los resultados de esta investigación.
Lo más resaltante que se observo en los diagramas es que en los métodos OO existe lo que se
conoce como diagramas de navegación que son utilizados para reflejar el flujo de navegación de
los sistemas, en cambio en UML no existen estos tipos de diagramas, existe una ausencia de
herramientas o artefactos para plasmar el mapa de navegación del sistema. Si bien es
relativamente sencillo desarrollarlo mediante herramientas básicas de generación de gráficos y
diagramas, esta situación de libertad de expresión provoca que dependiendo del proyecto o más
239
bien del responsable del diseño, se deba trabajar con diagramas semánticamente similares pero no
idénticos, con los consecuentes problemas potenciales que pueden derivarse de los fallos de la
interpretación.
Otras de las carencias de UML es que no existe una notación especifica para describir modelos de
sistemas de tiempo real orientados a objetos, se puede ver que existe una falta de elementos
específicos predefinidos en el lenguaje para representar otros conceptos estrechamente
relacionados con el diseño de los mismos, tales como: componentes de hardware específicos y
sus características, tareas concurrentes y los mecanismos de comunicación entre ellas o
restricciones temporales especificadas bien a nivel de objetos, de tareas o incluso de hardware.
Estas carencias deberían ser cubiertas en las próximas versiones de UML y de esta manera se va
ir cubriendo todos los modelos que se podría presentar en un sistema.
A pesar de sus carencias UML ofrece un proceso de modelado sin fallas durante el análisis, para
diseñar la implementación, define una notación expresiva y consistente que se basa en estándares,
ayuda a señalar omisiones e inconsistencias en los proyectos desarrollados y soporta tanto
análisis como diseño de pequeños y grandes sistemas.
Por otro lado, se puede resaltar como ventaja de UML es que existe la posibilidad de definir
reglas (usualmente en OCL6) que describen restricciones sobre la semántica de las relaciones,
pudiendo diferenciar las que se dan en los Métodos OO y en UML, pero en este caso no se harán
mención a ellas ya que sólo se estudio la parte de los bloques de construcción de UML.
UML no garantiza el éxito de un proyecto pero permite a los ingenieros centrarse en la entrega de
un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es
soportado directamente por las mejores herramientas de software.
6 OCL es el acrónimo de Object Constraint Language
Bibliografía
Alarcón, Raúl. (2000). Diseño Orientado a Objetos con UML. Grupo EIDOS Consultaría y
Documentación Informática. Madrid-España.
Biggs, Peter. (1999). A Survey of Object-Oriented Methods. University of Durham, Recuperado
el 12 de agosto de 2006 de: http://students.cs.byu.edu/~pbiggs/survey.html.
Böhm, Corrado; Jacopini, Giuseppe. (1996). Flow diagrams, turing machines and languages with
only two formation rules. Communications of the ACM, vol. 9, Nº 5, 366-371.
Booch, Grady. (1991). Object-Oriented Design with Applications. The Benjamin/Cummings
Publishing Company Inc., Redwood City, CA.
Booch, Grady. (1996). Análisis y Diseño Orientado a Objetos con Aplicaciones. México: Pearson
Educación.
Booch, Grady; Rumbaugh, James; Jacobson, Ivar. (1999). El Lenguaje Unificado de Modelado.
(J. Sáez, trad.). Madrid: Addison Wesley Iberoamericana (Original en inglés publicado en
1998).
Booch Grady; Rumbaugh, James; Jacobson, Ivar. (2002). El Lenguaje Unificado de Modelado.
Manual de Referencia. Addison Wesley.
Botelho, Alessandro; Balancieri, Renato; Ferrari, Sandra. (2004). Do Diagrama de Fluxo de
Dados ao Use Case. I Workshop de Computación. Universidad del Sur Santa Catarina.
Brasil. Recuperado el 12 de diciembre de 2006 de:
http://inf.unisul.br/~ines/workcomp/cd/pdfs/3007.pdf.
Castells, Pablo. (2002). Conceptos de Programación Orientada a Objetos. ETS Informática.
Universidad Autónoma de Madrid. Recuperado el 12 de diciembre de 2006 de:
http://www.ii.uam.es/~castells/docencia/poo/1-conceptos.pdf.
Chapin, Ned. (1974). New Format for Flowcharts. Software. Practice and Experiencia. No. 4 pp.
341-357.
240
Coad, Peter; Yourdon, Edward. (1991) Object Oriented Design, Yourdon Press, Englewood
Cliffs, N.J., 1991.
Codd, Edgar. (1970). A Relational Model of Data for Large Shared Data Banks. CACM 13, 6. pp
377-387. Codd, Edgar. (1971). Further Normalization of the Data Base Relational Model.
IBM Research Report, Santa Teresa Lab, San José, California.
Codd, Edgar. (1990). The Relational Model for Database Management. Version 2, Addison
Wesley Publishing Company. DeMarco, Tom. (1979). Structured Analysis and Systems
Specification. Englewood Cliffs, N.J.: Prentice-Hall.
Cruzado, Ignacio; García, Jorge; Portugal, Javier. (2006). Metodologías Orientadas a Objetos.
Trabajo Teórico de Programación Avanzada. Departamento de Ingeniería Civil. Área de
Lenguajes y Sistemas Informáticos. Universidad de Burgos – España. Recuperado el 21
de junio de 2006 de: http://pisuerga.inf.ubu.es/icruzado/tfc/Metodologias.pdf.
Cueva, Juan. (1999). Introducción a UML: Lenguaje para Modelar Objetos. Departamento de
Informática. Universidad de Oviedo – España. Recuperado el 10 de febrero de 2007 de:
http://gidis.ing.unlpam.edu.ar/downloads/pdfs/IntroduccionUML.PDF.
Diagrama de Paquetes (2006, 14) de septiembre. Wikipedia, La enciclopedia libre. Fecha: de
consulta: 20:42, septiembre 25, 2006 desde http://es.wikipedia.org/wiki/Diagrama_de_paquetes.
Díaz, Gregorio. (2007). Diseño y Programación Orientada a Objetos. Ingeniería en Informática.
Universidad de Castilla – España. Recuperado el 10 de febrero de 2007 de:
http://www.info-ab.uclm.es/asignaturas/42579/.
Dorantes, Víctor; Magariños, Fernando; Jury, José. (2001). Curso de Bases de Datos y
PostgreSQL. Recuperado el 04 de julio de 2007 de: http://es.tldp.org/Tutoriales/NOTAS-
CURSO-BBDD/notas-curso-BD/node20.html.
Eriksson, Hans-Erik; Penker, Magnus. (1997). UML Toolki. Wiley Computer Publishing. New
York USA. Recuperado el 04 de julio de 2007 de: http://www.fi-
b.unam.mx/pp/profesores/carlos/aydoo/uml.html.
Fowler, Martin. (2003). UML Destilled: A Brief guide to the Tandard Object modeling Languaje.
Third Edition. Addison Wesley.
241
Gacitúa, Ricardo. (2003). Métodos de Desarrollo de Software: El Desafió Pendiente de la
Estandarización. Dpto. Sistemas de Información, Facultad de Ciencias Empresariales,
Universidad del Bío-Bío, Avda. Collao 1202, Concepción, Chile, e-mail:
rgacitua@ubiobio.cl.n. Theoria, Vol. 12: 23-42. Recuperado el 10 de octubre de 2006 de:
http://redalyc.uaemex.mx/redalyc/pdf/299/29901203.pdf.
Gagliardi, Edilma (2003). Modelado Conceptual de Bases de Datos. Universidad Nacional de
San Luís. Ciclo Electivo. Recuperado el 24 de septiembre de 2006 de:
http://www.dirinfo.unsl.edu.ar/~bdtw/BD/teorias/modelado-rev06.ps.
Gane, Chris; Sarson, Trish. (1977). Análisis Estructurado de Sistemas. Quinta reimpresión.
Buenos Aires, Editorial El Ateneo.
Gane, Chris; Sarson, Trish. (1978). Structured Systems Analysis: Tool and Techniques.
Englewood Cliffs, N.J.: Prentice-Hall.
Gane, Chirs. (1988). Desenvolvimento Rápido de Sistemas. Libros Técnicos y Científicos Editora
LTDA, Río de Janeiro.
Gane, Chris; Sarson, Trish. (1990). Análisis Estructurado de Sistemas. Buenos Aires: El Ateneo
(traducción de Gane, C. and T. Sarson, Structured systems analysis, tools and techniques.
Software series. 1979, New Jersey: Prentice-Hall.).
Graham., Ian. (1994). Migrating to Object Technology. Workingham: Adison-Wesley
Hutchings, Timothy. (1997). Introduction to SSADM. Recuperado el 29 de octubre de 2006 de:
http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4/index.htm.
IBM (1974). HIPO: A Design Aid and Documentation Technique. Publication Number GC20-
1851. White Planis, NY: IBM Corporation Data Processing.
Insfrán, Emilio; Pelechado, Vicente; Gómez, Jaime; Pastor, Oscar. (2001). Un estudio
comparativo de la expresividad de relaciones entre clases en OO-Method y UML.
Departamento de Sistemas de Información y Computación. Universidad Politécnica de
Valencia – España, S/N, 46071. Recuperado el 20 de marzo de 2006 de:
http://www.dsic.upv.es/~einsfran/papers/09-JIS98.pdf.
242
Jackson, Michael. (1975). Principles of Program Design. New York: Academia Press Inc.
Jackson, Michael. (1983). System Development. Englewood Cliffs. New Jersey. Prentice-Hall.
Jacobson, Ivar. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach.
Addison-Wesley.
Jacobson, Ivar. (1993). Time for a cease-fire in the methods war. The Road to the Unified
Software Development Process. Parte 3 Cap. 4 p.59.
Jacobson, Ivar., Christerson, Magnus; Jonsson, Patrik; Overgaard, Gunnar. (1992). Object-
Oriented Software Engineering - A Use Case Driven Approach. ACM Press, Addison-
Wesley, Reading, Mass.
Joyanes, Luis (1992). Fundamentos de Programación. Algoritmos y Estructuras de Datos Mc
Graw-Hill. Mexico.
Kenneth, Orr (1977). Structured Systems Development. New York. Yourdon Press.
Larman, Craig. (2004). UML y Patrones. Una Introducción al Análisis y Diseño Orientado a
Objetos y al Proceso Unificado. Prentice Hall.
Letelier, Patricio. (1996). Desarrollo de Software Orientado a Objeto usando UML.
Departamento Sistemas Informáticos y Computación. Universidad de Valencia. España.
Recuperado el 29 de octubre de 2006 de: http://www.dsic.upv.es/~uml/curso.pdf.
Loucopoulos, Pericles; Karakostas Vassilios. (1995). Systems Requirements Engineering.
McGraw-Hill, New York, USA.
Losavio, Francisca; Chirinos, Ledis; Lévy, Nicole; Ramdane-Cherif, Amar. (2003). Quality
Characteristics for Software Architecture. Recuperado el 05 de agosto de 2006 de:
http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT
Journal of Object Technology. Vol. 2, No. 2, March-April.
Macías del Campo, Javier. (2006). Ingeniería del Software: UML. Material de Apoyo de I.T.I.G.
e Ingeniería Electronica de la Universidad de Alcalá – España. Recuperado el 05 de enero
243
de 2007 de: http://www.desarrollos-mecame.com/formacion/Ingenieria-
Software/Ingenieria%20software_archivos/temaUML.doc
Martin, James; McClure, Carma. (1985). Structured Techniques for Computing. Englewood
Cliffs. New Jersey. Prentice-Hall.
Martin, James; Odell, James. (1992). Object Oriented Analysis and Design, Englewood Cliffs,
NJ, Prentice Hall.
Matteo, Alfredo. (2005). Unifield Modeling Language 2.0. Modulos. 1,2 y 3. Material no
publicado. Universidad Central de Venezuela (UCV). Postgrado en Ciencias de la
Computación. Asignatura Ingeniería de Modelos.
Mercedes, Avda. (2004). Bases de Datos, Modelo Relacional de Cood, Estructuras y
Restricciones. Departamento de Lenguajes y Sistemas Informáticos. ETS Ingeniería
Informática. Universidad de Sevilla. España. Recuperado el 11 de septiembre de 2006 de:
http://www.lsi.us.es/docencia/get.php?id=1453.
Morales, Alicia; Rugerio Alma. (2003). Metodologías para generación de Sistemas Orientados a
Objetos. Recuperado el 21 de noviembre de 2006 de:
http://ccc.inaoep.mx/~labvision/doo/proy/T32.pdf.
Murillo, Félix. (2002) Técnicas de Programación. Instituto Nacional de Estadística e Informática.
Colección Informática Fácil. Recuperado el 04 de julio de 2007 de:
http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5115/Libro.pdf
Myers, Glen. (1975). Reliable Systems through Composite design. New York: 1ra Ed. Petrocelli
Charter.
Nassi, Isaac; Shneiderman, Ben. (1973). Flowchart Techniques for Structured Programming.
ACM SIGPLAN Notices, No.8, pp 12-26.
Oktaba, Hanna. (1999). Tecnologías Orientadas a Objetos – OMT. Postgrado en Ciencia e
Ingeniería de la Computación. Universidad Nacional Autónoma de México. Recuperado
el 17 de diciembre de 2006 de: http://www.mcc.unam.mx/~cursos/Objetos/Omt/omt.html.
244
Page-Jones, Meilir. (1980): The Practical Guide to Structured Systems Design. 1ra Ed. Yourdon
Press.
Pastor, Oscar; Ramos, Isidro. (1997). Oasis 2.2: A Class-Definition Language to Model
Information Systems Using an Object-Oriented Approach. SPUPV-95.788, Universidad
Politécnica de Valencia.
Pérez, Mario. (2002). Análisis y Diseño Orientado a Objetos usando la notación UML.
Universidad Nacional de Colombia. Basada en material de la Universidad Politécnica de
Valencia. Recuperado el 05 de septiembre de 2006 de:
http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CursoOOconUML.pdf.
Peter, Chen, (1976). The Entity-Relationship model. Tower A Unified View of Data. ACM
Transactions on Database System, Vol. 1, número 1, pp. 9-36.
Peter, Chen, (1977). The Entity-Relationship Approach to Logical Database Design. Wellesley,
Mass.:Q.E.D. Information Sciences.
Piattini, Mario; De Miguel, Adoración. (1939). Concepción y Diseño de Bases de Datos del
Modelo E/R al Modelo Relacional. Adison Wesley Iberoamericana México.
Pickin, Simon. (2005). Introducción a UML. Departamento de Ingeniería Telemática.
Universidad Carlos III de Madrid. España. spickin@it.uc3m.es. Recuperado el 14 de
septiembre de 2006 de:
http://www.hacktegus.com/univ/UNICAH/CASE/Gu%EDa%20de%20Estudio%20y%20
Manuales/UML_Presentacion.pdf.
Presman, Roger. (2001). Ingeniería del Software. Un enfoque Práctico. Quinta Edición. McGraw
Hill.
Robinson, Peter. (1992). Hierarchical Object-Oriented Design. Prentice Hall, London.
Robinson, Peter. (1992). Introduction and Overview. In: Object-Oriented Design. Robinson, P.J.
ed.; Chapman & Hall, London; pp 1-10.
Rossi, Bibiana; Britos, Paola; García, Ramón. (1998). Modelado de Objetos. Revista del Instituto
Tecnológico de Buenos Aires - Argentina, vol. 21, p.24–32. ISSN/ISBN: 03261840.
245
Recuperado el 17 de enero de 2007 de: http://www.itba.edu.ar/capis/webcapis/RGMITBA/articulosrgm/R-
ITBA-21-modeladodeobjetos.pdf.
Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William.
(1991). Object Oriented Modelling and Design. Prentice-Hall, Englewood Cliffs, N.J.
Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William.
(1999); Modelado y Diseño Orientados a Objetos; Metodología OMT. España: Prentice
Hall.
Sánchez, Jorge. (204). Principios sobre Bases de Datos Relacionales. Licencia de Creative
Commons del tipo Attribution-Non Comercial-ShareAlike. Recuperado el 03 de agosto de
2006 de: http://www.jorgesanchez.net/bd/bdrelacional.pdf.
Shlaer, Sally; Mellor, Stephen. (1988). Object-Oriented Systems Analysis: Modeling the World in
Data, Yourdon Press, Englewood Cliffs, N.J.
Sommerville, Ian. (2005). Ingeniería de Software .Addison-Wesley. Séptima Edición.
Vallejos, Oscar. (2001). OMT: Tema 8 de Análisis de Sistema I. Facultad de Ciencias Exactas y
Naturales y Agrimisura. Universidad de Nordeste – Argentina. Recuperado el 11 de
noviembre de 2006 de:
http://exa.unne.edu.ar/depar/areas/informatica/anasistem1/public_html/Marco-Temas.htm.
Warnier, Jean. (1981). Logical Construction of Systems. New York. Editorial Van Nostrand
Reinhold. pp.11-38.
Wasserman, Anthony; Pircher, Peter; Muller, Robert. (1990). The object-oriented structured
design notation for software design representation. IEEE Computer, Marzo, 50-62.
Webster`s New World Dictonary (1980). Second Collage Edition, New York: Simon & Schuster.
Weitzenfeld, Alfredo. (2004). Ingeniería de Software Orientada a Objetos con UML, Java e
Internet. Editorial Thomson Learning. Recuperado el 04 de julio de 2007 de:
ftp://ftp.itam.mx/pub/investigadores/alfredo/OBJETOS/MINT/Cap3-Procsw.pdf
246
Wirfs-Brock, Rebecca; Wilkerson, Brian; Wiener, Lauren. (1990). Designing Object Oriented
Software. Prentice-Hall, Englewood Cliffs, N.J.
Yourdon, Edward. (1989). Análisis Estructurado Moderno. Prentice –Hall. México.
Yourdon Edgard; Constantine Larry. (1975). Structured Design. 2da Ed. Englewood Cliffs,
Prentice Hall.
Yourdon Edward; Constantine, Larry. (1978). Structured Design. New York: Yourdon Press. pp.
42-50.