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

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

[email protected]

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


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


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


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”


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.


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”


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”


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”


S

condición

N

A

S

condición

N

A

S

condiciónN

A

S

condiciónN

A

43

2.1.2 Diagrama de Nassi−Schederman (N-S)

El modelo de diagramas fue desarrollado por Isaac Nassi y Ben Shneiderman, publicándose en el

año 1973. Corresponden a las normas DIN 66261 e ISO/IEC 8631:1989. Dado que muestran las

estructuras de un programa, también se denominan “estructogramas”.

Los diagramas estructurados N-S también conocido como diagrama de chapin son como los

diagrama de flujo con la diferencia que en estos diagramas se omiten las flechas de unión y las

cajas son contiguas. Un enfoque más estructurado, pero menos visual, para el diseño y la

documentación de estos diagramas.

Los diagramas NS tienen tres símbolos principales: el primero es un cuadro que sirve para

representar cualquier proceso en el programa; el segundo símbolo es una decisión; y el tercero es

un cuadro dentro de otro cuadro que se utiliza para indicar que se lleva a cabo una interacción.

Las acciones sucesivas se pueden escribir en cajas sucesivas y como en los diagramas de flujo, se

pueden escribir diferentes acciones en una caja.

Una de las ventajas de estos diagramas es que adopta la filosofía de la programación estructurada,

que utiliza un enfoque descendente, utiliza un número limitado de símbolos de tal forma que el

diagrama de flujo ocupa menos espacio y puede leerse con cierta finalidad. Estos diagramas

deben estar completos y ser muy claros, con el fin de que se entiendan. En la Figura 2.10 se

muestra la estructura de estos diagramas.

Figura 2.10

Ejemplo de diagrama N-S

Fuente: Martin y McClure (1985)

44

Estructuras básicas de los diagramas N-S

Secuencia: Sucesión de dos o más operaciones cuya ejecución coincide con el orden de aparición

de las instrucciones. En la Figura 2.11 se muestra un ejemplo de esta estructura.

Figura 2.11

Estructura secuencial de un diagrama N-S


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


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”


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.


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)


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.



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.


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.


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.


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.


Figura 2.21

Modelos de flujo de datos

Figura 2.22

Modelo de comportamiento de las entidades

Customer

Accounts1

D1

Check customer

Detaild and

Create orde

Ordes

Customer

Accounts1

D1

Check customer

Detaild and

Create orde

Ordes

Customer

First Order

Placed

My life

Cy ole Outstanding

Balance =0

And o ordes

For 6 mths

Detail changesBalance Changs

Balance Change *

Pymnt O

Made

Order o

Acept

Detail change *

Nam O Addr O Tel O

Customer

First Order

Placed

My life

Cy ole Outstanding

Balance =0

And o ordes

For 6 mths

Detail changesBalance Changs

Balance Change *

Pymnt O

Made

Order o

Acept

Detail change *

Nam O Addr O Tel O

53

Cada uno de estos tres modelos del sistema proporciona un punto de vista del mismo sistema, y

cada punto de vista se requiere para formar un modelo completo del sistema que se está

diseñando.

Los proyectos desarrollados bajo SSADM se dividen en cinco (5) módulos:

Estudio de viabilidad: se analiza el área comercial para determinarse si un sistema puede contar

con la eficacia de los requisitos del negocio.

Análisis de requisitos: para ser convertido los requisitos del sistema es necesario que se

identifique y se modele el ambiente de negocio actual en los términos de procesos realizados y de

las estructuras de datos implicadas.

Especificación de requisitos: en este módulo se identifican los requisitos funcionales y no

funcionales detallados y las nuevas técnicas se introducen para definir las estructuras requeridas

del proceso y de los datos.

Especificación de sistema lógica: se producen las opciones técnicas de los sistemas y el diseño

lógico de los diálogos de la actualización, del proceso y del sistema de la investigación.

Diseño físico: un diseño de base de datos físico y un sistema de especificaciones del programa se

crean usando la especificación de sistema lógico y las especificaciones del sistema.

SSADM construye cada paso del proyecto prescrito en el paso anterior sin la desviación del

modelo.

Entidades

Externas

Entidades

Externas

Procesos

Procesos

Procesos

Almacenes

de Datos

Almacenes

de Datos

Entidades

Externas

Entidades

Externas

Procesos

Procesos

Procesos

Almacenes

de Datos

Almacenes

de Datos

Figura 2.23

Ejemplo de un DFD con el método SSADM

u


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.


Niveles de los DFD

El DFD se basa en descomposiciones llamadas niveles. El primer nivel es una representación

muy general. Aumentan los detalles en la medida en que se alcancen niveles más bajos

(subniveles) en la descomposición. Un sistema se modela mediante un conjunto de DFD

nivelados en el que los niveles superiores definen las funciones del sistema de forma general y

los niveles inferiores (niveles más bajos) definen las funciones de forma más detalladas.

Se comienza por el nivel más alto de la jerarquía mediante un DFD denominado “diagrama de

contexto”. En este diagrama sólo hay un proceso que representa el sistema completo. Este

proceso se descompone en otro DFD (que se denomina “diagrama de sistema”) en el que se

representa las funciones principales o subsistemas. Luego se descompone cada uno de los

Entidades

ExternasEntidades

Externas

Procesos

Procesos

Almacenes

de Datos

Almacenes

de Datos

Flujo de Datos

Entidades

ExternasEntidades

Externas

Procesos

Procesos

Almacenes

de Datos

Almacenes

de Datos

Flujo de Datos

Figura 2.24

Ejemplo de un DFD con el método Gane & Sarson

55

procesos en nuevos diagramas que representan funciones más simples. Se procede de la misma

manera hasta que todas las funciones estén lo suficientemente detalladas como para que no sea

necesaria la creación de nuevos DFD.

Por lo tanto un conjunto de DFD queda definido por:

Diagrama de Contexto, único y en la parte superior.

Niveles Medios (Diagrama de Sistema), formado por el resto de diagramas.

Funciones Primitivas, son las que están presentes tanto en los niveles intermedios como

en los últimos niveles de la jerarquía y que se corresponden con procesos que no explotan

en nuevos DFD.

Los diagramas de flujos deben ser trazados en forma sistemática, con la ayuda de la

programación top-down. Se comienza haciendo un diagrama muy general y luego se va bajando

por niveles y se va detallando cada vez más a medida que va bajando de nivel, es decir se toma

cada proceso y se produce el desarrollo, esto significa que el proceso se subdivide en sub-

procesos para llegar a un gráfico con más nivel de detalle. En la Figura 2.25 se puede observar de

manera grafica en enfoque de análisis estructurado clásico.

Fuente: DeMarco (1979)

En la Figura 2.26 se muestra un ejemplo de los distintos niveles que puede tener un DFD.

Figura 2.25

Enfoque de análisis estructurado clásico

Diagrama de

Contexto

Sin estrategia que asista

en el criterio de participación

DFD de Primer nivel

nivel o nivel 0

División top-down de

Cada proceso

Diagrama de

Contexto

Sin estrategia que asista

en el criterio de participación

DFD de Primer nivel

nivel o nivel 0

División top-down de

Cada proceso

56

Fuente: DeMarco (1979)

2.3 Diagrama de estructura de datos (DED)

Los diagramas de estructuras de datos (DED) son una notación gráfica que representa la

estructura de un conjunto de módulos de un programa, existe una relación jerárquica con cada

uno de los módulos. Estos diagramas no informan sobre el orden de ejecución de los módulos ni

el número de veces que se ejecuta. Debido a su notación suele parecerse a la representación de

los DFD, pero no son iguales.

En los diagrama de estructura de datos cada rectángulo representa un módulo, las flechas que

conectan los rectángulos representan invocaciones de módulos (por ejemplo llamado de sub-

rutinas). El diagrama también muestra parámetros de entrada que se le dan a cada módulo

invocado y parámetros de salida devueltos por cada módulo cuando termina su tarea y devuelve

el control al que lo llama.

Figura 2.26

Niveles de los DFD

57

Este diagrama es una herramienta excelente para los diseñadores de sistemas, pero no es el tipo

de modelo que normalmente se mostrará al usuario, pues modela un aspecto de la implantación

del sistema, no de sus requerimientos.

Los diagramas de estructura de datos sirven para el modelado top-down de la estructura de

control de un programa descrito a través de un árbol de invocación de módulos. Fueron

presentados en la década de los 70 como la principal herramienta utilizada en los diseños

estructurados, por autores como Constantine y Yourdon (1978). La Figura 2.27, muestra un

ejemplo:


Un diagrama de estructura de datos permite modelar un programa como una jerarquía de módulos.

Cada nivel de la jerarquía representa una descomposición más detallada del módulo del nivel

superior. La notación usada se compone básicamente de tres símbolos: módulos, invocaciones y

cuplas.

Módulos

Para Yourdon y Constantine. (1978) un módulo es un conjunto de instrucciones que ejecutan

alguna actividad, desde un punto de vista práctico, un módulo es una colección de instrucciones

de un programa con cuatro características básicas:

Recibir

muestra

Comprobar

cliente

Alta

cliente

Alta

muestra

Comprobar

animal

Alta

animal

NumClienteNumCliente,

NumAnimal

NumAnimal

NumAnimalNumCliente

Recibir

muestra

Comprobar

cliente

Alta

cliente

Alta

muestra

Comprobar

animal

Alta

animal

NumClienteNumCliente,

NumAnimal

NumAnimal

NumAnimalNumCliente

Figura 2.27

Ejemplo de un diagrama de estructura de datos

58

1. Entradas y Salidas: lo que un módulo recibe en una invocación y lo que retorna como

resultado.

2. Función: las actividades que un módulo hace con la entrada para producir la salida.

3. Lógica Interna: por la cual se ejecuta la función.

4. Estado Interno: su área de datos privada, datos para los cuales sólo el módulo hace referencia.

Las entradas y salidas son, respectivamente, datos que un módulo necesita y produce. Una

función es la actividad que hace un módulo para producir la salida. Las Entradas, salidas y

funciones proveen una visión externa del módulo. La lógica interna son los algoritmos que

ejecutan una función, esto es, junto con su estado interno representan la visión interna del módulo.

Un módulo esta diseñado como una caja, su función es representada por un nombre en el interior

y las entradas y salidas de un módulo son representadas por pequeñas flechas que entran y salen

del módulo. Existen diferentes tipos de módulos: según el flujo de datos, su función y sus

conexiones.

• Según el flujo de datos:

– Aferentes (o de entrada): transfiere información desde los módulos inferiores a los

superiores.

– Eferentes (o de salida): transfiere información desde los módulos superiores a los

inferiores.

– De transformación: sirven para transformar datos a otro formato.

– Coordinación: manejan el flujo de datos entre sus sucesores, es decir, el flujo pasa

a través de él y se trasfiere de una rama a otra. Coordina y gestiona otros módulos

• Según su función:

– Ejecutivos: llaman a módulos subordinados y realizan las decisiones del sistema.

– Atómicos: realizan trabajos concretos.

• Según las conexiones:

– Mínimamente conectados: transmisión de datos y control a través de parámetros.

Un solo punto de entrada al módulo.

– Normalmente conectados: varios puntos de entrada (baja cohesión)

– Patológicamente conectados: transferencias de control al interior o datos globales.

59

Relaciones entre módulos

Los diagramas de estructura de datos muestran las invocaciones que un módulo hace a otros

módulos. Estas invocaciones son diseñadas como una flecha que sale del módulo llamador y

apunta al módulo llamado. La Figura 2.28, muestra un ejemplo:

Fuente: Yourdon y Constantine (1978)

En el ejemplo de la Figura 2.28 el módulo A invoca (o llama) a los módulos B, C y D. La

interpretación de las invocaciones provee información de la estructura interna del módulo

llamador. Los diagramas de estructura no tienen especificado el orden de invocación de los

módulos invocados. El orden de la figura de los módulos B, C, y D (de izquierda a derecha) no

debe ser interpretado como el orden de invocaciones ejecutado por el módulo A. Una invocación,

representa la idea de invocación a funciones o procedimientos en los lenguajes de programación

convencionales. En un diagrama de estructura de datos se pueden modelar varios tipos de

invocaciones, en el Cuadro 2.1 se explican y se representan gráficamente:

Cuadro 2.1

Tipos de invocaciones

Invocación

Estándar

El módulo A invoca al módulo B con la semántica de invocación

de procedimientos o funciones en los lenguajes de programación

convencionales (C, Pascal, etc.).

Invocación

Concurrente

El módulo A comienza dos tareas concurrentes, B y C.

Invocación

Co-rutina

El módulo A invoca al módulo B con una semántica de

transferencia de control al punto de entrada de una co-rutina.

A

B

A

B C

A

B C D

Modulo Llamador

Invocación

Modulo Llamado

A

B C D

Modulo Llamador

Invocación

Modulo Llamado

A BA B

Figura 2.28

Ejemplo de invocaciones

60

Transferencia

de Control

El módulo A hace una transferencia de control al interior del

módulo B.

Transferencia

de Datos

El módulo A hace referencia a un área de datos local del módulo B.


Comunicación entre módulos (cuplas)

Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, comúnmente

un conjunto de argumentos es comunicado y, en el caso de las funciones, también se espera que

retorne un resultado. Estos datos comunicados en una invocación son modelados por medio de

flechas, sobre el símbolo de invocación, llamadas cuplas, en la Figura 2.29 se muestra un ejemplo.

Como se muestra en el Cuadro 2.2, existen varios tipos de cuplas, basado en lo que ellas pueden

producir en el módulo receptor, las cuales se describen a continuación:

Cuadro 2.2

Tipos de cuplas

Cupla de

Datos

Una cupla de datos transporta datos “puros” a un módulo. No es necesario

conocer la lógica interna del módulo receptor, para determinar los valores

válidos de la cupla (ej.: número de cuenta, saldo, tabla de movimientos).

Cupla

Modificada

Con una flecha doble (apuntando al modulo llamador y al módulo llamado) se

especifica un argumento enviado a un módulo que deberá modificar su valor,

fijando un nuevo valor disponible para el módulo llamador (en la

implementación, se precisará que el lenguaje posea un mecanismo de pasaje de

parámetros por referencia) (ej.: el buffer enviado a un módulo de lectura de un

archivo).

B

A

B

A

A

B C D

Cúpula de Datos

Cúpula sin tipo

(o de datos o de

control o hibrida)

Z

X

YZ W

F

H

Cúpula Modificada

Cúpula de control

flag

Cúpula Hibrida

(datos y control)

A

B C D

Cúpula de Datos

Cúpula sin tipo

(o de datos o de

control o hibrida)

Z

X

YZ W

F

H

Cúpula Modificada

Cúpula de control

flag

Cúpula Hibrida

(datos y control)

Figura 2.29

Ejemplos de invocaciones con cuplas


61

Cupla de

Control






archivo).

Cupla

Híbrida

Una cupla que para algunos módulos transporta datos “puros” y para otros

transporta un flag de control es denominada cupla híbrida. Esta cupla

representa un híbrido entre una cupla de datos y una cupla de control. La

identificación de ellas depende de la lógica definida por el algoritmo de

implementación del módulo invocado.

Cupla sin

Tipo

Se utiliza para representar que hasta el momento no esta definida o se tienen

dudas con respecto a la interpretación que el módulo invocado hace de ella.

Fuente: Yourdon y Constantine, 1978

Estructura de control

Los diagramas de estructura también definen símbolos que posibilitan el modelamiento de

estructuras de control como repetición o alternativa:

Estructura condicional

Un rombo incluyendo una o más invocaciones especifica la ejecución condicional de ellas. En la

Figura 2.30 se muestra un ejemplo de esta estructura.

Puede que se llame a B o que no se

llame

Puede que se llame a alguno de entre B, C o D


A

B

A

B C D

Figura 2.30

Estructura condicional

62

Estructura iterativa

Una flecha circular, abarcando un número de invocaciones, especifica que las invocaciones que

abarca son ejecutadas repetidamente. En la Figura 2.31 se muestra un ejemplo de esta estructura.

Puede llamarse a B varias veces

Puede llamarse a B, C y D varias veces


2.4. Diagramas de transición de estados (DTE)

Según Yourdon (1989), el diagrama de transición de estado, también conocido como DTE

enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo

importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como ejemplo

de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas

de captura de datos de alta velocidad y sistemas de control y mando militares. Algunos de estos

sistemas son pasivos, en el sentido de que no buscan controlar el ambiente que los rodea, sino

más bien reaccionan a él o capturan datos que le atañen.

Para sistemas enfocados a los negocios no se veían demasiado importante, sin embargo en

sistemas grandes y complejos enfocados a negocios que si tienen aspectos de comportamiento de

tiempo real. Por ejemplo si el sistema maneja entradas de miles de terminales y entradas de alta

velocidad de otros sistemas, pueden entonces surgir aspectos de comportamiento dependientes

del tiempo, del tipo que surgen en un sistema típico de tiempo real. Por esto aunque no se

apliquen en todos los sistemas es conveniente estar familiarizado con herramientas de modelado

para el comportamiento dependiente del tiempo

A

B

A

B C D

Figura 2.31

Estructura iterativa

63

En la Figura 2.32 se muestra un DTE típico. Este diagrama muestra el comportamiento de una

máquina contestadora de teléfono normal. Los principales componentes del diagrama son estados,

y flechas que representan los cambios de estado.


Notación de los diagramas de transición de estados

Existe una variada notación pero lo más común es representar a los estados mediante rectángulos

o mediante círculos, esta última forma puede llegar a parecerse con los DFD; por lo tanto es

mejor representarlos mediante rectángulos.

Estados del sistema

Cada rectángulo representa un estado en el que se puede encontrar el sistema. El New World

Díctíonary de Webster define un “estado” de la siguiente manera: “Un conjunto de circunstancias

o atributos que caracterizan a una persona o cosa en un tiempo dado; forma de ser; condición. Por

tanto, los estados típicos de un sistema pueden ser: esperar a que el usuario dé su contraseña,

calentar una mezcla de sustancias químicas, esperar la siguiente orden, acelerar el motor, mezclar

los ingredientes, esperar los datos del instrumento, llenar el tanque, aguardar en reposo, entre

otros.

Estos ejemplos implican que el sistema está esperando a que algo ocurra, no se expresan en

términos de que la computadora este haciendo algo porque el DTE se usa para desarrollar un

Figura 2.32

Ejemplo de un diagrama de transición de estados

EN REPOSO

ESPERANDO

UNA

LLAMADA

RESPONDIENDO

A LLAMADA

GRABANDO

MENSAJEREBOBINADO

DEJANDO EL

MENSAJE

EN REPOSO

ESPERANDO

UNA

LLAMADA

RESPONDIENDO

A LLAMADA

GRABANDO

MENSAJEREBOBINADO

DEJANDO EL

MENSAJE

64

modelo esencial del sistema, un modelo de cómo se comportaría el sistema si hubiera tecnología

perfecta; es decir, tecnología perfecta se entiende como que cualquier proceso, calculo o acción

que debiera hacer la computadora se hiciera en cero momentos. Así, cualquier estado observable

en el que el sistema se puede encontrar sólo puede corresponder a periodos en los que 1) está

esperando que algo ocurra en el ambiente externo o, 2) está esperando a que alguna actividad que

se esté dando en ese momento en el ambiente (como mezclar, lavar, llenar, acelerar, etc.) cambie

a otra. Un estado representa algún comportamiento del sistema que es observable y que perdura

durante algún periodo finito.

Cambios de estado

Para Yourdon (1989) los cambios de estados válidos en un DTE se muestran conectando pares

relevantes de estado con una flecha. Es muy común que cualquier estado pueda llevar a un

número arbitrario de estados sucesores. Así, la Figura 2.33 muestra que el sistema puede ir del

estado 1 al estado 2. También muestra que cuando el sistema se encuentra en el estado 2 puede ir

al estado 3 o regresar al 1.


La mayoría de los sistemas tendrán un estado inicial reconocible y un estado final reconocible. El

estado inicial típicamente suele ser el que se dibuja en la parte superior del sistema, aunque no es

obligatorio; lo que realmente identifica al estado 1 en la Figura 2.34 Como inicial es la flecha que

no está conectada a ningún otro estado. De igual forma, el estado final suele dibujarse en la parte

inferior, pero tampoco es obligatorio; lo que realmente identifica al estado 5 como final es la

ausencia de una flecha que salga de él, por lo tanto una vez que se llega al estado 5 no se puede ir

a otra parte (Yourdon, 1989). Normalmente el sistema tendrá sólo un estado inicial, pero puede

tener múltiples estados finales como se puede observar en la Figura 2.35. Los estados finales son

Figura 2.33

Cambios de estado en un DTE

ESTADO 1

ESTADO 2

ESTADO 3

ESTADO 1

ESTADO 2

ESTADO 3

65

mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna

ejecución del sistema.

En la Figura 2.35 se muestra un diagrama de transición de estado con múltiples estados finales.


Condiciones y acciones

Para completar el DTE necesitamos agregar dos cosas: las condiciones que causan un cambio de

estado y las acciones que el sistema toma cuando cambia de estado. Como se señala en la Figura

2.36, las condiciones y acciones se muestran junto a la flecha que conecta los dos estados

relacionados.

Figura 2.34

Estados inicial y final en DTE

Figura 2.35

Estados finales múltiples de N Sistemas

ESTADO 1

ESTADO 2

ESTADO 4 ESTADO 5ESTADO 6

ESTADO 3

ESTADO 1

ESTADO 2

ESTADO 4 ESTADO 5ESTADO 6

ESTADO 3

ESTADO 1

ESTADO 2

ESTADO 3

ESTADO 4

ESTADO 5

ESTADO 1

ESTADO 2

ESTADO 3

ESTADO 4

ESTADO 5


66


Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar;

típicamente es una señal, una interrupción o la llegada de un paquete de datos.

Esto usualmente hace que el sistema cambie de un estado de espera X a un estado de espera Y o,

de realizar una actividad X a realizar una actividad Y.

Como parte del cambio de estado el sistema con frecuencia hará una o más acciones. Por ejemplo

producirá una salida, realizará un cálculo, etc. Entonces, las acciones que se muestran en un DTE

son respuestas regresadas al ambiente externo o bien cálculos que el sistema recuerda para poder

responder a algún acontecimiento futuro.

Diagramas particionados

En un sistema complejo puede haber docenas de estados distintos de un sistema, tratar de

colocarlos todos en un solo diagrama es difícil. Por esto, como se usan niveles y particiones en

los DFD pueden usarse particiones en los DTE. La Figura 2.37 muestra un ejemplo de DTE para

un cajero automático.

Figura 2.36

Condiciones y acciones de un DTE

ESTADO 1

ESTADO 2

CONDICION

ACCION

ESTADO 1

ESTADO 2

CONDICION

ACCION

67

Fuente: Yourdon, (1989).

Cualquier estado individual de un diagrama de mayor nivel puede convertirse en un estado inicial

para un diagrama de un nivel inferior que describe más a fondo ese estado de mayor nivel; y el o

los estados finales en un diagrama de nivel inferior corresponden a las condiciones de salida en el

estado asociado de nivel superior.

Construcción del diagrama de transición de estados

Luego de ver la notación para los DTE, se puede observar dos enfoques que pueden aplicarse

para su construcción.

Puede comenzarse con la identificación de todos los posibles estados del sistema y

representar cada uno en una caja separada. Luego puede explorar todas las conexiones

con significado (cambios de estado) entre las cajas.

Figura 2.37

DTE particionado para un cajero automático

ENREPOSO

ESPERANDO

RESPUESTA

ESPERNADO

CONTRASEÑA

ESPERANDO

ELECCION

DESPLIEGA

ESTADO DE

CUENTA

DEPOSITA

FONDO

TRANFIERE

FONDODA EFECTIVO

Se presiono “inicio”

despliega mensaje de inserte tarjeta

tarjeta insertada

despliega “introducir contraseña”

Contraseña ingresada

despliega “selección de función”

“da efectivo” “transfiere fondos”

“se presiono reinicio”

Borrar pantalla

Se presiono reinicio

o contraseña errónea


ENREPOSO

ESPERANDO

RESPUESTA

ESPERNADO

CONTRASEÑA

ESPERANDO

ELECCION

DESPLIEGA

ESTADO DE

CUENTA

DEPOSITA

FONDO

TRANFIERE

FONDODA EFECTIVO

Se presiono “inicio”

despliega mensaje de inserte tarjeta

tarjeta insertada

despliega “introducir contraseña”

Contraseña ingresada

despliega “selección de función”

“da efectivo” “transfiere fondos”


Borrar pantalla

Se presiono reinicio

o contraseña errónea


Esperando

Entrada

Dando

Efectivo

Esperando

El retiro

Del efectivo

Despliega “¿cuando desea?”

Cliente ingresa cantidad deseada

Efectivo disponible en cajero

Despliega “Favor esperar, dando efectivo”

Despliega “Favor retirar su efectivo”

Regresa al estado de ESPERANDO

ELECCIÓN en la figura superior

Esperando

Entrada

Dando

Efectivo

Esperando

El retiro

Del efectivo

Despliega “¿cuando desea?”

Cliente ingresa cantidad deseada

Efectivo disponible en cajero

Despliega “Favor esperar, dando efectivo”

Despliega “Favor retirar su efectivo”

Regresa al estado de ESPERANDO

ELECCIÓN en la figura superior


68

Otra alternativa es comenzar por el estado inicial y luego metodológicamente ir siguiendo

un camino hasta el o los estados restantes; luego del o los estados secundarios; seguir con

los terciarios, etc.

El enfoque lo determinará, en la mayoría de los casos, el nivel de conocimiento del usuario que

colabora en la construcción del modelo de comportamiento dependiente del tiempo del sistema.

Relación del DTE con los demás componentes del modelo

El DTE puede usarse por si solo como herramienta de modelado; pero debería ser utilizado en

conjunto con otras herramientas.

Generalmente, el DTE representa una especificación de proceso para una burbuja de control en

un DFD. Esto se muestra en la Figura 2.38, las condiciones en un DTE corresponden a los flujos

de control entrantes en un DFD, y las acciones en el DTE corresponden a los flujos de control de

salida en el DFD. Como herramienta de modelado de alto nivel el DTE puede servir incluso

como especificación de proceso para todo el sistema. Si se representa todo el sistema con un

diagrama de contexto, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.


2.5. Modelo relacional

