SlideShare una empresa de Scribd logo
1 de 242
Descargar para leer sin conexión
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ón
N
A
S
condición
N
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 changes
Balance 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 changes
Balance 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
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
Externas
Entidades
Externas
Procesos
Procesos
Almacenes
de Datos
Almacenes
de Datos
Flujo de Datos
Entidades
Externas
Entidades
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
NumCliente
NumCliente,
NumAnimal
NumAnimal
NumAnimalNumCliente
Recibir
muestra
Comprobar
cliente
Alta
cliente
Alta
muestra
Comprobar
animal
Alta
animal
NumCliente
NumCliente,
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
Y
Z 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
Y
Z 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)
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software
UML. Un análisis comparativo para la diagramación de software

Más contenido relacionado

La actualidad más candente

Analisis e implementacion de un sistema de información de una tienda de abarr...
Analisis e implementacion de un sistema de información de una tienda de abarr...Analisis e implementacion de un sistema de información de una tienda de abarr...
Analisis e implementacion de un sistema de información de una tienda de abarr...leidyshernandez23
 
Tema3 modelo relacional - normalización
Tema3   modelo relacional - normalizaciónTema3   modelo relacional - normalización
Tema3 modelo relacional - normalizaciónAlvaro Loustau
 
Estructuras repetitivas
Estructuras repetitivasEstructuras repetitivas
Estructuras repetitivasVictor Zapata
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativojorge paez
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientosFSILSCA
 
Analisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de SoftwareAnalisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de SoftwareMarvin Romero
 
Especificación de Requerimientos
Especificación de RequerimientosEspecificación de Requerimientos
Especificación de RequerimientosUTPL UTPL
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidosChristian19121
 
Dependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosDependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosEsteban Andres Diaz Mina
 
Alfabetos-Lenguajes y Automatas 1
Alfabetos-Lenguajes y Automatas 1Alfabetos-Lenguajes y Automatas 1
Alfabetos-Lenguajes y Automatas 1Osiris Mirerus
 
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A ObjetosMetodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetoshector_h30
 
Base de datos distribuidas vs centralizadas
Base de datos distribuidas vs centralizadasBase de datos distribuidas vs centralizadas
Base de datos distribuidas vs centralizadasEduardo Simon Hernandez
 

La actualidad más candente (20)

Examen complexivo sql resuelto
Examen complexivo sql resueltoExamen complexivo sql resuelto
Examen complexivo sql resuelto
 
Analisis e implementacion de un sistema de información de una tienda de abarr...
Analisis e implementacion de un sistema de información de una tienda de abarr...Analisis e implementacion de un sistema de información de una tienda de abarr...
Analisis e implementacion de un sistema de información de una tienda de abarr...
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
 
Tema3 modelo relacional - normalización
Tema3   modelo relacional - normalizaciónTema3   modelo relacional - normalización
Tema3 modelo relacional - normalización
 
Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
 
Estructuras repetitivas
Estructuras repetitivasEstructuras repetitivas
Estructuras repetitivas
 
Modelo entidad relación
Modelo entidad relaciónModelo entidad relación
Modelo entidad relación
 
9.laravel
9.laravel9.laravel
9.laravel
 
Gestores de bases de datos cuadros comparativos
Gestores de bases de datos cuadros comparativosGestores de bases de datos cuadros comparativos
Gestores de bases de datos cuadros comparativos
 
Cuadro comparativo
Cuadro comparativoCuadro comparativo
Cuadro comparativo
 
Clasificación de los requerimientos
Clasificación de los requerimientosClasificación de los requerimientos
Clasificación de los requerimientos
 
Analisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de SoftwareAnalisis de requerimientos, Ingenieria de Software
Analisis de requerimientos, Ingenieria de Software
 
Especificación de Requerimientos
Especificación de RequerimientosEspecificación de Requerimientos
Especificación de Requerimientos
 
Sistemas operativos distribuidos
Sistemas operativos distribuidosSistemas operativos distribuidos
Sistemas operativos distribuidos
 
Dependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosDependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de Datos
 
Alfabetos-Lenguajes y Automatas 1
Alfabetos-Lenguajes y Automatas 1Alfabetos-Lenguajes y Automatas 1
Alfabetos-Lenguajes y Automatas 1
 
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A ObjetosMetodologías Para AnáLisis Y DiseñO Orientado A Objetos
Metodologías Para AnáLisis Y DiseñO Orientado A Objetos
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Base de datos distribuidas vs centralizadas
Base de datos distribuidas vs centralizadasBase de datos distribuidas vs centralizadas
Base de datos distribuidas vs centralizadas
 
Tema 4: Procesamiento paralelo.
Tema 4: Procesamiento paralelo.Tema 4: Procesamiento paralelo.
Tema 4: Procesamiento paralelo.
 