El Modelo Relacional fue propuesto por Edgar Codd en 1970 (E. Codd era entonces un

investigador del Centro de IBM en San José - California y publicó su propuesta en un artículo

Figura 2.38

Relación entre un DFD y un DTE

ESTADO 1

ESTADO 2

Señal X

Activar burbuja 2

ESTADO 3

Señal Y

Activar burbuja 3

1

2 3

4

X

Y

ESTADO 1

ESTADO 2

Señal X

Activar burbuja 2

ESTADO 3

Señal Y

Activar burbuja 3

1

2 3

4

X

Y

69

fundamental que obtuvo el ACM Award correspondiente al Congreso VLDB de 1970,

proponiendo un nuevo modelo de datos que tenía como objetivo fundamental aislar al usuario de

las estructuras físicas de los datos, consiguiendo así la independencia de las aplicaciones

respecto de los datos.

Este objetivo fundamental es expresado explícitamente por Codd: "... se propone un modelo

relacional de datos como una base para proteger a los usuarios de sistemas de datos

formateados de los cambios que potencialmente pueden alterar la representación de los datos,

causados por el crecimiento del banco de datos y por los cambios en los caminos de acceso“.

Es un modelo lógico que se conoce como “esquema de la base de datos” (database schema) a

partir del cual se podrá realizar el modelado físico en el DBMS, es importante mencionar que es

un paso necesario, no se puede partir de un modelo conceptual para realizar un físico.

El modelo relacional se basa en la teoría matemática de las relaciones, los datos se estructuran

lógicamente en forma de relaciones, esta estructura lógica es muy parecida al concepto de tabla

que representa las relaciones entre los datos.

El trabajo de Codd en 1970 perseguía una serie de objetivos:

Independencia física: El modo cómo se almacenan los datos no debe influir en su manipulación

lógica y, por tanto, los usuarios que acceden a esos datos no han de modificar sus programas por

cambios en el almacenamiento físico.

Independencia lógica: Añadir, eliminar o modificar cualquier elemento de la BD no debe

repercutir en los programas y/o usuarios que están accediendo a subconjuntos parciales de los

mismos (vistas).

Flexibilidad: Ofrecer a cada usuario los datos de la forma más adecuada a la correspondiente

aplicación.

Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme (tablas), lo que

facilita la concepción y manipulación de la BD por parte de los usuarios.

Sencillez: Las características anteriores, así como unos lenguajes de usuario muy sencillos,

producen como resultado que el modelo relacional (MR) sea fácil de comprender y de utilizar por

parte del usuario final.

70

Evolución del modelo relacional

El Cuadro 2.3 hace una síntesis de la evolución del Modelo Relacional, desde su surgimiento a

fines de la década del sesenta hasta la actualidad.

Cuadro 2.3

Evolución del modelo relacional

Años Sucesos

1968-1970 Surge el Modelo Relacional (Codd). Aparece el concepto de

relación: tabla.

1970... Desarrollo teóricos: ej: álgebra relacional (Codd, 1972).

1973-1978 Prototipos (Ingres, Sistema R, etc.)

1979 Oracle

1981 SQL

1982 Sybase, Informix

1984 SQL/ANS

1986 SQL ISO

1990 Modelo Relacional versión 2 (RM/V2) Codd. Nulos

1992 SQL2 estándar.

1994 SQL3 Aun no estandarizado BDOO Fuente: Sánchez (2004)

Estructura del modelo relacional

Las estructuras de datos que se manejan en el modelo relacional corresponden a los conceptos de

relación, entidad, atributo, dominio y tupla (Dorantes, Magariños, Jury 2001).

Entidad: es una unidad de datos en una relación con un conjunto finito de atributos. Es también

conocido como n-ada, a raíz de que consiste de n-valores, uno por cada atributo (Dorantes,

Magariños, Jury 2001).

Relación: se entiende por relación una colección o grupo de objetos que tienen en común un

conjunto de características o atributos, es la estructura básica del modelo relacional. Es capaz de

recoger interrelaciones de cardinalidad múltiple (Dorantes, Magariños, Jury 2001).

Atributo: son las propiedades de la relación. Un atributo, necesariamente ha de definirse sobre un

dominio Se representan mediante columnas en las tablas. También llamado característica, cada

atributo de una relación tiene asociado un dominio en el cual toma sus valores (Dorantes,

Magariños, Jury 2001).

71

• Un atributo está siempre asociado a una relación, mientras que un dominio tiene existencia

propia con independencia de las relaciones que existan en el modelo.

• Un atributo representa una propiedad de una relación.

• Un atributo toma valores de un dominio.

• Varios atributos distintos (de la misma o de diferentes relaciones) pueden tomar sus valores

del mismo dominio.

Dominio:

Es el conjunto válido de valores de referencia para definir propiedades o atributos. Un dominio es

un conjunto nominado y homogéneo de valores. Cada dominio puede definirse de dos maneras:

Por extensión (enumeración de sus elementos):

días de la semana = {lunes, martes, miércoles, jueves, viernes, sábado, domingo}

Por intensión (mediante una propiedad que recoja el recorrido de sus valores

admisibles): edad: entero /. 0 ≤ edad ≤ 200.

Un dominio compuesto se puede definir como una combinación de dominios simples a la que se

puede aplicar ciertas restricciones.

Ej.: el dominio compuesto denominado Fecha se construye de los dominios simples Día, Mes y

Año, incorporando las restricciones a fin de que no aparezcan valores inválidos como: 29/2/2003,

31/4/2004.

Tupla: Es una ocurrencia o instancia dentro de una relación. Una tupla permite referenciar una

instancia de una entidad en el universo o la interrelación específica o concreta entre instancias de

entidades. Su representación es una fila. Una relación tiene un “conjunto” de tuplas. La relación

es el elemento fundamental del modelo relacional.

Clave

En el modelo relacional existen varios tipos de claves que funcionan como identificadores dentro

de las relaciones como las claves candidatas, las primarias, las alternativas y las foráneas.

Una clave candidata de una relación es un conjunto no vacío de atributos que identifican unívoca

y mínimamente cada tupla.

72

Clave primaria: es aquella clave candidata que el usuario elegirá, por consideraciones ajenas al

modelo relacional, para identificar las tuplas de la relación. El modelo relacional no incluye este

concepto de elegir una clave como primaria, cuando hay varias candidatas.

Clave alternativas: Son aquellas claves candidatas que no han sido escogidas como claves

primarias.

Clave ajena o foránea: de una relación R2 es un conjunto no vacío de atributos cuyos valores han

de coincidir con los valores de la clave primaria de una relación R1 (R1 y R2 no son

necesariamente distintas).

Grado: Se define como el número de atributos.

Cardinalidad: Se define como el número de tuplas de la relación.

En la Figura 2.39 se pueden observar los diferentes elementos que integra un modelo relacional

Fuente: Mercedes (2004)

Restricciones

Las restricciones son estructuras no permitidas. Hay dos tipos: inherentes y del usuario. Las

inherentes al modelo, tal como no tener tuplas repetidas y las del usuario que validan las

instancias de la relaciones.

Clave primariaClave primaria

Figura 2.39

Estructura de datos relacionales

73

Restricciones inherentes

Son aquellas que además de las derivadas por el concepto de relación, existe la llamada “regla de

integridad de entidad”, que serán explicadas más adelante. Esta restricción tiene como norma que

“ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo”

ya que nulo significa desconocido o inexistente. Esta restricción debería aplicarse a las claves

alternativas, pero el modelo no lo exige.

Restricciones de usuario

Se pueden definir como un predicado sobre un conjunto de atributos, de tuplas o de dominios,

que debe ser verificado para que constituya una ocurrencia válida del esquema.

Normalización

La normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar

un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede.

La normalización también se puede definir como "el proceso mediante el cual se transforman

datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más

simples y más estables, son más fáciles de mantener"

Grados de normalización

Existen varios niveles de normalización, sin embargo son tres los niveles básicos: Primera Forma

Normal (1FN), Segunda Forma Normal (2FN) y Tercera Forma Normal (3FN). Cada una de estas

formas tiene sus propias reglas. En el Cuadro 2.4 se muestran los grados de normalización.

Cuadro 2.4

Grados de normalización

Forma Normal Descripción

Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.

Segunda Forma Normal (2FN) Asegura que todas las columnas que no son llave sean

completamente dependientes de la llave primaria (PK).

Tercera Forma Normal (3FN) Elimina cualquier dependencia transitiva. Una

dependencia transitiva es aquella en la cual las

columnas que no son llave son dependientes de otras

columnas que tampoco son llave.

Forma Normal Boyce-Codd

(FNBC)

Una relación esta en FNBC si y solo si todas las

dependencias funcionales son completas y todos los

atributos determinantes son claves candidatas Fuente: Codd (1971)

74

Reglas de integridad

Una vez definida la estructura de datos del modelo relacional, pasamos a estudiar las reglas de

integridad que los datos almacenados en dicha estructura deben cumplir para garantizar que son

correctos.

Al definir cada atributo sobre un dominio se impone una restricción sobre el conjunto de valores

permitidos para cada atributo. A este tipo de restricciones se les denomina restricciones de

dominios. Hay además dos reglas de integridad muy importantes que son restricciones que se

deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias (las

reglas se deben cumplir todo el tiempo). Estas reglas son la regla de integridad de entidades y la

regla de integridad referencial. Antes de definirlas, es preciso conocer el concepto de nulo.

Reglas de integridad: restricción que debe cumplirse sobre una BD en todos sus estados. Existen

dos reglas de integridad generales: de identidades y referenciales; y una específica que es de

negocios.

Regla de integridad de entidades (amiga de las claves primarias). Ningún atributo de una llave

primaria puede tener el valor nulo.(NULL).

La primera regla de integridad se aplica a las claves primarias de las relaciones base: ninguno de

los atributos que componen la clave primaria puede ser nulo.

Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de

modo único las tuplas. Que es irreducible significa que ningún subconjunto de la clave primaria

sirve para identificar las tuplas de modo único. Si se permite que parte de la clave primaria sea

nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo

que se contradice la irreducibilidad.

Nótese que esta regla sólo se aplica a las relaciones base y a las claves primarias, no a las claves

alternativas.

Regla de integridad referencial (amiga de las claves ajenas). Debido a que las llaves foráneas

referencian llaves primarias, es esencial que el valor de una llave foránea coincida con el valor

de alguna llave primaria.

75

La segunda regla de integridad se aplica a las claves ajenas: si en una relación hay alguna clave

ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o

bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en términos de estados de la base de datos: indica lo

que es un estado ilegal, pero no dice cómo puede evitarse. La cuestión es ¿qué hacer si estando en

un estado legal, llega una petición para realizar una operación que conduce a un estado ilegal?

Existen dos opciones: rechazar la operación, o bien aceptar la operación y realizar operaciones

adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habrá que contestar a tres preguntas:

Regla de los nulos: ¿Tiene sentido que la clave ajena acepte nulos?

Regla de borrado: ¿Qué ocurre si se intenta borrar la tupla referenciada por la clave

ajena?

o Restringir: no se permite borrar la tupla referenciada.

o Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la

referencian mediante la clave ajena.

o Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a

nulo la clave ajena (sólo si acepta nulos).

Regla de modificación: ¿Qué ocurre si se intenta modificar el valor de la clave primaria

de la tupla referenciada por la clave ajena?

o Restringir: no se permite modificar el valor de la clave primaria de la tupla

referenciada.

o Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se

propaga la modificación a las tuplas que la referencian mediante la clave ajena.

Reglas de negocio: reglas de integridad específica de cada base de datos

Además de las dos reglas de integridad anteriores, los usuarios o los administradores de la base

de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de

negocio.

76

Por ejemplo, si en una oficina de la empresa inmobiliaria sólo puede haber hasta veinte

empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe

hacerla respetar. En este caso, no debería permitir dar de alta un empleado en una oficina que ya

tiene los veinte permitidos.

Hoy en día aún existen SGBD relacionales que no permiten definir este tipo de restricciones ni

las hacen respetar.

Además existen las restricciones de dominios: al definir cada atributo sobre un dominio, se

impone una restricción sobre el conjunto de valores permitidos para cada atributo.

Dinámica relacional

La última parte del Modelo Relacional es su componente dinámica, que se divide en dos partes:

álgebra relacional y cálculo relacional.

El álgebra relacional se basa en un conjunto de operadores que operan sobre relaciones. El

cálculo relacional se basa en predicados que definen un estado objetivo de la base de datos, y

tenemos el cálculo relacional orientado a la tupla y el cálculo relacional orientado al dominio.

2.6 Diagramas de entidad-relación (DER)

Para Chen (1976): “El enfoque entidad-relación provee una metodología comprehensiva y fácil

de entender para un diseño lógico de la base de datos independiente del almacenamiento o

consideraciones de eficiencia”.

El diagrama de entidad-relación (también conocido como DER) es un modelo conceptual de red

que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.

Es muy diferente del DFD, que modela las funciones que lleva a cabo un sistema; y es diferente

del diagrama de transición de estados, que modela el comportamiento dependiente del tiempo de

un sistema.

También se le llama modelo E/R e incluso EI (Entidad / Interrelación). Sus siglas más populares

son las E/R por que sirven para el inglés y el español. Fue creado por Peter Chen en los años

77

1976 y 1977 a través de dos artículos. Se trata de un modelo que sirve para crear esquemas

conceptuales de bases de datos. De hecho es prácticamente un estándar para crear esta tarea. El

propósito de este modelo es simplificar el diseño de bases de datos a partir de descripciones

textuales de los requerimientos, es una técnica de representación grafica que incorpora

información relativa a los datos y a la relación existente entre ellos para darnos una visión del

mundo real.

Inicialmente en la propuesta de Chen (1976), sólo se incluían los conceptos de entidad, relación y

atributos. Después se añadieron otras propuestas (atributos compuestos, generalizaciones, etc.)

que forman el llamado modelo “entidad relación extendido” (se conoce con las siglas ERE).

El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la

realidad mediante un conjunto de representaciones gráficas y lingüísticas. Estos conceptos, se

representa por un conjunto de entidades que presentan ciertas propiedades llamadas atributos,

definidos sobre un cierto dominio de datos. Las entidades se vinculan mediante relaciones que, en

ciertas variantes de la notación, pueden también tener sus propios atributos.

Las características principales son

1.- Refleja únicamente la existencia de los datos no lo que hace con ellos.

2.- El modelo E-R no esta orientado a aplicaciones particulares.

3.- Es independiente de las bases de datos y de los sistemas operativos concretos.

4.- A la hora de su confección no debemos considerar aspectos como espacio,

almacenamiento, ni tiempo de ejecución.

5.- Debe estar abierto a la evolución del sistema de tal forma que admita las posibles

incorporaciones que se produzcan o las variaciones de algunos elementos existentes.

El modelo E-R va a consistir en un conjunto de objetos básicos denominados entidades, así como

las relaciones existentes entre ellos. Las entidades vendrán representadas mediante un rectángulo

y las relaciones mediante un rombo. En la Figura 2.40 se muestra un ejemplo de un modelo de

entidad relación.

78


Componentes de un DER

Entidades

Según Peter Chen una entidad (objeto) es una “cosa” que puede ser identificada distintamente.

Una persona, una compañía, o un acontecimiento específico pueden ser ejemplo de una entidad.

Una relación es una asociación entre entidades. Por ejemplo, el "padre-hijo" es una relación entre

dos entidades.

Las entidades que poseen las mismas propiedades forman conjuntos de entidades. Ejemplos de

conjuntos de entidades son los conjuntos: personas, facturas, coches, etc., un ejemplo de esto se

puede observar en la Figura 2.41.


Figura 2.41

Ejemplos de entidades y conjunto de entidades

Figura 2.40

Ejemplo de un modelo de entidad relación

Alumno Profesor

Asignatura

Tiene

ImparteMatriculado

Alumno Profesor

Asignatura

Tiene

ImparteMatriculado

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Entidades

Personas

Conjunto de

entidades

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Entidades

Personas

Conjunto de

entidades

79

En la actualidad se suele llamar entidad a lo que anteriormente se ha definido como un conjunto

de entidades. De este modo hablaríamos de la entidad PERSONAS. Mientras que cada persona

en concreto sería una ocurrencia o un ejemplar de la entidad persona.

En el modelo entidad relación los conjuntos de entidades se representan con un rectángulo dentro

del cual se escribe el nombre de la entidad, en la Figura 2.42 se muestra un ejemplo de la entidad

“persona”.

Fuente: Chen (1976)

Tipos de entidades

Fuerte o Regulares. Son las entidades normales que tienen existencia por sí mismas sin

depender de otras. Su representación gráfica es la indicada arriba.

Débiles. Su existencia depende de otras. Por ejemplo, en la Figura 2.43 la entidad “tareas

laborales” sólo podrá tener existencia si existe la entidad trabajo. Las entidades débiles se

representan de esta forma:

Fuente: Chen (1976)

Relaciones

Representan asociaciones entre entidades, puede haber más de una relación entre dos entidades.

Es el elemento del modelo que permite relacionar en sí los datos del modelo. Por ejemplo (Ver

Figura 2.44), en el caso de que tengamos una entidad personas y otra entidad trabajos. Ambas se

realizan ya que las personas trabajan y los trabajos son realizados por personas.

PERSONA

Figura 2.42

Representación de la entidad: “persona”

Figura 2.43

Entidad débil

TAREAS LABORALES

80


La representación gráfica de las relaciones se realiza con un rombo al que se le unen líneas que se

dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo). En el ejemplo de la

Figura 2.45 podría usarse como nombre de relación, trabajar.

Fuente: Chen (1976)

Grado de la relación

Número de entidades que pueden participar en una relación

Unitarias (misma entidad).

Binarias (2 entidades)

N-arias (N entidades)

Cardinalidad de las relaciones

La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están

relacionadas con cuántas entidades del conjunto del otro extremo. Estas pueden ser de “una a

Figura 2.44

Ejemplo de relación (a)

Figura 2.45

Ejemplo de relación (b)

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Fontanero

Electricista

Peluquero

Administrativo

Personas Trabajos

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Fontanero

Electricista

Peluquero

Administrativo

Personas Trabajos

Personas Trabajar TrabajosPersonas Trabajar Trabajos

Figura 2.44


81

una” (1:1), de “una a muchas” (1:N), de “muchas a una” (N:1). y de “muchas a muchas” (N:N). Se

anota en términos de:

Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá

cada ejemplar de la entidad (el valor que se anota es de cero o uno)

Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer

cada ejemplar de la entidad (puede ser uno o muchos)

Roles en las relaciones

A veces en las líneas de la relación se indican roles. Los roles representan el papel que juega una

entidad en una determinada relación. En la Figura 2.46 se muestra un ejemplo de los roles en las

relaciones.


Atributos

Las distintas propiedades o características de una entidad o de una relación, se denomina Atributo.

Los atributos toman valores de uno o varios dominios. Así, el conjunto de posibles valores que

puede tomar una cierta propiedad se denomina dominio para tal propiedad. Por ejemplo,

propiedades de Profesores pueden ser su nombre y apellido, DNI, domicilio, etc.; de Cursos,

pueden ser nombre del curso, duración, requisitos, etc. y los dominios serán aquellos conjuntos

de los cuales podemos obtener esos valores “Sr. Sánchez”, 25657789, etc.

Tipos de atributos

Existen cuatro tipos de atributos:

1. simples o compuestos: Los atributos simples no están divididos en subpartes, mientras

que los compuestos sí pueden dividirse en varios atributos. Por ejemplo el atributo

nombre_completo podría dividirse en tres atributos: nombre, apellido1 y apellido2.

La diferencia entre un atributo compuesto y uno simple es que en los compuestos se

Figura 2.46

Ejemplo de roles en las relaciones

Trabajador Trabaja

Empleado

Jefe

Trabajador Trabaja

Empleado

Jefe

82

puede referir a cada componente de forma separada. En general ayudan a hacer los

modelos más claros pues agrupan atributos relacionados.

2. monovalorados y multivalorados: Los atributos univalorados sólo pueden tener un

valor para una entidad concreta. Por ejemplo una persona sólo puede tener un número

de DNI, y un préstamo tiene un único número de identificación. Hay que destacar que

esto es diferente de tener un valor único y distinto del resto de las entidades; un

atributo univalorado simplemente indica que un atributo de una entidad sólo tendrá un

valor. Los atributos multivalorados por el contrario pueden tener un conjunto de

valores para una entidad específica. El teléfono de un cliente es un buen ejemplo de

atributo multivalorado, ya que un cliente puede tener varios números de teléfono (fijo,

móvil, móvil de la empresa, etc.).

3. nulos: Un valor nulo se usa cuando una entidad no tiene un valor para ese atributo, ya

sea porque no se necesita o bien porque su valor se desconoce en ese momento. Por

ejemplo una entidad trabajador con un atributo subordinado, en el caso de que una

persona no tenga a otras a su cargo el atributo subordinado será nulo.

4. derivados: El valor para este tipo de atributo se puede obtener de los valores de otros

atributos o entidades. Por ejemplo en un conjunto de entidades cliente, el atributo

total_de_préstamos puede obtenerse contando el número de entidades préstamo

asociadas a dicho cliente.

Clave

Una clave nos sirve para identificar una entidad de forma inequívoca, ya que la diferencia sólo

puede expresarse en términos de sus atributos. Una superclave es un conjunto de uno o más

atributos que tomados colectivamente permiten identificar de forma única una entidad en el

conjunto de entidades. Se trata de uno o más campos cuyos valores son únicos en cada ejemplar

de una entidad. Se indican subrayando el nombre del identificador.

Para que un atributo sea considerado un buen identificador tiene que cumplir:

1. Deben distinguir a cada ejemplar teniendo en cuenta las entidades que utiliza el modelo.

No tiene que ser un identificador absoluto.

2. Todos los ejemplares de una entidad deben tener el mismo identificador.

3. Cuando un atributo es importante aun cuando no tenga una entidad concreta asociada,

entonces se trata de una entidad y no de un atributo.

83

2.7 Otros métodos estructurados

2.7.1 Método de Warnier/Orr

Los diagramas de Warnier/Orr (también conocidos como construcción lógica de programas)

fueron desarrollados inicialmente en Francia por Jean Dominique Warnier y en los Estados

Unidos por Kenneth Orr (Martin & McClure, 1985). Este método ayuda al diseño de estructuras

de programas identificando la salida y resultado del procedimiento. Los sencillos métodos

gráficos usados en los diagramas de Warnier/Orr hacen evidentes los niveles en un sistema y más

claros los movimientos de los datos en dichos niveles.

Los diagramas de Warnier/Orr muestran los procesos y la secuencia en que se realizan, cada uno

de estos procesos se define de una manera jerárquica; es decir, consta de conjuntos de

subprocesos que lo definen, en cada nivel, el proceso se muestra en una llave que agrupa a sus

componentes. Puesto que un proceso puede tener muchos subprocesos distintos, un diagrama de

Warnier/Orr usa un conjunto de llaves para mostrar cada nivel del sistema.

En los diagramas Wranier/Orr se trabaja hacia atrás, es decir, se comienza con la salida del

sistema y usando un análisis orientado hacia la salida. En el papel el desarrollo se mueve de

izquierda a derecha. En primer lugar, se definen la salida o resultados esperados del

procedimiento. En el nivel siguiente, mostrado mediante la inclusión por medio de una llave, se

definen los pasos necesarios para producir la salida. A su vez, cada paso se define un poco más.

Las llaves adicionales agrupan los procesos requeridos para producir el resultado en el siguiente

nivel (Martin & McClure, 1985).

Los diagramas de Warnier/Orr ofrecen la ventaja de ser simples en apariencia y fáciles de

entender tienen además, la ventaja de mostrar agrupaciones de procesos y los datos que deben

transferirse de nivel a nivel. Además, la secuencia del trabajo hacia atrás garantiza que el sistema

estará orientado hacia el resultado.

La representación de un algoritmo se basa en los siguientes puntos:

84

Un programa se representa por un solo diagrama en el cual se hallan todas las operaciones.

Las operaciones se colocan secuencialmente a la derecha de una llave, en cuya parte

izquierda esta el nombre del proceso, en la parte superior de la llave se halla la palabra

INICIO, y en la parte inferior la palabra FIN.

Los sucesivos procesos se hacen en forma similar. Cada nivel de descomposición viene

definido por el conjunto de procesos que en él se ejecutan.

En la Figura 2.47 se muestra un ejemplo de la estructura de un programa de Warnier.

Fuente: Martin y McClure (1985).

Estructuras de control

Estructura secuencial: En esta estructura las acciones se sitúan a la derecha de la llave y desde

arriba hacia abajo. En la Figura 2.48 se muestra un ejemplo de esta estructura.

Estructura alternativa: En esta estructura se ejecutara una acción dependiendo de la condición.

Si la acción es nula se representa mediante un guión (-). En la Figura 2.48 se muestra un ejemplo

de esta estructura.


Estructura repetitiva: Se hallan también las formas PARA, MIENTRAS QUE, HASTA QUE,

ITERAR. En la Figura 2.49 se muestra un ejemplo de estas estructuras.

A

B

C

Cond.SI

NO

A

BExpre.

=V1

=V2

=V3

=V4

A

B

C

D

Secuencial Alternativa

A

B

C

Cond.SI

NO

A

BExpre.

=V1

=V2

=V3

=V4

A

B

C

D

Expre.

=V1

=V2

=V3

=V4

AA

B

C

D

Secuencial Alternativa

Programa

uno

inicio

A

B

C

D

E

F

fin

Programa

uno

inicio

A

B

C

D

E

F

fin

Figura 2.47

Estructura de un programa - Warnier

Figura 2.48

Estructura secuencial y alternativa - Warnier

85


2.7.3 Método de Jackson

En 1957 Michael A. Jackson. Describe el método de programación estructurada de Jackson (JSP-

Jackson Structured Programing), como método de diseño de programas con aplicación a la

mayoría de los lenguajes de programación.

La metodología de Jackson es un proceso sistemático para la realización de un programa,

utilizando la técnica del diseño descendente (top-down), cuyo producto final es el programa

escrito en el pseudocódigo propio del método, de tal forma que su codificaci6n posterior en

cualquier lenguaje de programaci6n es relativamente sencilla, bien manualmente o de forma

automática.

Jackson se ayuda con la implementación de módulos, siguiendo un orden jerárquico de acuerdo a

los diferentes niveles en que se encuentra. Cada módulo se convierte en un dato o en un conjunto

de datos.

Este método se basa en la estructura lógica de la programación modular. La representación de los

programas se realiza por medio de un árbol que se denomina diagrama arborescente de Jackson.

Un diagrama de Jackson consta de: definición detallada de los datos de entrada y salida

incluyendo los archivos lógicos utilizados y representación del algoritmo. En la Figura 2.50 se

muestra un ejemplo de la estructura de un programa de Jackson.

A

CA

condición

B

B

PARA

Vi,Vf(,in)

MQ

Condición

HQ

Condición

LOOP

A

CA

condición

B

B

PARA

Vi,Vf(,in)

MQ

Condición

HQ

Condición

LOOP

Figura 2.49

Estructuras repetitivas - Warnier

86


Cada árbol se lee: nodo raíz, nodo izquierdo, nodo derecho hermano, nodo derecho hermano.

La representación del algoritmo se basa en los siguientes puntos:

todo programa (operaciones) se representa en un solo diagrama.

todo diagrama comienza con un rectángulo en cuyo interior se halla el nombre del

programa.

para tener una clara interpretación es necesario realizarlo de la forma más simétrica

posible.

Estructuras de control

Estructura secuencial: En esta estructura se realizan las acciones de izquierda a derecha. Los

módulos en un número determinado se ejecutan una sola vez, respetando un orden jerárquico

preestablecido. En la Figura 2.51 se muestra un ejemplo de esta estructura.


Proceso

B C DA

Proceso

B C DA

P1

Y XX

Secuencial

P2

SI O

A

Alternativo

NO O

B

P1

Y XX

Secuencial

P2

SI O

A

Alternativo

NO O

B

Figura 2.50

Estructura de un programa - Jackson

Figura 2.51

Estructura secuencial y alternativa - Jackson

87

Estructura alternativa: Se ejecuta una acción entre varias, según la evaluación de una condición.

El proceso se indica por medio de la letra O.

Estructura repetitiva: Se repiten operaciones dependiendo de una condición. Los módulos son

ejecutados desde cero hasta n veces. Cuando existe un proceso repetitivo, se indica con un

asterisco (*). En la Figura 2.52 se muestra un ejemplo de esta estructura.


2.7.3 Diagramas HIPO

HIPO es una abreviatura del nombre en inglés (Hierarchy-Input-Process-Output), en español,

Entrada-Proceso-Salida-Jerárquica, fueron desarrollados por IBM como esquemas de

representación para un desarrollo jerárquico de arriba abajo y como una ayuda de documentación

para productos comercializados. Los diagramas HIPO muestran lo que el sistema hace pero no

cómo lo hace. (Martin y McClure, 1985).

Este método fue creado con el propósito de ayudar a los diseñadores a no perder la pista de

alguna función dentro de un sistema grande, ésta es su principal ventaja con la que cuenta con

respecto a otras notaciones, ya que este método permite tener una vista panorámica de las

entradas, procesos y salidas de datos. Esto lo hace una herramienta útil para la documentación de

programas, además de que le puede facilitar al analista de un programa el recordar lo que hace el

sistema después de cierto tiempo.

Para

Proceso

A

Vc=Vi,V,i

*

Proceso

A

MQ cond.

*

Proceso

A

HQ cond.

*

Mientras Que Hasta QuePara

Proceso

A

Vc=Vi,V,i

*

Proceso

A

MQ cond.

*

Proceso

A

HQ cond.

*

Mientras Que Hasta Que

Figura 2.52

Estructuras repetitivas - Jackson

88

Sin embargo HIPO también cuenta con ciertas desventajas, una de ellas es que utilizan una gran

cantidad de papel para mostrar todo el diagrama de un sistema por lo que puede ocasionar que el

lector navegue entre hojas y se le dificulte el seguimiento del flujo de éste.

Existen tres clases de diagramas HIPO: tabla de contenido visual, los diagramas generales y los

detallados.

Los diagramas HIPO están conformados por tres (3) clases de diagramas: tabla de contenido, los

diagramas generales y los diagramas de detalles.

La tabla de contenido (Ver Figura 2.53).es el nivel superior del diagrama de HIPO. Es una

estructura en forma de árbol que muestra los componentes generales de un sistema. No ofrece

información de control ni describe los datos en el sistema.


Figura 2.53

Tabla de contenido - HIPO

PROCESO

DE

SUBSCRIPCIÓN

OBTENER UN

ARTICULO

VALIDO

LEER UN

ARTICULO

VALIDAR UN

ARTICULO

PROCESAR UN

ARTICULO

VALIDO

PROCESAR

UNA NUEVA

SUBSCRIPCIÓN

PROCESAR

CANCELACION

PROCESAR

RENOVACION

ADICIONAR

UN RECORD CREAR UNA

FACTURA

CREAR UN

REDCORD DE

FACTURA

1.0

3.02.0

2.1 2.2

3.1.1 3.1.2

3.1

3.1.3

3.2 3.3

PROCESO

DE

SUBSCRIPCIÓN

OBTENER UN

ARTICULO

VALIDO

LEER UN

ARTICULO

VALIDAR UN

ARTICULO

PROCESAR UN

ARTICULO

VALIDO

PROCESAR

UNA NUEVA

SUBSCRIPCIÓN

PROCESAR

CANCELACION

PROCESAR

RENOVACION

ADICIONAR

UN RECORD CREAR UNA

FACTURA

CREAR UN

REDCORD DE

FACTURA

1.0

3.02.0

2.1 2.2

3.1.1 3.1.2

3.1

3.1.3

3.2 3.3

89

Los diagramas generales (Ver Figura 2.54) especifican los procesos de un sistema en forma

funcional; cada diagrama describe las entradas, los pasos de proceso y las salidas de los

componentes principales del sistema; un diagrama general puede indicar la localización de los

diagramas de detalles subordinados necesarios. El propósito es “proveer de un conocimiento

general de una función”.


Los diagramas detallados (Ver Figura 2.55) proveen de la información necesaria para entender

cuales son las entradas, los procesos llevados a cabo y las salidas de un componente funcional.

(Martin y McClure, 1985).

SISTEMA DE SUBCRIPCIONES

Diagrama 1.0 SUBCRIPCIONES

ENTRADA PROCESO SALIDA

SUBCRIPCIONES

ARCHIVO DE CLIENTES

ARCIVO MAESTRO

ACTUALIZADO

FACTURAS/ RECLAMOS

Para todas las transacciones

de subscriciones:

1. Obtener un articulo valido

2. Si es una nueva subscrición

proceso una nueva

subscrición

3. Si es una renovación proceso

renovaciones

4. Si es una cancelación

proceso cancelaciones

SISTEMA DE SUBCRIPCIONES

Diagrama 1.0 SUBCRIPCIONES

ENTRADA PROCESO SALIDA

SUBCRIPCIONES

ARCHIVO DE CLIENTES

ARCIVO MAESTRO

ACTUALIZADO

FACTURAS/ RECLAMOS

Para todas las transacciones

de subscriciones:

1. Obtener un articulo valido

2. Si es una nueva subscrición

proceso una nueva

subscrición

3. Si es una renovación proceso

renovaciones

4. Si es una cancelación

proceso cancelaciones

Figura 2.54

Ejemplo de un diagrama general HIPO

90


Ambos tipos de diagramas los generales y detallados se parecen en el formato utilizado. Este

consiste en tres cajas o rectángulos identificados de la siguiente forma: entrada, proceso y salida.

En los diagramas la parte identificada como entrada se encuentra a mano derecha y muestra los

datos ya sean documentos, tablas, arreglos, archivos y otros que son necesarios para el proceso.

En el centro se encuentra la porción del diagrama que se utiliza para los procesos donde se

describen la serie de pasos utilizados para transformar los datos. A la izquierda del diagrama se

encuentra la salida que muestra lo que produjo el proceso. Cada caja o rectángulo esta conectado

por flechas que muestra que insumo o producto esta asociado con cada proceso (Martin y

McClure, 1985).

1. Reset error flags

2. Validate name street, zip,

and payment

a . if errors,

set flags

a . if errors

set flags

NEW-SUB-IN

INPUT

NEW-NAME

NEW-STR

NEW-CITY

NEW-ST

NEW-ZIP

NEW-PMT

NEW-TERMS

VALID-TERMS

VALID TERMS TABLE

NEW-SUB-IN

PROCESS OUTPUT

Validate

indicators2.2.2.1Validate terms

Reference number referring to more

detailed HIPO diagram which

expands step 3

1. Reset error flags

2. Validate name street, zip,

and payment

a . if errors,

set flags

a . if errors

set flags

NEW-SUB-IN

INPUT

NEW-NAME

NEW-STR

NEW-CITY

NEW-ST

NEW-ZIP

NEW-PMT

NEW-TERMS

VALID-TERMS

VALID TERMS TABLE

NEW-SUB-IN

PROCESS OUTPUT

Validate

indicators2.2.2.1Validate terms

Reference number referring to more

detailed HIPO diagram which

expands step 3

Figura 2.55

Ejemplo de un diagrama detallado HIPO

Desarrollo

Orientado a Objetos

CAPITULO

Desarrollo Orientado a Objetos

En este capítulo se hará un estudio documental sobre el desarrollo orientado a objetos, pero antes

de comenzar hablar de esto hay que explicar un poco cómo se dio su origen, comenzando con una

breve reseña histórica.

En la década de 1980, los métodos de desarrollo estructurado demostraron no escalar lo suficiente

y dieron paso a un nuevo paradigma, el de la programación orientada a objetos. El auge de este

paradigma, donde procesos y datos son tratados de forma conjunta conformando unidades de

trabajo coherentes llamadas objetos, supuso un cambio tan radical que implicó la existencia de

una metodología propia. Al igual que ocurrió con el paradigma estructurado, fue la creación de

lenguajes de programación orientados a objetos lo que fomentó un cambio en la forma de diseñar

y analizar. Los métodos orientados a objetos se utilizan en proyectos con unas características muy

concretas, coexistiendo en la actualidad con las técnicas estructuradas.

Con el análisis orientado a objetos, la forma de modelar la realidad difiere del análisis

convencional, se modela el mundo en términos de tipos de objetos y lo que le ocurre a éstos, esto

implica también diseñar y construir sistemas de forma orientada a objetos.

Los modelos que se construyen en el análisis orientado a objetos (OO, de ahora en adelante)

reflejan la realidad de modo más natural que los del análisis tradicional de sistemas. Después de

todo, la realidad consta de objetos y eventos que cambian el estado de dichos objetos. Mediante

las técnicas OO, construimos software que modela más fielmente el mundo real. Cuando el

mundo real cambia, nuestro software es más fácil de cambiar, lo que es una ventaja real.

93

3.1. Conceptos básicos del desarrollo OO

Se hará mención a los conceptos generales más utilizados en el modelo orientado a objetos, los

cuales son: abstracción, encapsulación y modularidad. Y con respecto a programación, son:

objeto, clase, método, envío y recepción de mensajes, herencia y polimorfismo.

Abstracción

Abstracción consiste en aislar un elemento de su contexto o del resto de los elementos que lo

acompañan. En programación, el término se refiere al énfasis en el "¿qué hace?" más que en el

"¿cómo lo hace?". Para Murillo (2002) es una descripción o especificación simplificada de un

sistema que hace énfasis en algunos detalles significativos y suprime los irrelevantes. La

abstracción se puede definir como la capacidad de examinar algo sin preocuparse de los detalles

internos.

El común denominador en la evolución de los lenguajes de programación, desde los clásicos o

imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del que cada uno de

ellos hace uso. La abstracción encarada desde el punto de vista de la programación orientada a

objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los

demás. Por ello, en OO lo más importante es que la abstracción debe enfocarse más en lo qué es

un objeto y lo qué hace, antes de pensar en la implementación. Por ejemplo, un automóvil puede

abstraerse como un objeto que sirve para desplazarse a mayor velocidad, sin importar cómo lo

haga.

Encapsulamiento

La información acerca de un objeto está encapsulada por su comportamiento. Esto significa que

un objeto mantiene datos acerca de cosas del mundo real a las que representa en su sentido

verdadero. Típicamente a un objeto se le debe “pedir” o “decir” que cambie sus propios datos con

un mensaje, en vez de esperar que tales datos de procesos extremos cambien la naturaleza de un

objeto (Murillo, 2002).

La encapsulación separa las características esenciales de las no esenciales dentro de un objeto. Al

encapsular u ocultar información, se separan los aspectos externos de un objeto (los accesibles

94

para todos) de los detalles de implementación (los accesibles para nadie). Con esto se trata de

lograr que al tener algún cambio en la implementación de un objeto no se tengan que modificar

los programas que utilizan tal objeto (Murillo, 2002).

Modularidad

La modularidad según Murillo (2002) consiste en dividir un programa en partes llamadas

módulos, los cuales pueden trabajarse por separado. En términos de programación, los módulos

pueden compilarse por separado y la división no depende de cierto número de líneas sino es una

división en términos de integrar en un módulo un conjunto de procedimientos relacionados entre

sí, junto con los datos que son manipulados por tales procedimientos. El objetivo de la

modularidad es reducir el costo de elaboración de programas al poder dividir el trabajo entre

varios programadores.

Objeto

Según Murillo (2002) un objeto es un elemento real o abstracto que tiene un estado, un

comportamiento y una identidad. Es un elemento independiente de un programa de

computadora, que representa un grupo asociado de características y está diseñado para realizar

tareas específicas. También se les conoce como instancias. Dicho en otras palabras es algo que es

identificable. Por ejemplo una silla, un libro o un lápiz.

Estado: el estado viene determinado por el conjunto de propiedades o atributos

que tiene el objeto junto con los valores que pueden asumir cada uno de esos

atributos. El hecho de que un objeto tenga un estado implica que ocupa un espacio,

exista durante un tiempo, cambie el valor de sus atributos, y sea creado o destruido

(Murillo,2002).

El comportamiento de un objeto viene determinado por la forma de actuar al

recibir un mensaje para que realice una acción. Un mensaje es una orden que se

manda a un objeto para que realice una operación con un propósito específico;

viene definido por tres componentes: el objeto receptor del mensaje, el selector del

mensaje, que es la acción que se quiere que realice el objeto y los argumentos, que

son los valores que se transmiten con el selector y que, en muchos casos, pueden

ser nulos (Murillo, 2002).

95

La identidad de un objeto es la propiedad característica que tiene ese objeto que

le distingue de todos los demás (Murillo, 2002).

Clase

Las clases son aquellas que permite crear objetos de la misma estructura y comportamiento. Las

clases igual que los objetos que salen de ellos están formadas por dos partes:

Una la constituyen las variables de la clase. Estas variables son los elementos que

definen los atributos de los objetos.

La otra parte son los métodos de la clase que van a ser los servicios que

proporcionan los objetos.

Herencia

Cuando se crean objetos derivados de otros, éstos heredan los atributos y los servicios de sus

clases base. Esta herencia puede ser sencilla o múltiple, en el primer caso, cada subclase tiene una

única superclase de la que es derivada. Mientras que en la herencia múltiple, una clase hereda a la

vez de varias superclases. Mediante la herencia se puede reutilizar el código.

Polimorfismo

El polimorfismo es capacidad de tener métodos con el mismo nombre pero que su

implementación sea diferente. En la vida diaria se presenta el siguiente ejemplo de polimorfismo:

al tratar de frenar un vehículo siempre se debe oprimir el pedal del lado izquierdo y el vehículo se

detendrá sin importar si los frenos son de tambor o de disco.

3.1.1. Estructura conceptual de un objeto

Un objeto puede considerarse como una especie de cápsula dividida en tres partes: (1) relaciones,

(2) propiedades y (3) métodos. Cada uno de estos componentes desempeña un papel totalmente

independiente:

http://www.monografias.com/trabajos5/recicla/recicla.shtml#papel

96

Las relaciones como se observan en la Figura 3.1 permiten que el objeto se inserte en la

organización y están formadas esencialmente por punteros a otros objetos. Las relaciones pueden

ser de tipo: asociativas, de agregación y especialización.

Fuente: Díaz (2007)

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma

organización y tienen valores que dependen de la propiedad de que se trate. Las propiedades de

un objeto pueden ser heredadas a sus descendientes en la organización. En la Figura 3.2 las

propiedades de directivos son: nombre, edad, categoría y sueldo bruto.


Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán

incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también

pone a disposición de sus descendientes a través de la herencia. Los métodos aplicados a

empleado en la Figura 3.3 son “mostrarDatos y “calcularSalario”

Figura 3.2

Ejemplo de propiedades de un objeto

Figura 3.1

Ejemplo de una relación de objetos

http://www.monografias.com/trabajos6/napro/napro.shtml



http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml

http://www.monografias.com/trabajos16/romano-limitaciones/romano-limitaciones.shtml


http://www.monografias.com/trabajos6/diop/diop.shtml

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/trabajos13/heren/heren.shtml

97


3.2. Métodos de análisis orientados a objetos (AOO)

Los métodos OO suelen, según muchos autores hacer la distinción entre análisis y diseño, pero,

pese a lo que anuncien sus autores o aún su mismo nombre, la distinción entre análisis y diseño se

difumina ya que esto depende de las necesidades del software que se este modelando, muchas

veces se mezclan estos métodos, pero sin embargo en esta investigación se estudian de forma

separada el análisis del diseño según sus creadores.

3.2.1. Método OOSA de Shlaer/Mellor

El primer paso del método de Shaler y Mellor (1988) es la definición de objetos y de sus

atributos. La notación de modelado de entidades desciende de la notación de Ward/Mellor. Este

método se puede clasificar como trilateral, y se desarrolla creando un modelo de información (o

de datos) que muestran los objetos, atributos y relaciones. Este método recibe un apoyo parcial de

la herramienta CASE, llamada teamwork. Es un método utilizado para diseñar sistemas de tiempo

real.

3.2.2. Método Coad /Yourdon

Coad y Yourdon publicaron libros prácticos y razonablemente completos en OOAD (Análisis

Orientado a Objetos y Diseño Orientado a Objeto, Prentice-Hall, 1990 y 1991, respectivamente).

Su metodología se centra en el análisis de los problemas de negocio, y utiliza una notación más

amistosa que el de Booch, Shlaer y Mellor, o los otros autores que se centran más en diseño.

Figura 3.3

Ejemplo de los métodos en un objeto

98

Existe una aproximación que surgió de Yourdon y se debe mucho a la tradición de modelado de

entidades y relaciones, esta aproximación se resume en Coad/Yourdon y resultó especialmente

interesante al ser la primera descripción ampliamente difundida de un método de análisis y una

notación de apoyo razonablemente completo, práctico, orientado a objetos y adecuados para

proyectos comerciales. Coad/Yourdon presenta una notación menos torpe que la que se encuentra

en Booch, Shlaer/Mellor o en la mayoría de las aproximaciones de diseño orientado a objetos.

Una de las características más notables de las notaciones de Shlaer/Mellor y Coad/Yourdon es

que los atributos resultan completamente explícitos. Coad/Yourdon (1991), sugiere que el análisis

se produce en cinco fases a las que dan los nombres siguientes:

Temas: estos son similares a los niveles del diagrama del flujo de datos y deben contener

cinco a nueve objetos aproximadamente.

Objetos: se identifican los objetos con detalle.

Estructuras: se identifican dos estructuras completamente distintas.

Estructuras de clasificación: corresponden a la relación de la herencia entre las

clases.

Estructuras de composición: definen los otros tipos de relaciones entre las clases.

Atributos: los atributos son detallados y se especifican las relaciones de modalidad y de

multiplicidad.

Servicios: esta es la palabra que emplea Coad Yourdon para las operaciones.

En diseño, estas cinco actividades se suplantan y se refinan en cuatro componentes:

Componente del dominio del problema: son las clases que se ocupan del dominio del

problema; por ejemplo, clases de cliente y clases de la orden

Componente humano de la interacción: clases de usuario-interfaz tales como las clases de

una ventana.

Componente de la gerencia de tarea: clases de la gestión de sistema tales como clases de

error y clases de seguridad.

Componente de la gerencia de datos: clases del método de acceso de base de datos y

similares Aunque la metodología de Coad y de Yourdon es quizás una de las

99

metodologías más fáciles de aprender del método OO y debido a su simplicidad no

conveniente aplicarla a proyectos grandes.

3.2.3. Método OMT de Rumbaugh

La metodología OMT (Object Modeling Technique/Técnica de Modelado de Objetos) fue creada

por James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy y William Lorensen

en 1991, mientras James dirigía un equipo de investigación de los laboratorios General Electric.

Esta metodología fue creada como método para desarrollar sistemas orientados a objeto y para

apoyar la programación orientada al objeto.

OMT es considerado ampliamente como uno de los sistemas de análisis orientados a objetos más

completos que se han publicado hasta el momento. OMT describe el análisis y diseño orientado a

objetos como una forma de organizar software dentro de una correlación de objetos discretos que

incorporan tanto comportamiento como estructuras de datos. La esencia del desarrollo orientado a

objetos en OMT es la identificación y organización de conceptos en el dominio del problema.

En su libro de Modelación y Diseño Orientado a Objetos, Rumbaugh señala con respecto a su

metodología OMT que: “La metodología consiste en construir un modelo de un dominio de

aplicación añadiéndosele detalles de implementación durante el diseño del sistema. Esta

aproximación se denomina Técnica de Modelado de Objetos (OMT) y consta de las siguientes

fases: Análisis, Diseño de Sistema, Diseño de Objetos e Implementación” (Rumbaugh, 1991).

El análisis presupone que existe una especificación de los requisitos y se desarrolla construyendo

tres modelos distintos mediante el uso de tres notaciones diferentes: modelo objeto, modelo

dinámico y modelo funcional. Cada modelo describe un aspecto del sistema pero contiene

referencias a los demás modelos. Lo cual indica que los tres no son totalmente independientes.

El diseño de sistemas se realiza organizando los objetos en subsistemas identificando la

concurrencia a partir del modelo dinámico (DM), asignando subsistemas a procesadores o tareas,

diciendo si los datos deben o no estar almacenados en archivos, en memoria o en un sistema de

administración de base de datos, diciendo el uso de periféricos, y recursos globales. El diseño de

objetos implica transformar la información del DM y del modelo funcional (FM) en operaciones

100

de modelo objeto (OM). En la fase de implementación se codifica lo ya diseñado. En la Figura

3.4 se puede observar el ciclo de vida o la metodología que utiliza OMT para desarrollar software.

Fuente: Rumbaugh (1991)

Fase de análisis

Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en

términos de objetos y de relaciones entre ellos, flujo dinámico de control y las transformaciones

funcionales.

Los pasos a seguir en el análisis son:

1. Obtener y escribir una descripción inicial del problema: se concentra en entender el

problema, se construye un modelo de la situación del mundo real que muestra las

propiedades más importantes. Dicho analista debe trabajar con quien hace la solicitud

para comprender el problema porque las definiciones del mismo no suelen ser completas

ni correctas. El modelo de análisis es una abstracción resumida y precisa de lo qué debe

hacer el sistema deseado y no de la forma (el cómo) en que se hará. Los objetos del

Figura 3.4

Ciclo de vida de OMT

Descripción del problema

Modelo del objeto

Modelo dinámico

Modelo funcional

Diseño de sistema

Diseño de objetos

Implementación

Análisis de Objetos

Diseño

Descripción del problema

Modelo del objeto

Modelo dinámico

Modelo funcional

Diseño de sistema

Diseño de objetos

Implementación

Análisis de Objetos

Diseño

101

modelo deberán ser conceptos del dominio de la aplicación y no conceptos de

implementación de la computadora tales como estructuras de datos. Un buen modelo

podrá ser comprendido y criticado por expertos de la aplicación que no sean

programadores (Rossi, Britos y García, 1998).

2. Construir un modelo de objeto y sus relaciones

Describe la estructura estática (de datos), de los objetos del sistema (identidad, atributos y

operaciones) y también sus relaciones. El modelo de objetos contiene diagramas de objetos. Un

diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones

entre las clases. El diagrama contiene clases de objetos organizados en jerarquías que

comparten una estructura y comportamiento comunes y que están asociadas a otras clases. Estas

clases definen los atributos que lleva cada instancia de objeto y las operaciones que efectúe o

sufre cada uno. En cada instancia de la clase se guardan los valores de esos atributos (Rossi et

al, 1998).

Para Rossi (1998) los pasos que se llevan a cabo para el modelo de objetos son:

Identificar las clases (y objetos): se seleccionan los sustantivos de la descripción del

problema como posibles clases candidatas y se construye una lista. Se eliminan las clases

redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de

implementación.

Las clases se representan (Ver Figura 3.5) por rectángulos con tres compartimientos, en el

primero se pone el nombre de la clase, en el segundo los atributos y en el tercero las

operaciones o métodos.

Fuente: Oktaba (1999)

Figura 3.5

Ejemplo de representación de una clase

Juez

Nombre

DaCalif()

Juez

Nombre

DaCalif()

102

Preparar un diccionario de datos que contengan descripciones de las clases, sus atributos y

sus asociaciones: es muy importante definir que se entiende con mayor detalle por cada

clase que quedó en la lista anterior.

Añadir las asociaciones y agregaciones entre las clases (y objetos): una asociación es una

dependencia entre dos o más clases, en la Figura 3.6 se muestra un ejemplo. Las

asociaciones, se representan por líneas que unen a las clases sobre las cuales se puede

escribir el nombre de la asociación.


A estos diagramas se les agrega la multiplicidad correcta. Puede ser “uno a uno”; “uno a muchos”

representada por una bolita rellena del lado de los “muchos”; o “muchos a muchos” representada

por bolitas rellenas a ambos extremos de la línea (Rossi et al, 1998).

También se puede representar la relación “es parte de” o agregación que indica que el objeto está

compuesto por objetos de las clases asociadas, un ejemplo sencillo es el que se muestra en la

Figura 3.7. Se denota un pequeño diamante del lado de la clase que agrega y puede incluir

multiplicidades (Rossi et al, 1998).

Figura 3.6

Ejemplo de asociaciones

Concursante

Nombre

Edad

Equipo

CalifEvento

Promedio Eventos

Equipo

Nombre

Categoría

Concursante

Nombre

Edad

Equipo

CalifEvento

Promedio Eventos

Equipo

Nombre

Categoría

103


El documento que genera el modelo de objetos es el siguiente:

3. Se desarrolla el modelo dinámico

Describe los aspectos de comportamiento (de control) de un sistema que cambian con el

tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos del control

del sistema. Los modelos dinámicos contienen diagramas de estados. Un diagrama de estados

es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por

sucesos o eventos (Rossi et al, 1998).

Se especifican en este modelo la temporización y secuencia de operaciones (sucesos que

marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos),

y la organización de sucesos y de estados. El modelo dinámico captura el control, aquel

aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en

cuanta lo que hagan las operaciones, aquello a lo que afecten o la forma en la que estén

implementadas. Las acciones de los diagramas de estado se corresponden con funciones

Modelo de objetos = diagrama del modelo de objetos + diccionario de datos

Figura 3.7

Ejemplo de una agregación

Estación

Nombre

Ubicación

Juez

Nombre

Da Calif()

Estación

Nombre

Ubicación

Juez

Nombre

Da Calif()

104

procedentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser

operaciones que se aplican a objetos dentro del modelo de objetos (Rossi et al, 1998).

Los pasos que se siguen en el modelo dinámico son:

Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y el

sistema.

Identificar los eventos que se dan entre objetos y preparar una traza de eventos para cada

escenario.

Construir los diagramas de estados: El estado de un objeto es un conjunto de valores

para sus atributos, en un cierto momento, el cual cambia al recibir un estímulo llamado

evento. Un diagrama de estados es una gráfica de estados representados por círculos y

eventos representados por flechas.

Chequear la consistencia de los eventos que aparecen en los diagramas.

El documento que genera el modelo dinámico es:

4. Se construye el modelo funcional

Describe las transformaciones (de función), de valores de datos que ocurren dentro del sistema,

captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se

haga. El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de datos es

un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se muestra las dependencias

entre los valores y el cálculo de valores de salida a partir de los de entrada y de funciones, sin

considerar cuando se ejecutan las funciones, ni siquiera si llegan a ejecutarse. Las funciones se

invocan como acciones en el modelo dinámico y se muestran como operaciones que afectan a

objetos en el modelo de objetos (Rossi et al, 1998).

Para Rossi (1998) los pasos que se llevan a cabo para el modelo funcional son:

Se identifican los valores de entrada y salida

Modelo dinámico = diagramas de estados + diagrama global de trazado de eventos

105

Se utilizan diagramas de flujo de datos para mostrar las dependencias funcionales.

Describir qué hace cada función

Se identifican las restricciones

Se especifica los criterios de optimización

El documento que genera el modelo funcional es:

5. Se verifican, iteran y refinan los tres modelos

Para Rossi (1998) los pasos que se deben seguir para verificar, iterar y refinar son los

siguientes:

Añadir las operaciones claves que fueron descubiertas durante la preparación del modelo

funcional al modelo objeto. No mostrar todas las operaciones durante el análisis, sólo

mostrar las más importantes.

Verificar que las clases, asociaciones, atributos y operaciones son consistentes y

completas al nivel elegido de abstracción. Compara los tres modelos con la definición del

problema y probar los modelos mediante el uso de escenarios.

Desarrollar escenarios más detallados (incluyendo condiciones que den errores) como

variaciones de los escenarios básicos. Usar estos escenarios para verificar en el futuro los

tres modelos.

Iterar los pasos anteriores cuanto sea necesario para completar el análisis.

El documento que genera el análisis contiene:

Diseño del sistema

Se define la arquitectura del sistema y se toman las decisiones estratégicas. Durante el diseño, el

sistema de destino se organiza en subsistemas basados tanto en la estructura del análisis como en

la arquitectura propuesta. El diseñador de sistemas deberá decidir qué características de

Documento de análisis = definición del problema + modelo de objetos + modelo

dinámico + modelo funcional.

Modelo funcional = diagramas de flujo de datos + restricciones

106

rendimiento hay que optimizar. Seleccionando una estrategia para atacar el problema y

efectuando las reservas de recursos tentativas (Rossi et al, 1998).

Según Rossi (1998) los pasos que se llevan acabo son:

1. Se organiza el sistema en subsistemas.

2. Se identifica la concurrencia inherente en el problema.

3. Se asignan los subsistemas a procesadores y a tareas.

4. Se selecciona la estrategia para implementar y administrar los almacenes de datos

(archivos o bases de datos).

5. Selección de la implementación del control del software.

6. Se consideran las condiciones de límite o contorno.

7. Se establecen las prioridades.

El documento que nos proporciona el diseño del sistema es:

Diseño de objetos

Su objetivo es refinar el modelo del análisis y proporcionar una base detallada para la

implementación tomando en cuenta el ambiente en que se implementará. El diseñador añade

detalles al modelo de acuerdo con la estrategia establecida durante el diseño del sistema. El foco

de atención del diseño de objetos son las estructuras de datos y los algoritmos necesarios para

implementar cada una de las clases. Las clases de objetos procedentes del análisis siguen siendo

significativas pero se aumentan con estructuras de datos y algoritmos del dominio de la

computadora seleccionados para optimizar medidas importantes de rendimiento (Rossi et al,

1998).

Para Rossi (1998) los pasos que se realizan en el diseño de objetos son los siguientes:

Documento de diseño del sistema = estructura de la arquitectura básica del sistema +

decisiones estratégicas de alto nivel.

107

1. Se refinan las operaciones para el modelo de objetos a partir de los demás modelos:

2. Se diseñan algoritmos para implementar las operaciones y las estructuras de datos

3. Se optimizan las vías de acceso a los datos.

4. Se implementa el control del software completando la aproximación propuesta en el

diseño del sistema.

5. Se ajusta la estructura de clases incrementando la herencia.

6. Se diseña la implementación de las asociaciones.

7. Se determina la representación exacta de los atributos de los objetos.

8. Se empaquetan las clases y las asociaciones en módulos.

El documento que se genera el diseño de objetos es:

Implementación

Las clases de objetos y las relaciones desarrolladas durante su diseño se traducen finalmente a un

lenguaje de programación concreto, a una base de datos o a una implementación en hardware. La

programación debería ser una parte relativamente pequeña del ciclo de desarrollo y

fundamentalmente mecánica porque todas las decisiones importantes deberán hacerse durante el

diseño. El lenguaje de destino influye en cierta medida sobre las decisiones de diseño pero éste

no debería depender de la estructura final de un lenguaje de programación. Durante la

implementación es importante respetar las ideas de la ingeniería del software, de tal manera que

el seguimiento hasta el diseño sea sencillo y de tal forma que el sistema implementado siga

siendo flexible y extensible (Rossi et al, 1998).

Es posible aplicar conceptos orientados a objetos a lo largo del todo el ciclo de vida de desarrollo

del sistema, desde el análisis hasta la implementación pasando por el diseño. Se pueden traspasar

las mismas clases de una etapa a otra sin modificar la notación aunque ganarán detalles

adicionales de implementación en las etapas posteriores. Siendo el punto de vista de análisis y el

de implementación de ‘‘Ventana’’ correctos tienen propósitos distintos y representan grados de

Documento de diseño de objetos = modelo de objetos detallado + modelo dinámico

detallado + modelo funcional detallado.

108

abstracción. Los mismos conceptos orientados a objetos de identidad, clasificación, polimorfismo

y herencia son aplicables a todo el ciclo de desarrollo completo.

Algunas clases no forman parte del análisis sino que se presentan como parte del diseño o de la

implementación. Por ejemplo, las estructuras de datos tales como árboles, tablas de dispersión y

listas enlazadas no suelen estar presentes en el mundo real. Se presentan para que presten su

apoyo a algoritmos concretos durante el diseño. Estos objetos de estructuras de datos se utilizan

para implementar objetos del mundo real dentro de la computadora y no derivan directamente sus

propiedades del mundo real.

OMT 22

En 1994 una revisión de OMT apareció con la introducción formal de los casos de uso. OMT2

declara que los casos de uso están limitados a la etapa de análisis de OMT. Esto requiere una

extensión sobre que está definido en OMT añadiendo 2 nuevos modelos a la etapa de análisis:

Modelo de dominio. Este modelo es creado explorando el dominio general y

adquiriendo conocimiento de las tareas que serán efectuadas.

Modelo de aplicación. Este modelo es construido sobre el modelo de dominio

examinando los casos de uso del dominio.

En esta revisión, los casos de uso son un método para examinar las interacciones de los actores

del sistema desde el punto de vista de un usuario.

Además OMT 2 introduce cambios en el modelo de objetos para hacerlo compatible con UML.:

Notación de objetos: Objeto como un rectángulo con la siguiente sintaxis

nombreObjeto : nombreClase

Multiplicidad: La multiplicidad muchos añade información al símbolo de círculo relleno,

incorporando información textual adicional

Atributos de la relación: Un atributo de la relación es un caso particular de la clase

asociación.

2 OMT 2 está publicado en las páginas blancas de www.rational.com

http://www.rational.com/

109

Clase asociación: La notación es ahora una línea discontinua que une la clase asociación

con la asociación.

Generalización: La representación aquí es una flecha cuyo extremo “toca” la clase más

+genérica. Puede organizarse en árbol.

Símbolo de cruce: Se introduce para evitar ambigüedades.

3.2.4 Método de Wirfs-Brock - Designing object oriented software (DOOS)

El Método de Wirfs-Brock (1990), cubre principalmente la fase de análisis del ciclo de vida del

desarrollo de los sistemas, pero no hace una distinción clara entre el análisis y el diseño. Dos

conceptos importantes, abstracción y encapsulación, se utilizan para manejar la complejidad del

mundo real. La metodología de DOOS describe el dominio del problema como sistema de objetos

de colaboración. Un sistema se desarrolla en dos fases. Durante los objetos exploratorios iniciales

de la fase, se identifican sus responsabilidades y las colaboraciones necesarias para satisfacer

estas responsabilidades. Dos técnicas gráficas se introducen para la segunda fase. Una técnica es

demostrar que las clases y las estructuras de clase y la otra es representar las clases, subsistemas y

relaciones del servidor de cliente.

Las tareas propuestas en este método son:

Evaluar la especificación del cliente.

Usar un análisis gramatical para extraer las clases candidatas de la especificación.

Agrupar las clases en un intento de determinar superclases.

Definir responsabilidades para cada clase.

Asignar responsabilidades a cada clase.

Identificar relaciones entre clases.

Definir colaboraciones entre clases basándose en sus responsabilidades.

Construir representaciones jerárquicas de clases para mostrar relaciones de herencia.

Construir un grafo de colaboraciones para el sistema.

110

3.3. Métodos de diseño orientados a objetos (DOO)

Los métodos de diseño orientados a objetos comparten los siguientes pasos básicos de diseño,

aunque los detalles varíen mucho.

Se identifican los objetos y sus atributos, así como los nombres de los métodos.

Se establece la visibilidad de cada objeto en relación con los demás objetos.

Se establece la interfaz de cada objeto y el tratamiento de excepciones.

Se realizan y comprueban los objetos.

3.3.1. Método de Booch - Diseño orientados a objetos con aplicaciones (OODA)

Grady Booch, en su libro Análisis y Diseño Orientado a Objetos con Aplicaciones da a conocer

su método de diseño (Booch, 1991) que se amplió a la fase de análisis (Booch, 1996), señala las

notaciones y métodos utilizados para el desarrollo de sistemas de software complejos que consta

de 4 actividades principales y 6 notaciones. Las actividades están comprendidas en: estructura

lógica, estructura física, dinámica de clases y dinámica de instancias; los primeros dos pasos

tratan los aspectos estáticos del sistema, tanto en su aspecto lógico (dominio del problema) como

en su aspecto físico; y los dos últimos tratan los aspectos dinámicos del sistema. Las notaciones

están contenidas en cada una de estás actividades.

Estructura lógica: Describe la existencia y significado de las abstracciones principales y los

mecanismos que forman el espacio del problema o para definir la arquitectura del sistema.

Diagramas de clases: Se usa para mostrar la existencia de clases y sus relaciones en la

visión lógica de un sistema. Un solo diagrama de clases representa una vista de la

estructura de clases de un sistema. Durante el análisis, se utilizan diagramas de clases para

indicar las misiones y responsabilidades comunes de las entidades que caracterizan el

comportamiento de un sistema. Durante el diseño, se utilizan diagramas de clases para

plasmar la estructura de las clases que forman la arquitectura del sistema.

111

Diagramas de objetos: Se usa para mostrar la existencia de objetos y sus relaciones en el

diseño lógico de un sistema, es decir, un diagrama de objetos representa una instantánea

en el tiempo de una corriente de eventos sobre una cierta configuración de objetos.

Estructura física: Describe la composición concreta en cuanto a hardware y software del

contexto o implantación del sistema.

Diagramas de módulos: Se usa para mostrar la asignación de clases y objetos a módulos

en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la

estructura de módulos de un sistema. Representa segmentos del sistema (paquetes o

funciones).

Diagramas de procesos: Representan los diagramas de bloques que muestran las

relaciones de comunicación entre dispositivos físicos y procesadores. Un solo diagrama

de procesos representa una vista de la estructura de procesos de un sistema.

Dinámica de clases

Diagramas de transición de estados: Se usa para mostrar el espacio de estados de una

clase determinada, los eventos que provocan una transición de un estado a otro, y las

acciones que resultan de ese cambio de estado. Muestran la dinámica a nivel de clases y

se centran en aquellos estados que den lugar a cambios en los datos o que sean

significativos

Dinámica de instancias

Diagramas de interacción: Se usa para realizar una traza de la ejecución de un escenario

en el mismo contexto que un diagrama de objetos. Muestran el comienzo y la terminación

de los métodos de cada instancia en relación con otros.

Booch (1996) en esencia plantea que para trabajar con su método es conveniente trabajar en dos

partes fundamentales: un micro-proceso y un macro-proceso, que se define a continuación:

Macro-procesos: engloba las ideas generales del sistema.

Primero se establecen los requisitos principales (conceptualización).

112

Luego se desarrolla un modelo de comportamiento deseado (análisis).

Se crea una arquitectura (diseño).

Proceso de evolución de la implementación (evolución).

Administra la evolución posterior a la entrega (mantenimiento).

Micro-procesos: se ocupa de los pequeños detalles de los macroprocesos, define un conjunto de

tareas de análisis que se reaplican en cada etapa en el macro proceso, por esto, mantiene un

enfoque evolutivo.

Identificación de las clases y de los objetos en un nivel de abstracción dado.

Identificación de la semántica de dichas clases y objetos.

Identificación de las relaciones entre estas clases y objetos.

Especificar las interfaces y después la implementación de éstas.

3.3.2. Método Good

El método de diseño general orientado a objetos (GOOD) fue desarrollado en la NASA por

Seidewitz y Stark (1983). Trata tanto la especificación de requisitos como el diseño de proyectos

en Ada. El método se desarrolla, al igual que sucede con el de Booch, partiendo de un conjunto

preliminar de diagramas de flujo por capas, llegando hasta la identificación de los objetos

implicados. En estos DFD se buscan objetos externos, depósitos de datos, interfaces de control y

depósitos de control.

3.3.3. Método Hood

La noción de la jerarquía de prioridades es aprovechada también por otro método, HOOD. La

“H” de HOOD quiere decir jerárquico. Este método también esta muy orientado al desarrollo en

Ada y fue desarrollado en la agencia espacial europea. Sufrió la influencia directa de GOOD, y

también se basa en el método de maquinas abstractas. En HOOD los objetos son pasivos o

activos. Los objetos pasivos solamente son capaces de utilizar los objetos de otros objetos pasivos,

pero los activos pueden utilizar los servicios de cualquier objeto. HOOD es un método de

113

refinamiento progresivo que se basa en la descomposición de un objeto del máximo nivel y,

posteriormente, en la descomposición de los objetos así resultantes.

El método HOOD utiliza un cierto número de pasos para descomponer cada objeto, comenzando

por un paso de diseño básico que podría implicar técnicas de realización de diagramas de

procedentes de otros métodos de análisis y diseño estructurado. El paso siguiente consiste en

generar una estrategia informal de soluciones. Esto se descompone en un cierto número de tareas:

un esbozo del lenguaje natural, diagramas HOOD de primera mano y una descripción del nivel

actual de abstracción. El tercer paso consiste en formalizar la estrategia de solución. Esto se hace

por fases, identificando y describiendo los objetos y sus operaciones.

Para Robinson (1992), las fases pueden ser resumidas como sigue:

1. Definición de problema. Se indica el contexto del objeto que se diseña, con la meta de

organizar y de estructurar los datos a partir de la fase de análisis de requisito.

1.1 Declaración del problema: el diseñador indica el problema, da una definición clara y

exacta del mismo, se diseña el contexto del sistema.

1.2 Análisis y estructuración de los datos de requisito: se recolecta toda la información

relevante al problema, incluyendo el ambiente del sistema que se diseñará.

2. Desarrollo de la estrategia de la solución. La solución del contexto del problema indicado

arriba se describe en términos de objetos en un alto nivel de la abstracción.

3. Formalización de la estrategia. Se definen los objetos y sus operaciones asociadas. Se diseña

un diagrama de HOOD de la propuesta, permitiendo la visualización fácil de los conceptos y de

la formalización posterior. Hay cinco sub-fases en la formalización de la estrategia:

3.1 Identificación del objeto.

3.2 Identificación de la operación.

3.3 Agrupar los objetos y las operaciones (tabla de la operación del objeto).

3.4 Descripción gráfica.

3.5 Justificación de las decisiones del diseño.

114

4. Formalización de la solución. La solución se formaliza a través de la definición formal de los

interfaces proporcionadas por los objetos, la descripción formal de las estructuras de control de

objeto y de la operación.

Notación del diagrama de HOOD

La notación del diagrama principal usado para describir la estructura de un sistema es el diagrama

del objeto de HOOD, que muestra una vista estática de la estructura en el diseño orientado a

objeto jerárquico.

En la Figura 3.8 se puede observar un ejemplo de un diagrama de HOOD para una compañía.

Fuente: Biggs (1999)

Análisis del método

Jacobson et al. opina que (1992): “el método da el paso básico hacia el diseño, pero no da

ninguna ayuda en encontrar la estructura apropiada del objeto. HOOD da realmente la ayuda

fuerte para las estructuras de contención, pero no para otras estructuras tales como estructuras de

uso o de la herencia”. Una de las críticas principales de HOOD es su carencia de la ayuda para

algunas de las técnicas más orientadas al objeto disponibles. La ayuda para la herencia es muy

pobre, según lo evidenciado por la carencia de cualquier notación para representarla gráficamente.

Figura 3.8

Ejemplo de un diagrama HOOD para una compañía

Estructura Alternativa Múltiple

115

3.3.4. Método OOSD

El diseño estructurado orientado a objetos (OOSD), que fuera presentado por Wasserman, Picher

y Muller (1990). Hablando estrictamente OOSD no es un método sino una notación a la cual se

pueden agregar reglas metodológicas. Esta notación es probablemente la que más próxima se

encuentra al espíritu de la orientación a objetos. OOSD es una notación no propietaria para el

diseño arquitectónico, que cambia el diseño por refinamiento progresivo estructurado y el diseño

orientado a objetos. Una vez más OOSD emplea una notación que se deriva de la de Booch, pero,

también tiene influencia de los diagramas estructurales.

OOSD no es tanto un método como una notación para apoyar los métodos de diseño orientado a

objetos en general. Los usuarios de OOSD pueden añadir reglas de diseño según cual sea el

método concreto que esté utilizando.

Otros puntos importantes de OOSD son la facilidad con la que es aceptado por los

desarrolladores que ya están familiarizados con el diseño estructurado así como lo adecuado que

resulta para los sistemas de tiempo real.

OOSD es una de las notaciones de diseño más avanzadas híbrido orientado a objetos de bajo

nivel. Parece improbable que sea posible extenderla hasta una notación de análisis congruente,

como consecuencia de la dificultad que surge al tratar un gran numero de métodos y como

consecuencia también de la ausencia de una forma en la que se puedan tratar estructuras y

atributos de datos muy complejos. Por otra parte, resulta mas adecuada para el diseño

arquitectónico o lógico que para el diseño físico.

3.3.5. Método JSD y OOJSD

El diseño estructurado de Jackson (JSD) es un método basado en objetos más que un método

completamente orientado a objetos. Los modelos JSD se descomponen en términos de sucesos o

de acciones y de sus dependencias temporales. Dentro de estos sucesos la aproximación JSD

define, en primer lugar los objetos. El paso siguiente construye una especificación en términos de

procesos secuenciales que se comunican, y que pueden acceder los unos al estado de los otros. El

116

método puede resultar útil si el diseño orientado a objetos debe realizarse en un lenguaje

convencional.

Es posible identificar un cierto número de similitudes entre JSD y los métodos de diseño

orientados a objetos. JSD contiene técnicas útiles para la identificación de entidades y de métodos

dentro de su fase de modelado. Además, la técnica de análisis por ordenación temporal de JSD y

el diseño orientado a objetos utilizan el concepto de los objetos de forma similar, aun cuando sus

terminologías son distintas.

3.3.6. Método OODLE

El OODLE (lenguaje de diseño orientado a objetos) es un componente específico de diseño del

método Shlaer/Mellor (1988), cuya aproximación al análisis orientado a objetos, prescribe 4 tipos

de diagramas, interrelacionados mediante un esquema de capas que ayuda con la documentación

y con un potencial de apoyo automático. Los tipos de diagramas son los siguientes:

Diagramas de dependencia, que muestran relaciones de utilización (cliente/servidor) y de

amigos entre clases.

Diagramas de clases, que muestran el aspecto externo de la clase de forma similar a

Booch.

Diagramas de estructuras de clases que muestran la estructura de los métodos de la clase,

y el flujo de datos y de control

Diagramas de herencia, que representan la herencia

3.4. Otros métodos

3.4.1. Método de Jacobson - Ingeniería de software orientado a objetos (OOSE)

El método de Ivar Jacobson conocido también por OOSE (ISWOO), es una simplificación de

Objectory, también de Jacobson. Se diferencia de los demás por la importancia que le da al caso

de uso que describe como el usuario interactúa con el producto o sistema.

117

En su libro de Ingeniería del Software Orientada a Objetos, Jacobson plantea con respecto a su

metodología que: "La primera transformación hecha es, de la especificación de los

requerimientos, al modelo de requerimientos. El modelo de requerimientos consiste de: un

modelo de casos de usos, la descripción de las interfaces y un modelo del dominio del problema".

El método desarrollado por Ivar Jacobson OOSE ha sido llamado “un enfoque para el manejo de

casos de uso”, en este enfoque el modelo de casos de uso sirve como un modelo central del cual

todos los otros modelos son derivados. Un modelo de casos de uso describe la funcionalidad

completa del sistema, identificando como, todo lo que esta fuera del sistema, interactúa con él.

Como se puede observar en la siguiente Figura 3.9 del modelo de casos de usos se derivan los

modelos: de requerimientos, análisis, diseño, implementación y prueba.

Fuente: Morales (2003)

Metodología OOSE

El modelo de casos de uso de acuerdo con Jacobson (1992), es la base en la etapa de análisis,

construcción y prueba, esto se puede apreciar mejor en la Figura 3.10 donde se puede apreciar

mejor en qué parte de estas etapas se aplican los diferentes modelos utilizados.

Figura 3.9

Manejo de casos de uso

Clases

SI

SI

SI

Modelo de casos de uso

Expresado en términos de

Estructurado por

Realizado por

Implementado por

Probado en

Modelo de

requerimientos

Modelo de

Análisis

Modelo de

diseño

Modelo de

implementación

Modelo de

prueba

Clases

SI

SI

SI

Modelo de casos de uso

Expresado en términos de

Estructurado por

Realizado por

Implementado por

Probado en

Modelo de

requerimientos

Modelo de

Análisis

Modelo de

diseño

Modelo de

implementación

Modelo de

prueba

118

Fuente: Morales (2003)

OOSE presenta cinco técnicas para modelar un sistema:

Modelo de requerimientos: delimita el sistema y define su funcionalidad. El

objetivo es la captura de requerimientos funcionales

Definir los actores y sus responsabilidades.

Identificar los casos de uso para cada actor.

Preparar una visión inicial de los objetos del sistema y sus relaciones.

Revisar el modelo usando los casos de uso como escenarios, para

determinar su validez.

Modelo de análisis: estructura el sistema, modelando tres tipos de objetos (objetos

de interfase, objetos entidad y objetos de control). El objetivo es dar al sistema una

estructura de objetos robusta y flexible a los cambios.

Identificar objetos de interfaz, usando información del tipo actor-

interacción.

Crear vistas estructurales de los objetos de interfaz.

Representar el comportamiento del objeto.

Aislar subsistemas y modelos para cada uno.

Revisar el modelo usando los casos de uso como escenarios, para

determinar su validez.

Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de

implementación. Consiste de diagramas de interacción y diagramas de transición

de estados.

Figura 3.10

Metodología OOSE

Análisis Contracción

Modelo de Requerimientos

Modelos de análisis

Prueba

Modelo de diseño

Modelos de implementación Modelo de Prueba

SistemaRequerimientos