Destacado

Titulo en Ciencias de la Computación
Titulo en Ciencias de la Computación Titulo en Ciencias de la Computación
Titulo en Ciencias de la Computación Yaskelly Yedra
 
Categorización de usuarios de Twitter
Categorización de usuarios de TwitterCategorización de usuarios de Twitter
Categorización de usuarios de TwitterYaskelly Yedra
 
Generador de Patrones de Diseño (GEPADI)
Generador de Patrones de Diseño (GEPADI)Generador de Patrones de Diseño (GEPADI)
Generador de Patrones de Diseño (GEPADI)Yaskelly Yedra
 
Reglamento para la presentacion de trabajos en la Universidad del Zulia
Reglamento para la presentacion de trabajos en la Universidad del ZuliaReglamento para la presentacion de trabajos en la Universidad del Zulia
Reglamento para la presentacion de trabajos en la Universidad del ZuliaYaskelly Yedra
 
Formato de minuta de reunión
Formato de minuta de reuniónFormato de minuta de reunión
Formato de minuta de reuniónYaskelly Yedra
 
La organización como un teatro: la tecnología y sistemas de información como ...
La organización como un teatro: la tecnología y sistemas de información como ...La organización como un teatro: la tecnología y sistemas de información como ...
La organización como un teatro: la tecnología y sistemas de información como ...Yaskelly Yedra
 
Sistemas transparente para gobierno electrónico eficientes
Sistemas transparente para gobierno electrónico eficientesSistemas transparente para gobierno electrónico eficientes
Sistemas transparente para gobierno electrónico eficientesYaskelly Yedra
 
Programa por competencias de Introducción a la Computación para biología
Programa por competencias de Introducción a la Computación para biologíaPrograma por competencias de Introducción a la Computación para biología
Programa por competencias de Introducción a la Computación para biologíaYaskelly Yedra
 
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...Yaskelly Yedra
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
 
Conceptos básicos sobre sistemas de información
Conceptos básicos sobre sistemas de información Conceptos básicos sobre sistemas de información
Conceptos básicos sobre sistemas de información Yaskelly Yedra
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML1da4
 
Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)Yaskelly Yedra
 
Red GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaRed GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaYaskelly Yedra
 
Intranet basada en multiplataforma para el apoyo a la toma de decisiones
Intranet basada en multiplataforma para el apoyo a la toma de decisionesIntranet basada en multiplataforma para el apoyo a la toma de decisiones
Intranet basada en multiplataforma para el apoyo a la toma de decisionesYaskelly Yedra
 
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...Manual de sistema de una Intranet basada en multiplataforma para la toma de d...
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...Yaskelly Yedra
 
actividades de soporte casos
actividades de soporte   casosactividades de soporte   casos
actividades de soporte casosTgestionaBlog
 

Destacado (20)

Titulo en Ciencias de la Computación
Titulo en Ciencias de la Computación Titulo en Ciencias de la Computación
Titulo en Ciencias de la Computación
 
Categorización de usuarios de Twitter
Categorización de usuarios de TwitterCategorización de usuarios de Twitter
Categorización de usuarios de Twitter
 
Generador de Patrones de Diseño (GEPADI)
Generador de Patrones de Diseño (GEPADI)Generador de Patrones de Diseño (GEPADI)
Generador de Patrones de Diseño (GEPADI)
 
Reglamento para la presentacion de trabajos en la Universidad del Zulia
Reglamento para la presentacion de trabajos en la Universidad del ZuliaReglamento para la presentacion de trabajos en la Universidad del Zulia
Reglamento para la presentacion de trabajos en la Universidad del Zulia
 
Formato de minuta de reunión
Formato de minuta de reuniónFormato de minuta de reunión
Formato de minuta de reunión
 
La organización como un teatro: la tecnología y sistemas de información como ...
La organización como un teatro: la tecnología y sistemas de información como ...La organización como un teatro: la tecnología y sistemas de información como ...
La organización como un teatro: la tecnología y sistemas de información como ...
 
Sistemas transparente para gobierno electrónico eficientes
Sistemas transparente para gobierno electrónico eficientesSistemas transparente para gobierno electrónico eficientes
Sistemas transparente para gobierno electrónico eficientes
 
Programa por competencias de Introducción a la Computación para biología
Programa por competencias de Introducción a la Computación para biologíaPrograma por competencias de Introducción a la Computación para biología
Programa por competencias de Introducción a la Computación para biología
 
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...
Impacto de las tecnologías de telecomunicaciones en los patrones de comunicac...
 
Metodologia de evaluacion uml
Metodologia de evaluacion umlMetodologia de evaluacion uml
Metodologia de evaluacion uml
 