Análisis Contracción

Modelo de Requerimientos

Modelos de análisis

Prueba

Modelo de diseño

Modelos de implementación Modelo de Prueba

SistemaRequerimientos

119

Modelo de implementación: consiste en el código fuente de los objetos

especificados en el modelo de diseño. Tiene como objetivo implementar el sistema.

Modelo de prueba: es llevado acabo mediante la realización de pruebas al modelo

de implementación. Su objetivo es verificar el sistema.

La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos

funcionales y usar sus perspectivas. Es por eso que la relación entre ellos es importante. Para ser

posible el mantenimiento del sistema es también necesario que los modelos sean tangibles.

3.4.2. Método de Graham. - Semantic Object Model Approach (SOMA)

Este método surgió en 1994 su creador por Graham, el cual propuso combinar una notación única

para el análisis OO con unas reglas del estilo de los sistemas basados en el conocimiento, está

conformado por las siguientes actividades:

Identificar capas: Forma de descomponer el dominio del problema.

Identificar objetos.

Identificar estructuras: de clasificación y composición.

Definir la semántica de los datos y asociaciones: Relaciones estructurales entre clases.

Añadir atributos y operaciones a los objetos.

Añadir la semántica declarativa de objetos: Reglas para resolver conflictos.

3.4.3. Método de fusion

En 1990, Derek Coleman de Hewlett-Packard condujo un equipo en el Reino Unido a desarrollar

un sistema de los requisitos para OOAD, este equipo buscaba crear una metodología simple con

una notación sencilla de manejar. El resultado era la fusión, que Coleman y otros desarrollaron

adaptando ideas de otras metodologías, como las de Booch, de Jacobson, de Rumbaugh, y

rechazaron explícitamente muchas ideas de estas metodologías. Coleman no utilizó algunos de

los componentes principales de Rumbaugh y Shlaer y Mellor en la fusion, porque los

componentes no son encontrados debido a que no fueron útiles en las prácticas.

120

3.4.4. Método de Martin/Odell - Object oriented analysis and design (OOAD)

Esta metodología toma ventaja de la teoría determinada y la lógica. Esta metodología se basa en

describir el comportamiento de objetos. Hay muchas técnicas desarrolladas para especificar

objetos y sus relaciones para describir el comportamiento dinámico de los objetos y la capturar de

los procesos del negocio. (Martin, 1992).

Este método realiza un análisis independiente de la estructura estática y la dinámica de los

objetos, se lleva a cabo de la siguiente manera:

Análisis de los requisitos del cliente.

Identificación de la estructura estática del objeto.

Modelación del análisis de la estructura del objeto.

Identificación de la estructura dinámica de los objetos.

Modelación del análisis del comportamiento de los objetos.

Lenguaje de

Modelado Unificado

CAPITULO

Lenguaje de Modelado Unificado

(UML)

El siguiente capítulo se hace un estudio documental sobre el origen y la evolución del Lenguaje

de Modelado Unificado, conocido por sus siglas como UML. Este lenguaje gráfico se usa para

visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de

software; integra una serie de diagramas que son utilizados para el análisis y diseño de software,

para modelar lo conceptual (procesos de negocio y funciones de sistema), además de cosas

concretas como lo son escribir las clases en un lenguaje determinado, esquemas de base de datos

y componentes de software reusables.

4.1. Introducción al UML

Una vez que el paradigma orientado a objetos (OO) fue adoptado como el más adecuado para

producir software de calidad, a principios de los noventa, emergió un buen número de métodos de

desarrollo de software OO. Diversos autores atravesaron por el problema de desarrollar

metodologías diversas, cada uno con sus métodos y hasta sus propios enfoques.

En julio de 1993, Jacobson criticó lo que él denominaba guerra de métodos y planteó la necesidad

de llegar a una notación estándar de modelado, para evitar la confusión reinante (por la falta de

estándares) y favorecer el uso de los métodos de software OO. A finales de 1994 se inició un

esfuerzo de unificación por parte de los creadores de los tres principales métodos: Booch,

Rumbaugh y Jacobson.

Así surgió el Lenguaje de Modelado Unificado (UML, Unified Modeling Language) que es el

resultado de cohesionar en un solo estándar, los mecanismos para desarrollar software, y ello

gracias a los esfuerzos de diversos autores (Ver Figura 4.1) que entendieron que el desarrollo de

126

un estándar era una prioridad en el diseño de software. Según sus creadores, UML (Lenguaje

Unificado de Modelado) es un lenguaje gráfico que sirve para visualizar, especificar, construir y

documentar los componentes de un sistema software.

Fuente: Letelier (1996)

Luego de diversas etapas de evolución, el UML fue adoptado en noviembre de 1997 por la OMG

(Object Management Group) como parte de sus requerimientos, y desde entonces se ha

convertido en un estándar para visualizar, especificar, construir y documentar los modelos que se

crean durante la aplicación de un proceso software. En la Figura 4.2 se puede observar la

evolución de UML hasta los actuales momentos.

Debido a que UML evolucionó a partir de varios métodos orientados a objetos de segunda

generación (en cuanto a nivel de notación), mayoritariamente se cree que sólo es aplicable a

sistemas de software orientados a objeto cuando, realmente, UML no es simplemente un lenguaje

para modelado orientado a objeto de tercera generación, sino un “lenguaje para modelado

unificado” relativo a sistemas en general.

UML

Rumbaugh

Jacobson

Meyer

Harel

Wirfs-Brock

Fusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions,

message numbering

Singleton classes

Frameworks, patterns,

notes

Object life cyclesUML

Rumbaugh

Jacobson

Meyer

Harel

Wirfs-Brock

Fusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions,

message numbering

Singleton classes

Frameworks, patterns,

notes

Object life cycles

Figura 4.1

Influencia de métodos de desarrollo de software y UML

127

Fuente: Letelier (1996)

El lenguaje de modelado unificado sirve para especificar, visualizar y documentar esquemas de

sistemas de software. UML no es un método de desarrollo, lo que significa que no sirve para

determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que le ayuda a visualizar el

diseño y a hacerlo más accesible para otros. Al ser un lenguaje de modelado gráfico y no un

método, consiste en una notación que cualquier método puede emplear para expresar su diseño.

UML permite tanto la especificación conceptual de un sistema como la especificación de

elementos concretos, como pueden ser el diseño de clases o el de una base de datos.

Según su definición, los objetivos de UML son los siguientes:

Visualizar, UML permite representar mediante su simbología el contenido y la estructura de un

sistema software. La notación UML permite definir modelos que serán claramente comprensibles

por otros desarrolladores facilitando así el mantenimiento del sistema que describe. Especificar,

UML permite especificar los procesos de análisis, diseño y codificación de un sistema software.

Figura 4.2

Evolución de UML

Otros métodos Booch’91 OMT-1 (Rumbaugh) OOSE (Jacobson)

Booch’93 OMT-2

OOPSLA’95 Método Unificado 0.8

Junio 96 y Octubre 1996 en la Web

UML 1.0Publicación de UML 1.0

Enero 1997

UML 1.1OMG lo adopta como estándar

Noviembre 1997

Colaboradores y

expertos

Do

cum

ento

s P

ub

lica

do

s

Fragmentación

Unificación

Estandarización

UML 1.3Junio 1999, OMG

diciembre 2004, OMG

UML 1.4

UML 1.5

UML 2.0UML 2.0

Industrializaciónmayo 2001, OMG

marzo 2003, OMG

UML 0.9 & 0.91

Otros métodos Booch’91 OMT-1 (Rumbaugh) OOSE (Jacobson)

Booch’93 OMT-2

OOPSLA’95 Método Unificado 0.8

Junio 96 y Octubre 1996 en la Web

UML 1.0Publicación de UML 1.0

Enero 1997

UML 1.1OMG lo adopta como estándar

Noviembre 1997

Colaboradores y

expertos

Do

cum

ento

s P

ub

lica

do

s

Fragmentación

Unificación

Estandarización

UML 1.3Junio 1999, OMG

diciembre 2004, OMG

UML 1.4

UML 1.5

UML 2.0UML 2.0

Industrializaciónmayo 2001, OMG

marzo 2003, OMG

UML 0.9 & 0.91

128

También permite determinar modelos precisos, sin ambigüedades, detallando las partes

esenciales de los mismos.

Especificar, UML permite especificar cuáles son las características de un sistema antes de su

construcción.

Construir, Las anteriores características permiten que UML pueda generar código en distintos

lenguajes de programación y tablas en una base de datos a partir de modelos UML. Además

permite simular el comportamiento de sistemas software.

Documentar, Como ya se comentó antes, UML permite especificar los procesos de análisis,

diseño y codificación y también permite documentar los mismos, dejando clara la arquitectura del

sistema.

En resumen, UML posibilita la captura y comunicación del conocimiento y facilita la adaptación

al posible aumento de complejidad o cambio. Este lenguaje para modelado (estandarizado en

ciertas industrias), no es un lenguaje cerrado, sino más bien, un lenguaje abierto y totalmente

extensible.

4.1.1. UML 2.0

La versión 2.0 de UML viene acompañada de nuevas versiones de los estándares MOF (Meta

Object Facility), XMI (XML Metadata Interchage) y OCL (Object Constraint Language). Es un

intento de coordinación general de varios estándares para dar un soporte más formal y completo a

la filosofía general de MDA (Model Driven Arquitectura). MOF 2.0 da soporte al núcleo de

UML y permite la creación formal de un número indeterminado de niveles de abstracción. XMI

2.0 permite la serialización automática de los modelos UML en forma de ficheros XML y de los

metamodelos en forma de XML Schemas. Está recomendado su uso para el intercambio estándar

de información entre herramientas UML y para el almacenamiento de los modelos en repositorios

XML.

129

Mientras que UML 1.4 tenía como objetivo principal la respuesta a las necesidades clásicas de la

industria del SW, UML 2.0 se plantea cubrir otros campos como el modelado de negocio, de

sistemas de tiempo real, basado en componentes, etc. El mecanismo estándar para extender las

capacidades de UML a cada uno de estos campos específicos es el de los perfiles y este

mecanismo se ve mejorado en la nueva versión. En general, se mejora la escalabilidad y

usabilidad del lenguaje en todos los ámbitos.

Características generales de UML 2.0:

Simplificación de la sintaxis y semántica del lenguaje.

Alineación formal con MOF.

Soporte del modelado de la arquitectura SW y del modelado basado en componentes, lo

que conlleva el uso de una nueva semántica:

Además de la semántica de comportamiento y datos propia de la orientación a objetos,

se expresan servicios e interfaces para desarrollar entidades autónomas.

Concepto de puerto (punto de interacción entre clases) y de puerto de comportamiento

(configuración inicial de una clase, capacidad para crear y borrar partes).

Descomposición jerárquica (bloques que se ensamblan formando bloques mayores)

Se refina el modelo de desarrollo y el de proceso, gracias a la mejora de los diagramas de

actividad, de interacciones y máquinas de estados.

Nuevo mecanismo de extensión para añadir metaclases propias y mejorar así la definición

de perfiles.

Soporte de arquitecturas en tiempo de ejecución para modelar flujo de datos y objetos

entre diferentes partes del sistema.

Mejor representación de las relaciones.

Mejor modelado de comportamiento con encapsulado y escalabilidad.

Modelos ejecutables (nueva semántica de acción):

130

Capacidad para definir puntos de entrada y salida de un estado compuesto.

Capacidad para expresar un bloque de acción.

Semánticas de acciones de ejecución (el modelo es independiente del lenguaje

destino). OCL (Object Constraint Language) refinado para dotar de semántica de

comportamiento (acción) a UML (aparte de la estructural).

UML 2.0 hace innecesario el uso de extensiones de su metamodelo para tratar los problemas

específicos de dominios específicos.

4.1.2. Modelo conceptual de UML

Según Booch, Rumbaugh y Jacobson (2002), el modelo conceptual de UML esta constituido por

tres grandes elementos:

1. Los bloques básicos de construcción de UML.

2. Las reglas semánticas que definen como se pueden combinar dichos bloques.

3. Mecanismos comunes de aplicación general.

Bloques de construcción de UML

Los bloques de construcción están subdivididos en elementos, relaciones y diagramas; los

elementos son las abstracciones de un modelo, pueden ser de algún componente o aspecto del

sistema modelado; las relaciones ligan estos elementos entre sí; los diagramas agrupan elementos

y relaciones.

Reglas de UML

Los bloques de construcción se deben combinar siguiendo las reglas que establece UML. UML

establece una serie de normas sobre cómo nombrar a los elementos, relaciones y diagramas; la

131

visibilidad y alcance de dichos nombres y sobre su integridad (cómo diseñar relaciones

consistentes). Podremos decir que un modelo está bien formado cuando cumpla estas reglas.

Las reglas semánticas se aplican a:

Los nombres: cómo llamar a los elementos, relaciones y diagramas

Ámbito o Alcance: contexto que da un significado específico a un nombre.

Visibilidad: cómo se pueden ver y utilizar estos nombres por otros.

Integridad: cómo se relacionan unos elementos con otros.

Ejecución: significado de simular o ejecutar un modelo dinámico

Las reglas de UML se aplican en las fases de análisis, diseño e implementación con el fin de

obtener un sistema eficiente y bien formado.

Mecanismos comunes de aplicación general

Bajo una serie de mecanismos que se aplican durante todo el proceso de desarrollo de modelos en

UML, se consiguen diseños simples y eficientes. UML utiliza cuatro mecanismos comunes

aplicados de forma consistente al sistema.

1. Especificaciones. Proporcionan una explicación textual de la sintaxis y la semántica de un

bloque de construcción.

Ejemplo: cuando se define una clase, detrás de ella hay una especificación que proporciona toda

la información acerca de sus atributos, operaciones y comportamiento. Un icono de la clase

puede mostrar una pequeña parte de su especificación. También se pueden generar vistas de la

clase que contengan elementos totalmente diferentes pero que están relacionados con las

especificaciones dadas a la clase inicial.

La notación gráfica de UML se utiliza para visualizar un sistema, la especificación de UML se

utiliza para enunciar los detalles del sistema. Se puede construir un modelo dibujando primero los

diagramas y luego añadir la semántica a las especificaciones o generar los diagramas a partir de

las especificaciones establecidas.

132

2. Apariencia o Adornos. Son los detalles de la especificación de un elemento que se añade

a su notación gráfica básica, incluye aspectos como el nombre, sus atributos y operaciones.

La especificación de una clase puede incluir detalles como si es abstracta o la visibilidad

de sus atributos y operaciones. Estos detalles se pueden incluir como adornos.

3. Categorizaciones o Divisiones Comunes: Cuando se modelan sistemas orientados a

objetos el mundo puede dividirse de varias formas. División entre clase y objeto,

separación entre interfaz e implementación, imagen interfaz e implementación

4. Mecanismos de Extensibilidad: Ya que un lenguaje cerrado no siempre es útil para la

representación de los matices de los modelos en todos los dominios y en todos los

momentos, UML es abierto permitiendo extender el lenguaje de manera controlada. Los

mecanismos de extensión incluyen:

o Estereotipos: Extiende el vocabulario de UML permitiendo crear nuevos tipos de

bloques de construcción que deriven de los existentes y que sean específicos a un

problema.

o Valores Etiquetados: Extiende las propiedades de un bloque de construcción de

UML, permitiendo añadir nueva información a la especificación del elemento.

Ejemplo: Cuando se trabaja con un producto que atraviesa muchas versiones a lo largo del tiempo,

se querrá registrar la versión y el autor. Para ello, estos datos pueden ser añadidos a cualquier

bloque de construcción, como una clase introduciendo nuevos valores etiquetados.

o Restricciones. Extiende la semántica de un bloque de construcción de UML,

permitiendo añadir nuevas reglas o modificar las existentes

En la Figura 4.3 se muestran los conceptos que maneja UML, organizados en un cuadro sinóptico

hecho a partir del modelo conceptual de UML que se enuncia en el libro de The Unified

Modeling Language Users Guide (Booch, Rumbaugh y Jacobson, 1999).

133

4.1.3. Diagramas en UML 2.0

UML en su versión 2.0 describe un total de trece (13) diagramas distintos. La particularidad de

UML es que no mantiene una relación estricta entre los diagramas y los elementos que éstos

contienen, sino que es posible el empleo de símbolos en principio asociados a un determinado

Figura 4.3

Modelo conceptual de UML

Fuente: Booch, Rumbaugh

y Jacobson (1999)

134

tipo de diagrama en otro distinto si de esta forma se clarifica el diseño del sistema que se está

modelando.

Los diagramas UML definen los modelos que manejan el lenguaje de modelado y se clasifican en

estáticos o de estructura y de comportamiento, como se observan en la Figura 4.4.

Figura 4.4

Diagramas en UML 2.0

Fuente: Fowler (2003)

135

4.2. Diagramas de estructura o estáticos

Son los diagramas que reflejan la estructura estática del sistema. Se centran en la identificación y

descripción de los elementos y componentes que forman parte del mismo, y de la forma que

tienen éstos de relacionarse entre sí.

4.2.1. Diagrama de clases

El diagrama de clases como se ve en la Figura 4.5 describe los tipos de objetos del sistema, y las

distintas relaciones estáticas que se dan entre ellos. Los diagramas de clases muestran también las

propiedades y operaciones de una clase, y las restricciones que se deben aplicar a la hora de

relacionar objetos

Las propiedades representan los rasgos estructurales de una clase. En una primera aproximación,

se corresponderían los atributos de la clase.

Las operaciones son las acciones que una clase puede llevar a cabo. Estas se corresponden con

los métodos de la clase. Normalmente no todas las operaciones son representadas en el diagrama

de clases, sólo las más representativas.

Las relaciones permiten representar las colaboraciones entre clases que se van a dar en el sistema.

UML contempla diferentes formas de relación entre clases, como las asociaciones y las

generalizaciones.

136


4.2.2. Diagrama de componentes

Un diagrama de componentes (Ver Figura 4.6) muestra las organizaciones y dependencias lógicas

entre componentes del software, sean éstos componentes de código fuente, binarios o ejecutables.

Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos

relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las

restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el

desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán

componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de componentes, ya

Figura 4.5

Ejemplo de un diagrama de clases

137

que las instancias específicas de cada tipo se encuentran especificadas en el diagrama de

despliegue.

Dado que los diagramas de componentes muestran los componentes de software que constituyen

una parte reutilizable, sus interfaces, y sus interrelaciones, en muchos aspectos se puede

considerar que un diagrama de componentes es un diagrama de clases a gran escala. Cada

componente en el diagrama debe ser documentado con un diagrama de componentes más

detallado, un diagrama de clases, o un diagrama de casos de uso.

Un paquete en un diagrama de componentes representa una división física del sistema. Los

paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida.


4.2.3. Diagramas de estructuras compuestas

Los diagramas de estructura compuesta como se observa en la Figura 4.7 permiten descomponer

una clase en su estructura interna (Fowler, 2003), de esta forma, es posible desgranar en partes

los objetos complejos del sistema.

Figura 4.6

Ejemplo de un diagrama de componentes

138

Los diagramas de estructuras compuestas son similares a los diagramas de paquetes, con la

salvedad de que estos últimos referencian agrupaciones dadas en tiempo de compilación,

mientras que los primeros muestran agrupaciones que sedan en tiempo de ejecución.


4.2.4. Diagrama de despliegues

Un diagrama de despliegue como se observa en la Figura 4.8 muestra las relaciones físicas entre

los componentes hardware y software en el sistema final, es decir, la configuración de los

elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y

objetos que se ejecutan en ellos). Están formados por instancias de los componentes de software

que representan manifestaciones del código en tiempo de ejecución (los componentes que sólo

sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes).

Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un

nodo puede contener instancias de componentes de software, objetos, procesos (caso particular de

un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a

un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de

dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).

Figura 4.7

Ejemplo de un diagrama de estructura compuesta

139

Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional,

generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o

tipos de nodos que se representa como un cubo 3D en los diagramas de implementación.

Las instancias de componentes de software muestran unidades de software en tiempo de

ejecución y generalmente ayudan a identificar sus dependencias y su localización en nodos.

Pueden mostrar también qué interfaces implementan y qué objetos contienen.

Los diagramas de despliegue muestran la configuración en funcionamiento del sistema,

incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se

deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de

respuesta requerido, etc.


La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la

topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son

fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema.

Aunque UML no es un lenguaje para especificar hardware de propósito general, se ha diseñado

para modelar muchos de estos aspectos a nivel básico, que sirven para que un ingeniero de

Figura 4.8

Ejemplo de un diagrama de despliegue

140

software pueda especificar la plataforma sobre la que se ejecuta el software del sistema y para

que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se

trata de una relación de conexión o comunicación. Los diagramas de despliegue sirven para

razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software.

Esta vista cubre principalmente la distribución, entrega e instalación de las partes que configuran

un sistema físico. Los diagramas de despliegue se suelen utilizar para modelar:

Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran

cantidad de software que interactúa con el mundo físico. Los sistemas empotrados

involucran software que controla dispositivo (motores, periféricos) que a su vez están

controlados por estímulos externos como sensores.

Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de

los sistemas distribuidos. Requieren tomar decisiones sobre la conectividad de red de los

clientes a los servidores, y sobre la distribución física de los componentes software del

sistema a través de los nodos.

Sistemas completamente distribuidos: son aquellos sistemas que son ampliamente o

totalmente distribuidos y que normalmente incluyen varios niveles de servidores, tales

sistemas contienen a menudo varias versiones de componentes software, alguno de los

cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere

tomar decisiones que permitan un cambio continuo de la topología del sistema.

4.2.5. Diagramas de objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagrama s de

clases. Un diagrama de objetos (Ver Figura 4.9) muestra un conjunto de objetos y sus relaciones

en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos

estáticos del sistema, mientras que los diagramas de interacción se utilizan para ver los aspectos

dinámicos del mismo. Estos cuentan con instancias de los elementos del diagrama de clases y

mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos,

que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases,

141

representando sólo la parte estática de un interacción, consistiendo en los objetos que colaboran

pero sin ninguno de los mensajes intercambiados entre ellos.

Los diagramas de objetos se emplean para modelar la vista de diseño estática o la vista de

procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la

perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos

funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos

estáticas.

En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que

implica tomar una instancia de los objetos de un sistema en un cierto momento. Un diagrama de

objetos representa una escena estática representada por un diagrama de interacción. Los

diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia

de ciertas instancias en el sistema, junto a las relaciones entre ellas.

Los diagramas de objetos son especialmente útiles para modelar estructuras de datos complejas.

Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un

conjunto de clases con varias relaciones entre ellas, pueden existir muchas más configuraciones

posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar

significativamente conjuntos interesantes de objetos concretos o prototipos.

desde el diagrama de clases

Fuente: Matteo (2005)

Figura 4.9

Ejemplo de un diagrama de objetos

Juan:Usuario

Nombre: “Juan L”

Edad: 22

Lisiu:Ordenador

Marca: “Sun”

UsaJuan:Usuario


Edad: 22

Juan:Usuario


Edad: 22

Lisiu:Ordenador

Marca: “Sun”

Usa

Ordenador

Marca: String

Usuario

Nombre: String

Edad: Integer

Usa0…* 1…*

Ordenador

Marca: String

Usuario

Nombre: String

Edad: Integer

Usa0…* 1…*

142

4.2.6. Diagrama de paquetes

Según la página web wikipedia3 un diagrama de paquetes muestra como un sistema está dividido

en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que

normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran

una descomposición de la jerarquía lógica de un sistema.

Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Para

ser funcional, la asignación debe seguir un cierto principio racional, tal como funcionalidad

común, implementación relacionada y punto de vista común. UML no impone una regla para

componer los paquetes.

Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas

agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del

modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los

modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión

de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del

modelo.

Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento

pertenece a (está definido en) sólo un paquete.

Los paquetes contienen elementos del modelo al más alto nivel, tales como clases y sus

relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones.

Atributos, operaciones, estados, líneas de vida y mensajes están contenidos en otros elementos y

no aparecen como contenido directo de los paquetes.

Las dependencias que se presentan entre los elementos individuales, pero en un sistema de

cualquier tamaño, deben ser vistas en un nivel más alto. Cuando las dependencias se dan entre

paquetes, resumen dependencias entre los elementos internos a ellos, es decir, las dependencias

del paquete son derivables a partir de las dependencias entre los elementos individuales.

La presencia de una dependencia entre paquetes implica que existe en un enfoque ascendente

(una declaración de existencia), o que se permite que exista más adelante en un enfoque

descendente (una restricción que limita cualquier otra relación), por lo menos un elemento de

3 http://es.wikipedia.org/wiki/Diagrama_de_paquetes

http://es.wikipedia.org/wiki/Diagrama_de_paquetes

143

relación con el tipo de dependencia indicado entre elementos individuales dentro de los paquetes

correspondientes.

Las dependencias múltiples del mismo tipo entre elementos individuales se agregan a una sola

dependencia entre los paquetes que contienen los elementos. Si las dependencias entre elementos

contienen estereotipos, éste puede ser omitido en la dependencia del paquete, para dar una sola

dependencia de alto nivel.

Una clase de un paquete puede aparecer en otro paquete por la importación a través de una

relación de dependencia entre paquetes. Todas las clases no son necesariamente visibles desde el

exterior del paquete, es decir, un paquete encapsula a la vez que agrupa.

En general, un paquete no puede tener acceso al contenido de otro paquete. Los paquetes son

cerrados, a menos que sean abiertos por una dependencia de acceso o de importación. La

dependencia de acceso indica que el contenido del paquete del proveedor puede aparecer en

referencias efectuadas por los elementos del paquete cliente. En general, un paquete puede ver

solamente los elementos de otros paquetes que tienen visibilidad pública. Los elementos con

visibilidad protegida pueden ser vistos únicamente por los paquetes que son descendientes del

paquete contenedor de dichos elementos. Los elementos con visibilidad privada sólo son vistos

por su paquete contenedor y anidados. La visibilidad también se aplica a las clases. El permiso de

acceso y visibilidad son necesarios para hacer referencia a un elemento.

La dependencia de acceso no modifica el espacio de nombres del cliente no crea las referencias

automáticamente, simplemente concede permiso para establecer referencias. La dependencia de

importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como

sinónimos de los caminos completos.

Los paquetes se dibujan como rectángulos con pestañas, y las dependencias se muestran como

flechas con líneas discontinuas. El operador: permite designar una clase definida en un contexto

distinto del actual, en la Figura 4.10 se muestra que el paquete “yyedra” contiene una

presentación y se relaciona con el paquete “util”.

144


4.3. Diagramas de comportamiento o dinámicos

Los diagramas dinámicos reflejan el comportamiento del sistema y de sus componentes. Tratan

de representar aspectos ligados al tiempo, mostrando como interactúan las distintas partes del

sistema.

4.3.1. Diagramas de actividades

Para Fowler (2003), los diagramas de actividades son una técnica para describir lógica de

procedimientos, procesos de negocios, y flujo de trabajo. En muchos modos juegan un papel

similar al de los diagramas de flujo, pero la principal diferencia entre ellos y la notación de los

diagramas de flujo es que ellos soportan el comportamiento paralelo. Un diagrama de actividad

representa el comportamiento mediante un modelo de flujo de datos y flujo de control

El ejemplo tomado del libro UML Distilled nos muestra un simple diagrama de actividades (Ver

Figura 4.11). Donde se comienza la acción en el nodo inicial y entonces hacemos que la acción

reciba órdenes. Hecho esto, encontramos un tenedor (nodo fork). Un tenedor tiene un flujo

entrante y varios flujos concurrentes salientes.

En la Figura 4.11 se muestra que llenar la orden, enviar la factura y las acciones subsecuentes

ocurren en paralelo. Esencialmente, esto significa que la secuencia entre ellas es irrelevante. Se

yyedra

presentación

utilyyedra

presentación

yyedra

presentación

utilutil

Figura 4.10

Ejemplo de un diagrama de paquetes

145

podría llenar la orden, enviar la factura, entregar y recibir el pago; o podría enviar la factura,

recibir el pago, llenar la orden y luego entregar.

También se podría llevar a cabo estas acciones por individual (interleaving). Se toma el primer

ítem de línea de los depósitos, escribo la factura, tomo el segundo ítem de línea, pongo la factura

en un sobre, y así sucesivamente. O podría ejecutar varias de estas simultáneamente: escribo la

factura con una mano mientras busco en mis depósitos con la otra. Cualquiera de estas secuencias

es correcta de acuerdo al diagrama.

El diagrama de actividades permite que cualquiera que este ejecutando el proceso pueda escoger

el orden en el cual desee hacer las cosas. En otras palabras, el diagrama simplemente declara las

reglas esenciales de secuencia que debe seguir. Esto es importante en el modelado de negocios

porque aquí los procesos usualmente ocurren en paralelo. También es útil para algoritmos

concurrentes, en los cuales los hilos independientes pueden hacer cosas en paralelo.

Cuando existe procesos en paralelo se deben sincronizar, por ejemplo, no se cerrará la orden

hasta que sea entregada y pagada. Se muestra esto unido antes de la acción de Cerrar Orden. Con

una unión, el flujo saliente es tomado solo cuando todos los flujos entrantes alcanzan la unión. De

modo que solo puedes cerrar la orden cuando has recibido el pago y entregado.

Se puede observar que los nodos sobre un diagrama de actividades son llamados acciones, no

actividades. Una actividad se refiere estrictamente a una secuencia de acciones, de modo que el

diagrama muestra una actividad hecha de acciones.

En la Figura 4.11, después de que la orden es llenada hay una decisión. Si tienen una orden

urgente, hacen una entrega nocturna; de otro modo hacen una entrega regular.

Una fusión tiene múltiples flujos de entrada y un único saliente. Un nodo merge marca el fin del

comportamiento condicional empezado por una decisión.

146


Acciones

En un diagrama de actividad una acción es un nodo de actividad ejecutable.

Una acción representa una unidad fundamental de funcionalidad ejecutable en una actividad. En

la Figura 4.12 se puede observar un ejemplo de una acción.


Figura 4.11

Ejemplo de un diagrama de actividades

Figura 4.12

Ejemplo de una “acción”

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura

Llenar

orden

Entregar

de noche

Entregar

regular

actividad final

joinnodo merge

acción

decisión

[sino]

nodo inicial

nodo fork

flujo

[prioridad]

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura

Llenar

orden

Entregar

de noche

Entregar

regular

actividad final

joinnodo merge

acción

decisión

[sino]

nodo inicial

nodo fork

flujo

[prioridad]

Enviar fichero PostScript

a la impresora

Crear fichero PostScrptMostrar mensaje

“imprimiendo”

Flujo de ControlAcción

Nodo final de actividad

Nodo inicial

Eliminar mensajeEnviar fichero PostScript

a la impresora

Crear fichero PostScrptMostrar mensaje

“imprimiendo”

Flujo de ControlAcción

Nodo final de actividad

Nodo inicial

Eliminar mensaje

147

Expresiones resguardadas (guard expressions)

Una expresión resguardada es utilizada para indicar una descripción explicita acerca de una

transición. Este tipo de expresión es representada mediante corchetes ([...] y es colocada sobre la

línea de transición.

Actividades

Una actividad representa un comportamiento compuesto de elementos individuales que son las

acciones. El flujo de ejecución se modela con nodos de actividad conectados por arcos de

actividad.

Los nodos incluyen:

Acciones de varios tipos: funciones primitivas, invocación de comportamiento, acciones de

comunicación (señales) y manipulación de objetos.

Objetos: nodos que proporcionan y aceptan objetos y datos.

Constructores de control de flujo: sincronización, decisión y control de concurrencia

Tipos de nodos

• Nodo de decisión: nodo con un arco de entrada y varios arcos de salida

• Nodo de fusión (merge): nodo de control al que llegan varios flujos alternativos

• Nodo tenedor (fork): Nodo de control que divide un flujo en múltiples flujos

concurrentes.

• Nodo unión (join): nodo que tiene como arcos de entrada múltiples flujos concurrentes y

un solo arco de salida.

• Nodo inicial: nodo de control en el que comienza el flujo cuando se invoca una actividad

• Nodo final:

- De actividad: nodo que detiene todos los flujos de una actividad

- De flujo: nodo que detiene un flujo

En la Figura 4.13 se pueden observar todos los tipos de nodos mencionados anteriormente.

148


Flujos y límites

UML usa los términos flujo y límite como sinónimos para describir las conexiones entre dos

acciones. El tipo más simple de límite es la flecha simple entre dos acciones. Le pueden dar un

nombre a un límite si eso desean, pero la mayor parte del tiempo, una simple flecha será

suficiente.

Si están teniendo problemas guiando las líneas, pueden usar conectores, los cuales simplemente

le ahorrarán el trabajo de tener que dibujar una línea para toda la distancia. Cuando se usan

conectores, se deben usar en pares: uno con el flujo entrante, uno con un flujo saliente y ambos

con el mismo tipo de etiqueta.

Los límites más simples pasan un token que no tiene ningún significado más que controlar el

flujo. Sin embargo, pueden también pasar objetos a lo largo de límites; luego los objetos juegan

el papel de tokens mientras llevan datos. Si están pasando un objeto a lo largo de un límite,

pueden mostrar eso poniendo una casilla de clase en el límite, o pueden usar pines sobre las

acciones.

Figura 4.13

Notación de diferentes tipos de nodos

Nodo final de flujoNodo inicial Nodo final de actividad

Nodo de decisión Nodo Fork

Nodo joinNodo merge

Nodo de decisión con

comportamiento

Nodo final de flujoNodo inicial Nodo final de actividad

Nodo de decisión Nodo Fork

Nodo joinNodo merge

Nodo de decisión con

comportamiento

149

Todos los estilos mostrados en la Figura 4.14 son equivalentes; deben usar cualquiera que

transmita mejor lo que intentan comunicar. La mayoría de las veces una simple flecha es

totalmente suficiente


Regiones de expansión

Con los diagramas de actividad, usualmente se encuentran en situaciones en las cuales la salida

de una acción activa múltiples invocaciones de otra acción. Hay muchas maneras de mostrar esto,

pero la mejor manera es usar una región de expansión. Una región de expansión marca un área

del diagrama de actividad donde las acciones ocurren una vez por cada ítem en un grupo.

En la Figura 4.15, la acción “elegir tópico” genera una lista de tópicos así como su salida.

Entonces cada elemento de esta lista se convierte en un token para la entrada a la acción de

“escribir artículo”. Igualmente, cada acción “revisar artículo” genera un único artículo que es

añadido a la lista de salida de la región de expansión. Cuando todos los tokens en la región de

expansión terminan en el grupo de salida, la región genera un único token para la lista que es

pasado a “publicar artículo”.

En este caso, tienen la misma cantidad de ítem tanto en el grupo de salida como en el de entrada.

Sin embargo, pueden tener menos, en cuyo caso la región de expansión actúa como un filtro.

Figura 4.14

Ejemplos de flujos y límites

Cuatro modos de mostrar un límite

Recibir

factura

Recibir

factura

Recibir

factura

Recibir

factura

Realizar

pago

Realizar

pago

Realizar

pago

Realizar

pago

Orden

A A

pin

orden orden

nodo objeto

(1)

(4)

(3)

(2)

conector

Cuatro modos de mostrar un límite

Recibir

factura

Recibir

factura

Recibir

factura

Recibir

factura

Realizar

pago

Realizar

pago

Realizar

pago

Realizar

pago

Orden

A A

pin

orden orden

nodo objeto

(1)

(4)

(3)

(2)

conector

Recibir

factura

Recibir

factura

Recibir

factura

Recibir

factura

Realizar

pago

Realizar

pago

Realizar

pago

Realizar

pago

Orden

A A

pin

orden orden

nodo objeto

(1)

(4)

(3)

(2)

conector

150

En la Figura 4.15 todos los artículos son escritos y revisados en paralelo, lo cual es señalado con

la palabra clave concurrent. También puede haber una región de expansión iterativa. Las regiones

iterativas deben procesar completamente cada elemento de entrada uno a la vez.


Señales

Señales en un diagrama de actividades

Una señal de tiempo ocurre cuando transcurre algún tiempo. Dichas señales pueden indicar el

final de un mes en período financiero o cada micro segundo en un controlador de tiempo real.

La Figura 4.16 muestra una actividad que recibe dos señales. Una señal indica que la actividad

recibe un evento de un proceso externo. Esto indica que la actividad constantemente presta

atención a esas señales, y el diagrama define como reacciona la actividad.

En el caso de la Figura 4.16, dos (2) horas antes de que el vuelo despegue se debe empezar a

empacar el equipaje. Aún si el equipaje estuviera listo, no se puede ir al aeropuerto si el taxi no

llega. Si el taxi llega antes de que termine de alistar el equipaje, debe esperar a que termine antes

de irnos.

Elegir

tópico

Escribir

artículo

región de expansiónlista de tópicos

Revisar

artículos

Publicar el

artículo

Palabra clave

Pin_ caja de lista

<<concurrent>>

Elegir

tópico

Escribir

artículo

región de expansiónlista de tópicos

Revisar

artículos

Publicar el

artículo

Palabra clave

Pin_ caja de lista

<<concurrent>>

Figura 4.15

Regiones de expansión

151


Envío y recepción de señal

Así como recibimos señales, podemos enviarlas. Esto es útil cuando tenemos que enviar un

mensaje y luego esperar una respuesta antes de continuar. La figura 4.17 muestra un buen

ejemplo de esto con un idioma común de timing out o pausa. Se puede observar que los dos flujos

se hallan en una carrera: El primero en alcanzar el estado final ganará y acabará con el otro flujo.

Aunque las admisiones esta generalmente esperando por un evento externo, también se puede

mostrar un flujo entrando a ellas. Eso indica que no comenzamos a percibir las señales hasta que

el flujo active la admisión.


Particiones

Los diagramas de actividad (Fowler, 2003), les dice que pasa, pero no les dice quién hace qué. En

programación, esto significa que el diagrama no transmite cuál clase es responsable por cada

Figura 4.16

Señales en un diagrama de actividades

Figura 4.17

Envío y recepción de señales

Empacar

equipaje

señal de tiempo

Llega el taxi

Ir al

aeropuerto

aceptar la señal

2 hrs. antes del

vuelo

Empacar

equipaje

señal de tiempo

Llega el taxi

Ir al

aeropuerto

aceptar la señal

2 hrs. antes del

vuelo

Confirmar

itinerario

Esperar 48 horas

aceptar la señal

Enviar la señal

Itinerario

de libros

Cancelar

itinerario

Reservar

itinerario

Enviar

itinerario

Confirmar

itinerario

Esperar 48 horas

aceptar la señal

Enviar la señal

Itinerario

de libros

Cancelar

itinerario

Reservar

itinerario

Enviar

itinerario

152

acción. En el modelado de procesos de negocios, éste no transmite cual parte de una organización

lleva a cabo cual acción. Esto no es necesariamente un problema; generalmente tiene sentido

concentrarse en lo que se ha hecho en lugar de quién hace que partes del comportamiento.

Si quieren mostrar quién hace qué, pueden dividir un diagrama de actividades en particiones, las

cuales muestran las acciones que llevan a cabo una clase o unidad de organización. La Figura

4.18 muestra un ejemplo simple de esto, mostrando como las acciones involucradas en el

procesamiento de órdenes pueden ser separadas en varios departamentos.

La fragmentación de la Figura 4.18 es una simple partición unidimensional. Este estilo es

generalmente llamado carriles de nado, por razones obvias, y fue el único formato usado en UML

1.x. En UML 2, pueden usar una red bidimensional, de modo que el sentido metafórico del carril

de nado se pierde. También se puede tomar cada dimensión y dividir las filas y las columnas

jerárquicamente.


Figura 4.18

Ejemplo de particiones en un diagrama de actividades

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura

FinanzasCumplimiento Servicio al Cliente

Llenar

orden

Entregar

orden

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura


Llenar

orden

Entregar

orden

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura


Llenar

orden

Entregar

orden

Llenar

orden

Entregar

orden

153

4.3.2. Diagramas de casos de uso

Un diagrama de casos de Uso muestra la relación entre los actores y los casos de uso del sistema.

Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Un

caso del uso especifica el comportamiento de un sistema o de una parte de este y describe las

secuencias de las acciones

Booch (2002) afirma que los diagramas de casos de uso se pueden utilizar para representar el

comportamiento deseado de un sistema, sin la necesidad de especificar cómo este

comportamiento se pone en ejecución. Los diagramas de casos de uso proveen una manera que

los desarrolladores, los especialistas finales del dominio y los usuarios tienen una comprensión

común del problema. Un caso de uso representa un requisito funcional del sistema en su totalidad.

Los diagramas de casos describe un conjunto de secuencias, cada una representa una interacción

de los actores externos. Este comportamiento, en la realidad son funciones utilizadas a nivel de

sistema para visualizar, especificar, construir y colocar el comportamiento previsto del sistema

durante el análisis de requisitos.

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son actores, casos de uso y

relaciones entre casos de uso.

Actores: un actor es una entidad externa al sistema que realiza algún tipo de interacción

con el mismo. Se representa mediante una figura humana dibujada con líneas. Esta

representación sirve tanto para actores que son personas como para otro tipo de actores

(otros sistemas, sensores, etc.).

Casos de uso: un caso de uso es una descripción de la secuencia de interacciones que se

producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una

tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el

Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su

interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea

llevar a cabo usando el sistema.

154

Relaciones en un diagrama de casos de uso:

Las relaciones que se dan en un diagrama de casos de uso son de asociación, generalización y

dependencia, en la figura 4.19 se muestra su notación.

Asociación: es la partición de un actor en un caso de uso, la instancia de un actor se comunican

con instancias de un caso de uso

Generalización: Relación taxonómica entre un caso de uso más general y otro más específico

(también entre actores)

Dependencia:

<<extend>>: Relación que define un curso alterno opcional (dependiendo de una

condición) de otro caso de uso

<<include>>: Relación que define una instancia de un caso de uso como un curso

obligatorio en otro caso de uso.

Figura 4.19

Relaciones en un diagrama de casos de uso

Asociación

Generalización

Dependencia <<extend>>

<<include>>


Como se puede observar en la Figura 4.20 un diagrama de casos de uso se puede representar

como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la

caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que

participa mediante una línea.

155


4.3.3. Diagrama de máquina de estado

Un diagrama de estados muestra la secuencia de estados por los que pasa un caso de uso o un

objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles

son las respuestas y acciones que genera. La Figura 4.21 muestra su representación, un diagrama

de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones

etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada

con el nombre del estado en su interior. Una transición se representa como una flecha desde el

estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el

primer compartimiento aparece el nombre del estado. El segundo compartimiento es opcional, y

en él pueden aparecer acciones de entrada, de salida y acciones internas.

Figura 4.20

Ejemplo de un diagrama de casos de uso

156


Una acción de entrada aparece en la forma entrada/acción asociada donde acción asociada es el

nombre que se le da a la acción que realiza al entrar en ese estado. Cada vez que se entra al

estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece

en la forma salida/acción asociada. Cada vez que sale del estado por una transición de salida la

acción de salida se ejecuta.

Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese

estado, pero que no causa una transición a otro estado. Se indica en la forma nombre de

evento/acción asociada.

Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay

un estado inicial de creación y un estado final de destrucción (del caso de uso o del objeto). El

estado inicial se representa con un círculo sólido y el estado final como un círculo sólido rodeado

de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no

puede permanecer en esos estados, pero nos sirven para saber cuál es la transición inicial y

final(es).

Figura 4.21

Ejemplo de un diagrama de estado

157

4.3.4. Diagramas de interacción

Los diagramas de interacción se utilizan para modelar los aspectos dinámicos de un sistema, lo

que conlleva a modelar instancias concretas o prototipos de clases, interfaces, componentes y

nodos, junto con los mensajes enviados entre ellos, y todo en el contexto de un escenario que

ilustra un comportamiento. En el contexto de las clases describen la forma en que grupos de

objetos colaboran para proveer un comportamiento. Mientras que un diagrama de casos de uso

presenta una visión externa del sistema, la funcionalidad de dichos casos de uso se recoge como

un flujo de eventos utilizando para ello interacciones entre sociedades de objetos.

Cada caso de uso es una composición de escenarios primarios (flujo normal del caso de uso) y

secundarios (flujos excepcionales y alternativos). Por tanto, para un caso de uso podemos definir

diferentes instancias (escenarios) que nos ayudan a la identificación de objetos, clases e

interacciones entre objetos necesarios para llevar a cabo la parte de funcionalidad que especifica

el caso de uso. Los escenarios documentan el reparto de las responsabilidades que se especifican

en el caso de uso.

El flujo de eventos de un caso de uso puede recogerse en una especificación texto acompañada de

distintos escenarios especificados mediante diagramas de interacción, donde cada diagrama será

una visión gráfica de un escenario. Existen cuatro (4) tipos de diagramas de interacción:

1. Diagrama de secuencia

Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia

temporal. La Figura 4.22 muestra los objetos que se encuentran en el escenario y la secuencia de

mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita por el

escenario. En aplicaciones grandes además de los objetos se muestran también los componentes y

los de casos de uso. En este sentido mostrar los componentes tiene sentido ya que se trata de

objetos reutilizables, en cuanto a los casos de uso hay que recordar que se implementan como

objetos cuyo rol es encapsular lo definido en el caso de uso.

158


Para mostrar la interacción con el usuario o con otro sistema se introducen en los diagramas de

secuencia las boundary classes. En las primeras fases de diseño el propósito de introducir estas

clases es capturar y documentar los requisitos de interfaz, pero no el mostrar como se va a

implementar dicha interfaz.

Los diagramas de secuencia, también llamados diagramas de traza de eventos o de interacción de

objetos, se utilizan con frecuencia para validar los casos de uso. Documentan el diseño desde el

punto de vista de los casos de uso, observando qué mensajes se envían a los objetos,

componentes o casos de uso y viendo cuánto tiempo consume el método invocado. Los

diagramas de secuencia nos ayudan a comprender los cuellos de botella potenciales, para así

poder eliminarlos. A la hora de documentar un diagrama de secuencia resulta importante

mantener los enlaces de los mensajes a los métodos apropiados del diagrama de clases. Los

conceptos más importantes relacionados con los diagramas de secuencia son:

Línea de vida de un objeto (lifeline): La línea de vida de un objeto representa la vida del

objeto durante la interacción. En un diagrama de secuencia un objeto se representa como

Figura 4.22

Ejemplo de un diagrama de secuencias

159

una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de

la línea principal que denotan la ejecución de métodos (activación). El rectángulo de

encabezado contiene el nombre del objeto y el de su clase, en un formato nombreObjeto:

nombreClase.

Activación: Muestra el período de tiempo en el cual el objeto se encuentra desarrollando

alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus

atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.

Mensaje: El envío de mensajes entre objetos se denota mediante una línea sólida dirigida,

desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.

Tiempos de transición: En un entorno de objetos concurrentes o de demoras en la

recepción de mensajes, es útil agregar nombres a los tiempos de salida y llegada de

mensajes.

Caminos alternativos de ejecución y concurrencia: En algunos casos sencillos los

caminos alternativos pueden expresarse en un diagrama de secuencias alternativas de

ejecución. Estas alternativas pueden representar condiciones en la ejecución o diferentes

hilos de ejecución (threads).

Destrucción de un objeto: Se representa como una X al final de la línea de ejecución del

objeto.

Métodos recursivos: Es un rectángulo adyacente a la activación principal y con líneas de

llamada de mensajes, que indican la entrada y salida de la recursión.

2. Diagrama de colaboración

Un diagrama de colaboración es una forma alternativa de mostrar el escenario que se da en un

diagrama de secuencia. Este tipo de diagrama muestra las interacciones entre objetos organizadas

entorno a los objetos y los enlaces entre ellos.

160

Los diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal

(qué pasa primero, qué pasa después). Los clientes entienden fácilmente este tipo de diagramas,

por lo que resultan útiles en las primeras fases de análisis. Por el contrario los diagramas de

colaboración como se muestra en la Figura 4.23 proporcionan la representación principal de un

escenario, ya que las colaboraciones se organizan entorno a los enlaces de unos objetos con otros.

Este tipo de diagramas se utilizan más frecuentemente en la fase de diseño, es decir, cuando se

diseña la implementación de las relaciones.


A diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en

el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de

colaboración. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por

esto que los diagramas de colaboración se deben crear en paralelo con los diagramas de clases.

Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboración

numerando los mensajes, aunque esto no se suele hacer, ya que para este propósito son mejores

los diagramas de secuencia.

A continuación se enumeran los conceptos fundamentales de un diagrama de colaboración:

Objeto: Se representa con un rectángulo que contiene el nombre y la clase del objeto en

un formato nombreObjeto: nombreClase.

Figura 4.23

Ejemplo de un diagrama de colaboración

161

Enlaces: Un enlace es una instancia de una asociación en un diagrama de clases. Se

representa como una línea continua que une a dos objetos, acompañada por un número

que indica el orden dentro de la interacción. Pueden darse varios niveles de subíndices

para indicar anidamiento de operaciones. Se pueden utilizar estereotipos para indicar si el

objeto que recibe el mensaje es un atributo, un parámetro de un mensaje anterior, si es un

objeto local o global.

Flujo de mensajes: Expresa el envío de un mensaje. Se representa mediante una flecha

dirigida cerca de un enlace.

Marcadores de creación y destrucción de objetos: Puede mostrarse en la gráfica qué

objetos son creados y destruidos, agregando una restricción con la palabra new o delete

respectivamente.

Objeto compuesto: Es una representación alternativa de un objeto y sus atributos. En

esta representación se muestran los objetos contenidos dentro del rectángulo que

representa al objeto que los contiene.

Patrón de diseño: Un diagrama de colaboración puede especificar un contrato entre

objetos, parte esencial para la descripción de un patrón de diseño. Este diagrama contiene

todos los elementos citados de un diagrama de colaboración, dejando libres posiblemente

los tipos exactos de algunos objetos o con nombres genéricos para los mensajes. Una

“instanciación” del patrón se representa como una elipse unida mediante flechas

punteadas a los objetos o clases que participan realmente en el patrón. Estas flechas

pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón.

Contexto: Un contexto es una vista de uno o más elementos dentro del modelo que

colaboran en el desarrollo de una acción. Se usa para separar los demás elementos en el

modelo de este problema en particular y darle énfasis. Puede mostrar sólo los detalles

relevantes de las clases u objetos que contiene, para resaltar su utilidad.

Objeto activo: Un objeto activo es el que contiene su propio flujo de control, a diferencia

de un objeto pasivo que encapsula datos y sólo reacciona al enviarle mensajes. Un objeto

activo se representa con un rectángulo de bordes gruesos. Puede contener otros objetos

pasivos o activos.

162

3. Diagramas de visualización de interacción

Los diagramas de visualización de interacción han sido incorporados en la versión 2.0 de UML.

Son la combinación gráfica de los diagramas de actividad con los de secuencia. Pueden

concebirse como diagramas de actividad en los cuales las actividades son reemplazadas por

pequeños diagramas de secuencia, o bien como diagramas de secuencia unidos mediante la

notación de los diagramas de actividad empleada para representar el control de flujo en el sistema

(Fowler03b), en la Figura 4.24 se muestra un ejemplo de este tipo de diagrama.


Dada su reciente aparición, aún no está clara la efectividad del alcance de estos diagramas en

aplicaciones reales.

Figura 4.24

Ejemplo de un diagrama de visualización de interacción

163

4. Diagramas de tiempo

Los diagramas de tiempo (Ver Figura 4.25) han sido incorporados a UML como una nuevo tipo

de diagrama de interacción, donde el elemento principal son las restricciones de tiempo. Son muy

útiles para representar restricciones temporales que afectan a cambios de estado de diferentes

objetos. Este tipo de diagrama se ha heredado de ámbitos relacionados con sistemas electrónicos

(microprocesadores, microcontroladores, etc.).


Figura 4.25

Ejemplo de un diagrama de tiempo

Análisis de los

Resultados

CAPITULO

Análisis de los Resultados

Diferencias y Semejanzas

El siguiente capítulo tiene como propósito hacer un análisis comparativo entre las diferencias y

semejazas que existen en UML con respecto a la programación estructurada y los métodos OO.

Para realizar este análisis se parte de los “bloques de construcción” que componen a UML, estos

son: sus elementos, relaciones y diagramas; de manera que se logra comparar los bloques de

construcción que se dan en UML con los que han surgido tanto en la programación estructurada

como en los métodos OO.

5.1. Análisis comparativo entre los elementos de UML y los de programación

estructurada y los métodos OO.

5.1.1. Elementos básicos en la programación estructurada

Tipos de Datos Primitivos

Palabras Reservadas

Variables

Constantes

Expresiones

Jerarquía de Operadores

Operadores Aritméticos

Operadores Relacionales

Operadores Lógicos o Booleanos (and, or, not, xor)

Estructuras de Control

166

Elementos estructurales de un módulo:

InterfazDatos de entrada

Datos de salida

Descripción funcionalidad

Implementación

Datos locales

Secuencia de instrucciones

Sintaxis del lenguaje:

Organización del código en bloques de instrucciones, se definen las funciones y los

procedimientos.

Extensión del lenguaje con nuevas operaciones y llamadas a nuevas funciones y

procedimientos

5.1.2. Elementos en los métodos OO

En los métodos OO las propiedades estáticas de los objetos se representan mediante elementos

estructurales, es decir, las entidades abstractas, las relaciones entre ellas, y otros elementos

complementarios. Y las propiedades dinámicas, que expresan el comportamiento de los elementos

estructurales y del sistema global, se representan mediante elementos dinámicos, como estados,

actividades, interacciones y las construcciones que los agrupan. A continuación se describen los

elementos más importantes nombrados por Castells (2002):

Objetos: atributos y métodos

Métodos: operaciones sobre los objetos

Clases: categorías de objetos con propiedades y operaciones comunes

Jerarquías de clases

En algunos lenguajes las clases son objetos, en otros no

Relaciones, objetos compuestos

167

5.1.3. Elementos en UML

Los elementos en UML se dividen en estructurales, de comportamiento, de agrupamiento y de

anotación.

Elementos estructurales: son aquellos elementos que pertenecen a la parte estática de un modelo,

representan partes materiales o conceptuales del sistema. Los elementos estructurales principales

de UML son la clase, la interfaz, la colaboración, el caso de uso, los componentes y los nodos.

Casos de uso: Describe un conjunto de secuencias de

acciones que un sistema ejecuta, para producir un

resultado observable de interés. Se emplea para

estructurar los aspectos de comportamiento de un

modelo.

Actor: Es algo o alguien que puede interaccionar con el

sistema que se está desarrollando

Clases: Describe un conjunto de objetos que comparten

los mismos atributos, métodos, relaciones y semántica.

Las clases implementan una o más interfaces.

Interfaces: Agrupación de métodos u operaciones que

especifican un servicio de una clase o componente,

describiendo su comportamiento, completo o parcial,

externamente visible. UML permite emplear un círculo

para representar las interfaces, aunque lo más normal es

emplear la clase con el nombre en cursiva.

Colaboraciones: Define una interacción entre

elementos que cooperan para proporcionar un

comportamiento mayor que la suma de los

comportamientos de sus elementos.

Componentes: Parte física y por tanto reemplazable de

un modelo, que agrupa un conjunto de interfaces,

archivos de código fuente, clases, colaboraciones y

proporciona la implementación de dichos elementos.

Nodos: Elemento físico que existe en tiempo de

ejecución y representa un recurso computacional con

capacidad de procesar.

168

Elementos de comportamiento: son aquellos elementos que pertenecen a la parte dinámica de un

modelo. Los elementos de comportamiento básico son las interacciones (que comprende un

conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto

particular, para alcanzar un propósito específico) y la máquina de estados (que especifica las

secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a

eventos, junto con sus reacciones a estos eventos).

Interacción: Conjunto de mensajes

intercambiados entre un conjunto de objetos

con un propósito particular.

de objetos con un propósito particular.

Máquina de estado: Secuencia de estados por

las que pasa un objeto durante su vida en

respuesta a eventos.

Elementos de agrupamiento: son aquellos elementos que pertenecen a la parte de organización

de los modelos de UML. Los elementos de agrupación de UML son los paquetes, y sirven para

organizar otros elementos de los modelos UML (pudiendo incluir incluso otros paquetes). Un

paquete es un mecanismo conceptual de propósito general para organizar elementos en grupos.

Por ejemplo, se pueden incluir en un paquete varias clases y luego asignar ese paquete a un

componente (con lo que, realmente, lo que estamos asignado al componente son todas las clases

que el paquete incluye). Gráficamente, un paquete se visualiza como una carpeta, incluyendo su

nombre y, a veces, su contenido.

Paquete, modelo y subsistema: Se

emplea para organizar otros elementos en

grupos.

Elementos de anotación: son aquellos elementos que pertenecen a la parte explicita de los

modelos UML. Son comentarios que se pueden aplicar para describir, clarificar o hacer

observaciones sobre cualquier elemento de un modelo. Aunque la mayoría de herramientas del

tipo Racional Rose permiten añadir un texto (o incluso un fichero o una dirección web)

comentando o documentando cada elemento, con las anotaciones este texto se ve de forma

explícita en el diagrama, de forma que resalta a primera vista.

169

Nota: Partes explicativa de UML, que puede describir

textualmente cualquier aspecto del modelo de objetos con

un propósito particular.

5.1.4. Análisis comparativo entre los elementos de UML y los de programación estructura y los

métodos OO.

Los elementos básicos que se presentan en el desarrollo estructural son de tipo condicional que

cambian según los requerimientos del sistema, se analizan los problemas mediante los diagramas

de flujo de datos, para luego programar una solución, es decir se desarrolla el sistema haciendo

uso de los datos, el diagrama de entidad relación se utiliza para el desarrollo básicamente de las

bases de datos. Se puede decir que en el desarrollo estructural lo que varía más que todo son las

diferentes notaciones que se presentan para diseñar los diagramas de flujo de datos donde tres

autores proponen notaciones distintas, pero igual significan lo mismo.

Los elementos que se presentan en los métodos orientados a objetos lo hacen con la finalidad de

representar objetos y sus clases utilizando diversos diagramas, unos más completos que otros.

Algunas estructuras se adaptan tanto a procesos estáticos como dinámicos como es el ejemplo de

la metodología OMT, hay otros métodos que sólo son estáticos, a decir verdad existe mucha

variedad y opiniones encontradas en cuanto a qué diagrama usar para desarrollar software.

Los elementos estructurales que se presentan en UML son heredados de los elementos

estructurales utilizados en los métodos orientados a objetos, estos se mantienen constantes en el

tiempo, desde que UML fue adoptado en noviembre de 1997 por la OMG como una de sus

especificaciones se ha convertido en un estándar que sirve para visualizar, especificar, construir y

documentar los modelos que se crean durante la aplicación de un proceso de software. Estas

estructuras varían muy poco con las versiones de UML, y las nuevas versiones que van surgiendo

lo hacen con el objetivo de mejorar lo anterior. Entre las fortalezas de UML se encuentra que los

elementos estructurales que manejan sirven para modelar tanto procesos estáticos como

dinámicos.

170

5.2. Análisis comparativo entre las relaciones de UML y las relaciones de la


5.2.1. Relaciones existentes en el desarrollo estructurado

Básicamente las relaciones que se dan en los diagramas que se presentan en el desarrollo

estructurado son los “flujos de datos” que llevan información de un lado a otro y están

representados por medio de una flecha.

En los Diagramas de Flujo de Datos (DFD) los flujos de información están representados

gráficamente por medio de una flecha que entran o salen de un proceso. Este flujo se usa para

describir el movimiento de bloques o paquetes de información de una parte del sistema a otra. Por

ello, los flujos representan datos en movimiento, la flecha indica la dirección de la información,

representarán datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos

tipos de información con los que las computadoras pueden tratar.

Los flujos de datos llevan nombres que representan el significado del paquete que se mueve a lo

largo del flujo, también llevan una dirección: una cabeza de flecha en cualquier extremo (o

posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o

hacia afuera de un proceso (o ambas cosas).

Tipos de Flujos de Datos que se dan en un DFD:

Flujo de consulta: Muestra la utilización de la información del almacén por el proceso

para utilizar los valores de uno o más atributos de una ocurrencia y comprobar si los

atributos seleccionados cumplen unas condiciones, su representación se muestra en la

Figura 5.1 (a).

Flujo de actualización: Indica que el proceso va a alterar la información mantenida en el

almacén para: crear una nueva ocurrencia en el almacén, borrar una o más ocurrencias y

modificar el valor de un atributo, su representación se muestra en la Figura 5.1 (b).

Flujo de diálogo: Representa un flujo de consulta y un flujo de actualización que no

tienen relación directa, su representación se muestra en la Figura 5.1 (c).

171

Flujo de consulta (a) Flujo de actualización (b) Flujo de dialogo (c)


En los Diagramas de Estructura de Datos (DED) las relaciones que se dan entre los módulos se

representan por medio de invocaciones.

Los diagramas de estructura de datos muestran las invocaciones que un módulo hace a otros

módulos. Estas invocaciones son diseñadas como una flecha que sale del módulo llamador y

apunta al módulo llamado en la Figura 5.2, se muestra un ejemplo:


En el ejemplo de la Figura 5.2 el módulo A invoca (o llama) a los módulos B, C y D. La

interpretación de las invocaciones provee información de la estructura interna del módulo

llamador. Los diagramas de estructura no tienen especificado el orden de invocación de los

módulos invocados. El orden de la figura de los módulos B, C, y D (de izquierda a derecha) no

debe ser interpretado como el orden de invocaciones ejecutado por el módulo A. Una invocación,

representa la idea de invocación a funciones o procedimientos en los lenguajes de programación

Figura 5.1

Diferentes flujos de datos

A

B C D

Modulo Llamador

Invocación

Modulo Llamado

A

B C D

Modulo Llamador

Invocación

Modulo Llamado

Figura 5.2

Ejemplo de invocaciones

172

convencionales. En un diagrama de estructura de datos se pueden modelar varios tipos de

invocaciones, en el Cuadro 5.1 se explican y se representan gráficamente:

Cuadro 5.1

Tipos de invocaciones

Invocación

Estándar

El módulo A invoca al módulo B con la semántica de invocación

de procedimientos o funciones en los lenguajes de programación

convencionales (C, Pascal, etc.).

Invocación

Concurrente

El módulo A comienza dos tareas concurrentes, B y C.

Invocación

Co-rutina

El módulo A invoca al módulo B con una semántica de

transferencia de control al punto de entrada de una co-rutina.

Transferencia

de Control

El módulo A hace una transferencia de control al interior del

módulo B.

Transferencia

de Datos

El módulo A hace referencia a un área de datos local del módulo B.


Comunicación entre módulos (cuplas)

Cuando una función o un procedimiento, en un lenguaje convencional, es invocado, comúnmente

un conjunto de argumentos es comunicado y, en el caso de las funciones, también se espera que

retorne un resultado. Estos datos comunicados en una invocación son modelados por medio de

flechas, sobre el símbolo de invocación, llamadas cuplas, en la Figura 5.3 se muestra un ejemplo.

A

B

A

B C

B

A

B

A

A BA B

A

B C D

Cúpula de Datos

Cúpula sin tipo

(o de datos o de

control o hibrida)

Z

X

YZ W

F

H

Cúpula Modificada

Cúpula de control

flag

Cúpula Hibrida

(datos y control)

A

B C D

Cúpula de Datos

Cúpula sin tipo

(o de datos o de

control o hibrida)

Z

X

YZ W

F

H

Cúpula Modificada

Cúpula de control

flag

Cúpula Hibrida

(datos y control)

Figura 5.3

Ejemplos de invocaciones con cuplas


173

Como se muestra en el Cuadro 5.2, existen varios tipos de cuplas, basado en lo que ellas pueden

producir en el módulo receptor, las cuales se describen a continuación:

Cuadro5.2

Tipos de cuplas

Cupla de

Datos

Una cupla de datos transporta datos “puros” a un módulo. No es necesario

conocer la lógica interna del módulo receptor, para determinar los valores

válidos de la cupla (ej.: número de cuenta, saldo, tabla de movimientos).

Cupla

Modificada






archivo).

Cupla de

Control






archivo).

Cupla

Híbrida

Una cupla que para algunos módulos transporta datos “puros” y para otros

transporta un flag de control es denominada cupla híbrida. Esta cupla

representa un híbrido entre una cupla de datos y una cupla de control. La

identificación de ellas depende de la lógica definida por el algoritmo de

implementación del módulo invocado.

Cupla sin

Tipo

Se utiliza para representar que hasta el momento no esta definida o se tienen

dudas con respecto a la interpretación que el módulo invocado hace de ella.


En los Diagramas de Transición de Estado (DTE) no existe una relación como tal, ya que en

estos diagramas se muestran los cambios de estados, que se representan por medio de flechas.

En el Modelo relacional las relaciones se representan mediante tablas, formadas por sus

columnas y filas que contienen cardinalidad, atributos, claves, entidades, dominio, tuplas y grado.

En los Diagramas de Entidad Relación (DER) las relaciones se representan mediante

asociaciones entre entidades. Puede haber más de una relación entre dos entidades. Es el

elemento del modelo que permite relacionar en sí los datos del modelo. Por ejemplo, en la Figura

5.4 se muestra una entidad personas y otra entidad trabajos. Ambas se realizan ya que las

personas trabajan y los trabajos son realizados por personas:

174


La representación gráfica de las relaciones se realiza con un rombo (Ver Figura 5.5) al que se le

unen líneas que se dirigen a las entidades, las relaciones tienen nombre (se suele usar un verbo).

En el ejemplo anterior podría usarse como nombre de relación, trabajar:

Fuente: Chen (1976)

Grado de relación: es el número de entidades que pueden participar en una relación, pueden ser:

unitarias (misma entidad), binarias (2 entidades) y n-arias (N entidades).

Cardinalidad de las relaciones: La cardinalidad expresa cuántas del conjunto de entidades de un

extremo de la relación están relacionadas con cuántas entidades del conjunto del otro extremo.

Estas pueden ser de “una a una” (1:1), de “una a muchas” (1:N), de “muchas a una” (N:1). y de

“muchas a muchas” (N:N). Se anota en términos de:

Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá

cada ejemplar de la entidad (el valor que se anota es de cero o uno)

Figura 5.4


Figura 5.5

Ejemplo de relación (b)

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Fontanero

Electricista

Peluquero

Administrativo

Personas Trabajos

Pedro

Ana

José

Maria

Consuelo

Jaime

Lourdes

Fontanero

Electricista

Peluquero

Administrativo

Personas Trabajos

Personas Trabajar TrabajosPersonas Trabajar Trabajos

175

Cardinalidad máxima. Indica el número máximo de relaciones en las que puede

aparecer cada ejemplar de la entidad (puede ser uno o muchos)

Roles de las relaciones: A veces en las líneas de la relación se indican roles. Estos roles

representan el papel que juega una entidad en una determinada relación. Un ejemplo de esto se

muestra en la Figura 5.6.


Síntesis

Diagramas Tipos de relaciones

Diagrama de Flujo de Datos Flujo de Datos. Se representan mediante

flechas

Diagrama de Estructura de Datos Llamadas a Invocaciones. Se

representan mediante flechas

Diagrama de Transición de Estado Flechas que Representan los Cambios de

Estado

Modelo Relacional Se representa utilizando relaciones, que

contienen cardinalidad, atributos, claves,

entidades, dominio, tuplas y grado

Diagrama de Entidad Relación Asociaciones. Se representan mediante

rombos

5.2.2. Relaciones existentes en los métodos OO

Las relaciones que se analizan en este apartado son las que más influyeron en UML como son la

notación de OMT y la de Booch.

Figura 5.6

Ejemplo de roles de las relaciones

Trabajador Trabaja

Empleado

Jefe

Trabajador Trabaja

Empleado

Jefe

176

Relaciones entre clases y objetos según la notación de Rumbaugh (OMT)

Las relaciones que se dan entre clases y los objetos son de asociación, agregación, generalización

y herencia.

Enlaces y asociaciones

Los enlaces y asociaciones en la metodología OMT son los medios para establecer relaciones

entre objetos y clases. Un enlace (Rumbaugh, 1999) es una conexión física o conceptual entre

instancias de objetos. Una asociación describe un grupo de enlaces con estructura y semántica

comunes. Las asociaciones son inherentemente bidireccionales. Las asociaciones pueden ser

binarias, ternarias (Ver Figura 5.7) o de órdenes superiores y los nombres de las asociaciones son

opcionales en la notación (se escriben en cursiva). El nombre de una asociación binaria suele

leerse en un solo sentido. Cada asociación en el diagrama de clase corresponde a un conjunto de

enlaces en el diagrama de instancias. Los nombres de las asociaciones (o de los enlaces) se

escriben en cursivas y comienza con mayúsculas como se muestra en la Figura 5.7.

Fuente: Vallejos (2001)

Multiplicidad

La multiplicidad especifica la cantidad de instancias que pueden estar relacionadas con una única