UML. un analisis comparativo para la diagramación de software
UML.  un analisis comparativo para la diagramación de softwareUML.  un analisis comparativo para la diagramación de software
UML. un analisis comparativo para la diagramación de software
 
Conceptos básicos sobre sistemas de información
Conceptos básicos sobre sistemas de información Conceptos básicos sobre sistemas de información
Conceptos básicos sobre sistemas de información
 
Cuestionario
CuestionarioCuestionario
Cuestionario
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)Diagrama de Flujo de Datos (DFD)
Diagrama de Flujo de Datos (DFD)
 
Red GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaRed GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado Zulia
 
Intranet basada en multiplataforma para el apoyo a la toma de decisiones
Intranet basada en multiplataforma para el apoyo a la toma de decisionesIntranet basada en multiplataforma para el apoyo a la toma de decisiones
Intranet basada en multiplataforma para el apoyo a la toma de decisiones
 
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...Manual de sistema de una Intranet basada en multiplataforma para la toma de d...
Manual de sistema de una Intranet basada en multiplataforma para la toma de d...
 
actividades de soporte casos
actividades de soporte   casosactividades de soporte   casos
actividades de soporte casos
 

Similar a UML. Un análisis comparativo para la diagramación de software (20)

Modelado sistemas UML
Modelado sistemas UMLModelado sistemas UML
Modelado sistemas UML
 
200609
200609200609
200609
 
Estanislao contreras object-oriented_y_uml
Estanislao contreras object-oriented_y_umlEstanislao contreras object-oriented_y_uml
Estanislao contreras object-oriented_y_uml
 
Uml
UmlUml
Uml
 
Modelado, Ingenieria de Software
Modelado, Ingenieria de SoftwareModelado, Ingenieria de Software
Modelado, Ingenieria de Software
 
Uml
UmlUml
Uml
 
Uml
UmlUml
Uml
 
sesion 1 - MAS.pptx
sesion 1 - MAS.pptxsesion 1 - MAS.pptx
sesion 1 - MAS.pptx
 
UTML
UTMLUTML
UTML
 
Uml tojava v2
Uml tojava v2Uml tojava v2
Uml tojava v2
 
Portafolio ing sotware ii
Portafolio ing sotware iiPortafolio ing sotware ii
Portafolio ing sotware ii
 
Camtasia Getting Started Guide
Camtasia Getting Started GuideCamtasia Getting Started Guide
Camtasia Getting Started Guide
 
Introduccion a la ingenieria de software
Introduccion a la ingenieria de softwareIntroduccion a la ingenieria de software
Introduccion a la ingenieria de software
 
UML
UMLUML
UML
 
UML_Clase_01
UML_Clase_01UML_Clase_01
UML_Clase_01
 
Ptordoya tfc0111
Ptordoya tfc0111Ptordoya tfc0111
Ptordoya tfc0111
 
Modelado Unificado (UML)
Modelado Unificado (UML)Modelado Unificado (UML)
Modelado Unificado (UML)
 
Uml
UmlUml
Uml
 
Diseño Estructurado de Algoritmos
Diseño Estructurado de AlgoritmosDiseño Estructurado de Algoritmos
Diseño Estructurado de Algoritmos
 
cursoUML.ppt
cursoUML.pptcursoUML.ppt
cursoUML.ppt
 

Más de Yaskelly Yedra

Es una aplicación de software que automatiza e integra tanto los procesos de...
Es una aplicación de software que  automatiza e integra tanto los procesos de...Es una aplicación de software que  automatiza e integra tanto los procesos de...
Es una aplicación de software que automatiza e integra tanto los procesos de...Yaskelly Yedra
 
Manual de descripcion de cargos para una empresa de desarrollo de software
Manual de descripcion de cargos para una empresa de desarrollo de softwareManual de descripcion de cargos para una empresa de desarrollo de software
Manual de descripcion de cargos para una empresa de desarrollo de softwareYaskelly Yedra
 
Manual del usuario de una Intranet multiplataforma para la toma de decisión
Manual del usuario de una Intranet multiplataforma para la toma de decisiónManual del usuario de una Intranet multiplataforma para la toma de decisión
Manual del usuario de una Intranet multiplataforma para la toma de decisiónYaskelly Yedra
 
Ciclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionCiclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionYaskelly Yedra
 
Red GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaRed GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaYaskelly Yedra
 
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...Metodología para el desarrollo de portales de gobierno electrónico bajo el en...
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...Yaskelly Yedra
 
Introducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de UsoIntroducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de UsoYaskelly Yedra
 
Modelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webModelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webYaskelly Yedra
 
Planificación de proyectos de software
Planificación de proyectos de software Planificación de proyectos de software
Planificación de proyectos de software Yaskelly Yedra
 
Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)Yaskelly Yedra
 