instancia de una clase asociada. Limita el número de objetos relacionados. Según la notación

Figura 5.7

Ejemplo de enlaces y asociaciones

177

OMT, se puede especificar multiplicidad mediante un número entero positivo o mediante un

conjunto de intervalos. Por ejemplo: “1”, “1+”, “3-5”, “2, 8, 15”. Existen terminadores especiales

que indican ciertos valores frecuentes de multiplicidad.

Un círculo negro indica multiplicidad de “muchos”, es decir cero o más. Un círculo blanco

denota “opcional”, es decir cero o uno. Cuando una asociación no tiene terminadores ni valores

de multiplicidad se asume uno a uno, en la Figura 5.8 se muestran todos los tipos de multiplicidad

que se dan en la notación OMT.


En la Figura 5.9 se presenta un ejemplo de multiplicidad en un diagrama de clases:


Figura 5.9

Ejemplo de multiplicidad en un diagrama de clases

Figura 5.8

Representación de la multiplicidad en OMT

178

Los atributos de un enlace

Son propiedades de los enlaces de una asociación. Todo atributo de enlace tiene un valor para

cada enlace. La notación OMT para un atributo de enlace es un cuadro de diálogo ligado a la

asociación mediante un lazo, en la Figura 5.10 se muestra un ejemplo de esto, tanto en un

diagrama de clases como de objetos o instancias.


Asociación como una clase

En algunas ocasiones resulta adecuado modelar las asociaciones como clase. Es útil modelar las

asociaciones como clases cuando los enlaces pueden participar en asociaciones con otros objetos

o cuando están sometidos a operaciones. Un ejemplo de esto se puede observar en la Figura 5.11.


Figura 5.10

Ejemplo de atributo en un enlace

Figura 5.11

Ejemplo de una asociación como una clase

179

Rol de una asociación

Los roles se colocan en uno de los extremos de una asociación. Una asociación binaria posee dos

roles (Ver Figura 5.2), cada uno de los cuales se puede identificar con un nombre de rol. El

nombre de rol es un atributo derivado cuyo valor es un conjunto de objetos relacionados. Los

roles suelen aparecer como sustantivos en las descripciones de un problema.


Los nombre de roles son necesarios para asociaciones entre dos objetos de la misma clase.

También son útiles para distinguir dos asociaciones entre un mismo par de clases.

Cualificación

Una asociación cualificada o calificada relaciona dos clases de objetos y un calificador. El

calificador es un atributo especial que reduce la multiplicidad efectiva de una asociación. Una

asociación cualificada también puede considerarse como una forma de relación ternaria. La

cualificación mejora la precisión semántica e incrementa la visibilidad de las vías de navegación.

En la Figura 5.13 se puede observar un ejemplo de esta asociación.


Figura 5.13

Ejemplo de una asociación calificada

Figura 5.12

Ejemplo de un rol en una asociación

180

Agregación

Rumbaugh (1999) afirma que una agregación representa la relación “parte-todo” o “una parte de”

en la cual los objetos componentes de algo se asocian a un objeto que representa el ensamblaje

completo. La agregación es una forma fuertemente acoplada de asociación, con semántica

adicional. Propiedades de la agregación: transitividad, antisimetría. La existencia de una parte

puede o no depender de la existencia del todo. Se representa por medio de una asociación que en

su extremo posee un rombo en blanco (superclase), en la Figura 5.14 se muestra un ejemplo de su

representación.


Generalización y herencia

La generalización y la herencia son mecanismos de abstracciones que sirven para compartir

similitudes entre las clases mientras estas preservan sus diferencias.

La generalización en OMT es una relación entre una clase (superclase) y una o más clases

(subclases) las cuales son refinamientos o especializaciones de la misma. Los atributos y las

operaciones comunes de un grupo de clases son vinculados a una superclase. Cada subclases se

dice que hereda las características de una superclase. La generalización es llamada “relación es-

uno/a”, debido a que cada instancia de una subclase es una instancia de la superclase también. En

la Figura 5.15 se puede observar un ejemplo de las superclase y las subclases.

Figura 5.14

Ejemplo de una relación de agregación

181


La generalización y la herencia son relaciones transitivas. Una instancia de una clase es

simultáneamente una instancia de sus “ancestros”. El estado de una instancia incluye un valor

para cada uno de los atributos de sus ancestros, y cualquier operación de un ancestro puede ser

solicitada a la instancia. Cada subclase no sólo hereda las características de sus ancestros, sino

que puede agregar sus propios atributos y operaciones.

En la generalización, algunas veces se hace uso de un discriminador que funciona como un

atributo de tipo enumerado que indica que propiedad de un objeto está siendo abstraída por una

relación de generalización. El discriminador es simplemente un nombre para la base de la

generalización.

Usos de la generalización y la herencia

La generalización es un mecanismo utilizado tanto en el modelamiento como en la

implementación. La generalización facilita el modelado mediante el estructurado de clases, a

través de la abstracción de las características comunes y diferentes de las clases. La herencia es

un mecanismo de definición en la implementación, posibilitando el reuso de código.

Para concluir se puede decir que la generalización y especificación se refiere a la relación entre

clases. La generalización indica que una superclase generaliza las subclases y la especificación:

se refiere al refinamiento de una superclase en una subclase, la herencia, se refiere a un

mecanismo para compartir atributos y operaciones.

Figura 5.15

Ejemplo de superclases y subclases

182

Diferencias entre agregación y generalización

Una agregación es una relación entre instancias en donde están implicados dos objetos diferentes

de modo que uno es parte del otro. La generalización en una relación entre clases, y es una forma

de estructurar la descripción de un objeto único. Mediante la generalización un objeto es, a la vez,

una instancia de la superclase y una instancia de la subclase.

Tipos de agregación:

Una agregación puede ser:

Simple o Fija: el número y tipo de componentes esta predeterminado.

Variable: número finito de niveles, pero el número de partes puede variar.

Recursiva: una agregación puede tener, directa o indirectamente, una instancia de la

misma clase agregada como parte.

Los diferentes tipos de agregación se muestran en la Figura 5.16.


Relaciones entre clases y objetos según la notación de Booch

Las relaciones más usadas en la notación Booch son: agregación, asociación, uso y la herencia.

Figura 5.16

Ejemplo de los tipos de agregación

183

Agregación

Denota una relación todo/parte (relación “tiene un” o agregación), aparece como una asociación

con un círculo relleno en el extremo que señala al agregado, la clase que está en el otro extremo

denota la parte cuyas instancias están contenidas por el objeto agregado, su representación gráfica

se puede ver en la Figura 5.17 (a).

Cuando la clase contenida no existe independientemente (Macías del Campo, 2006) de la clase

que la contiene se denomina agregación por valor (Ver Figura 5.17 b) y además implica

contenido físico, mientras que si existe independientemente y se accede a ella indirectamente, es

agregación por referencia (Ver Figura 5.17 c).

Agregación (a) Agregación por valor (b) Agregación por referencia (c)

Fuente: Cruzado (2006)

Asociación

Conecta dos clases y denota una conexión semántica, se etiquetan con expresiones sustantivas,

denotando la naturaleza de la relación. Las asociaciones se pueden etiquetar con un nombre o

frase, su representación se puede ver en la Figura 5.18 (a). Una clase puede asociarse consigo

misma, lo cual se denomina asociación reflexiva. La cardinalidad o multiplicidad especifica el

número de asociaciones entre dos clases. Si no se indica se considera sin especificar

– 1 (exactamente uno)

– N (cero o más)

– 1..N (uno o más)

– 3..7 (rango especificado)

– 7 (número exacto)

Figura 5.17

Representación grafica de las agregaciones

184

Uso o utilización

Los objetos de una clase usan servicios de objetos de otra clase. Denota una relación

cliente/servidor y aparece como una asociación con una circunferencia en el extremo que denota

al cliente. En esta relación de alguna forma el cliente depende del servidor para que éste le

proporcione determinados servicios. Su representación se puede ver en la Figura 5.18 (b).

Herencia

Para Booch (1996) la herencia es una relación entre clases, en la que una clase comparte la

estructura o comportamiento definido en otra (herencia simple) u otras (herencia múltiples)

clases. La herencia representa una jerarquía de abstracciones donde una subclase hereda de una o

más superclases. La subclase hereda la estructura y comportamiento de su superclase. Las

relaciones de herencia no pueden llevar indicaciones de cardinalidad. La notación consiste en una

flecha que apunta de la subclase a la superclase, como se observa en la Figura 5.18 (c).

Asociación (a) Uso o utilización (b) Herencia (c)


En la Figura 5.19 se pueden observar un diagrama de clases donde se dan las relaciones de:

asociación, herencia, agregación y uso

Otras dos (2) relaciones que no

Figura 5.19

Ejemplo de las Relaciones en un diagrama de clases

Figura 5.18

Representación grafica de las relaciones en el método Booch


185

son muy populares son: instanciación y metaclase

Metaclase: es una clase cuyas instancias son a su vez clases. Su representación se puede observar

en la Figura 5.20 (a).

Instanciación (templates): se refiere al hecho de ir creando las instancias de las clases. Se usa en

lenguajes que soportan genericidad (declaración de clases parametrizadas y argumentos tipo

template). Representa las relaciones entre las clases parametrizadas, que admiten parámetros

formales, y las clases obtenidas cuando se concretan estos parámetros formales. Su

representación se puede observar en la Figura 5.20 (b).

Metaclase (a) Instanciación (templates) (b)


A continuación se presenta una pequeña síntesis de los distintos diagramas con sus respectivas

relaciones.

Síntesis

Diagramas Tipos de Relaciones

Diagrama de Clases y

Objeto Notación de Rumbaugh (OMT)

Asociaciones

Agregaciones

Generalización y Herencia

Diagrama de Clase Notación de Booch

Herencia

Agregaciones

Asociación

Uso

Diagrama de Objeto Notación de Booch

Las relaciones entre los objetos se dan a través de sus

enlaces con otros objetos, representados por mensajes/valor,

rol, llave y restricciones. Un enlace es una instancia de una

asociación, al igual que un objeto es una instancia de una

clase.

Figura 5.20

Representaciones graficas de Metaclases e Instanciaciones

186

5.2.3. Relaciones Existente en UML

Relaciones entre Clases y Objetos según la notación de UML

Una relación es una conexión semántica entre elementos, en UML las relaciones que más se

utilizan son las que se aplican a las clases. Básicamente se distinguen cuatro tipos de relaciones

estáticas: asociaciones, generalizaciones, dependencia y realización.

Asociación

Es la relación estructural entre abstracciones que implican interconexiones o enlaces entre los

objetos representados por las abstracciones (instancias de clases). Las asociaciones están

compuestas por un nombre, roles, multiplicida y navegabilidad. La representación básica es una

línea enlazando las clases.

Nombre de la asociación: es un nombre descriptivo que indica la naturaleza de la asociación.

Opcionalmente se puede añadir un pequeño triángulo que indique el sentido en que se debe

interpretar.

En la Figura 5.21, se expresa que las personas trabajan para las compañías. Téngase en cuenta

que el sentido del nombre de la asociación no restringe la navegabilidad. Es posible indicar el

estereotipo de la asociación encima del nombre, siendo también posible indicar una cadena de

propiedades a la derecha del nombre o debajo.

Fuente: Pickin (2005)

Roles

Se puede indicar el rol que desempeña una o ambas clases en la asociación. Los roles describen el

papel específico que una clase juega en una asociación. Una clase puede jugar distintos roles en

diferentes asociaciones. Cada asociación tiene dos roles. Cada rol es una dirección en la relación,

Figura 5.21

Ejemplo de una relación de asociación

187

por ejemplo, si C1 está asociado con C2, la relación de C1 con C2 tiene un rol de C1 a C2 y otro

de C2 a C1 (Insfrán, 2001).

Los roles poseen un nombre (si no se indica un nombre de rol, el nombre del rol es el nombre de

la clase destino). Además un rol tiene una mutiplicidad que indica cuántos objetos pueden

participar en una relación dada (límite inferior y límite superior). Cuando el límite superior es

mayor a 1, se conoce como rol multivaluado. La convención usual es que este rol multivaluado

sea un conjunto. En el ejemplo de la Figura 5.22 se muestra un ejemplo de los roles en las

asociaciones.


Multiplicidad

La multiplicidad tiene por finalidad indicar cuántas instancias (objetos) de una clase podrán estar

asociadas a una instancia (objeto) de la otra. Estas pueden ser: uno (1), cero o uno (0..1), desde m

hasta n entero naturales (m..n), tres (3), muchos (*), cero a muchos (0..*), uno a muchos-al menos

uno (1..*), dos, cuatro o cinco (2,4,5). En el ejemplo de la Figura 5.23 se puede observa que de 0

a muchas compañías tiene una a muchas personas.


En este caso, para una compañía podrán trabajar una o más personas, y una persona podrá

trabajar en cero (que representaría el caso de estar desempleada) o más compañías.

Figura 5.22

Ejemplo de los roles en una relación de asociación

Figura 5.23

Ejemplo de multiplicidad

188

En multiplicidad se dan varios términos (Fowler, 2003), como: opcional (optional) que implica

un límite más bajo de cero, obligatorio (mandatory) que implica un límite más bajo de 1 o

posiblemente más, solo-valorado (single-valued) que implica un límite superior de 1 y

multivaluado (multivalued) que implica un límite superior de más de 1, usualmente *.

Navegabilidad

Otra propiedad de las asociaciones permite especificar la navegabilidad de la relación, esta indica

la posibilidad de ir desde el objeto fuente al objeto destino. La navegabilidad indica que los

objetos de la clase podrán hacer uso de las propiedades de los objetos de la clase relacionada en

la dirección indicada por la navegabilidad exclusivamente.

Si la navegabilidad existe sólo en un sentido se llama asociación unidireccional, y si existe en los

dos sentidos asociación bidireccional. La asociación sin navegabilidad puede considerarse como

bidireccional o no especificada. La asociación bidireccional añade la restricción de que los dos

roles son invertibles uno con otro.

Por ejemplo la asociación de la Figura 5.24 significa que la clase Compañía puede acceder a los

atributos y operaciones públicas de la clase Persona y que, de forma similar, la clase Persona

puede acceder a los atributos y operaciones públicas de la clase Compañía.


También se puede restringir la navegabilidad de la asociación, añadiendo una flecha que indique

el sentido de dicha asociación, en la siguiente Figura 5.25 se da un ejemplo:

Figura 5.24

Ejemplo de navegabilidad

189


En este caso, Compañía puede acceder a los atributos y operaciones públicas de la clase Persona,

pero Persona no puede acceder a Compañía.

Calificador

Es el particionamiento de un conjunto de objetos relacionados con otro objeto mediante un

atributo de la asociación (calificador). Dado un objeto origen y un valor determinado para el

calificador, se obtendrá un objeto destino (si la multiplicidad del destino es a lo más uno) o un

conjunto de objetos destino (si la multiplicidad del destino es muchos). Por ejemplo en la Figura

5.26 se puede observar que dado un banco y un número de cuenta, obtendremos una persona (el

titular de la cuenta). Téngase en cuenta que el calificador pertenece a la asociación y no es un

atributo ni del banco ni de la persona.


Es significativo el extremo de la asociación en el que se pone el calificador. Por ejemplo, si el

No. de cuenta lo representáramos nada más que con los dígitos finales (eliminando los dígitos

iniciales, que son los que especifican el banco), tal y como está el ejemplo, para un banco y un

número de cuenta obtendríamos un solo titular. Pero si pusiéramos el No. de cuenta en el extremo

de Persona, dado un titular y un No. de cuenta obtendríamos uno o más bancos.

Figura 5.26

Ejemplo del uso del calificador en una relación de asociación

Figura 5.25

Ejemplo de navegabilidad con restricción

190

El uso de calificadores restringe el entorno de la asociación y es útil, por ejemplo, para realizar

búsquedas.

Tipos de Asociaciones

Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es

decir, no se exige dependencia existencial ni encapsulamiento). Se indica como una línea

sólida que une dos clases como se observa en la Figura 5.27.


Asociación n-arias: Es una asociación entre tres (asociación ternaria) o más clases. Se

representa como un diamante del cual salen líneas de asociación a las clases como se observa

en la Figura 5.28.


Asociación Derivada: es una asociación redundante que se puede obtener como combinación

de otras relaciones del modelo. Un elemento derivado puede ser determinado a partir de otros.

Los atributos y las asociaciones son los elementos comunes para ser derivados. En UML un

elemento derivado se representa anteponiendo una “/” al nombre del elemento. En el

Figura 5.27

Representación de una asociación binaria

Figura 5.28

Representación de una asociación n-arias

191

diagrama de clases de la Figura 5.29 se puede observar una asociación derivada entre la clase

Profesor – Alumno.

Fuente: Insfrán (2001)

Asociaciones Reflexivas o Recursiva: una clase puede relacionarse consigo misma, es decir,

pueden modelarse asociaciones reflexivas. Las agregaciones pueden también ser reflexivas.

En la Figura 5.30 se puede observar que la clase Persona se relaciona consigo misma.


Asociación Restringida: Una restricción es un texto que especifica una o varias reglas que

sigue la clase, se indica mediante un texto libre encerrado entre llaves {}. Existe el OCL

(Object Constraint Language) que define de manera formal las restricciones en UML. En la

Figura 5.31 se puede observar un ejemplo de la asociación restringida.


Figura 5.29

Ejemplo de una asociación derivada

Figura 5.30

Ejemplo de una asociación reflexiva

Figura 5.31

Ejemplo de asociación restringida

192

Clase Asociación: Designa a una asociación que tiene propiedades de clase, tales como

atributos, operaciones y/o otras asociaciones. Siempre es representada junto a la asociación a

la que corresponde, y unida a ella mediante una línea discontinua. Ya que clase y asociación

forman un todo, el nombre de ambas es igual, pudiéndose especificarse en cualquiera de ellas

o en ambas. Una clase asociativa se representa como una clase colgada del símbolo de la

asociación por medio de una línea discontinua. En este caso, no puede haber relaciones de

agregación ni composición. En el ejemplo de la Figura 5.32 se puede observa la clase

asociada Trabajo.


Nótese que Trabajo, al pertenecer a la asociación, está ligado tanto a Compañía como a Persona,

y es ese conjunto el que tiene significado. Véase que este diagrama permite modelar que una

persona p1 fuera jefe de otra persona p2 en una compañía c1, y que simultáneamente p2 fuera

jefe de p1 en una compañía c2.

Casos Particulares de asociaciones

Existen dos casos particulares de la asociación, que son: agregación y composición.

Agregación

La agregación es la relación “es parte de”, que expresa un acoplamiento fuerte entre clases. Una

de las clases actúa como compuesta y la otra como componente y por defecto representa una

Figura 5.32

Ejemplo de una clase asociada

193

relación transitiva, asimétrica y reflexiva. Este concepto de agregación es una noción puramente

lógica, completamente independiente de las opciones de representación adoptadas. La agregación

se representa como una asociación con un rombo vacío en el lado de la clase todo, en la Figura

5.33 se muestra un ejemplo.

Fuente: Pickin (2005).

En la figura anterior, se muestra que un coche (el todo) tiene cuatro ruedas (la parte). Se ha

modelado como una agregación porque la rueda puede existir antes que el coche como entidad

propia o incluso después (se desguaza el coche y de dejan las ruedas) e incluso se puede cambiar

alguna de las ruedas de un coche a otro.

Composición

Si la relación de agregación es más fuerte, de tal forma que los componentes no pueden existir

independientemente, se denomina composición. En la composición, el “objeto parte” puede

pertenecer sólo a un “todo” y no puede ser cambiado (cualquier borrado del “todo” se considera

un borrado en cascada de sus “partes”, aunque esta restricción también puede expresarse

mediante un rol con mutiplicidad 1:1). La composición se representa como una asociación con un

rombo lleno en el lado de la clase todo, en la Figura 5.34 se muestra un ejemplo.


Figura 5.34

Representación de una relación de composición

Figura 5.33

Representación de una relación de Agregación

194

En la figura anterior se muestra un formulario (el todo) puede contener cero o más botones (la

parte). Un botón sólo puede existir dentro de un formulario, por lo que la vida del botón estará

restringida a la vida del formulario que lo posee. Un botón pertenece a uno y sólo un formulario.

Generalización

Alarcón (2000) la define como una relación entre un elemento general (llamado superclase o

padre) y un caso más específico de ese elemento (llamado subclase o hijo). La generalización a

veces es llamada relación “es-un-tipo-de”, ósea, un elemento (por ejemplo, una clase

Rectángulo) es-un-tipo-de un elemento más general (por ejemplo, la clase figura). La

generalización implica que los objetos hijo se pueden utilizar en cualquier lugar donde aparece el

padre, pero no a la inversa. La clase hijo siempre hereda todos los atributos y métodos de sus

clases padre y a menudo (no siempre) el hijo extiende los atributos y operaciones del padre. Una

operación de un hijo puede tener la misma signatura que en el padre pero la operación puede ser

redefinida por el hijo; esto es lo que se conoce como polimorfismo. Gráficamente viene dada por

una línea acabada en punta de flecha vacía que va del elemento especializado (llamado subclase o

hijo) al general (llamado superclase o padre), en la Figura 5.35 se muestra un ejemplo.


Una clase puede tener ninguno, uno o varios padres. Una clase sin padres y uno o más hijos se

denomina clase raíz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un

único padre se dice que utiliza herencia simple y una clase con varios padres se dice que utiliza

herencia múltiple. UML utiliza las relaciones de generalización para el modelado de clases e

Figura 5.35

Representación de una relación de generalización

195

interfaces, pero también se utilizan para establecer generalizaciones entre otros elementos como

por ejemplo los paquetes.

Una clase puede especializarse según ciertos criterios. Cada criterio de la generalización se indica

asociando un discriminador a la relación de generalización. Dicho discriminador es el nombre de

una partición de los subtipos de la superclase. Este discriminador puede ser un atributo de la clase

generalizada o el nombre de la partición. La generalización puede aplicarse a clases o a

asociaciones (aunque en este último caso es preferible representar la asociación como una clase

de asociación).

Pueden aplicarse diferentes restricciones a las relaciones de generalización para distinguir

diversas formas de generalización, en principio por defecto la generalización simboliza una

descomposición disjunta.

Pueden representarse grupos de generalizaciones semánticamente relacionados como árboles con

un segmento compartido. Si se añade una etiqueta a este segmento compartido (como nombre de

la partición) se aplica a todo el grupo de generalización.

Dependencia

Una dependencia es una relación entre un elemento dependiente (el cliente) y un elemento

independiente (el suministrador del servicio requerido). El elemento dependiente (cliente)

requiere conocer al elemento independiente (suministrador) y que éste esté presente. Las

dependencias se usan para modelar relaciones en la cual un cambio en el elemento independiente

(el suministrador) puede requerir cambios en el elemento dependiente (el cliente).

Es un tipo de relación unidireccional, ya que el elemento dependiente debe conocer al

independiente, pero el independiente desconoce la existencia del elemento dependiente.

Gráficamente se muestra como una línea discontinua acabada en flecha que va del elemento

dependiente al independiente (esto es, el elemento dependiente señala al elemento del que

depende) como se muestra en la Figura 5.36.

196


En este caso, la clase Cliente (dependiente) dependerá de servicios proporcionados por la clase

Servidor (independiente), y un cambio en la clase Servidor puede ocasionar que la clase Cliente

necesite ser adaptada. Un cambio en la clase Cliente no tiene ningún efecto sobre la clase

Servidor, ya que esta última es independiente de la primera (no la necesita).

Para que la clase dependiente tenga acceso a la clase independiente, la clase independiente debe

tener visibilidad global, ser pasada como parámetro a una operación o ser instanciada como

variable local en una operación de la clase dependiente.

Cuando una clase usa los servicios de otra a través de un interface, también se modela como

dependencia (depende del interface, un cambio en el interface requeriría un cambio en la clase

dependiente) esto se puede observa en la Figura 5.37.

Fuente: Alarcón (2000)

Nótese que la ClaseDependiente depende de Interface, no de la ClaseImplementadoraInterface.

De hecho un cambio en la ClaseImplementadoraInterface no tendría ninguna consecuencia sobre

la ClaseDependiente, ya que el interface aísla de posibles cambios en la clase implementadota

(Alarcón, 2000).

Figura 5.37

Representación de una relación de dependencia modelada a través

de una interfaz

Figura 5.36

Representación de una relación de dependencia

197

Realización

Es la relación semántica entre clases en la que una especifica un contrato que la otra clase se

compromete a cumplir. Es el mecanismo de separación entre la especificación de un servicio o

contrato y su implementación. Generalmente se emplea la realización para especificar una

relación entre una interfaz y la clase o componente que implementa las operaciones especificadas

en dicha interfaz. Existen dos casos en que se utiliza: en interfaz y clase o componente que la

implementa y en los caso de uso y colaboración que lo realiza

Gráficamente, una interfaz se muestra como una clase con el estereotipo «interface» y sus

operaciones, o en forma resumida como un círculo y debajo el nombre del interface como se

muestra en la Figura 5.38. En este caso, el interface Mensurable especifica dos operaciones,

peso() y volumen().


Para indicar que una clase realiza una interfaz, se muestra una línea discontinua acabada en

flecha vacía que va de la clase que implementa el interfaz a la interfaz, en la Figura 5.39 se

muestra un ejemplo.

Figura 5.38

Representación de una relación de realización

198


Se puede observar que tanto Saco como Automovil “realizan” el interface Mensurable, es decir,

ambas implementan las operaciones indicadas en la interfaz.

En el caso de usar la notación resumida, se unirá la interfaz a la clase que lo implementa por una

línea continua como se observa en la Figura 5.40.


Cuando una clase realiza un interface, debe implementar todas las operaciones indicadas en dicha

interface y, posiblemente, otras exclusivas de la clase.

Figura 5.39

Representación grafica de la relación de realización

Figura 5.40

Representación de la relación de realización de

manera resumida

199

Varias clases pueden satisfacer una interfaz (como en el ejemplo anterior), y una clase puede

satisfacer varias interfaces como se observa en la siguiente Figura 5.41.


Las interfaces pueden evitar en ciertos casos el uso de herencia múltiple. Son muy útiles para

independizar la implementación de sistemas o utilidades de los servicios u operaciones que

proporcionan (esto es, se puede cambiar la implementación sin que sea necesario modificar las

llamadas, ya que no se ha modificado el interface), fomentando la reutilización. Los interfaces

son soportados por lenguajes como Java.

Relaciones existentes en los diagramas de casos de uso

Cuando se implementa un caso de uso, su funcionamiento se basa en la colaboración entre clases.

Una clase puede participar en múltiples colaboraciones y por tanto, en múltiples casos de uso,

dando paso a relaciones entre los casos de uso (Fowler, 2003). Las relaciones que se dan en los

diagramas de caso de uso son: asociación, generalización y dependencia.

Asociación: es la participación de un actor en un caso de uso, la instancia de un actor se

comunican con instancias de un caso de uso; la relación entre los actores y los casos de uso se

representarán como una asociación, indicando la comunicación bidireccional entre usuarios y

sistema.

Generalización: Relación taxonómica entre un caso de uso más general y otro más específico

(también entre actores).

Figura 5.41

Representación de la relación de realización donde una clase

satisface varias interfaces

200

Dependencia:

<<extend>>: Relación que define un curso alterno opcional (dependiendo de una

condición) de otro caso de uso.

<<include>>: Relación que define una instancia de un caso de uso como un curso

obligatorio en otro caso de uso.

En la Figura 5.42 se muestra la representación grafica de todas las relaciones que se dan en un

diagrama de caso de uso.

Figura 5.42

Relaciones en un diagrama de casos de uso


En UML, la relación entre los actores y los casos de uso se representarán como una asociación,

indicando la comunicación bidireccional entre usuarios y sistema.

Relación existente en los diagramas de paquetes

En los diagramas de paquetes existe la relaciones de dependencia, la misma a parte de usarse en

otros tipos de diagramas, también se utilizan para mostrar la dependencia entre paquetes. Tal y

como se dijo, las clases se suelen agrupar en paquetes. Para agrupar las clases en paquetes, se

pueden utilizar varios criterios. Un criterio puede ser el agrupar las clases por estereotipos (en

este caso habría un paquete para las clases frontera, otro para las de control y otro para las de

entidad). También es posible agrupar las clases por su funcionalidad (podría haber un paquete

con clases que se encargaran del control de acceso, otras de la gestión informes, otra de errores,

etc.). Como los paquetes pueden contener a su vez otros paquetes, una tercera posibilidad

Asociación

Generalización

Dependencia <<extend>>

<<include>>

201

consiste en agrupar las clases por funcionalidades y dentro de cada grupo de funcionalidad,

volver a agrupar por estereotipo.

Una relación de dependencia entre un paquete A y un paquete B indica que alguna clase del

paquete A tiene una relación unidireccional con alguna clase del paquete B y, por tanto, el

paquete A necesita tener acceso al paquete B. Las relaciones de dependencia entre paquetes deben

ser calificadas con el estereotipo «access» o «import». Con ambos estereotipos se tiene acceso a

los elementos públicos del paquete independiente, pero con «access» es necesario preceder

dichos elementos por el nombre del paquete que los contiene mientras que con «import» no (en

este caso, es necesario que ningún nombre de un elemento del paquete dependiente coincida con

un nombre de elemento del paquete independiente). Un ejemplo de esto se muestra en la Figura

5.43.


Esta dependencia tiene implicaciones en la reutilización. El paquete B es fácilmente reutilizable

(es independiente), mientras que el paquete A no lo es, ya es dependiente del B y para reutilizar el

paquete A habría que usar también el B. Se deben evitar en lo posible referencias circulares.

Los paquetes contenidos en otros paquetes pueden acceder a todos los elementos del paquete que

los contiene. Sin embargo, las dependencias no son transitivas, tal y como se muestra en la Figura

5.44.

El paquete A puede acceder al paquete B y al paquete C. El paquete B y el paquete C pueden

acceder al paquete D. El paquete A no puede acceder al paquete D. Si se deseara que A accediera

a D, habría que añadir una dependencia de A a D.

Figura 5.43

Ejemplo de una dependencia

202


Relación existente en los diagramas de despliegue

Las instancias de cada uno de los componentes que integran los diagramas de componentes se

encuentran especificadas en los diagramas de despliegue mediante los nodos. Estos nodos son los

elementos donde se encuentran o ejecutan las instancias de los componentes en tiempo de

ejecución. Para mostrar que una instancia de un componente reside o se ejecuta en un nodo, es

decir, que el nodo soporta una instancia de ese componente, se relaciona al nodo con la instancia

mediante una dependencia estereotipada como «support», tal y como se muestra en la Figura

5.45.


Figura 5.44

Ejemplo de una dependencia cuando un paquete contiene otro paquete

Figura 5.45

Representación de una relación de dependencia en un diagrama

de despliegue

203

Los nodos están relacionados entre sí por asociaciones, que indican caminos de comunicación.

Una asociación se representa gráficamente como una línea entre los nodos que se comunica como

se muestra en la Figura 5.46. Es común estereotipar las asociaciones para indicar su tecnología.


Síntesis

Diagramas Tipos de Relaciones

Diagrama de Caso de Uso Asociación

Dependencia

Generalización

Diagrama de Clases y Diagrama de

Objetos Asociación

Generalización

Dependencia

Realización

Diagrama de Paquetes Dependencia

Diagrama de Despliegue Dependencia

Asociación

Figura 5.46

Representación de una relación de asociación en un diagrama de despliegue

204

5.2.4. Análisis comparativo entre las relaciones que se dan en los diagramas de clases y de

objeto de los métodos OO y los de UML

En este apartado se analizan cuáles son las características comunes y diferentes que se encuentran

entre los Métodos OO y en UML referentes a la semántica de las relaciones entre clases y objetos.

Asociación

En la Notación de Booch la asociación conecta dos clases y denota una conexión semántica, se

etiquetan con expresiones sustantivas, denotando la naturaleza de la relación. Las asociaciones se

pueden etiquetar con un nombre o frase.

En la Notación de OMT los enlaces y asociaciones son los medios para establecer relaciones entre

objetos y clases. Un enlace es una conexión física o conceptual entre instancias de objetos. Una

asociación describe un grupo de enlaces con estructura y semántica comunes.

En UML una asociación es una conexión entre dos o más objetos/clase. Dependiendo de la

semántica asociada a dicha conexión, puede clasificarse nuevamente en: asociación (en el caso

general), agregación (caso específico de la relación parte-de de los modelos semánticos) y

composición (una agregación donde la relación existente entre los objetos involucrados es más

fuerte).

Como se puede observar en la Figura 5.47 la representación grafica de la relación de asociación en

UML, Booch y OMT son iguales.

UML Notación Booch Notación OMT

Figura 5.47

Representación de la relación de asociación en UML, Booch y OMT

205

Tipos de Asociaciones

En la notación de OMT se da la clase asociada, que no es más que modelar la relación de

asociación como una clase, esto es útil cuando los enlaces pueden participar en asociaciones con

otros objetos o cuando están sometidos a operaciones, esta clase asociada se corresponde con la

utilizada en UML, sólo se diferencia en su notación.

La asociación calificada en UML es una asociación con un calificador. El calificador está

definido por un conjunto de atributos que pertenecen a la asociación (estos atributos no

pertenecen a la signatura de ninguna de las dos clases que participan en la asociación) y se

encuentra en un extremo de la asociación binaria. Esta asociación calificada se utiliza para

seleccionar exactamente una partición del conjunto de objetos asociados en el otro extremo de la

asociación.

En la notación OMT una asociación calificada relaciona dos clases de objetos y un calificador. El

calificador es un atributo especial que reduce la multiplicidad efectiva de una asociación. Una

asociación calificada también puede considerarse como una forma de relación ternaria. La

calificación mejora la precisión semántica e incrementa la visibilidad de las vías de navegación.

Las asociaciones derivadas de UML representan información sobre relaciones ya existentes en el

modelo, se muestran sólo a efectos expresivos; en el modelo subyacente a los Métodos OO esta

información está disponible aunque no tiene representación gráfica. En UML un elemento

derivado puede ser determinado a partir de otros. Los atributos y las asociaciones son los

elementos comunes para ser derivados. En UML un elemento derivado se representa anteponiendo

una “/” al nombre del elemento.

En la notación de Booch no se observa ningún tipo de asociación relevante para ser comparada.

Multiplicidad

La multiplicidad en UML o en los Métodos OO especifica el número de asociaciones entre dos

clases. Si no se indica se considera sin especificar. La multiplicidad en la notación de OMT se

señala por medio de terminadores (en el extremo de la asociación) que especifica la cantidad de

instancias que pueden estar relacionadas con una única instancia de una clase asociada. En UML

206

se indica la multiplicidad con un número entero positivo o mediante un conjunto de intervalos

números enteros que se colocan en el extremo de la asociación.

Agregación

En el caso de UML la agregación forma parte de la asociación como un caso particular. La

agregación en este caso es la relación “es parte de”, que expresa un acoplamiento fuerte entre

clases. Una de las clases actúa como compuesta y la otra como componente y por defecto

representa una relación transitiva, asimétrica y reflexiva. Se representa como una asociación con

un rombo vacío en el lado de la clase todo/parte como se muestra en la Figura 5.48 (a).

En la notación de Booch denota una relación todo/parte (relación “tiene un” o agregación),

aparece como una asociación con un círculo relleno en el extremo que señala al agregado como se

muestra en la Figura 5.48 (b), la clase que esta en el otro extremo denota la parte cuyas instancias

están contenidas por el objeto agregado.

Una agregación en la notación OMT representa la relación todo/parte o “una parte de” en la cual

los objetos componentes de algo se asocian a un objeto que representa el ensamblaje completo. La

agregación es una forma fuertemente acoplada de asociación, con semántica adicional. Las

propiedades de la agregación son: transitividad y antisimetría. La existencia de una parte puede o

no depender de la existencia del todo. La agregación se representa como una asociación con un

rombo vacío en el lado de la clase todo/parte como se muestra en la Figura 5.48 (c).

UML (a) Notación Booch (b) Notación OMT (c)

Tipos de Agregación

En la notación OMT se observa tres (3) tipos de agregación:(1) la simple o Fija, cuyo número y

tipo de componentes esta predeterminado; (2) la variable, donde el número de niveles es finito,

pero el número de partes puede variar; y (3) la recursiva, donde una agregación puede tener,

directa o indirectamente, una instancia de la misma clase agregada como parte.

Figura 5.48

Representación de la relación de agregación en UML, Booch y OMT

207

En la notación de Booch se observan dos (2) tipos de agregación: por valor y por regencia.

Cuando una clase contenida no existe independientemente de la clase que la contiene se denomina

agregación por valor y además implica contenido físico, mientras que si existe

independientemente y se accede a ella indirectamente, es agregación por referencia.

En UML existe solo una clase de agregación que existe como un caso particular de la relación de

asociación cuyo concepto se explicó con anterioridad.

Composición

La composición de UML se corresponde directamente en los Métodos OO con la agregación por

valor de la notación de Booch

En la composición, el “objeto parte” puede pertenecer sólo a un “todo” y no puede ser cambiado

(cualquier borrado del “todo” se considera un borrado en cascada de sus “partes”, aunque esta

restricción también puede expresarse mediante un rol con mutiplicidad 1:1). La composición se

representa como una asociación con un rombo lleno en el lado de la clase todo, como se muestra

en la Figura 5.49 (a).

En la notación de Booch cuando una clase contenida no existe independientemente de la clase que

la contiene se denomina agregación por valor y su representación grafica se muestra en la Figura

5.49 (b).

Herencia y generalización

La herencia, para Booch (1996), es una relación entre clases, en la que una clase comparte la

estructura o comportamiento definido en otra (herencia simple) u otras clases (herencia múltiple).

La herencia representa una jerarquía de abstracciones donde una subclase hereda de una o más

superclases. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones

UML (a) Notación de Booch (b)

Figura 5.49

Representación de la relación de composición en UML y Booch

208

de herencia no pueden llevar indicaciones de cardinalidad. La notación consiste en una flecha que

apunta de la subclase a la superclase.

En la Notación OMT se habla de generalización y especificación, esta se refiere a la relación entre

clases. La generalización indica que una superclase generaliza las subclases y la especificación: se

refiere al refinamiento de una superclase en una subclase. La herencia: se refiere a un mecanismo

para compartir atributos y operaciones.

UML utiliza un único concepto (generalización) para tratar la herencia en forma amplia como la

relación entre una clase más general y otra más específica. En los Método OO se categoriza la

herencia de acuerdo a su naturaleza, y puede ser la herencia descendente/simple o especialización

(subclase) o la herencia ascendente/múltiple o generalización (superclase).

Dada una relación de generalización entre dos clases4 en UML, el discriminador proporciona un

criterio para particionar las subclases de la superclase. Este discriminador puede ser un atributo de

la clase generalizada o el nombre de la partición. En los Métodos OO algunas veces se hace uso

de un discriminador que funciona como un atributo de tipo enumerado que indica que propiedad

de un objeto está siendo abstraída por una relación de generalización. El discriminador es

simplemente un nombre para la base de la generalización.

La generalización se utiliza para modelar la herencia en los lenguajes orientados a objetos. Una de

las características de la herencia es que permite simplificar la construcción de clases relacionadas,

ya que gracias a ella es posible agrupar las características comunes de un conjunto de clases en

una clase padre (superclase) y hacer que todas ellas hereden de la superclase (Pastor, 1997).

Todos los lenguajes orientados a objetos permiten la herencia simple (una clase puede descender a

lo sumo de otra), aunque algunos lenguajes, como C++, permiten la herencia múltiple (una clase

puede descender de varias clases padre). Aunque la descendencia múltiple puede ser muy

conveniente en algunos casos, no se debe abusar de ella (ya que puede resultar compleja su

utilización).

4 En UML también es posible definir un árbol de generalización (para herencia simple) para un conjunto de subclases, en este caso

es común que el discriminador de especialización sea común para todas las particiones definidas.

209

Como conclusión se puede decir que algunos aspectos presentes en los diagramas de UML no se

encuentran explícitamente en los Métodos OO (Notación Booch y OMT), aunque éstos en general

representan información orientada más bien a aspectos de diseño físico o implementación que a

nociones de modelado.

5.3. Análisis comparativo entre los diagramas de UML y los diagramas de la


En este apartado se hace un análisis comparativo de los diagramas de UML con los diagramas que

se dan en el desarrollo estructurado y con los diagramas usados en los métodos orientados a

objetos (OO). Cabe destacar que los diagramas que se seleccionaron fueron aquellos que tenían

semejanzas con el estándar UML.

5.3.1. Análisis comparativo entre los diagramas de flujo y los diagramas de actividad de UML

Los diagramas de actividad muchas veces juegan un papel similar al de los diagramas de flujo, la

principal diferencia entre estos dos diagramas, es que los diagramas de actividad soportan tanto el

comportamiento paralelo (parallel processing) como secuencial. Esto es importante cuando se

usan diagramas de actividad para modelar procesos de negocios, algunos de los cuales pueden

actuar en paralelo, y para modelar varios hilos en los programas concurrentes. El hecho de que

los diagramas de flujo sólo soporten procesos secuenciales se vuelve muchas veces una

desventaja ya que en ciertas ocasiones se requieren tomar varias decisiones a la vez.

Otra diferencia que se puede apreciar es que en los diagramas de actividades, las actividades

están claramente unidas a objetos y en un diagrama de flujo muchas se presentan en forma de

condiciones que se deben cumplir. Los diagramas de actividad siempre están asociados a una

clase, a una operación o a un caso de uso.

Como se mencionó anteriormente los diagramas de actividad soportan actividades tanto

secuenciales como paralelas. La ejecución paralela se representa por medio de iconos de

210

fork/espera, y en el caso de las actividades paralelas, no importa en qué orden sean invocadas

(pueden ser ejecutadas simultáneamente o una detrás de otra).

En la Figura 5.50 se muestra un ejemplo de cómo en un diagrama de actividades se dan procesos

paralelos, se observa que existen nodos (nodo fork) que tiene un flujo entrante y varios flujos

concurrentes salientes, de esta manera se pueden dar dos actividades a la vez, es decir, de forma

paralela, lo cual no poseen los diagramas de flujo. Así, que llenar la orden, enviar la factura y las

acciones subsecuentes ocurren en paralelo. Esencialmente, esto significa que la secuencia entre

ellas es irrelevante. Se podría llenar la orden, enviar la factura, entregar y recibir el pago; o podría

enviar la factura, recibir el pago, llenar la orden y luego entregar.

También podría llevar a cabo estas acciones por individual. Se toma el primer ítem de línea de los

depósitos, escribo la factura, tomo el segundo ítem de línea, pongo la factura en un sobre, y así

sucesivamente. O podría ejecutar varias de estas simultáneamente: escribo la factura con una

mano mientras busco en mis depósitos con la otra. Cualquiera de estas secuencias es correcta de

acuerdo al diagrama.

El diagrama de actividades permite que cualquiera que esta ejecutando el proceso escoger el

orden en el cual hacer las cosas. En otras palabras, el diagrama simplemente declara las reglas

esenciales de secuencia que debo seguir. Esto es importante en el modelado de negocios porque

aquí los procesos usualmente ocurren en paralelo. También es útil para algoritmos concurrentes,

en los cuales los hilos independientes pueden hacer cosas en paralelo.

Cuando tengan paralelismo tendrán que sincronizar. No se cerrara orden hasta que es entregada y

pagada. Mostramos esto unido antes de la acción de “cerrar orden”. Con una unión, el flujo

saliente es tomado sólo cuando todos los flujos entrantes alcanzan la unión. De modo que sólo

puede cerrar la orden cuando has recibido el pago y entregado.

211


Es importante recalcar que aunque un diagrama de actividad es muy similar en definición a un

diagrama de flujo (típicamente asociado en el diseño de software), éstos no son lo mismo. Un

diagrama de actividad es utilizado en conjunción de un diagrama de casos de uso para auxiliar a

los miembros del equipo de desarrollo a entender cómo es utilizado el sistema y cómo reacciona

en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un

programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera

considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo

describe la solución.

5.3.2. Análisis comparativo entre los DFD y los diagramas de casos de uso de UML

Según Larman (2004) el propósito del diagrama de los casos de uso es representar un tipo de

diagrama donde se refleje el contexto, con lo cual puede ser entendido rápidamente cuáles son los

agentes externos a un sistema y cómo los utiliza.

Figura 5.50

Ejemplo de un diagrama de actividades

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura

Llenar

orden

Entregar

de noche

Entregar

regular

actividad final

joinnodo merge

acción

decisión

[sino]

nodo inicial

nodo fork

flujo

[prioridad]

Recibir

orden

Cerrar

orden

Recibir

pago

Enviar

factura

Llenar

orden

Entregar

de noche

Entregar

regular

actividad final

joinnodo merge

acción

decisión

[sino]

nodo inicial

nodo fork

flujo

[prioridad]

212

En el caso de los DFD, las entidades externas (categorías lógicas de cosas o personas que

representan una fuente o destinación de la información) son el origen y/o destinación de la

información (Gane, 1988). Por lo tanto el uso de los DFD en comparación con los diagramas de

casos de uso implican el modelado del contexto del sistema, de esta manera las entidades

externas y los agentes externos respectivamente funcionan recíprocamente igual.

Se podría entender que un proceso definitivo del diagrama de flujo de datos (representa una

función) de un sistema se puede considerar como diagrama de casos de uso y que las entidades

externas del diagrama de flujo de datos pueden directamente ser mapeadas5 como agentes en un

diagrama de casos de uso.

Tanto el diagrama de flujo de datos como los diagramas de casos de uso hacen posible la visión

de los aspectos funcionales del sistema.

Para Pressman (2001) los DFD hacen posible que se desarrollen simultáneamente los modelos del

dominio de la información y del dominio funcional. Cuando los DFD están muy bien a nivel de

detalles, el analista ejecuta implícitamente una descomposición funcional. Al mismo tiempo, el

refinamiento de los DFD dan lugar a un refinamiento de los datos a medida que se ponen en

movimiento con los procesos.

La descomposición de los DFD en niveles inferiores de detalles es similar a la creación de

algunos diagramas de casos de uso, los datos en un diagrama de casos de uso se utilizan para

crear y para refinar un sistema de requisitos y por otro lado, se podría decir que en ambos

diagramas se eliminan la complejidad y los problemas de inconsistencia.

Los DFD por sí solos no son lo suficientes completos como para modelar todo un sistema y se

deben utilizar en sistemas con ayudas de otras herramientas, como los diagramas de entidad-

relación, para modelar los datos; los diagramas de estados, para modelar el comportamiento del

sistema, o el diccionario de datos, que contiene los datos.

5 Localizar y representar gráficamente la distribución relativa de las partes de un todo. Trasladar a un mapa sistemas

o estructuras conceptuales.

213

Semejantemente, un diagrama de casos de uso no es suficientemente poderoso como para

modelar sistemas orientados a objetos en su totalidad, teniendo una relación estrecha con los

diagramas de secuencia y de colaboración, entre otros.

Los DFD y los diagramas de casos de uso utilizan textos narrativos como ayuda para especificar

sus procesos.

Una de las críticas relacionadas a los DFD, es como abordan el diseño top down exigido para su

construcción y mantenimiento. Para Pressman (2001) los DFD se deben presentar a los usuarios

en la modalidad de top down, sin embargo, no es necesario que el analista de sistemas deba

desarrollar los diagramas del flujo de datos según esta modalidad. La subdivisión de un DFD

puede estar hacia arriba (crear DFD de niveles más altos) y hacia abajo (crear DFD de niveles

inferiores).

Para Booch et al. (2002) un diagrama de caso de uso describe lo que un sistema hace (o un

subsistema, o una clase, o interfaz), sin especificar cómo lo hace, captura el comportamiento del

sistema en desarrollo, sin necesidad de especificar cómo este comportamiento se pone en

ejecución Esto es un factor importante para el análisis (comportamiento del sistema) de aspectos

referentes a la puesta en marcha (ejecución del comportamiento).

En los DFD, aunque algunos aspectos físicos de la puesta en práctica pueden ser visualizados, no

se estimulan.

3.3.3. Análisis comparativo entre los diagramas de E-R y los diagramas de clases de UML

En UML existe la carencia de medios para representar los diagramas de entidad relación y pese a

que el área de la ingeniería de software cada día hay más avances en cuando al desarrollo del

software, las bases de datos relacionales no han podido ser suplidas por otro tipo de repositorios

que no choquen con el paradigma OO.

214

En consecuencia, la realidad sigue siendo que detrás de un modelo de software orientado a

objetos se encuentran habitualmente un repositorio de datos relacionales. Esto, desde el punto de

vista del desarrollo, obliga a las clases responsables de la gestión de la persistencia de las

entidades del sistema a adaptar ambos paradigmas. Por otro lado, y de forma evidente, obliga a

diseñador del sistema a modelar esa base de datos por medio de las herramientas oportunas. La

más adecuada es sin duda el modelo entidad relación, modelo no contemplado por UML. El

lenguaje de modelado que nos ocupa propone el empleo de los diagramas de clases para el

modelado de la base de datos relacional. No obstante, esta forma de trabajo no ha resultado

exitosa debido, entre otras cosas, a que el diagrama de clases del sistema no tiene porqué

coincidir con el modelo entidad relación en cuanto a entidades y sobre todo a relaciones se

refiere. Esto, unido a la confianza que las herramientas de modelado de bases de datos

relacionales clásica aportan a los responsables del diseño, hacen que en la mayoría de los casos se

opte por incorporar a los diseños UML diagramas de entidad relación clásicos.

En la Figura 5.51 se puede observar la situación actual del desarrollo de software, se presentan

las tres (3) etapas básicas de todo proyecto y se muestra como a pesar del avance de la ingeniería

del software de alguna manera siempre están presentes los modelos relacionales que son

diseñados para implementar las bases de datos que muchas veces son partes de los proyectos a

desarrollar.

En los diagramas entidad relación y los diagramas de clases pueden darse casos particulares en

donde coincidan de alguna forma las clases con las entidades, pero esto no tiene porque ser

necesariamente así. Por otra parte, hay que recordar que las clases tienen características que no se

consideran en las entidades como: atributos privados/protegidos/públicos y los métodos

(operaciones/comportamientos), las entidades sólo muestran de estás características los atributos

y las mismas relaciones que se dan en un diagrama de clases ya abarcan conceptos que no se

consideran en los diagramas E-R (p.ej. composición).

215

Fuente: Pérez (2002), adaptación por Yedra (2007)

Las clases, sus atributos, y sus relaciones pueden ser implementadas directamente en una base de

datos orientada a objetos. Pero aún así, en el entorno de desarrollo actual, la base de datos

relacional es el método más usado para el almacenamiento de datos. El diagrama de clase de

UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero

no cubre toda la semántica involucrada en el modelado relacional, como por ejemplo la notación

de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar este tipo de

información, se implementa el diagrama de entidad relación como extensión de los diagramas de

clase de UML, de esta manera se puede llegar a realizar un buen modelado de datos, ya que hay

detalles de semánticas de las bases de datos que UML no contempla en sus especificaciones.

Los diagramas de clase se pueden usar para modelar la estructura lógica de la base de datos,

independientemente de si es orientada a objetos o relacional, con clases representando tablas, y

atributos de clase representando columnas. Si una base de datos relacional es el método de

ANÁLISIS DISEÑO IMPLEMENTACIÓN

Desarrollo

Estructurado

Método Orientado

a Objetos

UML

DFD

E-R

DE

Modelo

Relacional

Entornos de

Programación

Entornos de Programación Orientada a Objetos

Bases de Datos Relacionales

Diagramas de Casos de Uso

Diagramas de Actividad

Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de Interacción

Diagramas de Clases

Diagramas de Estados


Modelo

Relacional

Métodos de Booch,

Good, Hood,

OODLE, JSD y

OOJSD, OOSD

Métodos de Shlaer/Mellor,

Coad/Yourdon, OMT de

Rumbaugh, Wirfs-Brock

ANÁLISIS DISEÑO IMPLEMENTACIÓN

Desarrollo

Estructurado

Método Orientado

a Objetos

UML

DFD

E-R

DE

Modelo

Relacional

Entornos de

Programación

Entornos de Programación Orientada a Objetos

Bases de Datos Relacionales

Diagramas de Casos de Uso


Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de Interacción

Diagramas de Clases

Diagramas de Estados


Modelo

Relacional

Métodos de Booch,

Good, Hood,

OODLE, JSD y

OOJSD, OOSD

Métodos de Shlaer/Mellor,

Coad/Yourdon, OMT de

Rumbaugh, Wirfs-Brock

Figura 5.51

Situación actual del desarrollo de software

216

implementación escogido, entonces el diagrama de clase puede ser referenciado a un diagrama de

entidad relación lógico. Las clases persistentes y sus atributos hacen referencia directamente a las

entidades lógicas y a sus atributos; el desarrollador dispone de varias opciones sobre cómo inferir

asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas

directamente a super-sub relaciones entre entidades en un diagrama de entidad relación.

Como conclusión, se tiene que los diagramas de clase representan las abstracciones de los objetos

y son utilizados en el desarrollo de software que no necesariamente tienen que tener bases de

datos. Los diagramas de entidad relación representan modelos de datos y muestran la parte

conceptual (nivel conceptual) de las bases de datos al contrario de lo que hacen los diagramas de

clases que muestran el lado práctico (nivel práctico). Se podría decir que la utilización de estos

dos diagramas forma una herramienta de modelado poderosa a la hora de diseñar bases de datos

5.3.4. Análisis comparativos entre los diagramas de estados de los métodos OO y los de UML

En los Métodos OO lo que se conoce como diagramas de transición de estados (Booch), y

diagramas de estados (OMT), se le denominan diagramas de estados en UML. En los diagramas

de estados se muestran la secuencia de estados por los que pasa un objeto durante su vida y que

se corresponden con los estímulos recibidos, junto con sus respuestas y acciones. Cada diagrama

de estados se corresponde con una clase o con un método.

Diagramas de transición de estados (Notación Booch)

Un diagrama de transición de estados (Ver Figura 5.52) muestra el espacio de estados de una

clase determinada, los eventos que provocan una transición de un estado a otro y las acciones que

resultan de ese cambio de estado. El estado de un objeto representa los resultados acumulados de

su comportamiento, cada estado necesita un nombre, por otro lado, se pueden poner las acciones

asociadas a cada estado. Siempre hay un estado inicial por defecto pero puede haber o no estado

final o de parada. Un evento es algún suceso que puede causar un cambio de estado en el sistema

y puede disparar una acción. La máquina de estados deja de existir cuando se destruye el objeto

que la contiene

217

Se pueden asociar acciones a los estados indicando la acción que ocurre cuando se entra o sale

del estado, ejemplo de esto es: en el estado Calentando, la entrada Calentador: activar y la salida

Calentador: desactivar.

Se pueden representar transiciones de estado condicionales (o vigiladas) por medio de una

expresión booleana entre llaves, ejemplo de esto es: en la transición Demasiado-frio [tiempo de

encendido>=5 minutos].

Se pueden detallar los estados utilizando estados anidados, por ejemplo

– Los estados continentes se llaman superestados

– Los estados anidados se llaman subestados

– Las transiciones desde y hacia subestados dentro de un superestado se hacen utilizando

flechas romas, un ejemplo es Transición de Encendido a Preparado. En la figura 5.52 se

puede observar este tipo de transición.

Fuente: Cueva (1999)

Diagramas de estados (Notación OMT)

Un diagrama de estados según la notación OMT (Ver Figura 5.53) relaciona sucesos y estados.

Cuando se recibe un suceso, el estado siguiente depende del actual, así como del suceso; un

cambio de estado causado por un suceso es lo que se llama una transición. Un diagrama de

estados es un grafo cuyos nodos son estados, y cuyos arcos dirigidos son transiciones rotuladas

con nombres de sucesos.

Figura 5.52

Ejemplo de un diagrama de transición de estados (Notación Booch)

218

El diagrama de estados especifica la secuencia de estados que causa una cierta secuencia de

sucesos. Si un objeto se encuentra en un cierto estado y se produce un suceso cuyo nombre

corresponda al de una de sus transiciones, entonces el objeto pasa al estado que se encuentra en el

extremo de destino de la transición. Se dice que la transición se dispara. Si hay más de una

transición que sale de un estado, entonces el primer suceso que se produzca dará lugar a que se

dispare la transición correspondiente.

Si se produce un suceso que no tiene ninguna transición que salga del estado actual, entonces el

suceso se ignora. Una secuencia de sucesos se corresponde con un camino a través del grafo.

Un diagrama de estados describe el comportamiento de una sola clase de objetos, como se

observa en la Figura 5.53. Dado que todas las instancias de una clase tienen el mismo

comportamiento, todas ellas comparten el mismo diagrama de estados, por cuanto todas ellas

comparten las mismas características de clase. Pero dado que todo objeto posee sus propios

valores de atributos, cada objeto posee su propio estado, que es el resultado de la especial

secuencia de sucesos que haya recibido. Todo objeto es independiente de los demás objetos, y

procede a su paso.


Los diagramas de estados pueden representar ciclos vitales únicos o bien bucles continuos. Los

diagramas de un solo uso representan objetos de duración finita y tienen estados iniciales y

finales. Se entra en el estado inicial al crear el objeto; al entrar en el estado final estamos

implicando la destrucción del objeto. Los diagramas de un solo uso son una subrutina del

Figura 5.53

Ejemplo de un diagrama de estado de la clase ajedrez

(Notación OMT)

219

diagrama de estados, a la cual se puede hacer alusión desde distintos lugares en un diagrama de

alto nivel.

Diagramas de estado en UML

Un diagrama de estados en UML (Ver Figura 5.54) muestra la secuencia de estados por los que

pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de

un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación,

un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son

transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja

redondeada con el nombre del estado en su interior. Una transición se representa como una flecha

desde el estado origen al estado destino. La caja de un estado puede tener cero o dos

compartimentos. En el primer compartimiento aparece el nombre del estado. El segundo

compartimiento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones

internas.


5.3.5. Análisis comparativos entre los diagramas de objetos de los métodos OO y los diagramas

de colaboración de UML

En los Métodos OO lo que se conoce como diagramas de objetos (Booch) se le denominan

diagramas de colaboración en UML, lo cual permiten profundizar el nivel de detalle de los

Figura 5.54

Ejemplo de un Diagrama de Estado en UML

220

diagramas de secuencia, los diagramas de colaboración permiten expresar en tiempos de

ejecución las colaboraciones de los objetos.

Diagramas de objetos (Notación de Booch)

Los diagramas de objetos muestra la existencia de objetos y sus relaciones en la vista lógica de un

sistema. En la fase de análisis estos diagramas se usan para indicar la semántica de los escenarios

primarios y secundarios que proporcionan la traza del comportamiento del sistema y en la fase de

diseño se utilizan para ilustrar la semántica de los mecanismos del diseño lógico. Cada objeto del

diagrama se denota con su nombre y opcionalmente con sus atributos, estos interaccionan a través

de enlaces con otros objetos. El objeto cliente es el objeto que invoca una operación y el objeto

servidor es el objeto que suministra la operación. La relación entre objetos viene dada por medio

de una flecha que indica la dirección de la invocación, así como la operación, y un número de

orden (opcional).

Diagramas de colaboración de UML

Un diagrama de colaboración es una forma alternativa de mostrar el escenario que se da en un

diagrama de secuencia. Este tipo de diagrama muestra las interacciones entre objetos organizadas

entorno a los objetos y los enlaces entre ellos. Un diagrama de colaboraciones muestra las

relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. En los

diagramas de colaboración de UML se separa el comportamiento de la clase, a diferencia de otras

notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases.

Los diagramas de colaboración enfatizan la organización estructural de los objetos que envían y

reciben mensajes.

5.3.6. Análisis comparativos entre las clases de los métodos OO y las clases de UML

Las “clases” en los métodos orientados a objetos

Para Booch (1996) una clase es un conjunto de objetos que comparten una estructura común y un

comportamiento común. Los términos clase y tipo son generalmente (pero no siempre)

intercambiables; y una clase es un concepto levemente distinto a tipo, en el hecho que acentúa la

importancia de jerarquías de clases.

221

Booch representa las clases por una nube con contorno discontinuo, colocándose en su

interior el nombre de la clase y separados por una línea están los atributos, las operaciones,

las restricciones y los adornos

La nube significa que las fronteras de una abstracción no son nítidas

Las líneas discontinuas indican que los clientes sólo operan sobre objetos y no sobre la clase

Los atributos y las operaciones pueden ser visibles o no según el detalle deseado

Un atributo es un dato que se almacenará en los objetos que son instancias de la clase

Un método es la implementación de una operación para la clase

Un adorno de clase es una propiedad por ejemplo indicar que la clase es abstracta (no puede

tener instancias, sólo se puede heredar de ella)

En la Figura 5.55 se muestra una clase según la notación de Booch, contienen el nombre de la

clase y sus atributos.

Fuente: Booch (1996)

Para Coad y Yourdon (1991) una descripción de uno o más objetos forman un conjunto uniforme

de cualidades y de servicios, incluyendo una descripción de cómo crear nuevos objetos en la

clase. Para ellos la relación Clase-Objeto significa “una clase y los objetos en esa clase”.

Para Martin y Odell (1992) una clase es una implementación de un concepto o de un tipo de

objeto. En lenguajes de programación OO, los tipos de datos abstractos se llaman clases.

Para Rumbaugh (1999) una clase del objeto describe un grupo de objetos con las características

similares (cualidades), el comportamiento común (operaciones), relaciones comunes a otros

objetos, y la semántica común. La persona, la compañía, el animal, el proceso, y la ventana son

Figura 5.55

Representación de una clase con el método Booch

222

todas las clases del objeto. En la Figura 5.56 se muestra una clase según la notación de OMT,

contienen el nombre de la clase, sus atributos y métodos.


Shlaer y Mellor (1992) no mencionan ninguna definición explicita de “clase”, sólo hacen una

aproximación de lo que sería una clase.

Para Wrifs-Brock (1999) los objetos que comparten el mismo comportamiento se dice que

pertenecen a la misma clase. Una clase es una especificación genérica para un número arbitrario

de objetos similares. Se puede pensar en una clase como plantilla para una clase específica de

objeto.

Las “clases” en UML

Según Fowler las clases en UML pueden ser representadas de tres (3) maneras:

– Sin detalle

– Detalles a nivel de análisis y diseño

– Detalle a nivel de implementación

Y los atributos pueden describirse como:

visibilidad : tipo = valor-inicial { propiedad }, donde visibilidad puede ser:

– + publico

– # protegido

– - privado

En la Figura 5.57 se muestra una clase según el estándar UML, contienen el nombre de la clase y

sus atributos.

Figura 5.56

Representación de una clase en OMT

223


5.3.7. Análisis comparativos entre los diagramas de secuencia de los métodos OO y los de

UML.

En los Métodos OO lo que se conoce como diagramas de interacción (Booch), y diagramas de

seguimientos de sucesos (OMT), se le denominan diagramas de secuencias en UML. En los

diagramas de secuencia por cada escenario que se presenta se construye un diagrama. En las fases

de iniciales de análisis y diseño de un proyecto estos diagramas permite razonar más en detalle

como es el comportamiento de un escenario y de esta manera se pueden obtener nuevas clases y

objetos en el escenario (enriquecimiento del diccionario de datos), además de permitir detectar

cuáles son los métodos de las clases, al observar como se relacionan los objetos entre sí para

llevar a cabo la tarea encomendada en el escenario. Y en la fase de prueba del desarrollo de un

software los diagramas de secuencia se utilizan para validar el código.

Diagramas de interacción (Notación Booch)

Para Booch (1991) un diagrama de interacciones se usa para realizar una traza de la ejecución de

un escenario en el mismo contexto que un diagrama de objetos de la notación Booch. Los

diagramas de interacción toman los elementos esenciales de los diagramas de objetos y los

Figura 5.57

Representación de una clase en UML

224

reestructuran para enfocarlos a la lectura de los mensajes en orden. El orden se indica mediante

la posición vertical, siendo el primer mensaje el de la parte superior y el último el de la parte

inferior. Por tanto no necesitan números de secuencia. Los diagramas de interacción son mejores

que los diagramas de objetos para capturar la semántica de los escenarios en un momento

temprano del ciclo de desarrollo.

Guiones y centros de control

Un guión son las instrucciones generales de cada mensaje del diagrama de interacción.

Los guiones se escriben a la izquierda del diagrama de interacción en lenguaje natural

(español) o en un lenguaje de programación.

Ni los diagramas de objetos ni los diagramas de interacción indican por sí solos el centro de

control a medida que pasan los mensajes.

En el diagrama de interacción se utilizan rectángulos en las líneas verticales de cada objeto

para indicar el tiempo relativo durante el cual el flujo de control está centrado en ese objeto.

En la Figura 5.58 se muestra un ejemplo de un diagrama de interacción según la notación de

Booch.


Escenarios y seguimientos de sucesos (Notación de OMT)

Un escenario es una secuencia de sucesos que se produce durante una ejecución concreta de un

sistema. El ámbito de un escenario es variable; puede incluir todos los sucesos del sistema, o que

sean generados por ellos. Todo suceso transmite información de un objeto a otro. El primer paso

Figura 5.58

Ejemplo de un diagrama de interacción (Notación Booch)

225

para la construcción de escenario es identificar los objetos emisores y receptores de cada suceso.

La secuencia de sucesos y los objetos que intercambian sucesos se pueden mostrar ambos en un

escenario mejorado que se denomina seguimiento de traza de sucesos. El tiempo aumenta desde

arriba hacia abajo, aunque en el seguimiento de sucesos no importa la temporización exacta, sino

que importa la secuencia de los procesos. Algunos de los pasos para construir un diagrama de

seguimientos de sucesos son los siguientes:

Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y el

sistema.

Identificar los eventos que se dan entre objetos y preparar una traza de eventos para cada

escenario.

En la Figura 5.59 se muestra un ejemplo de un diagrama de seguimiento de sucesos.


Diagramas de secuencias en UML

Un diagrama de secuencia como se observa en la Figura 5.60 muestra las interacciones entre

objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y

Figura 5.59

Ejemplo de un diagrama de seguimiento de sucesos

(Notación OMT)

226

la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad

descrita por el escenario. En aplicaciones grandes además de los objetos se muestran también los

componentes y los de casos de uso. En este sentido mostrar los componentes tiene sentido ya que

se trata de objetos reutilizables, en cuanto a los casos de uso hay que recordar que se

implementan como objetos cuyo rol es encapsular lo definido en el caso de uso. Los diagramas de

secuencia enfatizan el orden de tiempo de los mensajes. A diferencia de los anteriores diagramas

estos se corresponden con los escenarios y subescenarios con mucho más detalles y siguen la

misma codificación que los escenarios y subescenarios.


5.3.8. Análisis comparativo entre los casos de uso de los métodos OO y los de UML

Diagramas de casos de uso en los métodos OO

El modelo de casos de uso fue desarrollado por Ivar Jacobson cuando desarrollo el método

conocido como OOSE (Ingeniería de Software Orientado a Objetos-ISWOO) para ser utilizado

específicamente en el desarrollo de software orientado a objetos. En este método el modelo de

casos de uso sirve como un modelo central del cual todos los otros modelos son derivados.

Según Jacobson (1992) un caso de uso utilizado en el desarrollo de software orientado a objeto es

una técnica de modelado utilizada para describir lo que un nuevo sistema debe hacer o lo que un

sistema existente ya hace y se construye mediante un proceso iterativo durante las reuniones entre

Figura 5.60

Ejemplo de un diagrama de secuencia UML

227

los desarrolladores del sistema y los clientes (y/o los usuarios finales) conduciendo a una

especificación de requisitos sobre la que todos coinciden. Por otro parte captura algunas de las

acciones y comportamientos del sistema y de los actores.

En cuanto al escenario: a veces se utilizan como sinónimos de casos de uso, sin embargo en

UML un escenario se refiere a los pasos que se desarrollan dentro de un caso de uso

Semejanzas

El sistema que se desea modelar se representa encerrado en un rectángulo.

Los actores son los que interactúan con el sistema. Estos representan lo que necesite

intercambiar con el sistema. Un actor funciona como una clase.

Se diferenciará entre actores y usuarios: el primero representa el papel (rol) que una persona

desempeña y el segundo es una persona que utiliza el sistema. Por ejemplo una persona puede

ser usuario y administrador en un sistema, unas veces actuará como usuario y otras como

administrador, pero deben contemplarse ambos actores.

Los casos de uso es un camino específico para utilizar el sistema.

Para cada caso de uso, Actor y Sistema se realiza una descripción detallada.

Los casos de uso tan sólo indican opciones generales.

El diagrama de casos de uso (Ver Figura 5.61) es un diagrama sencillo que tiene como finalidad

dar una visión global de toda la aplicación de forma que se pueda entender de una forma rápida

y gráfica tanto por usuarios como por desarrolladores.