Introducción a la computación
Introducción a la computaciónIntroducción a la computación
Introducción a la computaciónYaskelly Yedra
 
Plantilla para realizar el manual de sistema o del analista
Plantilla para realizar el manual de sistema o del analista Plantilla para realizar el manual de sistema o del analista
Plantilla para realizar el manual de sistema o del analista Yaskelly Yedra
 
Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Yaskelly Yedra
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoFYaskelly Yedra
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
 

Más de Yaskelly Yedra (15)

Es una aplicación de software que automatiza e integra tanto los procesos de...
Es una aplicación de software que  automatiza e integra tanto los procesos de...Es una aplicación de software que  automatiza e integra tanto los procesos de...
Es una aplicación de software que automatiza e integra tanto los procesos de...
 
Manual de descripcion de cargos para una empresa de desarrollo de software
Manual de descripcion de cargos para una empresa de desarrollo de softwareManual de descripcion de cargos para una empresa de desarrollo de software
Manual de descripcion de cargos para una empresa de desarrollo de software
 
Manual del usuario de una Intranet multiplataforma para la toma de decisión
Manual del usuario de una Intranet multiplataforma para la toma de decisiónManual del usuario de una Intranet multiplataforma para la toma de decisión
Manual del usuario de una Intranet multiplataforma para la toma de decisión
 
Ciclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacionCiclo de vida de los sistemas de informacion
Ciclo de vida de los sistemas de informacion
 
Red GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado ZuliaRed GSM de Telefonía Básica para el Estado Zulia
Red GSM de Telefonía Básica para el Estado Zulia
 
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...Metodología para el desarrollo de portales de gobierno electrónico bajo el en...
Metodología para el desarrollo de portales de gobierno electrónico bajo el en...
 
Introducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de UsoIntroducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de Uso
 
Modelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones webModelos de desarrollo de aplicaciones web
Modelos de desarrollo de aplicaciones web
 
Planificación de proyectos de software
Planificación de proyectos de software Planificación de proyectos de software
Planificación de proyectos de software
 
Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)Ingenieria de software (conceptos básicos)
Ingenieria de software (conceptos básicos)
 
Introducción a la computación
Introducción a la computaciónIntroducción a la computación
Introducción a la computación
 
Plantilla para realizar el manual de sistema o del analista
Plantilla para realizar el manual de sistema o del analista Plantilla para realizar el manual de sistema o del analista
Plantilla para realizar el manual de sistema o del analista
 
Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software Plantilla para realizar un manual de usuario de software
Plantilla para realizar un manual de usuario de software
 
Patrones de diseño de GoF
Patrones de diseño de GoFPatrones de diseño de GoF
Patrones de diseño de GoF
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de información
 

UML. Un análisis comparativo para la diagramación de software

  • 1. 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
  • 2. 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
  • 3.
  • 4. 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.
  • 5. 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.
  • 6. Í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
  • 7. 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
  • 8. 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
  • 10. Í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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. Í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
  • 15. 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. .
  • 16. 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.
  • 17. 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.
  • 18. Modelo Conceptual de Desarrollo de Software CAPITULO
  • 19. 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,
  • 20. 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.
  • 21. 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.
  • 22. 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.
  • 23. 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.
  • 24. 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
  • 25. 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.
  • 26. 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).
  • 27. 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.
  • 28. 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.
  • 29. 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.
  • 31. 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.
  • 32. 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.
  • 33. 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 ....
  • 34. 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.
  • 35. 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.
  • 36. 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
  • 37. 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
  • 38. 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)
  • 39. 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”
  • 40. 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ón N A S condición N A
  • 41. 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)
  • 42. 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>
  • 43. 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>
  • 44. 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.
  • 45. 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
  • 46. 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
  • 47. 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
  • 48. 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)
  • 49. 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
  • 50. 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 changes Balance 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 changes Balance Changs Balance Change * Pymnt O Made Order o Acept Detail change * Nam O Addr O Tel O
  • 51. 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 Fuente: Gacitúa (2003)
  • 52. 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 Externas Entidades Externas Procesos Procesos Almacenes de Datos Almacenes de Datos Flujo de Datos Entidades Externas Entidades 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
  • 53. 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
  • 54. 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
  • 55. 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 NumCliente NumCliente, NumAnimal NumAnimal NumAnimalNumCliente Recibir muestra Comprobar cliente Alta cliente Alta muestra Comprobar animal Alta animal NumCliente NumCliente, NumAnimal NumAnimal NumAnimalNumCliente Figura 2.27 Ejemplo de un diagrama de estructura de datos
  • 56. 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.
  • 57. 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
  • 58. 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 Y Z 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 Y Z 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)