Figura 5.61

Ejemplo de un diagrama de caso de uso

228

Diagramas de casos de uso en UML

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del

sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción

externa. Un caso del uso especifica el comportamiento de un sistema o de una parte de éste y

describe las secuencias de las acciones

Booch et al. (2002) afirma que los diagramas de casos de uso se pueden utilizar para representar

el comportamiento deseado de un sistema, sin la necesidad de especificar cómo este

comportamiento se pone en ejecución. Los diagramas de casos de uso proveen una manera que

los desarrolladores, los especialistas finales del dominio y los usuarios tienen una comprensión

común del problema. Un caso de uso representa un requisito funcional del sistema en su

totalidad.

El diagrama de casos de uso es parte de UML.

Un caso de uso es la típica interacción entre un usuario y un sistema informático.

Un actor es el papel que el usuario juega con respecto al sistema. Un actor no tiene que ser un

humano, puede ser por ejemplo otro sistema externo que pide información al sistema actual

La relación <<extiende>> se utiliza cuando un caso de uso es similar a otro caso de uso pero

se le añade alguna característica nueva.

La relación <<include >> se utiliza cuando se tiene una parte del comportamiento común a

más de un caso de uso, y no se desea almacenar una copia en cada caso de uso de la

descripción de este comportamiento.

Los diagramas de casos describe un conjunto de secuencias, cada una representa una interacción

de los actores externos. Este comportamiento, en la realidad son funciones utilizadas a nivel de

sistema para visualizar, especificar, construir y colocar el comportamiento previsto del sistema

durante el análisis de requisitos.

Análisis a nivel de escenario

Se enumeran escenarios fundamentales para el funcionamiento del sistema.

Se estudia cada escenario utilizando guiones como los que se usan en el cine.

229

Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, así

como los mecanismos que relacionan los objetos.

De los escenarios iniciales se puede pasar a otros escenarios secundarios.

Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas.

El estudio de los escenarios con detalle permite ir enriqueciendo el diccionario de datos.

No es necesario hacer todos los escenarios y sub-escenarios posibles si se observa que no

enriquecen el diccionario de datos.

Los Casos de Uso de UML cubren la carencia existente en los métodos previos (OMT, Booch) en

cuanto a la determinación de requisitos.

5.3.9. Análisis comparativo entre los diagramas de objeto de los métodos OO y los de UML.

Diagrama de objeto (Notación OMT)

El uso de los diagramas de objetos se aplica en la construcción del modelado de objeto. Este

diagrama describe la estructura estática (de datos), de los objetos del sistema (identidad, atributos

y operaciones) y también sus relaciones. El modelo de objetos contiene diagramas de objetos. Un

diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones

entre las clases. El diagrama contiene clases de objetos organizados en jerarquías que comparten

una estructura y comportamiento comunes y que están asociadas a otras clases. Estas clases

definen los atributos que lleva cada instancia de objeto y las operaciones que efectúe o sufre cada

uno. En cada instancia de la clase se guardan los valores de esos atributos.

Los pasos que se llevan a cabo para el modelo de objetos son:

Identificar las clases (y objetos): se seleccionan los sustantivos de la descripción del

problema como posibles clases candidatas y se construye una lista. Se eliminan las clases

redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de

implementación. Las clases se representan por rectángulos con tres compartimientos, en el

primero se pone el nombre de la clase, en el segundo los atributos y en el tercero las

operaciones o métodos.

230

Se añaden las asociaciones y agregaciones entre las clases (y objetos): una asociación es

una dependencia entre dos o más clases. Las asociaciones, se representan por líneas que

unen a las clases sobre las cuales se puede escribir el nombre de la asociación.

Se añaden los atributos de los objetos y sus uniones: los atributos son propiedades de los

objetos tales como nombre, peso, velocidad, etc.

Se organizan y simplifican las clases usando herencia: la herencia se puede usar para

generalizar los aspectos comunes de las clases existentes construyendo una superclase, o

para refinar una clase en subclases especializadas. La notación de OMT para la herencia

es un triángulo debajo de la superclase.

Verificar que existan trayectorias en el modelo de objetos, usando escenarios e iterando

los pasos siguientes como sea necesario.

Agrupar las clases en módulos, basándose en su proximidad y función.

Iterar y refinar el modelo.

Diagrama de objeto (Notación de Booch)

Los diagramas de objeto de la notación de Booch (Ver Figura 5.62) se utilizan como parte de la

estructura lógica de su método, estos diagramas muestra la existencia de objetos y sus relaciones

en la vista lógica de un sistema. En la fase de análisis estos diagramas se usan para indicar la

semántica de los escenarios primarios y secundarios que proporcionan la traza del

comportamiento del sistema y en la fase de diseño se utilizan para ilustrar la semántica de los

mecanismos del diseño lógico. Cada objeto del diagrama se denota con su nombre y

opcionalmente con sus atributos, estos interaccionan a través de enlaces con otros objetos. El

objeto cliente es el objeto que invoca una operación y el objeto servidor es el objeto que

suministra la operación. La relación entre objetos viene dada por medio de una flecha que indica

la dirección de la invocación, así como la operación, y un número de orden (opcional). En la

Figura 5.62 se muestra un ejemplo de un diagrama de objeto según la notación de Booch.

231


Papeles (roles) y flujo de datos

• Se pueden especificar los papeles (roles) del diagrama de clases en el diagrama de objetos.

• Se pueden indicar también las claves y restricciones del diagrama de clases en el diagrama de

objetos.

• Se muestra explícitamente la dirección del flujo de datos que ayuda a explicar la semántica de

un escenario particular.

• Se indica la dirección del flujo de datos con una flecha y un círculo.

• Se puede usar tanto un objeto como un valor para el flujo de datos.

En la Figura 5.63 se muestran los roles y flujos de datos de un diagrama de objetos.


Figura 5.63

Ejemplo de flujo de datos

Figura 5.62

Ejemplo de un diagrama de objeto (Notación Booch)

232

Visibilidad de enlace

• En ciertos escenarios es útil reflejar la forma exacta en que un objeto tiene visibilidad sobre otro

• Las marcas de visibilidad son

G - El objeto servidor es global al cliente

P - El objeto servidor es parámetro de alguna operación del cliente

F - El objeto servidor es parte del cliente (field, campo)

L - El objeto servidor es un objeto declarado local en el ámbito del diagrama de objetos

• La ausencia del adorno de visibilidad indica que está sin especificar

En el diagrama de objetos de la Figura 5.64 se muestran los diferentes tipos de visibilidad sobre

un objeto.


Objetos activos y sincronizados

• Los objetos son activos si incorporan su propio hilo de control

• Todos los objetos son secuenciales a menos de que se diga lo contrario

– sincronismo simple: sólo hay un único hilo de control

• Se puede indicar el estilo de concurrencia de un objeto:

– Síncrono: el cliente espera hasta que el servidor acepte el mensaje

Figura 5.64

Ejemplo de visibilidad

233

– Paso de mensajes con abandono inmediato: el cliente abandona el mensaje si el

servidor no lo atiende inmediatamente

– Sincronización de intervalo (de espera o timeout): el cliente abandona el mensaje si el

servidor no puede atenderlo dentro de un espacio de tiempo determinado.

– Asíncrono: el cliente envía el evento al servidor para que lo procese, el servidor pone

el mensaje en una cola, y el cliente continúa su actividad sin esperar al servidor

En el diagrama de objetos de la Figura 5.65 se muestran los diferentes tipos de sincronismo.

Presupuestos de tiempo y especificaciones

• Para aplicaciones críticas respecto al tiempo se pueden trazar escenarios indicando tiempos

exactos. Se usan valores de tiempo en vez de números de secuencia que indican tiempo relativo

(por ejemplo en segundos) con el signo más delante. En la Figura 5.66 se muestra un diagrama de

objetos donde los tiempos son en segundos.

• Especificaciones. Al igual que para los diagramas de clases cada entidad del diagrama de

objetos puede tener su especificación en texto.

Figura 5.66

Representación de tiempos en un diagrama de objetos

Figura 5.65

Ejemplo de sincronismo



234

Diagramas de objetos (Notación UML)

Los diagramas de objetos de UML (Ver Figura 5.67) modelan las instancias de elementos

contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y

sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para

visualizar los aspectos estáticos del sistema, mientras que los diagramas de interacción se utilizan

para ver los aspectos dinámicos del mismo. Estos cuentan con instancias de los elementos del

diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los

diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el

diagrama de clases, representando sólo la parte estática de un interacción, consistiendo en los

objetos que colaboran pero sin ninguno de los mensajes intercambiados entre ellos.

Los diagramas de objetos se emplean para modelar la vista de diseño estática o la vista de

procesos estática de un sistema al igual que se hace con los diagramas de clases, pero desde la

perspectiva de instancias reales o prototípicas. Esta vista sustenta principalmente los requisitos

funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos

estáticas.

En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que

implica tomar una instancia de los objetos de un sistema en un cierto momento. Un diagrama de

objetos representa una escena estática representada por un diagrama de interacción. Los

diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia

de ciertas instancias en el sistema, junto a las relaciones entre ellas.

Los diagramas de objetos son especialmente útiles para modelar estructuras de datos complejas.

Evidentemente puede existir una multitud de posibles instancias de una clase particular, y para un

conjunto de clases con varias relaciones entre ellas, pueden existir muchas más configuraciones

posibles de estos objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar

significativamente conjuntos interesantes de objetos concretos o prototipos. En la Figura 5.67 se

observa un ejemplo de un diagrama de objetos en UML.

235

desde el diagrama de clases


La principal diferencia entre estos diagramas es el uso de mensajes entre objetos, el rol, el uso de

lleves y restricciones, el sincronismo y visibilidad de los enlaces.

Figura 5.67

Ejemplo de un diagrama de objetos en UML

Juan:Usuario


Edad: 22

Lisiu:Ordenador

Marca: “Sun”

UsaJuan:Usuario


Edad: 22

Juan:Usuario


Edad: 22

Lisiu:Ordenador

Marca: “Sun”

Usa

Ordenador

Marca: String

Usuario

Nombre: String

Edad: Integer

Usa0…* 1…*

Ordenador

Marca: String

Usuario

Nombre: String

Edad: Integer

Usa0…* 1…*

Conclusiones

Conclusiones

Para finalizar se puede decir que dentro del área de la computación el desarrollo de software es

importante, pero más importante que esto, es el planteamiento de un proyecto de software que se

le quiere dar solución con sistematización técnica, ya que podría caerse en un error al pensar que

sin el uso de técnicas y métodos se puede llegar fácilmente a la elaboración correcta y eficiente

de un software, lo cual sería posible si se tratase de programas sencillos y pequeños, pero cuando

se tienen que elaborar sistemas de grandes dimensiones y con alto grado de complejidad, se

presentan problemas para su diseño; como alternativa, se debe seguir un orden y aplicar unas

técnicas que deben ser tomadas en consideración para el diseño y la estructura general de un

programa.

La mayoría de los sistemas a desarrollar son complejos, por lo tanto, es necesario descomponerlo

o dividirlo en partes, de manera que sea posible su comprensión. Cada una de esas partes se

pueden representar como modelos que abstraen y describen los aspectos esenciales del sistema.

Por eso, es importante crear, durante la construcción del software, modelos que organicen y

comuniquen los detalles del mundo real con el sistema que son relacionados, así como del

sistema ya construido.

El primer enfoque que se utilizó para descomponer un problema en partes, fue el del análisis

estructurado basado en funciones y procesos, teniendo como resultado una descomposición

jerárquica de los componentes de los procesos en sub-procesos, ello hace posible la construcción

de modelos que representan el flujo y el contenido de la información. El siguiente enfoque fue el

del análisis orientado a objetos, que acentúa la descomposición de un problema, pero desde la

perspectiva de los objetos, clases, cualidades y operaciones como componentes principales a

modelar. Por último, con el surgimiento del UML se siguió el enfoque de descomposición de los

problemas en partes, para una mejor comprensión, pero ahora utilizando diferentes diagramas que

se dividen en estáticos y dinámicos, pero utilizando como base los objetos y las clases.

En esta investigación se ha realizado un análisis comparativo en cuanto a los elementos

estructurales, de relación y entre los diferentes diagramas que se presentan en la programación

estructurada y orientada a objeto con el fin de compararlo con los de UML.

238

En cuanto a los elementos básicos que se presentan en el desarrollo estructural son de tipo

condicional que cambian según los requerimientos del sistema. Se analizan los problemas

mediante los diagramas de flujo de datos, para luego programar una solución, es decir se

desarrolla el sistema haciendo uso de los datos, en este caso, los diagramas de entidad relación se

utilizan para el desarrollo de bases de datos. Los elementos que se presentan en los métodos

orientados a objetos lo hacen con la finalidad de representar objetos y sus clases utilizando

diversos diagramas, unos más completos que otros.

Los elementos estructurales que se presentan en UML son heredados de los elementos

estructurales utilizados en los métodos orientados a objetos, éstos se mantienen constantes en el

tiempo. Estas estructuran varían muy poco en las distintas versiones de UML.

Entre las fortalezas de UML se encuentra que los elementos estructurales que manejan sirven para

modelar tanto procesos estáticos como dinámicos.

Respecto a las relaciones que existen entre los métodos OO y los de UML, muchas de las

relaciones que surgieron en los métodos orientados a objetos fueron adaptadas por UML sin

cambios dramáticos en su teoría. Una crítica generalizada a UML es su generosidad y falta de

semántica precisa para muchos aspectos que se han presentado, y todo esto por su orientación a

ser un estándar notacional para la modelización de cualquier tipo de sistema orientado a objetos.

Sin embargo esto tiene su lado positivo, puede ser adoptado con cierta facilidad a modelos

suficientemente formales y semánticamente ricos. Este es el caso de los métodos OO que tienen

su propia notación gráfica.

En lo referente a los diagramas se puede mencionar muchas diferencias cuando se realiza las

comparaciones respectivas, cada una de estás se reflejan en los resultados de esta investigación.

Lo más resaltante que se observo en los diagramas es que en los métodos OO existe lo que se

conoce como diagramas de navegación que son utilizados para reflejar el flujo de navegación de

los sistemas, en cambio en UML no existen estos tipos de diagramas, existe una ausencia de

herramientas o artefactos para plasmar el mapa de navegación del sistema. Si bien es

relativamente sencillo desarrollarlo mediante herramientas básicas de generación de gráficos y

diagramas, esta situación de libertad de expresión provoca que dependiendo del proyecto o más

239

bien del responsable del diseño, se deba trabajar con diagramas semánticamente similares pero no

idénticos, con los consecuentes problemas potenciales que pueden derivarse de los fallos de la

interpretación.

Otras de las carencias de UML es que no existe una notación especifica para describir modelos de

sistemas de tiempo real orientados a objetos, se puede ver que existe una falta de elementos

específicos predefinidos en el lenguaje para representar otros conceptos estrechamente

relacionados con el diseño de los mismos, tales como: componentes de hardware específicos y

sus características, tareas concurrentes y los mecanismos de comunicación entre ellas o

restricciones temporales especificadas bien a nivel de objetos, de tareas o incluso de hardware.

Estas carencias deberían ser cubiertas en las próximas versiones de UML y de esta manera se va

ir cubriendo todos los modelos que se podría presentar en un sistema.

A pesar de sus carencias UML ofrece un proceso de modelado sin fallas durante el análisis, para

diseñar la implementación, define una notación expresiva y consistente que se basa en estándares,

ayuda a señalar omisiones e inconsistencias en los proyectos desarrollados y soporta tanto

análisis como diseño de pequeños y grandes sistemas.

Por otro lado, se puede resaltar como ventaja de UML es que existe la posibilidad de definir

reglas (usualmente en OCL6) que describen restricciones sobre la semántica de las relaciones,

pudiendo diferenciar las que se dan en los Métodos OO y en UML, pero en este caso no se harán

mención a ellas ya que sólo se estudio la parte de los bloques de construcción de UML.

UML no garantiza el éxito de un proyecto pero permite a los ingenieros centrarse en la entrega de

un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es

soportado directamente por las mejores herramientas de software.

6 OCL es el acrónimo de Object Constraint Language

Bibliografía

Alarcón, Raúl. (2000). Diseño Orientado a Objetos con UML. Grupo EIDOS Consultaría y

Documentación Informática. Madrid-España.

Biggs, Peter. (1999). A Survey of Object-Oriented Methods. University of Durham, Recuperado

el 12 de agosto de 2006 de: http://students.cs.byu.edu/~pbiggs/survey.html.

Böhm, Corrado; Jacopini, Giuseppe. (1996). Flow diagrams, turing machines and languages with

only two formation rules. Communications of the ACM, vol. 9, Nº 5, 366-371.

Booch, Grady. (1991). Object-Oriented Design with Applications. The Benjamin/Cummings

Publishing Company Inc., Redwood City, CA.

Booch, Grady. (1996). Análisis y Diseño Orientado a Objetos con Aplicaciones. México: Pearson

Educación.

Booch, Grady; Rumbaugh, James; Jacobson, Ivar. (1999). El Lenguaje Unificado de Modelado.

(J. Sáez, trad.). Madrid: Addison Wesley Iberoamericana (Original en inglés publicado en

1998).

Booch Grady; Rumbaugh, James; Jacobson, Ivar. (2002). El Lenguaje Unificado de Modelado.

Manual de Referencia. Addison Wesley.

Botelho, Alessandro; Balancieri, Renato; Ferrari, Sandra. (2004). Do Diagrama de Fluxo de

Dados ao Use Case. I Workshop de Computación. Universidad del Sur Santa Catarina.

Brasil. Recuperado el 12 de diciembre de 2006 de:

http://inf.unisul.br/~ines/workcomp/cd/pdfs/3007.pdf.

Castells, Pablo. (2002). Conceptos de Programación Orientada a Objetos. ETS Informática.

Universidad Autónoma de Madrid. Recuperado el 12 de diciembre de 2006 de:

http://www.ii.uam.es/~castells/docencia/poo/1-conceptos.pdf.

Chapin, Ned. (1974). New Format for Flowcharts. Software. Practice and Experiencia. No. 4 pp.

341-357.

http://students.cs.byu.edu/~pbiggs/survey.html

http://inf.unisul.br/~ines/workcomp/cd/pdfs/3007.pdf

http://www.ii.uam.es/~castells/docencia/poo/1-conceptos.pdf

240

Coad, Peter; Yourdon, Edward. (1991) Object Oriented Design, Yourdon Press, Englewood

Cliffs, N.J., 1991.

Codd, Edgar. (1970). A Relational Model of Data for Large Shared Data Banks. CACM 13, 6. pp

377-387. Codd, Edgar. (1971). Further Normalization of the Data Base Relational Model.

IBM Research Report, Santa Teresa Lab, San José, California.

Codd, Edgar. (1990). The Relational Model for Database Management. Version 2, Addison

Wesley Publishing Company. DeMarco, Tom. (1979). Structured Analysis and Systems

Specification. Englewood Cliffs, N.J.: Prentice-Hall.

Cruzado, Ignacio; García, Jorge; Portugal, Javier. (2006). Metodologías Orientadas a Objetos.

Trabajo Teórico de Programación Avanzada. Departamento de Ingeniería Civil. Área de

Lenguajes y Sistemas Informáticos. Universidad de Burgos – España. Recuperado el 21

de junio de 2006 de: http://pisuerga.inf.ubu.es/icruzado/tfc/Metodologias.pdf.

Cueva, Juan. (1999). Introducción a UML: Lenguaje para Modelar Objetos. Departamento de

Informática. Universidad de Oviedo – España. Recuperado el 10 de febrero de 2007 de:

http://gidis.ing.unlpam.edu.ar/downloads/pdfs/IntroduccionUML.PDF.

Diagrama de Paquetes (2006, 14) de septiembre. Wikipedia, La enciclopedia libre. Fecha: de

consulta: 20:42, septiembre 25, 2006 desde http://es.wikipedia.org/wiki/Diagrama_de_paquetes.

Díaz, Gregorio. (2007). Diseño y Programación Orientada a Objetos. Ingeniería en Informática.

Universidad de Castilla – España. Recuperado el 10 de febrero de 2007 de:

http://www.info-ab.uclm.es/asignaturas/42579/.

Dorantes, Víctor; Magariños, Fernando; Jury, José. (2001). Curso de Bases de Datos y

PostgreSQL. Recuperado el 04 de julio de 2007 de: http://es.tldp.org/Tutoriales/NOTAS-

CURSO-BBDD/notas-curso-BD/node20.html.

Eriksson, Hans-Erik; Penker, Magnus. (1997). UML Toolki. Wiley Computer Publishing. New

York USA. Recuperado el 04 de julio de 2007 de: http://www.fi-

b.unam.mx/pp/profesores/carlos/aydoo/uml.html.

Fowler, Martin. (2003). UML Destilled: A Brief guide to the Tandard Object modeling Languaje.

Third Edition. Addison Wesley.

http://pisuerga.inf.ubu.es/icruzado/tfc/Metodologias.pdf

http://gidis.ing.unlpam.edu.ar/downloads/pdfs/IntroduccionUML.PDF

http://es.wikipedia.org/wiki/Diagrama_de_paquetes

http://www.info-ab.uclm.es/asignaturas/42579/

http://es.tldp.org/Tutoriales/NOTAS-CURSO-BBDD/notas-curso-BD/node20.html

http://es.tldp.org/Tutoriales/NOTAS-CURSO-BBDD/notas-curso-BD/node20.html

http://www.fi-b.unam.mx/pp/profesores/carlos/aydoo/uml.html

http://www.fi-b.unam.mx/pp/profesores/carlos/aydoo/uml.html

241

Gacitúa, Ricardo. (2003). Métodos de Desarrollo de Software: El Desafió Pendiente de la

Estandarización. Dpto. Sistemas de Información, Facultad de Ciencias Empresariales,

Universidad del Bío-Bío, Avda. Collao 1202, Concepción, Chile, e-mail:

[email protected]. Theoria, Vol. 12: 23-42. Recuperado el 10 de octubre de 2006 de:

http://redalyc.uaemex.mx/redalyc/pdf/299/29901203.pdf.

Gagliardi, Edilma (2003). Modelado Conceptual de Bases de Datos. Universidad Nacional de

San Luís. Ciclo Electivo. Recuperado el 24 de septiembre de 2006 de:

http://www.dirinfo.unsl.edu.ar/~bdtw/BD/teorias/modelado-rev06.ps.

Gane, Chris; Sarson, Trish. (1977). Análisis Estructurado de Sistemas. Quinta reimpresión.

Buenos Aires, Editorial El Ateneo.

Gane, Chris; Sarson, Trish. (1978). Structured Systems Analysis: Tool and Techniques.

Englewood Cliffs, N.J.: Prentice-Hall.

Gane, Chirs. (1988). Desenvolvimento Rápido de Sistemas. Libros Técnicos y Científicos Editora

LTDA, Río de Janeiro.

Gane, Chris; Sarson, Trish. (1990). Análisis Estructurado de Sistemas. Buenos Aires: El Ateneo

(traducción de Gane, C. and T. Sarson, Structured systems analysis, tools and techniques.

Software series. 1979, New Jersey: Prentice-Hall.).

Graham., Ian. (1994). Migrating to Object Technology. Workingham: Adison-Wesley

Hutchings, Timothy. (1997). Introduction to SSADM. Recuperado el 29 de octubre de 2006 de:

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4/index.htm.

IBM (1974). HIPO: A Design Aid and Documentation Technique. Publication Number GC20-

1851. White Planis, NY: IBM Corporation Data Processing.

Insfrán, Emilio; Pelechado, Vicente; Gómez, Jaime; Pastor, Oscar. (2001). Un estudio

comparativo de la expresividad de relaciones entre clases en OO-Method y UML.

Departamento de Sistemas de Información y Computación. Universidad Politécnica de

Valencia – España, S/N, 46071. Recuperado el 20 de marzo de 2006 de:

http://www.dsic.upv.es/~einsfran/papers/09-JIS98.pdf.

http://redalyc.uaemex.mx/redalyc/pdf/299/29901203.pdf

http://www.dirinfo.unsl.edu.ar/~bdtw/BD/teorias/modelado-rev06.ps

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4/index.htm

http://www.dsic.upv.es/~einsfran/papers/09-JIS98.pdf

242

Jackson, Michael. (1975). Principles of Program Design. New York: Academia Press Inc.

Jackson, Michael. (1983). System Development. Englewood Cliffs. New Jersey. Prentice-Hall.

Jacobson, Ivar. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach.

Addison-Wesley.

Jacobson, Ivar. (1993). Time for a cease-fire in the methods war. The Road to the Unified

Software Development Process. Parte 3 Cap. 4 p.59.

Jacobson, Ivar., Christerson, Magnus; Jonsson, Patrik; Overgaard, Gunnar. (1992). Object-

Oriented Software Engineering - A Use Case Driven Approach. ACM Press, Addison-

Wesley, Reading, Mass.

Joyanes, Luis (1992). Fundamentos de Programación. Algoritmos y Estructuras de Datos Mc

Graw-Hill. Mexico.

Kenneth, Orr (1977). Structured Systems Development. New York. Yourdon Press.

Larman, Craig. (2004). UML y Patrones. Una Introducción al Análisis y Diseño Orientado a

Objetos y al Proceso Unificado. Prentice Hall.

Letelier, Patricio. (1996). Desarrollo de Software Orientado a Objeto usando UML.

Departamento Sistemas Informáticos y Computación. Universidad de Valencia. España.

Recuperado el 29 de octubre de 2006 de: http://www.dsic.upv.es/~uml/curso.pdf.

Loucopoulos, Pericles; Karakostas Vassilios. (1995). Systems Requirements Engineering.

McGraw-Hill, New York, USA.

Losavio, Francisca; Chirinos, Ledis; Lévy, Nicole; Ramdane-Cherif, Amar. (2003). Quality

Characteristics for Software Architecture. Recuperado el 05 de agosto de 2006 de:

http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT

Journal of Object Technology. Vol. 2, No. 2, March-April.

Macías del Campo, Javier. (2006). Ingeniería del Software: UML. Material de Apoyo de I.T.I.G.

e Ingeniería Electronica de la Universidad de Alcalá – España. Recuperado el 05 de enero

http://www.dsic.upv.es/~uml/curso.pdf

http://www.jot.fm/

243

de 2007 de: http://www.desarrollos-mecame.com/formacion/Ingenieria-

Software/Ingenieria%20software_archivos/temaUML.doc

Martin, James; McClure, Carma. (1985). Structured Techniques for Computing. Englewood

Cliffs. New Jersey. Prentice-Hall.

Martin, James; Odell, James. (1992). Object Oriented Analysis and Design, Englewood Cliffs,

NJ, Prentice Hall.

Matteo, Alfredo. (2005). Unifield Modeling Language 2.0. Modulos. 1,2 y 3. Material no

publicado. Universidad Central de Venezuela (UCV). Postgrado en Ciencias de la

Computación. Asignatura Ingeniería de Modelos.

Mercedes, Avda. (2004). Bases de Datos, Modelo Relacional de Cood, Estructuras y

Restricciones. Departamento de Lenguajes y Sistemas Informáticos. ETS Ingeniería

Informática. Universidad de Sevilla. España. Recuperado el 11 de septiembre de 2006 de:

http://www.lsi.us.es/docencia/get.php?id=1453.

Morales, Alicia; Rugerio Alma. (2003). Metodologías para generación de Sistemas Orientados a

Objetos. Recuperado el 21 de noviembre de 2006 de:

http://ccc.inaoep.mx/~labvision/doo/proy/T32.pdf.

Murillo, Félix. (2002) Técnicas de Programación. Instituto Nacional de Estadística e Informática.

Colección Informática Fácil. Recuperado el 04 de julio de 2007 de:

http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5115/Libro.pdf

Myers, Glen. (1975). Reliable Systems through Composite design. New York: 1ra Ed. Petrocelli

Charter.

Nassi, Isaac; Shneiderman, Ben. (1973). Flowchart Techniques for Structured Programming.

ACM SIGPLAN Notices, No.8, pp 12-26.

Oktaba, Hanna. (1999). Tecnologías Orientadas a Objetos – OMT. Postgrado en Ciencia e

Ingeniería de la Computación. Universidad Nacional Autónoma de México. Recuperado

el 17 de diciembre de 2006 de: http://www.mcc.unam.mx/~cursos/Objetos/Omt/omt.html.

http://www.desarrollos-mecame.com/formacion/Ingenieria-Software/Ingenieria%20software_archivos/temaUML.doc

http://www.desarrollos-mecame.com/formacion/Ingenieria-Software/Ingenieria%20software_archivos/temaUML.doc

http://www.lsi.us.es/docencia/get.php?id=1453

http://ccc.inaoep.mx/~labvision/doo/proy/T32.pdf

http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5115/Libro.pdf

http://www.mcc.unam.mx/~cursos/Objetos/Omt/omt.html

244

Page-Jones, Meilir. (1980): The Practical Guide to Structured Systems Design. 1ra Ed. Yourdon

Press.

Pastor, Oscar; Ramos, Isidro. (1997). Oasis 2.2: A Class-Definition Language to Model

Information Systems Using an Object-Oriented Approach. SPUPV-95.788, Universidad

Politécnica de Valencia.

Pérez, Mario. (2002). Análisis y Diseño Orientado a Objetos usando la notación UML.

Universidad Nacional de Colombia. Basada en material de la Universidad Politécnica de

Valencia. Recuperado el 05 de septiembre de 2006 de:

http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CursoOOconUML.pdf.

Peter, Chen, (1976). The Entity-Relationship model. Tower A Unified View of Data. ACM

Transactions on Database System, Vol. 1, número 1, pp. 9-36.

Peter, Chen, (1977). The Entity-Relationship Approach to Logical Database Design. Wellesley,

Mass.:Q.E.D. Information Sciences.

Piattini, Mario; De Miguel, Adoración. (1939). Concepción y Diseño de Bases de Datos del

Modelo E/R al Modelo Relacional. Adison Wesley Iberoamericana México.

Pickin, Simon. (2005). Introducción a UML. Departamento de Ingeniería Telemática.

Universidad Carlos III de Madrid. España. [email protected]. Recuperado el 14 de

septiembre de 2006 de:

http://www.hacktegus.com/univ/UNICAH/CASE/Gu%EDa%20de%20Estudio%20y%20

Manuales/UML_Presentacion.pdf.

Presman, Roger. (2001). Ingeniería del Software. Un enfoque Práctico. Quinta Edición. McGraw

Hill.

Robinson, Peter. (1992). Hierarchical Object-Oriented Design. Prentice Hall, London.

Robinson, Peter. (1992). Introduction and Overview. In: Object-Oriented Design. Robinson, P.J.

ed.; Chapman & Hall, London; pp 1-10.

Rossi, Bibiana; Britos, Paola; García, Ramón. (1998). Modelado de Objetos. Revista del Instituto

Tecnológico de Buenos Aires - Argentina, vol. 21, p.24–32. ISSN/ISBN: 03261840.

http://dis.unal.edu.co/~fgonza/courses/2003/ingSoft1/CursoOOconUML.pdf

mailto:[email protected]

http://www.hacktegus.com/univ/UNICAH/CASE/Gu%EDa%20de%20Estudio%20y%20Manuales/UML_Presentacion.pdf

http://www.hacktegus.com/univ/UNICAH/CASE/Gu%EDa%20de%20Estudio%20y%20Manuales/UML_Presentacion.pdf

245

Recuperado el 17 de enero de 2007 de: http://www.itba.edu.ar/capis/webcapis/RGMITBA/articulosrgm/R-

ITBA-21-modeladodeobjetos.pdf.

Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William.

(1991). Object Oriented Modelling and Design. Prentice-Hall, Englewood Cliffs, N.J.

Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William.

(1999); Modelado y Diseño Orientados a Objetos; Metodología OMT. España: Prentice

Hall.

Sánchez, Jorge. (204). Principios sobre Bases de Datos Relacionales. Licencia de Creative

Commons del tipo Attribution-Non Comercial-ShareAlike. Recuperado el 03 de agosto de

2006 de: http://www.jorgesanchez.net/bd/bdrelacional.pdf.

Shlaer, Sally; Mellor, Stephen. (1988). Object-Oriented Systems Analysis: Modeling the World in

Data, Yourdon Press, Englewood Cliffs, N.J.

Sommerville, Ian. (2005). Ingeniería de Software .Addison-Wesley. Séptima Edición.

Vallejos, Oscar. (2001). OMT: Tema 8 de Análisis de Sistema I. Facultad de Ciencias Exactas y

Naturales y Agrimisura. Universidad de Nordeste – Argentina. Recuperado el 11 de

noviembre de 2006 de:

http://exa.unne.edu.ar/depar/areas/informatica/anasistem1/public_html/Marco-Temas.htm.

Warnier, Jean. (1981). Logical Construction of Systems. New York. Editorial Van Nostrand

Reinhold. pp.11-38.

Wasserman, Anthony; Pircher, Peter; Muller, Robert. (1990). The object-oriented structured

design notation for software design representation. IEEE Computer, Marzo, 50-62.

Webster`s New World Dictonary (1980). Second Collage Edition, New York: Simon & Schuster.

Weitzenfeld, Alfredo. (2004). Ingeniería de Software Orientada a Objetos con UML, Java e

Internet. Editorial Thomson Learning. Recuperado el 04 de julio de 2007 de:

ftp://ftp.itam.mx/pub/investigadores/alfredo/OBJETOS/MINT/Cap3-Procsw.pdf

http://www.itba.edu.ar/capis/webcapis/RGMITBA/articulosrgm/R-ITBA-21-modeladodeobjetos.pdf

http://www.itba.edu.ar/capis/webcapis/RGMITBA/articulosrgm/R-ITBA-21-modeladodeobjetos.pdf

http://www.jorgesanchez.net/bd/bdrelacional.pdf

http://exa.unne.edu.ar/depar/areas/informatica/anasistem1/public_html/Marco-Temas.htm

ftp://ftp.itam.mx/pub/investigadores/alfredo/OBJETOS/MINT/Cap3-Procsw.pdf

246

Wirfs-Brock, Rebecca; Wilkerson, Brian; Wiener, Lauren. (1990). Designing Object Oriented

Software. Prentice-Hall, Englewood Cliffs, N.J.

Yourdon, Edward. (1989). Análisis Estructurado Moderno. Prentice –Hall. México.

Yourdon Edgard; Constantine Larry. (1975). Structured Design. 2da Ed. Englewood Cliffs,

Prentice Hall.

Yourdon Edward; Constantine, Larry. (1978). Structured Design. New York: Yourdon Press. pp.

42-50.

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

Software

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