plan docente de anÁlisis y diseÑo de sistemas de …

622
Plan docente de Análisis y Diseño de Sistemas de Información Página 1 de 316 PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN Departamento de Computación UNAN - León

Upload: others

Post on 16-Oct-2021

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 1 de 316

PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE

INFORMACIÓN

Departamento de Computación UNAN - León

Page 2: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 2 de 316

INDICE DE CONTENIDO 1 INTRODUCCIÓN............................................................................................................................8

2 OBJETIVOS.................................................................................................................................11

3 SITUACIÓN DE LA ASIGNATURA EN EL PLAN DE ESTUDIOS DE LA UNAN-LEON ..........13 3.1 RELACIÓN ENTRE ASIGNATURAS .............................................................................................13

3.1.1 Algoritmos y Estructuras de Datos..................................................................................15 3.1.2 Programación I ................................................................................................................15 3.1.3 Programación II ...............................................................................................................17 3.1.4 Programación Avanzada .................................................................................................17 3.1.5 Base de Datos I ...............................................................................................................19 3.1.6 Base de Datos II ..............................................................................................................20 3.1.7 Ingeniería del Software ...................................................................................................21

4 METODOLOGÍA DIDÁCTICA Y MATERIAL DIDÁCTICO UTILIZADO.....................................23

5 PROCESO DE EVALUACIÓN.....................................................................................................25

6 TEMPORIZACIÓN .......................................................................................................................27

7 DESARROLLO DEL TEMARIO ..................................................................................................34 7.1 PRESENTACIÓN DE LA ASIGNATURA ........................................................................................34 7.2 PROBLEMAS DE LA GESTIÓN DE LA INFORMACIÓN.....................................................................42

7.2.1 La información y su importancia......................................................................................43 7.2.2 El poder de la información...............................................................................................43 7.2.3 La información para la creación de riqueza ....................................................................44 7.2.4 La paradoja de la información .........................................................................................44 7.2.5 Administración de la información como recurso .............................................................45

7.3 INTRODUCCIÓN AL DESARROLLO DE SISTEMAS DE INFORMACIÓN...............................................47 7.3.1 Conceptos de Análisis y Diseño de Sistemas.................................................................49

7.3.1.1 Qué es un Sistema ..............................................................................................................49 7.3.1.2 Sistemas de información ..................................................................................................... 49

7.3.2 Categorías de los sistemas de información ....................................................................50 7.3.3 Quienes son los usuarios? (James)................................................................................52 7.3.4 Preguntas ........................................................................................................................53 7.3.5 Introducción al desarrollo de Sistemas de Información ..................................................56 7.3.6 Ciclo de vida de un Sistema de Información...................................................................56 7.3.7 El analisis y diseño de sistemas. (James) ......................................................................60

7.3.7.1 Ejemplo:............................................................................................................................... 60 7.3.8 Estrategia para el desarrollo de sistemas .......................................................................62 7.3.9 Ciclo de vida clásico del desarrollo de sistemas.............................................................62 7.3.10 Método del Prototipo de Sistema................................................................................66

7.3.10.1 ¿Qué es un prototipo? ......................................................................................................... 66 7.3.10.2 Razones para desarrollar prototipos de sistemas................................................................ 66 7.3.10.3 Condiciones para aplicar el método de prototipo................................................................. 66 7.3.10.4 Pasos para el desarrollo de prototipos ................................................................................ 67

7.3.11 Método de desarrollo del ciclo de vida estructurado ..................................................68 7.3.11.1 ¿Qué es el análisis estructurado? ....................................................................................... 68 7.3.11.2 Elementos del Análisis Estructurado ................................................................................... 69 7.3.11.3 Descripción gráfica .............................................................................................................. 69 7.3.11.4 El diagrama lógico de flujo de datos .................................................................................... 69 7.3.11.5 Diagrama de flujos de datos ................................................................................................ 69 7.3.11.6 Diccionario de Datos............................................................................................................ 70 7.3.11.7 ¿Qué es el diseño estructurado?......................................................................................... 70

7.3.12 Preguntas de autoevaluación del Tema 2 ..................................................................71 7.4 TÉCNICAS DE RECOPILACIÓN DE DATOS...................................................................................76

Departamento de Computación UNAN - León

Page 3: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 3 de 316

7.4.1 Introducción de “instrumentos de datos”.........................................................................77 7.4.2 Entrevista.........................................................................................................................77

7.4.2.1 Planeacion de la entrevista.................................................................................................. 78 7.4.2.2 Tipos de preguntas .............................................................................................................. 78 7.4.2.3 Patrones .............................................................................................................................. 80 7.4.2.4 Realización de la entrevista ................................................................................................. 81 7.4.2.5 Solución de problemas durante la entrevista ....................................................................... 81 7.4.2.6 Conclusión de la entrevista.................................................................................................. 83 7.4.2.7 Redacción del informe de la entrevista................................................................................ 84

7.4.3 Observación ....................................................................................................................85 7.4.3.1 Tipos de Información buscada............................................................................................. 85 7.4.3.2 Observación del comportamiento del tomador de decisiones.............................................. 85 7.4.3.3 Esquemas observacionales ................................................................................................. 86 7.4.3.4 Ventajas y Desventajas de los Muestreos ........................................................................... 86 7.4.3.5 Observación del Lenguaje Corporal del tomador de decisiones.......................................... 88 7.4.3.6 Oservación del ambiente físico............................................................................................ 88 7.4.3.7 Observación estructurada del ambiente .............................................................................. 88

7.4.4 El cuestionario .................................................................................................................90 7.4.4.1 Planeacion para el uso del cuestionario .............................................................................. 90 7.4.4.2 Definición de Preguntas....................................................................................................... 90 7.4.4.3 Requisitos para elegir el lenguaje de un cuestionario.......................................................... 92

7.4.5 Muestreo..........................................................................................................................94 7.4.5.1 Que es el Muestreo ............................................................................................................. 94 7.4.5.2 Diseño del muestreo............................................................................................................ 95 7.4.5.3 Decisión del tamaño de la muestra...................................................................................... 98

7.5 ESPECIFICACIÓN DE REQUISITOS SOFTWARE ........................................................................108 7.5.1 ¿Qué es una especificación de requisitos software?....................................................109 7.5.2 Propiedades de una especificación de requisitos software. .........................................109 7.5.3 Preparación del ERS.....................................................................................................111 7.5.4 Estructura de un ERS....................................................................................................111 7.5.5 Ventajas de un ERS. .....................................................................................................114 7.5.6 Ejemplo de un ERS. ......................................................................................................114

7.6 MÉTODOS DE ANÁLISIS DE REQUISITOS: ANÁLISIS ESTRUCTURADO........................................124 7.6.1 Análisis ..........................................................................................................................126 7.6.2 Análisis Estructurado.....................................................................................................126

7.6.2.1 Diagrama de Flujo de Datos – DFD................................................................................... 128 7.6.3 Mecánica del análisis estructurado ...............................................................................131

7.6.3.1 Creación de un modelo de flujo de datos .......................................................................... 131 7.6.4 Ejemplo 1: Creación de un modelo de flujo de datos: “Gallo Pinto”. ............................132 7.6.5 Ejemplo 2: Creación de un modelo de flujo de datos: “Hogar Seguro”. .......................136 7.6.6 Ejemplo 3: Creación de un modelo de flujo de datos: “Empresa Comercializadora de Productos”. .................................................................................................................................141 7.6.7 Diccionario de requisitos ...............................................................................................146

7.6.7.1 Definición de almacenes.................................................................................................... 149 7.6.8 Análisis estructurado e ingeniería del software asistida por computadora...................154

7.7 MODELO CONCEPTUAL DE DATOS..........................................................................................158 7.7.1 Método de diseño del modelo conceptual de datos......................................................159

7.7.1.1 Determinación del conjunto de referencia ......................................................................... 159 7.7.1.2 Determinación de los conjuntos primarios ......................................................................... 160

7.7.2 Determinación de los individuos y relaciones ...............................................................161 7.7.3 Determinación de las cardinalidades ............................................................................167 7.7.4 Determinación de las propiedades de cada individuo o relación..................................168 7.7.5 Verificación del modelo conceptual...............................................................................169 7.7.6 Simplificación del modelo conceptual ...........................................................................170 7.7.7 Determinación del modelo conceptual operativo ..........................................................170 7.7.8 Verificación del modelo conceptual operativo...............................................................171

7.8 FUNDAMENTOS DEL DISEÑO SOFTWARE.................................................................................173 7.8.1 Introducción...................................................................................................................175 7.8.2 Ingeniería del software y diseño del software. ..............................................................175 7.8.3 Proceso de diseño.........................................................................................................176

7.8.3.1 Diseño y calidad del software ............................................................................................ 177 7.8.3.2 Evolución del diseño de software ...................................................................................... 177

7.8.4 Fundamentos del Diseño ..............................................................................................178

Departamento de Computación UNAN - León

Page 4: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 4 de 316

7.8.5 Diseño modular efectivo................................................................................................183 7.8.6 Diseño de Datos............................................................................................................185 7.8.7 Diseño Arquitectónico ...................................................................................................186 7.8.8 Diseño Procedimental ...................................................................................................186

7.8.8.1 Herramientas de diseño..................................................................................................... 187 7.8.9 Diseño de interfaz .........................................................................................................191

7.9 MODELO LÓGICO DE DATOS .................................................................................................196 7.9.1 Introducción...................................................................................................................198 7.9.2 Modelo CODASYL ........................................................................................................198

7.9.2.1 Conceptos.......................................................................................................................... 198 7.9.2.2 Reglas de elaboración del modelo CODASYL................................................................... 200 7.9.2.3 Reglas de transformación de un M.C.D. en un M.L.D. CODASYL .................................... 204 7.9.2.4 Aplicación al ejemplo recapitulativo ................................................................................... 206

7.9.3 Modelo relacional ..........................................................................................................211 7.9.3.1 Presentación de los conceptos del modelo relacional. ...................................................... 211 7.9.3.2 Reglas de transformación de un M.C.D. en un M.L.D. relacional ...................................... 213 7.9.3.3 Ejemplo.............................................................................................................................. 215 7.9.3.4 Aplicación al ejemplo recapitulativo ................................................................................... 215

7.9.4 Caso de los ficheros clásicos ........................................................................................217 7.9.4.1 Introducción. ...................................................................................................................... 217 7.9.4.2 Definiciones con respecto a los ficheros............................................................................ 217 7.9.4.3 Reglas de transformación de un M.C.D. en un M.L.D. de tipo ficheros clásicos................ 218 7.9.4.4 Ejemplo.............................................................................................................................. 218 7.9.4.5 Aplicación al ejemplo recapitulativo ................................................................................... 219

7.9.5 Enfoque general de optimización de un M.L.D .............................................................220 7.10 MODELO LÓGICO DE TRATAMIENTO.......................................................................................223

7.10.1 Introducción...............................................................................................................224 7.10.2 Método de diseño conceptual de tratamientos .........................................................225

8 PRACTICAS DE LABORATORIO.............................................................................................239 8.1 PLANIFICACIÓN TEMPORAL....................................................................................................242 8.2 PROPUESTA Y SOLUCIÓN DE PRÁCTICAS................................................................................244

8.2.1 Práctica 1.......................................................................................................................244 8.2.2 Práctica 2.......................................................................................................................251 8.2.3 Práctica 3.......................................................................................................................261 8.2.4 Práctica 4.......................................................................................................................287

9 ANEXOS ....................................................................................................................................306

Departamento de Computación UNAN - León

Page 5: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 5 de 316

INDICE DE TABLAS Tabla 3.1.1 Relación de asignaturas........................................................................ 14 Tabla 5.1 Proceso de Evaluación............................................................................. 25 Tabla 6.1 Temporización general. ............................................................................ 27 Tabla 6.2 Temporización detallada. ......................................................................... 28 Tabla 7.4.1 Cuatro tipos principales de muestras. .................................................. 96 Tabla 7.4.2 Tabla del área bajo la curva normal. .................................................. 100 Tabla 8.1.1 Temporización de las prácticas y su relación con la teoría. ............... 243 INDICE DE FIGURAS Figura 3.1.1 Relación gráfica de asignaturas precedentes a ADSI. ......................... 14 Figura 3.1.2 Asignatura consecuente de ADSI. ....................................................... 21 Figura 7.3.1 Ejemplo de un DFD de nivel de contexto. ........................................... 69 Figura 7.6.1 Notación DFD básica. ....................................................................... 128 Figura 7.6.2 Refinamiento del flujo de información. .............................................. 130 Figura 7.6.3 DFD de nivel 0 del GalloPinto. .......................................................... 133 Figura 7.6.4 DFD de nivel 1 del GalloPinto. .......................................................... 134 Figura 7.6.5 Panel de Control de HogarSeguro. ................................................... 137 Figura 7.6.6 DFD de nivel contextual para HogarSeguro...................................... 137 Figura 7.6.7 DFD de nivel 1 para HogarSeguro. ................................................... 139 Figura 7.6.8 DFD de nivel 2 que refina el proceso Monitorizar Sensores........... 140 Figura 7.6.9 DFD de nivel 0 GESTION PEDIDO CLIENTE................................... 142 Figura 7.6.10 DFD de nivel 1 GESTION PEDIDO CLIENTE................................. 143 Figura 7.6.11 DFD de nivel 2 que refina el proceso EMITIR FACTURA............... 144 Figura 7.6.12 DFD de nivel 3 que refina el proceso GENERAR ORDEN COMPRA.

........................................................................................................................ 145 Figura 7.6.13 Notación de descripción del contenido para un diccionario de

requisitos......................................................................................................... 147 Figura 7.6.14 Ejemplo de Base de Datos de tipo Lista Invertida........................... 150 Figura 7.6.15 Ejemplo de Base de Datos tipo Jerárquica. .................................... 151 Figura 7.6.16 Ejemplo de Base de Datos tipo Red. .............................................. 152 Figura 7.6.17 Ejemplo de Base de Datos tipo Red. .............................................. 153 Figura 7.7.1 Modelo para la determinación de los conjuntos primarios................. 160 Figura 7.7.2 Ejemplo de representación de un modelo. ........................................ 161 Figura 7.7.3 Modelo para la determinación de individuos y relaciones. ................ 161 Figura 7.7.4 Existencia de un acontecimiento intercambio. .................................. 163 Figura 7.7.5 Caso 1: Venta viviendas.................................................................... 164 Figura 7.7.6 Caso 2: Almacenes realizan pedidos a proveedores. ....................... 164 Figura 7.7.7 Caso 3: Almacenes realizan pedidos a proveedores en fechas

diferentes. ....................................................................................................... 165 Figura 7.7.8 Caso 4: Médicos atienden a pacientes en una fecha determinada. .. 166 Figura 7.7.9 Regla de gestión 1 relativa a las dependencias funcionales. ............ 166 Figura 7.7.10 Regla de gestión 1: cada ocurrencia de precio vendrá dada por el

PROVEEDOR, PRODUCTO y TRAMO. ......................................................... 167 Figura 7.7.11 Cardinalidades de PEDIDO - PRODUCTO. .................................... 168 Figura 7.7.12 Ejemplo de relación completa. ........................................................ 170 Figura 7.8.1 Ubicación del Diseño del Software.................................................... 175

Departamento de Computación UNAN - León

Page 6: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 6 de 316

Figura 7.8.2 Diseño del Software e Ingeniería del Software. ................................ 176 Figura 7.8.3 Evolución de la estructura. ................................................................ 179 Figura 7.8.4 Diferentes estructuras. ...................................................................... 180 Figura 7.8.5 Estructuras de datos clásicas............................................................ 181 Figura 7.8.6 Procedimiento dentro de un módulo. ................................................ 182 Figura 7.8.7 Cohesión. .......................................................................................... 184 Figura 7.8.8 Acoplamiento. ................................................................................... 185 Figura 7.8.9 Construcciones en diagramas de flujo. ............................................. 188 Figura 7.8.10 Construcciones en diagramas de flujo. ........................................... 189 Figura 7.8.11 Nomenclatura de las tablas de decisión.......................................... 190 Figura 7.9.1 Ejemplo de un SET. .......................................................................... 199 Figura 7.9.2 Regla 1 del Modelo CODASYL. ........................................................ 200 Figura 7.9.3 Regla 2 del Modelo CODASYL. ........................................................ 201 Figura 7.9.4 Regla 3 del Modelo CODASYL. ........................................................ 202 Figura 7.9.5 Regla 4 del Modelo CODASYL. ........................................................ 202 Figura 7.9.6 Regla 2: transformación MCD MLD CODASYL. ........................... 204 Figura 7.9.7 Regla 3: transformación MCD MLD CODASYL. ........................... 205 Figura 7.9.8 Representación de los objetos de la PYME. ..................................... 207 Figura 7.9.9 M.C.D completo del ejemplo recapitulativo. ...................................... 208 Figura 7.9.10 M.L.D CODASYL del ejemplo recapitulativo. .................................. 210 Figura 7.10.1 Ejemplo de DFD y su matriz booleana. ........................................... 226 Figura 7.10.2 Grafo sin circuito. ............................................................................ 229 Figura 7.10.3 Ejemplo para explicar el Diagrama de Precedencia de Procesos... 232 Figura 8.2.1 Ejemplo de un diagrama E-.R. .......................................................... 245 Figura 8.2.2 Diagrama E-.R para el Registro Académico...................................... 247 Figura 8.2.3 Diagrama E-R para el Registro Académico en EasyCASE. .............. 250 Figura 8.2.4 Notación DFD básica. ....................................................................... 288 Figura 8.2.5 DFD de nivel 0 del GalloPinto. .......................................................... 292 Figura 8.2.6 DFD de nivel 1 del GalloPinto. .......................................................... 293 Figura 8.2.7 DFD de nivel 0 GESTION PEDIDO CLIENTE................................... 295 Figura 8.2.8 DFD de nivel 1 GESTION PEDIDO CLIENTE................................... 296 Figura 8.2.9 DFD de nivel 2 que refina el proceso EMITIR FACTURA................. 297 Figura 8.2.10 DFD de nivel 3 que refina el proceso GENERAR ORDEN COMPRA.

........................................................................................................................ 298 Figura 8.2.11 DFD de nivel 0 Gestión de la Sociedad ELEC. ............................... 300 Figura 8.2.12 DFD de nivel 1 Gestión de la Sociedad ELEC. ............................... 301 Figura 8.2.13 Explotación del proceso Facturación. ............................................. 303

Departamento de Computación UNAN - León

Page 7: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 7 de 316

IINNTTRROODDUUCCCCIIÓÓNN

Departamento de Computación UNAN - León

Page 8: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 8 de 316

1 INTRODUCCIÓN En el año 1994 se crea, bajo el Proyecto de Colaboración de la UA (Universidad de Alcalá) y la UNAN – León (Universidad Nacional Autónoma de Nicaragua – León), un convenio entre el Departamento de Automática –DA- de la UA y el Departamento de Computación –DC- de la UNAN. El objetivo inicial era apoyar la carrera de Licenciatura en Computación con capacitación continua al personal docente y la donación de bibliografía y ordenadores. El convenio ha permitido la especialización del personal docente y de estudiantes que se han incorporado al mismo. Una vez logrados con éxitos estos objetivos, el Departamento de Computación decidió la apertura de la carrera Ingeniería en Sistemas de Información - ISI, para ofrecer a los estudiantes una nueva alternativa en la elección de su carrera universitaria. Esta nueva carrera incluye asignaturas especializadas que antes no se tenían, así como asignaturas condensadas que reúnen diferentes materias del antiguo plan de la Licenciatura. Por esta razón, se ha elaborado este plan docente de una asignatura condensada, que servirá para alcanzar los objetivos propuestos en la apertura de la carrera. En el presente documento se aborda el desarrollo de los temas del Plan Docente de la asignatura Análisis y Diseño de Sistemas de Información que se imparte en la carrera de Ingeniería en Sistemas de Información en la UNAN – León. Se presenta también la relación con otras asignaturas, la metodología a seguir, material didáctico y apoyo para impartirla, la planificación del contenido teórico de dichos temas, así como la bibliografía necesaria con las referencias a Internet pertinentes. En este documento se describe y desarrolla los temas principales de cada capítulo de dicha asignatura, con el objetivo de que exista en el DC de la UNAN – León - una guía rápida de consultar y que pueda dar información tanto a profesores como a estudiantes del propósito y organización de la asignatura. El desarrollo de este plan docente se planteó en tres fases. En la primera fase se han definido: los objetivos, la situación de la asignatura en el plan de estudios, la metodología didáctica y material didáctico a utilizar, el proceso de evaluación de la asignatura y la temporización en el semestre. La segunda fase consistió en la recopilación de la información para desarrollar el contenido teórico previamente definido. En la última fase se elaboraron las propuestas de las prácticas de laboratorio a realizar y la temporización y el sistema de evaluación de dichas prácticas. El plan docente está compuesto de dos partes:

• Parte teórica: en esta parte se desarrolla el contenido teórico del temario planteado y que corresponde a la explicación de la asignatura en la clase magistral.

• Parte práctica: en esta parte se encuentran las prácticas de laboratorio que

los estudiantes deben seguir, para unificar los conceptos teóricos vistos en clase.

Departamento de Computación UNAN - León

Page 9: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 9 de 316

Para la realización del proyecto se ha contado con un ordenador IBM compatible con sistema operativo Windows XP y Microsoft Office 2000.

Departamento de Computación UNAN - León

Page 10: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 10 de 316

OOBBJJEETTIIVVOOSS

Departamento de Computación UNAN - León

Page 11: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 11 de 316

2 OBJETIVOS Los objetivos de este plan docente se listan a continuación:

• Elaborar un documento en el que se muestren los aspectos organizativos de la asignatura Análisis y Diseño de Sistemas de Información, tales como: situación, metodología y material didáctico, proceso evaluativo y temporización.

• Desarrollar el contenido temático, tanto a nivel teórico como práctico, de la asignatura Análisis y Diseño de Sistemas de Información.

• Proporcionar un material en el que se incluyan los conocimientos fundamentales en el área de Análisis y Diseño de Sistemas de Información, que un estudiante de Ingeniería en Sistemas de Información debería tener.

• Contar con un documento guía para impartir la asignatura de Análisis y Diseño de Sistemas de Información, y que sirva como elemento orientativo para futuros docentes de esta materia.

Departamento de Computación UNAN - León

Page 12: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 12 de 316

SSIITTUUAACCIIÓÓNN DDEE LLAA AASSIIGGNNAATTUURRAA EENN EELL PPLLAANN DDEE EESSTTUUDDIIOOSS

DDEE LLAA UUNNAANN--LLEEOONN

Departamento de Computación UNAN - León

Page 13: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 13 de 316

3 SITUACIÓN DE LA ASIGNATURA EN EL PLAN DE ESTUDIOS DE LA UNAN-LEON

La asignatura Análisis y Diseño de Sistemas de Información -ADS- se imparte en el noveno semestre (primer semestre de quinto año) de la carrera Ingeniería en Sistemas de Información de la UNAN – León, que ofrece la Facultad de Ciencias. La carrera se desarrolla a lo largo de 10 semestres de estudios, es decir, 5 años académicos / lectivos para la culminación de la misma. Esta asignatura se imparte en el IX semestre del plan de estudios. El período lectivo para esta asignatura consta de 6 horas a la semana, de las cuales 4 horas se dedican a la parte teórica y 2 horas a la parte práctica. El total de semanas de que consta un semestre es de 16, luego tenemos un total de 32 horas de práctica y 64 horas teóricas. Esta relación se muestra mejor en la Tabla 3.1

Tabla 3.1 Relación horaria de Análisis y Diseño de Sistemas de Información

Asignatura TSS HTS HPS THS THTS THPS THTPS ADSI 16 4 2 6 64 32 96

Leyenda: ADSI: Análisis y Diseño de Sistemas de Información. TSS: Total de Semanas por Semestre. HTS: Horas Teóricas Semanales. HPS: Horas Prácticas Semanales. THS: Total de horas semanales. THTS: Total de Horas Teóricas por Semestre. THPS: Total de Horas Prácticas por Semestre. THTPS: Total de Horas Teóricas y Prácticas por Semestre.

3.1 Relación entre asignaturas A continuación veremos la relación que existe entre Análisis y Diseño de Sistemas de Información y otras asignaturas del plan de ISI. En la siguiente tabla se muestran las asignaturas que aportan un conocimiento previo al curso de Análisis y Diseño de Sistemas de Información.

Departamento de Computación UNAN - León

Page 14: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 14 de 316

Tabla 3.1.1 Relación de asignaturas

Asignatura Impartida en Programación I y II III y IV Semestre Algoritmos y Estructuras de Datos

V Semestre

Estadística V Semestre Programación Avanzada VII Semestre Base de Datos I y II V y VI Semestre

Una relación más clara entre las asignaturas se muestra en la Figura 3.1.1.

Figura 3.1.1 Relación gráfica de asignaturas precedentes a ADSI. A continuación, se describirá brevemente el contenido de cada asignatura y su

on las demás asignaturas mostradas en la figura anterior. relación c

Departamento de Computación UNAN - León

Page 15: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 15 de 316

3.1.1 Algoritmos y Estructuras de Datos

su utilidad para resolver problemas de carácter científico o de la vida cotidiana..

ema No 1:

Esta asignatura tiene como algunos de sus objetivos, que el estudiante comprenda las estructuras de datos y su aplicación en la construcción de sistemas operativos, motores de base de datos y sistemas software; que entienda los algoritmos clásicosy El contenido por temas de la asignatura es el siguiente: TIntroducción a los Algoritmos: En este tema se estudia el concepto de Algoritmo, su representación, el análisis de la eficiencia de los algoritmos, y se exponen algunos algoritmos clásicos. Tema 2: Estructura de Datos: En este tema se estudian las diferentes estructuras de datos omo listas lineales, pilas, colas, listas doblemente enlazadas, tablas hash y árboles

binarios. Tema 3: Ordenamiento:

c

En este tema se estudian los conceptos de recursividad, ordenación y búsqueda. Se exponen los principales algoritmos de ordenación existentes como, la burbuja, inserción y quicksort; así como las dos técnicas de búsquedas más usadas: la búsqueda secuencial y la búsqueda binaria. La importancia de esta asignatura para Análisis y Diseño de Sistemas de Información, radica en la comprensión de las distintas estructuras de datos, las cuales son muy importantes al momento de usarlas en el desarrollo de un sistema.

3.1.2 Programación I Esta asignatura tiene como objetivos, que el alumno logre manejar y explicar las técnicas de un lenguaje de programación, que logre explicar los conceptos básicos de programación estructurada y que pueda atacar un problema haciendo uso de las técnicas para desarrollar algoritmos. El contenido por temas de la asignatura es el siguiente:

Departamento de Computación UNAN - León

Page 16: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 16 de 316

Tema No 1: Fundamentos de ordenadores: En este tema se estudia una Introducción a los ordenadores, el concepto de ordenador, la arquitectura propuesta por Von Neuman, definición de programa y lenguaje, qué son los periféricos y cómo funcionan, el concepto de un sistema operativo y qué tipos de programas existen. Tema No 2: Fases en el desarrollo de un programa: En este tema se hace una breve reseña histórica del Lenguaje C, se muestra la realización de un programa en C sencillo pero ilustrativo, se explican los caracteres que soporta C, los tipos fundamentales de datos con ejemplo de valores que puedan tomar, qué son los tipos derivados y cuándo usarlos, los nombres de tipos, constantes, identificadores, palabras claves, comentarios, variables, declaración de constantes, expresiones numéricas, los diferentes tipos de operadores que soporta C, qué son las expresiones y cómo se construyen, expresiones para expresar condición, y la prioridad y el orden de evaluación de una expresión. Tema No 3: Estructura de un programa: En este tema se explica cómo es la forma que debe tener un programa en C, qué son los ficheros de cabecera, expresiones, sentencias, declaraciones de funciones, definiciones de funciones, llamada a una función, los distintos tipos de argumentos que puede tener una función, ámbito y accesibilidad de una variable, las clases de almacenamiento, sentencias de asignación, y la entrada y salida estándar. Tema No 4: Sentencias de control: En este tema se estudian las sentencias condicionales if y else, las sentencias switch y las sentencias break, las sentencias while, do while, for, continue, y go to. Tema No 5: Tipos estructurados de datos: En este tema se estudian los arreglos, sus características, sus formas posibles de declaración, cómo se pasan los arreglos a una función, las cadenas de caracteres, las funciones para manipular cadenas de caracteres, funciones para conversión de datos, funciones para clasificar y convertir caracteres, qué son las estructuras y las uniones, qué son los campos de bits y cuando son útiles. Tema No 6: Punteros: En este tema se estudia qué son los punteros, para qué sirven y cómo se crean, las operaciones con punteros, se hace la relación entre punteros y arrays, los punteros a cadenas de caracteres, cómo se asigna memoria haciendo uso de los punteros y de las funciones de bibliotecas, y por último los punteros a estructuras. La importancia de esta asignatura en Análisis y Diseño de Sistemas de Información, se basa en que aporta los conocimientos necesarios de programación para que el alumno sea capaz de poder enfrentar la codificación básica de cualquier sistema.

Departamento de Computación UNAN - León

Page 17: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 17 de 316

3.1.3 Programación II Esta asignatura supone un previo conocimiento de Programación I, y tiene como objetivos desarrollar en el estudiante la capacidad para utilizar las funciones de C, así como ser capaz de desarrollar sus propias funciones para la implementación de programas de forma estructurada; proporcionar el estudiante el conocimiento necesario para que sea capaz de utilizar y crear sus propios archivos en Lenguaje C, y que pueda distinguir entre los diferentes tipos de archivos que se pueden implementar en este lenguaje; que el estudiante desarrolle habilidades para utilizar las macros predefinidas y directrices en C en el proceso de pre-compilación; y que el alumno pueda diseñar y utilizar estructuras dinámicas de datos y algoritmos básicos de ordenación. El contenido por temas de la asignatura es el siguiente: Tema No 1: Funciones: En este tema se estudia el paso de diferentes tipos de parámetros a una función: tipo array, tipo estructura y tipo puntero; las funciones que retornan punteros; los argumentos en la línea de órdenes; la redirección de la entrada y la salida; las funciones recursivas y las funciones predefinidas de C. Tema No 2: Funciones estándar de E / S: En este tema se estudia la manipulación de ficheros en el disco, la apertura y cierre de ficheros, la detección de errores, los diferentes tipos de E / S, los comandos que controlan el buffer, los ficheros temporales y los comandos para el acceso aleatorio. Tema No 3: El preprocesador de C: En este tema se estudia las macros y directrices, la compilación condicional y la utilización de ficheros de cabecera. Tema No 4: Estructuras dinámicas de datos y ordenación: En este tema se estudian las listas lineales y sus operaciones básicas; las pilas, colas, listas circulares y listas doblemente enlazadas; los árboles binarios de búsqueda, los árboles binarios perfectamente equilibrados, la recursividad y la clasificación de datos; los algoritmos de búsqueda de datos; la ordenación de ficheros en disco; y los algoritmos hash. La importancia de esta asignatura en Análisis y Diseño de Sistemas de Información, se basa en que aporta los conocimientos de programación en un nivel más complejo para que el alumno sea capaz de poder enfrentar la codificación básica de cualquier sistema.

3.1.4 Programación Avanzada Esta asignatura sirve para introducir al estudiante en los conceptos de la programación orientada a objetos, ya que la mayoría de los lenguajes de programación actuales se basan en esta metodología de programación y su

Departamento de Computación UNAN - León

Page 18: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 18 de 316

conocimiento es de vital importancia para el estudio de otras asignaturas tales como Programación Visual, Diseño de Compiladores, Análisis y Diseño de Sistemas de Información e Ingeniería del Software. El contenido por temas de la asignatura es el siguiente: Tema No 1: Introducción a la POO: En este tema se explican los conceptos en los que se fundamenta esta metodología de programación tales como herencia, polimorfismo, etc. Tema No 2: Mejoras en en C++: En este segundo tema se aborda el lenguaje C++ viendo algunos elementos propios del lenguaje y las mejoras con respecto a su antecesor: el lenguaje C.. Tema No 3: Clases: El tercer tema es uno de los más importantes ya que se encarga de explicar uno de los principales temas: el concepto de CLASE. Tema No 4: Trabajando con Clases: Este cuarto tema es una continuación del tercero, donde se ahonda aún más en el estudio de las clases, y se ven varios temas de carácter un poco más avanzado tales como miembros de una clase que son punteros, punteros a miembros de una clase, arrays de objetos, etc. Tema No 5: Operadores sobrecargados: El quinto tema abarca el tema de OPERADORES SOBRECARGADOS. Se explica cómo sobrecargar los operadores más importantes dentro de un contexto específico, ya sean unitarios o binarios. Tema No 6: Herencia y Polimorfismo: El sexto tema aborda otra de las características más importantes de la POO: el concepto de HERENCIA. También se estudia el concepto de POLIMORFISMO. Tema No 7: Tipos Genéricos: En el séptimo tema se estudian los tipos genéricos para comprender la forma de cómo generar plantillas de clase que puedan ser aplicadas a cualquier tipo de datos. Tema No 7: Manejo de excepciones: En el octavo y último tema se explica el mecanismo de manejo de excepciones que utiliza C++ para controlar situaciones anómalas durante la ejecución de un programa. La importancia de esta asignatura en Análisis y Diseño de Sistemas de Información, se basa en que aporta los conocimientos de la Programación Orientada a Objetos, necesarios para comprender los lenguajes orientados a objetos, tan comunes en la la codificación de los sistemas modernos.

Departamento de Computación UNAN - León

Page 19: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 19 de 316

3.1.5 Base de Datos I Esta asignatura tiene como objetivo fundamental dotar el estudiante de los conocimientos fundamentales en materia del diseño lógico de las bases de datos; para ello se estudian los elementos de gramatización, lenguajes de manipulación de datos, lenguajes de definición de datos y diversas técnicas que le permiten al estudiante evaluar un determinado diseño de base de datos. El contenido por temas de la asignatura es el siguiente: Tema No 1: Introducción a las Base de Datos: En este tema se estudian conceptos, historia y la evolución de las Base de Datos, con énfasis en la evolución de las Base de Datos en Nicaragua. Tema No 2: Diseño de Base de Datos: En este tema se estudia principalmente el diagrama Entidad – Relación: los elementos que lo conforman, las diversas representaciones gráficas que existen y ejemplos de utilización de un diagrama E-R en casos de la vida real. Tema No 3: Álgebra Relacional y Cálculo Relacional: En este tema se estudian conceptos del Álgebra Relacional y el Cálculo Relacional y las diferentes operaciones que éstos involucran. Mediante ejemplos de diagramas Entidad – Relación, se aplican diversas operaciones del Álgebra para mostrar la utilidad que tiene en la recuperación de la información. Tema No 4: Lenguaje de Definición y Manipulación de Datos: En este tema se estudian los conceptos de lo que es un Lenguaje de Definición y Manipulación de Datos; se estudia en particular el Lenguaje Estructurado de Consultas –SQL- y se muestran nuevamente, mediante un diagrama Entidad – Relación, ejemplos que primero se realizan con Álgebra Relacional y después se muestra la traducción directa al SQL. Tema No 5: Evaluación de Diseño de Base de Datos: En este tema se estudian las técnicas de evaluación de un diseño de Base de Datos; dichas técnicas son conocidas como Formas Normales. Esta asignatura es altamente importante para Análisis y Diseño de Sistemas de Información, porque proporciona los conocimientos necesarios para analizar y diseñar y evaluar un determinado sistema de gestión que involucran Bases de Datos.

Departamento de Computación UNAN - León

Page 20: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 20 de 316

3.1.6 Base de Datos II Esta asignatura tiene como objetivo fundamental dotar el estudiante de los conocimientos fundamentales en materia del diseño y modelado de una Base de Datos a nivel físico, y del estudio de las diferentes estructuras que se pueden implementar en una Base de Datos. Así mismo se muestra la implementación de archivos de Base de Datos, de Indices de Base de Datos y de Consultas y las diferentes técnicas de recuperación de un sistema de Base de Datos. El contenido por temas de la asignatura es el siguiente: Tema No 1: Almacenamiento y estructuras de Archivo de Base de Datos: En este tema se estudian las diferentes formas de almacenar un archivo de Base de Datos. Tema No 2: Indices estáticos e índices dinámicos: En este tema se estudian los diferentes tipos de índices que se pueden implementar en un sistema gestor de Base de Datos. Tema No 3: Recuperación del Sistema frente a fallos: En este tema se estudian las diferentes técnicas de recuperación que existen en un sistema gestor de Base de Datos. Tema No 4: Transacciones: En este tema se estudia el concepto de transacción y las siferentes tipos de transacciones en un sistema gestor de Base de Datos. Tema No 5: Control de concurrencia: En este tema se estudia el concepto de concurrencia y cómo inciden en el rendimiento de un sistema gestor de Base de Datos. Tema No 6: Base de Datos Distribuidas: En este tema se estudia el concepto de Base de Datos Distribuidas y los diferentes tipos de Base de Datos distribuidas que existen.

Departamento de Computación UNAN - León

Page 21: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 21 de 316

Asignatura consecuente de ADSI La asignatura Análisis y Diseño de Sistemas de Información, establece las bases para que el estudiante esté en capacidad de cursar la asignatura Ingeniería del Software, la cual se imparte en el segundo semestre de Quinto Año de la titulación. Una breve descripción gráfica de lo expuesto arriba se muestra en la Figura 3.1.1

Figura 3.1.2 Asignatura consecuente de ADSI.

3.1.7 Ingeniería del Software En esta asignatura se introduce al estudiante en la metodología de la Ingeniería del Software Orientada a Objetos se les facilitan los conceptos necesarios para el aprendizaje del lenguaje Unificado de modelado y se guia al estudiante en el uso de las herramientas de diseño orientado a objetos. El contenido por temas de la asignatura es el siguiente: Tema No 1: Introduccion a UML: En este tema se estudia una Introduccion al Lenguaje Unificado de Modelado (UML). Tema No 2: Fase de planeacion, analisis y diseño: En este tema se estudian los siguientes sub-temas:

• Especificacion de Requisitos. • Casos de Uso. • Diagramas de Casos de Uso.

Departamento de Computación UNAN - León

Page 22: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 22 de 316

• Construccion del Modelo Conceptual. • Agregacion de Asociaciones y atributos al Modelo Conceptual. • Diagramas de secuencia del sistema. • Contratos. • Descripcion de los Casos Reales de Uso. • Diagramas de Colaboracion.

Tema No 3: Modelado estructural basico: En este tema se estudian los siguientes sub-temas:

• Clases y Relaciones. • Mecanismos Comunes y Diagramas. • Diagramas de Clases y Diagramas de Objetos.

Tema No 4: Modelado estructural avanzado: En este tema se estudian los siguientes sub-temas:

• Características avanzadas de las Clases. • Características avanzadas de las Relaciones. • Paquetes. • Instancias.

Tema No 5: Modelado basico del comportamiento: En este tema se estudian los siguientes sub-temas:

• Diagrama de actividades. Tema No 6: Modelado avanzado del comportamiento: En este tema se estudian los siguientes sub-temas:

• Máquina de estados. • Diagramas de estados.

Tema No 7: Modelado arquitectonico: En este tema se estudian los siguientes sub-temas:

• Componentes. • Diagramas de Componentes, Despliegue y Diagramas de Despliegue. • Patrones.

Departamento de Computación UNAN - León

Page 23: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 23 de 316

4 METODOLOGÍA DIDÁCTICA Y MATERIAL DIDÁCTICO UTILIZADO

Podemos dividir la metodología didáctica y el material didáctico utilizado, de acuerdo a la clase teórica ya la clase práctica: METODOLOGÍA DIDÁCTICA Clase teórica: Para impartir los temas teóricos de esta asignatura, el método principal consiste en las lecciones magistrales, en las cuales se planificarán los apartados a desarrollar por medio de clases teóricas de dos horas de duración como máximo. La clase teórica es dialogada y los alumnos participan dando opiniones o pasando a la pizarra a resolver cuestiones. En estas clases teóricas, también se realizarán ejercicios prácticos relacionados con el tema teórico para una mejor comprensión del estudiante. De igual manera, se asignarán tareas grupales, que los estudiantes podrán resolver en el aula de clases o en horas extras de la clase, según lo indique el profesor. Clase práctica: La duración de cada clase práctica es de dos horas reloj. Para impartir las clases prácticas de esta asignatura, el método principal consiste en una exposición de la práctica a realizar, que tardará aproximadamente 45 minutos. En esta exposición, el profesor de la práctica explica todo lo relacionado con la realización de la práctica: objetivos, desarrollo, relación de la práctica actual con las prácticas anteriores (si las hubiera), funcionamiento, elementos software a utilizar, duración y fecha límite de entrega, etc. Durante la exposición del profesor, los alumnos pueden preguntar sobre cualquier aspecto relacionado con la realización de la práctica. Una vez que culmina la exposición, los alumnos comienzan a trabajar en el desarrollo de la práctica, pudiendo consultar al profesor cuando tengan alguna duda o inquietud. Cabe aclarar que, la exposición de la práctica por parte del profesor, se hará únicamente cuando se inice una nueva práctica. Las semanas de realización de la práctica, el profesor responderá dudas y hará aclaraciones sobre algún aspecto relevante de la práctica.

Departamento de Computación UNAN - León

Page 24: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 24 de 316

MATERIAL DIDÁCTICO A UTILIZAR Clase práctica: Con respeto al material didáctico, se usará retro proyector para proyectar las transparencias de cada tema, usando la pizarra cuando sea necesario ahondar en detalles acerca de algún gráfico o tabla. El material de estudio será las transparencias de la clase más documentación adicional (libros, revistas, tutoriales, etc). Dicho material se podrá adquirir de la página Web de la asignatura o directamente con el profesor o con la secretaria del departamento. Clase práctica: Con respecto al material didáctico de la clase práctica, se usará retroproyector para proyectar las transaparencias de la práctica. Se usará la pizarra para explicar con más detalle alguna parte de la práctica que lo requiera, o hacer alguna simulación del funcionamiento o desarrollo de la práctica. La clase práctica se lleva a cabo en los ordenadores de los laboratorios del Departamento. De acuerdo a la cantidad de estudiantes inscritos en el curso, cada ordenador podrá ser usado por uno o dos estudiantes cómo máximo. El software a utilizar estará instalado en los ordenadores, y también lo tendrá a disposición el profesor de la práctica, o en el sitio web o ftp de la asignatura. El alumno podrá también hacer uso de la bibliografía existente en el Departamento con el control respectivo.

Departamento de Computación UNAN - León

Page 25: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 25 de 316

5 PROCESO DE EVALUACIÓN La asignatura de Análisis y Diseño de Sistemas de Información está compuesta por clases teóricas y prácticas de laboratorios. Durante el semestre se realizan 2 evaluaciones parciales y por último un examen final o semestral. Las calificaciones obtenidas en las 2 evaluaciones parciales equivalen al 60% de la nota final, luego a esto se suma el 40% de la calificación obtenida en el examen final para obtener el 100% de la nota final de todo el curso. Una explicación gráfica del proceso de evaluación se puede ver en la Tabla 5.1

Tabla 5.1 Proceso de Evaluación

1Ex_Par 2Ex_Par Ex_Sem Nota_Final Ex_Teor 80 80 100 Ev_Lab 20 20 Total 100 100 100 Porcentaje 30% 30% 40% 100%

Otra manera de ver esto es siguiendo la siguiente fórmula: Nota_Final = ( ( 1Ex_Par + 2Ex_Par ) / 2 * ( 0.6 ) ) + ( Ex_Sem * 0.4 )

Departamento de Computación UNAN - León

Page 26: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 26 de 316

TTEEMMPPOORRIIZZAACCIIÓÓNN

Departamento de Computación UNAN - León

Page 27: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 27 de 316

6 TEMPORIZACIÓN La asignatura Análisis y Diseño de Sistemas de Información se imparte en el noveno semestre (primer semestre de quinto año) de la titulación Ingeniería en Sistemas de Información – ISI - ofrecida por el Departamento de Computación de la UNAN León. Cada semestre consta de 16 semanas lectivas. La asignatura consta de 6 horas semanales (4 de teoría y 2 de prácticas de laboratorio), resultando 64 horas teóricas y 32 horas prácticas para un total de 96 horas totales. Si tomamos en cuenta los días festivos y las semanas de realización de exámenes, la cantidad de semanas reales por semestre se reduce a 14, obteniendo ahora 56 horas de teoría y 28 horas de laboratorio respectivamente. Hay que recordar que cada sesión de clase teórica dura 2 horas reloj, así que por semana hay 2 sesiones teóricas de clase. La sesión del laboratorio también tiene una duración de 2 horas reloj, por lo que cada semana solamente hay una sesión de laboratorio. Una descripción general de la temporización del contenido teórico se muestra en la Tabla 6.1.

Tabla 6.1 Temporización general. Tema No

Nombre del Tema Duración del tema (en semanas)

Semana

0 Presentación de la asignatura. 1/2 1

1 Problemas de la gestión de la información. 1/2 1

2 Introducción al desarrollo de Sistemas de Información. 1 y 1/2 2

3

3 Técnicas de Recopilación de Datos. 1 y 1/2 3 4

4 Especificación de Requisitos Software - ERS 2 5

6

5 Métodos de análisis de requisitos: Análisis Estructurado. 3

7 8 9

6 Modelo Conceptual de Datos. 1 10

7 Fundamentos del Diseño Software. 1 y 1/2 11 12

8 Modelo Lógico de Datos. 1 y 1/2 12 13

9 Modelo Lógico de Tratamientos. 1 14 Total: 14 14

Departamento de Computación UNAN - León

Page 28: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 28 de 316

Una temporización más detallada de la parte teórica se muestra en laTabla 6.2

Tabla 6.2 Temporización detallada.

Semana Tema No

Clase No

Cant. Horas

Tema Contenido del tema

1 0 1 2 Presentación de la asignatura

Presentación de la asignatura

1 1 2 4 Problemas de la gestión de la Información.

-La información y su importancia. -El poder de la información -La información y la generación de riquezas. -La paradoja de la información -Administración de la información como recurso

2 2 3 6 Introducción al desarrollo de sistemas de información.

-Conceptos de Análisis y Diseño de Sistemas ¿Qué es un sistema? Sistemas de información -Categorías de los sistemas de información. -Usuarios de los sistemas de información

2 2 4 8 Introducción al desarrollo de sistemas de información.

-Introducción al desarrollo de sistemas de información. -Ciclo de vida de un sistema de información. -El análisis y diseño de sistemas. -Ejemplo.

3 2 5 10 Introducción al desarrollo de sistemas de información.

-Estrategia para el desarrollo de sistemas. -Ciclo de vida clásico del desarrollo de sistemas. -Método de Desarrollo de Prototipo.-Método de desarrollo del ciclo de vida estructurado.

3 3 6 12 Técnicas de recopilación de datos.

-Introducción. -La Entrevista. -La Observación.

4 3 7 14 Técnicas de recopilación de datos.

-El Cusestionario. -El Muestreo. .

4 4 8 16 Técnicas de recopilación de datos.

-El Muestreo. Diseño del muestreo.

Departamento de Computación UNAN - León

Page 29: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 29 de 316

Ejercicios para calcular el tamaño de la Muestra.

5 4 9 18 Especificación de Requisitos Software – ERS.

-¿Qué es una especificación de Requisitos Software? -Propiedades de un ERS. -Preparación del ERS

5 4 10 20 Especificación de Requisitos Software –ERS.

-Estructura de un ERS. -Inicio de la construcción de un ERS para una aplicación sencilla – Ejemplo 1.

6

4

11

22

Especificación de Requisitos Software –ERS.

-Estructura de un ERS. -Continuación del ERS para una aplicación sencilla – Ejemplo 1.

6

4

12

24

Especificación de Requisitos Software –ERS.

-Estructura de un ERS. - Construcción de un ERS para una aplicación sencilla – Ejemplo 1.

7

5

13 26 Métodos de análisis de requisitos: Análisis Estructurado.

-Análisis. -Análisis estructurado Historia Notaciones básicas

7 5 14 28 Métodos de análisis de requisitos: Análisis Estructurado.

-Diagramas de Flujo de Datos (DFD). -Elementos un DFD. -Mecánica del análisis estructurado. Creación de un modelo de flujo de datos.

8 5 15 30 Métodos de análisis de requisitos: AnálisisEstructurado.

-Ejemplo 1 de creación de un modelo de flujo de datos: “Gallo Pinto”.

8 5 16 32 Métodos de análisis de requisitos: Análisis Estructurado.

-Ejemplo 2 de creación de un modelo de flujo de datos: “Hogar Seguro”.

9 5 17 34 Métodos de análisis de requisitos: Análisis Estructurado.

-Ejemplo 3 de creación de un modelo de flujo de datos: “Empresa Comercializadora de Productos”.

9 5 18 36 Métodos de análisis de requisitos: Análisis Estructurado.

-Diccionario de Requisitos. - Formato del Diccionario de Re- quisitos. Definición de almacenes. Definición de Base de Datos.

Departamento de Computación UNAN - León

Page 30: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 30 de 316

Definición de base de datos tipo “Lista Invertida”. Definición de base de datos tipo “Jerárquica”. Definición de base de datos tipo “Red”. Definición de base de datos “Relacionales”. -Diccionario de datos mecanizado. -Análisis estructurado e Ingeniería del software asistida por computa- dora.

10 6 19 38 Modelo Conceptual de Datos.

-Método del diseño conceptual de datos. Determinación del conjunto de re- ferencia. Determinación de los conjuntos primarios. Determinación de los individuos y- Relaciones.

10 6 20 40 Modelo Conceptual de Datos.

Determinación de las cardinalida- des. Verificación del modelo concep- tual. Simplificación del modelo concep- tual. Determinación del modelo con- ceptual operativo. -Relaciones entre los conjuntos de individuos.

11 7 21 42 Fundamentos del Diseño Software.

-Introducción. -Ingeniería del software y diseño del Software. -Proceso de diseño. Diseño y calidad del software. Evolución del diseño del software. -Fundamentos del diseño. Abstracción. Refinamiento. Modularidad. Arquitectura del software. Jerarquía de control.

11 7 22 44 Fundamentos del Diseño Software.

-Fundamentos del diseño. Estructura de datos. Procedimientos del software. Ocultamiento de información.

Departamento de Computación UNAN - León

Page 31: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 31 de 316

-Diseño modular efectivo. Independencia funcional. Cohesión. Acoplamiento. -Diseño de datos. -Diseño arquitectónico.

12 7 23 46 Fundamentos del Diseño Software.

-Diseño procedimental. Herramientas de diseño. Programación estructurada. Notaciones gráficas de diseño. Notaciones tabulares de diseño. Lenguajes de diseño de progra- mas. -Diseño de Interfaz. Diseños de salidas. Diseños de entrada. Diseño de Menús.

12 8 24 48 Modelo Lógico de Datos.

-Introducción. -Modelo CODASYL. Reglas de elaboración del modelo CODASYL. Otras reglas. Reglas de transformación de un M.C.D en M.L.D CODASYL.

13 8 25 50 Modelo Lógico de Datos.

Aplicación al ejemplo recapitulati- vo. -Modelo Relacional. Conceptos del modelo relacional. Reglas de transformación de un M.C.D en un M.L.D relacional. Ejemplo. Aplicación al ejemplo recapitulati- vo.

13 8 26 52 Modelo Lógico de Datos.

-Caso de los ficheros clásicos. Introducción. Definiciones acerca de los fiche- ros. Reglas de Transformación de un M.C.D en un M.L.D de tipo ficheros clásicos. Ejemplo. Aplicación al ejemplo recapitulati- vo. -Enfoque general de optimización de un M.L.D.

Departamento de Computación UNAN - León

Page 32: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 32 de 316

14 9 27 54 Modelo Lógico de

Tratamiento. -Introducción. -Método de diseño coneceptual de tratamientos. Determinación del DFD de deta- lle. Eliminación de circuitos. Establecimiento de la matriz de incidencias. Diagrama de precedencia de procesos.

14 9 28 56 Modelo Lógico de Tratamiento.

Agrupación de procesos con el mismo orden externo. Diagrama de precedencia de operaciones. Determinación de la Red de Petri. Establecimiento de los diagra- mas de acción.

Departamento de Computación UNAN - León

Page 33: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 33 de 316

DDEESSAARRRROOLLLLOO DDEELL TTEEMMAARRIIOO

Departamento de Computación UNAN - León

Page 34: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 34 de 316

7 DESARROLLO DEL TEMARIO En esta sección se desarrollan los temas a impartir en Análisis y Diseño de Sistemas de Información. Se comienza a partir del tema uno, donde se refleja la importancia de saber gestionar la información, y luego se prosigue con el desarrollo de los demás temas.

7.1 Presentación de la Asignatura

TEMA N° 0

OBJETIVOS:

Dar a conocer al estudiante los aspectos relacionados a la docencia en general y horario de tutorías.

Explicar los objetivos generales de la asignatura, el temario y su distribución temporal, así como las relaciones de la misma con la carrera profesional de la titulación.

Exponer el método de enseñanza que se va a seguir durante el curso, los criterios de evaluación y la bibliografía necesaria.

Brindar detalles del modo de acceso a la documentación preparada por el profesor para la impartición de la asignatura.

CONTENIDO

Documento de presentación de la asignatura al alumno. Ver documento en la siguiente página.

Información sobre la organización de los grupos del laboratorio.

Acerca de las prácticas de Laboratorios: Todos los alumnos deben formar parte de un grupo para trabajar en el laboratorio; en total son 3 grupos, el horario de cada grupo se establecerá según la dirección del Departamento de Computación, y en ese momento se usará el documento de presentación del laboratorio en donde se le brindará todos los datos necesarios para la realización de éste. Dicho documento estará disponible en la página web del profesor y en la secretaría del Departamento de Computación. Se aclara que este documento estará presente en el proyecto en la sección de “Prácticas de Laboratorio”.

DURACIÓN: 2 HORAS.

Departamento de Computación UNAN - León

Page 35: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 35 de 316

OBJETIVOS DE LA ASIGNATURA

• Conocer las técnicas más adecuadas para resolver problemas informáticos, fundamentalmente aquellos relacionados con la gestión administrativa.

• Conocer las metodologías específicas relacionadas con el análisis

estructurado.

• Proporcionar los conocimientos necesarios para analizar aplicaciones específicas, con el fin de generar diseños óptimos y adecuados.

• Adquirir habiliades en el uso de herramientas CASE, con el fin de analizar

cada sistema con una presentación adecuada y tomando en cuenta todos los aspectos fundamentales de dicho análisis.

Departamento de Computación UNAN - León

Page 36: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 36 de 316

ASIGNATURA: ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN CURSO 2004 DEPARTAMENTO: COMPUTACIÓN – DC TITULACIÓN: INGENIERIA EN SISTEMAS DE INFORMACIÓN - ISI AÑO: V SEMESTRE: NOVENO PROFESOR: ALDO RENÉ MARTÍNEZ.

TEMARIO DE TEORÍA:

Tema 1: Problemas de la gestión de la Información

• La información y su importancia.

• El poder de la información.

• La información y la generación de riquezas.

• La paradoja de la información.

• Administración de la información co mo recurso.

Tema 2: Introducción al desarrollo de sistemas de información

• Conceptos de Análisis y Diseño de Sistemas.

• Categorías de los sistemas de información.

• Usuarios de los sistemas de información.

• Introducción al desarrollo de sistemas de información.

• Ciclo de vida de un sistema de infor mación.

• El análisis y diseño de sistemas.

• Ejemplo.

• Estrategia para el desarrollo de sistemas.

• Ciclo de vida clásico del desarrollo de sistemas.

• Método de Desarrollo de Prototipo.

• Método de desarrollo del ciclo de vida estructurado.

Tema 3: Técnicas de recopilación de datos.

• Introducción.

• La Entrevista.

• La Observación.

• El Cusestionario.

• El Muestreo.

• El Muestreo.

o Diseño del muestreo.

Departamento de Computación UNAN - León

Page 37: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 37 de 316

o Ejercicios para calcular el tamaño de la Muestra.

Tema 4: Especificación de Requisitos Software – ERS

• ¿Qué es una especificación de Requisitos Software?

• Propiedades de una Especificación de Requisitos Software.

• Preparación del ERS.

• Estructura de un ERS.

• Inicio de la construcción de un ERS para una aplicación sencilla

• Continuación del ERS para una aplicación sencilla.

Tema 5: Métodos de análisis de requisitos: Análisis Estructurado.

• Análisis.

• Análisis estructurado.

o Historia

o Notaciones básicas

• Diagramas de Flujo de Datos (DFD.)

• Mecánica del análisis estructurado.

o Creación de un modelo de flujo de datos.

• Ejemplo 1 de creación de un modelo de flujo de datos: “Gallo Pinto”.

• Ejemplo 2 de creación de un modelo de flujo de datos: “Hogar Seguro”.

• Ejemplo 3 de creación de un modelo de flujo de datos: “Empresa Comercializadora de Productos”.

• Diccionario de Requisitos.

o Formato del Diccionario de Requisitos.

o Definición de almacenes.

o Definición de Base de Datos.

o Definición de base de datos tipo “Lista Invertida”.

o Definición de base de datos tipo “Jerarquica”.

o Definición de base de datos tipo “Red”.

o Definición de base de datos “Relacionales”.

• Diccionario de datos mecanizado.

• Análisis estructurado e ingeniería del software asistida por computadoras.

Departamento de Computación UNAN - León

Page 38: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 38 de 316

Tema 6: Modelo conceptual de datos

• Método del diseño conceptual de datos.

o Determinación del conjunto de referencia.

o Determinación de los conjuntos primarios.

o Determinación de los individuos y Relaciones.

o Determinación de las cardinalidades.

o Verificación del modelo conceptual.

o Simplificación del modelo conceptual.

o Determinación del modelo conceptual operativo.

• Relaciones entre los conjuntos de individuos.

Tema 7: Fundamentos del Diseño Software

• Introducción.

• Ingeniería del software y diseño del Software.

• Proceso de diseño.

o Diseño y calidad del software.

o Evolución del diseño del software.

• Fundamentos del diseño.

o Abstracción.

o Refinamiento.

o Modularidad.

o Arquitectura del software.

o Jerarquía de control.

o Estructura de datos.

o Procedimientos del software.

o Ocultamiento de información.

• Diseño modular efectivo.

o Independencia funcional.

o Cohesión.

o Acoplamiento.

• Diseño de datos.

• Diseño arquitectónico.

• Diseño procedimental.

o Herramientas de diseño.

Departamento de Computación UNAN - León

Page 39: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 39 de 316

Programación estructurada.

Notaciones gráficas de diseño.

Notaciones tabulares de diseño.

Lenguajes de diseño de programas.

• Diseño de Interfaz.

o Diseños de salidas.

o Diseños de entrada.

o Diseño de menús.

Tema 8: Modelo Lógico de Datos

• Introducción.

• Modelo CODASYL.

o Reglas de elaboración del modelo CODASYL.

o Otras reglas.

o Reglas de transformación de un M.C.D en M.L.D CODASYL..

o Aplicación al ejemplo recapitulativo.

• Modelo Relacional.

o Conceptos del modelo relacional.

o Reglas de transformación de un M.C.D en un M.L.D relacional.

o Ejemplo.

o Aplicación al ejemplo recapitulativo.

• Caso de los ficheros clásicos.

o Introducción.

o Definiciones acerca de los ficheros.

o Reglas de Transformación de un M.C.D en un M.L.D de tipo ficheros clásicos.

o Ejemplo.

o Aplicación al ejemplo recapitulativo.

• Enfoque general de optimización de un M.L.D.

Tema 9: Modelo Lógico de Tratamiento

• Introducción.

• Método de diseño coneceptual de tratamientos.

o Determinación del DFD de detalle.

o Eliminación de circuitos.

o Establecimiento de la matriz de incidencias.

Departamento de Computación UNAN - León

Page 40: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 40 de 316

o Diagrama de precedencia de procesos.

o Agrupación de procesos con el mismo orden externo.

o Diagrama de precedencia de operaciones.

o Determinación de la Red de Petri.

o Establecimiento de los diagramas de acción.

MATERIAL DE ESTUDIO:

Transparencias y material de apoyo: http://www.isi.unanleon.edu.ni/~aldo/

Bibliografía (Teoría)

Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pearson Educación.

Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice Hall.

TUTORÍAS:

Despacho: Edificio de Ciencias - Segunda planta

Horario: Lunes 16:00 - 18:00

Martes 16:00 - 18:00

Correo: [email protected]

EVALUACIÓN DE LA ASIGNATURA:

Requisitos mínimos: Aprobar el examen de la asignatura y superar el laboratorio.

Cálculo de la nota final:

70% Examen 20% Laboratorio

Departamento de Computación UNAN - León

Page 41: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 41 de 316

PPRROOBBLLEEMMAASS DDEE LLAA GGEESSTTIIÓÓNN DDEE LLAA IINNFFOORRMMAACCIIÓÓNN

Departamento de Computación UNAN - León

Page 42: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 42 de 316

7.2 Problemas de la gestión de la información

Título del Tema 1: Problemas de la gestión de la Información

Objetivos: • Comprender la importancia de la información.

• Conocer de qué manera, mediante una buena administración de la información, se puede generar riquezas.

Contenido: • · La información y su importancia

• · El poder de la información

• · La información y la generación de riquezas

• · La paradoja de la información

• · Administración de la información como recurso

Duración: 2 horas Bibliografía básica:

• Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pearson Educación.

Departamento de Computación UNAN - León

Page 43: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 43 de 316

7.2.1 La información y su importancia En la era industrial (según James) lo más importante era el uso del capital, dinero y recursos tangibles, para generar nuevos productos. En el presente los recursos básicos son las ideas y el uso de la información. Según Kendal, desde hace mucho tiempo, las organizaciones han reconocido la importancia de una administración adecuada de los recursos básicos, tales como la mano de obra y las materias primas. Hasta ahora es cuando la información tiene una connotación del recurso primordial. La información se ha colocado en un lugar adecuado como recurso principal. Los responsables de la toma de decisión empiezan a comprender que la información ya no es sólo un producto subproducto de la conducción, sino que a la vez, alimenta los negocios y puede ser el factor crítico para la determinación del éxito o fracaso de un negocio. El mundo actual se caracteriza por un nivel extraordinario de automatización de los procesos tecnológicos e informativos, siendo esto un parámetro muy importante para medir el grado de desarrollo de determinado país. Un papel muy importante en el mismo ha sido desempeñado por los microprocesadores y sistemas computarizados modernos los que han contribuido a reducir laboriosidad, tiempo y costos de dichos procesos.

7.2.2 El poder de la información Iniciaremos partiendo que la información es poder. La mano de obra ocupada directamente en el procesamiento de la información supera la mano de obra destinada a la producción en los países desarrollados. Sin embargo la clave del éxito para que dicho poder sea efectivo, radica en su uso óptimo. Información que no se utiliza correctamente no tiene valor efectivo. La automatización se entiende como un conjunto de medios técnicos, matemáticos y programáticos tendentes a modernizar procesos informativos y tecnológicos (objeto de aplicación), en los cuales el hombre interactúa con los mismos ejerciendo su control y dirección. La combinación de la técnica de información con personas agrupadas para alcanzar objetivos determinados o para el control, forman el llamado sistema de información automatizado Una “base de datos” no es información. Es la materia prima de la información. Para que la materia prima se convierta en información tiene que ser organizada para una tarea, dirigida aun rendimiento específico, aplicada a una decisión.

Departamento de Computación UNAN - León

Page 44: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 44 de 316

7.2.3 La información para la creación de riqueza A las compañías les pagan por crear riquezas, no por controlar costos. Para ello se necesita información que les permita a los ejecutivos formar juicios bien fundados. Se requieren cuatro juegos de herramientas de diagnóstico:

• Información básica: ( proyecciones de flujos de fondos de liquidez, y medidas estándar tales como la razón entre inventario de dependencias y servicios ofrecidos, cuentas totales por cobrar, utilidades mensuales, etc ).

• Información de productividad de los recursos claves.

• Información sobre la competencia.

• Información sobre asignación de recursos: capital y personas

capaces.

7.2.4 La paradoja de la información Vivimos en medio de una paradoja. Las mismas personas se quejan de que reciben demasiado poco y excesivas cantidades de información. No podemos resolver la escasez mediante el recurso de producir más información ya que esto afectaría al segundo problema (superabundancia de información), tampoco podemos disminuir la cantidad de información producida debido a que ello incrementaría el primer problema (escasez). La respuesta a la paradoja es: estructura. La información es valiosa en la medida en que esté estructurada. Debido a la falta de estructura en la creación, distribución y recepción de la información, ésta a menudo no llega donde se le necesita siendo por lo tanto inútil. Es muy difícil para nosotros encontrar una pieza de información en una pila amorfa de papeles. Es aún mas difícil hacer frente a los millones de piezas informativas que recibimos en forma intangible a través de los modernos medios electrónicos. La paradoja de que hay simultáneamente demasiado poca o excesiva información se crea debido a que los métodos de procesamiento de información que hemos aprendido son inadecuados a los acelerados crecimientos de los volúmenes informativos y la rápida tasa de transformación en los medios que se procesa la información.

Departamento de Computación UNAN - León

Page 45: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 45 de 316

7.2.5 Administración de la información como recurso Con el fin de lograr la máxima utilidad de la información, un negocio debe manejar la información correctamente, tal como maneja los demás recursos. Los administradores necesitan comprender que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de la información. Aunque la información se encuentra siempre a nuestro alcance, ésta no es gratis, y su uso es estratégico para posicionar la competitividad de un negocio. La fácil disponibilidad de las computadoras ha creado una explosión de información a través de la sociedad en general y de los negocios en particular. El manejo de información generada por computadora difiere en forma significativa del manejo de datos producidos manualmente. Por lo general hay mayor cantidad de información de computadora a administrar. El costo de organizarla y mantenerla puede crecer a tasas alarmantes, y los usuarios frecuentemente la tratan menos escépticamente que la información obtenida por otras vías.

Departamento de Computación UNAN - León

Page 46: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 46 de 316

IINNTTRROODDUUCCCCIIÓÓNN AALL DDEESSAARRRROOLLLLOO

DDEE SSIISSTTEEMMAASS DDEE IINNFFOORRMMAACCIIÓÓNN

Departamento de Computación UNAN - León

Page 47: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 47 de 316

7.3 Introducción al desarrollo de sistemas de información

Título del tema 2: Introducción al desarrollo de sistemas de información.

Objetivos: • Comprender la diferencia entre sistema y sistema de información.

• Conocer cómo se clasifican los sistemas de información.

• Comprender el papel de los usuarios dentro un sistema de inforamación.

• Comprender las fases del ciclo de vida de desarrollo de sistemas.

• Entender el método de desarrollo del prototipo del sistema.

• Entender el método de desarrollo del ciclo de vida estructurado.

Contenido: • Conceptos de Análisis y Diseño de Sistemas

• Categorías de los sistemas de información

• Usuarios de los sistemas de información

• Introducción al desarrollo de sistemas de información

• Ciclo de vida de un sistema de información

• El análisis y diseño de sistemas

• Estrategias para el desarrollo de sistemas

• Ciclo de vida clásico del desarrollo de sistemas ( Según Kendall y Kendall)

• Método del desarrollo de Prototipo

• Método de desarrollo del ciclo de vida estructurado. (Según James)

Duración:

• 4 horas

Bibliografía básica: • Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición.

Pearson Educación.

Departamento de Computación UNAN - León

Page 48: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 48 de 316

• Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice Hall.

Departamento de Computación UNAN - León

Page 49: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 49 de 316

7.3.1 Conceptos de Análisis y Diseño de Sistemas Los sistemas de información son desarrollados con propósitos diferentes dependiendo de las necesidades del negocio.

7.3.1.1 Qué es un Sistema Según James: En el sentido más amplio, un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. Nuestra sociedad está rodeada de sistemas.

• Sistema nervioso (Las personas experimentan sensaciones físicas, frío, calor, etc.) (cerebro médula espinal, los nervios y las células sensoriales)

• El lenguaje, sistema formado por palabras y símbolos.

• Sistema económico (intercambios de bienes y servicios)

7.3.1.2 Sistemas de información Las finalidades de los sistemas de información, como los de cualquier otro sistema dentro de una organización, es la de procesar entradas, mantener archivos de datos relacionados con la organización y producir información, reportes y otras salidas. Los sistemas de información están formados por subsistemas que incluyen hardware, software, medios de almacenamiento de datos para archivos y bases de datos. El conjunto particular de subsistemas utilizados (equipo específico, programas, archivos y procedimientos) es lo que se denomina una aplicación de sistemas de información. De esta forma, los sistemas de información pueden tener aplicaciones en ventas, contabilidad o compras.

Departamento de Computación UNAN - León

Page 50: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 50 de 316

7.3.2 Categorías de los sistemas de información Según Kendall, los sistemas de información se desarrollan con diferentes propósitos para satisfacer las diferentes necesidades de una empresa. Los sistemas de información se pueden categorizar así:

a) Sistemas de procesamiento de transacciones (TPS).

Se desarrollan para procesar grandes volúmenes de información para transacciones rutinarias del negocio, generadas en las funciones administrativas, tales como nómina, inventarios, facturación, entrega de mercancías, depósitos de cheques. Las TPS eliminan el tedio de las transacciones operacionales necesarias y reducen el tiempo que alguna vez se requirió para ejecutarlas manualmente.

b) Sistemas de automatización de oficina y sistemas de manejo de conocimiento.

Al nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la información para analizarla y transformar datos o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organización y algunas veces mas allá de ella. Los aspectos familiares de los OAS incluyen procesamiento de palabras, hojas de cálculos, editor de publicaciones, calendarización electrónica y comunicación mediante correo de voz, correo electrónico y video conferencias.

Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como científicos, ingenieros y doctores, les ayudan a crear un nuevo conocimiento que contribuya a la organización o a toda la sociedad.

c) Sistemas de información gerencial (MIS).

No reemplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de información computarizada que trabajan debido a la interacción resuelta entre las personas y las computadoras. Requieren que las gentes, el software y el hardware trabajen al unísono. Los sistemas de información dan soporte a un espectro más amplio de tareas organizacionales que los sistemas de procesamiento de transacciones, incluyendo el análisis de decisiones y la toma de decisiones.

Para poder ligar la información, los usuarios de un sistema de información gerencial comparten una base de datos común. La base de datos guarda

Departamento de Computación UNAN - León

Page 51: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 51 de 316

modelos que ayudan a los usuarios a interpretar y aplicar esos mismos datos. Los sistemas de información gerencial producen información que es usada en la toma de decisiones.

d) Sistemas de apoyo para la toma de decisiones (DSS).

Es similar a los sistemas de información tradicionales para la administración, en el sentido de que ambos dependen de una base de datos como fuente de información. Un DSS se aparta del MIS tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisión actual todavía es del dominio del tomador de decisiones. Los sistemas de apoyo a decisiones están más hechos a la medida de la persona o grupo que los usa que los sistemas de información gerencial tradicionales.

e) Sistemas expertos e inteligencia artificial (IA).

La inteligencia artificial puede ser considerada la meta de los sistemas expertos. El empuje general de la IA ha sido desarrollar máquinas que se comporten de forma inteligente. Dos caminos de la investigación de la IA son la comprensión del lenguaje natural y el análisis de la habilidad para razonar un problema y llegar a conclusiones lógicas. Los sistemas de expertos usan los enfoques del razonamiento de la IA para resolver los problemas que les plantean los usuarios de negocios.

Los sistemas expertos son un caso muy especial de un sistema de información, cuyo uso ha sido factible para los negocios a partir de la reciente y amplia disponibilidad de hardware y software tal como las microcomputadoras y sistemas expertos. Un sistema experto (también llamado un sistema basado en el conocimiento); captura; y utiliza, el conocimiento de un experto, para resolver un problema particular experimentado en una organización. La diferencia con el DSS, es que este deja la decisión final al tomador de decisiones, un sistema experto selecciona la mejor solución a un problema o a una clase específica de problemas.

f) Sistemas de apoyo a decisiones de grupo (GDSS).

Cuando los grupos necesitan trabajar juntos para tomar decisiones semiestructuradas o sin estructurar, un sistema de apoyo a decisiones de grupo puede plantear una solución. Los sistemas de apoyo a decisiones de grupo (GDSS) son usados en cuartos especiales, equipados en varias configuraciones diferentes, que permiten que los miembros del grupo interactúen con apoyo electrónico, frecuentemente en forma de software especializado y con una persona que da facilidades al grupo. Los sistemas para decisiones de grupo están orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios apoyos

Departamento de Computación UNAN - León

Page 52: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 52 de 316

como votaciones, cuestionarios, aportación de ideas y creación de escenarios. El software GDSS puede ser diseñado para minimizar el comportamiento negativo típico de un grupo, tal como la falta de participación debido al miedo a represiones por expresar un punto de vista no popular o conflictivo, dominación por miembros del grupo con voz dominante y la toma de decisiones de “pensamiento en grupo”.

g) Sistemas de apoyo a ejecutivos (ESS).

Cuando los ejecutivos se acercan a la computadora, frecuentemente están buscando formas que les ayuden a tomar decisiones a nivel estratégico. Un sistema de apoyo a ejecutivos (ESS) ayuda a éstos, para organizar sus interacciones con el ambiente externo, proporcionando apoyo de gráficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas. Aunque los ESS se apoyan en la información generada por los TPS y los MIS, los sistemas de apoyo a ejecutivos ayudan a sus usuarios a que ataquen problemas de decisión sin estructuras, que no son específicos de una aplicación, creando un ambiente que ayude a pensar acerca de los problemas estratégicos de una manera informada. Los ESS extienden y dan apoyo a las capacidades de los ejecutivos para encontrar sentido en sus ambientes.

7.3.3 Quienes son los usuarios? (James) Son los gerentes, directores y empleados de una organización que interactuan con los sistemas de información. Los tipos de usuarios, según el grado de participación, se clasifican en:

1. Usuario final directo (usuarios primarios): los que interactuan con el sistema (operadores).

2. Usuario final indirecto (usuarios indirectos): son los que se benefician

de los resultados o reportes generados por el sistema pero no operan el equipo (Ej: gerente mercadotecnia, etc.)

3. Administrador (gerente): controla las actividades del sistema (supervisar

la inversión).

4. Directivos: (aprueba los usos estratégicos y evalúan los riesgos).

Departamento de Computación UNAN - León

Page 53: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 53 de 316

7.3.4 Preguntas

1. Describa por qué es mas útil pensar sobre la información como un recurso de la organización en vez de un subproducto de la organización.

R: Es útil pensar en la información como un recurso más de la organización, porque al considerarla como tal, se le establecen las mismas prioridades que a los demás recursos; es decir, los administradores compreden que hay costos asociados con la producción, distribución, seguridad, almacenamiento y recuperación de ese nuevo recurso que es la información. Cuando el administrador tiene conciencia de esto, existe previamente, una planificación lógica y económica destinada a la gestión eficiente de la información. Esto es muy importante porque al momento de elaborar el presupuesto para la empresa, ya se tienen en cuenta los costos asociados a la administración correcta de la información; esto a la postre, evita improvisaciones de carácter lógico - económico al momento de intentar paliar alguna situación anómala originada por el incorrecto manejo de la información.

De lo dicho anteriormente, se deriva una consecuencia lógica: si se invierten recursos económicos y humanos para gestionar correctamente otro recurso (la información), el tomador de decisiones debe tener en cuenta que esto redundará en beneficios para la empresa; ya que al tener un acceso oportuno y eficiente a la información que se genera en la empresa, esto puede ser usado estratégicamente para situar a la empresa en un lugar competitivo.

2. Explique mediante un ejemplo de la vida real, cúal es la utilidad de considerar la información como un recurso.

R: Pensemos por ejemplo, en una empresa que se dedica a la fabricación de hielo en diferentes formas: marquetas de tamaño variable y bolsas de cubitos. Dicha empresa no tenía ninguno de sus procesos automatizados: llevaba manualmente los procesos contables, de inventario, las encuestas de opinión, etc. La empresa era totalmente desconocida y sus ventas apenas alcanzaban para el pago de sus 5 empleados incluyendo el gerente. El gerente decidió comprar más equipos de refrigeración para aumentar la producción de hielo, hacerse de un camión repartidor extra, y contratar a 4 personas más. Con esta inversión, el gerente pensaba en aumentar sus ganancias. La contabilidad creció y el inventario se hizo cada vez más difícil de manejar. Los informes de ventas se hacían cada vez más extensos y esto origino una lentitud general en el funcionamiento de la empresa. El resultado era que aunque se producía más hielo, las ganancias eran las mismas, porque las decisiones que el gerente debía tomar, no las tomaba por carcer de información precisa. El gerente no podía tener información rápida y a su gusto. Todo esto pasó porque nunca pensaron en tratar a la información que se generaba en la empresa, como un recurso más al que le debían de asignar prioridades cómo a los demás, y en la que debían invertir dinero y

Departamento de Computación UNAN - León

Page 54: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 54 de 316

capital humano. Una vez que la Empresa decidió automatizar todos sus procesos y a considerar la información como un recurso para generar ganancias, la empresa pasó a ser competitiva

3. Defina lo que significa un sistema de procesamiento de transacciones.

R: Los sistemas de procesamiento de transacciones (TPS), sosn sistemas de información automatizados desarrollados para procesar grandes volúmenes de información para transacciones rutinarias del negocio, generadas en las funciones administrativas, tales como nómina, inventarios, facturación, entrega de mercancías, depósitos de cheques

4. Explique la diferencia entre los sistemas de automatización de oficina (OAS) y los sistemas de manejo de conocimiento (KWS).

R: La diferencia es clara: los sistemas de automatización de oficina (OAS) incluyen aspectos como procesamiento de palabras, hojas de cálculos, editor de publicaciones, calendarización electrónica y comunicación mediante correo de voz, correo electrónico y videoconferencias. Dichos OAS dan soporte a los trabajadores de datos; estos trabajadores de datos, por lo general, no crean un nuevo conocimiento, sino que usan la información para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organización

En cambio, los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como científicos, ingenieros y doctores, y les ayudan a crear un nuevo conocimiento que contribuya a la organización o a toda la sociedad.

5. Compare la definición de sistema de información gerencial (MIS) con la definición de sistema de apoyo a decisiones. (DSS).

R: Los MIS son sistemas de información computarizada que trabajan debido a la interacción resuelta entre gentes y computadoras. Los sistemas de información gerencial producen información que es usada en la toma de decisiones. Los DSS se apartan del sistema de información gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisión actual todavía es del dominio del tomador de decisiones. La diferencia entre ambas es la utilidad que tienen en cada una al momento de tomar la decisión: en el primero, requieres que las gentes trabajen al unísono y se presenta una una fase de la toma de decisiones; en el segundo, se enfatiza el apoyo a la toma de decisiones en todas sus fases y está más orientado a la persona que los usa o grupo que lo usa.

Departamento de Computación UNAN - León

Page 55: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 55 de 316

6. Defina el término sistema de expertos. ¿En qué difieren los sistemas expertos de los sistemas de apoyo a decisiones?

R: Un sistema experto (también llamado un sistema basado en el conocimiento); captura; y utiliza, el conocimiento de un experto, para resolver un problema particular experimentado en una organización. La diferencia con el DSS, es que este deja la decisión final al tomador de decisiones, un sistema experto selecciona la mejor solución a un problema o a una clase específica de problemas.

7. Liste los problemas de interacción de grupo para los que fueron diseñados los sistemas de apoyo a decisiones de grupo (GDSS).

R: Los problemas de interacción de grupo que han sido identificados son:

• Falta de participación. • Dominación por miembros del grupo con voz dominantes. • La toma de decisiones de “pensamiento en grupo”.

Departamento de Computación UNAN - León

Page 56: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 56 de 316

7.3.5 Introducción al desarrollo de Sistemas de Información Los sistemas de información ocupan ahora un sitio especial en las empresas donde facilitan la operación eficiente de oficinas de reservación de aerolíneas, departamento de archivos clínicos en hospitales, funciones de contabilidad y nómina, banca electrónica, sistemas de conmutación telefónica, etc.

7.3.6 Ciclo de vida de un Sistema de Información Es el uso de un ciclo específico de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. Las fases de desarrollo de un sistema, aunque son presentadas en forma discreta, nunca se lleva a cabo como un paso aparte. En vez de ello, varias actividades pueden suceder simultáneamente, y las actividades pueden ser repetidas. (con actividades traslapándose y luego disminuyendo). Las fases son las siguientes:

1. Identificación de problemas, oportunidades y objetivos.

Esta etapa es crítica para el éxito del resto de proyecto, debido a que nadie quiere desperdiciar el tiempo subsecuente resolviendo el problema equivocado.

La primera fase requiere que el analista observe honestamente lo que está sucediendo en un negocio. Luego, junto con los demás miembros de la organización, el analista hace resaltar los problemas.

Las oportunidades son situaciones que el analista considera que pueden ser mejoradas por medio del uso de sistemas de información computarizados. El aprovechar las oportunidades puede permitir que el negocio gane un avance competitivo o ponga un estándar de la industria.

La identificación de objetivos es también un componente importante de la primera fase. En primer lugar el analista, debe descubrir lo que está tratando de hacer el negocio. Luego será capaz de ver si algún aspecto de la aplicación de sistemas de información puede ayudar para que el negocio alcance sus objetivos atacando problemas específicos u oportunidades.

Las personas involucradas en la primera fase son los usuarios, analistas y administradores de sistemas que coordinan el proyecto. Las actividades de es fase consisten en entrevistas a los administradores de los usuarios, sumarización del conocimiento obtenido, estimación del alcance del proyecto y documentación de los resultados. La salida de esta fase es

Departamento de Computación UNAN - León

Page 57: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 57 de 316

un estudio de factibilidad que contiene una definición del problema y la sumarización de los objetivos.

2. Determinación de los requerimientos de información.

La siguiente fase a la que entra el analista es la de la determinación de los requerimientos de información para los usuarios particulares involucrados. Entre las herramientas utilizadas para definir los requerimientos de información en el negocio se encuentran: muestreo e investigación de los datos relevantes, entrevistas, cuestionarios, el comportamiento de los tomadores de decisiones y su ambiente de oficina y hasta la elaboración de prototipos.

En esta fase el analista está esforzándose por comprender qué información necesitan los usuarios para realizar su trabajo.

El analista de sistema necesita saber los detalles de las funciones actuales del sistema: quién (las personas que están involucradas), qué (la actividad del negocio), dónde (el ambiente donde se lleva a cabo el trabajo), cuándo (en qué momento) y cómo (de que manera) se desarrollan los procedimientos actuales del negocio bajo estudio.

Al término de esta fase, el analista debe comprender el por qué de las funciones del negocio y tener información completa sobre las personas, objetivos, datos y procedimientos involucrados.

3. Análisis de las necesidades del sistema.

La siguiente fase que realiza el analista de sistemas involucra el análisis de las necesidades del sistema. Nuevamente, herramientas y técnicas especiales ayudan para que el analista haga las determinaciones de los requerimientos. Una herramienta de éstas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones del negocio en forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos, que lista todos los conceptos de datos usados en el sistema, así como sus especificaciones, si son alfanuméricos y qué tanto espacio ocupan cuando se imprimen.

Durante esta fase el analista de sistemas también analiza las decisiones estructuradas que se hacen. Las decisiones estructuradas son aquellas para las que pueden ser determinadas las condiciones como alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de decisiones estructurales: lenguaje estructurado, tablas de decisión y árboles de decisión.

Departamento de Computación UNAN - León

Page 58: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 58 de 316

4. Diseño del sistema recomendado

En esta fase, el analista usa la información recolectada anteriormente para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos, a fin de que los datos que van a entrar al sistema de información sean correctos. Además, el analista también proporciona entrada efectiva para el sistema de información mediante el uso de técnicas para el buen diseño de formas y pantalla. Parte del diseño lógico del sistema de información es diseñar la interfaz de usuario. La interfaz conecta al usuario con el sistema y es, por lo tanto, extremadamente importante.

La fase de diseño también incluye el diseño de archivos o bases de datos que guardarán la mayor parte de los datos necesarios por los tomadores de decisiones de la organización. Una base de datos bien organizada es la base para todos los sistemas de información. En esta fase, el analista también trabaja con los usuarios para diseñar la salida (ya sea en pantalla o impresora) que satisfaga sus necesidades de información.

Por último el analista debe de diseñar procedimientos de control y respaldo para proteger al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener diseños de entrada y salida, especificaciones de archivos y detalles de procedimiento, y también puede incluir árboles o tablas de decisión, diagramas de flujo de datos, un diagrama de flujo del sistema y los nombres y funciones de cualquier de las rutinas de código que ya hayan sido escritas.

5. Desarrollo y documentación del software

En la quinta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los programadores para desarrollar cualquier software original que se necesite. Algunas de las técnicas estructuradas para el diseño y documentación de software incluyen diagramas estructurados, el método HIPO, diagramas de flujo, diagramas Nassi-Schneiderman y y Warnier-Orr y seudocódigo. El analista usa uno o más de estos dispositivos para comunicar al programador lo que necesita ser programado.

Durante esta fase, el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, incluyendo manuales de procedimientos. La documentación le dice al usuario la manera de usar el software y también qué hacer si se suceden problemas con el software.

Departamento de Computación UNAN - León

Page 59: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 59 de 316

6. Pruebas y mantenimiento del sistema

Antes de que pueda ser usado, el sistema de información debe ser probado. Es mucho menos costoso encontrar problemas antes de que el sistema sea entregado a los usuarios. Algunas de las pruebas son realizadas por los programadores solos, y otras por los analistas de sistemas junto con los programadores. Primero se ejecuta una serie de pruebas para que destaquen los problemas con datos de ejemplo y eventualmente con datos reales del sistema actual.

El mantenimiento del sistema y de su documentación comienza en esta fase y es efectuado rutinariamente a lo largo de la vida del sistema de información. Mucho del trabajo rutinario del programador consiste en el mantenimiento, ya que los negocios gastan gran cantidad de dinero en dicho mantenimiento. Muchos de los procedimientos sistemáticos que emplea el analista a lo largo del ciclo de vida del desarrollo del sistema pueden ayudar a asegurar que el mantenimiento se mantenga al mínimo.

7. Implementación y evaluación del sistema

En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de información. Esto incluye el entrenamiento de los usuarios para que manejen el sistema. Algún entrenamiento es hecho por los proveedores, pero la supervisión del entrenamiento es responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para una conversión suave del sistema antiguo al nuevo. Este proceso incluye la conversión de archivos de formatos antiguos a nuevos o la construcción de una base de datos, la instalación de equipo y la puesta del nuevo sistema en producción.

La evaluación se muestra como parte de esta fase final de ciclo de vida del desarrollo de sistema, principalmente para efectos de discusión. De hecho, la evaluación se realiza durante cada fase. Un criterio principal que debe ser satisfecho es si los usuarios pretendidos ya están usando el sistema.

Departamento de Computación UNAN - León

Page 60: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 60 de 316

7.3.7 El analisis y diseño de sistemas. (James) Se refiere al proceso de examinar la situación de una empresa con el propósito de mejorarle con métodos y procedimientos más adecuados. Analisis de sistemas: Es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de la información para recomendar mejoras al sistema. Diseño de sistemas: Es el proceso de planificar, reemplazar o complementar un sistema organizacional existente. Sin embargo antes de llevar a cabo estas actividades, es necesario comprender en su totalidad, el viejo sistema y determinar la mejor forma en que se pueden hacer las operaciones más eficientes.

7.3.7.1 Ejemplo: Considere por ejemplo las operaciones del almacén de una tienda de ropa. Para tener mejor control del inventario y acceso a información más actualizada con respecto a los niveles de inventario y abastecimiento, la empresa solicita a un analista de sistemas "computarizar" todas las operaciones del almacén. ¿Que debe hacer el analista? Respuesta:

• Primero necesita averiguar más acerca de cómo opera el almacén, con qué documentación cuenta (requisiciones, pedidos, facturas) para guardar la información normalmente y qué informe, si es que los hay, se producen y cómo se emplean.

• Buscar información relacionada con las listas de reabastecimiento,

pedidos pendientes, registros manuales del almacén y otros reportes. Dónde se origina esta información. El analista debe comprender cómo trabaja el sistema actual y el flujo de información en todo el sistema.

• El Analista necesita saber los motivos que tiene la tienda para cambiar su

modo de operación:

¿Tiene la empresa problemas con el surtido de pedidos, con la mercancía o con el dinero?

¿Se rezaga el registro de inventario?

¿Se necesita un sistema más eficiente como registro previo para poder aumentar el número de operación?

Departamento de Computación UNAN - León

Page 61: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 61 de 316

Sólo después de haber reunido todos los hechos, el analista se encuentra en la posición de determinar cómo y dónde un sistema de información basado en computadora será benéfico para todos los usuarios, del sistema. Esta acumulación de información, denominada Estudio del sistema, es la que precede a todas las demás actividades del análisis. James, resume así: El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo.

Departamento de Computación UNAN - León

Page 62: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 62 de 316

7.3.8 Estrategia para el desarrollo de sistemas En algunos casos, los factores que deben considerarse en un proyecto de sistemas de información tales como el aspecto más apropiado de la computadora o la tecnología de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características específicas que el sistema debe tener, se pueden determinar de una manera secuencial. Hay tres métodos o enfoques de las estrategias de desarrollo de sistemas de información basados en computadora:

1. Método del ciclo de vida para el desarrollo de sistemas (SDLC) (Systems Development Life Cicle).

2. Método del desarrollo del análisis estructurado.

3. Método del prototipo de sistemas.

Si va a desarrollar un sistema por cualquiera de los métodos o combinación de estos, primero es necesario revisar la solicitud de proyecto, revisar si es factible o no, para esto hay que desarrollar una investigación preliminar:

a. Aclarar y comprender la solicitud del proyecto.

b. Determinar el tamaño del proyecto.

c. Evaluar los costos y beneficios de diversas opciones.

d. Determinar la factibilidad técnica y operacional de las diferentes alternativas.

e. Formular recomendaciones que esbocen la aceptación o rechazo de la propuesta.

7.3.9 Ciclo de vida clásico del desarrollo de sistemas. Según James A. Senn, consta de las siguientes fases:

1. Investigación preliminar 2. Determinación de los requerimientos del sistema 3. Diseño del sistema 4. Desarrollo de Software 5. Prueba de los sistemas 6. Implantación y evaluación.

Departamento de Computación UNAN - León

Page 63: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 63 de 316

Explicación de cada una de las fases:

1. Investigación preliminar

Es la primera actividad para el desarrollo de un sistema y consta de tres partes:

a. Aclaración de la solicitud.

b. Estudio de factibilidad; el cual tiene tres aspectos:

• Factibilidad técnica: Si el sistema se puede desarrollar con el

equipo y software actual. Qué se necesita. El analista debe encontrar si los recursos técnicos actuales pueden ser mejorados o añadidos, en forma tal que satisfagan la petición bajo consideración.

• Factibilidad Económica: En este tipo de factibilidad, los

recuros básicos a considerar son el tiempo propio y el del equipo de sistemas, el costo de hacer un estudio de sistema completo (incluyendo el tiempo de los empleados con los que se trabajará), el costo del tiempo de los empleados del negocio, el costo estimado del software y/o desarrollo de software. El negocio de que se trate deberá ser capaz de hacer ver el valor de la inversión en su ponderación antes de comprometerse a un estudio de sistemas completos. Si los costos a corto plazo no son sobrepasados por las ganancias a largo plazo, o no producen una reducción inmediata en los costos de operación, el sistema no es factible económicamente y el proyecto no debe ya continuar.

• Factibilidad operacional: Supongamos por un momento que

se juzguen adecuados los recursos técnicos y económicos. El analista de sistemas deberá todavía considerar la factibilidad operacional del proyecto solicitado. La factibilidad operacional depende de los recursos humanos disponibles para el proyecto, e involucra proyectar si el sistema operará y será usado una vez que esté instalado.

Si los usuarios están virtualmente casados con el sistema presente, no ven problemas con él y, por lo general, no están involucrados en la petición de un nuevo sistema, la resitencia ante la implementación del nuevo sistema será fuerte. Las oportunidades de que alguna vez llegue a ser operacional son escasas. En forma alterna, si los usuarios han expresado la necesidad de que un sistema que es operacional la mayor parte del tiempo tegna una forma más eficiente y accesible, se tiene mejor

Departamento de Computación UNAN - León

Page 64: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 64 de 316

oportunidad de que el sistema solicitado llegue a ser utilizado. Mucho del arte de la determinación de la facftibiliad operacional se encuentra en las interfaces de usuario que se escogen.

c. Aprobación de la solicitud.

2. Determinación de los requerimientos del sistema

Con frecuencia se denomina investigación detallada, y contempla los siguientes aspectos:

• Qué es lo que se hace.

• Cómo se hace.

• Con qué frecuencia se presenta.

• Qué tan grande es el volumen de transacciones

• Cuál es el grado de eficiencia con el que se efectúan los temas.

• Existe algún problema. Qué tan serio es.

• Cuál es la causa.

Todo esto se recopila con los empleados y administradores.

3. Diseño del sistema

Indica cómo se cumplirán con los requerimientos identificados en la fase anterior.

Se especifican los reportes de salida, pantalla de estradas, procedimientos de cálculos, estructura de archivo, etc.

4. Desarrollo de Software

Se procede a escribir los programas. Lo mismo que se prepara la documentación, lo es escencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicación se encuentra instalada.

Departamento de Computación UNAN - León

Page 65: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 65 de 316

5. Prueba de sistemas

El sistema se emplea de manera experimental para asegurarse de que el software no tenga fallos.

6. Implementación y evaluación

Es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.

Dependiendo del caso y de la empresa, se puede iniciar de forma progresiva en algunos departamentos, que trabajan de forma paralela los dos sistemas o un día determinado deja de funcionar el viejo para iniciar con el nuevo.

Departamento de Computación UNAN - León

Page 66: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 66 de 316

7.3.10 Método del Prototipo de Sistema Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño. La construcción de prototipos es muy eficaz bajo las circunstancias correctas. El método es útil sólo si se emplea en el momento adecuado y en la forma adecuada.

7.3.10.1 ¿Qué es un prototipo? El prototipo es un sistema que funciona, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Es la primera versión de un sistema de información, es el modelo original. Los usuarios evalúan el diseño y la información generada por el sistema.

7.3.10.2 Razones para desarrollar prototipos de sistemas Los requerimientos de información no siempre están bien definidos. Es probable que los usuarios conozcan sólo ciertas áreas de la empresa donde se necesitan mejoras o cambios en los procedimientos actuales. También es posible que reconozcan la necesidad de tener mejor información para administrar ciertas actividades, pero que no están seguros cuál de esta información será la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aún al formular el diseño. Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e implementar sistemas no tienen información ni experiencia o también donde existen situaciones de riesgo y costos elevados, y aquellos donde el diseño propuesto es novedoso y aún no ha sido probado. El prototipo es en realidad, un modelo piloto ó de prueba; el diseño evoluciona con el uso.

7.3.10.3 Condiciones para aplicar el método de prototipo En general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:

• Los encargados de diseñar e implementar sistemas nunca han desarrollado uno con las características del sistema propuesto.

• Se conoce una parte de las características esenciales del sistema; las demás

no son identificables a pesar de un cuidadoso análisis de requerimientos.

Departamento de Computación UNAN - León

Page 67: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 67 de 316

• La experiencia con el uso del sistema añadirá una lista significativa de

requerimientos que el sistema debe satisfacer.

• Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus características.

• Los usuarios del sistema participan en el proceso de desarrollo.

7.3.10.4 Pasos para el desarrollo de prototipos En general, los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:

1. Identificar los requerimientos de información que el usuario conoce junto con las características necesarias del sistema.

2. Desarrollar un prototipo que funcione.

3. Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto

amplia la lista de los requerimientos de sistemas conocidos.

4. Revisar el prototipo en base a la información obtenida a través de la experiencia del usuario.

5. Repetir los pasos anteriores las veces que sea necesario, hasta obtener un

sistema satisfactorio. Cuando el usuario y el analista deciden que cuentan ya con la suficiente información proveniente del proceso de construcción del Prototipo, optan por una de las siguientes cuatro opciones:

1. Volver a desarrollar el prototipo. 2. Implantar el prototipo como sistema terminado. 3. Abandonar el proyecto. 4. Iniciar otra serie de construcción de prototipos.

Departamento de Computación UNAN - León

Page 68: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 68 de 316

7.3.11 Método de desarrollo del ciclo de vida estructurado Las dificultades de comprender de manera completa sistemas grandes y complejos, es lo que se trata de superar con este sistema, por medio de:

• La división del sistema en componentes. • La construcción de un modelo del sistema.

En este modelo del ciclo de vida existen tres entidades externas que son: los usuarios, el director y las operaciones del personal. Por entidad externa se entiende un individuo o grupo de individuos que proporcionan entradas al equipo del proyecto, y que son los últimos receptores del sistema. En el modelo estructurado se han identificado nueve tareas principales:

1. Estudio de factibilidad 2. Análisis del sistema 3. Diseño 4. Implementación 5. Generación de la prueba de aceptación. 6. Asegurar la calidad del producto 7. Descripción de procedimientos 8. Conversión de las bases de datos 9. Instalación

Lo más importante es notar que una actividad no tiene que esperar necesariamente a que se haya completado la anterior. Se pueden realizar en paralelo. En casos extremos, el que exista ciertos sucesos, puede desencadenar la terminación brusca del proyecto.

7.3.11.1 ¿Qué es el análisis estructurado? El Análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. No se establece cómo se cumplirán los requerimientos o la forma en que implantará la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistema de almacenamiento, etc.)

Departamento de Computación UNAN - León

Page 69: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 69 de 316

7.3.11.2 Elementos del Análisis Estructurado Los elementos esenciales del análisis estructurado son símbolos gráficos, diagramas de flujos de datos y el diccionario centralizado de datos.

7.3.11.3 Descripción gráfica Una de las formas de escribir un sistema es preparar un bosquejo que señale sus características, identifique la función para la que sirve e indique como este interactúa con otros elementos, entre otras cosas. Sin embargo, describir de esta manera un sistema grande es un proceso tedioso y propenso a errores. En lugar de las palabras el análisis estructurado utiliza símbolos o íconos para crear un modelo gráfico del sistema.

7.3.11.4 El diagrama lógico de flujo de datos Muestra las fuentes y destino de los datos, identifica y da nombre a los procesos que se llevan a cabo, identifica y da nombre a los grupos de datos que relacionan una función con otra y señala los almacenes de datos a los que se tiene acceso. Un ejemplo de lo dicho anteriormente se puede ver en la Figura 7.3.1 :

0

Procesamientode Pedido

ClienteDatos

Pedidos

del Inventario

Movimientoproducto

Facturas

Informaciónproducto

.3.11.5 Diagrama de flujos de datos

l nombre de diagrama de flujo de datos (DFD). La escripción completa de un sistema está formada por un conjunto de diagramas de

flujo de datos.

Figura 7.3.1 Ejemplo de un DFD de nivel de contexto.

7 El modelo del sistema recibe ed

Departamento de Computación UNAN - León

Page 70: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 70 de 316

Para desarrollar una descripción del sistema por el método de análisis estructurado se sigue un proceso descendente (top-down). Cada proceso puede desglosarse en iagramas de flujo de datos cada vez más detallados.

nen suficientes detalles que permiten al

nalista comprender en su totalidad la parte del sistema que se encuentra bajo

a meta del diseño estructurado es crear programas formados por módulos dependientes unos de otros desde el punto de vista funcional. Este enfoque no

solo conduce hacia mejores programas sino que facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo. La herramienta fundamental del diseño estructurado es el diagrama estructurado. Al igual que los diagramas de flujos de datos, los diagramas estructurados son de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas. Los diagramas estructurados describen las interacciones entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

d

Esta secuencia se repite hasta que se obtieainvestigación.

7.3.11.6 Diccionario de Datos Todas las definiciones de los elementos en el sistema (flujo de datos, procesos y almacenes de datos) están descritas en forma detallada en el diccionario de datos.

7.3.11.7 ¿Qué es el diseño estructurado? Lin

Departamento de Computación UNAN - León

Page 71: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 71 de 316

7.3.12 Preguntas de autoevaluación del Tema 2 (Introducción al desarrollo de Sistemas de Información)

El siguiente es la solución al primer examen parcial de Análisis y Diseño de Sistemas de Información, de Abril del 2004.

Universidad Nacional Autónoma de Nicaragua-León Facultad de Ciencias

Departamento de Computacion

Primer Examen Parcial de Análisis y Diseño de Sistemas de Información Apellidos: _______________________ Nombre: __________________________ Carnet: _____________ I. COMPLETAR.

a) La respuesta a la paradoja de la información es: ESTRUCTURAR

b) SISTEMA es un conjunto de componentes que interaccionan entre si para lograr un objetivo común.

c) La estrategia de desarrollo de S.I que hace que el usuario participe de

manera más directa es: PROTOTIPO. II. CONTESTE FALSO (F) O VERDADERO (V) SEGUN EL CASO.

a) El Diseño especifica que es lo que debe hacer el sistema. ___F____.

b) En la metodología del ciclo de vida estructurado se trata de superar las dificultades de comprender de manera completa sistemas grandes y complejos ___V____.

c) Las finalidades de los sistemas de información, como las de cualquier

otro sistema dentro de una organización, es la de procesar entradas, mantener archivos de datos relacionados con la organización y producir información, reportes y otras salidas.___V___

d) Un prototipo es un documento que detalla de forma completa un

S.I.___F___

Departamento de Computación UNAN - León

Page 72: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 72 de 316

III. ENGLOBAR LA RESPUESTA CORRECTA:

1) El poder de la información radica en:

a) En la abundancia de información. b) La cantidad de mano de obra ocupada directamente en el

procesamiento de la información.

c) En su uso optimo d) La poca información

2) Una de las siguientes afirmaciones no es correcta:

a) Los sistemas de procesamiento de transacciones se desarrollan para procesar grandes volúmenes de información para transacciones rutinarias del negocio.

b) El sistema de apoyo para la toma de decisiones está más hecho

a la medida de la persona que los usa.

c) Un sistema es un conjunto de componentes que interaccionan

entre si. d) Los sistemas de expertos e inteligencia artificial recurren a los

datos almacenados en el sistema de procesamiento de datos.

3) Una de las siguientes afirmaciones es correcta:

a) El Análisis especifica cómo es que se debe hacer el sistema. b) El ciclo de vida de un Sistema es el conjunto de actividades que

se realizan para desarrollar un sistema de información.

c) Existen 4 estrategias básicas para desarrollar Sistemas de

Información. d) Los sistemas de información han jugado un papel

preponderante en las empresas desde la era industrial.

Departamento de Computación UNAN - León

Page 73: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 73 de 316

4) Una de las siguientes afirmaciones es correcta:

a) El diseño precede a la fase de análisis. b) Realizar el análisis de factibilidad para desarrollar un sistema de

información no es muy importante.

c) La estrategia para el desarrollo de un sistema depende

principalmente del problema a automatizar. d) Un prototipo es un sistema que se desarrolla hasta la etapa de

diseño para que los usuarios lo completen. IV. EXPLIQUE:

a) En que se basa la metodología del Ciclo de Vida Clásico (En cascada). Explique brevemente.

R: SU METODOLOGÍA CONSISTE EN IR REALIZANDO CADA FASE DE FORMA COMPLETA Y NO PASAR A LA SIGUIENTE FASE SIN HABER TERMINADO LA ANTERIOR.

b) Explique cómo se puede realizar la fase de implementación de un Sistema de Información.

R: INCLUYE EL ENTRENAMIENTO A LOS USUARIOS.

UN PLAN PARA LA CONVERSIÓN SUAVE DEL SISTEMA ANTIGUO AL NUEVO.

CONVERSIÓN DE ARCHIVOS DE FORMATOS ANTIGUOS A NUEVOS O CONSTRUCCIÓN DE BASE DE DATOS, INSTALACIÓN DE EQUIPO.

SE PUEDE INICIAR FORMA PROGRESIVA, DE FORMA PARALELA. UN DIA DEJA DE FUNCIONAR EL VIEJO PARA INICIAR CON EL NUEVO.

Departamento de Computación UNAN - León

Page 74: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 74 de 316

c) Defina el término sistema de expertos.

R: LOS SISTEMAS DE EXPERTOS SON UN CASO MUY ESPECIAL DE UN SISTEMA DE INFORMACIÓN. UN SISTEMA DE EXPERTOS TAMBIEN LLAMADO SISTEMAS BASADO EN EL CONOCIMIENTO; CAPTURA Y EN EFECTO UTILIZA EL CONOCIMIENTO DE UN EXPERTO. LOS SISTEMAS DE EXPERTOS USAN LOS ENFOQUES DEL RAZONAMIENTO DE LA INTELIGENCIA ARTIFICIAL PARA RESOLVER LOS PROBLEMAS.

Departamento de Computación UNAN - León

Page 75: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 75 de 316

TTÉÉCCNNIICCAASS DDEE RREECCOOPPIILLAACCIIÓÓNN DDEE

DDAATTOOSS

Departamento de Computación UNAN - León

Page 76: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 76 de 316

7.4 Técnicas de recopilación de datos

Título del tema 3: Técnicas de recopilación de datos.

Objetivos: • Comprender la necesidad que tienen los analistas de utilizar métodos

específicos, para encontrar datos.

• Dar a conocer las diferentes técnicas de recopilación de datos y su importancia en cada caso.

Contenido: • Introducción.

• La Entrevista.

• La Observación.

• El Cusestionario.

• El Muestreo.

Duración: • 6 horas

Bibliografía básica:

• Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pearson Educación.

• Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

Departamento de Computación UNAN - León

Page 77: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 77 de 316

7.4.1 Introducción de “instrumentos de datos” Los analistas utilizan métodos específicos denominados técnicas para encontrar hechos (datos), con el objeto de reunir datos relacionados con los requerimientos. Entre éstos se incluyen la entrevista, el cuestionario, el muestreo, la observación. Es muy importante tener en cuenta que como resultado del análisis de los requerimientos debe desarrollarse el documento de especificación de requerimiento. Este contiene definiciones abstractas de los componentes del software ó sea es necesario que la especificación indique lo que debe hacer el software.

7.4.2 Entrevista Una entrevista para la recopilación es una conversación dirigida con un propósito específico, que se basa en un formato de preguntas y respuestas. En la entrevista se desea conocer tanto las opiniones como los sentimientos del entrevistado acerca del estado actual del sistema, sus metas personales, de la organización y de los procedimientos informales. Antes de todo, hay que observar las opiniones de la persona a la que está entrevistando. Las opiniones pueden ser más importantes y más reveladoras que los hechos. También podrá determinar el grado de optimismo imperante. Las metas son una fuente importante de información. Debe contar con una buena planeación de la entrevista. En la entrevista se está estableciendo una relación con alguien que probablemente es un extraño para usted, se necesita dar confianza y comprensión rápidamente, pero al mismo tiempo, se debe mantener el control de la entrevista. También se necesita vender el sistema, proporcionando la información necesaria al entrevistado. La manera para comenzar hacer esto es planear la entrevista antes de ir a ella.

Departamento de Computación UNAN - León

Page 78: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 78 de 316

7.4.2.1 Planeacion de la entrevista La planeación de la entrevista consta de cinco pasos:

1. Lectura de antecedentes: explorar de ante mano la organización, aprovechar al máximo el tiempo de la entrevista, más que desperdiciarlo al hacer preguntas generales sobre los antecedentes.

2. Establecimiento de los objetivos de la entrevista: se establecen

los objetivos de la entrevista en base a la información que se recopiló en los antecedentes que consulte y en su experiencia particular.

3. Selección de los entrevistados: Cuando decida a quienes

entrevistar incluya gente clave en todos los niveles.

4. Preparación del entrevistado: Prepare a la persona que entrevistará, avisando con tiempo para que pueda pensar acerca de la entrevista.

5. Selección del tipo y estructura de las preguntas: La esencia de la

entrevista se basa en el uso de técnicas inquisitivas adecuadas. Las entrevistas deben ser de 45 minutos a una hora, a lo mucho.

Los dos tipos básicos de pregunta son:

• Las abiertas • Las cerradas

Los patrones pueden ser

• Estructura de pirámide • Estructura de embudo • Estructura de diamantes

7.4.2.2 Tipos de preguntas

7.4.2.2.1 Preguntas abiertas Son las opciones que el entrevistado tiene para responder. Ventajas:

1. Simplifica las cosas para el entrevistado.

2. Permite al entrevistador seleccionar el vocabulario del entrevistado lo que refleja su educación, valor y creencia.

3. Proporciona una gran riqueza de detalles.

Departamento de Computación UNAN - León

Page 79: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 79 de 316

4. Revela nueva entrevista sobre preguntas no considerada.

5. Hacer más interesante la entrevista.

6. Permite mayor espontaneidad.

7. Facilita el estilo del entrevistador sin interrumpirlo.

8. Se utilizan como una alternativa cuando el entrevistado no se

encuentra preparado. Desventajas

1. Permiten preguntas que puedan generar demasiada información.

2. Posible pérdida del control de la entrevista.

3. Permite respuesta que puedan llevar mucho tiempo para la cantidad de información que aporta.

4. Pueda dar la apariencia que el entrevistador no se preparó.

7.4.2.2.2 Preguntas cerradas Limita las repuestas disponibles del entrevistado. Un tipo especial de pregunta cerrada es la pregunta bipolar; ésta es aún más limitada al tener solo dos repuestas alternativas tales como si o no, falso o verdadero, acuerdo en desacuerdo. Ventajas

1. Se ahorra tiempo.

2. Se facilita la cooperación de las entrevistas.

3. Se llegar al punto de interés.

4. Se mantiene el control de la entrevista.

5. Se tratan muchos temas rápidamente.

6. Se obtienen datos relevantes.

Departamento de Computación UNAN - León

Page 80: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 80 de 316

Desventajas

1. Aburren al entrevistado.

2. Pierden la riqueza del detalle.

3. Se puede perder ideas centrales por el punto anterior.

4. No favorecen un clima de armonía entre el entrevistado y el entrevistador.

7.4.2.3 Patrones Así como hay dos formas reconocidas generalmente para razonar, inductiva y deductiva, hay dos formas similares para organizar las entrevistas. Una tercera forma combina ambos patrones, inductivo y deductivo.

a. La organización -infraestructura- de la entrevista puede concebirse como una pirámide.

Debe utilizar la estructura piramidal cuando crea que su entrevistado requiere de introducción hacia el tópico. También es útil el uso de una estructura piramidal para encadenar preguntas cuando desee llegar a una conclusión del tópico. El entrevistador comienza con preguntas muy detalladas y frecuentemente cerradas. El entrevistador luego expande el tema permitiendo preguntas abiertas y respuestas más generalizadas.

b. Uso de la estructura en embudo

El entrevistado forma el enfoque deductivo, comenzando con preguntas generales y abiertas y estrechando las respuestas posibles usando preguntas cerradas. El uso de una estructura en embudo facilita el inicio de entrevista sin comprometerle. Es útil cuando el entrevistado está involucrado sentimentalmente con el tópico y necesita cierta libertad para expresar sus emociones. Este tipo de estructura organiza la entrevista.

c. Estructura en forma de diamante (rombo)

Es mejor una combinación de dos estructuras lo que da por resultado una entrevista con estructura en forma de diamante. Esto conlleva el comenzar en una forma muy específica, luego examinar temas generales y por último llegar a una conclusión muy específica. El entrevistador comienza con preguntas cerradas fáciles que

Departamento de Computación UNAN - León

Page 81: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 81 de 316

proporcionan un calentamiento al proceso de la entrevista. A la mitad de la entrevista, se le pide al entrevistado, opiniones sobre temas amplios, que obviamente no tienen una respuesta correcta. Luego el entrevistador estrecha las preguntas nuevamente para hacer que se respondan preguntas específicas. La estructura de diamante tiene como inconveniente que requiere más tiempo. La principal ventaja de usarla es que mantiene interés y la atención de su entrevistado, mediante la variedad de preguntas.

7.4.2.4 Realización de la entrevista Comienzo de la entrevista

• Estreche la mano de su entrevistado, repita su nombre, plantee el motivo de su presencia y la razón de haberle escogido.

• Verifique que todo la que utiliza está en orden.

• Se comienza con preguntas generales abiertas.

• Controlar el uso del tiempo a fin de mantener un balance adecuado de la

entrevista.

7.4.2.5 Solución de problemas durante la entrevista Existen ocho problemas que bloquean la habilidad de respuesta del entrevistado; ellas son:

1. Percibir que la autoestima del entrevistado se encuentra amenazada. 2. Reacciones emotivas a temas conflictivos. 3. Malos entendidos respecto a la sucesión de los acontecimientos. 4. Apego a las formas sociales tradicionales. 5. Equívocos al inferir sobre lo observado. 6. Competencia por el tiempo. 7. Olvido de hechos importantes. 8. Mentir para ocultar hechos importantes.

Departamento de Computación UNAN - León

Page 82: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 82 de 316

1. Percepción de que la autoestima del entrevistado se encuentra amenazada.

Esto ocurre si aparenta ser superior o desafía la opinión del entrevistado; ante ciertos temas centrales el entrevistado puede negarse a contestar o bien tratar de demostrar que es superior a usted. Ofrezca su disculpa por su intromisión. Plantee de otra manera sus preguntas refiriéndose a terceras personas.

2. Reacción emotiva a temas conflictivos

Experiencias traumáticas, y las emociones asociadas con ellas renacen cuando las induce una frase particular. Para manejar de manera adecuada una reacción emotiva, dé usted por terminada la discusión del tema; o bien, dirija la conversación hacia el tema que sugiera la entrevista.

3. Mal entendido respecto a la sucecion de los acontecimientos

Esto ocurre cuando el entrevistado confunde el orden correcto de los acontecimientos en el tiempo. Una forma de corregir o evitar malentendidos en la secuencia de los acontecimientos, consiste en llevar a cabo investigaciones de los hecho antes de la entrevista.

4. Apegos a formas sociales tradicionales

Apegarse a las formas sociales tradicionales puede llegar a crear obstáculos en las respuestas de su entrevistado. Es conveniente entonces modificar el texto de alguna pregunta o mencionarla posteriormente y asegurar a su entrevistado que conviene mantener un enfoque franco y honesto.

5. Equívocos al inferir sobre lo observado

Este error ocurre cuando su entrevistado observe algo pero infiere en otra cosa. Cuando sospeche que las observaciones son sustituidas por las deducciones entonces escudriñe el origen de las conclusiones de su entrevistado. Evite la aceptación de deducciones en lugar de las observaciones.

Departamento de Computación UNAN - León

Page 83: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 83 de 316

6. Competencia por el tiempo

Ocurre cuando hay competencia por el tiempo de la entrevista. Puede darse cuenta de cuán ocupado estén los miembros de la organización, cuando intenta programar sus entrevistas. Proponga una programación o quizás de una disculpa y sugiera una llamada telefónica posterior para establecer una entrevista más formal.

7. Olvidos de hechos importantes

Puede decirse que sus entrevistados han caído en el olvido, cuando vacilan continuamente o se contradicen a lo largo de la entrevista. Una manera de manejar la situación es retroalimentarlos mediante su impresión de que, parece que ha pasado mucho tiempo desde la última vez que se discutió tal punto. Otra forma de manejar el problema del olvido es averiguar y corroborar los hechos a partir de la información de archivo, de otra entrevista y de la observación.

8. Mentir para ocultar hechos importantes

La falsedad de los entrevistados es una amenaza final que afecta la utilidad de la información contenida en la entrevista. La mejor defensa ante alguien que miente en una entrevista es una buena ofensiva. Esto es, crear una atmósfera de confianza con el entrevistado.

7.4.2.6 Conclusión de la entrevista Todo el material de la entrevista debe cubrirse en un periodo de 45 minutos a una hora y esta altura, ya estará consciente de la planeación y del manejo requerido para lograrlo. Esté pendiente de la hora y concluya su entrevista en el momento prometido. Durante la entrevista repita algunas de las respuestas de su entrevistado para verificar que comprendió lo que quiso expresar. Al concluir la entrevista, habrá que seguir otos procedimientos. Resuma y retro alimente sus impresiones globales.

Departamento de Computación UNAN - León

Page 84: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 84 de 316

7.4.2.7 Redacción del informe de la entrevista Es indispensable que escriba el informe tan pronto ha concluido la entrevista. Cuando escriba sus impresiones de la entrevista, mantenga una secuencia escrupulosa de los acontecimientos. No deje de evaluar su desempeño personal durante la entrevista. Revise con su entrevistado el informe de la entrevista, en una reunión de seguimiento.

Departamento de Computación UNAN - León

Page 85: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 85 de 316

7.4.3 Observación

7.4.3.1 Tipos de Información buscada. La observación, tanto del tomador de decisiones como del ambiente físico de éste son técnicas importantes de recopilación de información para el analista de sistema. Mediante la observación de las actividades de los tomadores de decisiones, el analista busca obtener una percepción de lo que realmente se hace y no sólo de lo que está documentado o explicado. Además, al observar al tomador de decisiones, el analista intenta ver de primera mano las relaciones que existen entre éstos y los demás miembros de la organización. Mediante la observación del ambiente de oficina, el analista de sistema busca el significado simbólico del contexto de trabajo de los tomadores de decisiones. El analista examina los elementos físicos del espacio de trabajo del tomador para ver su influencia sobre el comportamiento del mismo. Además, mediante la observación de los elementos físicos sobre los que el tomador de decisiones tiene control (vestimenta, posición del escritorio, etc.), el analista trabaja para comprender qué mensaje está enviando este tomador de decisiones. Por último, mediante la observación, el analista trabaja para comprender la influencia del tomador de decisiones sobre los demás en la organización

7.4.3.2 Observación del comportamiento del tomador de decisiones. Hay tres razones por las cuales la observación de la organización es útil para el analista de sistema:

1. Obtener información sobre los tomadores de decisiones y su ambiente.

2. Auxilia a confirmar lo que las entrevistas y los cuestionarios hubieran

detectado.

3. Rebatir o anular lo que otros métodos encontraron. La observación debe ser estructurada y sistemática. Por ello es fundamental que el analista de sistema esté consciente de lo que observa. Debe tener gran cuidado y reflexionar sobre qué y quienes fueran sujeto de observación así como dónde, porqué, cómo.

Departamento de Computación UNAN - León

Page 86: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 86 de 316

7.4.3.3 Esquemas observacionales

• Observación de las actividades de toma de decisiones del gerente típico

Los pasos que ayudan al analista a identificar las actividades típicas de toma de decisiones de un gerente son:

1. Decidir qué observará.

2. Decidir el nivel de concreción de las actividades (Es decir si el

gerente comparte sin restricción a sus subordinados toda la información o envía una copia del mismo memorando a tres de sus subordinados).

3. Crear categorías que capturen de manera adecuada las

actividades claves.

4. Preparar escalas apropiadas, lista de verificación u otros materiales para la observación.

5. Decidir cuándo observar.

• Muestro de tiempo y Eventos

El muestreo por tiempo permite que el analista defina períodos o intervalos específicos en los cuales observar las actividades de los gerentes. Por ejemplo, puede especificar la observación de un tomador de decisiones durante 5 intervalos de 10 minutos, escogidos al azar a lo largo de 7 días de 8 horas. El muestreo por eventos está dirigido por eventos completos tales como reunión de consejo. El muestreo de eventos proporciona observaciones sobre un comportamiento integro en su contexto natural.

7.4.3.4 Ventajas y Desventajas de los Muestreos Ventajas del Muestreo por tiempo

1. Minimización de la parcialidad aleatorizando las observaciones. 2. Permite una concepción representativa de las actividades más

frecuentes.

Departamento de Computación UNAN - León

Page 87: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 87 de 316

Desventajas del muestreo por tiempo

1. Recopilar fragmentos de datos que no da tiempo para toma de decisiones.

2. Se pierden decisiones poco frecuentes, aunque importante.

Ventajas del muestreo por eventos

1. Permite la observación del comportamiento conforme este se expresa. 2. Permite la observación de eventos considerados importante.

Desventajas del muestreo por eventos

1. El analista pierde tiempo considerable. 2. Se pierden muestras representativas de las decisiones más

frecuentes. Ejemplo de observación usando pares de objetivos:

Nombre del Observador: Juan Pérez Tomador de Decisiones: Bill Fecha de Observación: 21/04/04 Observado desde: 8 am a 8:.30 am De cada par encierre en un círculo el adjetivo que describa mejor al tomador de decisiones durante el tiempo de la observación:

1. Enérgico / No Enérgico 2. Calmado / Exitado 3. Creíble / No creible 4. Extrovertido / Introvertido 5. Parlanchin / Silencioso 6. Congruente / Incongruente 7. Conocedor / Desinformado 8. Emprendedor / No motivado 9. Decidido / Indeciso 10. Resolvedor de problemas / Causante de problemas

Departamento de Computación UNAN - León

Page 88: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 88 de 316

7.4.3.5 Observación del Lenguaje Corporal del tomador de decisiones Los analistas de sistemas inconscientemente observan el lenguaje corporal durante la entrevista aunque es muy difícil la interpretación precisa movimiento por movimiento.

7.4.3.6 Oservación del ambiente físico El ambiente físico en el cual se desempeña su actividad los tomadores de decisiones, también revela sus requerimientos de información. Esto implica examinar de manera sistemática la oficina de un tomador de decisiones, al ser ésta su sitio principal de trabajo.

7.4.3.7 Observación estructurada del ambiente Al método de observación estructurada del ambiente se denomina: STROBE (Structure Observation of the Enviroment) Es un método sistemático porque proporciona un método y clasificación estándar para el análisis de los elementos de la organización que participa en la toma de decisiones. Permite que cualquier otro analista de sistema aplique la misma estructura analista a la misma organización. Limita el análisis de la organización de su existencia en la etapa actual de su ciclo de vida. Elementos STROBE Hay 7 elementos concretos que son fácilmente observables por el analista de sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo.

1. Ubicación de la oficina

Las oficinas accesibles tienden a incrementar la frecuencia de relación y las comunicaciones informales, mientras aquellas oficinas inaccesibles tienden a reducir las relaciones y a incrementar los mensajes orientados a la tarea.

2. Ubicación del escritorio del tomador de decisiones

Este puede dar indicios del ejercicio de autoridad del tomador de decisiones. Los analistas de sistemas deben de notar el arreglo del mobiliario de la oficina, en particular la posición del escritorio.

Departamento de Computación UNAN - León

Page 89: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 89 de 316

3. Equipo de fijo de oficina

Archivadora, librero, todo aquel mobiliario para almacenar artículos se incluye en la categoría de equipo fijo de oficina. Si hay una abundancia de equipos es presumible que el tomador de decisiones almacene y valore mucha información.

4. Artículos personales

Son todos aquellos que se utilizan para procesar información. La presencia de calculadoras, plumas, reglas y terminales de video sugerirá que el tomador de decisiones las usas personalmente a diferencia de otro que tiene que salir de la oficina para utilizarlo.

5. Revistas y periódicos del negocio

Un analista necesita conocer el tipo de información que utiliza el tomador de decisiones, esto indicará el tipo de información que es usada por el tomador de decisiones.

6. Iluminación y color de la oficina

Estos parámetros desempeñan un papel importante en la manera en que el tomador de decisiones obtiene la información. Un ejecutivo obtendrá mayor información del carácter informal dentro de una oficina cálida. Mientras que otro que trabaja en una oficina con iluminación brillante y colores fuertes recibe información mediante memorándums y otros informes oficiales.

7. Vestimenta del tomador de decisiones

Los ejecutivos con trajes masculinos formales de tres piezas y los trajes sastres femeninos representan la máxima autoridad. La presentación informal abre las puertas para la toma de decisiones más participativa pero con frecuencia, si predominan los valores tradicionales coacciona cierta perdida de credibilidad dentro de la organización. Mediante el uso de STROBE , el analista de sistemas logra una mayor comprensión de como los gerentes obtienen , procesan , almacenan y utilizan la información.

Departamento de Computación UNAN - León

Page 90: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 90 de 316

7.4.4 El cuestionario Los cuestionarios constituyen una técnica de recopilación de información que permite a los analistas de sistemas recoger opiniones, posturas, conductas y características de las diversas personas clave de una organización. Un cuestionario sirve para sondear una gran muestra de usuarios de sistema con el fin de detectar problemas, o bien, tener presente aspectos importantes, antes de la programación de un sistema de entrevista. Existen grandes similitudes entre las técnicas ENTREVISTA Y CUESTIONARIO, y talvez la idea seria utilizarlas en conjunto; ya sea darles seguimiento a formas ambiguas de un cuestionario, o para el diseño de cuestionarios basados en los resultados de una entrevista sin embargo, cada técnica tiene funciones particulares y no siempre es necesario el uso de ambas técnicas.

7.4.4.1 Planeacion para el uso del cuestionario Los cuestionarios pueden verse como una forma rápida de recopilar cantidades masivas de datos acerca de la opinión de los usuarios al sistema actual, que problemas experimentan ellos en su trabajo y que es lo que esperan del sistema nuevo o modificado. El desarrollo de un cuestionario útil se lleva un gran tiempo de planeación. Lo primero que debe definirse ES QUÉ BUSCA con un cuestionario. La conveniencia de los cuestionarios requiere de:

1. Las personas a quienes necesita interrogar se encuentren muy dispersa.

2. El porcentaje de ese grupo aprobando o desaprobando las

características particulares del sistema.

3. Desea medir la opinión general.

4. Sondear los problemas para identificarlos y darles seguimiento.

7.4.4.2 Definición de Preguntas El analista de sistema al formular las preguntas debe hacer que estas sean completamente transparente, el flujo del cuestionario convincente, se debe anticipar las respuestas de las preguntas que se utilizan en el cuestionario sea planificado con todo detalle.

Departamento de Computación UNAN - León

Page 91: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 91 de 316

Los tipos de preguntas que se utilizan en el cuestionario así como en las entrevistas son:

• Preguntas abiertas • Preguntas cerradas

• Preguntas abiertas

Es necesario recordar que las preguntas abiertas (o enunciados), son aquellos que permiten al entrevistado cualquier opción de respuestas. Ejemplo. “Describa cualquier problema que esté teniendo actualmente con los reportes de salida”. Cuando redacta preguntas abiertas para un cuestionario, se anticipa al tipo de respuesta que piensa obtener. Es importante que las respuestas que reciba puedan interpretarse correctamente, de otra manera, se desperdiciarían recursos importantes en el desarrollo, la aplicación y la interpretación de un cuestionario inútil. No se puede formular preguntas que apunten a respuestas muy extensas, amplias que nos llevarían a un problema serio a la hora de hacer la interpretación y comparación precisa. De tal forma, que cuando redacte preguntas abiertas, sea suficientemente preciso para guiar a quien responda el cuestionario. Estas son adecuadas, en especial, en aquellas circunstancias que se desea conocer la opinión de los miembros de una organización sobre algunos aspectos del sistema.

• Preguntas cerradas

Son aquellas que limitan o restringen el número disponible de opciones de quien responde el cuestionario. Las preguntas cerradas pueden solicitar que se responda marcando recuadros:

1. Que se cierre con un círculo el número. 2. Que se encierre la respuesta.

Al elaborar preguntas cerradas se debe tomar en cuenta que las respuestas planteadas deben ser mutuamente exclusivas, de forma tal que al elegir una de ellas no implique la elección de ninguna otra. Las preguntas cerradas se recomiendan cuando se requiera explorar una gran muestra de personas. Ejemplo:

Departamento de Computación UNAN - León

Page 92: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 92 de 316

Estudia usted actualmente? ( ) Sí ( ) No

Hay preguntas cerradas, donde el respondiente puede seleccionar más de una opción o categoría de respuesta. Ejemplo:

Esta familia tiene: ( ) Radio? ( ) Televisión? ( ) Videocasetera? ( ) Teléfono? ( ) Automóvil o camioneta? ( ) Ninguno de los anteriores

Algunos respondientes pudieran marcar una, dos, tres, cuatro o cinco opciones de respuesta. Las categorías no son mutuamente excluyentes.

7.4.4.3 Requisitos para elegir el lenguaje de un cuestionario.

1. Use, en lo posible, el lenguaje de quien contesta. Mantenga redacción sencilla.

2. Sea específico, sin embargo, evite preguntas sumamente específicas.

3. Use preguntas cortas.

4. No sea condescendiente con lo que contestan. Evite el uso de

lenguaje corriente.

5. Evite la parcialidad en la redacción. Esto también significa evitar preguntas censurables.

6. Dirija las preguntas a las personas indicadas.

7. Asegúrese que las preguntas sean técnicamente precisas antes de

incluirlas.

Departamento de Computación UNAN - León

Page 93: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 93 de 316

En ambos casos la elección por preguntas abiertas o cerradas en un cuestionario tiene inconvenientes. Las respuestas a preguntas abiertas permiten al analista contar con una mayor información, adentrarse más, así como obtener una mayor profundidad y amplitud sobre los tópicos. Cuando nos referimos a la redacción de preguntas cerradas con respuestas que siguen o no un orden, nos estamos refiriendo al proceso que denominamos Escalamiento. Este es el proceso de asignar número u otros símbolos a un atributo con el fin de poder medirlo, con frecuencia estas escalas son arbitrarias y no llegan a ser únicas.

Departamento de Computación UNAN - León

Page 94: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 94 de 316

7.4.5 Muestreo Existen varios métodos de recopilación de información como investigación, la entrevista o la observación y todos ellos requieren que se decida con anticipación el marco de trabajo, como es determinar lo que examinará, a quién se entrevistara y observará; el análisis de sistema hace uso del muestreo para tomar estas decisiones.

7.4.5.1 Que es el Muestreo Es el proceso por el cual se selecciona de manera sistemática elementos representativos de una población. El analista de sistema debe tomar en cuenta dos aspectos importantes al realizar el muestreo:

1. Efectuar una selección sobre los diferentes documentos de reporte

2. Debe seleccionar también el tipo y el número de personas involucradas, de las cuales se obtendrá información en el proceso de automatización.

Necesidades del muestreo

1. La realización del muestreo puede brindar al analista numerosas ventajas relacionadas con los costos, recopilación ágil de datos, mejoría en la eficiencia y reducción de la separación de muestreo probabilística.

2. Muestreo estratificado: son los más importantes ya que la

estratificación es el proceso mediante el cual se identifican sub-poblaciones para luego mediante el muestreo, seleccionarlo

3. Muestro por grupo: es cuando se tiene que seleccionar un grupo de

documentos o gentes a estudiar. En el muestro es más importante el número absoluto que el porcentaje de la población. El tamaño de la muestra depende de varios elementos:

a. Costo que involucra

b. Tiempo disponible del analista de sistema

Departamento de Computación UNAN - León

Page 95: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 95 de 316

c. El tiempo del cual disponen los integrantes de la organización.

d. El analista puede elegir un intervalo aceptable (esto es el grado de precisión deseado).

7.4.5.2 Diseño del muestreo Los cuatro pasos que debe seguir un analista de sistemas para diseñar una buea muestra son:

1. Determinar los datos a ser recolectados o descritos.

2. Determinar la poblacióna a ser muestreada.

3. Seleccionar el tipo de muestra.

4. Decidir el tamaño de la muestra. Estos pasos son descritos a continuación:

1. Determinar los datos a ser recolectados o descritos

El analista de sistemas necesita un plan realista sobre lo que hará con los datos una vez que se recolecten. Si se recolectan datos irrelevantes, se desperdiciará tiempo en la recolección, almacenamiento y análisis sobre datos inútiles. Las tareas y responsabilidades del analista de sistemas en este punto son identificar las variables, atributos y conceptos de datos asociados que necesitan ser recolectados en la muestra. Se deben considerar los objetivos del estudio, así como el tipo de método de recolección de datos (investigación, entrevistas, cuestionarios, observación) a ser usados.

2. Determinación de la población a ser muestreada

El analista de sistemas debe determinar cuál es la población. En el caso de datos relevantes, necesita decidir, por ejemplo, si son suficientes los dos últimos meses o si se necesitan los reportes de todo el año para ese análisis. En forma similiar, cuando se decide a quién entrevistar, el analista de sistemas tiene que determinar si la población debe incluír solamente un nivel de la organización o todos los niveles, o tal vez ir hasta el exterior del sistema para incluír la reacción de los clientes.

Departamento de Computación UNAN - León

Page 96: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 96 de 316

3. Selección del tipo de muestra

El analista de sistemas tiene cuatro tipos principales de muestras, tal como muestra Tabla 7.4.1. Son: de conveniencia, intencionada, aleatoria simple, aleatoria compleja.

Tabla 7.4.1 Cuatro tipos principales de muestras.

No basadas en probabilidad. Basadas en probabilidad. Los elementos de muestra son seleccionados directamente sin

restricciones.

Conveniencia Aleatoria simple

Los elementos de muestra son seleccionados de acuerdo con in

criterio específico.

Intencionada

Aleatoria compleja (sistemática, estratificada y aglomerada)

El analista desistemas debe usaruna muestraaleatoria complejade ser posible.

Muestras de convenciencia Las muestras de conveniencia son muestras no restringidas y no probables. Una muestra puede ser llamada de conveniencia, si, por ejemplo, el analista de sistemas pone una noticia en el boletín de la compañía pidiendo a cualquier interesado en el nuevo reporte de desempeño de ventas que asista a una reunión a la 1:00 pm. el Martes 12. Obviamente, la muestra es la más fácil que se podría recolectar, pero, al mismo tiempo, es la menos confiable. Muestras intencionadas Un analista de sistemas puede seleccionar a un grupo de individuos que parecen tener conocimientos e interés en el nuevo sistema de información. Este es un ejemplo de una muestra intencionada basada en el juicio del analista. Aquí el analista de sistemas basa la muestra sobre un criterio (conocimiento e interés sobre el nuevo sistema), pero todavía es una muestra no probada. Por lo tanto, este muestreo intencionado es sólo moderadamente confiable. Muestras aleatorias simples Si se escoge realizar una muestra aleatoria simple se necesita obtener una lista enumerada de la población para asegurarse de que cada documento o persona de la población, tenga una oportunidad igual de

Departamento de Computación UNAN - León

Page 97: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 97 de 316

ser seleccionado. A veces esto no es prático, especialmente cuando el muestreo involucra documentos y reportes. Muestras aleatorias complejas Frecuentemente se pueden lograr los objetivos del muestreo seleccionando uno de los enfoques para el muestreo aleatorio complejo. Los enfoques más adecuados para el analista de sistemas son: (1) muestreo sistemático, (2) muestreo estratificado y (3) muestreo aglomerado. En el método más simple de muestreo probable, el muestreo sistemático, el analista de sistemas podría, por ejemplo, escoger entrevistar a cada enésima persona de una lista de empleados de la compañía. Sin embargo, este método tiene ciertas desventajas. Tal vez no se qusisiera usar para seleccionar para una muestra, debido al problema potencial de periodicidad. Lo que es más, un analista de sistemas no querría usar este enfoque si la lista estuviera ordenada (por ejemplo, una lista de bancos, desde el más pequeño hasta el mayor) debido a la ascendencia introducida. Las muestras estratificadas son, tal vez, las más importantes para el analista de sistemas. La estratificación es el proceso de identificación de subplobaciones, o estratos, y luego la selección de objetos o personas a muestrear dentro de estas subploaciones. La estratificación es, a menudo, esencial si el analista de sistemas va a recolectar datos eficientemente. Por ejemplo, si se quiere buscar la opinión de un amplio rango de empleados en diferentes niveles de la organización, el muestreo sistemático seleccionaría una cantidad desproporcionada de empleados del nivel de control operacional. Una muestra estratificada compensaría esto. La estratificación también se aplica cuando el analista de sistemas quiere usar diferentes métodos para recolectar datos de diferentes subgrupos. Por ejemplo, tal vez quiera usar un cuestionario para recolectar datos de los gerentes medios, pero usar entrevistas personales para recolectar datos similares de los ejecutivos. Algunas veces el analista de sistemas debe seleccionar un grupo de documentos o personas a estudiar. A esto se le llama muestreo aglomerado. Suponga que una organización tiene 20 bodegas repartidas por todo el país. Tal vez quiera seleccionar una o dos de estas bodegas, bajo la hipótesis de que son típicas de las bodegas restantes.

4. Decisión del tamaño de la muestra

Obviamente,si todos en la población vieran el mundo de la misma forma, o cada uno de los documentos de una población contuviera exactamente sla misma información que cualquier otro documento,

Departamento de Computación UNAN - León

Page 98: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 98 de 316

sería suficiente un tamaño de muestra de uno. Dado que éste no es el caso, es necesario tomar un tamaño de muestra mayor de uno pero menor que el tamaño de la población misma. Es importante recordar que la cantidad absoluta es más importante en el muestreo que el porcentaje de la población. Podemos obtener resultados satisfactorios haciendo un muestreo de 20 personas en 200 o 20 personas en 2,000,000. El tamaño de la muestra depende de muchas cosas, algunas puestas por el analista de sistemas, algunas determinadas por lo que se sabe acerca de la población misma y otros factores imperantes. El analista de sistemas puede esocoger la estimación de intervalo aceptable (eso es, el grado de precisión deseado) y el error estándar (seleccionando el grado de precisión deseada) y el error estándar (seleccionando el grado de confianza). Lo que es más, las características de la población pueden cambiar el tamaño de la muestra. Si las cifras de un reporte van de $10,000 a $15,000, un tamaño de muestra pequeño sería suficiente para dar una estimación precisa de las ventas promedio. Sin embargo, si las ventas van de $1,000 a $100,000, entoncesse requerirá un tamaño de muestra mucho más grande. El tamaño de la muestra es tratado con mayor detalle en la siguiente sección.

7.4.5.3 Decisión del tamaño de la muestra El tamaño de la muestra depende frecuentemente del costo involucrado en el tiempo requerido por el analista de sistemas o hasta del tiempo disponible de las personas de la organización. En esta sección se explican algunos lineamientos para determinar el tamaño de la muestra requerido bajo condiciones ideales. Determinación del tamaño de muestra cuando se muestrean datos de atributos Algunas veces el analista de sistemas querrá encontrar qué proporción de personas de una organización piensan de determinada manera o tienen determinadas características. Otras veces el analista puede necesitar saber qué porcentaje de las formas de entrada tienen errores. Este tipo de datos puede ser mencionado como datos de atributos. El analista de sistemas necesita seguir una serie de pasos, donde algunos son juicios subjetivos, para determinar el tamaño de muestra requerido. La siguiente es la lista de los siete pasos:

Departamento de Computación UNAN - León

Page 99: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 99 de 316

1. Determinar el atributo que se muestreará.

2. Localizar la base de datos o reportes donde se puede encontrar el atributo.

3. Examinar el atributo. Esimar p , la proporción de la población que

tiene el atributo.

4. Tomar la decisión subjetiva en relación con el intervalo estimado aceptable, i .

5. Seleccionar el nivel de confianza y buscar el coeficiente de confianza

(valor z) en una tabla.

6. Calcular pσ , el error estándar de la proporción, de la manera siguiente:

zi

p =σ

7. Determinar el tamaño de la muestra, , usando la siguiente fórmula: n

( )1

12

+−

=p

ppn

σ

El primer paso, por supuesto, es determinar cuál atributo se muestreará. Una vez que se hace esto, se puede encontrar dónde está guardado el dato, tal vez en una base de datos, o en una forma o en un reporte. Es importante estimar p , la proporción de la población que tiene el atributo, para que se ponga el tamaño de la muestra adecuado. Muchos libros de texto sobre análisis análisis de sistemas sugieren el uso de un valor heurístico de 0.25 para

. Esto da casi siempre como resultado un tamaño de muestra mayor que que el necesario, debido a que 0.25 es el valor máximo de que sucede solamente cuando . Cuando

( pp −1 ))( pp −1

50.0=p 10.0=p , como es más frecuente, ( )pp −1 llega a ser 0.09, lo que da como resultado un tamaño de muestra mucho más pequeño. Los pasos 4 y 5 son decisiones subjetivas. El intervalo estimado aceptable de significa que se acepta un error de no más de 0.10 en ambas direcciones de la actual proporción

10.0±

p . El nivel de confianza es el grado deseado de certidumbre, digamos, por ejemplo, 95 por ciento. Una vez que es seleccionado el nivel de confianza, el coeficiente de confianza (también llamado valor ) puede ser buscado en una tabla como la que se encuentra en la Tabla 7.4.2.

z

Departamento de Computación UNAN - León

Page 100: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 100 de 316

Tabla 7.4.2 Tabla del área bajo la curva normal.

Nivel de Confianza

Coeficiente de Confianza (valor z)

99% 2.58 98% 2.33 97% 2.17 96% 2.05 95% 1.96 90% 1.65 80% 1.28 50% 0.67

Primero decida el nivel de confianza

Luego busque el valor z.

La Tabla 7.4.2, puede ser usada para buscar un valor, una vez que el analista de sistemas decide el nivel de confianza. Los pasos 6 y 7 completan el proceso, toamando los parámetros que se encuentran o ponen en los pasos 3 a 5 y alimentándolos a dos ecuaciones, para posteriormente resolveras para el tamaño de muestra requerido. Ejemplo Los pasos anteriores pueden ser mejor ilustrados. Supongamos que la compañía A. Sembly, un gran fabricante de productos de anaqueles, pide que se determine qué tanto porcentaje de órdenes contendrán errores. Se acuerda realizarlos y se ejecutan los siguientes pasos: Se determina que se estarán órdenes que contengan errores en nombres, direcciones, cantidades o números de modelo. Se localizarán copias de formas de órdenes de los seis meses anteriores. Se examinarán algunas de las formas de órdenes y se concluirá que solamente 5 por ciento (0.05) contienen errores. Se tomará una decisión subjetiva de que el intervalo estimado aceptable será de

. 02.0± Se seleccionará un nivel de confianza de 95 por ciento. Se busca el coeficiente de confianza (valor ) en la Tabla 7.4.2. El valor es igual a 1.96 z z Se calcula pσ de la siguiente manera:

Departamento de Computación UNAN - León

Page 101: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 101 de 316

zi

p =σ

0102.096.102.0

==

Se determina el tamaño de la muestra necesario, , de la manera siguiente: n

( )1

12

+−

=p

ppn

σ

( )( )( ) 4581

0102.00102.095.005.0

=+=

Luego, la conclusión es ajustar el tamaño de la muestra a 458. Obviamente, un nivel de confianza mayor, o un estimado de intervalo aceptable más pequeño, requeriría un tamaño de muestra más grande, tal como se muestra a continuación. Si mantenemos el estimado de intervalo aceptable igual, pero implantamos el nivel de confianza a 99 por ciento (con un valor de 2.58), el error estándar es: z

zi

p =σ

078.058.202.0

==

y el tamaño de muestra necesario es:

( )1

12

+−

=p

ppn

σ

( )( )( ) 7821

0078.00078.095.005.0

=+=

Departamento de Computación UNAN - León

Page 102: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 102 de 316

Si el nivel de confianza permanece al 95 por ciento (valor 96.1=z ), pero el estimado de intervalo aceptable es puesto a 0.01, el error estándar de la proporción es:

zi

p =σ

051.096.101.0

==

y el tamaño de muestra necesario es:

( )1

12

+−

=p

ppn

σ

( )( )( ) 18271

0051.00051.095.005.0

=+=

Determinación del tamaño de muestra cuando se muestrean datos en variables Un analista de sistemas puede algunas veces, necesitar recolectar información sobre cifras actuales, tales como ventas brutas, cantidad de artículos regresados o cantidad de errores tecleados. Los datos de este tipo son mencionados como variables. Los pasos para la determinación del tamaño de muestra necesario para las variables es similar a los pasos para los datos de atributos. Son los siguientes:

1. Determinar la variable que se muestreará.

2. Localizar la base de datos o reporte donde pueda ser encontrada la variable.

3. Examinar la variable para obtener alguna idea acerca de su magnitud

y dispersión. Idealmente, sería útil saber la media para determinar un estimado de intervalo aceptable más adecuado, y la desviación estándar, , para determinar el tamaño de la muestra (en el paso 7). s

4. Tomar una decisión subjetiva en relación con el estimado de intervalo

aceptable, i .

Departamento de Computación UNAN - León

Page 103: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 103 de 316

5. Seleccionar un nivel de confianza y buscar el coeficiente de confianza

(valor ) en una tabla. z

6. Calcular x

σ , el error estándar de la media, de la manera siguiente:

zi

x=σ

7. Determine el tamaño de la muestra necesario, , utilizando la siguiente fórmula:

n

12

+⎟⎟⎠

⎞⎜⎜⎝

⎛=

x

snσ

El paso 3 es difícil de realizar con precisión. Para estimar la media y la desviación estándar se tendría, de hecho, que muestrear la población. Esto es, por supuesto, un problema, debido a que el analista de sistemas no sabe qué es lo que es primero. Por consecuencia, no es necesario saber con precisión cuáles son la media y la desviación estándar. Será suficiente una estimación razonable. La importancia de la estimación de la media y la desviación estándar se hace obvia cuando se trata de poner el estimado de intervalo aceptable. Supongamos que se pide que se determine el promedio de ventas brutas paa una pequeña tienda de tarjetas de felicitación ($3,500 por semana) y de una dulcería grande ($70,000 por semana). Un estimado de intervalo deseado de $350 para la pequeña tienda sería inadecuado para la dulcería grande. Lo que es más, la dispersión estimada es importante, debido a que entre más pequeña es la dispersión (medida por la desviación estándar) menor es el tamaño de muestra necesario. Por ejemplo, supongamos que se estuviera tratando de detrminar la edad promedio de los compradores de discos compactos. Si se tomara la suposición de ue cualquiera de 10 a 100 años de edad compra discos compactos, se necesitaría un tamaño de muestra muy grande. Sin embargo, si se estima que, por lo general, las edades de los compradores de discos compactos están entre 13 y 23, se puede salir al paso con un tamaño de muestra más pequeño. Las fórmulas para determinar el tamaño de muestra necesario para las variables son diferentes de las fórmulas para los datos de atributos. Debido a que el analista de sistemas debe tener cuidado en la estimación de la magnitud y dispersión de una variable.

Departamento de Computación UNAN - León

Page 104: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 104 de 316

Ejemplo Tomemos otro ejemplo de la compañía A. Semble, para ilustrar la manera de econtrar el tamaño de muestra necesario para las variables. Ahora se pide que se determine la cantidad en dólares promedio de una órden. Se está de acuerdo con esto y se ejecutan los siguientes pasos: Se determina que se estará buscando la media de la cantidad de dólares de las órdenes sobre anaqueles. Se localizan las copias de formas de órdenes de los seis meses pasados. Se examinan algunas de las formas de órdenes y se concluye que el promedio de las órdenes es cercano a $·1,500, con una desviación estándar, , de cerca de $100.

s

Se toma una decisión subjetiva de que el estimado de intervalo aceptable sería de $5.00. Se escoge un nivel de confianza de 96 por ciento. Se busca el coeficiente de confianza (valor ) en la Tabla 7.4.2. El valor es igual a 2.05. z z Se calcula

xσ de la siguiente manera:

zi

x=σ

44.205.200.5

==

Se determina el tamaño de la muestra necesario, , de la manera siguiente: n

12

+⎟⎟⎠

⎞⎜⎜⎝

⎛=

x

snσ

144.2

100 2

+⎟⎠⎞

⎜⎝⎛=

11680 +=

1681=

Departamento de Computación UNAN - León

Page 105: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 105 de 316

Por lo tanto, se muestreará 1,681 órdenes para determinar la media del importe en dólares de las órdenes. Tal como sucede con el muestreo de datos de atributos, un mayor nivel de confianza, o un menor estimado de intervalo aceptable, requerirá un tamaño de muestra más grande. Si mantenemos igual el estimado de intervalo aceptable, pero incrementamos el nivel de confianza a 99 por ciento (con un valor de 2.58), el error estándar de la media es:

z

zi

x=σ

94.258.200.5

==

y el tamaño de muestra necesario es:

12

+⎟⎟⎠

⎞⎜⎜⎝

⎛=

x

snσ

194.1

100 2

+⎟⎠⎞

⎜⎝⎛=

658,2= Si el nivel de confianza permance al 96 por ciento (valor 05.2=z ), pero el estimado de intervalo aceptable es puesto a $1.00, el error estándar de la media es:

zi

x=σ

488.005.200.1

==

Departamento de Computación UNAN - León

Page 106: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 106 de 316

y el tamaño de muestra necesario es:

12

+⎟⎟⎠

⎞⎜⎜⎝

⎛=

x

snσ

1488.0

100 2

+⎟⎠⎞

⎜⎝⎛=

1992,41 +=

993,41= Esto implica que la precisión al dólar será demasiado cosotosa en el muestreo, debido a que muestrear más de 41,000 de cualquier cosa, es excesivo. Determinación del tamaño de muestra cuando se muestrean datos cualitativos Una gran cantidad de información no puede ser obtenida buscando archivos. Esa información puede ser obtenida en mejor forma entrevistando personas de la organización. No hay fórmulas mágicas que ayuden al analista a determinar el tamaño de muestra para las entrevistas. La variable relevante que determina a qué tanta gente debe entrevistar el analista de sistemas a fondo es el tiempo que se lleva una entrevista. Una verdadera entrevista a fondo, y el seguimiento de ésta, consume demasiado tiempo, tanto para el entrevistador como para el participante. Una buena regla empírica es entrevistar al menos a tres personas de cada nivel de organización y al menos a una de cada una de las áreas funcionales de la organización. Recuerde también que no se tienen que entrevistar a más personas simplemente porque la organización sea más grande. Si la muestra estratificada se realiza correctamente, un pequeño número de personas representará adecuadamente a la organización completa.

Departamento de Computación UNAN - León

Page 107: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 107 de 316

EESSPPEECCIIFFIICCAACCIIÓÓNN DDEE RREEQQUUIISSIITTOOSS SSOOFFTTWWAARREE--

EERRSS..

Departamento de Computación UNAN - León

Page 108: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 108 de 316

7.5 Especificación de Requisitos Software

Título del tema 4: Especificación de Requisitos Software - ERS.

Objetivos: • Comprender la importancia de especificar los requisitos de un problema

a resolver, como un paso importante en la etapa de análisis del sistema.

• Explicar las propiedades que debe cumplir una especificación de requsisitos software.

• Mostrar la forma de cómo estructurar una especificación de requisitos software.

• Dar ejemplos prácticas de construcción de especificación de requisitos software para problemas de la vida real.

Contenido: • ¿Qué es una especifcación de requisitos software?

• Propiedades de una especifación de requisitos software.

• Preparación del ERS

• Estructura de un ERS.

• Ventajas de un ERS.

• Ejemplo de un ERS.

Duración: • 10 horas

Bibliografía básica:

• Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pearson Educación.

• Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

Departamento de Computación UNAN - León

Page 109: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 109 de 316

7.5.1 ¿Qué es una especificación de requisitos software? La especificación de requisitos software es el establecimiento conciso de un conjunto de requisitos que deben ser satisfechos por un producto o un proceso, indicando, siempre que sea adecuado, el procedimiento mediante el cual se puede determinar si se han logrado satisfacer los requisitos Los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir la descripción de las características del nuevo sistema. Esta actividad tiene tres partes relacionadas entre si:

1. Análisis de datos basados en hechos reales.

Se examinan los datos recopilados durante el estudio, incluidos en la documentación de flujo de datos y análisis de decisiones, para examinar el grado de desempeño del sistema y si cumple con las demandas de la organización.

2. Identificación de requerimientos esenciales.

Características que deben incluirse en el nuevo sistema y que van desde detalles de operación hasta criterios de desempeño.

3. Selección de estrategias para satisfacer los requerimientos.

Métodos que serán utilizados para alcanzar los requerimientos establecidos y seleccionados. Estos forman la base para el diseño de sistemas, los cuales deben cumplir con la especificación de requerimientos.

Las tres actividades son importantes y deben realizarse en forma correcta. La especificación de requerimientos implica una gran responsabilidad para los analistas de sistemas, ya que la calidad del trabajo realizado en esta etapa se verá reflejada más adelante en las características del nuevo sistema.

7.5.2 Propiedades de una especificación de requisitos software. Un ERS debe cumplir las propiedades siguientes:

• No ambiguo, es decir que cada requisito tenga una única interpretación y un único significado.

Departamento de Computación UNAN - León

Page 110: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 110 de 316

• Que sea completo:

Incluye todos los requisitos significativos. Define las respuestas del software para todos los datos de

entrada en todas las clases de situación posible. En caso de no aplicarse alguna sección se debe indicar el por

qué no se aplica. Define todos los términos, unidades de medida y hace

referencia a todas las figuras, tablas y diagramas. Si algún apartado del ERS contiene la frase: “se determinará”m

entonces el ERS no está completo.

• Que sea verificable. Debe existir un procedimiento finito de coste razonable en el que una persona pueda probar que el producto software cumpla el requisito.

• Consistencia. Ninguno de los requisitos individuales descritos del

ERS debe presentar conflictos.

• Modificable. Debe estar organizado de forma fácil y coherente y no presentar información redundante.

• Rastreable. Cada uno de los requisitos debe dejar claro su origen

para que sea fácil el desarrollo y mejorar la documentación futura.

• Utilizable en la fase de operación y mantenimiento. Por ejemplo, si el personal encargado del mantenimiento es diferente al personal que estuvo a cargo del análisis, diseño y codificación, entonces el primero necesitará utilizar la documentación generada en la Especificación de Requisitos para poder hacer los cambios pertinetes al sistema.

Departamento de Computación UNAN - León

Page 111: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 111 de 316

7.5.3 Preparación del ERS. El objetivo del ERS es el establecimiento de un acuerdo entre el usuario y los analistas sobre QUÉ debe hacer el software. Debe prepararse de forma conjunta por los usuarios y por los analistas.

7.5.4 Estructura de un ERS. El cuadro siguiente refleja la estructura que debe contener un ERS: Índice de contenidos. 1.- Introducción.

1.1.- Propósito. 1.2.- Alcance. 1.3.- Definiciones, acrónimos y abreviaturas. 1.4.- Referencias. 1.5.- Visión general.

2.- Descripción general.

2.1.- Relaciones del producto. 2.2.- Funciones del producto. 2.3.- Características del usuario. 2.4.- Restricciones generales. 2.5.- Suposiciones y dependencias.

3.- Requisitos específicos.

3.1.- Requisitos funcionales.

3.1.1.- Requisito funcional 1.

3.1.1.1.- Especificación.

3.1.1.1.1.- Introducción. 3.1.1.1.2.- Entradas. 3.1.1.1.3.- Proceso. 3.1.1.1.4.- Salidas.

3.1.1.2.- Interfaces externas.

3.1.1.2.1.- Interfaces de usuario.

Departamento de Computación UNAN - León

Page 112: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 112 de 316

3.1.1.2.2.- Interfaces hardware. 3.1.1.2.3.- Interfaces software. 3.1.1.2.4.- Interfaces de comunicaciones.

3.1.2.- Requisito funcional 2. ……………………………… 3.1.n.- Requisito funcional n.

3.2.- Requisitos de funcionamiento. 3.3.- Restricciones de diseño. 3.4.- Atributos.

3.4.1.- Seguridad. 3.4.2.- Mantenibilidad. ………………………………

3.5.- Otros requisitos.

3.5.1.- Bases de datos. 3.5.2.- Operaciones.

Apéndices.

La estructura del ERS se encuentra en el estándar IEEE 830. El capítulo 1, Introducción, consta de los siguientes apartados:

• Delimitando el propósito del ERS y a quién va dirigido.

• Identificar el alcance, es decir, darle un nombre al proyecto, indicar qué hará y qué no hará así como describir la aplicación del software que se está especificando.

• El apartado de Definiciones, acrónimos y abreviaturas deberá

contener todas las definiciones de todos los términos y abreviaturas que se necesitarán para entender el ERS

• El apartado Referencias debe proporcionar una lista completa de

todos los documentos referenciados identificando cada documento por su título, número de informe, fecha y editorial e indicar dónde se pueden encontrar.

• Por último el apartado de Visión General contendrá la descripción del

resto del ERS y la explicación de cómo está organizado el resto del ERS.

Departamento de Computación UNAN - León

Page 113: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 113 de 316

El capítulo 2, Descripción general, describe los factores generales que afectan al producto y a sus requisitos. Cada uno de los apartados será:

• El apartado Relaciones del producto muestra las relaciones del producto a desarrollar con otros productos o proyectos. Es decir, aquí aparece si el producto es un producto aislado, o si por el contrario, forma parte de un gran proyecto.

• El apartado Funciones del producto contiene las funciones que

realizará el producto a nivel general.

• La sección de Características del usuario describe el por qué de ciertos requisitos o restricciones de diseño. Tiene que ver con las características generales de los usuarios que trabajarán con el producto.

• El apartado Restricciones generales proporcionará la descripción de

cualquier elemento que limite las opciones del desarrollador a la hora de diseñar el sistema. Se tratarán temas como: las normas de desarrollo, las limitaciones hardware, las interfaces con otras aplicaciones y las consideraciones sobre seguridad pertinentes.

• Por último, el apartado Suposiciones y dependencias indicará los

factores que afectan a los requisitos enunciados en el ERS. El capítulo 3, Requisitos específicos, contiene todos los detalles que el desarrollador de software va a necesitar para realizar el diseño. Es la parte más extensa y más importante del ERS. Contendrá los siguientes apartados:

• El apartado Requisitos funcionales especificará cómo se transforman las entradas al producto software, en las salidas correspondientes. Describirá las acciones fundamentales que debe realizar el software.

• El apartado Requisitos de funcionamiento contendrá:

Los requisitos estáticos: ♦ Número máximo de terminales. ♦ Número máximo de usuarios simultáneos aceptados por

el sistema. ♦ Número de ficheros y registros que se manejarán. ♦ Tamaño de los ficheros.

Los requisitos dinámicos:

♦ Máximo número de transacciones por periodo de tiempo.

• El apartado Atributos contiene todos los temas relativos a la seguridad y al mantenimiento del producto final que necesitarán los diseñadores del producto.

Departamento de Computación UNAN - León

Page 114: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 114 de 316

atos que empleará el producto, las operaciones que se realizarán sobre ellas, etc.

El capítulo A documentación adicional necesaria para oder comprender la especificación de requisitos.

.5.5 Ventajas de un ERS.

• do entre los clientes y los obre lo qué va a hacer el producto software.

• Proporciona una base sobre la que estimar los costes y los tiempos

roducto software.

• Sirve como base para el mantenimiento del producto final.

.5.6 Ejemplo de un ERS.

El ejemplo se ha desarrollado sobre la realización de una especificación de ducto que se encargará de la gestión de importación

posterior venta de papel de la empresa PAPELIX S.A.

.1.- Propósito.

efinición del conjunto de especificaciones de requisitos software que debe cumplir GESTIÓN DE IMPORTACIÓN Y VENTA DE PAPEL de la empresa

APELIX S.A., consiste en la mecanización de los procesos de importación de

o antes de abordar la fase de nálisis.

Finalmente, el apartado Otros requisitos, contendrá la descripción de las bases de d

péndices contiene toda lap

7

Establece las bases para un acuersuministradores s

• Reduce el esfuerzo de desarrollo.

necesarios para la realización del p

• Proporciona una base para la validación y la verificación del producto.

7

requisitos software para un proy 1.- Introducción. 1 Dla aplicación de Ppapel a los proveedores y de la venta a los clientes. Este documento se dirige a la Dirección de la empresa y a los usuarios finales que deberán estudiarlo para su aprobación o desacuerda

Departamento de Computación UNAN - León

Page 115: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 115 de 316

1.2.- Alcance. El nombre con el que se conocerá a está aplicación será: de GESTIÓN DE IMPORTACIÓN Y VENTA DE PAPEL. El producto realizará las siguientes funciones:

• Generación de Órdenes de Compra a Proveedores.

• Captura del Documento de Recepción de Embarque que envía la Aduana.

• Anotación del Pago a la Aduana por la importación realizada.

• Anotación del Pago del Proveedor por la mercancía suministrada.

• Generación de la Orden de Carga a la Agencia de Transportes que se

encarga de trasladar la mercancía desde el puerto hasta el almacén de PAPELIX S.A.

• Anotación del Pago a la Agencia de Transportes por el servicio

realizado.

• Captura del Documento de Recepción de Mercancía que entrega la Agencia de Transportes junto con la mercancía.

• Captura de los Pedidos Realizados por los Clientes.

• Generación de la Orden de Carga a la Agencia de Transportes, que

se encargará del traslado de la mercancía desde el almacén hasta el establecimiento del cliente.

• Anotación de la Salida de la Mercancía hacia el Cliente.

• Emisión de la Factura al Cliente por la mercancía servida.

• Anotación del Cobro al Cliente correspondiente a la Factura remitida.

• Emisión de los siguientes Listados de información:

Listado de Mercancía Pendiente de Recibir de Proveedores. Listado de Mercancía Pendiente de Servir a Clientes. Listado de Facturas Pendientes de Cobro.

Quedará fuera del alcance de esta aplicación el enlace con la aplicación de Contabilidad ya existente en la empresa.

Departamento de Computación UNAN - León

Page 116: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 116 de 316

1.3.- Definiciones, acrónimos y abreviaturas.

á PROVEEDOR.

enviado al Proveedor en el que se le comunica la mercancía solicitada y las condiciones de la compra,

n el que se ha especificado la recepción en el puerto de la mercancía solicitada en O_COMPRA, En el resto del ERS se

de la mercancía que llega a puerto desde otros países. en lo sucesivo

• edor: documento que envía el proveedor en el que

se especifica el importe a pagar por la mercancía servida. En lo

• Orden de Carga: documento que se envía a la agencia de

o sucesivo se hará referencia como O_CARGA.

• Agencia de Transportes: empresa que se encarga de transportar la

• Puerto de llegada: puerto en el que se recibe la mercancía, en lo

cibido junto con la mercancía por parte de la agencia de transportes en el que se

D_R_MERCANCÍA.

• Cliente: empresa que realiza la compra del papel a PAPELIX S.A.

• Fa l cual se

es suministrado. A lo largo del ERS se denominará F_CLIENTE.

ra al PROVEEDOR, de la ADUANA.

• Proveedor: empresa que suministra el papel con el que se comercia.

El resto del ERS lo llamar

• Orden de Compra: documento

O_COMPRA en lo sucesivo.

• Documento de Recepción de Embarque: documento que envía la aduana e

denotará por D_R_EMBARQUE.

• Aduana: entidad que se ocupa de la tramitación de la importación

ADUANA.

Factura de Prove

sucesivo F_PROVEEDOR.

transportes en el que se solicita un servicio de transporte desde el puerto hasta el almacén de PAPELIX. En l

mercancía especificada en la O_CARGA. El resto del ERS la llamará A_TRANSPORTES.

sucesivo PUERTO.

• Documento de Recepción de Mercancía: documento re

indican las cantidades transportadas y su importe. Le llamaremos

ctura a Cliente: documento enviado al Cliente en epecifica el importe correspondiente al pedido

• Pago: acción por la cual la empresa PAPELIX S.A. abona el importe

correspondiente a una comp

Departamento de Computación UNAN - León

Page 117: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 117 de 316

• Cobro: acción por la cual el cliente abona al PAPELIX S.A. el importe correspondiente a una factura.

1.4.- Ref nc

• interna de la gestión de importación y venta de PAPELIX S.A. Informe nº 1. Fecha: 12/02/97. Suministrador

me nº 3. Fecha: 13/2/97. Realizado por el departamento de informática de la empresa PAPELIX S.A.

1.5.- Visión ge

Primeram ntedesarrollar paEspecíficos in

2.- Descripció 2.1.- Relacion

La aplica ón que existe en

l equipo en el que se desarrollará e implantará el producto final es:

• • 128 Mb RAM.

La instalación inicial constará de cuatro terminales y una impresora láser.

.2.- Funcione

El producto spersonal de P

O_COMPRA que se imprimirá posenviada al PROVEEDOR.

ere ias.

Guía para la mecanización

por PAPELIX S.A.

Informe obtenido como resultado de las entrevistas realizadas desde el 15/6/96 hasta el 15/9/96. Infor

neral.

e se realizará una Descripción General del producto que se desea ra pasar posteriormente a estudiar cada uno de los Requisitos

dividualmente.

n General.

es del producto.

ci interactúa con una aplicación de mantenimiento de ficheros maestros la empresa PAPELIX S.A.

E

IBM AS400.

• 10 Gb de disco duro.

2

s del producto.

oftware debe contener todas las tareas que realiza manualmente el APELIX S.A. de forma diaria. Éstas son:

1. Cuando se necesite la reposición de mercancía por falta de

existencias, el usuario deberá introducir en el ordenador la teriormente en papel para ser

Departamento de Computación UNAN - León

Page 118: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 118 de 316

2. Cuando se reciba por parte de la ADUANA el D_R_EMBARQUE, el usuario debe introducirlo en el ordenador como justificante de llegada de mercancía al puerto.

3. Cuando se reciba la F_PROVEEDOR correspondiente a la mercancía istrada, el usuario debe introducir sus datos en el ordenador,

para poder realizar posteriormente el PAGO al PROVEEDOR.

4. enador.

6. Una vez introducido el D_R_EMBARQUE el usuario podrá generar

una O_CARGA a una A_TRANSPORTES. Se realizará de forma iva por un terminal.

8. Una vez capturado el D_R_MERCANCÍA y cuando se produzca el _TRANSPORTES, se deberá registrar en el ordenador.

un PEDIDO de un CLIENTE deben introducirse los datos del mismo en el ordenador de forma interactiva.

al CLIENTE, el usuario deberá introducir en el terminal la O_CARGA para solicitar a la A_TRANSPORTES el

. roduzca la retirada de la mercancía por parte de la TES se deberá registrar este hecho en el ordenador.

12. tará un proceso automático que generará todas

las facturas correspondientes a los pedidos servidos en ese mes. Se

13. Al producirse el COBRO correspondiente a una F_CLIENTE el usuario orma interactiva.

sumin

Cuando se realice el PAGO al PROVEEDOR el usuario deberá registrarlo en el ord

5. Cuando se realice el PAGO a la ADUANA, el usuario debe registrarlo

en el ordenador.

interact

7. Cuando se reciba el D_R_MERCANCÍA de la A_TRANSPORTES se debe realizar la captura de los datos de forma interactiva en el terminal.

PAGO a la A

9. Cuando se reciba

10. Al ir a entregar l mercancía

envío de la mercancía al CLIENTE.

11 Cuando se pA_TRANSPOR

A final de mes se ejecu

imprimirá en papel para su envío a los CLIENTES.

lo registrará de f

14. El usuario podrá disponer de los siguientes listados de forma diaria:

• Listado de Mercancía Pendiente de Recibir de Proveedores, que informa de todas las O_COMPRA para las que se espera la recepción de mercancía.

Departamento de Computación UNAN - León

Page 119: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 119 de 316

• Listado de Mercancía Pendiente de Servir a Clientes, informa sobre los PEDIDOS de CLIENTES para los que no se ha realizado la salida de mercancías.

.3.- Características del usuario. Los usuarios finales de la aplicación serán personas cuya experiencia informática es scasa, motivo por el que se deberá incluir ayuda en línea en el producto final.

2.4.- Restricc

El lengu deSe deberán s

2.5.- Su ici

urante las entrevistas iniciales, la Dirección de la empresa PAPELIX S.A. ha indicado pCLIENTES en

3.- Requisito

3.1.- Re t……………….1.9.- Captura de un pedido de un cliente.

3.1.9.1

3.1.9.1.1.- Introducción.

minal y realizar automáticamente la reserva de las cantidades especificadas en el pedido.

3.1.9.1.2.- Entradas.

IENTE. • Código del Tipo de Papel. • Cantidad en kilos. • Fecha de Pedido.

• Listado de Facturas Pendientes de Cobro, informará sobre todas las F_CLIENTE emitidas a CLIENTES para los cuales no se ha producido todavía el COBRO.

2

e

iones generales.

aje programación utilizado será COBOL 400 eguir los estándares de la programación estructurada.

pos ones y dependencias.

D la osibilidad de desarrollar en el futuro la aplicación de COBROS A

detalle.

s Específicos.

quisi os funcionales. ……………

3

.- Especificación.

Este proceso deberá realizar la captura de todos los datos de un pedido de CLIENTE por ter

Por pantalla: datos para codificar el pedido: • Código del CL

Departamento de Computación UNAN - León

Page 120: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 120 de 316

• Fecha de Entrega.

Datos proporcionados por el sistem

a:

cliente. • Límite de cantidad pedida. • Límite de importe de pedido. • Tipo de cliente.

• Precio por kilo. • Gramaje. • Cantidad Actual en Almacén.

a en Almacén.

3.1.9.1.3.- Proceso.

de introducción de datos al usuario. El número

necesarios a introducir serán:

• Código del cliente: es un dato obligatorio. Debe existir el fichero maestro de clientes o se indicará un error.

digo del Tipo de Papel: es un dato obligatorio. El chero maestro de Tipos de

de no existir se indicará un mensaje de

dato obligatorio. Se deberá que existe cantidad suficiente en el almacén

e entrega: dato obligatorio.

A pa porte del Pedido automáticam nte

Referente al cliente: • Nombre del cliente. • Dirección del

Referente al Tipo de Papel: • Descripción del Tipo de Papel.

• Cantidad Reservad

Se mostrará la pantallacon que se registrará el nuevo pedido será asignado automáticamente de manera correlativa. Los datos

en

• Cócódigo deberá existir en el fiPapel. En caso error.

• Cantidad pedida en kilos:

comprobarpara satisfacer la cantidad pedida.

• Fecha de pedido: dato obligatorio.

• Fecha d

rtir de estos datos se calculará el Ime .

Departamento de Computación UNAN - León

Page 121: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 121 de 316

3.1.9.1.4.- S ida

Con to nará el Pedido en la base de datos del sistema, y se registrará la reserva de mercancía correspondie

3.1.9.2.- Interfaces externas. 3.1.9.2.1.- Interfac de

La captura de datos del pedido se realizará de forma interactiva por pantalla.

3.1.9.2.2.- Interfac ha

Se podrá iza inal conectado al ordenador central.

3.1.9.2.3.- Interfaces software. ractúa con la base de datos de ficheros maestros .

a interfaz de comunicaciones en la aplicación. …………………………………………… 3.2.- Requisitos de fun ona Requisitos estáticos: no existe ninguna restricción sobre el número de terminales y de usuarios que estén aba Requisitos dinámicos: es exponencialmente con el número de usuarios. 3.3.- Restricciones de diseñ El formato de pantallas y listados de la aplicación deberá contener información acerca del Nombre d a E realiza el trabajo, la fecha y la hora del trabajo. 3.4.- Atributo

3.4.1.- Seguridad. Todos los programas de la aplicación deberán estar protegidos mediante autorizaciones de uso.

al s.

dos los datos mencionados se almace

nte al pedido.

es usuario.

es rdware. r termutil r cualquie

El proceso inteya mencionada

3.1.9.2.4.- Interfaces de comunicaciones. No existe ningun

ci miento.

tr jando simultáneamente con el sistema.

importante que el tiempo de respuesta no aumente

o.

e l mpresa, el Nombre del usuario que

s.

Departamento de Computación UNAN - León

Page 122: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 122 de 316

3.4.2.-

en las fases de análisis, diseño y programación.

3.4.3.- Ayuda en línea.

Debidalos procesos del sistema deberán contar con una ayuda en línea.

3.5.- Otros re

3.5.1.- Base de datos.

El almacenamiento de información se realizará por medio de una base

3.5.2.- Operaciones.

datos de realizarán según lo mencio

Mantenimiento.

Cualquier modificación que afecte a los requisitos mencionados en este documento, deberá ser reflejada en el mismo, así como la documentación obtenida

a la carencia de base informática de los usuarios finales todos

quisitos.

de datos relacional.

Todas las operaciones sobre la base de

nado en el subapartado de Seguridad.

Departamento de Computación UNAN - León

Page 123: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 123 de 316

TTRRUUCCTTUURRAADDOO

MMÉÉTTOODDOOSS DDEE AANNÁÁLLIISSIISS DDEE RREEQQUUIISSIITTOOSS:: AANNÁÁLLIISSIISS EESS

Departamento de Computación UNAN - León

Page 124: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 124 de 316

7.6 Métodos de Análisis de Requisitos: Análisis Estructurado

Título del tema 5: Métodos de Análisis de Requisitos: Análisis Estructurado.

Objetivos: • Comprender la importancia del Análisis Estructurado, cómo un método

de análisis de requisitos, que nos permite crear modelos de información.

• Explicar en qué consiste el Análisis Estructurado.

• Explicar el Diagarama de Flujo de Datos (DFD), y su utilidad en la representación del flujo de la información.

• Mostrar con un ejemplo, la creación de un modelo de flujo de datos.

• Dar a conocer el Diccionario de Requisitos y su estructura.

• Explicar en qué consisten las herramientas CASE.

Contenido: • Análisis.

• Análisis estructurado

o Historia

o Notaciones básicas

• Diagramas de Flujo de Datos (DFD).

• Elementos un DFD.

• Mecánica del análisis estructurado.

o Creación de un modelo de flujo de datos.

• Ejemplo 1 de creación de un modelo de flujo de datos: “Gallo Pinto”.

• Ejemplo 2 de creación de un modelo de flujo de datos: “Hogar Seguro”.

• Ejemplo 3 de creación de un modelo de flujo de datos: “Empresa Comercializadora de Productos”.

Departamento de Computación UNAN - León

Page 125: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 125 de 316

• Diccionario de Requisitos.

o Formato del Diccionario de Requisitos.

Definición de almacenes.

o Definición de Base de Datos.

o Definición de base de datos tipo “Lista Invertida”.

o Definición de base de datos “Relacionales”.

o

o Definición de base de datos tipo “Jerarquica”.

o Definición de base de datos tipo “Red”.

• Diccionario de datos mecanizado.

• Análisis estructurado e Ingeniería del software asistida por computadora.

Du irac ón:

• 10 horas

Bibliografía básica: •

on Educación. • Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

• Ver bilbliografía adicional al final del capítulo.

Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pears

Departamento de Computación UNAN - León

Page 126: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 126 de 316

7.6.1 Análisis

• Es el estudio de un problema antes de tomar una acción.

• El producto nto de especificación de requisitos.

Hasta hace unos años, la mayoría de los prbasaban en la creación erimientos de los usuarios, en muc mas siguientes:

1. Sistemas 2. Sistemas muy redundantes. 3. Sis4. Sistemas de difícil mantenimiento. 5. Sis

Para tratar de solucionar estos problemas se introdujo lo que se ha llamado "Análisis Estructurado".

7.6.2 rado El análisis estructurado, como todos los demás métodos de análisis de requisitos, es una actividad de construcción de modelos. Mediante una notación que es única del método l contenido de la información (datos y control)según los distintos comportamientos, establecemos la esencia de lo que se debe constr ir. l que se aplica siempre de la misma forma. Ha evolucionado durante los últimos 20 años.

istoria

os primeros trabajos sobre modelos de análisis aparecieron a finales de los 60 y rincipios de los 70, pero la primera aparición del enfoque de análisis estructurado

fue como complemento de otro tema importante -el “diseño estructurado”. El termino “análisis estructurado” fue popularizado por DeMarco [1] que presentó y denominó los símbolos gráficos clave que permitirían a un analista crear modelos de flujo de información; sugirió heurísticas para utilizar esos símbolos; sugirió el uso de un diccionario de datos y narrativas de procesamiento como complementos a los modelos de flujo de información. En los años siguientes, Page-Jones [2], Gane y Sarson [3] y muchos otros propusieron variaciones del enfoque de análisis estructurado. A mediados de los 80, comenzaron a hacerse evidentes las deficiencias del análisis estructurado (cuando se intentaba aplicar el método a aplicaciones orientadas a

que se obtiene es el docume

oyectos de desarrollo de sistemas se de un modelo que recogía las necesidades y requhos volúmenes, los cuales tenían los proble

poco modulares.

temas ambiguos.

temas excesivamente físicos.

Análisis Estructu

de análisis estructurado, creamos modelos que reflejan el flujo y e; partimos el sistema funcionalmente y,

u E análisis estructurado no es un método sencillo

H Lp

Departamento de Computación UNAN - León

Page 127: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 127 de 316

control). Las “ampliaciones” para tiempo real fueron introducidas por Ward y Mellor or Halley y Pirbhai [5].

otaciones básicas

A medida que fluye por un sistema basado

ansforma a acepta entradas en una gran variedad de formas, aplica los

que se encuentra en un dispositivo de almacen ie mación puede ser, desde una sencilla comparación lógica, hasta un complejo algoritmo numérico o un mecanismo de reglas d fe lida puede ser el encendido de un diodo de m e 200 páginas. Podemos crear un

odelo flu a, independientemente del

cas de este modelo de flujo son:

• Productos altamente mantenibles.

• Método para particionar problemas complejos.

♦ Diagramas de descomposición de procesos. ♦ Diagramas de flujo de datos. ♦ Diagrama de transición de estado. ♦ Diagrama de Entidad-Relación (Modelo de Datos).

♦ DD (Diseño de Datos).

[4] y, más tarde, p

N

en computadora, la información se . El sistemtr

elementos de hardware, software y humanos para transformar la entrada en salida y produce salida en una gran variedad de formas. La entrada puede ser una señal de control transmitida por un controlador; una serie de números escritos en el teclado or un operador humano, un paquete de información transmitido por un enlace de p

una red o un archivo voluminoso de datos am nto secundario. La transfor

e in rencia de un sistema experto. La sad e isión de luz (LED) o un informe

de jo para cualquier sistema de computadormtamaño y de la complejidad. as característiL

• Uso de gráficas.

• Construcción de un modelo del sistema lógico.

• Uso de Herramientas.

• Uso de técnicas.

♦ Lenguaje estructurado. ♦ Tablas de decisión. ♦ Arboles de decisión. ♦ Diagramas de acción.

Departamento de Computación UNAN - León

Page 128: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 128 de 316

Diferencias entre la especificación funcional y la especificación estructurada ESPECIFICACION FUNCIONAL ESPECIFICACION ESTRUCTURADA El texto se introduce en detalles

pasos iniciales. Presenta primero un gran cuadro, con la intensión de ir de lo abstracto al detalle. inmediatamente en los

No es gráfica Es gráfica Unidimensional Multidimensional

7.6.2.1 Diagrama de Flujo de Datos – DFD El diagrama de flujo de datos (DFD) es una técnica gráfica que representa el flujo de información y las transformaciones que se aplican a los datos al moverse desde la entrada a la salida. El DFD también es conocido como grafo de flujo de datos o como diagrama de burbujas. Se puede usar el DFD para representar un sistema o un software a cualquier nivel de abstracción. Así, un DFD de nivel 0 también es denominado modelo fundamental del sistema o modelo de contexto, y representa al elemento de software completo omo una sola burbuja con datos de entrada y de salida representados por flechas

rtir el DFD de nivel 0 para mostrar ás detalles, aparecen representados procesos (burbujas) y caminos de flujo de

inform ció D de nivel 1 puede contener cinco o eis burbujas con flechas interconectándolas. Cada uno de los procesos

repre nta general en el modelo del ontexto.

n la Figura 7.6.1 se ilustra la notación básica que se usa para crear un DFD.

Figura 7.6.1 Notación DFD básica.

cde entrada y de salida, respectivamente. Al pam

a n adicionales. Por ejemplo, un DFs

se dos en el nivel 1 es una subfunción del sistemac

E

idor de información que reside fuera de los límites del sistema a Un productor o consum stino ser modelado. Origen /De eside dentro de los límites del sistema a ser mo- Un transformador de información que r bia de alguna forma. delado. Se aplica a los datos (o al control) y los cam Transformación de los datos olección de elementos de datos; la cabeza de la flecha in- Un elemento de datos o una c atos. Todas las flechas de un DFD deben estar etiqueta- dica la dirección del flujo de d Elemento das. Datos en Movimiento de datos uardan para ser usados por uno o más procesos; puede ser tan Un depósito de datos que se g sencillo como un buffer o una cola, o tan sofisticado como una base de datos relacional. Datos en Reposo

Entidad externa

Proceso

Almadatos

cén de

Departamento de Computación UNAN - León

Page 129: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 129 de 316

El diagrama no proporciona ninguna indicación explícita de la secuencia de rocesamiento. El procedimiento o la secuencia pueden estar implícitamente en el

n proce a

1. Es una técnica gráfica en red, de un sistema.

do sus componentes y las conexiones entre ellos.

• No requieren nombres aquellos que entran y salen de almacenes simples.

• Puede representarse varias veces en un DFD.

pdiagrama, pero la representació dimental explícita generalmente quedpospuesta hasta el diseño del software. En resumen:

2. Representa el sistema mostran

Los componentes del DFD son:

1. Flujo de Datos

• Camino a través del cual fluyen paquetes de información de una composición conocida.

• Los nombres son elegidos en función de los datos que se mueven y

de lo que sabemos acerca de ellos.

• Datos diferentes fluyendo entre los procesos no constituyen un paquete.

• No es un flujo de control.

• No es un activador de procesos.

2. Procesos • Muestran el trabajo realizado con los datos. • Tendrán número y nombre único.

• El nombre debe de describir claramente el proceso.

3. Almacén de datos

• Depósito temporal de datos.

• Deben llevar un nombre.

Departamento de Computación UNAN - León

Page 130: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 130 de 316

• No existe diferencia entre base de datos y ficheros convencionales.

4. Entidad Externa

• Persona u organización que no pertenece al sistema y que origina o recibe datos del sistema.

• Aparece sólo en el DFD de mayor nivel.

a información acerca de la conexión con el mundo

Se puede re amayor detalle. La Figura 7.6.2 muestra este concepto. El modelo fundamental del sistema F presenta la entrada principal A y la salida final B. Refinamos el modelo F en las transfflujo de informac lida de cada refinamiento debe ser la misma. Este concepto, a veces también es denominado equilibrado. Un mayor refinamiento f45. De nuevo, la entrada (X, Y) y la salida (Z) permanecen inalteradas.

del flujo de información.

• Suministr

exterior.

Puede representarse varias veces en un DFD.

fin r cada una de las burbujas en distintos niveles para mostrar un

ormaciones f1 a f7. Observe que se debe mantener la continuidad del ión, es decir, que la entrada y la sa

de f4 muestra más detalle en la forma de las transformaciones f41 a

F A B

Figura 7.6.2 Refinamiento

f1

f2

f3

f4

f5

f6

f7

f41 f43

f42 f44

f45

A

V X

W

Z z1z2

z3

B Y

x1

y1

x2

y2

X

Y

Z

Departamento de Computación UNAN - León

Page 131: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 131 de 316

La notación b iara describir los requisitos del software. Por ejemplo, una flecha de un DFD presenta un elemento de datos que entra o sale de un proceso. Un almacén de

datos representa alguna colección organizada de datos. Pero, ¿cuál es el contenido e los datos implicados en las flechas o en el almacén? Para responder a esta

pregunta, ap-el diccionario de requisitos, también denominado diccionario de datos. El formato y el uso del diccionario de requisitos se explican más adelante. Finalmente, ncon texto descriptivo. Se puede usar especificar los detalles de procesamiento que implica una burbuja del DFD. Esta narrativa des b lica a esa entrada y

salida que se puestas al proceso, las características de rendimiento que son relevantes al

e requisitos el software, se ha de combinar esa notación con un conjunto de heurísticas que ermitan al ingeniero del software derivar un buen modelo de análisis.

uno de los pasos que se deben seguir para

desarrollar modelos completos y precisos mediante el análisis estructurado.

7.

cabo implícitamente una descomposición funcional del sistema. Al mismo tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida que se

• El diagrama de flujo de datos de nivel 0 debe reflejar el software/sistema

como una sola burbuja.

• Se deben anotar cuidadosamente la entrada y la salida principales.

• El refinam entos de datos y los alm sentados en el siguiente nivel.

ás ca que se usa para desarrollar un DFD no es en sí misma suficiente pre

dlicamos otro componente de la notación básica del análisis estructurado

la otación gráfica representada en la Figura 7.6.2 debe ser ampliada una narrativa de procesamiento para

cri e la entrada a la burbuja, el algoritmo que se approduce. Además, la narrativa indica las restricciones y limitaciones la

improceso y las restricciones de diseño que pueden tener influencia en la forma de implementar el proceso.

7.6.3 Mecánica del análisis estructurado Para poder utilizar eficientemente las notaciones básicas en el análisis ddp

A continuación, se examina cada

6.3.1 Creación de un modelo de flujo de datos

A medida que se refina el DFD en mayores niveles de detalle, el analista lleva a

mueven a través de los procesos que componen la aplicación.

Unas pocas directrices sencillas pueden ayudar de forma considerable durante la derivación de un diagrama de flujo de datos:

iento debe comenzar aislando los procesos, los elemacenes de datos que sean candidatos a ser repre

Departamento de Computación UNAN - León

Page 132: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 132 de 316

• Todas las flechas y las burbujas deben ser etiquetadas con nombres significativos.

• Entre sucesivos niveles se debe mantener la continuidad del flujo de

información.

• Se deben refinar las burbujas de una en una. Para ilustrar el uso de estas directrices básicas, usaremos tres ejemplos de la vida

permite al usuario conocer el proceso de elaboración del lato típico de Nicaragua, llamado gallo pinto. Dicho plato tiene unos pasos de laboración, que podemos resumir así:

en a hervir los frijoles al fuego. La

hasta que los

edar lo más suelto posible, para efectos del futuro gallo pinto. Para hacer el arroz,

arroz en una cazuela con aceite uede totalmente cubierto por el

aceite; agregue cebolla y sal al gusto; revuelva y revuelva el arroz hasta que

ela del fuego y deje reposar al arroz.

• el siguiente paso es

preparar el gallo pinto: ponga una cazuela a fuego lento con aceite y cebolla

regue el arroz y revuelva hasta obtener una mezcla bien hecha; puede agregar sal si lo desea; espere 5 minutos y vuelva a

entonces retire la cazuela del fuego

real.

7.6.4 Ejemplo 1: Creación de un modelo de flujo de datos: “Gallo Pinto”. A continuación, mostramos una narrativa de procesamiento de dicho sistema: El software “GalloPinto”, pe

• Antes de hacer ningún otro paso, se poncantidad puede ser de una libra de frijoles crudos. Con una libra de frijoles, usted puede usar 2 litros y medio de agua para hervirlos. Agregue antes de que el agua esté hirviendo, una o dos cabezas de ajos. Cuando el agua empiece a hervir, agregue sal al gusto. Espere una media hora, frijoles estén suaves.

• Luego de tener cocidos los frijoles, prepare el arroz. El arroz debe qu

siga los siguientes pasos: eche una libra decaliente; revuelva el arroz bien hasta que q

tenga un color dorado; una vez dorado el arroz, eche un litro de agua tibia al arroz, revuelva bien y deje reposar; agregue a continuación trozos de chiltomas al gusto; tape la cazuela y espere por quince minutos hasta que el arroz esté suave. Una vez suave el arroz, retire la cazu

Una vez que se tienen el arroz y los frijoles listos,

al gusto; a continuación eche los frijoles cocidos con poquísima sopa y sofría por 8 minutos; luego ag

revolver; repita lo anterior hasta que sienta que la mezca está frita,

El gallo pinto está ya listo para servirse a la mesa.

Departamento de Computación UNAN - León

Page 133: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 133 de 316

Lo solicitado en este ejemplo es: Descomponer en procesos la receta para elaborar n buen gallo pinto al estilo nicaragüense.

olución:

u

S

0

GENERAREL GALLO PINTO

COCINA MESA

Utenciliospara GP

Gallo PintoIngredientesGP

Project Name:Projec

Proyecto del Gallo Pintot Path:

Chart File:Chart Name:

Modified On:

d:\misdoc~1\cl7d0c~1\anbf28~1\ejerce~1\gallop~1\dfd00001.dfdDiagrama de Contexto del GP

Apr-22-2003

Created On:Created By:

Apr-22-2003Danilo

Modified By: Danilo

Figura 7.6.3 DFD de nivel 0 del GalloPinto.

Departamento de Computación UNAN - León

Page 134: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 134 de 316

Project Name: Proyecto del Gallo Pinto

1

PREPARARARROZ

2

PREPARARFRIJOLES

3

ELABORARGALLO PINTO

Almacende Arroz Cocinado

Almacen deFrijoles Cocidos

FrijolesCocidos

Arroz Cocinado

FrijolesCocidos

Ing de Arroz

Uten de ArrozIng de Frijoles

Uten de Frijoles

Ing PrepararGP

Uten prepararGP

Gallo Pinto

Arroz Cocinado

Project Path:Chart File:

Created By:Modified On:Modified By:

d:\misdoc~1\cl7d0c~1\anbf28~1\ejerce~1\gallop~1\dfd00002.dfdGENERAR EL GALLO PINTOApr-22-2003DaniloApr-22-2003Danilo

Figura 7.6.4 DFD de nivel 1 del GalloPinto. En el DFD de nivel 0 representado en la Figura 7.6.3 , podemos observar las entidades externas COCINA y MESA. La entidad externa COCINA proporciona los flujos de datos Ingredientes GP y Utencilios para GP. Ingredientes GP es un flujo de datos que nos proporciona información sobre los ingredientes que se necesitarán para elaborar el gallo pinto. Pero, ¿dónde se encuentra esa información? La respuesta a esta pregunta se encuentra más adelante en este mismo tema, donde se explicará el Diccionario de Requisitos. De igual manera sucede con el flujo de datos Utencilios para GP: es un flujo de datos que nos brinda información acerca de qué utencilios son necesarios para elaborar el gallo pinto.

Chart Name:Created On:

Departamento de Computación UNAN - León

Page 135: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 135 de 316

¿A quién proporciona dicha información la entidad externa COCINA? La respuesta s simple: al proceso encargado de generar el gallo pinto, que en este nivel de e

contexto o nivel cero, está representado en una sola burbuja con el nombre “GENERAR EL GALLO PINTO”. A su vez, la burbuja “GENERAR EL GALLO PINTO”, produce un flujo denominado Gallo Pinto, que alimenta a la entidad externa MESA. Este flujo representa en sí, el plato ya preparado y listo para ser servido a la mesa. Igual que antes, en el Diccionario de Requisitos se puede mirar la descripción de este flujo. La entidad externa MESA, representa un objeto del mundo real, en la cual se sirve el producto elaborado. En este caso, MESA, no produce ningún tipo de información necesaria para la elaboración del gallo pinto, tan sólo es consumidora del flujo de información Gallo Pinto. En la Figura 7.6.4 se muestra la descomposición del GalloPinto, en el nivel 1. A como se puede observar, hay 3 procesos dentro de este nivel, enumerados del 1 al 3. Cada proceso, además de tener un número, debe tener también un nombre; dicho nombre debe dar una idea de lo que el proceso en cuestión realiza. Así, el proceso 1 llamado PREPARAR ARROZ, da una idea clara de lo que este proceso hace: preparar el arroz y producir un flujo de información correspondiente al arroz cocinado -Arroz Cocinado-, y dejarlo almacenado en un almacén. La misma idea se aplica al proceso PREPARAR FRIJOLES. De nuevo, este proceso origina un flujo de información correspondiente a los frijoles cocidos y los deja almacenados en otro almacén. Estos almacenes pueden ser, desde simples ficheros, hasta bases de datos relacionales complejas. Una vez que se tiene preparado el arroz y los frijoles, se procede a la elaboración del gallo pinto. Esto lo hacemos con el proceso ELABORAR GALLO PINTO, el cual toma como entradas las salidas de los almacenes descritos anteriormente (más otras entradas adicionales que se explicarán más adelante) y origina el flujo de datos Gallo Pinto. Este flujo de datos, representa el producto alimenticio preparado y listo para servirse a la mesa.

Departamento de Computación UNAN - León

Page 136: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 136 de 316

7.6.5 Ejemplo 2: Creación de un modelo de flujo de datos: “Hogar Seguro”.

Ahora usaremos el ejemplo del sistema de seguridad HogarSeguro. A continuación, mostramos una narrativa de procesamiento de dicho sistema: El software HogarSeguro permite al propietario de la vivienda configurar el sistema de seguridad al instalarlo; controla todos los sensores conectados al sistema de seguridad e interactúa con el propietario a través de un teclado numérico y unas teclas de función que se encuentran en el panel de control de HogarSeguro que se

uestra en la Figura 7.6.5.

naturaleza del suceso detectado. Cada 20 segundos

, muestra mensajes de petición en un monitor LCD y uestra información sobre el estado del sistema en el monitor LCD. La interacción or teclado toma la forma de la Figura 7.6.5.

m Durante la instalación, se usa el panel de control de HogarSeguro para “programar” y configurar el sistema. Cada sensor tiene asignado un número y un tipo; existe una contraseña maestra para activar y desactivar el sistema, y se introduce(n) un(os) teléfono(s) con los que contactar cuando se produce un suceso detectado por un sensor. Cuando el software detecta la sensorización de un suceso, hace que suene una alarma audible que está incorporada en el sistema. Tras un retardo, especificado por el propietario durante la configuración del sistema, el programa marca un número de teléfono de un servicio de monitorización, proporciona información sobre la situación e informa sobre la se volverá a marcar el número de teléfono hasta que se consiga establecer la comunicación. Toda la interacción con HogarSeguro está gestionada por un subsistema de interacción con el usuario que lee la información introducida a través del teclado numérico y las teclas de funciónmp

Departamento de Computación UNAN - León

Page 137: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 137 de 316

isten realmente en colecciones de otros muchos elementos de datos dicionales. Por ejemplo, órdenes y datos de usuario engloba todas las órdenes

Figura 7.6.6 DFD de nivel contextual para HogarSeguro.

HogarSeguro desactivado fuera en casa max prueba desvío inmediato código zumbido preparado activado potencia

Figura 7.6.5 Panel de Control de HogarSeguro.

En la Figura 7.6.6 se muestra el DFD de nivel 0 para HogarSeguro. Las flechas etiquetadas representan elementos de datos compuestos, es decir, elementos de datos que cons

01 fuera alarma en casa comprobación inmediato fuego desvío no preparado

4 65

7 98

* #0

ade configuración, todas las órdenes de activación/desactivación, todas las variadas interacciones y todos los datos que se introducen para cualificar o ampliar una orden.

Ordenes y datos Información del usuario a visualizar Tipo de alarma Estado del sensor Tonos del número de teléfono

Panel de control

Sensores

Monitor de panel de control

Alarma

Línea telefónica

Software HogarSeguro

Departamento de Computación UNAN - León

Page 138: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 138 de 316

Ahora, tenemos que expandir el DFD de nivel 0 a un modelo de nivel 1. Una sencilla, pero efectiva, técnica consiste en realizar un “análisis gramatical” de la narrativa de procesamiento que describe la burbuja de nivel contextual. Es decir, aislar todos los nombres (y sentencias nominales) y todos los verbos (y sentencias verbales) de la n rrativ rriba cimos de nuevo la narrativa de procesamiento, subrayando las primeras ocurrencias de los nombres y con las primeras ocurrencias de los verbos en cursiva: El software

a a presentada a . Para ilustrarlo, reprodu

HogarSeguro permite al propietario de la d vivien a configurar el sistema de seguridad al instalarlo ; controla sensores todos los conectados al sistema de seguridad e interactúa con el propietario a través de un teclado numérico y unas teclas de función que se encuentran en el panel de control de HogarSeguro que se muestra en la Figura 7.6.5. Durante la instalación, se u a el pa el de c ntrol ds n o e HogarSeguro para “programar” y configurar el sistema. Cada sen r tieneso asignado un número y un tipo ; existe una contraseña maestra para

l siste e ma, y se introduce(n) un(os) teléfono(s)activar y desactivar con los que contactar cuando se produce un suceso detectado por un sensor. Cuando el software detecta la sensorización de un suceso, hace que suene una alarma audible que está incorporada en el sistema. Tras un retardo, especificado por el propietario durante la configuración del sistema, el programa marca un número de teléfono de un servicio de monitorización, proporciona información sobre la situación e informa sobre la naturaleza del suceso

etectado. Cada 20 segundos se volverá a marcar el número de teléfono hasta que se consiga establecer la comunicd

ación. Toda la interacción con HogarSeguro está gestionada por un subsistema de interacción con el usuario que lee la información introducida a través del teclado numérico y las teclas de función, muestra mensajes de petición en un monitor LCD y muestra información sobre el estado del sistema en el monitor LCD. La interacción por teclado toma la forma ... Se ignoran los nombres y los verbos que sen sinónimos o que no incumban directamente al proceso de modelización. Todos los verbos son procesos de HogarSeguro representados como burbujas en el onsiguiente DFD. Todos los nombres son, o bien entidades externas (cuadros),

elementos de datos o de control (flechas) o almacenes de datos (líneas dobles). Además, los nombres y los verbos están relacionados entre sí (p. ej.: cada sensor

c

tiene asignado un número y un tipo). Usando esa información obtenemos el DFD de nivel 1 que se muestra en la Figura 7.6.7.

Departamento de Computación UNAN - León

Page 139: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 139 de 316

Ordenes y datos del usuario Datos de configuración

Petición de Información de

Datos de

nsor Tipo de alarma

Figura 7.6.7 DFD de nivel 1 para HogarSeguro.

e pueden refinar en posteriores niveles los procesos representados en el DFD de

nte como una componente del programa. odríamos decir que el refinamiento de los DFDs sigue hasta que cada burbuja sea na idea”.

urante el análisis de requisitos, el ingeniero del software puede detectar ciertos spectos del sistema que “son susceptibles al cambio” o que “serán mejorados en el turo” o que han sido definidos por el cliente de forma poco clara. También puede

er que el analista esté trabajando sobre un software existente que va a ser osteriormente modificado. En cualquiera de estos casos, el diagrama de flujo de atos permite aislar fácilmente el campo de cambio.

configuración configuración Datos de configu- Inicio/ ción parada

Contraseña configuración Mensaje de activación/ Información desactivación a visualizar

Monitor de panel

Panel de control

Mensaje de identificación válida

In Información

de sensor Estado del se

Tonos del número de teléfono

Snivel 1. Por ejemplo, se puede refinar el proceso Monitorizar sensores al DFD de nivel 2 que se muestra en la Figura 7.6.8. El refinamiento de los DFDs continúa hasta que cada burbuja representa una función sencilla, es decir, hasta que el proceso que representa la burbuja realiza una función que se puede implementar fácilmeP“u Dafuspd

Sensores

de control

Alarma

Configurar el sistema

Interaccionar con el usuario

Activar/ desactivar el

sistema

Procesar contraseña

Visualizar mensajes y

estado

Monitorizar sensores

Línea telefónica

Departamento de Computación UNAN - León

Page 140: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 140 de 316

Departamento de Computación UNAN - León

.

Información del sensor

Información y ubicación de

configuración sensor

Datos de Datos Tipo configuración de alarma

ID de tipo de sensor Número de de teléfono

del

ensor

Figura 7.6.8 DFD de nivel 2 que refina el proceso Monitorizar Sensores

ID de tipo de

de alarma Tonos Estado del s

número de teléfono

Leer sensores

Comprobar con los ajustes iniciales

Dar formato para visualización

Generar señal de alarma

número Marcar

Page 141: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 141 de 316

7.6.6 Ejemplo 3: Creación de un modelo de flujo de datos: “Empresa Comercializadora de Productos”.

Enunciado del problema

mpresa se dedica a vender pr sus clientes, por medio del contacto d mpres

ontacta con los proveedores que pueden servir dichos pedidos. Cada pedido se olicita a un proveedor, por medio de una Orden de Compra que se envía a éste. La

los productos, por lo cual actúa omo intermediario e roveedores ntes.

os prove directamente a los clientes los productos citados en la rd compra, por lo cual ésta deb ontener los datos del cliente necesarios ara el envío. Cuando se genera una nueva Compra, la empresa elecciona el proveedor que ofrece el mejor precio del producto pedido, entre todos s proveedores que sirven ese producto. Para poder tomar esta decisión, la

empr los rodu dor

io de precios o cuando empieza a uministrar un nuevo producto.

l final de cada mes se genera una factura para cada cliente, que recoge el total de dos los pedidos realizados por éste y para los que se ha generado una Orden de ompra. Cada nuevo cliente informa a la empresa sobre todos sus datos.

Una econ

oductos a eterminados proveedores. La e a recibe pedidos de sus clientes, y

csempresa no dispone de almacén en el que guardarc ntre p y clie L edores envíanO en de e cps

Orden de

loesa dispone de los catálogos enviados por los proveedores, que contienenctos que pueden suministrar y el precio de cada producto. Cada proveep

envía un catálogo cada vez que hay un cambs AtoC

Departamento de Computación UNAN - León

Page 142: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 142 de 316

Solución:

0

GESTIONPEDIDO CLIENTE

CLIENTES PROVEEDORESPedido Cliente Orden Compra

Factura

Datos ClienteNuevo

Catalogos

Project Name: Proyecto Empresa Comercializadorc~1\analis~1\ejease~1\

como se puede ver en el DFD de nivel 0, mostrado en la Figura 7.6.9, las ntidades externas que surgen como consecuencia del análisis de problema, son LIENTES y PROVEEDORES. Ambas se retroalimentan con la burbuja de nivel 0, ESTION DE PEDIDO CLIENTE. La entidad externa CLIENTES suministra al

istema los datos de un cliente nuevo (mediante el flujo Datos Cliente Nuevo), y los atos relativos al pedido de un cliente (mediante el flujo Pedido Cliente). El sistema roduce un flujo Factura, el cual es consumido por CLIENTES; esto es, el sistema rigina una factura al final de cada mes, que es entregada a cada cliente que haya alizado un pedido.

a entidad externa PROVEEDORES alimenta al sistema con el flujo Catalogos, porque los proveedores envían catálogos a la Empresa para mantenerla actualizada con los precios de los productos. A su vez, el sistema genera un flujo Orden Compra, el cual es consumido por PROVEEDORES; esto es así porque la Empresa envía órdenes de compra a los proveedores, para que éstos puedan entregar los productos a los clientes.

Project Path:Chart File:

d:\misdoc~1\cl7d0dfd00001.dfd

Chart Name:Created On:Created By:Modified On:Modified By:

Diagrama de ContextoMay-03-2002DaniloMay-03-2002Danilo

Figura 7.6.9 DFD de nivel 0 GESTION PEDIDO CLIENTE.

AeCGsdpore L

Departamento de Computación UNAN - León

Page 143: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 143 de 316

1

CAPTURACLIENTE

2

CAPTURAPEDIDO

3

CAPTURACATALOGO

5GENERARORDEN COMPRA

4

EMITIRFACTURA

AlmacenDatos Cliente

AlmacenPedido Cli

AlmacenCatalogo

Datos ClienteNuevo

Pedido Cliente Catalogos

Datos Cliente Pedidos Cli Catalogo Prov

Datos ClientePedidos Cli Pedidos Cli Catalogo Prov

Factura Orden Compra

Project Name:Project Path:Chart File:

Created By:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00002.dfdGESTION PEDIDO CLIENTEMay-03-2002DMay-03-2002Danilo

Figura 7.6.10 DFD de nivel 1 GESTION PEDIDO CLIENTE. En la Figura 7.6.10 se puede ver el DFD de nivel1 para GESTION PEDIDO CLIENTE. Una recomendación que se suele seguir por los analistas de sistemas es, identificar los flujos de datos que le llegan a la burbuja de nivel 0 y convertirlos en procesos para en el nivel 1. Así, por ejemplo, Pedido Cliente, Datos Cliente Nuevo y Catalogos, se convierten en los procesos CAPTURA PEDIDO, CAPTURA CLIENTE y CAPTURA CATALOGO respectivamente.

Chart Name:Created On:

aniloModified On:Modified By:

Departamento de Computación UNAN - León

Page 144: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 144 de 316

De igual forma, se identifican los flujos que produce la burbuja de nivel 0, y se convierten en procesos del nivel 1. Así, Factura y Orden Compra, se convirten en los procesos EMITIR FACTURA y GENERAR ORDEN COMPRA. El proceso EMITIR FACTURA, toma como entradas el flujo del Almacén Datos Cliente y el flujo del Almacén Pedido Cli, para producir la facutura del cliente. El mismo razonamiento se hace para el proceso GENERAR ORDEN COMPRA. A continuación, se muestra la explotación del proceso 4, EMITIR FACTURA:

4.1ACUMULARTOTAL PEDIDO

4.2

IMPRIMIRFACTURA

Pedido Cli

Datos Clientes

Importe Total

Factura

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00003.dfdEMITIR FACTURAMay-03-2002DaniloMay-03-2002Danilo

Figura 7.6.11 DFD de nivel 2 que refina el proceso EMITIR FACTURA.

como se puede ver en Figura 7.6.11, es necesario explotar el proceso EMITIR

e de datos los pedidos de los lientes, ubicar a un cliente en específico, y sumar todos los pedidos que pudiese

AFACTURA, ya que para imprimir una factura de cobro para un cliente, primero habrá que acumular los pedidos que ha realizado éste a la empresa durante un mes. Ya que este proceso no es una función sencilla porque habrá que hacer dos funciones: acumular el total de pedidos y luego imprimir la factura, habrá que explotarlo para simplificar aun más y hacer más entendible el diagrama.

cumular el total de pedido, implicaría buscar en la basAc

Departamento de Computación UNAN - León

Page 145: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 145 de 316

tener dicho cliente al fin de mes. Luego, con ese resultado, se enviaría una órden de imperesión ya sea en impresora o por pantalla, de la factura correspondiente. A continuación se muestra la descomposición del proceso 5, GENERAR ORDEN

E COMPRA. D

5.1SELECCIONMEJOR PROVEEDOR

5.2IMPRIMIRORDEN COMPRA

Catalogo Prov

Mejor Proveedor

Pedidos Cli

Orden Compra

Project Name:Project Path:Chart File:ChaCreaCreated By:Modified On:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00004.dfd

DaniloMay-03-2002

Figura 7.6.12 DFD de nivel 3 que refina el proceso GENERAR ORDEN COMPRA.

A como muestra la Figura 7.6.12, es necesario descomponer el proceso GENERAR ORDEN DE COMPRA, porque para poder generar una órden, primero habrá que seleccionar al mejor proveedor, esto es, al proveedor que ofrezca un mejor precio de el(los) producto(s) solicitado(s) por el cliente. Lo lógico es que el proceso 5.1 SELECCIÓN MEJOR PROVEEDOR, busque en la base de datos el producto de más bajo precio, y a continuación consulte a qué proveedor pertenece ese producto. Una vez teniendo al proveedor indicado, se enviaría una órden de imprimir la órden de compra para el proveedor seleccionado.

rt Name:ted On:

GENERAR ORDEN COMPRAMay-03-2002

Modified By: Danilo

Departamento de Computación UNAN - León

Page 146: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 146 de 316

Una cosa importantísima que se debe cumplir es que, los flujos de datos que se apliquen sobre un proceso (de entrada o de salida) en un nivel superior, se deben respetar si ese proceso se explota en un nivel inferior. Así por ejemplo, al nivel 0 del ejemplo que estamos analizando (el cual es lógico que se explote), tiene como entradas los flujos de datos Pedido Cliente, Datos Cliente Nuevo y Catalogos. Pues en la explotación de dicho nivel, también aparecen los mismos flujos de entrada, pero ahora aplicados a los distintos procesos en los que se ha descompuesto el nivel. Lo mismo sucede con las salidas; las salidas del diagrama de contexto del mismo ejemplo son Factura y Orden Compra, y en la explotación de dicho nivel, o

e algún método para representar el contenido de cada componente del modelo de flujo.

e ha propuesto el diccionario de requisitos (también denominado diccionario de atos) como gramática casi formal para describir el contenido de los objetos

ctualmente, casi siempre se implementa el diccionario de requisitos como parte de

sea en en el nivel 1, las salidas son las mismas: Factura es una salida del proceso 4 EMITIR FACTURA y Orden Compra es una salida del proceso 5, GENERAR ORDEN COMPRA. La misma lógica se sigue aplicando a las sucesivas explotaciones de los sucesivos niveles.

7.6.7 Diccionario de requisitos Un análisis del ámbito de información estaría incompleto si sólo se considera el flujo de la información. Cada flecha del diagrama de flujo de datos representa un elemento de información o varios. Cada almacén de información a menudo es una colección de elementos de datos individuales. Puede que cada elemento de control esté definido en términos de otros elementos de control. Incluso puede que el contenido de una entidad externa requiera ser expandido antes de que su significado pueda ser definido explícitamente. Por tanto, el analista debe disponer d

Sddefinidos durante el análisis estructurado. Esta notación ha sido definida así [6]:

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensión de las entradas, de las salidas, de las componentes de los almacenes y (también) de los cálculos intermedios.

Auna “herramienta CASE de análisis y diseño estructurado”. Aunque el formato del diccionario varía entre las distintas herramientas, la mayoría contiene la siguiente información:

• Nombre: el nombre principal del elemento de datos o de control, del almacén de datos o de una entidad externa.

• Alias: otros nombres usadas para la entrada.

Departamento de Computación UNAN - León

Page 147: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 147 de 316

• Dónde se usa/cómo se usa: un listado de los procesos que usan el elemento de datos o de control y cómo lo usan (p. ej.: como entrada al proceso, como salida del proceso, como almacén de datos, como entidad externa).

scripción del contenido: el contenido representado mediante una notación.

estricciones o limitaciones, etc.

a información de “dónde se usa/cómo se usa” se regista automáticamente a partir

itos omo una base de datos, el analista puede hacer preguntas basadas en dónde se

usa/có La noten la Ftres formas fundamentales de construcción (secuencia, selección o agrupación

petitiva).

• De

• Información adicional: otra información sobre los tipos de datos, los valores

implícitos (si se conocen), las r Una vez que se introducen en el diccionario de requisitos un nombre y sus alias, se debe revisar la consistencia de las denominaciones. Es decir, si un equipo de análisis decide denominar un elemento de datos recién derivado como xyz, la herramienta CASE que soporta el diccionario muestra un mensaje de alerta sobre la duplicidad de nombres. Esto mejora la consistencia del modelo de análisis y ayuda a reducir errores. Lde los modelos de flujo por la herramienta CASE. Durante el análisis, hay una corriente casi continua de cambios. Para proyectos grandes, a menudo es bastante difícil determinar el impacto de un cambio. Al poder tratar el diccionario de requisc

mo se usa y obtener respuestas a peticiones similares a las anteriores.

ación usada para desarrollar una descripción del contenido, que se muestra igura 7.6.13, permite al analista representar los datos compuestos en una de

re

Construcción del dato

Notación Significado

= está compuesto de

Secuencia + y

Selección [ | ] o bien-o

Repetición { }n n repeticiones de

( ) datos opcionales

* * delimita comentarios

Figrequisi

ura 7.6.13 Notación de descripción del contenido para un diccionario de tos.

Departamento de Computación UNAN - León

Page 148: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 148 de 316

Cada entrada de elemento de datos que aparezca como parte de una secuencia, na selección o una repetición puede a su vez ser otro elemento de datos ompuestos que necesite unmayor refinamiento en el diccionario.

rior]

de contenido:

número de teléfono = [extensión local|número exterior] extensión lo . | número exterior = (0) + [ número local | mero número local = prefijo + número de acceso número de larga código de + número prefijo = [ 725 | 474 | 255 | 394] número de acceso = * ualquier caden cuat

entales (elementos que no requieren más expansión) todos los lementos de datos compuestos o hasta que todos los elementos compuestos

aparecen representados en términos bien conocidos y sin ambigüedad para cualquier lector. Para grandes sistemas basados en computadora, el diccionario de requisitos crece rápidamente en tamaño y complejidad. De hecho, es extremadamente difícil mantener manualmente el diccionario. Por esta razón, se deben usar herramientas CASE. Para evitar redundancia en o entre los elementos de la Especificación Estructurada, es esencial saber qué clase de información pertenece a qué parte de la especificación:

uc Volviendo al DFD de nivel 2 del proceso Monitorizar el sistema de HogarSeguro, que se muestra en la Figura 7.6.8, especificamos el elemento de datos número de teléfono: nombre: número de teléfono alias: ninguno dónde se usa/cómo se usa: Comprobar con ajustes iniciales (salida) Marcar número (entrada) descripción: número de télefono = [extensión local|número exte La extensión local y el número exterior son datos compuestos y deben ser refinados en otras sentencias de descripción de contenido. Continuando con la descripción

cal = [ 2001 | 2002 | .. 2999]

nú de larga distancia]

distancia = área local

c a de ro dígitos *

La descripción de contenido es expandida hasta que se hayan representado como datos eleme

Departamento de Computación UNAN - León

Page 149: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 149 de 316

• Información acerca de la composición de los datos (de qué componentes y cómo se interrelacionan estos componentes) va en el Diccionario de Datos.

• Información acerca del contenido y proceso de los elementos (cómo se

rmación acerca de la ruta de los datos va en el Diagrama de Flujo de Datos.

iguiendo estos tres puntos, el Diccionario de Datos no debería contener form a otra parte de la especificación.

n almacén es un depósito temporal de los datos. Los almacenes se definen como

njunto de entradas se subraya.

n. Mediante esta estructura e pue que se solicite.

dos notaciones aracte

1. 2. o (o conjunto de datos elementales) que serán la

a clave primaria es elegida entre las claves candidatas para identificar una entrada imple entre todas en el almacén de datos.

r Base de Datos como dos o más ficheros (almacenes de atos) que se relacionan mediante algún dato/s, a los cuales se puede

• Lista invertida.

l.

establecen sus valores) va en la descripción del proceso.

• Info

Sin ación que estuviese ya presente en algun

7.6.7.1 Definición de almacenes Uentidades repetitivas compuestas de datos y/o grupos de datos. El analista o usuario selecciona uno o más datos para organizar la colección de entradas en un almacen. La clave primaria de ese co El almacén tiene siempre una estructura de organizaciós de sacar cualquier dato almacenado Todas las definiciones de almacenes de datos deben tener

rísticas: c

Un grupo repetitivo general.

Un dato elemental subrayadclave primaria del almacén.

Ls Una tabla de datos tiene las características de un almacén de datos y por esa razón se define en el Diccionario de Datos como un Almacén. Podemos definidacceder de más de una manera. Hay cuatro tipos de Base de Datos que se usan generalmente:

• Jerárquicas. • Red. • Relaciona

Departamento de Computación UNAN - León

Page 150: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 150 de 316

GOYA, 18 98711 2-10-88 20 T300K

3 JUAN RODRIGUEZ ALCALA, 130 987423 2-10-88 14 K07G

K07G 3

De i

n este tipo de Base de Datos, el usuario ve los datos como una gran tabla de reg rprincip os en la gran tabla,

l como se muestra en la Figura 7.6.14.

Figura 7.6.14 Ejemplo de Base de Datos de tipo Lista Invertida.

n el Diccionario de Datos, La Base de Datos se define como:

Un simple almacén de datos con una clave primaria.

n la Base de Datos tipo Jerárquicas el usuario ve los datos organizados en una

n grupo de datos relacionados constituye lo que se llama un tipo de registro. Cada

uchos registros “hijos” relacionados a él, pero un gistro “hijo” sólo tiene un registro “padre”. Como cada registro está unido en una

ede representar con na única entrada al almacén.

La clave principal indica el camino de acceso que se usa con más frecuencia. Índices secundarios (camino de acceso) se definen en la entrada del Diccionario de Datos como comentarios asociados.

PEDIDOS-CLIENTES

fin ción de base de datos de tipo lista invertida

Eist o de datos y algunas tablas más pequeñas, formadas por las claves

ales, que contienen las posiciones de los registros asociadta

E

•• Los accesos adicionales se mostrarán con un comentario.

POSICION NOMBRE-CLI DIREC-CLI PEDIDO FECHA-PDO CANT PROD

1 LUIS PEREZ

NOMBRE-CLI POSICION PROD POSICION

LUIS PEREZ 1

Definición de base de datos jerárquica Eestructura árbol. Utipo de registro es un nodo en la estructura árbol. Un registro “padre”, puede tener mrerelación “padre-hijo”, la base de datos entera se puede se puu

Departamento de Computación UNAN - León

Page 151: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 151 de 316

PEDIDOS PEDIDOS

PRODUCTOPRODUCTO

Definción

n una Base de Datos de este tipo el usuario ve los datos como una colección de elementales y están

nidos entre sí por delante y por detrás mediante punteros. La t ra en árbol de una ase de datos jerárquica con un nivel adicional de complejidad.

en jerarquías de dos niveles llamadas ETS o enlaces.

puede ser parte de diferentes SETS. Al contrario de la base de atos jerárquica, donde cada registro de datos tiene exactamente un “padre”, un

2. Una entrada de comentario con la definición de los SETS.

PEDIDOS-CLIENTES

NOMBRE-CLI

DIREC-CLI

Figura 7.6.15 Ejemplo de Base de Datos tipo Jerárquica.

de base de datos de tipo red

Econjuntos de registros de datos. Los registros contienen datosu

es ructura de la base de datos tipo red es similar a la estructub Cada grupo de registros está organizadoS Un registro dadodregistro de base datos tipo red puede tener más de un “padre” o puede ser que no tenga ninguno. Una base de datos tipo red se define en el Diccionario de Datos como:

1. Un almacén de datos.

PEDIDOS PEDIDOSPEDIDOS

CANT PRODUCTOS CANT PRODUCTOS

CANT PRODUCTOS

CANT PRODUCTOS

CANT PRODUCTOS

CANT PRODUCTOS

CANT PRODUCTOS

CANT PRODUCTOS CANT PRODUCTOS

CLIENTE

PEDIDO

PRODUCTO

Departamento de Computación UNAN - León

Page 152: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 152 de 316

Departamento de Computación UNAN - León

SUMINISTRADOR SUMINISTRADOR

PEDIDOS PEDIDOS

PRODUCTOPRODUCTO

Figura 7.6.16 Ejemplo de Base de Datos tipo Red.

Definición de base de datos relacionales

n una Base junto simple e tablas delementales que describe un objeto particular, tal y como muestra el ejemplo de la igura 4.11.

lacional es muy simple ya que es una

l uso de una base de datos relacional es muy sencillo. Usuarios finales conociendo

elecciona las relaciones necesarias y realiza las operaciones piadas para obtener los resultados deseados. Por esta razón, las

evas relaciones que eviten el tiempo que consume la operación

omo:

. Conjunto de definiciones de almacenes. Una por cada relación, con su propia

PEDIDOS-CLIENTES

CLIENTE

set PEDIDO CLIENTE PEDIDO

set PRODUCTO PEDIDO PRODUCTO

SUMINISTRADOR

set SUMINISTRADOR PEDIDO

set SUMINISTRADOR PRODUCTO

E de Datos de este tipo, el usuario ve los datos como un con

registros de datos, en el que cada registro contiene los datos deF a estructura de una base de datos reL

colección de tablas; sin embargo, el organizar el contenido de cada una de ellas adecuadamente requiere un profesional de base de datos. Elenguajes de interrogación de cuarta generación pueden crear sus propios informes sin ayuda de un programador profesional. Si el usuario decide cambiar los caminos de acceso, el sistema de gestión de la base de datos s

lacionales aprorebases de datos relacionales son capaces de responder a peticiones no anticipadas. Si el tiempo de acceso que se requiere es bajo, el administrador de la base de datos puede crear nuOIN. J

na base de datos tipo relacional se define en el Diccionario de Datos cU

1

clave primaria.

Page 153: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 153 de 316

ANTONIO BARRAGÁN JORGE JUAN, 76

G56F PAPEL PIJAMA 30 T212K DISQUETES 20

987371 2-10-88 20 T212K 987423 2-10-88 12 G56F

os manual es una tarea

programa de gestión de Diccionario de

alias rrectas

• Que tenga facilidades para el control de alias.

CLIENTES: NOMBRE-CLIENTE DIRECCION-CLIENTE

PRODUCTOS: PRODUCTO DESCRIPCIÓN PESO

Figura 7.6.17 Ejemplo de Base de Datos tipo Red.

PEDIDOS: PEDIDO FECHA-PROD CANTIDAD PRODUCTO

Diccionario de Datos mecanizado El tener que construir y mantener un Diccionario de Datrepetitiva y sobre todo consume mucho tiempo. Luego, sería conveniente y productivo poseer un programa que ayudase a gestionar el Diccionario de Datos. Las características que debiera tener esteDatos, desde el punto de vista del análisis serían las siguientes:

• Que soporte las 4 clases de elementos: flujo de datos, almacenes, datos y procesos que hemos identificado como esenciales.

• Que prevea formatos de definición como los vistos anteriormente.

• Que permita entradas no redundantes.

• Que suministre alguna comprobación de consistencia, tales como

desconectados, definiciones circulares, definiciones incosintácticamente, etc.

Que produzcan como salidas, listados de definiciones.

Departamento de Computación UNAN - León

Page 154: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 154 de 316

Departamento de Computación UNAN - León

• Que produzca listados de referencias cruzadas; correlaciones de datos elementales a sus flujos de datos, datos requeridos por cada proceso, términos no definidos.

de fácil manejo para que lo utilizase un equipo de analistas sin especial entrenamiento.

• Si además de poseer esas características tuviera las siguientes podríamos

decir que sería un programa de gestión de DD ideal.

sacase un listado con todos los elementestuviese gráficamente en el círculo asociado en el Diagrama de Flujo de Datos.

• Que buscase por fuentes y destinos de datos inadvertidos en la estructura del

• Que verificase el balanceo del Diagrama de Flujo de Datos en cada nivel.

• Que mantenga y dibuje los Diagramas de Flujo de Datos.

n programa de ordenador que gestionase un Diccionario de Datos de esta manera roveería las ventajas de la redundancia sin el costo de las actualizaciones

computadora

técnica manual de escripción de sistemas y de software. Todo lo que necesitaba el analista para

rea aembar modelización del análisis structurado puede hacer que el papeleo se convierta en una pesadilla cuando se

mo li os muchos iveles diferentes de modelos de flujo; por ejemplo, es irritante tener que seguir la

pis a razones, las herramientas CASE se an convertido en un elemento imprescindible.

Dado qDFDs más eficientemente y conseguir resultados más estéticos con herramientas

ASE. El ingeniero del software usa las posibilidades de dibujo de una herramienta CA e esta alternativa son l ratón, los menús desplegables, las ventanas múltiples y una paleta que contiene

los

• A parte de estas características el programa debería ser

• Que comprobase la descripción del Lenguaje Estructurado de cada proceso y os usados por el proceso y que no

almacén.

Upmúltiples.

7.6.8 Análisis estructurado e ingeniería del software asistida por

El análisis estructurado originalmente se usaba como una d

liz r el trabajo era papel, plantillas (con los símbolos gráficos) y un lápiz. Sin go, no tardó en reconocerse que la notación de

ede zan grandes proyectos. Resulta difícil relacionar manualmente l

nta los cambios y gestionarlos. Por estas

h

ue la modelización de flujo es una actividad gráfica, se pueden desarrollar los

CSE para crear cada modelo de flujo. Los elementos clave d

e símbolos de modelización.

Page 155: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 155 de 316

A dconstrucon sus burbujas “hijas”, y éstas con ella. De esta forma, el analista puede ir asando por los distintos modelos de flujo, a partir del nivel de contexto hasta el

niv dpulsac flechas de atos o de control, a los almacenes o a las entidades específicas. Una vez que se

ha epocas

me ida que se refina cada nivel del modelo de flujo, la herramienta CASE ye una jerarquía interna, de forma que cada burbuja “madre” está asociada

pel e mayor refinamiento. El analista puede también “asociar”, con unas sencillas

iones de ratón, las entradas del diccionario de requisitos a las d

cr ado el modelo, puede ser redibujado, cambiado o imprimido con sólo unas órdenes.

Departamento de Computación UNAN - León

Page 156: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 156 de 316

Bibliografía adicional [1] DeMarco, T., Structured Analysis and System Specification, Prentice-Hall, 1979. [2] Page-Jones, M., The Practical Guide to Structured Systems Desing, Yourdon Press, 1980. [3] Gane, T., and C. Sarson, Structured Systems Analysis, McDonnell Douglas, 982.

] Ward, P. T., and S. J. Mellor, Structured Development for Real-Time Systems (three volumes), Yourdon Press, 1985. [5] Hatley, D.J., and I. A. Pirbhai, Strategies for Real-Time System Specification, Dorset Hoose, 1987. [6] Yourdon, E. N., Modern Structured Analysis, Prentice-Hall, 1990.

1 [4

Departamento de Computación UNAN - León

Page 157: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 157 de 316

MMOODDEELLOO CCOONNCCEEPPTTUUAALL DDEE DDAATTOOSS

Departamento de Computación UNAN - León

Page 158: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 158 de 316

7.7 Modelo conceptual de datos

Título del tema 6: Modelo conceptual de datos.

Objetivos: • Comprender el método de diseño del modelo conceptual de datos.

• Mostrar con ejemplos, los diferentes tipos de relaciones se presentan en el modelo conceptual.

Contenido: • Método del diseño conceptual de datos.

o Determinación del conjunto de referencia.

o Determinación de los conjuntos primarios.

o Determinación

o Determinación de las cardinalidades.

o Verificación del modelo conceptual.

o Simplificación del modelo conceptual.

o Determinación del modelo conceptual operativo.

• Relaciones entre los conjuntos de individuos..

de los individuos y Relaciones.

Duración: • 4 horas

Bibliografía básica: • Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición.

Pearson Educación. • Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

Departamento de Computación UNAN - León

Page 159: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 159 de 316

7.7.1 Método de diseño del modelo conceptual de datos

La secuencia siguiente indica los pasos que se deben seguir para la obtención del modelo con

1. Determinación del conjunto de referencia. Determinación de los conjuntos primarios.

terminación de los individuos y relaciones.

5. Determinación de las propiedades de cada individuo y relación.

7. conceptual de datos. 8. Determinación del modelo conceptual de datos operativo.

Verificación del modelo conceptual de datos operativo.

7.7.1.1 Determinación El punto de partida para la determinación del referencial es la disponibilidad de:

• El diagrama de contexto de los diagramas de flujo de datos.

• El diccionario de

• El diccionario de

• Las informacione

• Las reglas de gestión.

A partir de esta información el referencial se constituye con:

a: el diagrama de flujo de datos de contexto.

• n cia:

ceptual de datos:

2. 3. De4. Determinación de las cardinalidades.

6. Verificación del modelo coneptual de datos. Simplificación del modelo

9.

del conjunto de referencia

datos primario.

datos secundarios con sus algoritmos.

s de entrada salida.

• Una parte gráfic

U a parte textual, la definición en comprensión del conjunto de referen

R(referencial)={ }x x Z/ es un conjunto de individuos y relaciones de la empresa referencial

Departamento de Computación UNAN - León

Page 160: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 160 de 316

7.7.1.2 Determinación de los conjuntos primarios Constituyen la definición en extensión del referencial. Viene determinado por las personas que están en relación con la empresa (recogidas en el DFD de contexto)

Se lleva a cabo en base al modelo mostrado en la Figura 7.7.1 :

Figura 7.7.1 Modelo para la determinación de los conjuntos primarios.

l p os:

sonas o unidades que suministran algo a la

l s gu

l rcer nivel se establecen las unidades o personas que aparecen en el DFD de con

na u a intercambios con la ente). En rproveedores internos B2, C clientes internosel mostrado en la Figura 7.7.2:

Internos { Proveedores

Externos {

A rimer nivel el conjunto de referencia se subdivide en dos conjunt

• Proveedores: todas aquellas perempresa, objeto o servicio.

• Clientes: todas las personas o unidades que reciben algo de la empresa.

Aque la unidad o persona pertenezca a al empresa o sea externa a ella.

e ndo nivel se divide cada subconjunto en internos y externos dependiendo de

A te

texto. U nid o persona puede aparecer en distintos subconjuntos si tiene

empresa referencial bajo diferentes perspectivas (proveedor o cli

la rep esentación del procedimiento 1, si representa proveedores externos B1 y y A clientes externos el resultado será

Diagrama de

Clientes

contexto

N3 N2 N1

R erencial ef

Internos {

Externos {

Departamento de Computación UNAN - León

Page 161: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 161 de 316

7.7.2 Lo prim cidad e alm datos ecundarios se ignoren en esta fase.

el siguiente o lo

Figura 7.7.3 Modelo para la determinación de individuos y relaciones.

• Los datos generales hace referencia a las fechas que corresponden al subconjunto de una manera global.

Internos { B2 Proveedores

Externos { B1

N3 N2 N1

Clientes

Referencial

Internos { C

Figura 7.7.2 Ejemplo de representación de un modelo.

Determinación de los individuos y relaciones

ero que debemos considerar es que nuestro ordenador tiene una capaacenamiento infinita y un tiempo de proceso nulo. El objetivo es que losd

s

cada uno de los subconjuntos del apartado anterior se le aplica

Externos { A

Subconjunto Objetos de los intercambios

Entrega/presentación⎪

Am de :

Datos generales de la empresa.

⎪⎪⎪

Terceros⎨

⎪⎪

Intercambios Factura / cotizaciónPago / remuneración

⎩⎪⎪⎩

⎪⎪⎪

Pedido / contrato⎧⎪

⎪⎪⎪

⎪⎪

Departamento de Computación UNAN - León

Page 162: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 162 de 316

• Los terceros son las personas o unidades que están en relación con la

• etos físicos o servicios: camas,

• do/contrato, entrega/presentación,

factura/cotización, pago/remuneración, son abstracciones semánticas de todos lo ir todos en un determinado sistema.

Así, por ejemplo, una devolución de mercancías sería una entrega negativa; días de , etc.

función de la distinta naturaleza de los

e puede decir lo mismo en cuanto a los intercambios y a los objetos de

los datos generales de la empresa se transforman en Individuos.

ran en el diagrama de flujo de datos de

1. rcambio que posee un identificador de

ra. En este caso se genera por un ción o relaciones que identifican todas

Ejemplo: La Empresa genera pedidos a los proveedores identificados por nº_pedido y

o) de stra el

esquema generado.

empresa referencial.

Los objetos de intercambio son los objpatatas, actos médicos, medicinas, etc. que intercambian los terceros con la empresa referencial.

Los intercambios recogen todas las actividades realizadas en relación con el objeto de intercambio entre la empresa y los terceros.

Las etiquetas del intercambio: pedi

s componentes de un intercambio, pudiendo no interven

ausencia de un empleado también; ventas sería una entrega Los terceros se subdividen en función de la distinta naturaleza de los mismos (una persona y una unidad), en función de la naturaleza de los intercambios (en un hospital, el servicio de camas ofrece camas y la farmacia medicinas, luego son dos

rceros distintos) y por último enteintercambios. Sintercambio.

El proceso se repite para cada subconjunto. Una vez que se ha terminado, los terceros, los objetos de intercambios

En cuanto a los intercambios, que se encuentcontexto, se pueden dar dos situaciones diferentes:

Existencia de un acontecimiento integestión, por ejemplo nº_pedido, nº_factulado un individuo intercambio y la relalas peculiaridades del intercambio.

comprendiendo cada pedido un número cualquiera (al menos unproductos correspondientes a un único proveedor. La Figura 7.7.4 ilu

Departamento de Computación UNAN - León

Page 163: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 163 de 316

a un proveedor de un producto en un pedido y por otro una LIF

terminan el intercambio.

o identificará el intercambio.

intercambio entre terceros externos a la

PEDIDO

……

Figura 7.7.4 Existencia de un acontecimiento intercambio.

En este caso vemos que se genera el individuo pedido (intercambio) y además por un lado la relación LÍNEA_PEDIDO que recoge la cantidad pedida correspondiente a una regla de gestión relativa a cómo se hará el pedido.

2. Existencia de acontecimientos intercambio que no poseen un identificador más que el de los individuos que participan en el intercambio. En éste caso el intercambio genera una relación cuyo identificador son los identificadores de los individuos que de

En el caso de que el individuo que genera el intercambio genere una sola ocurrencia de dicho identificador, este individu Si el tiempo participa en la identificación del intercambio, éste no se convierte en individuo sino que será una propiedad del individuo al que califica. La existencia de acontecimientos empresa, no tiene interés para la construcción del modelo. Ejemplo: Caso 1: la venta de viviendas por los constructores a los compradores en los que un proveedor vende a un comprador una sola vez.

nº_pedido

……

PRODUCTO

nº_pedido …… ……

PROVEEDOR

nº_pedido …… ……

LÍNEA_PEDIDO

CANTIDAD

LIF 1,1 0,N

0,N

1,N

Departamento de Computación UNAN - León

Page 164: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 164 de 316

COMPRADOR y VIVIENDA, siendo la Fecha una propiedad de la relación que caracteriza las fecha en que tuvo lugar el intercambio de venta.

so tenemos una relación que recoge las cantidades pedidas por un lmacén de los diferentes productos solicitados a los proveedores.

CÉN identifica cada ocurrencia del producto pedido por almacén; y al ser un único pedido para un código de almacén tendremos las cantidades de todos los productos pedidos a los proveedores en ese pedido, luego el almacén en este caso de existir una sola ocurrencia pedido por almacén identifica el pedido.

COMPRADOR CONSTRUCTOR

VIVIENDA

VENTA

FECHA

1,N1,N

0,N

Figura 7.7.5 Caso 1: Venta viviendas.

En el ejemplo de la Figura 7.7.5, el intercambio Venta de vivienda (cada venta) viene identificado por la concatenación de CONSTRUCTOR,

Ejemplo: Caso 2: sean una serie de almacenes que realizan un único pedido de productos a los diferentes proveedores, no existiendo un código identificador de intercambio.

PROVEEDOR ALMACÉN

LÍNEA_PEDIDO

CANTIDAD 0,N1,N

PRODUCTO

0,N

Figura 7.7.6 Caso 2: Almacenes realizan pedidos a proveedores.

En este caa La concatenación PROVEEDOR, PRODUCTO, ALMA

Departamento de Computación UNAN - León

Page 165: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 165 de 316

Ejemplo:

F

n este caso cada cantidad de producto pedido necesita para su identificación el

Ejemplo: Caso 4:

dad de que en una fecha un médico no repita l acto a un enfermo.

Caso 3: supongamos la situación anterior con la diferencia de que un almacén puede hacer más de un pedido en diferentes fechas.

PROVEEDOR ALMACÉN

FECHA

PRODUCTO

LÍNEA_PEDIDO 0,N1,N

0,N

CANTIDAD

0,N

igura 7.7.7 Caso 3: Almacenes realizan pedidos a proveedores en fechas diferentes.

Etiempo y así, éste se convierte en individuo. Puede verse que la CANTIDAD es la cantidad pedida por almacén en una fecha de un producto a un proveedor.

sea un hospital en el que los médicos realizan actos médicos de distintos tipos a los enfermos con la particularie

Departamento de Computación UNAN - León

Page 166: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 166 de 316

ENFERMO MÉDICO

TIPO ACTO

Figura 7.7.8 Caso 4: Médicos atienden a pacientes en una fecha determinada.

Como se ve la fecha participa en la identificación del acto y por lo tanto es el identificador.

egu ada subc

1. Hacer referencia a dependencias funcionales establecidas por la empresa.

Estas reglas generan relaciones (limitaciones de integridad funcional o dependencias fuertes o débiles).

Ejemplo: RG1: a efectos organizativos y de ventas los vendedores están agrupados por territorios de ventas. Se establece el concepto territorio de ventas relacionado con el proveedor.

Figura 7.7.9 Regla de gestión 1 relativa a las dependencias funcionales.

S idamente se analizarán las reglas generales de gestión relativas a c

onjunto. Éstas son de dos tipos:

RG1: Se selecciona como proveedor de un producto al de precio menor. En caso de igualdad al de código menor.

2. Señalan conceptos u objetos establecidos por la empresa a efectos organizativos o de intercambio. Generan los individuos y las relaciones de éstos con el resto de individuos del modelo.

FECHA

ACTO

0,N1,N

0,N

0,N

VENDEDOR

TERRITORIO DE VENTAS

1,11,N

Departamento de Computación UNAN - León

Page 167: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 167 de 316

Ejemplo

RG1:

PRODUCTO y TRAMO.

inalmentre i

7.7.3 lidades

ar

1.

dos por la empresa con sus relaciones.

apartado anterior tenemos que

los proveedores deben presentar los catálogos de sus productos indicando el

precio por tramos hasta un máximo de cinco tramos. Así el trama 1 estará comprendido entre 1 y 500 ptas., el tramo 2 entre 501 y 1000 ptas., etc. Se crea el concepto tramo en función del cual los proveedores harán sus propuestas pudiendo un mismo tramo y producto ser ofrecido por diferentes proveedores.

Es decir, cada ocurrencia precio vendrá determinada por el PROVEEDOR, el PRODUCTO y el TRAMO.

PROVEEDOR TRAMO

PRODUCTO

PRECIO

1,N1,N

1,N

Figura 7.7.10 Regla de gestión 1: cada ocurrencia de precio vendrá dada por el PROVEEDOR,

F ente, se analizarán las restantes reglas de gestión que supongan relaciones

ndividuos si las hubiere.

Determinación de las cardina P a la determinación de las cardinalidades seguiremos los pasos siguientes:

Analizaremos las reglas generales de gestión que hagan referencia a LIF o a dependencias funcionales y a las que señalen conceptos u objetos estableci

En el ejemplo anterior se indica que un territorio tiene varios vendedores correspondiendo un vendedor a un único territorio. Análogamente en el segundo ejemplo delun proveedor establece varios tramos para cada producto a los que les asigna un precio pudiendo corresponder un producto a varios proveedores y lo mismo puede ocurrir con los tramos. Ello lleva a las cardinalidades reflejadas en el procedimiento anterior.

Departamento de Computación UNAN - León

Page 168: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 168 de 316

2. Analizando las reglas de gestión de cada intercambio y éstas nos determinarán las cardinalidades.

gún pedido. En esta relación PEDIDO, PRODUCTO se reflejan las siguientes

3. Analizando el resto de las reglas de gestión que den información relativa a relaciones del modelo que no corresponden a los intercambios.

Aquellas relaciones para las que no se explicite cardinalidad se pedirá y si

propiedades de cada individuo o relación

n primer lugar se definen en comprensión todos los individuos y relaciones del

{ }

Ejemplo: Un pedido identificado por un nº_pedido comprende varios productos, pudiendo existir productos de los cuales no se efectúa nin

cardinalidades:

PRODUCTO PEDIDO

0,N1,N

Figura 7.7.11 Cardinalidades de PEDIDO - PRODUCTO.

no es posible se establecerá una cardinalidad 0,N.

7.7.4 Determinación de las Emodelo.

{ }lreferencia del R1relación ls a relativas spropiedade tiene/=R1 OO

{ }{ }pedidoun en pedido ucto

ocurrencia=O lreferencia del I1 individuo al relativas spropiedade tiene/1I

LíneaEnfer

OO=

Seguidadicciona a un individuo o relación se asignpertenectantas pque pert

produn a relativas spropiedade tiene/_hospital del enfermoun a relativas spropiedade tiene/=

:

OOPedidoOOmo

Ejemplos

=

mente se analiza propiedad a propiedad cada uno de los datos primarios del o de datos y en función del criterio de pertenencia ri

a dicha propiedad a un individuo o relación a que pertenezca. En el caso de er a varios individuos o relaciones, una propiedad se descompone en

ropiedades, con nombres distintos (alias) como individuos o relaciones a los enece.

Departamento de Computación UNAN - León

Page 169: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 169 de 316

7.7.5 Verificación del modelo conceptual

En la verificación del modelo conceptual se aplicarán las siguientes reglas: distribuidas en cuatro conjuntos, el primero aplicable a los individuos, el segundo a las relaclas aplic

1. a los individuos.

R1: existencia de un identificador para cada individuo.

R3: todas las propiedades deben ser elementales. Es decir, no desc R4: todas las propiedades del individuo deben depender de todo el

2.

5: A cada ocurrencia de una relación corresponde una y sólo una ocurrencia de cada individuo que participa en la relación.

Así cada propiedad debe depender de todo el identificador y no de una parte del mismo.

iones, el tercero a las cardinalidades y el cuarto a las correspondencias de aciones solicitadas.

Reglas relativas

R2: para cada ocurrencia de un individuo, una propiedad no puede tomar más que un único valor.

omponibles.

identificador y directamente, no pueden existir dependencias transitivas.

Reglas relativas a las relaciones.

R

R6: Para cada ocurrencia de una relación no puede existir más que in sólo valor y sólo uno de cada propiedad de la relación.

R7: Todas las propiedades de una relación deben depender plenamente del identificador de la relación.

3. Reglas relativas a las cardinalidades.

R8: Como las cardinalidades son dadas independientemente a través de las reglas de gestión pueden darse errores de interpretación y surgir incompatibilidades entre las cardinalidades. Por tanto debe verificarse que las cardinalidades del modelo son compatibles. R9: Debe verificarse que no existen ciclos en el modelo. Se caracterizan por ser el origen y el blanco de una cardinalidad 1,1.

Departamento de Computación UNAN - León

Page 170: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 170 de 316

4. Reglas relativas a las correspondencias de las informaciones.

R10: se verificará que las correspondencias solicitadas en las

7.7 Simplificación del modelo conceptual

La simpl

1.

2. escomposición exógena.

3. s y relaciones que participan en una relación de forma ompleta, siendo el blanco de una dependencia funcional fuerte, teniendo

las hubiere al otro individuo de la relación.

Ejemplo:

Figura 7.7.12 Ejemplo de relación completa.

7.7.7 Determinación del modelo conceptual operativo Se consy tiempo

Se determina en función de los dos criterios siguientes:

informaciones son aplicaciones correctas para un único individuo con las relaciones del ciclo.

.6

ificación del modelo conceptual consiste en:

Descomposición endógena.

D

Aquellos individuocexclusivamente el identificador y no participando en otra relación se pueden eliminar pasando el identificador y las propiedades de la relación si

MODELO

nº_modelo

VEHÍCULO

matrícula color cilindrada

PROVEEDOR

matrícula

nº_modelo

color cilindrada

1,1 1,N

idera que el ordenador dispone de una capacidad de almacenamiento finita de proceso no nulo.

Departamento de Computación UNAN - León

Page 171: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 171 de 316

1.

ncia o no de su incorporación al modelo de datos. Se tiene en cuenta para tomar la decisión: Si el mantener el dato secundario en el modelo supone ahorro de

po de proceso.

rioridad a su obtención.

ilización más uniforme de los recursos.

2. Relaciones entre los conjuntos individuos y conjuntos relaciones.

7.7.8 Verificación del modelo conceptual operativo

onsiste en realizar los pasos descritos en el apartado 7.7.5 para ver las posibles onsecuencias producidas al realizar el paso 7.7.7

Limitación de recursos.

Se analiza cada propiedad secundaria del diccionario (propiedades que se obtienen mediante un algoritmo) recogidas en el diccionario de datos. Para ver la ocurre

espacio de almacenamiento o tiem

Si van a ser utilizadas o no con poste

Si ello supone una ut

Se estudia la posibilidad de reunión de conjuntos aplicando los criterios lógicos con el fin de reducir la redundancia, facilitando y garantizando así la integración delos datos, sobre todo cuando existe intersección.

Cc

Departamento de Computación UNAN - León

Page 172: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 172 de 316

MMEENNTTOOSS DDEELL

FFUUNNDDAA DDIISSEEÑÑOO SSOOFFTTWWAARREE

Departamento de Computación UNAN - León

Page 173: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 173 de 316

7.8 Fundamentos del diseño software

Título del tema 7: Fundamentos del diseño software.

Objetivos: • Comprender el concepto de diseño y la importancia de éste dentro del

proceso del ciclo de vida de un sistema de información.

• Exponer los conceptos fundamentales que se pueden aplicar a todos los diseños de programas.

• Mostrar los criterios para determinar la calidad del diseño de un software.

• Exponer los Fundamentos del Diseño Software.

• Explicar los elementos que nos permiten lograr un diseño modular efectivo.

• Mostrar la relación entre Ingeniería

del Software y Diseño del Software.

Contenido: • Introducción.

• Ingeniería del software y diseño del Software.

• Proceso de diseño.

o Diseño y calidad del software.

o Evolución del diseño del software.

• Fundamentos del diseño.

o Abstracción.

o Refinamiento.

o Modularidad.

o Arquitectura del software.

o Jerarquía de control.

o Estructura de datos.

Departamento de Computación UNAN - León

Page 174: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 174 de 316

o Procedimientos del software.

o Ocultamiento de información.

ño modular efectivo.

o Independencia funcional.

o Cohesión.

o

Notaciones tabulares de diseño.

• Diseño de Interfaz.

o Diseño de salida.

de entrada.

• Dise

o Acoplamiento.

• Diseño de datos.

• Diseño arquitectónico.

• Diseño procedimental.

Herramientas de diseño.

Programación estructurada.

Notaciones gráficas de diseño.

Lenguajes de diseño de programas.

o Diseño

o Diseño de Menús.

Duración:

• 6 horas

Bibliografía básica: • Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición.

Pearson Ed • Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

• Ver bilbliog ulo.

ucación.

rafía adicional al final del capít

Departamento de Computación UNAN - León

Page 175: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 175 de 316

7.8.1 Introducción El diseño es el primer paso de la fase de de ingeniería. P dprincipios con el propó , proceso o sistema con los suficientes detalles como para permitir su realización física” [1]. El objetivo del diseñador epresentación de una entidad que se construirá más adelante. El proceso por el cual se desarrolla el modelo combina: la intuición y los criterios en base a la experiencia de construir entidades similares, un conjunto de principios y/o heurísticas que guían la forma en la que se desarrolla el mod s que permiten discernir sobre la calidad y un proceso de iteración que conduce finalmente a una representación del diseño final. Este capítulo presenta ue se pueden aplicar a todos los diseños de programas.

7.8.2 Ingeniería del softwa Una vez que se han establecid l software es la primera de t as -diseño, codificación y prueba. Cada actividad transforma la información de forma que finalmente se obtiene un software para computadora valid uestra lo expuesto.

Figura 7.8.1 Ubicación del Diseño del Software. En la Figura 7.8.2 se muestra el flujo de información durante la fase de desarrollo. Los requisitos del programa, establecidos mediante los modelos de información, funcional y de comportamiento, alimentan el paso del diseño. Mediante alguna de las meto o o de datos, el diseño arquitectónico y el diseño procedimental. El diseño e el análisis, en las estructuras de datos que se van a requerir para implementar el software. El diseño arquitectónico define las relaciones entre los principales elementos estructurales del programa.

l diseño procedimental transforma los elementos estructurales en una descripción procedimental del software. Se genera el código fuente y, para integrar y validar el software, se llevan a cabo las pruebas.

desarrollo de cualquier producto o sistema ue e definirse como: “el proceso de aplicar distintas técnicas y

sito de definir un dispositivo

es producir un modelo o r

elo, un conjunto de criterio

los conceptos fundamentales q

re y diseño del software.

o los requisitos del software, el diseño deres actividades técnic

ado. La Figura 7.8.1 m

dol gías de diseño (tratadas en temas posteriores) se realiza el diseñ

d datos transforma el modelo del campo de información, creado durante

Requisitos del Software Diseño, Codificación y Prueba

E

Departamento de Computación UNAN - León

Page 176: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 176 de 316

El diseño es el proceso en el que se asienta la calidad del desarrollo del software. El ma mediante la cual podremos traducir con precisión los

quisitos del cliente en un producto o sistema acabado. Sin diseño, nos

.8.3 Proceso de diseño

esde el punto de vista de la gestión del proyecto, el diseño del software se realiza n dos pasos:

arquitectónica que lleva a una estructura de datos detallada y a las

contexto de los diseños preliminar y detallado, se llevan a cabo varias ctividades de diseño diferentes. Además del diseño de datos, del diseño

eño de la interfaz que establece la disposición y los ecanismos para la interacción hombre-máquina.

diseño es la única forrearriesgamos a construir un sistema inestable que falle cuando se realicen pequeños cambios; un sistema que pueda ser difícil de probar y cuya calidad no pueda ser evaluada hasta más adelante en el proceso de ingeniería del software, cuando quede poco tiempo y se haya gastado ya mucho dinero.

Modelo funcional Modelo de información Diseño de datos Modelo de comportamiento Diseño

Figura 7.8.2 Diseño del Software e Ingeniería del Software.

7

De

1. Diseño preliminar: que se centra en la transformación de los requisitos en los datos y la arquitectura del software y

2. Diseño detallado: que se ocupa del refinamiento de la representación

representaciones algorítmicas del software. Dentro del aarquitéctonico y del diseño procedimental, muchas aplicaciones modernas requieren una actividad distinta de dism

arquitectónico Otros requisitos Diseño procedimental Módulos del programa

Software integrado y validado

Diseño

Codificación

Prueba

Departamento de Computación UNAN - León

Page 177: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 177 de 316

7.8.3.1 Diseño y calidad del software A lo largo del proceso de diseño, la calidad del diseño resultante se evalúa mediante una serie de revisiones técnicas formales. Para evaluar la calidad de una representación del diseño debemos establecer unos criterios que determine cuándo el diseño es bueno. Entre estos criterios están:

1. Un diseño debe mostrar una organización jerárquica que haga un uso teligente del control entre los componentes del software.

. Un diseño debe ser modular, es decir, el software debe estar dividido de

eleme tos que realicen funciones y subfunciones

. Un diseño debe contener representaciones distintas y separadas de los

datos y de los procedimientos.

s

conexiones entre los módulos y el entorno exterior.

6. Un diseño debe obtenerse mediante un método reproducible y que esté co s requisitos del software.

.8.3.2 Evolución del diseño de software

el diseño de software es un proceso continuo que se ha ido roduciendo durante las últimas tres décadas. Los primeros trabajos sobre diseño

se cenmétodos pa manera descendente [3].

Los asfilosofía depropusieron os [6] o de la estructura de

s datos ([7], [8]) en una definición de diseño. Nuevos enfoques para el diseño ([9],

in

2forma en específicas.

lógica n

3

4. Un diseño debe llevar a módulos (subrutinas, procedimientos, etc) que exhiban características funcionales independientes.

5 r an la complejidad de. Un diseño debe llevar a interfaces que eduzc la

nducido por la información obtenida durante el análisis de lo

7 La evolución dp

traron sobre los criterios para el desarrollo de programas modulares [2] y los ra mejorar la arquitectura del software de una

pectos procedimentales de la definición del diseño evolucionaron hacia una

nominada programación estructurada ([4] [5). Posteriores trabajos métodos para la traducción del flujo de dat

lo[10] proponen un método orientados a los objetos para la obtención del diseño.

Departamento de Computación UNAN - León

Page 178: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 178 de 316

7.8.4 Fundamentos del Diseño En las últimas tres décadas se ha establecido un conjunto de conceptos fundamentales para el diseño del software. Todos dan al diseñador del software una base sobre la que pueden aplicarse metodologías de diseño más o menos sofisticadas. Abstracci

Cuan sformularseestablece una solución en términos amplios, usando el lenguaje del entorno del roblema. En los niveles inferiores de abstracción se toma una orientación más

proce eterminolog ión, en un esfuerzo para establecer una olución. Por último, en el nivel más bajo de abstracción, se establece la solución de

forma e

ada paso de un proceso de ingeniería del software es un refinamiento del nivel de abstr ióniveles de nes de datos y de rocedimientos. Una abstracción procedimental es una determinada secuencia de

instru on“pase” encaminar hacia la puerta, coger el pomo, girar el pomo y abrir la puerta, atravesar la

uerta, etc.). Una abstracción de datos es una determinada colección de datos que escriben un objeto (por ejemplo, un “cheque-nómina” que es en realidad un onjunto de información: nombre del beneficiario, cantidad bruta, etc.).

efinamiento

escomponiendo una declaración macroscópica de una función de una forma

l concepto de modularidad para el software de computadora se lleva teniendo en uenta desde hace casi cuatro décadas. La arquitectura del software (como se escribe posteriormente) implica modularidad, es decir, el software se divide en

ones determinados, que se denominan módulos y que se integrar para satisfacer los requisitos del problema.

ón

do e considera una solución modular para cualquier problema, pueden muchos niveles de abstracción. En el nivel superior de abstracción, se

pdim ntal. La terminología orientada al problema se acompaña con una

ía orientada a la implementacs

qu pueda implementarse directamente.

Cacc n de la solución de software. Conforme nos movemos por diferentes

abstracción, trabajamos para crear abstracciop

cci es que tienen una función limitada y específica (por ejemplo, la palabra una puerta implica una larga secuencia de pasos procedimentales:

pdc

R El refinamiento sucesivo es una primera estrategia de diseño propuesta por Niklaus Wirth [3]. La arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento de los detalles procedimentales. Se desarrolla una jerarquíadsucesiva, hasta que se llega a las sentencias del lenguaje de programación. Por lo tanto, el refinamiento es realmente un proceso de elaboración. Modularidad Ecdcomponentes con nombres y ubicaci

Departamento de Computación UNAN - León

Page 179: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 179 de 316

“La modularidad es el atributo individual del software que permite a un programa ser oftware monolítico (es decir, un gran programa

ompuesto de un único módulo) no puede ser fácilmente abarcado por un lector. El

(coste) de desarrollo de un módulo individual disminuye conforme umenta el número total de módulos. Para un mismo conjunto de requisitos, al aber más módulos, el tamaño de cada uno es más pequeño. Sin embargo,

e el número de módulos, el esfuerzo (coste) asociado a las interfaces ntre los módulos también crece. Esto nos lleva a una curva de coste o esfuerzo

na definición el problema. La solución aparece cuando cada parte del problema está resuelta ediante uno o más elementos de software. Este proceso, simbólicamente

n la Figura 7.8.3, representa una transición entre el análisis de quisitos del software y el diseño.

Figura 7.8.3 Evolución de la estructura.

intelectualmente manejable” [11] El scnúmero de caminos de control, la expansión de las referencias, el número de variables y la complejidad global podrían hacer imposible su correcta comprensión. El esfuerzo ahconforme crecetotal como la que muestra la figura. Hay un número, M, de módulos para el que el coste de desarrollo es mínimo, pero no tenemos los medios suficientes para poder predecir M con seguridad. El tamaño de un módulo dependerá de su función y aplicación. En el apartado siguiente se tratan unas medidas del diseño que ayudan a determinar el número apropiado de módulos que debe tener un software. Arquitectura del software La arquitectura del software se refiere a dos características importantes del software de computadora:

• La estructura jerárquica de los componentes procedimentales (módulos) y • La estructura de los datos.

La arquitectura del software se obtiene mediante un proceso de partición, que relaciona los elementos de una solución de software con partes de un problema de un modelo real definido implícitamente durante el análisis de los requisitos. La evolución del software y de la estructura de los datos comienza con udmrepresentado ere

P1 P2

P3 P5

S1

S4

S3

S

P4

2

S5

“Problema” a ser resuelto con el software “Solución” de software

Departamento de Computación UNAN - León

Page 180: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 180 de 316

Observando la Figura 7.8.4, se ve que un problema puede ser resuelto mediante diferentes estructuras. Cada método de diseño dará como resultado una estructura distinta, para el mismo conjunto de requisitos del software. No hay una respuesta fácil a la pregunta “¿cuál es el mejor?”. Sin embargo, hay características de una estructura que se pueden examinar para determinar la calidad global (trataremos sto más adelante en este capítulo).

ominada estructura del programa, representa la rganización (frecuentemente jerárquica) de los componentes del programa

(módulos) e implica una jerarquía de control. No representa aspectos procedimentales del software, tales como laorden de decisiones o la repetición de operaciones.

rol se utilizan muchas notaciones. La más en forma de árbol. La profundidad y la anchura son una

y de la amplitud global del control, grado de salida es una medida del número de módulos que

están directamente controlados por otros módulos. El grado de entrada indica cuantos módulos controlan directamente a un módulo dado.

e

Figura 7.8.4 Diferentes estructuras.

Jerarquía de control a jerarquía de control, también denL

o

secuencia de procesos, la ocurrencia u

Para representar la jerarquía de contcomún es un diagrama indicación del número de niveles de control respectivamente. El

S1

S4

S3 S2 S5

S1

S4 S5

S3

S1 S5

S2

S3

S4

“Problema”

S2

Estructura 1 Estructura 2

Departamento de Computación UNAN - León

Page 181: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 181 de 316

Estructura de datos La estructura de datos es una representación de la relación lógica existen entre los elementos individuales de datos. Debido a que la estructura de la información afectará invariablemente al diseño procedimental final, la estructura de datos es tan importante como la estructura del programa en la representación de la arquitectura el software.

La estructura de datos dicta la organización, los métodos de acceso, el grado de asociatividad y las alternativas de procesamiento de la información.

un número reducido de estructuras de

más sofisticadas. Estas estructuras de datos

d

La organización y complejidad de una estructura de datos tan sólo está limitada por el ingenio del diseñador. Sin embargo, hay datos clásicas, que constituyen los bloques con los que se construyen estructuras

clásicas se ilustran en la Figura 7.8.5.

Figura 7.8.5 Estructuras de datos clásicas.

Elemento escalar

Vector secuencial

Lista enlazada

Árbol jerárquico

Espacio n-dimensional

Departamento de Computación UNAN - León

Page 182: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 182 de 316

Procedimientos del software

structura de los datos.

bordinados del ódulo que se describe. Es decir, la representación procedimental del software se

Figura 7.8.6 Procedimiento dentro de un módulo.

El procedimiento del software se centra sobre los detalles de procesamiento de cada módulo individual. El procedimiento (Figura 7.8.6) debe proporcionar una especificación precisa del procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la repetición de operaciones e incluso la organización/e Existe una relación entre la estructura y el procedimiento. El procesamiento indicado para cada módulo debe incluir referencias a todos los módulos sumrealiza por capas.

Módulo A

Módulo A

Departamento de Computación UNAN - León

Page 183: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 183 de 316

Ocultamiento de información El concepto de modularidad lleva a todo diseñador de software a plantearse una pregunta fundamental: “¿cómo descomponer una solución de software obteniendo el mejor conjunto de módulos?”. El principio de ocultamiento de información sugiere que para conseguir una modularidad efectiva hay que definir un conjunto de módulos independientes, es decir, deben especificarse y diseñarse de forma que la

formación (procedimientos y datos) contenida dentro de un módulo sea inaccesible

ría de los datos y de los procedimientos estarán ocultos a otras artes del software y será menos probable que los errores introducidos advertidamente durante la modificación se propaguen a otros lugares del software.

Por lo tanto, la prueba y el mantenimiento del software se beneficiarán de este criterio.

7.8.5

iormente sirven para incentivar los diseños modulares.

(un aspecto crítico de la facilidad de como resultado una implementación más

sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un sistema. Independencia funcional La independencia funcional se adquiere desarrollando módulos que se centren en una subfunción específica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras partes de la estructura del software evitando una excesiva interacción con otros módulos. Los módulos independientes son más fáciles de mantener (y de probar) debido a

oducidos por las modificaciones en el rrores y se fomenta la reutilización de funcional es clave en la calidad del

software. La independencia se mide con dos criterios cualitativos: la cohesión y el acoplamiento.

ina otros módulos que no necesiten tal información. Con el uso del ocultamiento de información como criterio de diseño para los sistemas modulares, la mayopin

Diseño modular efectivo

Los fundamentos de diseño descritos anter

Un diseño modular facilita los cambios mantenimiento del software) y produce

que se limitan los efectos secundarios prdiseño/código, se reduce la propagación de elos módulos. Por lo tanto, la independencia

Departamento de Computación UNAN - León

Page 184: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 184 de 316

Cohesión La cohesión es una medida de la fortaleza funcional relativa de un módulo. Un módulo cohesivo ejecuta una tarea sencilla de un procedimiento de software y requiere poca interacción con procedimientos que ejecutan otras partes de un programa. La cohesión puede presentarse como se muestra en la Figura 7.8.7. Lo deseable siempre es conseguir una gran cohesión, aunque un punto medio normalmente es ceptable. La escala de cohesión no es lineal, es decir, una cohesión baja es mucho

iento depende de la complejidad de las interfaces entre los módulos, del

n el diseño de software buscamos el acoplamiento más bajo posible. La onectividad sencilla entre módulos da como resultado un software que es más fácil e comprender y menos propenso al “efecto onda” producido cuando los errores

aparecen en una posición y se propagan a lo largo del sistema.

a“peor” que una de la mitad de la escala, que, a su vez, es casi tan “buena” como una gran cohesión. TIPO DE COHESIÓN NIVEL DE

COHESIÓN Coincidental : Un módulo que realiza un conjunto de tareas débilmente relacionadas entre sí. BAJO

Lógica: Un módulo que realiza tareas relacionada

s de forma lógica.

Temporal: Un módulo que contiene tareas relacionadas por ejecutarse en el mismo momento.

Procedimental: Los elementos de procesamiento de un módulo están relacionados y deben ejecutarse

en un orden específico.

Comunicativa: Los elementos de procesamiento se concentran sobre un área de una estructura de datos.

Secuencial: Un módulo que ejecuta tareas secuenciales sin interrupción.

Funcional: Un módulo que sólo ejecuta una tarea. ALTO

Figura 7.8.7 Cohesión.

coplamiento A El acoplamiento es una medida de la interdependencia relativa entre los módulos de una estructura de programa. La Figura 7.8.8 representa un espectro de acoplamiento.

l acoplamEpunto en el que se hace una entrada o referencia a un módulo y de los datos que pasan a través de la interfaz. Ecd

Departamento de Computación UNAN - León

Page 185: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 185 de 316

TIPO DE ACOPLAMIENTO NIVEL DE ACOPLAMIENTO Sin acoplamiento directo: Los módulos no están relacionados. BAJO Acoplamiento de datos: Se pasan datos simples a través de una interfaz de módulo. Acoplamiento por estampado: Se pasa una porción de una estructura de datos a través de una

interfaz de módulo. Acoplamiento de control: En su forma más sencilla, el control se pasa mediante un “indicador” sobre el

que se toman las decisiones en un módulo subordinado o superior. Acoplamiento externo: Los módulos están ligados a un entorno externo al software. Por ejemplo a la E/S. Acoplamiento común: Varios módulos referencian un área de datos global. Por ejemplo, un archivo. Acoplamiento del contenido: Un módulo utiliza información de datos o de control contenida dentro de

los límites de otro módulo.

Figura 7.8.8 Acoplamiento.

Diseño de Datos

l diseño de datos es la primera de las tres actividades de diseño realizadas durante ingeniería del software.

l proceso de diseño ha sido resumido por Wasserman [12]:

a actividad principal durante el diseño de datos ess objetos de datos (estructuras de datos), identificados durante las fases de definición y specificación de requisitos. El proceso de selección puede implicar un análisis algorítmico de las structuras alternativas, de cara a determinar el diseño más eficiente, o puede simplemente implicar

nto de módulos (un “paquete”), que proporcione las operaciones deseadas sobre lguna representación de un objeto.

de las decisiones concretar de diseño de datos.

siderar los siguientes principios para la especificación e datos:

los datos, se debe considerar organizaciones de datos alternativas y se debe evaluar el impacto de la modelización de datos sobre el diseño del software.

ALTO

7.8.6 Ela E

L la selección de las representaciones lógicas de loeeel uso de un conjua Una actividad importante durante el diseño es la de identificar los módulos de programa que deben operar directamente sobre las estructuras de datos lógicas. De esta forma, puede restringirse el ámbito del efecto Teniendo en cuenta que el análisis de requisitos y el diseño se solapan frecuentemente, podemos cond

• Los principios sistemáticos de análisis aplicados a la función y el comportamiento también deben aplicarse a los datos: Se deben desarrollar y revisar las representaciones del flujo y del contenido de

Departamento de Computación UNAN - León

Page 186: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 186 de 316

Departamento de Computación UNAN - León

• Deben identificarse todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas.

• Debe establecerse y usarse un diccionario de datos para definir el diseño de los datos y del programa.

• Se deben posponer las decisiones de diseño de datos de bajo nivel hasta más adelante en el proceso de diseño.

• La representación de una estructura de datos sólo debe ser conocida por los módulos que hagan un uso directo de los datos contenidos en la estructura.

• Se debe desarrollar una biblioteca de estructuras útiles y de las operaciones que se les pueden aplicar.

• El diseño de software y el lenguaje de programación deben soportar la

especificación y la realización de tipos abstractos de datos.

.8.7 Diseño Arquitectónico

es desarrollar una estructura de rograma modular y representar las relaciones de control entre los módulos.

ces que facilitan el flujo de datos a lo largo del programa.

rma más restringida para la representación de los detalles procedimentales:

7 El objetivo principal del diseño arquitectónicopAdemás, el diseño arquitectónico mezcla la estructura de programas y la estructura de datos y define las interfa

7.8.8 Diseño Procedimental El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos. El diseño procedimental debe especificar los detalles de los procedimientos sin ambigüedad y la falta de ambigüedad en un lenguaje natural no es habitual. Usando un lenguaje natural podríamos describir un conjunto de pasos procedimentales de emasiadas formas diferentes. Por esta y otras muchas razones, debemos usar una d

fo

Page 187: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 187 de 316

7.8.8.1

Progra

A f lconjun podría formarse cualquier programa.

Lasconstru e iseño importante dentro del área de ingeniería del software.

Cualqu emente del área de aplicación y de la complejidad

cnica, puede diseñarse e implementarse usando sólo las tres construcciones est tsólo estas construcciones puede provocar a veces dificultades prácticas.

otaciones gráficas de diseño

ntación gráfica más ampliamente usada para el iseño procedimental.

Herramientas de diseño

mación estructurada

ina es de los años sesenta, Dijkstra y otros ([13] [14]) propusieron el uso de un to de construcciones lógicas con las que

construcciones son la secuencia, la condición y la repetición. Estas tres

cciones son fundamentales en la programación estructurada - una técnica dd

ier programa, independientté

ruc uradas. Sin embargo, debe tenerse en cuenta que el uso dogmático de tan

N

El diagrama de flujo es la represed Un diagrama de flujo es un gráfico muy sencillo. Para representar un paso de procesamiento se utiliza un cuadro, un rombo para representar una condición lógica y flechas para mostrar un flujo de control. La Figura 7.8.9 muestra las tres onstrucciones de la programación estructurada tratadas anteriormente. c

Departamento de Computación UNAN - León

Page 188: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 188 de 316

ualquiera de los bloques de la Figura 7.8.9 en un módulo podría hacer referencia a tro módulo, teniéndose de ese modo la disposición por capas procedimentales plicada por la estructura de programa.

ualquiera de los bloques de la Figura 1.9 en un módulo podría hacer referencia a tro módulo, teniéndose de ese modo la disposición por capas procedimentales plicada por la estructura de programa.

tra herramienta gráfica de diseño, el diagrama de cajas, diagramas N-S o iagramas de Chapin tienen las siguientes características:

• El ámbito de una repetición o de un if-then-else está bien definido y es claramente visible como representación gráfica.

• La transferencia arbitraria de control es imposible.

• Se puede determinar fácilmente el ámbito de los datos locales y/o globales.

• La recursividad es fácil de representar.

Figura 7.8.9 Construcciones en diagramas de flujo.

Condición F T

Parte then

condición Condición del bucle

Do-while Repeat-until

Primera tarea

Parte else

Coim Coim Od

Siguiente tarea

Secuencia If-then-else

T T F Parte del caso F

T F T Casos de

F

T Repetición F

Selección

Tarea del bucle

Departamento de Computación UNAN - León

Page 189: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 189 de 316

La representación gráfica de construcciones estructuradas, usando diagramas de ajas, se muestra en la Figura 7.8.10.

F

iento a una forma tabular.

es de las condiciones y s o

esp íe pro

c

Secuencia If-then-else

Repetición Selección

Primera tarea

Siguiente tarea

Tarea siguiente+1

F Condición T Parte- Parte- else then

Condición del bucle Parte do-while

Parte repeat-until Condición del bucle

Caso de condición Valor Valor . . . Parte Parte . . . del caso del caso

igura 7.8.10 Construcciones en diagramas de flujo. Notaciones tabulares de diseño En muchas ocasiones, puede ser necesario que un módulo evalúe una compleja combinación de condiciones y, de acuerdo con ellas, seleccione una acción apropiada. Las tablas de decisión constituyen una notación que traduce las acciones las condiciones descritas en el procesamy

La Figura 7.8.11 muestra la organización de una tabla de decisión. Los cuadrantes e la derecha forman una matriz que indica las combinaciond

la c rrespondientes acciones que se han de producir para cada combinación ec fica. Por tanto, cada columna de la matriz puede interpretarse como una regla

cesamiento. d

Departamento de Computación UNAN - León

Page 190: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 190 de 316

Para desarrollar una tabla de decisión se aplican los siguientes pasos:

1. Listar todas las acciones que puedan asociarse con un módulo.

2. Listar todas las condiciones (o decisiones hechas) durante la ejecución del procedimiento.

3. eliminando las combinaciones de condiciones imposibles; alternativamente, desarrollar cada posible permutación de condiciones.

4. Definir reglas indicando qué acciones ocurren para un conjunto de condiciones.

Figura 7.8.11 Nomenclatura de las tablas de decisión.

ente dentro de las sentencias de LDP.

gen, un lenguaje de diseño debe tener las siguientes características:

Asociar conjuntos específicos de condiciones con acciones específicas,

Números de reglas Filas de condiciones Filas de acción

Reglas

1 2 3 4 5 6 7 8 9 10

Lenguajes de diseño de programas El lenguaje de diseño de programas (LDP), denominado lenguaje estructurado o seudocódigo, es un lenguaje que utiliza el vocabulario de un lenguaje (p. ej. : p

inglés) y la sintaxis general de otro (p. ej. : un lenguaje de programación estructurada) [14] A primera vista, LDP se puede parecer a PASCAL o a Ada. La diferencia entre LDP y un lenguaje de programación de alto nivel real se encuentra en el uso de texto escriptivo directamd

Independientemente de su ori

Departamento de Computación UNAN - León

Page 191: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 191 de 316

1. Una sintaxis fija de palabras clave que permitan realizar todas las construcciones estructuradas, declarar datos y establecer características

to.

4. Un mecanismo de definición de subprogramas y de invocación,

7.8.9 e interf Diseños de Salida: El término salida, como es probable que se conozca, se refiere a los resultados e

sistem Cuando se diseña la salida, se debe considerar lo siguiente:

• Determinar qué información presentar.

• Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida.

formación en un formato aceptable.

l diseño de entrada:

2. Qué medios utilizar.

de modularidad.

2. Una sintaxis libre en lenguaje natural para describir las características del procesamien

3. Facilidades para la declaración de datos, incluyendo estructuras de datos

sencillas (escalares, arrays) y complejas (listas enlazadas o árboles).

soportando los distintos modos de descripción de interfaces.

Diseño d az

información generada por el sistema. Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el

a.

• Disponer la presentación de la in

• Decidir cómo distribuir la salida entre los posibles destinatarios. La

disposición de la información sobre una pantalla o documento impreso se denomina distribución.

Diseños de Entrada: Los analistas de sistemas deciden los siguientes detalles de

1. Qué datos ingresan al sistema.

Departamento de Computación UNAN - León

Page 192: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 192 de 316

3. La forma en que se deben disponer o codificar los datos.

El diálogo que s

4. ervirá de guía a los usuarios para dar entrada a los datos.

5. aria de datos y transacciones para detectar errores.

Las decisi rma en que erán aceptados los datos para su procesamiento por computadora.

l diseño de entrada incluye también la especificación de los medios por los que tanto los usuarios finales como los operadores darán instrucciones al sistema sobre

nder.

iseño de Menús

l responder el usuario al menú, se limita a las opciones que se le presentan. El ber que tareas pueden

alizarse. os mexi n

de lápi

Validación neces

6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

ones de diseño para el manejo de entradas, especifican la fos E

las acciones que debe empre D Esta interfaz toma su nombre de manera muy apropiada a partir de la lista de platillos que pueden seleccionarse en un restaurante. De manera similar, una interfaz de menú permite que el usuario elija las posibles opciones de una lista en pantalla. Ausuario no necesita conocer el sistema, pero si necesita sare

Le

nús, considerados como interfaces, no son dependientes del hardware. Pero ste ciertas variantes. Pueden tenerse acceso a los menús a través del teclado,

ces ópticos o de ratones.

Departamento de Computación UNAN - León

Page 193: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 193 de 316

Biblio f

[1] Taylor, . E. S., An Interim Report on Engineering Design, Massachussetts

Institute of Technology, 1959.

[2] D nBauer, de.), Springer-Verlag, 1973, pp. 128-182.

athematical Foundations for Structured Programming”, Technical 1-6012, IBM Corp., Federal Systems Division, Gaithersburg,

nal, vol. 113, no. 2, 1974, pp. 115-139.

] Booch, G., Software Engineering with Ada, Benjamin-Cummings, 1983.

0] Meyer, B., Object-Oriented Software Construction, Prentice-Hall, 1988.

1] Myers, G., Composite Structured Design, Van Nostrand, 1978.

2] Wasserman, A., “Principles of Systematica Data design and Implementation”, in Software Design Techniques (P. Freeman y A. Wasserman, eds.), 2d ed., IEEE Computer Society Press, 1980, pp. 287-293.

[13] Dijkstra, E., “Programming Considered as a Human Activity”, in Proc. 1965 IFIP

Congress, North-Holland Publishing Co., 1965.

gra ía adicional

en is, J., “Modularity”, in Advanced Course on Software Engineering (F.L.

[3] Wirth, N., “Program Development by Stepwise Refinement”, CACM, vol. 14, no.

4, 1971, pp. 221-227. [4] Dahl, O., E. Dijkstra, and C. Hoare, Structure Programming, Academic Press,

1972. [5] Mills, H. D., “M

Report FSC 7Maryland, 1972.

[6] Stevens, W., G. Myer, and L. Constantine, “Structured Design”, IBM Systems

Jour [7] Jackson, M., Principles of Program Design, Academic Press, 1975. [8] Warnier, J., Logical Construction of Programs, Van Nostrad Reinhold, 1974. [9 [1 [1 [1

Departamento de Computación UNAN - León

Page 194: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 194 de 316

[14] Dijkstra, E., “Structured Programming”, in Software Engineering, Concepts and Techniques. (J. Buxton et al., eds.), Van Nostrad Reinhold, 1976.

[15] Software: un enfoque práctico, 3ª ed., Mc. Graw Hill, 1993.

Pressman, R. S., Ingeniera del

Departamento de Computación UNAN - León

Page 195: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 195 de 316

MMOODDEELLOO LLÓÓGGIICCOO DDEE DDAATTOOSS

Departamento de Computación UNAN - León

Page 196: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 196 de 316

7.9 Modelo Lógico de Datos

Título del tema 8: Modelo Lógico de Datos.

Objetivos: • Comprender la importancia del Modelo Lógico de Datos en el proceso

de Diseño del Sistema.

• Explicar la elaboración de un M.L.D, considerando las tres eventualidades de elaboración del sistema de gestión de datos.

• Exponer el Modelo CODASYL como un primer soporte del Modelo Lógico de Datos.

• Exponer el Modelo Relacional como un segundo soporte del Modelo Lógico de Datos.

• Dar a conocer una tercera alternativa de soporte del Modelo Lógico de Datos, conocida como Ficheros Clásicos

.

Contenido: • Introducción.

• Modelo CODASYL.

o Reglas de elaboración del modelo CODASYL.

o Otras reglas.

o Reglas de transformación de un M.C.D en M.L.D CODASYL.

o Aplicación al ejemplo recapitulativo.

• Modelo Relacional.

o Conceptos del modelo relacional.

o Reglas de transformación de un M.C.D en un M.L.D relacional.

o Ejemplo.

o Aplicación al ejemplo recapitulativo.

Departamento de Computación UNAN - León

Page 197: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 197 de 316

• Caso de los ficheros clásicos.

o Introducción.

Definiciones acerca de los ficheros.

o Reglas de Transformación de un M.C.D en un M.L.D de tipo ficheros clásicos.

al ejemplo recapitulativo.

o

o Ejemplo.

o Aplicación

• Enfoque general de optimización de un M.L.D..

Du irac ón: •

6 horas

Bib glio rafía básica: • 1997. Análisis y Diseño de Sistemas. 3 Edición.

Pearson Educación.

• istemas. 1 Edición. Prentice Hall.

ilbliografía adicional al final del capítulo.

Kendall y Kendall.

Seen James. 1996. Análisis y Diseño de S

• Ver b

Departamento de Computación UNAN - León

Page 198: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 198 de 316

7.9.1 Introducción El Modelo Conceptual de Datos (M.C.D.), independencia de las de El Modelo Lógico de Datos (cuenta los elementos siguie

1. El nivel y tipo de automatización.

Se trata de contemplar en el M.L.D. la parte de M.C.D. que será automatiza o diferido) será estudiado en el momento en que se haga la optimización del M.L.D.;

2. e criterios técnicos con respecto al sistema de gestión de datos:

3. Criterio de base de datos de tipo CODASYL (ref. [CODA71]),

4. Cr r

5. Criterio de ficheros clásicos.

Vamos a estudiar sucesivamente la elaboración del M.L.D. considerando las tres eventualidades de elaboración del sistema de gestión de datos.

7.9.2 Modelo CODASYL

7.9.2.1 Conceptos Este modelo, llamado también “EN RED”, es el que ha sido adoptado inicialmente en MERISE como soporte del modelo lógico de datos. Está perfectamente adaptado ya que un Sistema de Gestión de Datos en red como IDS II, TOTAL, CLIO... Este modelo ha sido normalizado por el grupo de trabajo “CODASYL” (Conference On Data Systems Languages) que ha producido las recomendaciones correspondientes [1]. Vamos por tanto a examinar los conceptos manipulados.

1. Record

Definición: Un RECORD es un conjunto de datos elementales que representa un registro lógico en un entorno de base de datos.

ha permitido representar los datos con cisiones técnicas.

M.L.D.) está construido a partir del M.C.D. teniendo en ntes:

da. El tipo de automatización (tiempo real o tiemp

Adopción d

ite io de base de datos RELACIONAL,

Departamento de Computación UNAN - León

Page 199: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 199 de 316

Un record se caracteriza por: sus propiedades llamadas también DATA-ITEM,

• el modo de acceso a las ocurrencias del RECORD,

Los dos principales modos de acceso a un record son:

• CALC (para acceso calculado sobre la clave).

apel de clave de acceso del RECORD (pueden existir varias claves).

El acceso a una ocurrencia de un record se hará por medio de un enlace que materializa una relación con otro record.

Formalismo y ejemplo

Este esquema representa RECORD CLIENTE

2. Set

• la lista de

• el nombre que se le asigna.

Una propiedad tiene el p

• VÍA SET (por un enlace lógico).

Definición:

El SET representa el enlace entre un record llamado OWNER (propietario) y otro record llamado MEMBER (miembro). Formalismo y ejemplo RECORD “OWNER”

RECORD “MEMBER” SET HACER-PDO

Figura 7.9.1 Ejemplo de un SET.

CLIENTE

CLIENTE

PEDIDOS

Departamento de Computación UNAN - León

Page 200: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 200 de 316

En la Figura 7.9.1, se puede ver que:

tipo Padre-Hijos LIENTE y PEDIDOS.

ACER-PDO le hará

corresponder las n ocurrencias de PEDIDOS que le están asociadas.

• Este formalismo se llama DIAGRAMA DE BACHMAN [2].

7.9.2.2 Reglas de elaboración del modelo CODASYL. Las pr ecto a los SETS y a los RECORDS ue han sido enunciadas en las recomendaciones de CODASYL son las siguientes:

Regla 1. Todo RECORD puede ser miembro de varios sets diferentes. Un ejemplo de esta regla se puede ver en la Figura 7.9.2:

SET PEDIR SET PROVEER El record PRODUCTO es miey del SET PROVEER

Figura 7.9.2 Regla 1 del Modelo CODASYL.

• El SET HACER-PDO representa la relación dellamada también 1...n entre C

• A una ocurrencia de CLIENTE el SET H

incipales reglas de elaboración con respq

CLIE

mbro del SET PEDIR

NTE

PROVEEDOR

PRODUCTO

Departamento de Computación UNAN - León

Page 201: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 201 de 316

Re Todo REC R Un ejemp d

El record PRODUCTO es propietario del SET-LDO

y del SET L-FRA

ET L-PDO SET L-FRA

Modelo CO SYL.

egla 3.

odo RECORD puede ser a la vez:

• ios ere s.

la se puede ver en la Figura 7.9.4

gla 2.

O D puede ser propietario de varios sets diferentes.

lo e esta regla se puede ver en la Figura 7.9.3:

S

Figura 7.9.3 Regla 2 del DA R T

propietario de uno o varios SETS diferentes, • miembro en uno o var SE dif nte

TS

Un ejemplo de esta reg

LÍNEA-PDO

LÍNEA-FRA

PRODUCTO

Departamento de Computación UNAN - León

Page 202: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 202 de 316

El record PROGRAMA es SET-PROG-LIN

SET APL-PROG

Figura 7.9.4 Regla 3 del Modelo CODASYL.

egla 4.

os RECORDS pu s alquiera de sets iferentes.

lo de esta regla se puede ver en la Figura 7.9.5

ET ALQUILER SET CO-PROPIETARIO LE y OCUPANTES hay 2 sets:

- SET ALQUILER (para los inquilinos). - SET CO-PROPIETARIO (para los dueños)

Figura 7.9.5 Regla 4 del Modelo CODASYL.

propietario del

y miembro del

SET APL-PROG SET PROG-LIN

R Dd

eden e tar enlazados por un número cu

Un ejemp

S Entre INMUEB

PROGRAMA

LÍNEA-PROG

APLICACIÓN

OCUPANTES

INMUEBLE

Departamento de Computación UNAN - León

Page 203: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 203 de 316

Otras reglas.

T a la vez como OWNER y

SE .

• Un RECORD puede participar en el mismo SEcomo MEMBER (caso de una relación reflexiva).

• Para una ocurrencia de T existe siempre un OWNER

• Un record no tiene porqué estar ligado a un SET.

Departamento de Computación UNAN - León

Page 204: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 204 de 316

7.9.2.3 Reglas de transformación de un M.C.D. en un M.L.D. CODASYL

Regla

Ca o bjeto se convierte n la clave del RECORD.

egla 2 (regla aplicable a relaciones de tipo padre-hijos).

Una relación que tenga las características siguientes: - dimensión 2, - cardinalidad de los objetos participantes en la relación: - 1,1 y 1,N ó 1,1 y 0,N - 0,1 y 1,N ó 0,1 y 0,N se transforma en un SET. Un ejemplo de esta regla se puede ver en la Figura 7.9.6 M.C.D. 1,N 1,1 M.L.D.

Figura 7.9.6 Regla 2: transformación MCD MLD CODASYL. En el caso que la relación tenga propiedades, éstas se harán migrar hacia el record MEMBER.

1 (regla aplicable a objetos).

da bjeto se transforma en RECORD, el identificador del oe

R

CLIENTE

CLIENTE Nº cliente

PEDIDO Nº código

PEDIDO

HACER PDO.

HACER PDO.

Departamento de Computación UNAN - León

Page 205: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 205 de 316

Regla 3 (regla aplicable a relaciones de dimensión 2).

Una relación que tenga las características siguientes: - dimensión 2.

- cardinalidad de los objetos pertenecientes a la relación: - 0,N y 0,N ó 1,N y 1,N

record y dos SETS.

M

1,N

PROVEEDOR PRODUCTO

Figura 7.9.7 Regla 3: transformación MCD CODASYL.

egla 4 (regla aplicable a relaciones de dimensión >2).

na relaci im n tos SETS como objetos participan en la relación.

éase la relación “INTERVENIR” tratada en el ejemplo recapitulativo.

- 0,N y 1,N ó 1,N y 0,N se transforma en un Un ejemplo de esta regla se puede ver en la Figura 7.9.7

.C.D. 1,N M.L.D. CATÁLOGO CATÁLOGO

MLD

R U ón de d e sión mayor que 2 se transforma en un record y tan

Ejemplo: V

ROV Nº

P EEDOR

proveedor

PRODUCTO Nº prod.

PRODUCTO

PROVEER

precio

PROVEEDOR

CATÁLOGO P.

Departamento de Computación UNAN - León

Page 206: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 206 de 316

7.9.2.4 Aplicación al ejemplo recapitulativo

Enunciado del caso: Sea una “pyme” (pequeña y mediana empresa) especializada

ada terve ión d el cliente; las principales informaciones del contrato son:

• la descripción sucinta del trabajo,

• la fecha de inicio del trabajo,

• la cualificación requerida de cada persona (hay una lista de las cualificaciones posibles).

• el número de pre t

• Cada cualificación tiene una tarifa diaria.

me” se otorga una cieta flexibilidad a la hora de determinar la procediendo de la manera siguiente:

• Cada persona posee a priori una cualificación base.

• ismo en bajo

está determinada en todo contrato. La cualificación requerida siempre debe pertenecer al conjunto de las cualificaciones estándar.

e pide: Construir el M.C.D. correspondiente al sistema simplificado arriba.

olución p

vestigación de los objetos de la gestión

en proporcionar personas bajo petición de sus clientes. C in nc a lugar a un contrato con

días por h bre vis om o.

• La “pycualificación precisa de su personal

A cada trabajo se le puede ajustar la cualificación requerida por el mrelación a la cualificación base de una persona. La cualificación del tra

S S del ejem lo recapitulativo. In

Esta “pyme” genera las cuatro entidades siguiente s:

- Contratos (un cliente puede hacer varios contratos).

- Cualificaciones. La representación de estos objetos (Figura 7.9.8) puede ser fácilmente elaborada:

- Clientes. - Personas.

Departamento de Computación UNAN - León

Page 207: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 207 de 316

de los objetos de la PYME.

v ti d

CLIENTE Núm. cliente Sede Social

Figura 7.9.8 Representación In es gación de las relaciones y de la cardinalida

C nrela ó

C n ernir a una o varias ua com

por - Pers

relac

, hay la

La Figura 7.9.9 presenta el M.C.D. completo:

- lie te - Contrato: Un cliente puede hacer de 1 a n contratos. Por tanto, hay la

ci n “HACER CONTRATO”. - o trato - Cualificación: Un contrato puede conc

lifi aciones. Para una cualificación tendremos el número previsto de días por ch bre. Por tanto, hay la relación “REQUERIR” con la propiedad número de días

hombre.

onal - Cualificación: Cada empleado posee una cualificación. Por tanto, hay ión “CUALIFICAR”. la

- Personal - Cualificación - Contrato: Un empleado puede intervenir en un contrato con una cualificación distinta a su cualificación base. Por tantorelación “INTERVENIR”.

Dirección

CONTRATO Núm. de contrato Objeto Fecha inicio

PERSONAL

Núm. empleado Apellido Nombre Etc.

CUALIFICACIÓN Código cualif. Descripción cualif. Tarifa/día

Departamento de Computación UNAN - León

Page 208: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 208 de 316

1,n

1,n

1,n

0,n 0,n0,n

1,1

1,1

.D. presentado en la Figura 7.9.9 inicialmente presentaremos la las reglas de transformación del M.C.D. en M.L.D. y a continuación

Los objetos se transforman en RECORDS.

BJETOS RECORDS CLIENTE L-CLIENTE CONTRATO L-CONTRATO PERSONAL L-PERSONAL CUALIFICACIÓN L-CUALIFICACIÓN - las relaciones. - caso de las relaciones simples de tipo padre-hijos

Figura 7.9.9 M.C.D completo del ejemplo recapitulativo. Dado el M.Cplicación dea

presentaremos el diseño del M.L.D. Transoformación de objetos y relaciones - los objetos.

O

Estas relaciones se transforman en SETS. Examinemos el caso de cada relación.

CLIENTE Núm. cliente Sede Social Dirección

CONTRATO Núm. de contrato Objeto Fecha inicio

PERSONAL Núm. empleado Apellido Nombre Etc.

CUALIFICACIÓN

if. Código cual Descripción cualif. Tarifa/día CUALIFICAR

INTERVENIR

HACER CONTRATO

REQUERIR

Núm. días x hombres

1,n

Departamento de Computación UNAN - León

Page 209: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 209 de 316

Departamento de Computación UNAN - León

• HACER CONTRATO ..... se convierte en el set L-HACER-CONTRATO entre L-LIENTE (owner) y L-CONTRATO (member). Regla 2.

CUALIFICAR ..... se convierte en el set L-CUALIFICAR entre L-PERSONAL owner) y L-CUALIF (member). Regla 2.

- caso de las otras relaciones

C •( ICACIÓN

• REQUERIR

Regla 3

L-CONTRATO-CUALIF. campo: L-Número de días-hombre;

- 2 SETS: - el SET L-CONTRATO-CARGO: Record OWNER: L-CONTRATO,

Rec - el SET L-CUALI-CARGO: Record OWNER: L-CUALIFICACIÓN,

• INTERVENIR la 4)

- 1 record L-CONTRATO-CARGO,

- el SET L-CUALIFINT.

c

La representación gráfica del M.L.D. CODASYL se da en la Figura 7.9.10.

Esta relación se transforma en: (por la ) - 1 record L-CARGO, clave:

ord MEMBER: L-CARGO. Record MEMBER: L-CARGO. Esta relación se transforma en: (por la Reg - 3 SETS: - el SET L-CONTRATO-CUALIFINT, - el SET L-PERSONAL-CUALIFINT,

Representación gr fi a.á

Page 210: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 210 de 316

Nº cliente Nº contrato L-HACER-CONTRATO

L-CONTRATO-CARGO

FINT L-CUALI-CARGO

Código cualif.

L del ejemplo recapitulativo.

de cada RECORD. Este número e s .L.D.

jemplo:

L-CONTRATO-CUALIF.

L-PERSONAL-CUALIFINT L-CUALI Nº empleado

Figura 7.9.10 M.L.D CODASY A efectos de complementar la representación propuesta en la Figura 3.1 se recomienda hacer figurar el número de ocurrenciass u ará en la fase de optimización del M E

L-CLIENTE

L-CONTRATO

L-CARGO

L-CONTRATO-CARGO

L-PERSONAL

L-CUALIFICACIÓN

L-CONTRATO 5 000

Departamento de Computación UNAN - León

Page 211: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 211 de 316

7.9.3 Modelo relacional

este epígrafe el modelo relacional. l estudiante puede informarse en las numerosas obras de referencia sobre este ma ([3] y [4]). Nos limitaremos pues a la introducción de los principales conceptos

desarrollaremos las reglas d ción del M.C.D. al M.L.D. de tipo l c n l.

.9.3.1 Presentación de los conceptos del modelo relacional.

ominio.

to.

jemplo:

No es nuestra intención tratar completamente enEtey e transformare a io a

7 D Es el conjunto de valores qu ede tomar un da

e pu

E - el dato MARCA estará definido sobre el dominio: D1=RENAULT, PEUGEOT

- el dato color estará definido sobre el dominio: D2=azul, blanco, rojo

- el dato salario estará definido sobre el dominio: D3= entre 5.000 y 100.000 F

Relación (lla ás co

s un subconjunto del producto cartesiano de dominios. Este subconjunto estará

mada m rrientemente TABLA). Edesignado por un nombre que será el nombre de la relación (o tabla). Ejemplo: Consideremos el producto cartesiano D1*D2:

RENAULT, azul RENAULT, blanco

RENAULT, rojo , azul

blanco rojo

TUPLO.

na relación está descrita citando todos los tuplos del subconjunto de D1*D2, sea descrita de la manera siguiente:

COCHE D1 D2 RENAULT blanco PEUGEOT blanco RENAULT rojo PEUGEOT rojo

PEUGEOT PEUGEOT, PEUGEOT, Cada pareja se llama Upor ejemplo la relación COCHE,

Departamento de Computación UNAN - León

Page 212: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 212 de 316

Atributo.

epresenta una columna de una relación caracterizada por un nombre. R Ejemplo: MARCA y COLOR son los atributos de la relación COCHE. Esta relación se escribe: COCHE (MARCA, COLOR). Clave de una relación.

na clave está constituida por uno o varios atributos cuyos valores definen de ica los tuplos de la relación.

Umanera ún Ejemplo: sea la relación EMPLEADO EMPLEADO (APELLIDO, NOMBRE, FECHA NACIMIENTO, SALARIO)

a que

or razones de seguridad procederemos así: tomaremos los atributos APELLIDO,

“artificial” Nº EMPLEADO, dando lugar a la relación:

Si tomáramos el atributo APELLIDO como clave de la relación comportaría un riesgo

podrían existir homónimos. y

PNOMBRE y FECHA NACIMIENTO como clave y les asignaremos un atributo

EMPLEADO (Nº EMPLEADO, APELLIDO, NALARIO) con los tuplos siguientes:

OMBRE, FECHA NACIMIENTO,

- tuplo 2 1013 DURAND JEANNE 03/08/55 7.500

- tuplo 3 1014 DUPONT PIERRE 10/05/49 8.400

están subrayados.

Si hay varias claves para una relación se escogerá una entre ellas como clave rimaria de la relación; las otras serán llamadas claves candidatas.

S - tuplo 1 1012 DURAND JEAN 15/10/52 7.500

Obsérvese que el -o- los atributos clave

p

Departamento de Computación UNAN - León

Page 213: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 213 de 316

7.9.3.2 Reglas de transformación de un M.C.D. en un M.L.D. relacional Reglas para los OBJETOS del M.C.D.

Reglas para las RELACIONES del M.C.D.

Caso de la relación padre-hijos

ardinalidad del objeto “padre” 0,N ó 1,N -cardinalidad de los objetos “hijos” 0,1 ó 1,1).

(c

- El objeto “padre” se convierte en tabla “padre”.

- Los objetos “hijos” se convierten en tabla “hijos”.

- El identificador del objeto “padre” se convierte en atributo de la tabla “hijos”.

- Este atributo se llama también clave tercera.

- Las propiedades de la relación se convierten en atributos de la tabla “hijos”.

e convierte en la clave primaria de la tabla.

- Las propiedades del objeto se convierten en atributos de la tabla.

- El objeto se transforma en una tabla.

- El identificador del objeto s

Departamento de Computación UNAN - León

Page 214: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 214 de 316

Ejemplo: M.C.D. TABLAS M.L.D. RELACIONAL

CLIENTE (NUMCLI, APELLIDO)

1,N

- caso de otras relaciones

CLIENTE

. numcli

. nom

1,1 PEDIDOS (NUMPDO, FECHA, NUMCLI )

HACER PDO.

PEDIDOS . núm. pdo. . fecha

(cardinalidad de los objetivos 0,N ó 1,N)

-Un objeto se convierte en una tabla. El identificador del objeto se convierte en clave

-Una relación se convierte en una tabla.

-El identificador de la relación se convierte en clave primaria de la tabla.

de la tabla.

Departamento de Computación UNAN - León

Page 215: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 215 de 316

7.9.3.3 Ejemplo

A M.C.D. TA S M.L.D. RELACIONAL BL PROVEEDOR (NOMPROV, CALLE, CIUDAD)

PROVEEDOR (NOMPROV-NUMPROD

1,N , PRECIO) 1,N PRODUCTOS (NUMPROD, DESCRIPCIÓN)

o recapitulativo

formación de los objetos y relaciones

ea el M.C.D. de la Figura 7.9.9, el paso al M.L.D. de tipo relacional se efectúa omo sigue:

los OBJETOS se transforman en TABLAS: CLIENTE .................... T-CLIENTE (NUMCLIENTE

7.9.3.4 Aplicación al ejempl Trans Sc - , SEDESOCIAL...)

CONTRATO ........ ...... T-CONTRATO (NUMCONTRATO , OBJETO...) PERSONAL ........... .... T-PERSONAL (NUMEMPLEADO , APELLIDO...) CUALIFICACIÓN ... . T-CUALIFICACIÓN (CODCUALI , DESCRIPCIÓN...)

las relaciones de tipo “padre-hijo” completan las TABLAS “hijos” ya creadas de la anera siguiente:

• la relación HACER-CONTRATO completa la tabla T-CONTRATO al añadirle el número de cliente:

T-CONTRATO (NUMCONTRATO

- m

, OBJETO..., NUMCLIENTE)

• la relación CUALIFICAR completa la tabla T-PERSONAL al añadirle el código de cualificación:

PROVEEDOR nomprov calle ciudad

PROVEER

S PRODUCTO

numprod.

precio

descripción

Departamento de Computación UNAN - León

Page 216: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 216 de 316

T-PERSONAL (NUMEMPLEADO, APELLIDO, .........., CODCUALI) s se transforman en nuevas tablas:

RIR

T-REQUERIR (NUMCONTRATO-CODCUALI, DÍASHOMBRE)

T-CUALIF-INT (NUMCONTRATO-CODCUALI-NUMEMPLEADO)

Representación completa del M.L.D. relacional del ejemplo recapitulativo.

M.L.D. rela nal del ejemplo recapitulativo se representa bajo la forma de la lista e tabla que lo componen, son las seis siguientes:

las otras relacione

• la relación REQUERIR ----------------------- > T-REQUE

• la relación INTERVENIR -------------------- > T-CUALIF-INT

Ed

l cios

T-CLIENTE (NUMCLIENTE, SEDE SOCIAL)

T-CONTRATO (NUMCONTRATO, OBJETO, .. , NUMCLIENTE...)

T-PERSONAL (NUMEMPLEADO, APELLIDO, ....., CODCUALI)

(CODCUALI T-CUALIFICACIÓN , DESCRIPCIÓN, ....)

T-REQUERIR (NUMCONTRATO-CODCUALI, DÍASHOMBRE)

LI-NUMEMPLEADO T-CUALIF-INT (NUMCONTRATO-CODCUA )

Departamento de Computación UNAN - León

Page 217: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 217 de 316

7.9.4 Caso de los ficheros clásicos

7.9.4.1 Introducción.

l objetivo del presente epígrafe es tratar el caso en que se considera una solución de h os rápidamente lguna de las nociones necesarias para la comprensión de este enfoque.

Poster en ficheros clásicos.

egistro de un fichero

• Un registro es una colección de propiedades que se refieren a un mismo tema.

• Una ocurrencia de un registro representa el conjunto de los valores de las propiedades para un registro en particular.

ichero

• Un fichero es un conjunto de informaciones agrupadas en registros.

• El identificador de un fichero es una propiedad escogida de tal forma que a cada valor de dicha propiedad le corresponde una, y sólo una, ocurrencia del registro del fichero.

Ejemplo:

Fichero CLIENTE:

• Num-Cliente (identificador) • Apellido. • Calle. • Ciudad. • Etcétera.

Efic eros clásicos para la gestión física de los datos. Presentarem

aiormente daremos las reglas de un M.C.D. a un M.L.D. basado

7.9.4.2 Definiciones con respecto a los ficheros R

F

Departamento de Computación UNAN - León

Page 218: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 218 de 316

7.9.4.3 Reglas de transformación de un M.C.D. en un M.L.D. de tipo ficheros clásicos.

aso de los objetos: c

aso de las relaciones de tipo “padre-hijos”:

- 1 objeto --------------------------- > 1 fichero (lógico) - el identificador ------------------ > la identificación del artículo del fichero - las propiedades ---------------- > las propiedades (o informaciones o campos) c

dre” - objeto “hijos” -------------------- > 1 fichero “hijos”

re” ----------- > propiedad del fichero “padre”

.9.4.4

M.C.D.

ero CLIENTE Fichero PEDIDO - numpdo (identificador)

- fecha - etc. - numcli

Ejemplo: véase la aplicación al ejemplo recapitulativo. caso de otras r c

- objeto “padre” ------------------ > 1 fichero “pa - identificador “pad

- propiedades de la relación -- > propiedades del fichero “hijos”

7 Ejemplo

1,N 1,1

M.L.D. “ficheros clásicos”. Fich - numcli (identificador)

- apellido

ela iones: - 1 relación ------------------------------ > 1 fichero - identificador de la relación --------- > identificador de fichero

CL numcl

IENTE i

apellido

PEDIDO numpdo fecha

HACER

Departamento de Computación UNAN - León

Page 219: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 219 de 316

7.9.4.5 Aplicación al ejemplo recapitulativo

ea el M.C.D. presentado en la Figura 7.9.9, el M.L.D. de tipo ficheros clásicos es el siguiente:

los objetos se transforman en ficheros lógicos:

- sedesocial

CONTRATO - numcontrato (identificador)

o

- numempleado (identificador) - apellido

• CUALIFICACIÓN ------------------- F-CUALIFICACIÓN

- codcuali (identificador) - descripción

- las relaciones del tipo “padre-hijos” se traducen en la agregación de sus informaciones a los ficheros lógicos correspondientes a los objetos hijos de las relaciones:

- agregación de codcuali en F-PERSONAL.

n en nuevos ficheros:

campos:

- NUMCONTRATO-CODCUALI (identificador) NDÍASHOMBRE

La relación INTERVENIR se transforma en un fichero F-CUALIF-INT con el campo: - NUMCONTRATO-CODCUALI-NUMEMPLEADO (identificador)

S

-

• CLIENTE ----------------------------- F-CLIENTE - numcliente (identificador)

• CONTRATO ------------------------- F-

- objet

• PERSONAL -------------------------- F-PERSONAL

- agregación de numcliente en F-CONTRATO,

- otras relaciones se transforma • La relación REQUERIR se transforma en un fichero F-REQUERIR con los

- •

Departamento de Computación UNAN - León

Page 220: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 220 de 316

7.9.5 Enfoque general de optimización de un M.L.D

AL, FICHEROS CLÁSICOS) no es óptimo desde el punto de vista de las prestaciones de acceso lógico.

ara poder hacer esta optimización hará falta disponer:

• odelo ente los tipos y

frecuencias de los accesos a los datos así como el tipo de funcionamiento (tiempo real o tiempo diferido).

• la enumeración de las ocurrencias de los RECORDS y SETS o TABLAS o FICHEROS LÓGICOS.

l obje ivo pe segui o por opti izació es d cos al M.L.D. para los tratamientos del M.O.T.

ncia en el M.L.D. para obtener un mínimo número de accesos lógicos.

Ejemplo tipo:

El M.L.D. obtenido anteriormente para cada tipo de representación (CODASYL, RELACION

P

del modelo organizacional de los tratamientos, incluído un moperacional inicial de los tratamientos que requerirá especialm

E t r d la m n isminuir el número de accesos lógi

La tarea de optimización consistirá en crear el mínimo de redunda

Añadir un SET en un M.L.D. de tipo CODASYL para evitar tener que recorrer sistemáticamente uno o varios RECORDS intermedios teniendo en cuenta que la

ecuencia es elevada. fr

Departamento de Computación UNAN - León

Page 221: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 221 de 316

Bibliografía adicional

dasyl Daba Base Task Group”, ACM, New York,

[2] B

[1] Codasyl, “Report on the Co USA, 1971.

achman, Ch. W., “Data structure diagrams, Database”, vol. 1, no. 2, 1969.

Departamento de Computación UNAN - León

Page 222: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 222 de 316

MMOODDEELLOO LLOOGGIICCOO DDEE TTRRAATTAAMMIIEENNTTOO

Departamento de Computación UNAN - León

Page 223: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 223 de 316

7.10 Modelo Lógico de Tratamiento

Título del tema 9: Modelo Lógico de Tratamiento.

Objetivos: • Dar a conocer qué son y para qué sirven los tratamientos.

• Explicar los pasos del método de diseño conceptual de tratamiento.

Contenido: • Introducción.

• Método de diseño coneceptual de tratamientos.

o Determinación del DFD d

o Eliminación de circuitos.

o Establecimiento de la matriz de incidencias.

o Diagrama de precedencia de procesos.

o Agrupación de procesos con el mismo orden externo.

o Diagrama de precedencia de operaciones.

o Determinación de la Red de Petri.

o Establecimiento de los diagramas de acción.Introducción.

e detalle.

Duración: • 4 horas

Bibliografía básica: • Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición.

Pearson Educación. • Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice

Hall.

• Ver bilbliografía adicional al final del capítulo.

Departamento de Computación UNAN - León

Page 224: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 224 de 316

7.10.1 Introducción Los tratamientos constituyen la parte dinámica del sistema de información. Describen las acciones a ejecutar sobre los datos a fin de obtener los resultados deseados p Los tratamientos no son de hecho, más que la traducción en acciones de las reglas de gestión que guían la actividad de la empresa. Ejemplo: Sea la regla de gestión siguiente: “Un pedido sólo será considerado si la cantidad en stock es superior a la cantidad pedida”. Esta regla de gestión se traduce en los tratamientos de informaciones siguientes:

• Leer la cantidad p

• Comparar dicha c tock.

• Si la cantidad pedida es superior a larechazado,

• En caso contrario

La representación esquemática con la ayuda del formalismo MERISE de la actividad o de un subconjunto de la actividad de una empresa independientemente de las decisiones de la organización y de los medios de ejecución, corresponderá al Modelo Conceptual de Tratamientos (M.C.T.). En otras palabras, el M.C.T. permite representar las acciones llevadas a cabo por la empresa para conseguir sus finalidades.

ENFOQUE GENERAL DE LA FINALIDAD DEL M.C.T

OBJETIVO INTENCIÓN

or la empresa.

edida.

antidad con la cantidad en s

cantidad en stock el pedido es

, el pedido es aceptado.

CONCEPTO Modelo Tratamientos ados en la empresa

con independencia de su

ni el cómo)

Conceptual de Representar los tratamientos ejecut

El qué (sin el quién

organización

Departamento de Computación UNAN - León

Page 225: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 225 de 316

7.10.2 Método de diseño conceptual de tratamientos

1. Determinación del DFD de detalle.

2. Eliminación de circuitos.

blecimiento de la matriz de incidencia informaciones/procesos.

de procesos.

5. Agrupación de procesos con el mismo orden externo (determinación de operaciones).

Petri (sincronizaciones y bucles).

8. Establecimiento de los diagramas de acción.

1. Determinación del DFD de detalle.

onsideraremos que disponemos de él como punto de partida, habiéndose obtenido el DFD por alguno de los múltiples procedimientos de obtención existentes.

acía de nodos (no necesariamente todos distintos) de manera que constituyen un camino y el extremo final del mismo coincida con el extremo inicial.

entonces se tendrá:

(xip,xip+1) ∈ U para p= 1,2, ..., (q-1) y además, (xiq,xi1) ∈ U siendo U el conjunto de arcos de la dupla G(x,U).

Se dice que x’ es ascendiente de x si existe el camino x’ → x.

Se dice que x’ es descendiente de x si existe el camino x → x’.

El método consta de los siguientes pasos en orden secuencial:

3. Esta

4. Diagrama de precedencias

6. Diagrama de precedencias de operaciones.

7. Determinación de Red de

C

2. Eliminación de circuitos Un circuito s de un grafo -en nuestro caso, el DFD de detalle- es una sucesión circular no v

σ = xi1, xi2, xi3, ..... ,xip,xip+1, ...... ,xiq

Departamento de Computación UNAN - León

Page 226: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 226 de 316

Si un nodo es ascendiente y descendiente existe un circuito:

étodo para determinar la existencia de circuitos:

Sea

Figura 7.10.1 Ejemplo de DFD y su matriz booleana.

n esta matriz se desprecian los 1’s de la diagonal principal que corresponden a alimentación del proceso elemental.

M

a. Se toma la matriz booleana del DFD.

por ejemplo el DFD y la matriz booleana de la Figura 3.1.

x

x’

Ere

A1

I1

I2I0 I7

I10

I8I3

I4 I5

I9

I111

2

3

4

DFD Matriz booleana

1 2 3 4

1 2

1 1 0 0 0 0 0 1

I6

0 1 0 1 1 0 0 0

3 4

Departamento de Computación UNAN - León

Page 227: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 227 de 316

A la matriz obtenida se le aplica el cierre transitivo.

Cierre transitivo

diagonal principal

omo hay 1’s en la diagonal principal existen circuito/s.

b. Se toma el diccionario de siguientes del DFD.

Diccionario de siguientes

Se busca un vértice que no tenga siguientes Γ(x) = 0 y se tacha dicho vértice del diccionario. Se sigue haciendo lo mismo mientras sea posible. Si se han tachado todos los vértices se trata de un grafo sin circuitos. Si no sucede lo anterior, se coge un nodo no tacha de los que queden y se inicia con el una lista.

siguiente a dicho vértice que no esté tachado. Se sigue ste procedimiento hasta que un elemento de los añadidos esté ya en la lista bteniéndose así un circuito.

1 2 3 4

1

2

3

4

0 1 0 0 0 0 0 1 0 1 0 1 1 0 0 0

1 2 3 4

1

2

3

4

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1

Eliminación de 1’s de la

C

En el ejemplo anterior tenemos:

x Γ(x)

1

2

3

4

2 4 2,4 1

Se añade a la lista el primer eo

Departamento de Computación UNAN - León

Page 228: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 228 de 316

En el ejemplo anterior tenemos, comenzando por 1, lo siguiente:

1 - 2 - 4 - 1 ⇒ Circuito

∨ I2 ∧ I10 ∨ A ∧ I2 → A, I3

= I3 ∧ I7 ∧ I6 → I8

s4 = I8 ∧ I9 → I10

En estas expresiones podemos observar que s4 requiere imprescindiblemente I8 ego, necesita la realización del proceso 2. A su vez, s2 requiere de I3 luego,

requiere la realización del proceso 1.

ionalmente de I10, pero puede realizarse sin ella cuando e dispone de I0 e I1 luego, no es imprescindible. Se crea un nuevo grafo en el que

Seguidamente, se analiza el subconjunto del DFD del circuito.

I0I1 I2

I3I6 I7

4

I9I8

1

2

I10

Se analizan los predicados de cada sincronización. Sean estos: s1 = I0 ∧ I1

s2

lu

Por último, s1 requiere opcsse elimina la realimentacion, es decir, el cierre 4 - 1 del ejemplo. Lo mismo se hace en el caso de reflexión, resultando el grafo sin circuito (Figura 7.10.2).

Departamento de Computación UNAN - León

Page 229: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 229 de 316

étodo de determinación de circuitos, ción de todos los circuitos.

plicando el cierre transitivo resulta:

Figura 7.10.2 Grafo sin circuito. Sobre el grafo obtenido se aplica de nuevo el mrepitiéndose el proceso anterior hasta la elimina

a

A1

I1

I2I0 I7

I8I3

I4I5

I9

I111

24

I10

I6

3

1 2 3 4

1

2

0 1 0 0 0 0 0 1

3

4

0 1 0 1 0 0 0 0

Departamento de Computación UNAN - León

Page 230: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 230 de 316

luego ya no existen circuitos. Si hubiésemos empleado el diccionario de siguientes y dando los pasos de determinación de circuitos tendremos:

luego ya no hay más circuitos.

En el caso de que el circuito no hubiera podido eliminarse por no existir expresiones ooleanas disjuntas existe ificación que es preciso revisar hasta ue desaparezca el circuito.

3. Establecimiento de la matriz de incidencia.

Se diseña una matriz en la cual en filas colocamos las informaciones y en columnas los procesos. En la matriz se coloca un 1 en el elemento ai5 si la información Ii es requerida en el roceso p5 , -1 en el elemento aRl si la información IR es suministrada por el proceso

pl y cero cuando la información no participa en el proceso.

1 2 3 4

0 1 0 1

0 1 0 1 0 0 0 0

1

3

4

2

0 0 0 1

x Γ(x)

1

4

2

0

4 2,4

1

3

0 0

2

3

b un error de especq

p

Departamento de Computación UNAN - León

Page 231: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 231 de 316

En el ejemplo resulta:

as filas que sólo tienen 1’s corresponden a informaciones externas. Las filas que sólo tienen -1’s corresponden a informaciones resultados. Las filas que tienen 1’s y -’s corresponden a informaciones intermedias.

ncias de procesos

Se aplica el siguiente algoritmo:

1. Seleccionar los procesos que sólo requieren información externa.

nar los procesos que requieren informaciones ya obtenidas y eventualmente informaciones externas.

n la Figura 7.10.3 mostramos este paso del método para el ejemplo:

1 2 3 4

1 0 0 0 E 1 0 0 0 E 1 0 0 0 E 0 -1 0 1 - -1 0 0 0 R

0 0 - 0 1 0 0 E

0 0 1 0 E 0 1 -1 0 -

-

R

R

I0

I1

I2

I8

A

I7

I5

I6

I10

I11

I3 -1 1

I4

0 0 1 0 E

I9 0 0 -1 1

0 0 0 -1

0 0 0 -1

L

1

4. Diagrama de precede

2. Seleccio

3. Se repite el paso 2 hasta finalizar con todos los procesos.

E

Departamento de Computación UNAN - León

Page 232: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 232 de 316

I0 I1 I2 I4 I5

1 3

I7 I6 I9 I3

2

I8

4externo externo

interno

resultado

I10

I10 I11

Figura 7.10.3 Ejemplo para explicar el Diagrama de Precedencia de Procesos.

5. Agrupación de procesos con el mismo origen externo (determinación de operaciones):

Proceso Información externa requerida

1 I0, I1, I2

2 I0, I1, I2, I7, I4, I5

3 I4, I5

4 I0, I1, I2, I7, I4, I5

Departamento de Computación UNAN - León

Page 233: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 233 de 316

luego resulta:

Operación

Proceso

OP1 1

OP3 2,4

OP2 3

6. Diagrama de precedencias de operaciones. 6.a. Se construye la matriz de inciderequeridas, eliminando las informaciones internas de una operación. Es decir, sólo se consideran las informaciones exteoperación distinta a la que las generó.

e recogen como acontecimientos resultado, los resultados de la operación y las

ncia de operaciones e informaciones

rnas y las internas utilizadas por una

OP1 OP2 OP3

I0

I2

I3

I4

I5

I6

I7

I9

I10

A

I11

1

1

-1 1 1 1 -1 1 1

-1 1 -1 -1 -1

I1 1

I8 se elimina al ser unainformación interna a laoperación OP3 y no serutilizado por otraoperación.

I8

Sinformaciones internas utilizadas por otra operación.

Departamento de Computación UNAN - León

Page 234: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 234 de 316

6.b. Se aplica el algoritmo de precedencias.

En el ejemplo resul

7.

ias de operaciones las condiciones de incronización de cada operación y en restablecer los circuitos eliminados por existir isyunción.

Aplicando lo anterior al diagrama del ejemplo resulta:

ta:

I3 I6 I9

Determinación de la red de Petri. Consiste en añadir a la red de precedencsd

P1 OP1 OP2 P3

P2, P4OP3

I0 I1 I2 I4 I5

I7 A

I10 I11

Departamento de Computación UNAN - León

Page 235: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 235 de 316

Los predicados y condiciones locales sólo pueden hacer referencia a propiedades e los acontencimientos de entrada.

lecimiento de los diagramas de acción

Finalmente, se establece el diagrama de acción de cada operación, lo cual no coge la Red de Petri.

a Red de Petri en sus operaciones recoge únicamente el inventario de procesos ero no la secuencia y condiciones de ejecución de éstos.

A título de ejemplo, se recoge el diagrama de acción de OP3.

I0 I1 I2 I4 I5

I3 I7 I6 I9

I10 I11

P1 A OP2 P3

P2, P4OP3

s1= I0∧I1∨I2∧I10∨A∧I2 I4∧I5

I3∧I6∧I7∧I9

d

8. Estab

re Lp

Departamento de Computación UNAN - León

Page 236: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 236 de 316

MIENTRAS I3∧I7∧I6∧I9

SI I3.a = 100

HACER P4

I7.c

P2

SI I3.a ≠ 100

P2

F

IN

SINO

HACER

SINO

SINO

HACER

= I9.d SI I6.b = Pueden hacer referenciaa propiedades Modelo Conceptual deDatos.

del

Departamento de Computación UNAN - León

Page 237: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 237 de 316

Bibliog

Merise, Ed. Masson, 1991.

rafía adicional

Aprender y practicar [1] Gabay, J.,

Departamento de Computación UNAN - León

Page 238: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 238 de 316

PPRRÁÁCCTTIICCAASS DDEE LLAABBOORRAATTOORRIIOO

Departamento de Computación UNAN - León

Page 239: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 239 de 316

8 PRACTICAS DE LABORATORIO

medida que se avanza en la asignatura en aspectos teóricos, también es portante ir realizando prácticas de laboratorio, para que el estudiante conozca que

explicado en el aula de clases es aplicable a la realidad del computador. Estas afianzar y reforzar la visión que tienen

e las cuestiones teóricas de libros y apuntes. En esta sección se describe el a Análisis y Diseño de Sistemas de

formación.

bjetivos de las prácticas de Laboratorio

• Desarrollar habilidades en los estudiantes que les permitan implementar, las propuestas teóricas del análisis de los requisitos de un sistema, en diagramas de fujos de datos eficientes y comprensibles.

• Adquirir destrezas para comprender los distintos tipos de errores que se puedan originar en la elaboración de un diagrama de fujo de datos, y la forma de cómo resolverlos.

• Familiarizar al estudiante en el manejo de

que ofrece el software de análisis y diseño, EasyCASE Professional Versión 4.21.016, para la gestión los archivos de programas y para el tratamiento y depuración de errores.

Conformación de los grupos y criterios de evaluación La conformación de los grupos será como máximo de dos alumnos. La asistencia a los laboratorios es obligatoria, ya que la evaluación es acumulativa. La nota total del laboratorio representa un 20% de las notas parciales de la asignatura. Los estudiantes deberán realizar todas las prácticas establecidas en tiempo y forma para poder tener derecho al porcentaje del laboratorio. Cada grupo deberá entregar cada práctica funcionando y responder a las preguntas hechas por el profesor. Duración del laboratorio Para el laboratorio se cuentan con 2 horas semanales. Cada grupo deberá haber leído y analizado previamente el contenido de la práctica para llegar al laboratorio con ideas claras de lo que hay que realizar. Al inicio del laboratorio el profesor explicará en qué consiste la práctica y estará en el laboratorio para responder dudas y ayudar a los alumnos.

Aimloprácticas también le servirán al alumno para dprograma de prácticas de la asignaturIn O

l entorno integrado de desarrollo

Departamento de Computación UNAN - León

Page 240: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 240 de 316

Enunciados de las prácticas os enunciados de las prácticas, serán dados a conocer por el (los) profesor (es) de

la práctica desde el primer día de clases. Dichos enunciados se publicarán en la página web de la asignatura, y estarán disponibles en la secretaría del Departamento para reproducciones en fotocopias o mediante el servicio de impresión. Entrega de las prácticas asignadas Las prácticas deberán ser entregadas en el tiempo estipulado por el profesor de la

erán estar impresas en papel y serán e to como, diskettes, CDs, etc. La memoria impresa, deberá tener contener los siguientes elementos:

L

práctica. Las memorias de las prácticas, debntregadas en algún medio de almacenamien

Apartado del documento

Contenido

Carátula • Titulo de la práctica.

• Nombre de los 2 integrantes.

• Nombre del profesor que imparte la práctica.

• Fecha de entrega.

Enunciado de la • Dado por el profesor (No es necesario incluirlo en el reporte).

práctica

Solución • Es la propuesta del estudiante para resolver el problema planteado por el profesor.

• Dicha solución puede constar de gráficos o ilustraciones

adicionales a las dadas por el profesor en el enunciado de la práctica; cuando éste sea el caso, dichos gráficos deberán llevar la explicación pertinente del por qué se utilizaron y cómo ayuda a la solución del problema.

Herramientas utilizadas • El Software utilizado para compilar y ejecutar los

programas; en este caso, EasyCASE Professional Versión 4.21.016

• Algún editor de texto utilizado para elaborar el

documento de entrega de la práctica.

Explicación de la solución

• Incluir la explicación de los aspectos más relevantes o donde se presentó mayor dificultad.

Conclusiones Redactar las metas alcanzadas (debe ir de acorde con los

objetivos de la práctica, los cuales están en el enunciado proporcionado por el profesor).

Departamento de Computación UNAN - León

Page 241: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 241 de 316

Recomendaciones • Aquí se escribirán las sugerencias que sobre el desarrollo del programa tenga el alumno; podrá sugerir una mejora de su solución para futuras prácticas, etc.

Bibliografía • Referencias documentales que utilizó el estudiante para

dar solución a la práctica (pueden ser libros, folletos, sitios de Internet, revistas, manuales, etc)

Software a utilizar Se utilizarán los siguientes software:

sión 4.21.016, para la construcción de los

• Microsoft Word 2000.

• Sistema Operativo Windows 2000 Proffesional.

• EasyCASE Profesdiagramas de flujos

sional Ver de datos.

Departamento de Computación UNAN - León

Page 242: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 242 de 316

8.1 Planificación tempora

aboratorio se cu ttotal de 28 horas a lo largo de lalaboratorio.

El número de horas asignadas para cada práctica ha sido obtenido en base a la complejidad relativa y al tiempo total disponible.

Se ha buscado en la medida de lo posible, que exista una concordancia entre la realizar cada práctica de laboratorio, ya se han

impartido los conocimientos teóricos necesarios para poder desarrollarla. Sumado a est e eb de la asignatura y en la secretaría del Departamento, toda la documma a

n la T ión de las prácticas, su relación con la teoría y s r arrollarlas:

l

Como ya se ha mencionado en el apartado Teprácticas de l

mporización, para el desarrollo de las en a con una sesión de dos horas por semana, para un

s 14 semanas netas con las que se cuenta para el

teoría y la práctica, de manera que al

o, l alumno tendrá a disposición en la página wentación adicional necesaria (tutoriales,

nu les, etc) para no tener inconveniente alguno en el desarrollo de las prácticas.

abla 8.1.1 se muestra la duracEla ho as necesarias para des

Departamento de Computación UNAN - León

Page 243: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 243 de 316

e las prácticas y su relación con la teoría.

Tabla 8.1.1 Temporización d

Semana Teoría Práctica Semanas necesarias

1 -Presentación de la asignatura 1 Problemas de la gestión de la

información.

2 3

Introducción al desarrollo de Sistema de Información.

Práctica 1 Introducción al uso del Easy CAS

2

Técnicas de recopilación de datos E-

Diseño de diagramas Entidad – Relación.

4 5

Técnicas de recopilación de datos Especificación de requisitos software. ERS.

Práctica 2 Cuestionario para matricula en línea de la UNAN – León.

2

6 7

Especificación de requisitos software. ERS. Métodos de análisis de requisitos: Análisis Estructurado.

8 9

-Métodos de análisis de requisitos: Análisis Estructurado.

Práctica 3 Especificación de Requisitos Software de un Sistema de Inventario.

4

10

Modelo Conceptual de Datos Práctica 4 Ejercicio 1: Elaboración del DFD del Gallo Pinto Nicaragüense.

1

11 12

Fundamentos del Diseño Software. Modelo Lógico de Datos.

Práctica 4 Ejercicio 2: Elaboración del DFD de una Empresa Comercializadora de Productos.

2

13 14

Modelo Lógico de Datos. Modelo Lógico de Tratamiento.

Práctica 4 Ejercicio 3: Elaboración del DFD de una PYME (Pequeña y Mediana Empresa)

2

Departamento de Computación UNAN - León

Page 244: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 244 de 316

8.2 P s

8.2.1 Práctica 1

ropue ta y solución de prácticas

INTRODUCCIÓN AL USO DEL EASY CASE DISEÑO DE DIAGRAMAS ENTIDAD - RELACIÓN

OBJETIVO En esta práctica se introduce el uso del software para Análisis y Diseño de Sistemas, EasyCASE, versión 4.21.016. El estudiantes se familiaricen con el uso del software, y que puedan diseñar diagramas entidad – rela n e TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 2 sesiones de laboratorio (4 horas) SOFTWARE A UTILIZAR EasyCASE, versión 4.21.016 para Window INTRODU El CASE (Computer Aided Software Engineering) surgió a mediados de los ochenta como un intento de proporcionar un soporte automatizado a los métodos de desarrollo software estructurado. Las herramientas CASE incluyen editores gráficos interactivos que facilitan la creación de diagramas de flujo de datos y de control. La información de estos diagramas se almacena en una base de datos, llamada nciclopedia, que facilita la coordinación de un proyecto software a lo largo de todo

su ciclo de vida. En los entornos de herramientas CASE integradas, las erramientas de dirección de proyectos emplean la enciclopedia para descomponer

ignan a cada una de ellas un presupuesto y gual manera, la mayoría de herramientas

CASE, traen consigo mútliples modelos de datos integrados, con el objetivo de hacer universal su uso por parte de los analistas y diseñadores de sistemas. El diagrama de entidad-relación (también conocido como DER, o diagrama E-R) es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.

objetivo es que los

ció n base a un problema propuesto.

s.

CCIÓN TEÓRICA

e

hel proyecto software en subtareas y asun control del progreso de desarrollo. De i

Departamento de Computación UNAN - León

Page 245: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 245 de 316

¿Por qué podríamos estar interesados en modelar los datos de un sistema?. y las relaciones pueden ser tan

complejas que se deseará enfatizarlas y examinarlas independientemente del roceso que se llevará a cabo. De hecho, esto se da sobre todo si mostramos el

modelo del sistema correspondiente a los usuarios ejecutivos quienes se preocupan más por los datos: ¿Qué dato requerimos para manejar nuestro negocio? ¿Quién lo ene? ¿Quién tiene acceso a ellos?.

Los elementos de un dia ades que representan los objetos, y se representan mediante una caja rectangular; las relaciones, que on un conjunto de conexiones entre objetos, y se representan por medio de un

s atributos, que son características particulares que distinguen a un o objeto.

Primeramente, porque las estructuras de datos

p

ti

grama entidad relación, son las entidasrombo, y loobjeto de otr En la Figura 8.2.1, se muestra un ejemplo de un diagrama entidad – relación, que contiene varias entidades, varios tipos de diferentes relaciones y varios atributos.

Figura 8.2.1 Ejemplo de un diagrama E-.R.

Departamento de Computación UNAN - León

Page 246: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 246 de 316

DESARROLLO DE LA PRÁCTICA Se pide diseñar un diagrama entidad – relación para el registro académico y de becas de nuestra facultad, de acuerdo a los enunciados siguientes:

1. Un estudiante recibe una o más asignaturas en un semestre dado.

2. Un profesor imparte una o más asignaturas en un semestre dado.

3. Un estudiante puede recibir clases con uno o más profesores.

4. Una asignatura pueden ser impartida por uno o más profesores.

5. Las asignaturas se imparten en aulas.

7. En un aula se pueden impartir varias asignaturas ( a horas diferentes por supuesto ).

Tipo A: 400 córdobas Tipo B: 300 córdobas Tipo C: 200 córdobas

9. Un alumno sólo puede poseer un tipo de beca en un semestre dado.

10. Como es obvio, varios alumnos pueden poseer el mismo tipo de beca.

Se pide:

a. Diseñar el diagrama entidad – relación de acuerdo a los enunciados proporcionados. (Nota: Se aconseja primero, diseñar el diagrama en papel)

b. Proponer un conjunto de atributos en cada entidad y relación, que esté

acorde a lo pedido. Mostrar en forma tabular cada entidad y relación, con sus atributos, indicando en cada caso, qué atributos son claves.

c. Haciendo uso del EasyCASE, implementar el diseño anterior. (Nota: Mirar el

Anexo A del plan docente, Pasos para crear un Modelo Entidad Relación, para los pasos iniciales del trabajo con el software)

6. Una asignatura sólo puede ser impartida en una aula determinada.

8. Un alumno puede o no estar becado. Hay tres tipos de becas:

Departamento de Computación UNAN - León

Page 247: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 247 de 316

Solución de la práctica 1 Apartado a.): De acuerdo a los enunciados propuestos, un posible diagrama entidad – relación, sería el mostrado en la Figura 8.2.2

b)

Los

nt

Figura 8.2.2 Diagrama E-.R para el Registro Académico. Apartado

atributos de cada entidad y relación pueden verse en las siguientes tablas: E idades:

Estudiante Nombre_atributo Tipo Llave carnet char (30) si nombres char (30) no apellidos char (30) no dirección char (30) no f_nac datetime no

Departamento de Computación UNAN - León

Page 248: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 248 de 316

Asignatura

Nombre_atributo Tipo Llave codigo_asig char (30) si nombre char (30) no

Profesor Nombre_atributo Tipo Llave

inss char (30) si nombres char (30) no apellidos char (30) no antiguedad int no

Aula Nombre_atributo Tipo Llave

codigo_aula char (30) si nombre char (30) no ubicacion char (30) no

Beca Nombre_atributo Tipo Llave

tipo_beca char si monto real no Relaciones:

Recibe Nombre_atributo Tipo Llave

carnet char (30) no codigo_asig char (30) no anyo int no sem char (4) no

Imparte Nombre_atributo Tipo Llave

inss char (30) no codigo_asig char (30) no

Departamento de Computación UNAN - León

Page 249: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 249 de 316

Posee

Nombre_atributo Tipo Llave carnet char (30) si tipo_beca char si cant_sem Int no

Tiene_asignada Nombre_atributo Tipo Llave

codigo_asig char (30) no codigo_aula char (30) no horario Date no

Apartado c)

entidad – relac mentado en EasyCASE es el mostrado en la

El diagrama ión imple

Departamento de Computación UNAN - León

Page 250: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 250 de 316

Figura 8.2.3 Diagrama E-R para el Registro Académico en EasyCASE.

Departamento de Computación UNAN - León

Page 251: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 251 de 316

8.2.2 Práctica 2

USO DE TÉCNICAS DE RECOPILACIÓN DE DATOS CUESTIONARIO PARA MATRÍCULA EN LÍNEA DE LA UNAN LEÓN-

OBJETIVO En esta práctica se pretende que el estudiante haga uso de los conocimientos teóricos adquiridos en clase acerca de las técnicas de recopilación de datos, para la elaboración de un cuestionario sobre la matrícula en línea en la UNAN – León. Con este cuestionario se pretende conocer el grado de viabilidad del sistema, y el nivel de aceptación de los estudiantes ante el nuevo sistema. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 2 sesiones de laboratorio (4 horas) SOFTWARE A UTILIZAR Microsoft Word 2000 o cualquier editor de texto preferido por el alumno. INTRODUCCIÓN TEÓRICA Los cuestionarios son una técnica de recopilación de información que permite que los analistas de sistemas estudien actitudes, creencias, comportamientos y características de varias personas principales en la organización que pueden ser afectadas por los sistemas actual y propuesto. Las actitudes son lo que la gente de la organización dice que quiere (un nuevo sistema, por ejemplo), las creencias son lo que la gente piensa que es, de hecho cierto, el comportamiento es lo que hacen los miembros de la organización y las características son propiedades de las personas o cosas. Las respuestas obtenidas mediante cuestionarios usando preguntas cerradas pueden ser cuantificadas. Las respuestas a cuestionarios que usan preguntas abiertas son analizadas e interpretadas de otras formas. Las preguntas sobre actitudes y creencias son notablemente sensibles a la redacción escogida por el analista de sistemas. Preguntas abiertas: Son aquellas que dejan abiertas todas las posibles opciones de respuesta al interlocutor. Por ejemplo, las preguntas abiertas en un cuestionario pueden decir, “Describa cualquier problema que esté teniendo actualmente con los reportes de

Departamento de Computación UNAN - León

Page 252: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 252 de 316

salida”, o “En su opinión, ¿qué tan útiles son los manuales de usuario del paquete sistema actual?”.

Cuando se es e el tipo de respuesta qu demasiado mplias para una interpretación o comparación precisa. Por lo tanto, cuando escriba na pregunta abierta, debe ser lo suficientemente estrechada para guiar al

que responda en una forma específica.

._______________________________________________________

._______________________________________________________

__________________________

11.De los problemas listados anteriormente, ¿cuál es el que le da mayor problema? __________________________________________________________ __________________________________________________________

de contabilidad del

criban preguntas abiertas en un cuestionario, anticipe va a obtener. Es importante que las respuestas sean

auinterlocutor a Ejemplo: 10.¿Cuáles son los problemas más frecuentes que tiene con la salida de computadora ? A

B

._____________________________C Las preguntas

abiertas puedenpedir listas a losinterlocutores.

Departamento de Computación UNAN - León

Page 253: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 253 de 316

12.¿Por qué? ____________________________________________________________

___________________________________________________________

___________________________________________________

sponibles al terlocutor. Las preguntas cerradas

istemas sea capaz de listar efectivamente todas las respuestas posibles a la regunta y cuando todas las respuestas listadas sean mutuamente excluyentes, ara que la selección de una impida la selección de cualquiera de las demás.

jemplo

esponda las preguntas 23-24 marcando el cuadro adecuado

3. A continuación están seis paquetes de software disponibles actualmente en el usted usa

personalmente en forma más frecuente.

[ ] Freelance [ ] WordPerfect [ ] Paradox [√ ] Excelerator

24. ”Las cifras de vetnas están por lo general atrasadas”.

[ ] De acuerdo [√ ] En desacuerdo

____________________________________________________________ ____________________________________________________________ _ _________

O respuestas detalladas.

Preguntas cerradas Son aquellas que limitan o cierran las opciones de respuesta diin deben ser usadas cuando el analista de spp E R 2

centro de información. Por favor, marque el paquete que

[ ] Excel [ ] Word para Windows

Departamento de Computación UNAN - León

Page 254: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 254 de 316

Responda a la pregunta 25 marcando con un círculo el número adecuado.

atos de cómputo, están atrasadas”.

Nunca Rara vez A veces Frecuentemente Siempre

1 2 3 4 5

a.

5. La división en que estoy actualmente es llamada:

Inversiones

Operaciones

Ventas

Licenciatura

Maestría o más

DESA

El departamento TIC (Tecnologías de la Información y Comunicaciones) de la UNAN – León, está pensando en elaborar para el siguiente curso lectivo, un sistema de matrícula en línea, con el propósito de agilizar los procesos de pre-matrícula y matrícula en toda la Universidad. El departamento TIC necesita conocer la factibilidad operacional del nuevo sistema y el grado de aceptación de los usuarios finales. Para eso, ha pedido a un analista de sistemas, que elabore un cuestionario, n base a la información acerca del antiguo y nuevo sistema que el departamento IC le ha proporcionado. La información del nuevo sistema puede ser resumida

o:

El nuevo sistema constará de formularios de entrada, en las cuales se pedirá información como:

25. ”Cuando las cifras de venta están preparadas por servicios de d

Responda a las preguntas 45-46 poniendo un círculo a la respuesta adecuad 4

46. Mi nivel de estudios puede ser mejor descrito como

Preparatoria

Pasante de universidad

RROLLO DE LA PRÁCTICA

eTcom

Departamento de Computación UNAN - León

Page 255: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 255 de 316

Datos generales:

édula de Identificación Ciudad

egión Sexo

ombre del padre

atos académicos:

arrera Facultad

ño Becado

signaturas que inscribe Asignaturas pendientes

d

atos económicos:

arjeta de crédito Cuenta en un banco

gr Ingreso propio

asa propia Casa de alquiler

atos familiares

on hijos Sin hijos

:

usuarios finales, y demuestre el grado de aceptación que ndrán esos usuarios al interactuar con el nuevo sistema.

Nombres Apellidos

C

R

N Nombre de la madre

D C

A

A

Tipo e matrícula Traslado

D

T

In eso familiar

C D C Casado Soltero Hay que hacer mención que, la mayoría de la información del nuevo sistema, ya estaba presente en el antiguo. Se pide En base a esta información proporcionada, realizar un cuestionario que recoja las impresiones de loste

Departamento de Computación UNAN - León

Page 256: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 256 de 316

El diseño del cuestionario puede ser en base a preguntas abiertas, cerradas o una ombinación de ambas. Recuerde los requisitos para elegir el Lenguaje del

Cuestionario.

c

Departamento de Computación UNAN - León

Page 257: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 257 de 316

Solución de la práctica 2 En base a la información proporcionada por el departamento TIC, se propone el iguiente cuestionario:

UESTIONARIO DE OPINIÓN SOBRE EL NUEVO SISTEMA DE MATRÍCULA EN ÍNEA DE LA UNAN – LEÓN --------------------------------------------------------------------------------------------------------------

l siguiente cuestionario, pretende recoger sus impresiones acerca del nuevo sistema de matrícula n línea de nuestra Universidad. Por favor, colabore con nuestra Universidad aceptando llenar estas

hojas cuando el encuestador se lo pida. Todas sus opiniones serán consideradas al momento de la alización del nuevo sistema. Si tiene alguna duda en alguna pregunta, pregunte con toda confianza

l enceustador.

echa:____ / ____ / _____ Facultad: _________________ Carrera:_______________ día mes año

En esta sección, por favor ponga un círculo al número que mejor sugiera su opinión acerca de cada tema. Recuerde poner solamente UN número en cada pregunta. 1.Mi nivel de conocimiento en computación puede ser descrito como:

Escaso Básico Intermedio Avanzado 1 2 3 4 2.Utilizo la computadora: Casi nunca En ocasiones Muy a menudo Siempre 1 2 3 4 3.Tengo acceso a un computador: Por un amigo Por un familiar Alquilada Propia 1 2 3 4 4.Mis familiares más cercanos saben de computación: Nada Poco Bastante Mucho 1 2 3 4 5.Mis posibilidades de alquilar un ordenador son: Nulas Pocas Muchas Seguras 1 2 3 4

s CL--

Ee

rea

F

Departamento de Computación UNAN - León

Page 258: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 258 de 316

6.Hago uso del Internet: Nunca Algunas veces Muy a menudo Siempre 1 2 3 4

Responda las preguntas 7 – 10, Marcando con una x en la casilla apropiada.

7.¿Ha usado alguna vez Internet? [ ] Si [ ] No

8.¿Conoce algún sitio web? [ ] Si

] Si ] No

0. ¿Ha hecho compras por Internet?

] No

1. ¿Ha ormula ios por

2. ¿Ha la imp sora a ?

] Si

a x el uadro a . Si re pondió a pregunta 7, continuar respondiendo a partir de la pregunta 5.

s de más uso en Internet. Por favor marque el más frecuente.

] Netscape Navigator [ ] Galeon

[ ] Konqueror [ ] Otro

A continuación, se encuentran preguntas acerca de su formación informática. Por favor lea las instrucciones de cada sección antes de contestar.

[ ] No 9.¿Conoce algún programa que le permita visualizar páginas web ? [ [ 1 ] Si [[

llenado f r Internet?1 [ ] Si ] No [ 1 utilizado re lguna vez [ [ ] No

i respondió “si”, a la pregunta 7, por favor responda a las preguntas 13 – 14 marcando con unSc adecu do s “no” la1 13. A continuación, se presentan 5 navegadore

avegador que usted usa personalmente en forman ] Internet Explorer [ ] Mozilla [ [

Departamento de Computación UNAN - León

Page 259: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 259 de 316

14.Uso el Internet para: [ ] Buscar información de mis estudios. [ ] Leer noticias. [ ] Charlar. [ ] Mirar y enviar correo.

] Descargar software [ ] Comprar libros y artículos.

[ ] Otra actividad.

Responda la pregunta 15, poniendo un círculo en la respuesta adecuada.

15.La idea de implementar el sistema de matrícula en línea, me parece:

Excelente

Buena

Regular

Mala

la(s) que usted crea correcta.

nas razones por las que estaría de acuerdo con el nuevo sistema en línea es: ] Se agilizaría el proceso

s culturización informática ] Privacidad con mis datos académicos

parte

nas de las razones por las que no estaría de acuerdo con el nuevo sistema en línea es:

] No sabría cómo usar el sistema

[ ] Tendría dificultades para manejar la computadora

e haría difícil alquilar / prestar un ordenador con Internet

] La inseguridad del Internet

] Fácil de usar [ ] Con instrucciones de uso

] Liviano en tamaño [ ] Igual que el sistema antiguo

] Vistoso y agradable [ ] Con reportes útiles

[ [ ] Registrarme en listas de discusión.

Responda las preguntas 16 – 19, marcando con una x en la(s) casil 16. Algu

[ [ ] Se ahorraría dinero y tiempo [ ] Má

[ [ ] Me podría matricular desde cualquier

17. Algu [

[ ] Se m [ [ ] La falta de tarjeta de crédito 18. Me gustaría que el sistema de matrícula en línea fuese: [ [ [

Departamento de Computación UNAN - León

Page 260: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 260 de 316

19. Qué temor(es) tendría usted al usar el nuevo sistema:

] Alte s académicos

er res en l man o ] Vio ito del sistema

s suge encias jo.

0. ¿Qué sugerencias tendría para el departamento que desarrollará el sistema?

._________________________________________________________________________

_______________________________________________________________

._________________________________________________________________________

____________________________________________________________________

El Analista de Sistemas

[ ] Pérdida de mi dinero [ ración de mis dato [ ] Cometer ro e ej [ lación de mi tarjeta de créd Conteste la siguiente pregunta listando la r en las líneas de aba 2 1 2.__________

3 4._____

Muchas gracias por su atención

Departamento de Computación UNAN - León

Page 261: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 261 de 316

8.2.3 Práctica 3

ESPECIFICACIÓ D QUISITOS SOFTWARE - ERS N E REDISEÑO DE UN ERS PARA UN SISTEMA DE INVENTARIO

OBJETIVO

al.

IEMPO DE REALIZACIÓN DE LA PRÁCTICA

OFTWARE A UTILIZAR

Microsoft Word 2000 o cualquier editor de texto preferido por el alumno. INTRODUCCIÓN TEÓRICA El avance de la tecnología hoy mayor parte de las personas que poseen un pequeño negocio y que lo desean automatizar. Los pequeños negocios generan cada vez, más y más información, que en poco tiempo de existir les resulta difícil manejar. Muchos de los propietarios de esos pequeños negocios, han llegado a comprender la necesidad de tener sistemas automatizados, que les permita controlar sus productos con rapidez, llevar un control de las ventas y compras realizadas, estar al día con los deudores del negocio, etc. La información recopilada por mecanismos automatizados se utiliza en mayor medida en todas las actividades del hombre, y van desde el manejo de un pequeño negocio hasta controles industriales avanzados. En esta práctica nos proponemos realizar un ERS para un sistema de inventario de una pequeña tienda de ropa y mercancías. La especificación de requisitos software es el establecimiento conciso de un conjunto de requisitos que deben ser satisfechos por un producto o un proceso, indicando, siempre que sea adecuado, el procedimiento mediante el cual se puede determinar si se han logrado satisfacer los requisitos Los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir la descripción de las

En esta práctica se pretende que el alumno haga uso de los conocimientos teóricos dquiridos en clase, para construir un ERS basado en un problema de la vida rea

T 4 sesiones de laboratorio (8 horas) S

en día, incide sobre la

Departamento de Computación UNAN - León

Page 262: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 262 de 316

características del nuevo sistema. Esta actividad tiene tres partes relacionadas

1. Análisi

2. Identificación de requerimientos esenciales

ción de estrategias para satisfacer los requerimientos

n ERS debe cumplir las propiedades siguientes:

significado.

pleto:

Define las respuestas del software para todos los datos de n todas las clases de situación posible.

Que sea verificable. Debe existir un procedimiento finito de coste

• Consistencia. Ninguno de los requisitos individuales descritos del

• Modificable. Debe estar organizado de forma fácil y coherente y no

r la documentación futura.

• Utilizable en la fase de operación y mantenimiento. Por ejemplo, si el personal encargado del mantenimiento es diferente al personal que estuvo a cargo del análisis, diseño y codificación, entonces el primero

entre si:

s de datos basados en hechos reales

3. Selec

Propiedades de una especificación de requisitos software. U

• No ambiguo, es decir que cada requisito tenga una única interpretación y un único

• Que sea com

Incluye todos los requisitos significativos.

entrada e En caso de no aplicarse alguna sección se debe indicar el por

qué no se aplica. Define todos los términos, unidades de medida y hace

referencia a todas las figuras, tablas y diagramas. Si algún apartado del ERS contiene la frase: “se determinará”m

entonces el ERS no está completo.

• razonable en el que una persona pueda probar que el producto software cumpla el requisito.

ERS debe presentar conflictos.

presentar información redundante.

• Rastreable. Cada uno de los requisitos debe dejar claro su origen para que sea fácil el desarrollo y mejora

Departamento de Computación UNAN - León

Page 263: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 263 de 316

necesitará utilizar la documentación generada en la Especificación de Requisitos para poder hacer los cambios pertinetes al sistema.

DE

La ado, cosméticos, ccesorios, ropa, lencería, porcelana, adornos para el hogar etc.

La Boutique está conformada por la dueña que es la administradora, y dos ependientas que se encargan de atender a los clientes.

a boutique está organizada de tal manera que todos los productos le sean visibles al cliente lospared, etc.

a Boutique tiene 1 almacén, el cual se encuentra en un lugar retirado de la tienda. Cuando se necesita algún producto y éste no se encuentra en la tienda, se trae del almacén. Cada nueva de compra productos por parte de la tienda, se lleva al almacén, y luego des y estmaciones de venta que tenga la dueña de la tienda. La administradora de la tienda nos ha pedido un conjunto de especificación de requisitos software, para la automatización del inventario de dicha tienda. El sistema contemplará los productos a proveedores, venta de productos a cliente, devoluciones, etc. La tienda tiene urequiere. La administradory a qué proveedo ctos. De igual manera, le

teresaría poder conocer a sus clientes más asiduos para saber si podrá hacerles algún de uen El control de se lleva a cabo de forma manual: les socian un número interno y una descripción y algunas características adicionales.

El control de lleva a cabo manualmente. Cada proveedor tiene asignado un nombrcontacto ire

e pide:

Definir e conturo sistema

SARROLLO DE LA PRÁCTICA

boutique EXCELENCIA ofrece variedad de productos como calz

a

d L

; productos se muestran en vitrinas, en maniquíes, colgados en la

L

pasa a la tienda en función de las necesida

diferentes movimientos posibles dentro de la tienda: compras de

nos proveedores que le suministran productos cuando la tienda lo

a quisiera poder llevar un control de quiénes son sus proveedores, r es quien más le compra produ

insc to o incluirlos en algún tipo de promoción.

los productos actualmente a

los proveedores también see y algunos datos extras como, teléfonos de

, d cción, etc.

S

l junto de especificación de requisitos software que debe cumplir el de automatización de la Boutique. fu

Departamento de Computación UNAN - León

Page 264: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 264 de 316

Solución de l

l ejemplo se ha desarrollado sobre la realización de una especificación de quisitos software para un producto que se encargará de la gestión del inventario

e la boutique EXCELENCIA.

.1.- Propósito.

software que debe cumplir aplicación de GESTIÓN DE INVENTARIO de la BOUTIQUE EXCELENCIA,

ento se dirige a la dueña – administradora- de la tienda y a los usuarios nales –dependietnas- que deberán estudiarlo para su aprobación o desacuerdo

a está aplicación será: de GESTIÓN DE VENTARIO.

• Modificación de los datos de un Cliente.

• Modificación de los datos de un Proveedor.

• Modificación de los datos de un Producto.

• Captura de la compra de productos a un Proveedor.

a práctica 3

Ered 1.- Introducción. 1 Definición del conjunto de especificaciones de requisitos laconsiste en la mecanización del proceso de inventario. Este documfiantes de abordar la fase de análisis. 1.2.- Alcance. El nombre con el que se conocerá IN El producto realizará las siguientes funciones:

• Captura de los datos de un nuevo Cliente.

• Eliminar a un Cliente.

• Captura de los datos de un Proveedor.

• Eliminar a un Proveedor.

• Captura de los datos de un Producto.

• Eliminar a un Producto.

• Captura de la venta de productos realizada a un Cliente y emisión de

la Factura al Cliente por la mercancía servida.

Departamento de Computación UNAN - León

Page 265: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 265 de 316

• Emisión de los siguientes Listados de información:

todos los productos.

.3.- Definiciones, acrónimos y abreviaturas.

• Proveedor: empresa que suministra los productos con el que se comercia. El resto del ERS lo llamará PROVEEDOR.

• Cliente: persona que realiza la compra de productos a BOUTIQUE

EXCELENCIA. A lo largo del ERS se llamará CLIENTE.

• Factura a Cliente: documento dado al Cliente, en el cual se especifican los productos comprados y el importe correspondiente a cada uno de ellos, así como el total de la compra. A lo largo del ERS

• Producto: Bien material existente en el negocio. En el resto del ERS. se llamará PRODUCTO.

n en el negocio. En el resto del ERS. se llamará EXISTENCIAS.

s entrevistas realizadas a la administradora de la tienda y a la dependienta, desde el 01/06/2004

.5.- Visión general.

rimeramente se realizará una Descripción General del producto que se desea

desarroll pa cada uno de los Requisitos specíficos individualmente.

2.- Desc ció

2.1.- Rel ion a aplicación no interactúa con ninguna aplicación de ningún tipo que pudiera existir

en la tienda.

Listado de Clientes actuales de la Boutique. Listado de Proveedores actuales de la Boutique. Listado de

1

se denominará F_CLIENTE.

• Existencias: Artículos que existe

1.4.- Referencias.

• Informe obtenido como resultado de la

hasta el 07/06/2004.

1

Par ra pasar posteriormente a estudiar

E

rip n General.

ac es del producto.

L

El equipo en el que se desarrollará e implantará el producto final es:

Departamento de Computación UNAN - León

Page 266: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 266 de 316

• HP Pavilion. • Pr• 25• 40

a instalación inicial se hará en el único ordenador de la tienda, con una impresora

2.2.- Funcione

El produ spersonal de B

1.

la base de datos.

ueda de éste, y a continuación el usuario

puede proceder a eliminarlo.

3. el registro de un CLIENTE en la base de datos, se hará una búsqueda de éste, y a continuación el usuario puede proceder a eliminarlo.

4. Cuando aparezca un nuevo PRODUCTO por parte de un proveedor, el usuario debe registrarlo en el ordenador y, a continuación almacenarlo en la base de datos.

5. Cuando se desee eliminar el registro de un PRODUCTO en la base

de datos, se hará una búsqueda de éste, y a continuación el usuario proceder a eliminarlo.

6. Cuando se desee modificar el registro de un PRODUCTO en la base de datos, se hará una búsqueda de éste, y a continuación el usuario puede proceder a eliminarlo.

7. Cuando aparezca un nuevo PROVEEDOR, el usuario debe registrarlo dor y, a continuación almacenarlo en la base de datos.

e eliminar el registro de un PROVEEDOR en la base de datos, se hará una búsqueda de éste, y a continuación el usuario puede proceder a eliminarlo.

ocesador Pentium 4, 1.4 GHz. 6 Mb RAM. Gb de disco duro.

LLáser.

s del producto.

cto oftware debe contener todas las tareas que realiza manualmente el OUTIQUE EXCELENCIA. de forma diaria. Éstas son:

Cuando se reciba la solicitud de una persona para ser un nuevo CLIENTE, el usuario debe registrarlo en el ordenador y, a continuación almacenarlo en

2. Cuando se desee eliminar el registro de un CLIENTE en la base de datos, se hará una búsq

Cuando se desee modificar

puede

en el ordena

8. Cuando se dese

Departamento de Computación UNAN - León

Page 267: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 267 de 316

9. Cuando se desee modificar el registro de un PROVEEDOR en la base hará una búsqueda de éste, y a continuación el usuario

10. Cuando se realice una venta de productos a un CLIENTE, el usuario deberá seleccionar los productos a vender de una lista y digitar la

automáticamente el sub-total por productos y el total de la venta y actualizará las EXISTENCIAS. A continuación el usuario imprimira la F_CLIENTE.

productos a un PROVEEDOR, el usuario deberá seleccionar los productos a comprar de una lista y digitar la cantidad a recibir de cada uno. Si el producto fuese nuevo, el usuario lo registrará de la forma adecuada en la base de datos. El sistema calculará automáticamente el sub-total por productos y el total

12. dos de forma diaria:

ES actuales de la Boutique.

2.3.- Características del usuario. Los usuarios finales de la aplicación serán personas cuya experiencia informática es escasa, motivo por el que se deberá incluir ayuda en línea en el producto final.

2.4.- Restricci

l lenguaje de programación utilizado será Visual Basic. El Gestor de B

l Sistema Operativo será Windows 2000 Server. Se deberán se

2.5.- Suposici

urante las entrevistas iniciales, la administradora de la BOUTIQUE EXCELENCIA, ha indicado la posibilidad de desarrollar en el futuro la aplicación de CONTABILIDAD.

de datos, se puede proceder a eliminarlo.

cantidad a llevar por cada producto. El sistema calculará

11. Cuando se realice una compra de

de la compra y actualizará las EXISTENCIAS.

El usuario podrá disponer de los siguientes lista

• Listado de CLIENTES actuales de la Boutique.

• Listado de PROVEEDOR

• Listado de EXISTENCIAS a la fecha.

ones generales.

E

ase de Datos a utilizar será SQL Server 2000.

E

guir los estándares de la programación estructurada.

ones y dependencias.

D

Departamento de Computación UNAN - León

Page 268: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 268 de 316

3.- Requ o 3.1.- Requisito.1.1.-Captura de los datos de un nuevo Cliente.

3.

3

3.1.1.1.2.- Entradas.

Ninguno

3.1.1.1.3.- Proceso.

Se mostrará la pantalla de introducción de datos al usuario. Los datos necesarios a introducir serán:

• Nombres: es un dato obligatorio.

• Apellidos: es un dato obligatorio.

tificación: dato obligatorio. Puede ser la cédula de

orio.

mencionados se almacenará el registro del datos.

isit s Específicos.

s funcionales. 3

1.1.1.- Especificación.

.1.1.1.1.- Introducción. Este proceso deberá realizar la captura de todos los datos de un CLIENTE y almacenarlo en la base de datos.

Por pantalla: datos de un CLIENTE: • Nombres. • Apellidos. • Identificación. • Fecha de Ingreso.

Dirección.

Datos proporcionados por el sistema:

• Iden

identidad, pasaporte u otro.

• Fecha de Ingreso: dato no obligatorio.

• Dirección: dato obligat

3.1.1.1.4.- Salidas.

Con todos los datos CLIENTE en la base de

3.1.1.2.- Interfaces externas.

Departamento de Computación UNAN - León

Page 269: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 269 de 316

3.1.1.2.1.- Interfaces de usuario. La captura de datos del CLIENTE se realizará de forma

por pantalla.

No hay interfaces hardware.

ware.

3.1.9.2.4.- Interfaces de comunicaciones. No existe ninguna interfaz de comunicaciones en la aplicación.

---------------------------------------------------------------------------------------------------------------- 3.1.2.- Eliminar a un Cliente.

3.1.2.1.- Especifica ón

3.1.2.1

de un CLIENTE de la base de datos.

3.1.2.1.2.- Entradas.

NA

.1.2.1.3 Pro

e mostrará la n CLIENTE

l dato n es será:

rio. Puede ser la cédula de identidad, pasaporte u otro.

ificación, se buscará al CLIENTE en la base de

búsqueda, se mostrarán los datos del CLIENTE ncontrado en la pantalla, y se preguntará si realmente se desea

interactiva3.1.1.2.2.- Interfaces hardware.

3.1.1.2.3.- Interfaces softNo hay interfaces software.

ci .

.1.- Introducción. Este proceso deberá realizar la eliminación de todos los datos

Por pantalla: datos de un CLIENTE:

Identificación. Datos proporcionados por el sistema:

ombre pellidos

3 .- ceso.

pantalla de eliminación de uS E

ec ario a introducir (seleccionar de una lista)

• Identificación: dato obligato

A partir de la identdatos.

3.1.2.1.4.- Salidas.

Ce

on el resultado de la

Departamento de Computación UNAN - León

Page 270: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 270 de 316

elminar a ese CLIENTE de la base de datos. Si la respuesta es si, se elimina

3.1.2.2

3.1.2.2.1.- Interfaces de usuario.

La eliminación de CLIENTE se realizará de forma interactiva por pantalla.

3.1.2.2.2.- Interfaces hardware. No hay interfaces hardware.

3.1.2.2.3.- Interfaces software.

3.1.2.2.4.- Interfaces de comunicaciones. nguna interfaz de comunicaciones en la aplicación.

--------------------------

.1.3.- Modificar datos de un Cliente.

3.1.3.1.- Especificación.

3.1.3.1.1.- Inste proceso deberá realizar la modificación de los datos que

ase de datos.

3.1.3.1.2.- En

Por pantalla: datos de un CLIENTE: ación.

Apellidos FD

Se mostrará la pantalla de modificación de un CLIENTE

El dato necesario a introducir (seleccionar de una lista) será:

rá el registro del CLIENTE en la base de datos.

.- Interfaces externas.

No hay interfaces software.

No existe ni

--------------------------------------------------------------------------------------

3

troducción. Eelija el usuario, de un CLIENTE de la b

tradas.

Identific

Datos proporcionados por el sistema:

Nombre

echa de Ingreso irección

3.1.3.1.3.- Proceso.

Departamento de Computación UNAN - León

Page 271: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 271 de 316

• Identificación: dato obligatorio. Puede ser la cédula de identidad, pasaporte u otro.

ación, se buscará al CLIENTE en la base de

atos.

3.1.3.1

Con el resultado de la búsqueda, se mostrarán los datos del CLIENTE ntinuación, el usuario podrá modificar

los campos del CLIENTE que estime conveniente. Después de haber hecho los cambios, el usuario almacenará al CLIENTE en la base de datos.

3.1.3.2.- Inter

3.1.3.2.1.- Interfaces de usuario.

NTE se realizará de forma

3.1.3.2.2.- Interfaces hardware.

3.1.3.2.3.- Interfaces software. No hay interfaces software.

3.1.3.2plicación.

---------------------------------------------------------------------------------------------------------------- 3.1.4.- Captura de los datos de un proveedor.

3.1.4.1.- Especificación.

3.1.4.1.1.- Introducción. Este proceso deberá realizar la captura de los datos deun PROVEEDOR y almacenarlo en la base de datos.

Nombre

Dirección Contacto

A partir de la identificd

.4.- Salidas.

encontrado en la pantalla. A co

faces externas.

La modificación de datos del CLIEinteractiva por pantalla.

No hay interfaces hardware.

.4.- Interfaces de comunicaciones. No existe ninguna interfaz de comunicaciones en la a

3.1.4.1.2.- Entradas.

Por pantalla: datos de un PROVEEDOR:

Identificación

Departamento de Computación UNAN - León

Page 272: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 272 de 316

Datos proporcionados por el sistema:

Ninguno

Se mostrará la pantalla de introducción de datos al usuario.

Los datos necesarios a introducir serán:

RUC.

n: dato obligatorio.

gatorio.

3.1.4.1.4.- Salidas.

Con todos los datos mencionados, se almacenará el PROVEEDOR en la base de datos del sistema.

3.1.4.2 3.1.4.2.1.- Interfaces de usuario.

La captura de datos del PROVEEDOR se realizará de forma

3.1.4.2.2.- Interfaces hardware.

No hay interfaces hardware.

3.1.4.2.3.- Interfaces software.

3.1.4.2.4.- Interfaces de comunicaciones.

interfaz de comunicaciones en la aplicación.

-------------------------------------------------------------------------------------------------------------- .1.5.- Eliminar a un PROVEEDOR

3.1.5.1.- Especificac

3.1.5.1.1.- Introducción.

3.1.4.1.3.- Proceso.

• Nombre: dato obligatorio. • Identificación: dato obligatorio. Puede ser el número

• Direcció

• Contacto: dato obli

.- Interfaces externas.

interactiva por pantalla.

No hay interfaces software.

No existe ninguna

--

3

ión.

Departamento de Computación UNAN - León

Page 273: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 273 de 316

Este proceso deberá realizar la eliminación de todos los datos de un PROVEEDOR de la base de datos.

Identificación.

Datos proporcionados por el sistema:

Nombre DContacto

3.1.5.1.3 Pro

Se mostrará la pantalla de eliminación de un PROVEEDOR

El dato necesario a introducir (seleccionar de una lista) será:

• Identificación: dato obligatorio. Puede ser el RUC.

buscará al PROVEEDOR en la base de datos.

.1.5.1.4.- Salidas.

Con ePROVEEDOR encontrado en la pantalla, y se preguntará si realmente se desea elminar a ese PROVEEDOR de la base de datos. Si la

registro del PROVEEDOR en la base de dat

3.1.5.2.- Interfaces externas.

3.1.5.2.1.- Interfaces de usuario. La eliminación de PROVEEDOR se realizará de forma interactiva por pantalla.

3.1.5.2No hay interfaces hardware.

3.1.5.2.3.- Interfaces software. software.

es de comunicaciones. No existe ninguna interfaz de comunicaciones en la aplicación.

---------------------------------------------------------------------------------------------------------------

3.1.5.1.2.- Entradas.

Por pantalla: datos de un PROVEEDOR:

irección

.- ceso.

A partir de la identificación, se

3

l resultado de la búsqueda, se mostrarán los datos del

respuesta es si, se eliminará el os.

.2.- Interfaces hardware.

No hay interfaces

3.1.5.2.4.- Interfac

Departamento de Computación UNAN - León

Page 274: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 274 de 316

3.1.6.- Modificar da

3.1.6.1.- Especificación.

3.1.6.1.1.- Introducción. Este proceso deberá realizar la modificación de los datos que elija el usuario, de un PROVEEDOR de la base de datos.

3.1.6.1

Por pantalla: datos de un PROVEEDOR: n.

Datos proporcionados por el sistema:

Nombre

Contacto

3.1.6.1.3.- Proceso.

e mostrará la pantalla de modificación de un PROVEEDOR.

necesario a introducir (seleccionar de una lista) será:

ficación: dato obligatorio.

Con el resultado de la búsqueda, se mostrarán los datos del

ado en la pantalla. A continuación, el usuario podrá modificar los campos del PROVEEDOR que estime conveniente.

cambios, el usuario almacenará al PROV

3.1.6.2.- Interfaces externas.

3.1.6.2

La modificación de datos del PROVEEDOR se realizará de forma interactiva por pantalla.

3.1.6.2No hay interfaces hardware.

No hay interfaces software.

tos de un Proveedor.

.2.- Entradas.

Identificació

Dirección

S El dato

• Identi

A partir de la identificación, se buscará al PROVEEDOR en la base de datos.

3.1.6.1.4.- Salidas.

PROVEEDOR encontr

Después de haber hecho los EEDOR en la base de datos.

.1.- Interfaces de usuario.

.2.- Interfaces hardware.

3.1.6.2.3.- Interfaces software.

Departamento de Computación UNAN - León

Page 275: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 275 de 316

3.1.6.2.4.- Interfaces de comunicaciones. No existe ninguna interfaz de comunicaciones en la aplicación.

----------------------------------------------------------------------------------------------------------------

3.1.7.-Captura de los datos de un nuevo Producto.

3.1.7.1.- Esp

3.1.7.1.1.- Introducción. de todos los datos de un

PRODUCTO y almacenarlo en la base de datos.

3.1.7.1.2.- En

Por pantalla: datos de un PRODUCTO: igo.

• Descripción.

N

Se mostrará la pantalla de introducción de datos al usuario.

Los datos necesarios a introducir serán:

3.1.7.1

almacenará el registro del

.

3.1.7.2.- Interfaces externas.

ecificación.

Este proceso deberá realizar la captura

tradas.

• Cód

• Tipo.

Datos proporcionados por el sistema:

inguno

3.1.7.1.3.- Proceso.

• Código: es un dato obligatorio.

• Descripción: es un dato obligatorio.

Tipo: dato obligatorio.

.4.- Salidas.

Con todos los datos mencionados sePRODUCTO en la base de datos

3.1.7.2.1.- Interfaces de usuario.

Departamento de Computación UNAN - León

Page 276: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 276 de 316

La captura de datos del PRODUCTO se realizará de forma interactiva por pantalla.

3.1.7.2No hay interfaces hardware.

No hay interfaces software.

es de comunicaciones. No existe ninguna interfaz de comunicaciones en la aplicación.

----------------------------------------------------------------------------------------------------------------

3.1.8.- Elimin

3.1.8.1.- Esp

3.1.8.1.1.- I oduEste proceso deberá realizar la eliminación de todos los datos de un PRODUCTO de la base de datos.

3.1.8.1.2.- Entradas.

Por pantalla: datos de un PRODUCTO:

Tipo

.1.8.1.3.- Proceso.

e mostrará la UCTO.

l dato n es ionar de una lista) será:

• Código: dato obligatorio.

buscará a ese PRODUCTO en la base

la búsqueda, se mostrarán los datos del ntalla, y se preguntará si realmente

de la base de datos. Si la

.2.- Interfaces hardware.

3.1.7.2.3.- Interfaces software.

3.1.7.2.4.- Interfac

ar un Producto

ecificación.

ntr cción.

Código.

Datos proporcionados por el sistema:

Descripción

3

S

pantalla de eliminación de un PROD

E ec ario a introducir (selecc

A partir de la identificación, se de datos.

3.1.8.1.4.- Salidas.

Con el resultado dePRODUCTO encontrado en la pase desea elminar a ese PRODUCTO

Departamento de Computación UNAN - León

Page 277: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 277 de 316

respuedatos.

3.1.8.2

3.1.8.2.1.- Interfaces de usuario.

UCTO se realizará de forma interactiva

3.1.8.2.2.- Interfaces hardware.

3.1.8.2.3.- Interfaces software.

es de comunicaciones. No existe ninguna interfaz de comunicaciones en la aplicación.

---------------------------------------------------------------------------------------------------------------- 3.1.9.- Modificar da

3.1.9.1

3.1.9.1Este proceso deberá realizar la modificación de los datos que lija el usuario, de un PRODCUTO de la base de datos.

3.1.9.1.2.- Entradas.

Por pantalla: datos de un PRODCUTO:

Código.

Datos proporcionados por el sistema:

Descripción

3.1.9.1.3 Pro

El dato necesario a introducir (seleccionar de una lista) será:

• Código: dato obligatorio.

sta es si, se eliminará el registro del PRODUCTO en la base de

.- Interfaces externas.

La eliminación del PRODpor pantalla.

No hay interfaces hardware.

No hay interfaces software.

3.1.8.2.4.- Interfac

tos de un Proucto.

.- Especificación.

.1.- Introducción.

e

Tipo

.- ceso.

Se mostrará la pantalla de modificación de un PRODCUTO.

A partir de la identificación, se buscará al PRODCUTO en la base de datos.

Departamento de Computación UNAN - León

Page 278: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 278 de 316

4.- Salidas.

la búsqueda, se mostrarán los datos del RODCUTO encontrado en la pantalla. A continuación, el usuario

RODCUTO que estime conveniente. DespuPRODCUTO en la base de datos.

3.1.9.2

3.1.9.2.1.- Interfaces de usuario.

La modificación de datos del PRODCUTO se realizará de forma

3.1.9.2.2.- Interfaces hardware.

3.1.9.2.3.- Interfaces software.

3.1.9.2.4.- Interfaces de comunicaciones. nguna interfaz de comunicaciones en la aplicación.

-------------------------- .1.10.- Captura de la venta de productos realizada a un Cliente y emisión de la

Factura al Cliente por la mercancía servida.

3.1.10.1.- Es

3.1.10.1.1.- Introducción. ra de todos los datos de

una venta de productos realizada a un CLIENTE y, realizar automáticamente la actualización de las EXISTENCIAS.

3.1.10.1.2.- Entradas.

Por pantalla: datos para capturar la venta:

• Código del PRODUCTO.

• Fecha de la venta.

3.1.9.1.

Con el resultado de Ppodrá modificar los campos del P

és de haber hecho los cambios, el usuario almacenará al

.- Interfaces externas.

interactiva por pantalla.

No hay interfaces hardware.

No hay interfaces software.

No existe ni

--------------------------------------------------------------------------------------

3

pecificación.

Este proceso deberá realizar la captu

• Identificación del CLIENTE.

• Cantidad por cada PRODUCTO.

Datos proporcionados por el sistema:

Departamento de Computación UNAN - León

Page 279: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 279 de 316

Referente al CLIENTE: Nombre del cliente.

• Dirección del cliente.

usuariautom

rán:

• Código del producto: es un dato obligatorio.

producto: dato obligatorio. Si la a las EXISTENCIAS para ese

producto, se le dará paso a la entrada de los demás

n la base de datos, se le preguntará verbalmente si quiere registrarse como cliente de la tienda. Si el cliente accede, se procederá a llamar al formulario para Capturar los datos de un nuevo cliente.

A parttodal ductos

ario, actualizará de forma automática las da producto.

3.1.10.1.4.- lid

Con todos os ará a imprimir la F_CLIENTE a la impresora Láser.

3.1.10.2.- Interfaces externas.

Referente a los PRODUCTOS: • Descripción. • Tipo.

3.1.10.1.3.- Proceso.

Se mostrará la pantalla de introducción de datos para la nueva venta al o. El número con que se registrará la nueva venta será asignado áticamente.

Los datos necesarios a introducir se

• Cantidad por cada

cantidad no excede

datos.

• Fecha de la venta: dato obligatorio.

Los datos no necesarios a introducir serán:

• Identificación del cliente: no es un dato obligatorio. Si el cliente no existe e

ir de estos datos se calculará el sub-total por cada producto y el de la compra automáticamente. La cantidad de pro

digitada por el usuEXISTENCIAS para ca

Sa as.

l datos mencionados, se mand

Departamento de Computación UNAN - León

Page 280: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 280 de 316

3.1.10.2.1.- ILa captura da lizará de forma interactiva por pantalla.

3.1.10.2.2.- Interfa s h No hay interfaces hardware.

software.

.1.10.2.4.- Interfaces de comunicaciones.

nicaciones en la aplicación. ---------------------------------------------------------------------------------------------------------------- 3.1.11.- Captura de la com

3.1.11.1.- Especifica

Este proceso deberá realizar la captura de todos los datos de una compra de productos realizada a un PROVEEDOR y,

ión de las EXISTENCIAS.

3.1.11.1.2.- Entradas.

Por pantalla: datos para capturar la compra: • Identificación del PROVEEDOR. • Código del PRODUCTO. • Cantidad por cada PRODUCTO. • Fecha de la compra.

Referente al PROVEEDOR:

• Nombre. • Dirección. • Contacto.

Referente a los PRODUCTOS:

• Descripción. • Tipo.

nterfaces de usuario. de tos de la venta se rea

ce ardware.

3.1.10.2.3.- Interfaces

No hay interfaces software.

3No existe ninguna interfaz de comu

pra de productos a un Proveedor.

ción.

3.1.10.1.1.- Introducción.

realizar automáticamente la actualizac

Datos proporcionados por el sistema:

Departamento de Computación UNAN - León

Page 281: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 281 de 316

3.1.11.1.3.- Proceso.

Se mostrará la pantalla de introducción de datos para la nueva compra al usuario. El número con que se registrará la nueva compra será asignado automáticamente.

os datos necesarios a introducir serán:

• Código del producto: es un dato obligatorio.

• Identificación del PROVEEDOR: es un dato obligatorio.

• Cantidad por cada producto: dato obligatorio.

• Fecha de la compra: dato obligatorio. A partir de estos datos se calculará el sub-total por cada producto y el

digitada por el usuario, actualizará de forma automática las

3.1.11.1.4.- Salidas.

Con tode los

3.1.11.2.- Interfaces externas. 3.1.10

La c tur realizará de forma intera iva

3.1.11.2.2.- Interfaces hardware. No hay

3.1.11.2.3.- I No hay interfaces ftw

3.1.11.2.4.- INo existe ninguna interfaz de comunicaciones en la aplicación.

------------------------------------------------ -------------------------------------------------------

L

todal de la compra automáticamente. La cantidad de productos

EXISTENCIAS para cada producto.

dos los datos mencionados, se mandará a guardar los registros nuevos productos en la base de datos.

.2.1.- Interfaces de usuario. ap a de datos de la compra se ct por pantalla.

interfaces hardware.

nterfaces software.

so are.

nterfaces de comunicaciones.

-- -------

Departamento de Computación UNAN - León

Page 282: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 282 de 316

3.1.12.- Lista les de la Boutique.

3.1.12

Este proceso deberá listar a todos los Clientes actuales de la

3.1.12.1 En

P pan

Ninguno

D s p

Ninguno

nar los distintos tipos de reportes

porte Listar Clientes.

nterior, se generará como salida un

reporte

• Nombres. • Apellidos.

• Fecha de Ingreso.

3.1.12.2.- Interfaces externas.

.1.12.2.1.- Interfaces de usuario. El listado de CLIENTES se realizará de forma interactiva por la

3.1.12.2.2.- Interfaces hardware.

do de Clientes actua

.1.- Especificación.

3.1.12.1.1.- Introducción.

BOUTIQUE.

.2.- tradas.

or talla: datos para generar el listado:

ato roporcionados por el sistema:

3.1.12.1.3.- Proceso.

Se mostrará el menú para seleccioque genera el sistema.

Se seleccionará el Re

No habrá necesidad de introducir ningún dato.

3.1.12.1.4.- Salidas.

Una vez hecho el procedimiento a con todos los clientes actuales de la BOUTIQUE, con los datos:

• Identificación.

• Dirección.

3

pantalla.

No hay interfaces hardware.

Departamento de Computación UNAN - León

Page 283: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 283 de 316

3.1.12.2.3.- Interfaces software. No hay interfaces software.

omunicaciones.

----------------------------------------------------------------------------------------------------------------

3.1.13.- Listado de

3.1.13.1.- Especificación.

3.1.13Este proceso deberá listar a todos los PROVEEDORES actuales de la BOUTIQUE.

Datos proporcionados por el sistema:

3.1.13.1.3.- Proceso.

Se mostrará el menú para seleccionar los distintos tipos de reportes

e seleccionará el Reporte Listar Proveedores. No habrá necesidad de introducir ningún dato.

3.1.13.1.4.- lid

ior, se generará como salida un

oveedores actuales de la BOUTIQUE, con los

3.1.12.2.4.- Interfaces de cNo existe ninguna interfaz de comunicaciones en la aplicación.

Proveedores actuales de la Boutique.

.1.1.- Introducción.

3.1.13.1.2.- Entradas.

Por pantalla: datos para generar el listado:

Ninguno

Ninguno

que genera el sistema. S

Sa as.

Una vez hecho el procedimiento anterreporte con todos los pr

atos: d

Nombre Identificación Dirección Contacto

Departamento de Computación UNAN - León

Page 284: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 284 de 316

3.1.13

.1.13.2.1.- Interfaces de usuario. El listado de PROVEEDORES se realizará de forma interactiva

3.1.13.2.2.- Interfaces hardware.

No hay interfaces hardware.

3.1.13.2.3.- Interfaces software.

3.1.13.2.4.- Interfaces de comunicaciones. terfaz de comunicaciones en la aplicación.

----------------------------------------------------------------------------------------------------------------

.1.14.- Listado de todos los productos.

3.1.14.1.- Especifica

3.1.14.1.1.- Introducción. s PRODUCTOS actuales

de la BOUTIQUE.

3.1.14.1.2.- Entradas.

Por pantalla: datos para generar el listado:

Ninguno

3.1.14.1.3.- Proceso.

Se mostrará el menú para seleccionar los distintos tipos de reportes que genera el sistema. Se seleccionará el Reporte Listar Productos.

No habrá necesidad de introducir ningún dato.

3.1.14.1.4.- S

.2.- Interfaces externas.

3

por la pantalla.

No hay interfaces software.

No existe ninguna in

3

ción.

Este proceso deberá listar a todos lo

Ninguno

Datos proporcionados por el sistema:

alidas.

Departamento de Computación UNAN - León

Page 285: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 285 de 316

Una vez hecho el procedimiento anterior, se generará como salida un porte con todos los productos actuales de la BOUTIQUE, con los

datos:

Descripción Tipo

3.1.14

.1.14.2.1.- Interfaces de usuario. El listado de PRODUCTOS se realizará de forma interactiva por

3.1.14.2.2.- Interfaces hardware.

No hay interfaces hardware.

3.1.14.2.3.- Interfaces software. No hay interfaces software.

3.1.14.2.4.- Interfaces de comunicaciones. terfaz de comunicaciones en la aplicación.

----------------------------------------------------------------------------------------------------------------

3.2.- Requisi Requisitos estáticos Requisitos dinámicos: No existen requisitos dinámicos.

3.3.- Restricciones de dise

El formato de pantallas y listados de la aplicación deberá contener información acerca del Nombre de la BOUTIQUE, el Nombre del usuario que realiza el trabajo,

fecha y la hora del trabajo. 3.4.- Atributos.

3.4.1.- Seguridad. Todos los programas de la aplicación deberán estar protegidos

ediante autorizaciones de uso.

re

Código

.2.- Interfaces externas.

3

la pantalla.

No existe ninguna in

tos de funcionamiento.

: No existen requisitos estáticos.

ño.

la

m

Departamento de Computación UNAN - León

Page 286: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 286 de 316

3.4.2.- Mantenimiento.

Cualquier modificación que afecte a los requisitos mencionados en este documento, deberá ser reflejada en el mismo, así como la documentación obtenida en las fases de análisis, diseño y programación.

3.4.3.- Ayuda en línea.

ebida a la carencia de base informática de los usuarios finales todos

.5.- Otros requisitos.

3.5.1.- Base

n se realizará por medio de una base de dat

3.5.2.-

Todas las operaciones sobre la base de datos de realizarán según lo mencionado en el subapartado de Seguridad.

Dlos procesos del sistema deberán contar con una ayuda en línea.

3

de datos.

El almacenamiento de informacióos relacional.

Operaciones.

Departamento de Computación UNAN - León

Page 287: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 287 de 316

8.2.4 Práctica 4

MÉTODOS DE ANÁLISIS DE REQUISITOS: ANÁLISIS ESTRUCTURADO.

ELABORACIÓN DEL DFD DEL GALLO PINTO NICARAGÜENSE. ELABORACIÓN DEL DFD DE UNA EMPRESA COMERCIALIZADORA DE PRODUCTOS. ELABORACIÓN ( ) DEL DFD DE UNA PYME PEQUEÑA Y MEDIANA EMPRESA OBJETIVO En esta práctica se pretende que el alumno haga uso de los conocimientos teóricos adquiridos en clase sobre el análisis estructurado, para diseñar diagramas de flujos

TIEMPO DE REALIZACIÓN DE LA PRÁCTICA Elaboración del DFD del Gallo Pinto Nicaragüense: 1 sesión de laboratorio. Elaboración del DFD de una Empresa Comercializadora de Productos: 2 sesiones de laboratorio. Elaboración del DFD de una PYME (Pequeña y Mediana Empresa): 2 sesiones de laboratorio. SOFTWARE A UTILIZAR EasyCASE, versión 4.21.016 para Windows. Microsoft Word 2000 o cualquier editor de texto preferido por el alumno. INTRODUCCIÓN TEÓRICA El diagrama de flujo de datos (DFD) es una técnica gráfica que representa el flujo de información y las transformaciones que se aplican a los datos al moverse desde la entrada a la salida. El DFD también es conocido como grafo de flujo de datos o como diagrama de burbujas. Se puede usar el DFD para representar un sistema o un software a cualquier nivel de abstracción. Así, un DFD de nivel 0 también es denominado modelo fundamental del sistema o modelo de contexto, y representa al elemento de software completo como una sola burbuja con datos de entrada y de salida representados por flechas de entrada y de salida, respectivamente. Al partir el DFD de nivel 0 para mostrar

de datos que corresponden a aplicaciones de la vida real.

Departamento de Computación UNAN - León

Page 288: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 288 de 316

más detalles, aparecen representados procesos (burbujas) y caminos de flujo de información adicionales. Por ejemplo, un DFD de nivel 1 puede contener cinco o seis burbujas con flechas interconectándolas. Cada uno de los procesos repr del contexto.

Figura 8.2.4 Notación DFD básica.

na ninguna indicación explícita de la secuencia de

tal explícita generalmente queda

reación de un modelo de flujo de datos

FD en mayores niveles de detalle, el analista lleva a

durante la derivación de un diagrama de flujo de datos:

• El diagrama de flujo de datos de nivel 0 debe reflejar el software/sistema como una sola burbuja.

esentados en el nivel 1 es una subfunción del sistema general en el modelo

Un productor o consumidor de información que reside fuera de los límites del sistema a ser modelado. Origen /Destino Un transformador de información que reside dentro de los límites del sistema a ser mo-

delado. Se aplica a los datos (o al control) y los cambia de alguna forma. Transformación de los datos

El diagrama no proporciorocesamiento. El procedimiento o la secuencia pueden estar implícitamente en el p

diagrama, pero la representación procedimenospuesta hasta el diseño del software. p

C

medida que se refina el DAcabo implícitamente una descomposición funcional del sistema. Al mismo tiempo, el refinamiento del DFD produce un refinamiento de los datos a medida que se mueven a través de los procesos que componen la aplicación.

• Unas pocas directrices sencillas pueden ayudar de forma considerable

Un elemento de datos o una colección de elementos de datos; la cabeza de la flecha in- dica la dirección del flujo de datos. Todas las flechas de un DFD deben estar etiqueta- Elemento das. Datos en Movimiento de datos Un depósito de datos que se guardan para ser usados por uno o más procesos; puede ser tan sencillo como un buffer o una cola, o tan sofisticado como una base de datos relacional. Datos en Reposo

Entidad externa

Proceso

Almacén de datos

Departamento de Computación UNAN - León

Page 289: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 289 de 316

• Se deben anotar cuidadosamente la entrada y la salida principales.

• El refinamiento debe comenzar aislando los procesos, los elementos de datos y los almacenes de datos que sean candidatos a ser representados en el siguiente nivel.

• Todas las flechas y las burbujas deben ser etiquetadas con nombres

• Se deben refinar las burbujas de una en una.

ESARROLLO DE LA PRÁCTICA

diagramas de flujos de datos, que corresponden a plicaciones de la vida real.

laboración del DFD del Gallo Pinto Nicaragüense.

continuación, mostramos una narrativa de procesamiento de dicho sistema:

io conocer el proceso de elaboración del lato típico de Nicaragua, llamado gallo pinto. Dicho plato tiene unos pasos de laboración, que podemo mir as

• Antes de hacer ningún otro paso, se ponen a hervir los frijoles al fuego. La cantidad puede ser de una libra de frijoles crudos. Con una libra de frijoles, usted puede usar 2 litros y medio de agua para hervirlos. Agregue antes de que el agua esté hirviendo, una o dos cabezas de ajos. Cuando el agua empiece a hervir, agregue sal al gusto. Espere una media hora, hasta que los frijoles estén suaves.

epare el arroz. El arroz debe quedar lo futuro gallo pinto. Para hacer el arroz,

tinuación trozos de

onga una cazuela a fuego lento con aceite y cebolla al gusto; a continuación eche los frijoles cocidos con poquísima sopa y sofría

significativos.

• Entre sucesivos niveles se debe mantener la continuidad del flujo de información.

D Se pretende elaborar tresa E A

El software “GalloPinto”, permite al usuarpe s resu í:

• Luego de tener cocidos los frijoles, pr

más suelto posible, para efectos del siga los siguientes pasos: eche una libra de arroz en una cazuela con aceite caliente; revuelva el arroz bien hasta que quede totalmente cubierto por el aceite; agregue cebolla y sal al gusto; revuelva y revuelva el arroz hasta que tenga un color dorado; una vez dorado el arroz, eche un litro de agua tibia al arroz, revuelva bien y deje reposar; agregue a conchiltomas al gusto; tape la cazuela y espere por quince minutos hasta que el arroz esté suave. Una vez suave el arroz, retire la cazuela del fuego y deje reposar al arroz.

• Una vez que se tienen el arroz y los frijoles listos, el siguiente paso es preparar el gallo pinto: p

Departamento de Computación UNAN - León

Page 290: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 290 de 316

por 8 minutos; luego agregue el arroz y revuelva hasta obtener una mezcla bien hecha; puede agregar sal si lo desea; espere 5 minutos y vuelva a

• El gallo pinto está ya listo para servirse a la mesa.

Lo solicitado en este ejemplo es: Descomponer en procesos la receta para ela r Elaboración del DFD de una Empresa Comercializadora de Productos.

nunciado del problema

roductos a sus clientes, por medio del contacto

solicita a un proveedor, por productos, por lo cual actúa

como intermediario entre proveedores y clientes.

Los proveedores envían directamente a los clientes los productos citados en la Orden de compra, por lo cual ésta debe contener los datos del cliente necesarios para el envío. Cuando se genera una nueva Orden de Compra, la empresa elecciona el proveedor que ofrece el mejor precio del producto pedido, entre todos

empresa dispone de los catálogos enviados por los proveedores, que contienen los productos que pueden suministrar y el precio de cada producto. Cada proveedor envía un catálogo cada vez que hay un cambio de precios o cuando empieza a suministrar un nuevo producto.

a cada cliente, que recoge el total de todos los pedidos realizados por éste y para los que se ha generado una Orden de Compra. Cada nuevo cliente informa a la empresa sobre todos sus datos. Lo que se solicita es: Diseñar el DFD que muestre los procedimientos de comercialización correspondiente a la Empresa Comercializadora.

revolver; repita lo anterior hasta que sienta que la mezca está frita, entonces retire la cazuela del fuego

bo ar un buen gallo pinto al estilo nicaragüense.

E

na empresa se dedica a vender pUcon determinados proveedores. La empresa recibe pedidos de sus clientes, y contacta con los proveedores que pueden servir dichos pedidos. Cada pedido se

medio de una Orden de Compra que se envía a éste. La empresa no dispone de almacén en el que guardar los

slos proveedores que sirven ese producto. Para poder tomar esta decisión, la

Al final de cada mes se genera una factura par

Departamento de Computación UNAN - León

Page 291: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 291 de 316

Elabor Enunc a sociedad ELEC es una PYME: especializada en la distribución de productos de

equ a

l catálogo de la sociedad presenta una treintena de productos. La venta se efectúa

reas geográficas del país.

os representantes están repartidos por sector geográfico. Un cierto número de llos están especializados en uno o varios ramos profesionales. En la actualidad se

el cliente y el representante se ha cerrado la venta, el liente firmará una nota de pedido. El pedido se transmite a la sociedad por el

de las comisiones por las ventas alizadas y aceptadas por la sociedad.

r el DFD que muestre los procedimientos de la gestión comercial de la PYME.

ación del DFD de una PYME (Pequeña y Mediana Empresa)

iado del problema

Lip miento electrónico.

Epor medio de una red de representantes que trabajan para la sociedad. La comercialización de los productos sólo abarca a ciertas á Leabarca una veintena de ramos profesionales. Si tras la entrevista entre crepresentante. En todos los casos, cada venta es firmada por el representante responsable de dicho cliente. El representante recibe una comisión. Cada mes los representantes perciben el montore

Por cada venta aceptada por la sociedad se confecciona una factura por los artículos disponibles en existencias. En el caso de los artículos sin existencias se elaborará una factura complementaria cuando se reciba el material. Los pedidos no aceptados no son objeto de ningún tratamiento. Cada mes se confeccionan unos listados estadísticos a fin de seguir la evolución por ramo y sector. Lo que se solicita es: Diseña

Departamento de Computación UNAN - León

Page 292: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 292 de 316

Solución de la práctica 4

olución a la Elaboración del DFD del Gallo Pinto Nicaragüense.

S

0

GENERAREL GALLO PINTO

COCINA MESA

Utenciliospara GP

Gallo PintoIngredientesGP

Project Name:Project Path:Chart File:

Proyecto del Gallo Pintod:\misdoc~1\cl7d0c~1\anbf28~1\ejerce~1\gallop~1\dfd00001.dfd

Chart Name: Diagrama de Contexto del GP

Figura 8.2.5 DFD de nivel 0 del GalloPinto.

Created On:Created By:Modified On:Modified By:

Apr-22-2003DaniloApr-22-2003Danilo

Departamento de Computación UNAN - León

Page 293: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 293 de 316

1

PREPARARARROZ

2

PREPARARFRIJOLES

3

ELABORARGALLO PINTO

Almacende Arroz Cocinado

Almacen deFrijoles Cocidos

FrijolesCocidos

Arroz Cocinado

FrijolesCocidos

Ing de Arroz

Uten de ArrozIng de Frijoles

Uten de Frijoles

Ing PrepararGP

Gallo Pinto

Arroz Cocinado

Project Name:Project Path:

Proyecto del Gallo Pintod:\misdoc~1\cl7d0c~1\anbf28~1\ejerce~1\gallop~1\

Uten prepararGP

Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

dfd00002.dfdGENERAR EL GALLO PINTOApr-22-2003DaniloApr-22-2003Danilo

Figura 8.2.6 DFD de nivel 1 del GalloPinto.

En el DFD de nivel 0 representado en la Figura 8.2.5, podemos observar las ntidades externas COCINA y MESA. La entidad externa COCINA proporciona los

flujos de datos Ingredientes GP y Utencilios para GP. Ingredientes GP es un flujo e datos que nos proporciona información sobre los ingredientes que se necesitarán ara elaborar el gallo pinto. Pero, ¿dónde se encuentra esa información? La

respuesta a esta pregunta se encuentra más adelante en este mismo tema, donde se explicará el Diccionario de Requisitos. De igual manera sucede con el flujo de datos Utencilios para GP: es un flujo de datos que nos brinda información acerca de qué utencilios son necesarios para elaborar el gallo pinto.

e

dp

Departamento de Computación UNAN - León

Page 294: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 294 de 316

¿A quién proporciona dicha información la entidad externa COCINA? La respuesta es simple: al proceso encargado de generar el gallo pinto, que en este nivel de

esa. Igual que antes, en el Diccionario de Requisitos se puede mirar la descripción de este flujo. La entidad externa MESA, representa un objeto del mundo real, en la ual se sirve el producto elaborado. En este caso, MESA, no produce ningún tipo de

e lo que este proceso ace: preparar el arroz y producir un flujo de información correspondiente al arroz

s, representa el producto alimenticio preparado listo para servirse a la mesa.

contexto o nivel cero, está representado en una sola burbuja con el nombre “GENERAR EL GALLO PINTO”. A su vez, la burbuja “GENERAR EL GALLO PINTO”, produce un flujo denominado Gallo Pinto, que alimenta a la entidad externa MESA. Este flujo representa en sí, el plato ya preparado y listo para ser servido a la m

cinformación necesaria para la elaboración del gallo pinto, tan sólo es consumidora del flujo de información Gallo Pinto. En la Figura 8.2.6 se muestra la descomposición del GalloPinto, en el nivel 1. A como se puede observar, hay 3 procesos dentro de este nivel, enumerados del 1 al 3. Cada proceso, además de tener un número, debe tener también un nombre; dicho nombre debe dar una idea de lo que el proceso en cuestión realiza. Así, el proceso 1 llamado PREPARAR ARROZ, da una idea clara dhcocinado -Arroz Cocinado-, y dejarlo almacenado en un almacén. La misma idea se aplica al proceso PREPARAR FRIJOLES. De nuevo, este proceso origina un flujo de información correspondiente a los frijoles cocidos y los deja almacenados en otro almacén. Estos almacenes pueden ser, desde simples ficheros, hasta bases de datos relacionales complejas. Una vez que se tiene preparado el arroz y los frijoles, se procede a la elaboración del gallo pinto. Esto lo hacemos con el proceso ELABORAR GALLO PINTO, el cual toma como entradas las salidas de los almacenes descritos anteriormente (más otras entradas adicionales que se explicarán más adelante) y origina el flujo de datos Gallo Pinto. Este flujo de datoy

Departamento de Computación UNAN - León

Page 295: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 295 de 316

Solución a la Elaboración del DFD de una Empresa Comercializadora de Productos.

0

GESTIONPEDIDO CLIENTE

CLIENTES PROVEEDORESPedido Cliente Orden Compra

Factura

Datos ClienteNuevo

Catalogos

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00001.dfdDiagrama de ContextoMay-03-2002DaniloMay-03-2002Danilo

Figura 8.2.7 DFD de nivel 0 GESTION PEDIDO CLIENTE. A como se puede ver en el DFD de nivel 0, mostrado en la Figura 8.2.7, las entidades externas que surgen como consecuencia del análisis de problema, son CLIENTES y PROVEEDORES. Ambas se retroalimentan con la burbuja de nivel 0, GESTION DE PEDIDO CLIENTE. La entidad externa CLIENTES suministra al sistema los datos de un cliente nuevo (mediante el flujo Datos Cliente Nuevo), y los datos relativos al pedido de un cliente (mediante el flujo Pedido Cliente). El sistema produce un flujo Factura, el cual es consumido por CLIENTES; esto es, el sistema origina una factura al final de cada mes, que es entregada a cada cliente que haya realizado un pedido. La entidad externa PROVEEDORES alimenta al sistema con el flujo Catalogos, porque los proveedores envían catálogos a la Empresa para mantenerla actualizada con los precios de los productos. A su vez, el sistema genera un flujo Orden Compra, el cual es consumido por PROVEEDORES; esto es así porque la Empresa envía órdenes de compra a los proveedores, para que éstos puedan entregar los productos a los clientes.

Departamento de Computación UNAN - León

Page 296: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 296 de 316

1

CAPTURACLIENTE

2

CAPTURAPEDIDO

3

CAPTURACATALOGO

5GENERARORDEN COMPRA

4

EMITIRFACTURA

AlmacenDatos Cliente

AlmacenPedido Cli

AlmacenCatalogo

Datos ClienteNuevo

Pedido Cliente Catalogos

Datos Cliente Pedidos Cli Catalogo Prov

Datos ClientePedidos Cli Pedidos Cli Catalogo Prov

Factura Orden Compra

Project Name: PProject Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

royecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00002.dfdGESTION PEDIDO CLIENTEMay-03-2002DaniloMay-03-2002Danilo

Figura 8.2.8 DFD de nivel 1 GESTION PEDIDO CLIENTE.

rten en los procesos CAPTURA PEDIDO, CAPTURA CLIENTE y CAPTURA CATALOGO respectivamente.

En la Figura 8.2.8 se puede ver el DFD de nivel1 para GESTION PEDIDO CLIENTE. Una recomendación que se suele seguir por los analistas de sistemas es, identificar los flujos de datos que le llegan a la burbuja de nivel 0 y convertirlos en procesos para en el nivel 1. Así, por ejemplo, Pedido Cliente, Datos Cliente Nuevo y Catalogos, se convie

Departamento de Computación UNAN - León

Page 297: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 297 de 316

De igual forma, se identifican los flujos que produce la burbuja de nivel 0, y se

te y el flujo el Almacén C zonamiento e hace para el proceso GENERAR ORDEN COMPRA.

convierten en procesos del nivel 1. Así, Factura y Orden Compra, se convirten en los procesos EMITIR FACTURA y GENERAR ORDEN COMPRA. El proceso EMITIR FACTURA, toma como entradas el flujo del Almacén Datos Clien

Pedido li, para producir la facutura del cliente. El mismo rads A continuación, se muestra la explotación del proceso 4, EMITIR FACTURA:

4.1ACUMULARTOTAL PEDIDO

4.2

IMPRIMIRFACTURA

Pedido Cli

Datos Clientes

Importe Total

Factura

Project Name:Project Path:Chart File:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00003.dfd

Chart Name:Created On:Created By:Modified On:Modified By:

EMITIR FACTURAMay-03-2002DaniloMay-03-2002Danilo

Figura 8.2.9 DFD de nivel 2 que refina el proceso EMITIR FACTURA. A como se puede ver en la Figura 8.2.9, es necesario explotar el proceso EMITIR FACTURA, ya que para imprimir una factura de cobro para un cliente, primero habrá que acumular los pedidos que ha realizado éste a la empresa durante un mes. Ya que este proceso no es una función sencilla porque habrá que hacer dos funciones: acumular el total de pedidos y luego imprimir la factura, habrá que explotarlo para simplificar aun más y hacer más entendible el diagrama. Acumular el total de pedido, implicaría buscar en la base de datos los pedidos de los clientes, ubicar a un cliente en específico, y sumar todos los pedidos que pudiese

Departamento de Computación UNAN - León

Page 298: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 298 de 316

tener dicho cliente al fin de mes. Luego, con ese resultado, se enviaría una órden de peresión ya sea en impresora o por pantalla, de la factura correspondiente.

A continuación se muestra la descomposición del proceso 5, GENERAR ORDEN

E COMPRA.

im

D

Project Name:Project Path:Chart File:Chart Name:

Proyecto Empresa Comercializadord:\misdoc~1\cl7d0c~1\analis~1\ejease~1\dfd00004.dfdGENERAR ORDEN COMPRA

5.1SELECCIONMEJOR PROVEEDOR

5.2

ORDEN COMPRA

Catalogo Prov

Mejor Proveedor

IMPRIMIR

Pedidos Cli

Orden Compra

Created On:Created By:Modified On:Modified By:

May-03-2002DaniloMay-03-2002Danilo

Figura 8.2.10 DFD de nivel 3 que refina el proceso GENERAR ORDEN COMPRA.

A como muestra la Figura 8.2.10, es necesario descomponer el proceso GENERAR ORDEN DE COMPRA, porque para poder generar una órden, primero habrá que seleccionar al mejor proveedor, esto es, al proveedor que ofrezca un mejor precio de el(los) producto(s) solicitado(s) por el cliente. Lo lógico es que el proceso 5.1 SELECCIÓN MEJOR PROVEEDOR, busque en la base de datos el producto de más bajo precio, y a continuación consulte a qué proveedor pertenece ese producto. Una vez teniendo al proveedor indicado, se enviaría una órden de imprimir la órden de compra para el proveedor seleccionado.

na cosa importantísima que se debe cumplir es que, los flujos de datos que se apliquen sobre un proceso (de entrada o de salida) en un nivel superior, se deben

U

Departamento de Computación UNAN - León

Page 299: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 299 de 316

respetar si ese proceso se explota en un nivel inferior. Así por ejemplo, al nivel 0 del ejemplo que estamos analizando (el cual es lógico que se explote), tiene como ntradas los flujos de datos Pedido Cliente, Datos Cliente Nuevo y Catalogos. Pues

en la explotación de dicho nivel, también aparecen los mismos flujos de entrada, ero ahora aplicados a los distintos procesos en los que se ha descompuesto el

nivel. Lo mismo sucede con las salidas; las salidas del diagrama de contexto del ismo ejemplo son Factura y Orden Compra, y en la explotación de dicho nivel, o

MITIR FACTURA y Orden Compra es una salida del proceso 5, GENERAR ORDEN COMPRA.

La misma lógica se sigue aplicando a las sucesivas explotaciones de los sucesivos iveles.

e

p

msea en en el nivel 1, las salidas son las mismas: Factura es una salida del proceso 4 E

n

Departamento de Computación UNAN - León

Page 300: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 300 de 316

Solución a la Elaboración del DFD de una PYME (Pequeña y Mediana Empresa)

0

Gestionde la Sociedad ELEC

REPRESENTANTE CLIENTESPedido Factura

Comisiones

Nota Pedido

Fact Complementaria

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Comercial PYMEd:\misdoc~1\cl7d0c~1\analis~1\ejease~1\pyme\dfd00001.dfdDiagrama de ContextoMay-13-2002DaniloMay-13-2002Danilo

Figura 8.2.11 DFD de nivel 0 Gestión de la Sociedad ELEC.

La figura Figura 8.2.11 muestra el nivel 0 para la la Gestión de la sociedad ELEC. En ella se puede ver el sistema a nivel global. Vemos por ejemplo, que los representantes hacen unos pedidos a la Sociedad, y reciben unas comisiones. Así mismo, observamos que los Clientes, emiten notas de pedido a la Sociedad, y que, una vez que éstos llegan a la Sociedad y som aprobados, se les envía o una factura normal si todos los productos que solicitó existen, o una factura complementaria por los prdocutos que en ese momento no hay, pero que se le serán entregados después.

Departamento de Computación UNAN - León

Page 301: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 301 de 316

1

ProcesarPedido

2

ProcesarVentas

3

Facturacion

4

CalcularComision

5

ListadoEstadistico

AlmPedido

AlmVenta

AlmFacturas

AlmComisiones

Pedido Nota PedidoComisiones

Pedido Aprobado

Estadisticas

Comisiones

Comisiones

Pedido Aprobado

Venta Total

Venta Total

Venta Total

Facturas

Facturas

Fact Complementaria

Factura

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Comercial PYMEd:\misdoc~1\cl7d0c~1\analis~1\ejease~1\pyme\dfd00002.dfdGestion de la Sociedad ELEC

May-13-2002Danilo

Figura 8.2.12 DFD de nivel 1 Gestión de la Sociedad ELEC. La Figura 8.2.12 muestra el DFD de nivel 1 para la Gestión de la Sociedad ELEC. En el proceso 1, se combinan el Pedido y la Nota de Pedido, para procesar el pedidp de Cliente. El proceso 2 toma como entrada el pedido aprobado, para procesar esa venta. En base a esa venta, se calcula la comisión para el representante en el proceso 4. La venta total es útil para generar las facturas en el proceso 3, ya sean facturas corrientes o complementarias. Las facturas complementarias y las comisiones, son usados para generar los listados estadísticos en el proceso 5.

May-13-2002Danilo

Departamento de Computación UNAN - León

Page 302: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 302 de 316

Departamento de Computación UNAN - León

Page 303: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 303 de 316

3.1

ElaborarFactura

3.2

ImprimirFactura

AlmDatos Fact

Venta Total

Datos Factura Datos Factura

Factura

Fact Complementaria

Project Name:Project Path:Chart File:Chart Name:Created On:Created By:Modified On:Modified By:

Comercial PYMEd:\misdoc~1\cl7d0c~1\analis~1\ejease~1\pyme\dfd00003.dfdFacturacionMay-13-2002DaniloMay-13-2002Danilo

Figura 8.2.13 Explotación del proceso Facturación. La Figura 8.2.13 muestra la explotación del proceso 3 del DFD de nivel 1. Esta explotación se debe a que, en el momento de elaborar la factura, se debe comprobar que los productos que nos piden están disponibles. Una vez que conozcamos esta información, podemos imprimir el tipo de factura correspondiente.

Departamento de Computación UNAN - León

Page 304: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 304 de 316

Departamento de Computación UNAN - León

Page 305: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 305 de 316

AANNEEXXOOSS

Departamento de Computación UNAN - León

Page 306: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 306 de 316

9 Anexos

Ma l

as El CASEomo u dos de esarrollo oftware estructurado. Las herramientas CASE incluyen editores gráficos teractivo que facilitan la creación de diagramas de flujo de datos y de control. La formación de estos diagramas se almacena en una base de datos, llamada nciclopedia, que facilita la coordinación de un proyecto software a lo largo de todo u ciclo de vida. En los entornos de herramientas CASE integradas, las erramientas de dirección de proyectos emplean la enciclopedia para descomponer

el proyecto software en subtareas y asignan a cada una de ellas un presupuesto y un control del progreso de desarrollo. Dado que la modelización de flujo es una actividad gráfica, se pueden desarrollar los DFDs más eficientemente y conseguir resultados más estéticos con herramientas CASE. El ingeniero del software usa las posibilidades de dibujo de una herramienta

entos clave de esta alternativa son el tón, los menús desplegables, las ventanas múltiples y una paleta que contiene los

símbolos de modelización. A medida que se refina cada nivel del modelo de flujo, la herramienta CASE construye una jerarquía interna, de forma que cada burbuja “madre” está asociada con sus burbujas “hijas”, y éstas con ella. De esta forma, el analista puede ir pasando por los distintos modelos de flujo, a partir del nivel de contexto hasta el nivel de mayor refinamiento. El analista puede también “asociar”, con unas sencillas pulsaciones de ratón, las entradas del diccionario de requisitos a las flechas de datos o de control, a los almacenes o a las entidades específicos. Una vez que se ha creado el modelo, puede ser redibujado, cambiado o imprimido con sólo unas pocas órdenes.

ANEXO A

nua del Easy CASE E y CASE Profesional

(Computer Aided Software Engineering) surgió a mediados de los ochenta n intento de proporcionar un soporte automatizado a los métoc

d ss in

inesh

CASE para crear cada modelo de flujo. Los elemra

Departamento de Computación UNAN - León

Page 307: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 307 de 316

Pasos para crear un proyecto:

1. Crear un directorio antes de entrar a EasyCASE, para almacenar los rchivos del proyecto.

2. ar click en la opción EasyCASE Profesional 4.21, del menú Inicio

ASE de la siguiente ventana.

3. se la op n F cionar PROJECT ...

4. dicar el directorio de trabajo, tecleandolo o buscandolo en la lista de irectorios, seleccionar Open y luego aparecerá una ventana: "Create new

ras muestran lo expuesto.

a

DProgram. Luego, seleccione EasyC

Ir a ció ILE del menú de barra y selec

Indproject configuration". Las siguientes figu

Departamento de Computación UNAN - León

Page 308: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 308 de 316

5. De esta ventana:

a.) Teclear el nombre del proyecto en: New Project Name b.) Process Models Methodology, dejarlo como: [Yourdon (DFD)] c.) Seleccionar: "Merise (ERD)" en - Data Models Methodology- [Merise (ERD)] La siguiente figura muestra lo expuesto:

d.) Presionar o hacer clic en el botón: Define Context Diagram y luego dar clic en OK.

Departamento de Computación UNAN - León

Page 309: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 309 de 316

e.) Dar click en el botón OK de la ventana Create New Project n.

f.) En la ventana: Name object, teclear el nombre del diagrama de contexto

Configuratio

Nota:

6.

Si se no se agregó el nombre o el método en esta parte, se puede con OPTION del menú principal, seleccionando "Project preferences..."

Seleccionar FILE, New y agregando el nombre del proyecto aparece la pantalla de diseño con una ventana con los símbolos a utilizar en el diseño del DFD. La siguiente figura muestra el resultado.

Departamento de Computación UNAN - León

Page 310: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 310 de 316

Iconos de control:

Crear un nuevo gráfico.

Dar nombre a un objeto.

Cambiar el número de un objeto.

Definir los hijos para un objeto.

Abrir un gráfico

Salvar el gráfico actual.

Mostrar la caja de diálogo de impresión.

Editar la entrada del diccionario de datos para el objeto seleccionado.

Cambiar la escala de visualización del gráfico.

Departamento de Computación UNAN - León

Page 311: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 311 de 316

Pro

lug amente. Se puede cambiar de tamaño al símbolo ubicándose en uno de los cuadritos (que indica que está señalado o marcado) con el ratón manteniendo el clic pre cerlo mas grande o mas pequeño, y finalmente dejar de presionarlo en el tamaño deseado.

2. Pre

Cambiar en 10% el gráfico en mas pequeño o mas grande

Mostrar o esconder una rejilla de puntos

Mostrar y esconder una reglilla

Mostrar y esconder una ventana de fácil observación de objetos

Mostrar los hijos del objeto seleccionado

to

Mostrar y esconder la paleta de objetos gráficos

Mostrar los niveles del objeto seleccionado

Desplegar la arquitectura del proyec

Desplegar los detalles de una entidad

cedimientos para seleccionar los símbolos:

1. Presionar click sobre el símbolo que está en la ventana y luego ubicarse en el ar de la pantalla que se desea el símbolo y presionar clic nuev

sionado mover el ratón para ha

sionar la barra con la flecha inclinada.

Departamento de Computación UNAN - León

Page 312: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 312 de 316

Procedimientos para agregar los símbolos de flujo:

Marcar de la ventana de símbolos la barra con la flecha horizontal (indica el flujo).

2. Ubicarse en el gráfico de partida y dar click. Luego, dar click nuevamente na línea que se puede extender con el ratón).

gada y marcarlo con un click.

4. rde donde se quiere que llegue el flujo y

dar click.

ombres a los procesos, flujos y almacenes:

Exi

For

1. Marcar el objeto y presionar clic.

Pregunta si dar nombre antes de ... (chart object must be named ...). Contestar SI

3. Aparece ventanta: Nombre Object

4. Luego aparece otra ventana: Define child object.

5. Para definir el objeto hijo como: Dar clic en el boton para que muestre la lista:

Text file (txt) [Para agregar un texto como comentario] Document (doc)

Primitive Process Specification. (pps) [Procesos que no se

descomponen]

Estos cambian dependiento del tipo de objeto.

6. Dar los nombres de los componentes separados con el signo mas (+) y presionar APPEND para cada uno. Esto es para que se agreguen al Diccionario de Datos.

1.

(debe aparecer u

3. Ubicarse en el símbolo de lle

Ubicarse en uno de los puntos del bo

Procedimientos para asignarles n

sten dos formas:

ma 1:

2.

Data Flow Diagrama (DFD) [Si es proceso que se descompone]

Record [Para flujos de datos] Element (Para elementos de datos)

Departamento de Computación UNAN - León

Page 313: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 313 de 316

En caso que se requiera agregar los elementos posteriormente, primero se marca el flujo y luego se da doble click.

orma 2:

1. Marcar el objeto

2.

Name: (agregar el nombre del objeto)

Para descomponer un Proceso:

1. Marcar el proceso.

2. Asegurarse eque el tipo de objeto sea DFD con EDIT y Define Child.

3. Dar dos click y luego pasa a una nueva pantalla en blanco donde se debe iseñar la descomposición. Esto se realiza de la misma forma que en los

procedimientos anteriores. Para realizar la Pruebas: Estas se realizan con dos opciones del EasyCase.

1. Seleccionar Tools del menú principal y luego Rule check. Esta se realiza a cada uno de los DFD, y revisa los errores de nombres, de consistencia, etc.

2. Seleccionar Tools del menú principal y luego Level Balance. Este se puede

realizar desde cualquier nivel, y comprueba el balance de entradas y salidas, entre el DFD actual con todos los inferiores o subordinados. Lo común es realizarlo desde el Diagrama de Contexto.

F

Ir al menú Edit y seleccionar:

Define child... (definir el tipo de objeto)

d

Departamento de Computación UNAN - León

Page 314: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 314 de 316

Pasos para crear un Modelo Entidad Relación:

1. Crear el Proyecto, con la Metodología Merise ERS.

2. Crear un New Chart.

3. Seleccionar en Chart Type: Entity Relationship Diagrama (erd)

4. Dar el nombre del Diagrama en:

Chart Name:____________________________

La siguiente figura ilustra lo expuesto:

Al dar clic en OK, aparece el enotorno de trabajo que se muestra a ontinuación:

c

Departamento de Computación UNAN - León

Page 315: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 315 de 316

5. Para agregar la cardinalidad, se procede de la siguiente forma:

a. Marcar el objeto (línea de asociación)

b. Presionar el botón derecho (alternativo)

c. Seleccionar Line properties (propiedades de las líneas)

d. Seleccionar Cardinality: 0:1

6. Agregar nombre a las entidades:

Para incorporar los nombres de las entidades, solamente hay que agregar el nombre del Objeto.

7. Para agregar los atributos, definir el objeto como Record y luego de View,

seleccionar Entity Details (F9), de esta ventana seleccionar el botón Display Record Components.

Departamento de Computación UNAN - León

Page 316: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Análisis y Diseño de Sistemas de Información Página 316 de 316

Departamento de Computación UNAN - León

ANEXO B: REFERENCIAS BIBLIOGRAFÍA

• Kendall y Kendall. 1997. Análisis y Diseño de Sistemas. 3 Edición. Pearson Educación.

• Seen James. 1996. Análisis y Diseño de Sistemas. 1 Edición. Prentice Hall.

Page 317: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 1 de 1

PLAN DOCENTE DE ALGORITMOS Y ESTRUCTURAS DE DATOS

Departamento de Computación UNAN - León

Page 318: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 2 de 2

INDICE DE CONTENIDO 1 INTRODUCCIÓN............................................................................................................................6

2 OBJETIVOS...................................................................................................................................9

3 SITUACIÓN DE LA ASIGNATURA EN EL PLAN DE ESTUDIOS DE LA UNAN-LEON ..........11 3.1 RELACIÓN ENTRE ASIGNATURAS .............................................................................................11

3.1.1 Programación I ................................................................................................................12 3.1.2 Programación II ...............................................................................................................14

4 METODOLOGÍA DIDÁCTICA Y MATERIAL DIDÁCTICO UTILIZADO.....................................16

5 PROCESO DE EVALUACIÓN.....................................................................................................18

6 TEMPORIZACIÓN .......................................................................................................................20

7 DESARROLLO DEL TEMARIO ..................................................................................................24 7.1 PRESENTACIÓN DE LA ASIGNATURA ........................................................................................24 7.2 INTRODUCCIÓN A LOS ALGORITMOS ........................................................................................30

7.2.1 Definición de Algoritmo ...................................................................................................32 7.2.2 ¿Qué es un algoritmo?....................................................................................................32 7.2.3 Clasificación de algoritmos..............................................................................................33 7.2.4 Tipos de Algoritmos.........................................................................................................35 7.2.5 Lenguajes Algorítmicos ...................................................................................................35 7.2.6 Metodología para la solución de problemas por medio de computadora .......................35 7.2.7 El Pseudocódigo .............................................................................................................37 7.2.8 Problema y ejemplar de un problema .............................................................................42 7.2.9 Problemas Secuenciales.................................................................................................43 7.2.10 Problemas Condicionales ...........................................................................................44 7.2.11 Problemas ( Hacer para )............................................................................................47 7.2.12 Ciclos con un número indeterminado de iteraciones..................................................49 7.2.13 El cálculo del máximo común divisor ..........................................................................50 7.2.14 Algoritmos Numéricos.................................................................................................56

7.3 ESTRUCTURAS DINÁMICAS DE DATOS ......................................................................................59 7.3.1 Introducción.....................................................................................................................61 7.3.2 Asignación dinamica de memoria ...................................................................................61 7.3.3 Listas lineales..................................................................................................................62 7.3.4 Operaciones básicas.......................................................................................................65

7.3.4.1 Inserción de un elemento al comienzo de la lista ................................................................ 65 7.3.4.2 Inserción de un elemento en general................................................................................... 66 7.3.4.3 Borrar un elemento de la lista. ............................................................................................. 67 7.3.4.4 Recorrido de una lista cuyo primer elemento está apuntado por p...................................... 68 7.3.4.5 Buscar un elemento con un valor x...................................................................................... 68

7.3.5 Pilas, colas y listas doblemente enlazada.......................................................................73 7.3.5.1 Pilas..................................................................................................................................... 73 7.3.5.2 Colas. .................................................................................................................................. 93 7.3.5.3 Listas circulares. .................................................................................................................. 99 7.3.5.4 Listas doblemente enlazadas ............................................................................................ 105 7.3.5.5 Arboles .............................................................................................................................. 110 7.3.5.6 Árboles binarios de búsqueda ........................................................................................... 114 7.3.5.7 Borrado en árboles ............................................................................................................ 118 7.3.5.8 Árboles binarios perfectamente equilibrados ..................................................................... 121

7.4 ALGORITMOS DE ORDENACIÓN Y BÚSQUEDA ..........................................................................125 7.4.1 Introducción...................................................................................................................126 7.4.2 Recursividad..................................................................................................................126 7.4.3 Ordenación de datos .....................................................................................................131

7.4.3.1 Método de la burbuja. ........................................................................................................ 132 7.4.3.2 Método de inserción. ......................................................................................................... 134

Departamento de Computación UNAN - León

Page 319: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 3 de 3

7.4.3.3 Método de Quicksort.......................................................................................................... 136 7.4.4 Búsqueda de datos .......................................................................................................139

7.4.4.1 Búsqueda secuencial......................................................................................................... 139 7.4.4.2 Búsqueda Binaria .............................................................................................................. 141

8 PRACTICAS DE LABORATORIO.............................................................................................146 8.1 PLANIFICACIÓN TEMPORAL....................................................................................................149 8.2 PROPUESTA Y SOLUCIÓN DE PRÁCTICAS................................................................................151

8.2.1 Práctica 1.......................................................................................................................151 8.2.2 Práctica 2.......................................................................................................................159 8.2.3 Práctica 3.......................................................................................................................169 8.2.4 Práctica 4.......................................................................................................................175 8.2.5 Práctica 5.......................................................................................................................206 8.2.6 Práctica 6.......................................................................................................................216 8.2.7 Práctica 7.......................................................................................................................261 8.2.8 Práctica 8.......................................................................................................................272 8.2.9 Práctica 9.......................................................................................................................291

9 ANEXOS ....................................................................................................................................306

Departamento de Computación UNAN - León

Page 320: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 4 de 4

INDICE DE TABLAS Tabla 3.1.1 Relación de asignaturas........................................................................ 12 Tabla 5.1 Proceso de Evaluación............................................................................. 18 Tabla 6.1 Temporización general. ............................................................................ 20 Tabla 6.2 Temporización detallada. ......................................................................... 21 Tabla 8.1.1 Temporización de las prácticas y su relación con la teoría. ............... 150 INDICE DE FIGURAS Figura 3.1.1 Relación gráfica de asignaturas precedentes a AED. .......................... 12 Figura 7.3.1 Ejemplo de una lista. ............................................................................ 63 Figura 7.3.2 Inserción en la lista detrás del elemento apuntado por p. .................... 66 Figura 7.3.3 Inserción en la lista antes del elemento apuntado por p. ..................... 67 Figura 7.3.4 Borrar el sucesor del elemento apuntado por p. ................................. 67 Figura 7.3.5 Borrar el elemento apuntado por p...................................................... 68 Figura 7.3.6 Pilas sin uso de listas lineales............................................................. 74 Figura 7.3.7 Representación de una Pila ................................................................. 89 Figura 7.3.8 Representación de una Cola............................................................... 93 Figura 7.3.9 Representación de una Lista Circular ................................................. 99 Figura 7.3.10 Lista doblemente enlazada. ............................................................ 105 Figura 7.3.11 Arbol................................................................................................ 110 Figura 7.3.12 Fórmulas algebraicas. ..................................................................... 111 Figura 7.3.13 Un árbol representado como una estructura de datos. ................... 112 Figura 7.3.14 Recorridos de un árbol. ................................................................... 112 Figura 7.3.15 Árbol de búsqueda. ......................................................................... 114 Figura 7.3.16 Borrar el nodo con clave 5. ............................................................. 119 Figura 7.3.17 Árboles perfectamente equilibrados. ............................................... 121 Figura 8.2.1 Cuadrado mágico para una matriz de 3 x 3. ..................................... 151 Figura 8.2.2 Un posible moivimiento del caballo. .................................................. 159 Figura 8.2.3 Ejemplo de una lista. ......................................................................... 175 Figura 8.2.4 Estado del diccionario con 3 palabras introducidas. ......................... 178 Figura 8.2.5 Representación de una pila............................................................... 206 Figura 8.2.6 Cola mediante listas lineales............................................................. 216 Figura 8.2.7 Funcionamiento de la cola a simular. ................................................ 218 Figura 8.2.8 Clientes atendido en cada caja. ........................................................ 219 Figura 8.2.9 Representación gráfica de un árbol binario....................................... 262 Figura 8.2.10 Ejemplo de una lista lineal............................................................... 291

Departamento de Computación UNAN - León

Page 321: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 5 de 5

IINNTTRROODDUUCCCCIIÓÓNN

Departamento de Computación UNAN - León

Page 322: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 6 de 6

1 INTRODUCCIÓN En el año 1994 se crea, bajo el Proyecto de Colaboración de la UA (Universidad de Alcalá) y la UNAN – León (Universidad Nacional Autónoma de Nicaragua – León), un convenio entre el Departamento de Automática –DA- de la UA y el Departamento de Computación –DC- de la UNAN. El objetivo inicial era apoyar la carrera de Licenciatura en Computación con capacitación continua al personal docente y la donación de bibliografía y ordenadores. El convenio ha permitido la especialización del personal docente y de estudiantes que se han incorporado al mismo. Una vez logrados con éxitos estos objetivos, el Departamento de Computación decidió la apertura de la carrera Ingeniería en Sistemas de Información - ISI, para ofrecer a los estudiantes una nueva alternativa en la elección de su carrera universitaria. Esta nueva carrera incluye asignaturas especializadas que antes no se tenían, así como asignaturas condensadas que reúnen diferentes materias del antiguo plan de la Licenciatura. Por esta razón, se ha elaborado este plan docente de una asignatura condensada, que servirá para alcanzar los objetivos propuestos en la apertura de la carrera. En el presente documento se aborda el desarrollo de los temas del Plan Docente de la asignatura Algoritmos y Estructuras de Datos que se imparte en la carrera de Ingeniería en Sistemas de Información en la UNAN – León. Se presenta también la relación con otras asignaturas, la metodología a seguir, el material didáctico y apoyo para impartirla, la planificación del contenido teórico de dichos temas, así como la bibliografía necesaria con las referencias a Internet pertinentes. En este documento se describe y desarrolla los temas principales de cada capítulo de dicha asignatura, con el objetivo de que exista en el DC de la UNAN – León - una guía rápida de consultar y que pueda dar información tanto a profesores como a estudiantes, acerca del propósito y organización de la asignatura. El desarrollo de este plan docente se planteó en tres fases. En la primera fase se han definido: los objetivos, la situación de la asignatura en el plan de estudios, la metodología didáctica y material didáctico a utilizar, el proceso de evaluación de la asignatura y la temporización en el semestre. La segunda fase consistió en la recopilación de la información para desarrollar el contenido teórico previamente definido. En la última fase se elaboraron las propuestas de las prácticas de laboratorio a realizar y la temporización y el sistema de evaluación de dichas prácticas. El plan docente está compuesto de dos partes:

• Parte teórica: en esta parte se desarrolla el contenido teórico del temario planteado y que corresponde a la explicación de la asignatura en la clase magistral.

• Parte práctica: en esta parte se encuentran las prácticas de laboratorio que

los estudiantes deben seguir, para unificar los conceptos teóricos vistos en clase.

Departamento de Computación UNAN - León

Page 323: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 7 de 7

Para la realización del proyecto se ha contado con un ordenador IBM compatible con sistema operativo Windows XP y Microsoft Office 2000.

Departamento de Computación UNAN - León

Page 324: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 8 de 8

OOBBJJEETTIIVVOOSS

Departamento de Computación UNAN - León

Page 325: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 9 de 9

2 OBJETIVOS Los objetivos de este plan docente se listan a continuación:

• Elaborar un documento en el que se muestren los aspectos organizativos de la asignatura Algoritmos y Estructuras de Datos, tales como: situación, metodología y material didáctico, proceso evaluativo y temporización.

• Desarrollar el contenido temático, tanto a nivel teórico como práctico, de la asignatura Algoritmos y Estructuras de Datos.

• Proporcionar un material en el que se incluyan los conocimientos fundamentales en el área de Algoritmos y Estructuras de Datos, que un estudiante de Ingeniería en Sistemas de Información debería tener.

• Contar con un documento guía para impartir la asignatura de Algoritmos y Estructuras de Datos, y que sirva como elemento orientativo para futuros docentes de esta materia.

Departamento de Computación UNAN - León

Page 326: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 10 de 10

SSIITTUUAACCIIÓÓNN DDEE LLAA AASSIIGGNNAATTUURRAA EENN EELL PPLLAANN DDEE EESSTTUUDDIIOOSS

DDEE LLAA UUNNAANN--LLEEOONN

Departamento de Computación UNAN - León

Page 327: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 11 de 11

3 SITUACIÓN DE LA ASIGNATURA EN EL PLAN DE ESTUDIOS DE LA UNAN-LEON

La asignatura Algoritmos y Estructuras de Datos -AED- se imparte en el quinto semestre ( primer semestre de tercer año ) de la carrera Ingeniería en Sistemas de Información de la UNAN – León, que ofrece la Facultad de Ciencias. La carrera se desarrolla a lo largo de 10 semestres de estudios, es decir, 5 años académicos / lectivos para la culminación de la misma. Esta asignatura se imparte en el V semestre del plan de estudios. El período lectivo para esta asignatura consta de 4 horas a la semana, de las cuales 2 horas se dedican a la parte teórica y 2 horas a la parte práctica. El total de semanas de que consta un semestre es de 16, luego tenemos un total de 32 horas de práctica y 32 horas teóricas. Esta relación se muestra mejor en la Tabla 3.1

Tabla 3.1 Relación horaria de Algoritmos y Estructuras de Datos.

Asignatura TSS HTS HPS THS THTS THPS THTPS AED 16 2 2 4 32 32 64

Leyenda: AED: Algoritmos y Estructuras de Datos. TSS: Total de Semanas por Semestre. HTS: Horas Teóricas Semanales. HPS: Horas Prácticas Semanales. THS: Total de horas semanales. THTS: Total de Horas Teóricas por Semestre. THPS: Total de Horas Prácticas por Semestre. THTPS: Total de Horas Teóricas y Prácticas por Semestre.

3.1 Relación entre asignaturas A continuación veremos la relación que existe entre Algoritmos y Estructuras de Datos y otras asignaturas del plan de ISI. En la siguiente tabla se muestran las asignaturas que aportan un conocimiento previo al curso de Algoritmos y Estructuras de Datos.

Departamento de Computación UNAN - León

Page 328: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 12 de 12

Tabla 3.1.1 Relación de asignaturas

Asignatura Impartida en Programación I III Semestre Programación II IV Semestre

Una relación más clara entre las asignaturas se muestra en la Figura 3.1.1.

Figura 3.1.1 Relación gráfica de asignaturas precedentes a AED. A continuación, se describirá brevemente el contenido de cada asignatura y su relación con las demás asignaturas mostradas en la figura anterior.

3.1.1 Programación I Esta asignatura tiene como objetivos, que el alumno logre manejar y explicar las técnicas de un lenguaje de programación, que logre explicar los conceptos básicos de programación estructurada y que pueda atacar un problema haciendo uso de las técnicas para desarrollar algoritmos. El contenido por temas de la asignatura es el siguiente:

Departamento de Computación UNAN - León

Page 329: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 13 de 13

Tema No 1: Fundamentos de ordenadores: En este tema se estudia una Introducción a los ordenadores, el concepto de ordenador, la arquitectura propuesta por Von Neuman, definición de programa y lenguaje, qué son los periféricos y cómo funcionan, el concepto de un sistema operativo y qué tipos de programas existen. Tema No 2: Fases en el desarrollo de un programa: En este tema se hace una breve reseña histórica del Lenguaje C, se muestra la realización de un programa en C sencillo pero ilustrativo, se explican los caracteres que soporta C, los tipos fundamentales de datos con ejemplo de valores que puedan tomar, qué son los tipos derivados y cuándo usarlos, los nombres de tipos, constantes, identificadores, palabras claves, comentarios, variables, declaración de constantes, expresiones numéricas, los diferentes tipos de operadores que soporta C, qué son las expresiones y cómo se construyen, expresiones para expresar condición, y la prioridad y el orden de evaluación de una expresión. Tema No 3: Estructura de un programa: En este tema se explica cómo es la forma que debe tener un programa en C, qué son los ficheros de cabecera, expresiones, sentencias, declaraciones de funciones, definiciones de funciones, llamada a una función, los distintos tipos de argumentos que puede tener una función, ámbito y accesibilidad de una variable, las clases de almacenamiento, sentencias de asignación, y la entrada y salida estándar. Tema No 4: Sentencias de control: En este tema se estudian las sentencias condicionales if y else, las sentencias switch y las sentencias break, las sentencias while, do while, for, continue, y go to. Tema No 5: Tipos estructurados de datos: En este tema se estudian los arreglos, sus características, sus formas posibles de declaración, cómo se pasan los arreglos a una función, las cadenas de caracteres, las funciones para manipular cadenas de caracteres, funciones para conversión de datos, funciones para clasificar y convertir caracteres, qué son las estructuras y las uniones, qué son los campos de bits y cuando son útiles. Tema No 6: Punteros: En este tema se estudia qué son los punteros, para qué sirven y cómo se crean, las operaciones con punteros, se hace la relación entre punteros y arrays, los punteros a cadenas de caracteres, cómo se asigna memoria haciendo uso de los punteros y de las funciones de bibliotecas, y por último los punteros a estructuras. La importancia de esta asignatura en Algoritmos y Estructuras de Datos, se basa en que aporta los conocimientos básicos necesarios de programación, para que el alumno sea capaz de poder estructurar de forma eficiente un programa en Lenguaje C.

Departamento de Computación UNAN - León

Page 330: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 14 de 14

3.1.2 Programación II Esta asignatura supone un previo conocimiento de Programación I, y tiene como objetivos desarrollar en el estudiante la capacidad para utilizar las funciones de C, así como ser capaz de desarrollar sus propias funciones para la implementación de programas de forma estructurada; proporcionar el estudiante el conocimiento necesario para que sea capaz de utilizar y crear sus propios archivos en Lenguaje C, y que pueda distinguir entre los diferentes tipos de archivos que se pueden implementar en este lenguaje; que el estudiante desarrolle habilidades para utilizar las macros predefinidas y directrices en C en el proceso de pre-compilación; y que el alumno pueda diseñar y utilizar estructuras dinámicas de datos y algoritmos básicos de ordenación. El contenido por temas de la asignatura es el siguiente: Tema No 1: Funciones: En este tema se estudia el paso de diferentes tipos de parámetros a una función: tipo array, tipo estructura y tipo puntero; las funciones que retornan punteros; los argumentos en la línea de órdenes; la redirección de la entrada y la salida; las funciones recursivas y las funciones predefinidas de C. Tema No 2: Funciones estándar de E / S: En este tema se estudia la manipulación de ficheros en el disco, la apertura y cierre de ficheros, la detección de errores, los diferentes tipos de E / S, los comandos que controlan el buffer, los ficheros temporales y los comandos para el acceso aleatorio. Tema No 3: El preprocesador de C: En este tema se estudia las macros y directrices, la compilación condicional y la utilización de ficheros de cabecera. Tema No 4: Estructuras dinámicas de datos y ordenación: En este tema se estudian las listas lineales y sus operaciones básicas; las pilas, colas, listas circulares y listas doblemente enlazadas; los árboles binarios de búsqueda, los árboles binarios perfectamente equilibrados, la recursividad y la clasificación de datos; los algoritmos de búsqueda de datos; la ordenación de ficheros en disco; y los algoritmos hash. La importancia de esta asignatura en Algoritmos y Estructuras de Datos, se basa en que aporta los conocimientos de programación en un nivel más complejo para que el alumno sea capaz de poder enfrentar programas con un alto nivel de estructuración y funcionalidad.

Departamento de Computación UNAN - León

Page 331: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 15 de 15

Asignaturas consecuentes de AED La asignatura Algoritmos y Estructuras de Datos, establece las bases para que el estudiante esté en capacidad de cursar asignaturas posteriores. Algunas de esas asignaturas son por ejemplo, Diseño de Compiladores, Sistemas Operativos I y II y Base de Datos II.

Departamento de Computación UNAN - León

Page 332: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 16 de 16

4 METODOLOGÍA DIDÁCTICA Y MATERIAL DIDÁCTICO UTILIZADO

Podemos dividir la metodología didáctica y el material didáctico utilizado, de acuerdo a la clase teórica ya la clase práctica: METODOLOGÍA DIDÁCTICA Clase teórica: Para impartir los temas teóricos de esta asignatura, el método principal consiste en las lecciones magistrales, en las cuales se planificarán los apartados a desarrollar por medio de clases teóricas de dos horas de duración como máximo. La clase teórica es dialogada y los alumnos participan dando opiniones o pasando a la pizarra a resolver cuestiones. En estas clases teóricas, también se realizarán ejercicios prácticos relacionados con el tema teórico para una mejor comprensión del estudiante. De igual manera, se asignarán tareas grupales, que los estudiantes podrán resolver en el aula de clases o en horas extras de la clase, según lo indique el profesor. Clase práctica: La duración de cada clase práctica es de dos horas reloj. Para impartir las clases prácticas de esta asignatura, el método principal consiste en una exposición de la práctica a realizar, que tardará aproximadamente 45 minutos. En esta exposición, el profesor de la práctica explica todo lo relacionado con la realización de la práctica: objetivos, desarrollo, relación de la práctica actual con las prácticas anteriores (si las hubiera), funcionamiento, elementos software a utilizar, duración y fecha límite de entrega, etc. Durante la exposición del profesor, los alumnos pueden preguntar sobre cualquier aspecto relacionado con la realización de la práctica. Una vez que culmina la exposición, los alumnos comienzan a trabajar en el desarrollo de la práctica, pudiendo consultar al profesor cuando tengan alguna duda o inquietud. Cabe aclarar que, la exposición de la práctica por parte del profesor, se hará únicamente cuando se inice una nueva práctica. Las semanas de realización de la práctica, el profesor responderá dudas y hará aclaraciones sobre algún aspecto relevante de la práctica.

Departamento de Computación UNAN - León

Page 333: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 17 de 17

MATERIAL DIDÁCTICO A UTILIZAR Clase práctica: Con respeto al material didáctico, se usará retro proyector para proyectar las transparencias de cada tema, usando la pizarra cuando sea necesario ahondar en detalles acerca de algún gráfico o tabla. El material de estudio será las transparencias de la clase más documentación adicional (libros, folletos, tutoriales, etc). Dicho material se podrá adquirir de la página Web de la asignatura o directamente con el profesor o con la secretaria del departamento. Clase práctica: Con respecto al material didáctico de la clase práctica, se usará retroproyector para proyectar las transaparencias de la práctica. Se usará la pizarra para explicar con más detalle alguna parte de la práctica que lo requiera, o hacer alguna simulación del funcionamiento o desarrollo de la práctica. La clase práctica se lleva a cabo en los ordenadores de los laboratorios del Departamento. De acuerdo a la cantidad de estudiantes inscritos en el curso, cada ordenador podrá ser usado por uno o dos estudiantes cómo máximo. El software a utilizar estará instalado en los ordenadores, y también lo tendrá a disposición el profesor de la práctica, o en el sitio web o ftp de la asignatura. El alumno podrá también hacer uso de la bibliografía existente en el Departamento con el control respectivo.

Departamento de Computación UNAN - León

Page 334: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 18 de 18

5 PROCESO DE EVALUACIÓN La asignatura de Algoritmos y Estructuras de Datos, está compuesta por clases teóricas y prácticas de laboratorios. Durante el semestre se realizan 2 evaluaciones parciales y por último un examen final o semestral. Las calificaciones obtenidas en las 2 evaluaciones parciales equivalen al 60% de la nota final, luego a esto se suma el 40% de la calificación obtenida en el examen final para obtener el 100% de la nota final de todo el curso. Una explicación gráfica del proceso de evaluación se puede ver en la Tabla 5.1

Tabla 5.1 Proceso de Evaluación

1Ex_Par 2Ex_Par Ex_Sem Nota_Final Ex_Teor 80 80 100 Ev_Lab 30 30 Total 100 100 100 Porcentaje 30% 30% 40% 100%

Otra manera de ver esto es siguiendo la siguiente fórmula: Nota_Final = ( ( 1Ex_Par + 2Ex_Par ) / 2 * ( 0.6 ) ) + ( Ex_Sem * 0.4 )

Departamento de Computación UNAN - León

Page 335: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 19 de 19

TTEEMMPPOORRIIZZAACCIIÓÓNN

Departamento de Computación UNAN - León

Page 336: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 20 de 20

6 TEMPORIZACIÓN La asignatura Algoritmos y Estructuras de Datos, se imparte en el quinto semestre (primer semestre de tercer año) de la titulación Ingeniería en Sistemas de Información – ISI - ofrecida por el Departamento de Computación de la UNAN León. Cada semestre consta de 16 semanas lectivas. La asignatura consta de 4 horas semanales (2 de teoría y 2 de prácticas de laboratorio), resultando 32 horas teóricas y 32 horas prácticas para un total de 64 horas totales. Si tomamos en cuenta los días festivos y las semanas de realización de exámenes, la cantidad de semanas reales por semestre se reduce a 14, obteniendo de esta manera 28 horas de teoría y 28 horas de laboratorio respectivamente. Hay que recordar que cada sesión de clase teórica dura 2 horas reloj, así que por semana hay 1 sesión teórica de clase. La sesión del laboratorio también tiene una duración de 2 horas reloj, por lo que cada semana solamente hay una sesión de laboratorio. Una descripción general de la temporización del contenido teórico se muestra en la Tabla 6.1.

Tabla 6.1 Temporización general. Tema No

Nombre del Tema Duración del tema (en semanas)

Semana

0 Presentación de la asignatura. 1 1

1 Introducción a los Algoritmos. 3 2 3 4

2 Estructuras dinámicas de datos. 7

5 6 7 8 9

10 11

3 Algoritmos de ordenación y búsqueda. 3 12 13 14

Total: 14 14

Departamento de Computación UNAN - León

Page 337: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 21 de 21

Una temporización más detallada de la parte teórica se muestra en laTabla 6.2

Tabla 6.2 Temporización detallada.

Semana Tema No

Clase No

Cant. Horas

Tema Contenido del tema

1 0 1 2 Presentación de la asignatura

-Presentación de la asignatura

2 1 2 4 Introducción a los Algoritmos

-Algoritmos Definición de Algoritmo ¿Qué es un algoritmo? Clasificación de algoritmos Tipos de Algoritmos Lenguajes Algorítmicos

3 1 3 6 Introducción a los Algoritmos.

-Algoritmos Métodología para la solución de problemas por medio de computadora El Pseudocódigo Problema y ejemplar de un problema Problemas Secuenciales Problemas Condicionales Problemas Selectivos Simples Problemas Selectivos compuestos Problemas (Hacer para) Ciclos con un número indeterminado de iteraciones (Hacer-Mientras, Repetir-Hasta)

4 1 4 8 Introducción a los Algoritmos.

-Algoritmos El cálculo del máximo común divisor Algoritmos Numéricos

5 2 5 10 Estructuras dinámicas de datos.

-Introducción -Asignación dinamica de memoria -Listas lineales -Operaciones básicas Inserción de un elemento al comienzo de la lista Inserción de un elemento en general

6 2 6 12 Estructuras dinámicas de datos.

Borrar un elemento de la lista Recorrido de una lista cuyo primer elemento está apuntado por p Buscar en la lista un elemento con un valor x

Departamento de Computación UNAN - León

Page 338: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 22 de 22

7 2 7 14 Estructuras dinámicas de datos.

-Pilas, colas y listas doblemente enlazadas Pilas Pilas sin usar listas lineales

8 2 8 16 Estructuras dinámicas de datos.

Pilas usando listas lineales Colas

9 2 9 18 Estructuras dinámicas de datos.

Listas Circulares Listas doblemente enlazadas

10 2 10 20 Estructuras dinámicas de datos.

-Arboles Arboles binarios Recorrido de árboles binarios

11

2

11

22

Estructuras dinámicas de datos.

-Arboles binarios de búsqueda Borrado en árboles -Arboles binarios perfectamente equilibrados.

12

3

12

24

Algoritmos de ordenación y búsqueda.

-Introducción -Recursividad Ordenación de datos Burbuja

13

3

13 26 Algoritmos de ordenación y búsqueda.

Inserción QuickSort

14 3 14 28 Algoritmos de ordenación y búsqueda.

-Búsqueda de datos Búsqueda Secuencial Búsqueda Binaria

Departamento de Computación UNAN - León

Page 339: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 23 de 23

DDEESSAARRRROOLLLLOO DDEELL TTEEMMAARRIIOO

Departamento de Computación UNAN - León

Page 340: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 24 de 24

7 DESARROLLO DEL TEMARIO En esta sección se desarrollan los temas a impartir en Algoritmos y Estructuras de Datos. Se comienza a partir del tema uno, donde se refleja la importancia de saber gestionar la información, y luego se prosigue con el desarrollo de los demás temas.

7.1 Presentación de la Asignatura

TEMA N° 0

OBJETIVOS:

Dar a conocer al estudiante los aspectos relacionados a la docencia en general y horario de tutorías.

Explicar los objetivos generales de la asignatura, el temario y su distribución temporal, así como las relaciones de la misma con la carrera profesional de la titulación.

Exponer el método de enseñanza que se va a seguir durante el curso, los criterios de evaluación y la bibliografía necesaria.

Brindar detalles del modo de acceso a la documentación preparada por el profesor para la impartición de la asignatura.

CONTENIDO

Documento de presentación de la asignatura al alumno. Ver documento en la siguiente página.

Información sobre la organización de los grupos del laboratorio.

Acerca de las prácticas de Laboratorios: Todos los alumnos deben formar parte de un grupo para trabajar en el laboratorio; en total son 3 grupos, el horario de cada grupo se establecerá según la dirección del Departamento de Computación, y en ese momento se usará el documento de presentación del laboratorio en donde se le brindará todos los datos necesarios para la realización de éste. Dicho documento estará disponible en la página web del profesor y en la secretaría del Departamento de Computación. Se aclara que este documento estará presente en el proyecto en la sección de “Prácticas de Laboratorio”.

DURACIÓN: 2 HORAS.

Departamento de Computación UNAN - León

Page 341: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 25 de 25

OBJETIVOS DE LA ASIGNATURA

• Explicar las técnicas adecuadas para la construcción de pseudocódigos que den respuesta a un problema planteado.

• Conocer las diferentes formas de evaluar la eficiencia de los algoritmos.

• Dar a conocer las diferentes estructuras lineales y la forma en cómo

funcionan.

• Exponer las principales técnicas de ordenación y búsqueda, y la utilidad de éstas en la solución de problemas con un número elevado de datos.

• Explicar la técnica de la recursividad y su uso en aplicaciones de diferentes

tipos.

Departamento de Computación UNAN - León

Page 342: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 26 de 26

ASIGNATURA: ALGORITMOS Y ESTRUCTURAS DE DATOS CURSO 2004 DEPARTAMENTO: COMPUTACIÓN – DC TITULACIÓN: INGENIERIA EN SISTEMAS DE INFORMACIÓN - ISI AÑO: III SEMESTRE: QUINTO PROFESOR: ALDO RENÉ MARTÍNEZ.

TEMARIO DE TEORÍA:

Tema 1: Introducción a los Algoritmos

• Definición de Algoritmo

• ¿Qué es un algoritmo?

• Clasificación de algoritmos

• Tipos de Algoritmos

• Lenguajes Algorítmicos

• Métodología para la solución de problemas por medio de computadora

• El Pseudocódigo

• Problema y ejemplar de un problema

• Problemas Secuenciales

• Problemas Condicionales

o Problemas Selectivos Simples

o Problemas Selectivos Compuestos

• Problemas (Hacer para)

• Ciclos con un número indeterminado de iteraciones (Hacer-Mientras, Repetir-Hasta)

• El cálculo del máximo común divisor

• Algoritmos Numéricos

Tema 2: Estructuras Dinámicas de Datos

• Introducción

• Asignación dinamica de memoria

• Listas lineales

o Operaciones básicas

Inserción de un elemento al comienzo de la lista

Inserción de un elemento en general

Borrar un elemento de la lista

Recorrido de una lista cuyo primer elemento está apuntado por p

Buscar en la lista un elemento con un valor x

Departamento de Computación UNAN - León

Page 343: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 27 de 27

• Pilas, colas y listas doblemente enlazadas

o Pilas

Pilas sin usar listas lineales

Pilas usando listas lineales

o Colas

o Listas Circulares

o Listas doblemente enlazadas

• Arboles

o Arboles binarios

o Recorrido de árboles binarios

• Arboles binarios de búsqueda

• Borrado en árboles

• Arboles binarios perfectamente equilibrados

Tema 3: Algoritmos de ordenación y búsqueda.

• Introducción

• Recursividad

• Ordenación de datos

o Burbuja

o Inserción

o QuickSort

• Búsqueda de datos

o Búsqueda Secuencial

o Búsqueda Binaria.

MATERIAL DE ESTUDIO:

Transparencias y material de apoyo: http://www.isi.unanleon.edu.ni/~aldo/

Bibliografía (Teoría)

Ceballos, Fco Javier. 1997. Enciclopedia del Lenguaje C. Alfaomega RAMA.

Ceballos, Fco Javier. 1995. Curso de Programación C/C++. RAMA.

Deitel y Deitel. 1999. Cómo programar en C/C++. 1 Edición. Prentice Hall. Joyanes, Luis. 1999. "Metodología de la programación" Mc Graw Hill.

Wirth, Niklaus. 1994. Algoritmos y Estructuras de Datos. 1a Edición. Prentice Hall.

Departamento de Computación UNAN - León

Page 344: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 28 de 28

TUTORÍAS:

Despacho: Edificio de Ciencias - Segunda planta

Horario: Lunes 16:00 - 18:00

Martes 16:00 - 18:00

Correo: [email protected]

EVALUACIÓN DE LA ASIGNATURA:

Requisitos mínimos: Aprobar el examen de la asignatura y superar el laboratorio.

Cálculo de la nota final:

70% Examen 30% Laboratorio

Departamento de Computación UNAN - León

Page 345: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 29 de 29

IINNTTRROODDUUCCCCIIÓÓNN AA LLOOSS

AALLGGOORRIITTMMOOSS

Departamento de Computación UNAN - León

Page 346: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 30 de 30

7.2 Introducción a los Algoritmos

Título del Tema 1: Introducción a los Algoritmos

Objetivos: • Comprender qué es un algoritmo y cuál es su utilidad en la

programación de computadoras.

• Comprender cómo se clasifican los algoritmos.

• Dar a conocer el método para resolver problemas por medio de un ordenador.

Contenido: • Definición de algoritmo.

• Qué es un algoritmo.

• Clasificación de algoritmos.

• Tipos de Algoritmos

• Lenguajes Algorítmicos.

• Metodología para la solución de problemas por medio de computadora.

• El Pseudocódigo.

• Problema y ejemplar de un problema

• Problemas Secuenciales

• Problemas Condicionales

o Problemas Selectivos Simples

o Problemas Selectivos Compuestos

• Problemas (Hacer para)

• Ciclos con un número indeterminado de iteraciones (Hacer-Mientras, Repetir-Hasta)

• El cálculo del máximo común divisor

• Algoritmos Numéricos

Duración: 6 horas

Departamento de Computación UNAN - León

Page 347: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 31 de 31

Bibliografía básica:

• Wirth, Niklaus. 1994. Algoritmos y Estructuras de Datos. 1a Edición. Prentice Hall.

• Joyanes Aguilar Luis. 2001. "Metodología de la programación". McGraw Hill.

• Joyanes Aguilar Luis; 2002. "Problemas de metodología de la programación". McGraw Hill

Departamento de Computación UNAN - León

Page 348: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 32 de 32

7.2.1 Definición de Algoritmo La palabra algoritmo se deriva de la traducción al latín de la palabra árabe alkhowarizmi, nombre de un matemático y astrónomo árabe que escribió un tratado sobre manipulación de números y ecuaciones en el siglo IX. Un algoritmo es una serie de pasos organizados que describe el proceso que se debe seguir, para dar solución a un problema específico.

7.2.2 ¿Qué es un algoritmo? El diccionario de Petit Robert define Algoritmo como “Conjunto de reglas operacionales inherentes a un cómputo”. Se trata de un método sistemático susceptible de ser realizado mecánicamente, para resolver un problema dado. Siempre que se plantea un problema hay que plantearse qué algoritmo utilizar. La respuesta a esto depende de numerosos factores como son, el tamaño del problema, el modo en que está planteado, y la potencia del equipo disponible para su solución. De forma más sencilla, podemos decir que un algoritmo es un conjunto de pasos que nos permite obtener un dato. Además debe cumplir estas condiciones:

• Finitud: el algoritmo debe acabar tras un número finito de pasos. Es más, es casi fundamental que sea en un número razonable de pasos.

• Definibilidad: el algoritmo debe definirse de forma precisa para cada

paso, es decir, hay que evitar toda ambigüedad al definir cada paso. Puesto que el lenguaje humano es impreciso, los algoritmos se expresan mediante un lenguaje formal, ya sea matemático o de programación para un computador.

• Entrada: el algoritmo tendrá cero o más entradas, es decir, cantidades

dadas antes de empezar el algoritmo. Estas cantidades pertenecen además a conjuntos especificados de objetos. Por ejemplo, pueden ser cadenas de caracteres, enteros, naturales, fraccionarios, etc. Se trata siempre de cantidades representativas del mundo real, expresadas de tal forma que, sean aptas para su interpretación por el computador.

• Salida: el algoritmo tiene una o más salidas, en relación con las

entradas.

• Efectividad: se entiende por esto que una persona sea capaz de realizar el algoritmo de modo exacto y sin ayuda de una máquina en un lapso de tiempo finito.

Departamento de Computación UNAN - León

Page 349: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 33 de 33

A menudo los algoritmos requieren una organización bastante compleja de los datos, y es por tanto necesario un estudio previo de las estructuras de datos fundamentales. Dichas estructuras pueden implementarse de diferentes maneras, y es más, existen algoritmos para implementar dichas estructuras. El uso de estructuras de datos adecuadas pueden hacer trivial el diseño de un algoritmo, o un algoritmo muy complejo puede usar estructuras de datos muy simples. Uno de los algoritmos más antiguos conocidos es el algoritmo de Euclides. El término algoritmo proviene del matemático Muhammad ibn Musa al-Khwarizmi, que vivió aproximadamente entre los años 780 y 850 d.c. en la actual nación Iraní. Él describió la realización de operaciones elementales en el sistema de numeración decimal. De al-Khwarizmi se obtuvo la derivación algoritmo.

7.2.3 Clasificación de algoritmos

• Algoritmo determinista: en cada paso del algoritmo se determina de forma única el siguiente paso.

• Algoritmo no determinista: deben decidir en cada paso de la ejecución

entre varias alternativas y agotarlas todas antes de encontrar la solución. Todo algoritmo tiene una serie de características, entre otras que requiere una serie de recursos, algo que es fundamental considerar a la hora de implementarlos en una máquina. Estos recursos son principalmente:

• El tiempo: período transcurrido entre el inicio y la finalización del algoritmo.

• La memoria: la cantidad (la medida varía según la máquina) que necesita el algoritmo para su ejecución. Obviamente, la capacidad y el diseño de la máquina pueden afectar al diseño del algoritmo.

En general, la mayoría de los problemas tienen un parámetro de entrada que es el número de datos que hay que tratar, esto es, N. La cantidad de recursos del algoritmo es tratada como una función de N. De esta manera puede establecerse un tiempo de ejecución del algoritmo que suele ser proporcional a una de las siguientes funciones:

• 1: Tiempo de ejecución constante. Significa que la mayoría de las instrucciones se ejecutan una vez o muy pocas.

• logN: Tiempo de ejecución logarítmico. Se puede considerar como una gran

constante. La base del logaritmo (en informática la más común es la base 2) cambia la constante, pero no demasiado. El programa es más lento cuanto más crezca N, pero es inapreciable, pues logN no se duplica hasta que N llegue a N2.

Departamento de Computación UNAN - León

Page 350: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 34 de 34

• N: Tiempo de ejecución lineal. Un caso en el que N valga 40, tardará el doble que otro en que N valga 20. Un ejemplo sería un algoritmo que lee N números enteros y devuelve la media aritmética.

• N·logN: El tiempo de ejecución es N·logN. Es común encontrarlo en

algoritmos como Quick Sort y otros del estilo divide y vencerás. Si N se duplica, el tiempo de ejecución es ligeramente mayor del doble.

• N2: Tiempo de ejecución cuadrático. Suele ser habitual cuando se tratan

pares de elementos de datos, como por ejemplo un bucle anidado doble. Si N se duplica, el tiempo de ejecución aumenta cuatro veces. El peor caso de entrada del algoritmo Quick Sort se ejecuta en este tiempo.

• N3: Tiempo de ejecución cúbico. Como ejemplo se puede dar el de un bucle

anidado triple. Si N se duplica, el tiempo de ejecución se multiplica por ocho.

• 2N: Tiempo de ejecución exponencial. No suelen ser muy útiles en la práctica por el elevadísimo tiempo de ejecución. El problema de la mochila resuelto por un algoritmo de fuerza bruta -simple vuelta atrás- es un ejemplo. Si N se duplica, el tiempo de ejecución se eleva al cuadrado.

• Algoritmos polinomiales: aquellos que son proporcionales a Nk. Son en

general factibles.

• Algoritmos exponenciales: aquellos que son proporcionales a kN. En general son infactibles salvo un tamaño de entrada muy reducido.

Notación O-grande En general, el tiempo de ejecución es proporcional, esto es, multiplica por una constante a alguno de los tiempos de ejecución anteriormente propuestos, además de la suma de algunos términos más pequeños. Así, un algoritmo cuyo tiempo de ejecución sea T = 3N2 + 6N se puede considerar proporcional a N2. En este caso se diría que el algoritmo es del orden de N2, y se escribe O(N2) Los grafos definidos por matriz de adyacencia ocupan un espacio O(N2), siendo N el número de vértices de éste. La notación O-grande ignora los factores constantes, es decir, ignora si se hace una mejor o peor implementación del algoritmo, además de ser independiente de los datos de entrada del algoritmo. Es decir, la utilidad de aplicar esta notación a un algoritmo es encontrar un límite superior del tiempo de ejecución, es decir, el peor caso. A veces ocurre que no hay que prestar demasiada atención a esto. Conviene diferenciar entre el peor caso y el esperado. Por ejemplo, el tiempo de ejecución del algoritmo Quick Sort es de O(N2). Sin embargo, en la práctica este caso no se da casi nunca y la mayoría de los casos son proporcionales a N·logN. Es por ello que se utiliza esta última expresión para este método de ordenación.

Departamento de Computación UNAN - León

Page 351: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 35 de 35

Una definición rigurosa de esta notación es la siguiente: Una función g(N) pertenece a O(f(N)) si y sólo si existen las constantes c0 y N0 tales que: |g(N)| <= |c0 - f(N)|, para todo N >= N0.

7.2.4 Tipos de Algoritmos

• Cualitativos: Son aquellos en los que se describen los pasos utilizando palabras.

• Cuantitativos: Son aquellos en los que se utilizan cálculos numéricos para

definir los pasos del proceso.

7.2.5 Lenguajes Algorítmicos Es una serie de símbolos y reglas que se utilizan para describir de manera explícita un proceso. Tipos de Lenguajes Algorítmicos

• Gráficos: Es la representación gráfica de las operaciones que realiza un algoritmo (diagrama de flujo).

• No Gráficos: Representa en forma descriptiva las operaciones que debe

realizar un algoritmo (pseudocodigo).

7.2.6 Metodología para la solución de problemas por medio de computadora

• Definición del Problema

Esta fase está dada por el enunciado del problema, el cual requiere una definición clara y precisa. Es importante que se conozca lo que se desea que realice la computadora; mientras esto no se conozca del todo no tiene mucho caso continuar con la siguiente etapa.

• Análisis del Problema

Una vez que se ha comprendido lo que se desea de la computadora, es necesario definir: Los datos de entrada.

Departamento de Computación UNAN - León

Page 352: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 36 de 36

Cual es la información que se desea producir (salida) Los métodos y fórmulas que se necesitan para procesar los datos.

Una recomendación muy práctica es el que nos pongamos en el lugar de la computadora, y analicemos qué es lo que necesitamos que nos ordenen y en qué secuencia para producir los resultados esperados.

• Diseño del Algoritmo

Las características de un buen algoritmo son: Debe tener un punto particular de inicio.

Debe ser definido, no debe permitir dobles interpretaciones.

Debe ser general, es decir, soportar la mayoría de las variantes que se

puedan presentar en la definición del problema. Debe ser finito en tamaño y tiempo de ejecución.

• Codificación

La codificación es la operación de escribir la solución del problema (de acuerdo a la lógica del diagrama de flujo o pseudocodigo), en una serie de instrucciones detalladas, en un código reconocible por la computadora. La serie de instrucciones detalladas se le conoce como código fuente, el cual se escribe en un lenguaje de programación o lenguaje de alto nivel.

• Prueba y Depuración

Los errores humanos dentro de la programación de computadoras son muchos y aumentan considerablemente con la complejidad del problema. El proceso de identificar y eliminar errores, para dar paso a una solución sin errores se le llama depuración. La depuración o prueba resulta una tarea tan creativa como el mismo desarrollo de la solución, por ello se debe considerar con el mismo interés y entusiasmo. Resulta conveniente observar los siguientes principios al realizar una depuración, ya que de este trabajo depende el éxito de nuestra solución.

Departamento de Computación UNAN - León

Page 353: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 37 de 37

• Documentación

Es la guía o comunicación escrita en sus variadas formas, ya sea en enunciados, procedimientos, dibujos o diagramas. A menudo un programa escrito por una persona, es usado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento). La documentación se divide en tres partes: Documentación Interna Documentación Externa Manual del usuario

Documentación Interna: Son los comentarios o mensaje que se añaden al código fuente para hacer mas claro el entendimiento de un proceso. Documentación Externa: Se define en un documento escrito, los siguientes puntos: Descripción del Problema Nombre del Autor Algoritmo (diagrama de flujo o pseudocodigo) Diccionario de Datos Código Fuente (programa)

Manual del Usuario: Describe paso a paso la manera como funciona el programa, con el fin de que el usuario obtenga el resultado deseado.

7.2.7 El Pseudocódigo El pseudocódigo es una herramienta algorítmica que permite escribir pseudoprogramas (una imitación de un programa real) utilizando un lenguaje de pseudoprogramación que es una imitación de los lenguajes de programación de alto nivel. Así, un pseudocódigo es una combinación de símbolos (+, -, *, /, %, >, >=, <, <=, !=, ==, y, o, no), términos (Leer, Imprimir, Abrir, Cerrar, Hacer...Mientras, Mientras...Hacer, Para...Mientras, etc) y otras características comúnmente utilizadas en uno o más lenguajes de alto nivel. No existen reglas que determinen qué es o no es un pseudocódigo, sino que varía de un programador a otro. El objetivo del pseudocódigo es permitir al programador centrarse en los aspectos lógicos de la solución evitando las reglas de sintáxis de un lenguaje de programación. Posteriormente el pseudocódigo debe ser traducido a programa usando un lenguaje de programación de alto nivel como Java, C++, C, etc.

Departamento de Computación UNAN - León

Page 354: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 38 de 38

Ejemplo: Diseñe un algoritmo para preparar una limonada. Solución: INICIO Llenar una jarra con un litro de agua Echar el jugo de tres limones Echar cuatro cucharadas de azúcar Remover el agua hasta disolver completamente el azúcar FIN Ejemplo: Diseñe un algoritmo que permita hallar la suma y el promedio de tres números. INICIO LEER numero1, numero2, numero3 suma = numero1 + numero2 + numero3 promedio = suma / 3 IMPRIMIR suma, promedio FIN Algoritmo Multiplicación Rusa Si procedemos de una cultura latina, es probable que se comience multiplicando cada cifra del multiplicador, de derecha a izquierda, por todo el multiplicando, desplazando hacia la izquierda los resultados sucesivos. Se terminara el cálculo mediante una simple suma. Aquí, se ha utilizado el algoritmo clásico. La Multiplicación Rusa se usa para multiplicar dos Números enteros positivos (problema de aritmética elemental). Escríbase el multiplicando y el multiplicador uno al lado del otro. Fórmese dos columnas, una debajo de cada operando, aplicando repetidamente la regla siguiente: hasta que el multiplicador valga 1: divídase por dos el multiplicador en curso sin tener en cuenta el posible resto y duplíquese el correspondiente multiplicando. Por ejemplo Multiplicar 19 por 45 se obtiene

45 19 22 38 11 76 5 152 2 304 1 608

Departamento de Computación UNAN - León

Page 355: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 39 de 39

Finalmente, marcar los números de la columna del multiplicando que corresponden a multiplicadores pares y sumar los números no marcados. En ese caso sería 19 + 76 + 152 + 608 = 855. Este método es usado por los circuitos electrónicos de muchos ordenadores, ya que como ha podido notar, sólo se necesita duplicar y dividir por 2. Al utilizar pseudocódigo, algunas veces se usarán las palabras comienzo y fin, y otras veces la palabra begin end o bien las llaves, pero para evitar la proliferación de estas instrucciones, podremos usar los sangrados a la derecha de los texto afectados. De igual manera, usaremos algunas veces la palabra devolver o retornar, las cuales señalan la terminación, en tiempo de ejecución de un procedimiento o una función; para este caso, indicará el valor devuelto por dicha función. Se usarán algunos operadores como , que indicará asignación; div, división entera, y mod el módulo o resto de la división. Además, algunos comentarios se colocan entre llaves. Veamos el Algoritmo de la multiplicación Rusa.

Función mrusa(A, B) Vector X, Y {inicialización de} X[1] A ; Y[1] B i 1 {construcción de las columnas} Mientras X{i] > 1 hacer

X[i+1] X[i] div 2 Y[I+1] Y[i]+ Y[i]

{Sumar los valores apropiados} prod 0 Mientras i > 0 hacer

Si impar (X[i ] ) entonces prod prod +Y[i] i i –1

devolver prod A continuación se presenta en Lenguaje C, una implementación del algoritmo de la multiplicación rusa. #include <stdio.h> #define N_MAX 200 /* Tamaño máximo de elementos */ /* Funciones prototipos */ void Inicializar ( int a[], int n ); // Inicializar el multiplicando y el multiplicador void LeerDatos ( int *pa, int *pb); int Multiplicar_R ( int multiplicando, int multiplicador ); void main() /* Función principal */

Departamento de Computación UNAN - León

Page 356: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 40 de 40

{ int multiplicando; int multiplicador; int r; // resultado de la multiplicacion printf ("\n\t BIENVENIDOS A LA MULTIPLICACION RUSA \n"); LeerDatos(&multiplicando, &multiplicador); r = Multiplicar_R ( multiplicando, multiplicador ); printf ("\n\n\t Resultado: %d \n", r); } // Fin del main /////////////////// Definición de funciones ////////////////////// /////////// Leer multiplicando y multiplicador /////////////////// void LeerDatos ( int *pa, int *pb ) { printf("\n\t Multiplicando: "); scanf ("%d", pa ); printf("\n\t Multiplicador: "); scanf ("%d", pb); } // Fin de LeerDatos() ////////////////// Inicializar los arreglos /////////////////////////////// void Inicializar ( int a[], int n) { int i; i = 0; for (i = 0; i < n; i++) a[i] = 0; // Inicializar a cero } // Fin de Inicializar() ////////////////////// Funcion Multiplicacion_Rusa ////////////////////////// int Multiplicar_R ( int multiplicando, int multiplicador ) { int a[N_MAX]; // Valores intermedios del multiplicador int b[N_MAX]; // Valores intermedios del multiplicando int i, j; int r; // Resultado de la multiplicacion // Inicializar los arreglos adecuadamente Inicializar ( a, N_MAX ); Inicializar ( b, N_MAX ); // Proceso

Departamento de Computación UNAN - León

Page 357: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 41 de 41

i = 0; // Poner en la primera posición de los arreglos el multiplicador y el // multiplicando a[i] = multiplicador; b[i] = multiplicando; // Llenar los valores de los arreglos adecuadamente while (a[i] > 1) { a[i + 1] = a[i] / 2; b[i + 1] = b[i] * 2; i++; } // Fin del while... j = 0; r = 0; while (j <= i) { if ( ( a[j] % 2 ) != 0 ) { // El elemento i-ésimo del multiplicador es impar r = r + b[j]; } j++; } // Fin del while return (r); } // Fin de Multiplicar_R()

Departamento de Computación UNAN - León

Page 358: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 42 de 42

7.2.8 Problema y ejemplar de un problema El algoritmo de la multiplicación rusa visto anteriormente, es para resolver cualquier producto de dos valores enteros no grandes, esto quiere decir que resuelve el problema de multiplicar dor valores enteros positivos, ejemplo (45,19). Esto es un ejemplar del problema. Por regla general diremos que un problema es una colección infinita de ejemplares. Tambien existen muchos problemas finitos. Normalmente un algoritmo deberá funcionar perfectamente para todo ejemplar del problema que se pretende solucionar. Para invalidar un algoritmo basta demostrar que para un ejemplar del problema, el algoritmo no funciona. Pero es muy difícil demostrar que un algoritmo es el correcto. Todo computador real tendrá un límite en el tamaño de los ejemplares que es capaz de resolver. Este límite no afecta al algoritmo (esto es otra diferencia entre algoritmo y programa). Es importante al definir un problema, especificar perfectamente su dominio de definición, es decir el conjunto de sus ejemplares. Por ejemplo el algoritmo mrusa no funciona si los enteros son negativos Ej: (-45, 19). Esto no invalida el algoritmo ya que el (-45, 19), no forma parte del ejemplar del problema.

Departamento de Computación UNAN - León

Page 359: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 43 de 43

7.2.9 Problemas Secuenciales Realizar el algoritmo de los siguientes problemas: 1) Suponga que un individuo desea invertir su capital en un banco, y desea saber cuánto dinero ganará después de un mes si el banco paga a razón de 2% mensual. Solución: Inicio Leer cap_inv gan = cap_inv * 0.02 Imprimir gan Fin 2) Un vendedor recibe un sueldo base más un 10% extra por comisión de sus ventas. El vendedor desea saber cuánto dinero obtendrá por concepto de comisiones por las tres ventas que realiza en el mes y el total que recibirá en el mes tomando en cuenta su sueldo base y comisiones. Solución: Inicio Leer sb, v1, v2, v3 tot_vta = v1 + v2 + v3 com = tot_vta * 0.10 tpag = sb + com Imprimir tpag, com Fin 3) Una tienda ofrece un descuento del 15% sobre el total de la compra, y un cliente desea saber cuánto deberá pagar finalmente por su compra. Solución: Inicio Leer tc d = tc * 0.15 tp = tc - d Imprimir tp Fin 4) Un alumno desea saber cuál será su calificación final en la materia de Algoritmos. Dicha calificación se compone de los siguientes porcentajes: 55% del promedio de sus tres calificaciones parciales. 30% de la calificación del examen final.

Departamento de Computación UNAN - León

Page 360: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 44 de 44

15% de la calificación de un trabajo final. Solución: Inicio Leer c1, c2, c3, ef, tf prom = (c1 + c2 + c3)/3 ppar = prom * 0.55 pef = ef * 0.30 ptf = tf * 0.15 cf = ppar + pef + ptf Imprimir cf Fin

7.2.10 Problemas Condicionales Realizar el algoritmo de los siguientes problemas: Problemas Selectivos Simples 1) Un hombre desea saber cuánto dinero se genera por concepto de intereses, sobre la cantidad que tiene en inversión en el banco. Él decidirá reinvertir los intereses siempre y cuando éstos excedan a $7000, y en ese caso desea saber cuanto dinero tendrá finalmente en su cuenta. Solución: Inicio Leer p_int, cap int = cap * p_int si int > 7000 entonces capf = cap + int fin-si Imprimir capf Fin 2) Determinar si un alumno aprueba a reprueba un curso, sabiendo que aprobará si su promedio de tres calificaciones es mayor o igual a 70; reprueba en caso contrario. Solución:

Departamento de Computación UNAN - León

Page 361: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 45 de 45

Inicio Leer calif1, calif2, calif3 prom = (calif1 + calif2 + calif3)/3 Si prom >= 70 entonces Imprimir “alumno aprobado” si no Imprimir “alumno reprobado” Fin-si Fin 3) En un almacén se hace un 20% de descuento a los clientes cuya compra supere los $1000 ¿Cuál será la cantidad que pagará una persona por su compra? Solución: Inicio Leer compra Si compra > 1000 entonces desc = compra * 0.20 si no desc = 0 fin-si tot_pag = compra - desc imprimir tot_pag Fin. 4) Un obrero necesita calcular su salario semanal, el cual se obtiene de la siguiente manera: Solución: Si trabaja 40 horas o menos se le paga $16 por hora. Si trabaja más de 40 horas, se le paga $16 por cada una de las primeras 40 horas y $20 por cada hora extra. Inicio Leer ht Si ht > 40 entonces he = ht - 40 ss = he * 20 + 40 * 16 si no ss = ht * 16 Fin-si Imprimir ss Fin

Departamento de Computación UNAN - León

Page 362: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 46 de 46

Problemas Selectivos Compuestos Realizar el algoritmo de los siguientes problemas: 1) Leer 2 números y; si son iguales que los multiplique; si el primero es mayor que el segundo que los reste y si no que los sume. Solución: Inicio Leer num1, num2 si num1 = num2 entonces resul = num1 * num2 si no si num1 > num2 entonces resul = num1 - num2 si no resul = num1 + num2 fin-si fin-si Fin 2) Leer tres números diferentes e imprimir el número mayor de los tres. Solución: Inicio Leer num1, num2, num3 Si (num1 > num2) and (num1 > num3) entonces mayor = num1 si no Si (num2 > num1) and (num2 > num3) entonces mayor = num2 si no mayor = num3 fin-si fin-si Imprimir mayor Fin

Departamento de Computación UNAN - León

Page 363: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 47 de 47

3) Determinar la cantidad de dinero que recibirá un trabajador por concepto de las horas extras trabajadas en una empresa, sabiendo que cuando las horas de trabajo exceden de 40, el resto se consideran horas extras y que éstas se pagan al doble de una hora normal cuando no exceden de 8; si las horas extras exceden de 8 se pagan las primeras 8 al doble de lo que se pagan las horas normales y el resto al triple. Solución: Inicio Leer ht, pph Si ht < = 40 entonces tp = ht * pph si no he = ht - 40 Si he < = 8 entonces pe = he * pph * 2 si no pd = 8 * pph * 2 pt = (he - 8) * pph * 3 pe = pd + pt fin-si tp = 40 * pph + pe fin-si Imprimir tp fin

7.2.11 Problemas ( Hacer para ) Realizar el algoritmo de los siguientes problemas: 1) Calcular el promedio de un alumno que tiene 7 calificaciones en la materia de Diseño Estructurado de Algoritmos. Solución: Inicio Sum=0 Leer Nom Hacer para c = 1 a 7 Leer calif Sum = sum + calif Fin-para prom = sum /7 Imprimir prom Fin.

Departamento de Computación UNAN - León

Page 364: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 48 de 48

2) Leer 10 números y obtener su cubo y su cuarta. Solución: Inicio Hacer para n = 1 a 10 Leer num

cubo = num * num * num cuarta = cubo * num Imprimir cubo, cuarta

Fin-para Fin. 3) Leer 10 números e imprimir solamente los números positivos Solución: Inicio Hacer para n = 1 a 10 Leer num Si num > 0 entonces Imprimir num fin-si Fin-para Fin. 4) Leer 20 números e imprimir cuántos son positivos, cuántos negativos y cuántos neutros. Solución: Inicio cn = 0 cp = 0 cneg = 0 Hacer para x = 1 a 20 Leer num Sin num = 0 entonces cn = cn + 1 si no Si num > 0 entonces cp = cp + 1 si no cneg = cneg + 1 Fin-si Fin-si Fin-para Imprimir cn, cp, cneg Fin.

Departamento de Computación UNAN - León

Page 365: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 49 de 49

7.2.12 Ciclos con un número indeterminado de iteraciones Son aquellos en que el número de iteraciones no se conoce con exactitud, ya que está dado en función de un dato dentro del programa. Hacer-Mientras: Esta es una estructura que repetira un proceso durante “N” veces, donde “N” puede ser fijo o variable. Para esto, la instrucción se vale de una condición que es la que debe cumplirse para que se siga ejecutando. Cuando la condición ya no se cumple, entonces ya no se ejecuta el proceso. La forma de esta estructura es la siguiente:

Repetir-Hasta: Esta es una estructura similar en algunas características, a la anterior. Repite un proceso una cantidad de veces, pero a diferencia del Hacer-Mientras, el Repetir-Hasta lo hace hasta que la condición se cumple y no mientras, como en el Hacer-Mientras. Por otra parte, esta estructura permite realizar el proceso cuando menos una vez, ya que la condición se evalúa al final del proceso, mientras que en el Hacer-Mientras puede ser que nunca llegue a entrar si la condición no se cumple desde un principio. La forma de esta estructura es la siguiente:

Departamento de Computación UNAN - León

Page 366: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 50 de 50

7.2.13 El cálculo del máximo común divisor Sean n y m dos enteros positivos. El máximo común divisor de m y n, denotado mcd (m, n), es el mayor entero que divide exactamente m y n. Cuando mcd (m, n) = 1, m y n son primos entre sí. Por ejemplo, mcd (6, 15) = 3 y mcd (10, 21) = 1. Un algoritmo eficiente para calcular el máximo común divisor, es el algoritmo de Euclides. El algoritmo se muestra a continuación: función Euclides (m, n) mientras m > 0 hacer t n mod m n m m t devolver n Este algoritmo, emplea en el peor caso un tiempo del orden del logaritmo de sus argumentos. Números racionales Recuerde que un número racional es cualquier número que puede expresarse como el cociente de dos enteros. Así 1/2, 3/4, 2/3 y 2 (o sea 2/1) son números racionales, mientras que 2 y π no lo son. Una computadora por lo general, representa los números racionales mediante su aproximación decimal. Si se dan instrucciones a la computadora para imprimir 1/3, ésta responderá con 0.333333. Aunque es una buena aproximación (la diferencia entre 1/3 y 0.333333 sólo es una trimillonésima), no es exacta. Si se pregunta por el valor de 1/3 + 1/3, el resultado será 0.666666 (que es igual a 0.33333 + 0.333333), mientras que el resultado de imprimir 2/3 podría ser 0.666667. Esto podría significar que el resultado de la pregunta 1/3 + 1/3 == 2/3 ¡podría ser falso! En muchos casos, la aproximación decimal es muy buena, pero a veces no lo es. Por esto, es deseable implantar una representación de los números racionales para que pueda ejecutar la aritmética exacta. ¿Cómo puede representarse de forma exacta un número racional? Puesto que un número racional consiste en un numerador y un denominador, puede representarse un número racional mediante estructuras, como sigue: typedef struct { int numerador; int denominador; }racional; Luego, podríamos declarar un racional así: racional r,

Departamento de Computación UNAN - León

Page 367: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 51 de 51

Podría pensarse que se está listo ahora para definir la aritmética de números racionales, pero hay un problema importante. Supóngase que se definen dos números racionales r1 y r2 y que ses les da un valor. ¿Cómo puede comprobarse si dos números son iguales? Quizá podría querer programarse: if (r1.numerador == r2.numerador && r1.denominador == r2.denominador) ........ Es decir, si tanto los numeradores como los denominadores son iguales, los dos números racionales son iguales. Sin embargo, es posible que ambos numeradores y denominadores sean diferentes y, no obstante, ser iguales los números racionales. Por ejemplo, los números 1/2 y 2/4 son iguales, aunque tanto sus numeradores (1 y 2) como sus denominadores (2 y 4) son distintos. Por consiguiente, se necesita una nueva forma de probar la igualdad para nuestra representación. Bien, ¿por qué son iguales 1/2 y 2/4? La respuesta es que ambos representan el mismo racional. Uno entre dos y dos entre cuatro, son ambos, un medio. Para probar igualdad en números racionales debe transformárseles a fracciones reducidas. Una vez que se ha hecho, puede probarse la igualdad por medio de la simple comparación de numeradores y denominadores. Fracción reducida Se define una fracción reducida como un número racional para el que no existe entero que divida exactamente tanto al denominador como al numerador. Así, 1/2, 2/3 y 10/1, son fracciones reducidas, mientras que 4/8, 12/18 y 15/6 no lo son. En nuestro ejemplo, 2/4 se reduce a 1/2 de manera que los dos números racionales son iguales. Puede usarse el algoritmo de Euclides para reducir un número racional a una fracción reducida cuando el número está en la forma numerador / denominador. Este procedimiento puede esbosarse como sigue:

1. Sea a, el mayor y b, el menor entre el numerador y el denominador.

2. Divídase a entre b, para encontrar un cociente y un resto, q y r respectivamente (es decir, a = q * b + r).

3. Hágase a = b y b = r.

4. Repítase los pasos 2 y 3 hasta que b sea igual a 0.

5. Divida el numerador y el denominador por el valor de a.

Cómo ejemplo vamos a mostrar la secuencia de pasos, para representar 1032/1976 como fracción reducida.

Departamento de Computación UNAN - León

Page 368: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 52 de 52

paso 0 numerador = 1032 denominador = 1976 paso 1 a = 1976 , b = 1032 paso 2 a = 1976 , b = 1032 q = 1 r = 944 paso 3 a = 1032 , b = 944 pasos 4 y 2 a = 1032 , b = 944 q = 1 r = 88 paso 3 a = 944 , b = 88 pasos 4 y 2 a = 944 , b = 88 q = 10 r = 64 paso 3 a = 88 , b = 64 pasos 4 y 2 a = 88 , b = 64 q = 1 r = 24 paso 3 a = 64 , b = 24 pasos 4 y 2 a = 64 , b = 24 q = 2 r = 16 paso 3 a = 24 , b = 16 pasos 4 y 2 a = 24 , b = 16 q = 1 r = 8 paso 3 a = 16 , b = 8 pasos 4 y 2 a = 16 , b = 8 q = 2 r = 0 paso 3 a = 8 , b = 0 paso 5 1032/8 = 129 1976/8 = 247

El siguiente programa muestra la codificación del algoritmo de Euclides en lenguaje C. El programa consta de una declaración como la que sigue: typedef struct racional fraccion; struct racional { int numerador; int denominador; }; para manejar el número racional. La funcionalidad del programa se resume en: leer una fracción y validarla, llamar a la función ReducirFraccion() para la fracción leída, reducirla e imprimirla. Antes de cerrar el main(), nosotros liberamos la memoria asignada para los objetos de tipo fraccion, y verificamos si dicha liberación fue exitosa mediante la llamada a la función _CrtDumpMemoryLeaks(). El programa es el siguiente: /* euclides.c*/ /* Implementación del algoritmo de Euclides */ #include <stdio.h> #include <crtdbg.h> #include <stdlib.h> #include <malloc.h> typedef struct racional fraccion; struct racional {

Departamento de Computación UNAN - León

Page 369: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 53 de 53

int numerador; int denominador; }; typedef enum boolean booleano; enum boolean { Falso, Verdad }; /* Prototipos de funciones */ fraccion *NuevaFraccion (void); void Error (void); void LeerFraccion (fraccion *pf); fraccion *ReducirFraccion (fraccion *pf); void ImprimirFraccion (fraccion *pf); void LiberarMemoria (fraccion **pf); booleano FraccionValida (fraccion *pf); /* Denominador = 0 ?*/ void main() /* Función principal */ { fraccion *f; // puntero a fraccion fraccion *fr; // fracción reducida booleano r; system ("cls"); printf ("\n\t **** DEMOSTRACION DEL ALGORITMO DE EUCLIDES ****"); f = NuevaFraccion(); do { LeerFraccion (f); r = FraccionValida (f); if (r == Falso) printf ("\n\t Fraccion no valida...."); }while (r == Falso); fr = ReducirFraccion (f); ImprimirFraccion (fr); /* Liberamos la memoria de los objetos asignados */ LiberarMemoria (&fr); LiberarMemoria (&f); /* Verificamos la existencia de lagunas de memoria */ if (_CrtDumpMemoryLeaks()) printf ("\n\t Hay Lagunas de Memoria"); } // Fin del main()

Departamento de Computación UNAN - León

Page 370: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 54 de 54

/////////////// Definición de funciones ///////////////////// /* Asignar memoria para una fraccion */ fraccion *NuevaFraccion (void) { fraccion *faux; faux = (fraccion *) malloc (sizeof (fraccion)); if (faux == NULL) Error(); return (faux); } // Fin de NuevaFraccion() /* Manejador de error */ void Error (void) { perror ("Espacio de memoria insuficiente"); exit(0); } // Fin de Error() /* Leer una fracción */ void LeerFraccion (fraccion *pf) { int num, den; printf ("\n\t Introduzca una fraccion de la forma (a/b): "); scanf ("%d/%d", &num, &den); pf->numerador = num; pf->denominador = den; } // Fin de LeerFraccion() /* Imprimir una fracción */ void ImprimirFraccion (fraccion *f) { printf ("\n\t Fraccion reducida: "); printf ("\n\t %d/%d\n", f->numerador, f->denominador); } // Fin de ImprimirFraccion() /* Liberar la memoria de un objeto tipo fracción */ void LiberarMemoria (fraccion **pf) { fraccion *aux; aux = *pf; free (aux);

Departamento de Computación UNAN - León

Page 371: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 55 de 55

aux = NULL; *pf = aux; } // Fin de LiberarMemoria() /* Reducir fracción */ fraccion *ReducirFraccion (fraccion *pf) { int a, b, resto; fraccion *aux; aux = NuevaFraccion(); if (aux == NULL) Error(); /* Encontrar el mayor del denominador y numerador */ if (pf->numerador > pf->denominador) { a = pf->numerador; b = pf->denominador; } else { a = pf->denominador; b = pf->numerador; } while (b != 0) { resto = a % b; a = b; b = resto; } aux->numerador = pf->numerador / a; aux->denominador = pf->denominador / a; return (aux); } // Fin de ReducirFraccion() /* Verifica que la fraccion tenga un denominador válido */ booleano FraccionValida (fraccion *pf) { if (pf->denominador == 0) return (Falso); else return (Verdad); } // Fin de FraccionValida() El código de la función que reduce la fracción, se muestra en negrita.

Departamento de Computación UNAN - León

Page 372: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 56 de 56

7.2.14 Algoritmos Numéricos Un número es perfecto cuando la suma de todos los números menores y divisibles por él, es igual al mismo número. Por ejemplo, 6 es un numero perfecto, pues 6 es divisible entre 1 6 es divisible entre 2 6 es divisible entre 3 y, 1 + 2 + 3 = 6 El algoritmo para determinar si un número es perfecto, es como sigue: Boleano Funcion EsPerfecto (numero) i = 1 suma = 0 Hacer para i = 1 a numero Si (numero mod i) == 0 entonces suma = suma + i Fin-si Fin-para Si suma == numero Regresar Verdadero Sino Regresar Falso Fin. Ejercicio: Escribir un programa en C, para encontrar los números perfectos en el rango inf – sup. Solución: /* perfectos.c */ /* Este programa imprime los números perfectos que están dentro de un intervalo dado. */ #include <stdio.h> typedef enum boolean booleano; enum boolean { Falso, Verdad }; /* Prototipos de funciones */

Departamento de Computación UNAN - León

Page 373: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 57 de 57

booleano EsPerfecto (int numero); void Perfectos (int inf, int sup); void main () /* Función principal */ { int inf, sup; printf ("\n\t **** NUMEROS PERFECTOS DENTRO DE UN INTERVALO ****"); printf ("\n\t Limite inferior: "); scanf ("%d", &inf); printf ("\n\t Limite superior: "); scanf ("%d", &sup); Perfectos (inf, sup); printf("\n\n"); } // Fin del main() /* Verifica si un número es perfecto */ booleano EsPerfecto (int numero) { int i, suma = 0; for (i = 1; i < numero; i++) { if ((numero % i) == 0) suma = suma + i; } if (suma == numero) return (Verdad); else return (Falso); } // Fin de EsPerfecto() /* Verifica e imprime los números perfectos en el rango (inf, sup) */ void Perfectos (int inf, int sup) { int i; for (i = inf; i <= sup; i++) { if ( EsPerfecto (i) == Verdad ) printf ("\n\t %d -->: %3s", i, "PERFECTO"); } } // Fin de Perfectos()

Departamento de Computación UNAN - León

Page 374: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 58 de 58

EESSTTRRUUCCTTUURRAASS DDIINNÁÁMMIICCAASS DDEE DDAATTOOSS

Departamento de Computación UNAN - León

Page 375: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 59 de 59

7.3 Estructuras dinámicas de datos

Título del tema 2: Estructuras dinámicas de datos.

Objetivos: • Comprender las propiedades de las estructuras dinámicas.

• Conocer los diferentes tipos de listas dinámicas y la utilidad que tienen en aplicaciones de la vida real.

• Comprender las operaciones que se aplican sobre los diversos tipos de listas dinámicas.

Contenido: • Introducción

• Asignación dinamica de memoria

• Listas lineales

o Operaciones básicas

Inserción de un elemento al comienzo de la lista

Inserción de un elemento en general

Borrar un elemento de la lista

Recorrido de una lista cuyo primer elemento está apuntado por p

Buscar en la lista un elemento con un valor x

• Pilas, colas y listas doblemente enlazadas

o Pilas

Pilas sin usar listas lineales

Pilas usando listas lineales

o Colas

o Listas Circulares

o Listas doblemente enlazadas

Departamento de Computación UNAN - León

Page 376: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 60 de 60

• Arboles

o Arboles binarios

o Recorrido de árboles binarios

• Arboles binarios de búsqueda

o Borrado en árboles

• Arboles binarios perfectamente equilibrados

Duración: • 14 horas

Bibliografía básica:

• Ceballos, Fco Javier. 1997. Enciclopedia del Lenguaje C. Alfaomega RAMA.

Departamento de Computación UNAN - León

Page 377: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 61 de 61

7.3.1 Introducción La propiedad característica de las estructuras dinámicas, es la facultad que tienen para variar su tamaño y hay muchos problemas que requieren de este tipo de estructuras. Esta propiedad las distingue claramente de las estructuras estáticas fundamentales (arrays y estructuras). Por tanto, no es posible asignar una cantidad fija de memoria para una estructura dinámica, y como consecuencia un compilador no puede asociar direcciones explícitas con las componentes de tales estructuras. La técnica que se utiliza más frecuentemente para resolver este problema consiste en realizar una asignación dinámica de memoria, al tiempo que son creadas durante la ejecución del programa, en vez de hacer la asignación durante la compilación del mismo. Cuando se trabaja con estructuras dinámicas, el compilador asigna una cantidad fija de memoria para mantener la dirección del componente asignado dinámicamente, en vez de hacer una asignación para el componente en sí. Esto implica que debe haber una clara distinción entre datos y referencias a datos y que consecuentemente se deben emplear tipos de datos cuyos valores sean punteros o referencias a otros datos.

7.3.2 Asignación dinamica de memoria Cuando se asigna una memoria dinámicamente para un objeto de un tipo cualquiera, se devuelve un puntero a la zona asignada. Para realizar esta operación disponemos en C de la función malloc (t). #include <stdlib.h> o <malloc.h> void *malloc(size_t t); Esta función asigna un bloque de memoria t bytes y devuelve un puntero que referencia el espacio asignado. Si hay insuficiente espacio de memoria o si t es 0, la función retorna un puntero nulo (NULL). Puesto que el puntero devuelto es a un objeto de un tipo no especificado (void), utilizar la notación cast sobre el valor devuelto, para realizar la conversión al tipo deseado. Ejemplo: typedef struct datos elemento; struct datos { /*miembros de la estructura */ . . . }; elemento *NuevoElemento(void) { return ((elemento *) malloc (sizeof(elemento)));

Departamento de Computación UNAN - León

Page 378: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 62 de 62

} main() { elemento *c; c = NuevoElemento ( ); /*asignación dinamica de memoria*/ if ( c) { printf (“error: insuficiente espacio de memoria\n”); exit (1); } . . . free (c); /* liberar el bloque de memoria apu tado por c */ } La función NuevoElemento() asigna memoria para un objeto de tipo elemento y devuelve un puntero a dicho elemento. Si no hay espacio suficiente para crear un objeto del tipo especificado, la función NuevoElemento() devuelve un puntero nulo (0 ó NULL). En programas que utilizan asignación dinámica de memoria, es muy importante liberar este espacio cuando no se utilice, ya que si se pierde la dirección que referencia el espacio asignado, dicho espacio no puede ser liberado y además inaccesible. Para liberar un bloque de memoria asignado por la función malloc(), utilizaremos la función free(). #include <stdlib.h> o <malloc.h> void free (void *p);

7.3.3 Listas lineales Un array dinámico, según se ha definido en el capitulo de punteros, una vez creado no permite alterar su tamaño. Si lo que deseamos es una lista de elementos u objetos de cualquier tipo, originalmente vacía, que durante la ejecución del programa vaya creciendo y decreciendo elemento a elemento, según las necesidades previstas en el programa, entonces tenemos que construir una lista lineal en la que cada elemento apunte o direccione al siguiente. Por este motivo, una lista lineal se le denomina lista enlazada. En Figura 7.3.1, se muestra un gráfico que representa una lista enlazada.

Departamento de Computación UNAN - León

Page 379: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 63 de 63

p

NULL

Figura 7.3.1 Ejemplo de una lista.

Para construir una lista lineal primero tendremos que definir la clase de objetos que van a formar parte de la misma. De una forma genérica el tipo definido será de la forma: typedef struct id tipo__objeto; struct id { /* declaración de los miembros de la estructura */ tipo__objeto *siguiente; }; Ejemplo: typedef struct datos elemento; struct datos { int dato; elemento *siguiente; }; elemento *p; p = NuevoElemento; p->siguiente = NULL; Este ejemplo declara un tipo denominado elemento. Observamos que uno de sus miembros es un puntero a un objeto del mismo tipo. Esto permitirá a un elemento creado referenciar su sucesor. La sentencia elemento *p declara un puntero a un objeto de tipo elemento. La sentencia p = NuevoElemento; crea (asigna memoria para) un objeto de tipo elemento, genera un puntero (dirección de memoria) que referencia este nuevo objeto y asigna esta dirección a la variable p. La sentencia p->siguiente = NULL asigna al miembro siguiente del objeto apuntado por p el valor NULL, indicando así que después de este elemento no hay otro. El valor NULL, dirección nula, nos permite crear estructuras finitas. Una declaración como p = NULL indica una lista vacía (suponiendo que p apunta al principio de la lista). Un objeto puede referenciarse por más de un puntero, y también un objeto de un determinado tipo puede copiarse en otro objeto del mismo tipo.

Departamento de Computación UNAN - León

Page 380: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 64 de 64

Ejemplo: #include <stdio.h> #include <stdlib.h> typedef struct datos elemento; /*declaracion del tipo elemento*/ struct datos { int dato; elemento *siguiente; }; elemento *NuevoElemento(); void error(void); main() { elemento *p,*q,*r; /* Crear dos objetos de tipo elemento apuntados por p yq * respectivamente. */ p = NuevoElemento(); if(!p)

error();

q = NuevoElemento(); if(!q)

error();

p->dato = 5; *q = *p; /*copia el objeto apuntado por p en el objeto *apuntado por q */ r = q; /*r apunta al mismo objeto que q*/ printf("%d\n",r->dato*2); /*escribe 10*/ } elemento *NuevoElemento() { return((elemento *)malloc(sizeof(elemento))); } void error(void) { perror("error: insuficiente espacio de memoria.\n"); exit(1); }

Departamento de Computación UNAN - León

Page 381: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 65 de 65

7.3.4 Operaciones básicas Las operaciones que podemos realizar con listas incluyen fundamentalmente las siguientes:

1. Recorrido de una lista. 2. Búsqueda de un elemento en la lista. 3. Inserción de un elemento en la lista. 4. Borrado de un elemento de la lista.

A continuación, y partiendo de las declaraciones: typedef struct datos elemento /*declaración del tipo elemento*/ struct datos { int dato. Elemento *siguiente; }; elemento p, q; Se indica la forma de realizar estas operaciones.

7.3.4.1 Inserción de un elemento al comienzo de la lista Primero se crea un elemento y después se reasignan los punteros, tal como se indica a continuación: q = NuevoElemento(); q->dato = n; /*asignación de valores*/ p->siguiente = p; /*reasignación de punteros*/ p = q; El orden en el que se realizan estas operaciones es esencial. Este concepto nos sugiere cómo crear una lista. Para ello, y partiendo de una lista vacía, no tenemos más que repetir la operación de insertar un elemento al comienzo de una lista. Veámoslo a continuación: elemento *p, *q; int n; printf("Introducir datos. Finalizar con F6\n\n"); p = NULL; printf("dato: "); while(scanf("%d",&n)!=EOF) {

Departamento de Computación UNAN - León

Page 382: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 66 de 66

q = NuevoElemento(); q->dato = n; q->siguiente = p; p = q; printf("dato: "); } Notar que el orden de los elementos en la lista, es el inverso del orden en el que han llegado. Nota: Inserciones al inicio de la lista, son muy comunes en estructuras dinámicas tipo LIFO (Last In, First Out), las cuales estudiaremos más adelante.

7.3.4.2 Inserción de un elemento en general La inserción de un elemento en la lista, a continuación de otro elemento apuntado por p, es de la forma siguiente: q = NuevoElemento(); q->dato = x; /*Valor insertado */ q->siguiente = p->siguiente; p->siguiente = q; La Figura 7.3.2, ilustra las operaciones a seguir.

q p

Figura 7.3.2 Inserción en la lista detrás del elemento apuntado por p. La inserción de un elemento en la lista antes de otro elemento apuntado por p, se hace insertado un nuevo elemento detrás del elemento apuntado por p, intercambiando previamente los valores del nuevo elemento y del elemento apuntado por p.

Departamento de Computación UNAN - León

Page 383: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 67 de 67

q = NuevoElemento(); *q = *p; p->dato = x; /*valor insertado */ p->siguiente = q; La Figura 7.3.3, ilustra las operaciones a seguir.

27q

p

Figura 7.3.3 Inserción en la lista antes del elemento apuntado por p.

7.3.4.3 Borrar un elemento de la lista. Para borrar el sucesor de un elemento apuntado por p, las operaciones a realizar son las siguientes: q = p->siguiente; p->siguiente = q->siguiente; free(q); La Figura 7.3.4, ilustra las operaciones a seguir.

Figura 7.3.4 Borrar el sucesor del elemento apuntado por p.

13 27 21 13 8 21

q

p p

Departamento de Computación UNAN - León

Page 384: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 68 de 68

Para borrar un elemento apuntado por p, las operaciones a realizar son las siguientes: q = p->siguiente; *p = *q; free(q); La Figura 7.3.5, ilustra las operaciones a seguir. q

p p 20 20 30

10 20 30

Figura 7.3.5 Borrar el elemento apuntado por p.

7.3.4.4 Recorrido de una lista cuyo primer elemento está apuntado por p. Supongamos que hay que realizar una operación con todos los elementos de una lista, cuyo primer elemento está apuntado por p. Por ejemplo, escribir el valor de cada elemento de la lista. La secuencia de operaciones es la siguiente: q = p; /*salvamos el puntero al comienzo de la lista*/ while(q!=NULL) { printf(“%d”,q->dato); q = q->siguiente; }

7.3.4.5 Buscar un elemento con un valor x. La búsqueda es secuencial y termina cuando se encuentra el elemento, o bien, cuando se llega al final de la lista. q = p; printf(“valor: ”); scanf(“%d”,&x); while(q != NULL && q->dato != x) q = q->siguiente;

Departamento de Computación UNAN - León

Page 385: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 69 de 69

Como ejercicio, realizamos a continuación un programa que nos permita crear una lista clasificada, en la cual cada elemento conste de dos campos: uno que contenga un número entero y otro que sea un puntero a un elemento del mismo tipo.

El programa incluirá las siguientes funciones:

1. Añadir un elemento. Esta función comprenderá dos casos: insertar un

elemento al principio de la lista o insertar un elemento después de otro.

2. Borrar un elemento de la lista. Esta función buscará el elemento a borrar y después lo borrará. Hay que distinguir si se trata de la cabecera o de un elemento cualquiera.

3. Buscar un elemento en la lista.

4. Visualizar el contenido de la lista.

/****************** Operaciones con listas **********************/ #include <stdio.h> #include <stdlib.h> #include <conio.h> #define ListaVacia (cabecera==NULL) /*Lista simplemente enlazada *Cada elemento contiene un nº entero */ typedef struct datos elemento; /*declaración del tipo elemento*/ struct datos /*elemento de una lista de enteros*/ { int dato; elemento *siguiente; }; /*Funciones prototipos*/ elemento *NuevoElemento() void error(void) void menu(void); void anadir(elemento **, int); void borrar(elemento **, int); elemento *buscar(elemento *, int); void visualizar(elemento *); main() /*Función principal*/ { elemento *cabecera = NULL; elemento *q; int opcion, dato, k = 10; while(1) { do

Departamento de Computación UNAN - León

Page 386: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 70 de 70

{ system("cls"); menu(); opcion = getche(); }while(opcion < '1' || opcion > '5'); system("cls"); switch(opcion) { case '1': printf("añadir datos: "); scanf("%d",&dato); anadir(&cabecera,dato); break; case '2': printf("Borrar dato: "); scanf("%d",&dato); borrar(&cabecera,dato); break; case '3': printf("Buscar dato: "); scanf("%d",&dato); q = buscar(cabecera,dato); if(q) q->dato+=k; else printf("Lista vacia\n"); break; case '4': visualizar(cabecera); break; case '5': exit(0); } printf("\nPulse una tecla para continuar"); getch(); } } ////////////////////////////////// Definición de Funciones ////////////////////////////////////////// /* Crear un nuevo elemento */ elemento *NuevoElemento() { return ((elemento *)malloc(sizeof(elemento))); } /* Función Error */ void error (void) { perror ("error: insuficiente espacio de memoria.\n"); exit (1); } /* Función Menú */ void menu() { printf("\n\t1. Añadir un elemento\n"); printf("\n\t2. Borrar un elemento\n");

Departamento de Computación UNAN - León

Page 387: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 71 de 71

printf("\n\t3. Buscar un elemento\n"); printf("\n\t4. Vizaualizar la lista\n"); printf("\n\t5. Salir\n"); printf("\n\t Elija la opcion deseada\n"); } /* Introducir un elemento ordenadamente en la lista */ void anadir(elemento **cab, int dato) { elemento *cabecera = *cab; elemento *actual = cabecera,*anterior = cabecera, *q; if (ListaVacia) /*si esta vacía, crear un nuevo elemento*/ { cabecera = NuevoElemento(); cabecera->dato = dato; cabecera->siguiente = NULL; *cab=cabecera; return; } /*Entrar en la lista y encontrar el punto de inserción*/ while(actual != NULL && dato > actual->dato) { anterior = actual; actual = actual->siguiente; } /*Dos casos: *1) Insertar al principio de la lista *2) Insertar después de anterior (incluye insertar al final) */ q = NuevoElemento(); /*se genera un nuevo elemento*/ if(anterior == actual) /*insertar al principio*/ { q->dato = dato; q->siguiente = cabecera; cabecera = q; } else /*insertar después de anterior*/ { q->dato = dato; q->siguiente = actual; anterior->siguiente = q; } *cab = cabecera; } /* Encontrar un dato y borrarlo */ void borrar(elemento **cab, int dato) { elemento *cabecera = *cab; elemento *actual = cabecera, *anterior = cabecera;

Departamento de Computación UNAN - León

Page 388: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 72 de 72

if (ListaVacia) { printf("Lista Vacia\n"); return; } /*entrar en la lista y encontrar el elemento a borrar*/ while(actual !=NULL && dato != actual->dato) { anterior = actual; actual = actual->siguiente; } /*si el dato no se encuentra retornar*/ if(actual == NULL) return; /*si el dato s eencuentra, borrar el elmento*/ if(anterior == actual) /*borrar el elemento de cabecera*/ cabecera = cabecera->siguiente; else anterior->siguiente = actual->siguiente; free(actual); *cab = cabecera; } /* Buscar un elemento determinado en la lista */ elemento *buscar(elemento *cabecera, int dato) { elemento *actual = cabecera; while(actual != NULL && dato != actual->dato) actual = actual->siguiente; return (actual); } /* Visualizar la lista */ void visualizar(elemento *cabecera) { elemento *actual = cabecera; if (ListaVacia) printf("Lista Vaica\n"); else { while(actual != NULL) { printf("%d ",actual->dato); actual = actual->siguiente; } printf("\n"); } }

Departamento de Computación UNAN - León

Page 389: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 73 de 73

7.3.5 Pilas, colas y listas doblemente enlazada

7.3.5.1 Pilas Pilas sin uso de listas lineales En términos de listas lineales, una pila puede ser definida como, una lista lineal, en la que las inserciones y supresiones se hacen en un extremo de la lista. Por esto, las pilas son estructuras de datos de tipo LIFO (Last In, First Out): último en entrar, primero en salir. Esto sugiere la idea de una pila de platos, en la que se van apilando platos unos encima de otros. En un momento determinado, si nos decidiéramos a quitar un plato, el plato que quitaríamos será el último que pusimos en la pila, es decir, el plato que está más arriba; de ahí, el nombre de estrucuturas tipo LIFO. Como un primer paso para el entendimiento de lo que son las pilas, comenzaremos diciendo que las pilas se pueden implementar también mediante estructuras estáticas (arrays). Cuando se usa este tipo de implementación, el tamaño del array, debe ser un número tal que, el crecimiento máximo que la pila pueda tener, nunca vaya a sobrepasar el límite del array, aún cuando esto pueda ser controlable. Esto se logra realizando el análisis previo de los requisitos que el programa debe cumplir. Para empezar a comprender cómo funciona una pila, haremos uso de una estructura que incluya como campos, un array de elementos enteros y un variable tipo entero, que nos diga a cada momento, cuál es el tope de la pila. En este contexto, entenderemos por tope de la pila, la posición (índice) del arreglo en la que se encuentra el último elemento introducido a la pila. Dicho de otra forma, el tope de la pila incrementado en una unidad (recordar que los arreglos en C comienzan en la posición 0), nos indica el tamaño de la pila o la cantidad de elementos introducidos en la pila. La Figura 7.3.6 ilustra lo expuesto:

Departamento de Computación UNAN - León

Page 390: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 74 de 74

Figura 7.3.6 Pilas sin uso de listas lineales. En la Figura 7.3.6 podemos ver lementos, consta de N_MAX eleme

que el arreglo referenciado por la variable ntos. El miembro top, inicialmenete vale –1, lo

ca que la pila está vacía, esto es, que no contiene elementos. Cuando s decidamos a introducir el primer elemento de la pila, top tomará el valor de 0;

uan l segundo elemento de la pila, top tomará el

continuación, mostraremos un programa en donde se implementa una pila con la cnica explicada anteriormente. La pila será mantenida mediante la siguiente

as funciones de inserción y supresión de datos, son llamadas comúnmente push y

ción, su valor es de -1, lo cual dica que la pila está vacía. Conforme se introducen valores en la pila, top va umentando su valor. De hecho, top siempre apunta a la posición del último

ecual signifinoc do nos decidamos a introducir evalor de 1, y así. A téestructura: #define N_MAX 100 // La pila contendrá 100 elementos typedef struct pila Pila; /* tipo pila */ struct pila { int top; // tope de la pila int elementos[N_MAX]; }; Lpop. El programa contendrá un menú, mediante el cual se podrá meter y sacar elementos o visualizar el estado de la pila. Los campos de la estructura de la pila se explican a continuación: top: es un tipo de datos entero. Al iniciar la aplicaina

Departamento de Computación UNAN - León

Page 391: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 75 de 75

elemento introducido. Ya que los arreglos en C, empiezan de cero, en la posición ero del arreglo elementos, estará el primer elemento de la pila. Si solamente

to en la pila, entonces top valdría 0; si hubiese cinco elementos n la pila, entonces top valdría 4.

lementos: Es un arreglo de enteros en el cual se almacenan los elementos de la pila. Posee u

miembro top nos servirá como dice ara a emento introducido en la pila. Hay que recordar que s ins rcion e elementos en una pila, siempre se hacen por el ismo xtrem e la pila.

eclare y defina las siguientes funciones:

chubiese un elemene e

n tamaño igual al valor de la constante N_MAX; este sería el tamaño máximo de pila. Como se explicó anteriormente, elín p cceder al último ella e es y supresiones dm e o, en este caso, por el tope d D int Menu ( void );

de esta función, será mostrar un menú como el siguiente:

Menú de operaciones con pila ---------------------

1. Meter un dato.

Su opción:

a función retorna un entero que corresponde a la opción que ha seleccionado el

El objetivo

--------------------- 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Lusuario. void Inicializar ( Pila *pp ); Esta función recibe como único argumento, la dirección de una variable de tipo Pila.

l objetivo de esta función es inicializar la pila con valores adecuados. Por ejemplo, icializar a un valor que convenga el alumno. La

ariable top deberá ser inicializada a -1, para indicar que la pila está vacía.

Eel arreglo elementos se podría inv void ValidarEntrada ( char *dato );

sta función recibe como argumento un puntero a una cadena de caracteres, que es to a leer y validar dentro de esta función.

Edonde residirá el da La función valida la entrada, para que la pila sólo contenga datos enteros positivos o negativos.

Departamento de Computación UNAN - León

Page 392: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 76 de 76

void Push ( Pila *pp, int dato ); Esta función recibe como argumentos, un puntero a un objeto de tipo pila y el dato a introducir en la pila. La función verificará que haya espacio en la pila para meter el elemento. int Pop (Pila *pp);

sta función recupera el dato del tope de la pila. Se deberá verificar si la pila tiene al Emenos un elemento. int PilaVacia (Pila p);

sa ALSE.

Regresa TRUE si la pila tiene al menos un elemento. En caso contrario, retorna FALSO. La forma de verificar si la pila tiene elementos, será comprobando el valor de top. Si top vale -1, entonces se regresa TRUE. En caso contrario, se regreF

void Visualizar (Pila p); Si la pila no está vacía, visualiza los elementos de la pila. Se pide: De acuerdo a lo expuesto anteriormente, construya una función main( ), y desde ahí llame al menú para seleccionar las operaciones con la pila. Ejecute el programa repetidas veces para observar si los resultados están de acorde con lo solicitado.

Departamento de Computación UNAN - León

Page 393: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 77 de 77

Solución: /* pila.c */ #include <stdio.h> #include <stdlib.h> #include <conio.h> #include <ctype.h> #include <string.h> #define N_MAX 100 // La pila contendrá 100 elementos #define TRUE 1 #define FALSO 0 typedef struct pila Pila; /* tipo pila */ struct pila { int top; // tope de la pila int elementos[N_MAX]; }; ////////////////// Prototipos de funciones /////////////////////////////// int Menu ( void ); void Inicializar ( Pila *pp ); void Push ( Pila *pp, int dato ); int Pop (Pila *pp); int PilaVacia (Pila p); void Visualizar (Pila p); void ValidarEntrada ( char *dato ); void LimpiarDato (char *dato); void main () { int op; // opcion escogida //int dato; // dato a meter o a sacar char dato[81]; int dato1, valor; Pila P; // Inicializar la pila a valores adecuados Inicializar ( &P ); while (1) { printf("\n"); op = Menu(); switch (op) { fflush(stdin); case 1: // Meter un dato en la pila

Departamento de Computación UNAN - León

Page 394: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 78 de 78

LimpiarDato(dato); printf("\n\t Dato: "); ValidarEntrada (dato); valor = atoi (dato); Push (&P, valor); break; case 2: // Sacar un dato de la pila dato1 = Pop ( &P ); if ( dato1 == '@' ) // La Pila esta vacía continue; printf ("\n\t El dato sacado fue: %d \n", dato1); break; case 3: // Verificar el estado de la pila if (PilaVacia (P) ) printf("\n\t !!! PILA VACIA !!!! \n"); else printf("\n\t !!! PILA CON ELEMENTOS !!!! "); break; case 4: // Visualizar la pila Visualizar (P); break; case 5: // Salir exit(0); } // Cierre del switch } // Cierre del while } // Cierre del main /////////////////////////////////////////////////////////////////////////////////////// ///////////////////// Definicion de Funciones ///////////////////////// ////////////////////////////////////////////////////////////////////////////////////// ///////////// Funcion Menu ///////////// int Menu (void) { int op; do { printf("\n\t Menu de operaciones con pila"); printf("\n\t ------------------------------"); printf("\n\t 1. Meter un dato."); printf("\n\t 2. Sacar un dato."); printf("\n\t 3. Verificar estado de la pila."); printf("\n\t 4. Visualizar la pila.");

Departamento de Computación UNAN - León

Page 395: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 79 de 79

printf("\n\t 5. Salir."); printf("\n\n\t Su opcion: "); scanf ("%d", &op); } while ( op < 1 || op > 5); return (op); } // Fin de Menu () /////////////////// Funcion Inicializar ////////////////////////// void Inicializar ( Pila *pp ) { // Inicializamos la pila a un valor que nunca aparecerá como // elemento de la pila int i; for ( i = 0; i < N_MAX; i++ ) pp->elementos[i] = '@'; pp->top = -1; // Cuando top vale -1, la pila esta vacia } // Fin de Inicializar () ///////////////// Funcion Push ///////////////// void Push ( Pila *pp, int dato ) { // Verificar que la Pila no esta llena if ( pp->top == N_MAX - 1 ) { printf ("Pila llena.... Saque un elemento."); return; } pp->top++; // Incrementar el índice pp->elementos [ pp->top ] = dato; } // Fin de Push () //////////////// Funcion PilaVacia ////////////// int PilaVacia ( Pila p) { if ( p.top == -1 ) return (1);

Departamento de Computación UNAN - León

Page 396: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 80 de 80

else return (0); } // Fin de PilaVacia () /////////////////// Funcion Pop /////////////////// int Pop ( Pila *pp ) { int x; if ( PilaVacia (*pp) ) { printf ("\n\t !!!!! PILA VACIA !!!!!"); printf ("\n\t Meta un elemento... "); return('@'); } x = pp->elementos [ pp->top ]; pp->elementos [ pp->top ] = '@'; pp->top--; return (x); } // Fin de Pop () /////////////////// Funcion Visualizar ///////////////////////////// void Visualizar ( Pila p) { int i; if ( PilaVacia (p) ) { printf ("\n\t !!!! PILA VACIA !!!!! \n"); return; } else { printf ("\n\t La pila es: \n\n\t"); for ( i = 0; i <= p.top; i++ ) printf("%d --> ", p.elementos [i] ); printf ("NULL \n\n"); } } // Fin de Visualizar ()

Departamento de Computación UNAN - León

Page 397: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 81 de 81

/////////////////////// Funcion ValidarEntrada //////////////////////////// void ValidarEntrada ( char *dato ) { // Valida la entrada, para que la pila sólo contenga datos // enteros positivos o negativos /* Recorrer el arreglo e ir verificando que cada caracter sea un dígito Los espacios que anteceden al número, son descartados Si el número empieza con '-', es un número negativo; si empieza con un '+' o no se especifica el signo, el número es positivo. */ int ch; int i = 0; ch = getch(); if ( ch == '+' || ch == '-' ) // Numeros con caracter de signado { dato[i++] = ch; // Guardar en el array numero el signo putch( ch ); while( !isdigit( ch = getch() ) ) ; ungetch( ch ); while( isdigit( ch = getch() ) ) { putch( ch ); dato[i++] = ch; }

} // Cierre del if else { // 2 posiblidades: la primera entrada fue un numero // o fue un caracter no numerico if ( isdigit ( ch ) ) // El caracter fue un numero { ungetch( ch ); while( isdigit( ch = getch() ) ) { putch( ch ); dato[i++] = ch; } } else //Caracter no valido

Departamento de Computación UNAN - León

Page 398: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 82 de 82

{ fflush (stdin); ValidarEntrada (dato); } } // Fin de else } // Fin de ValidarEntrada() ///////////////////// Funcion ValidarDato ///////////////////////// void LimpiarDato (char *dato) { int i; for (i = 0; i < 81; i++) dato[i] = '\0'; } // Fin de LimpiarDato() A continuación, se presenta una corrida del programa para que el estudiante se de una idea de cómo es la funcionalidad de la aplicación. Primera ejecución: Nota: las entradas del usuario están en negritas cursivas y subrayadas. Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 1 Dato: +10 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> NULL

Departamento de Computación UNAN - León

Page 399: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 83 de 83

Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 1 Dato: -8 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> NULL Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 1 Dato: 12 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> 12 --> NULL

Departamento de Computación UNAN - León

Page 400: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 84 de 84

Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 1 Dato: 16 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> 12 --> 16 --> NULL Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 1 Dato: -24 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> 12 --> 16 --> -24 --> NULL

Departamento de Computación UNAN - León

Page 401: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 85 de 85

Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 2 El dato sacado fue: -24 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> 12 --> 16 --> NULL Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 2 El dato sacado fue: 16 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> 12 --> NULL

Departamento de Computación UNAN - León

Page 402: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 86 de 86

Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 2 El dato sacado fue: 12 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> -8 --> NULL Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 2 El dato sacado fue: -8 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 La pila es: 10 --> NULL

Departamento de Computación UNAN - León

Page 403: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 87 de 87

Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 2 El dato sacado fue: 10 Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 4 !!!! PILA VACIA !!!!! Menu de operaciones con pila ------------------------------ 1. Meter un dato. 2. Sacar un dato. 3. Verificar estado de la pila. 4. Visualizar la pila. 5. Salir. Su opcion: 5 Press any key to continue Hay dos funciones que merecen ser explicadas en esta sección, la función Push ( ) y la función Pop ( ). La función para introducir un nuevo dato, Push ( ), primero verifica, mediante el campo top, si la Pila aún tiene espacio para albergar otro dato. De ser así, incrementa a top, y a continuación, mete el dato entero que se le pasa como segundo argumento, en el arreglo elementos, con índice top. La definición de la función Push es como sigue:

Departamento de Computación UNAN - León

Page 404: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 88 de 88

void Push ( Pila *pp, int dato ) { // Verificar que la Pila no esta llena if ( pp->top == N_MAX - 1 ) { printf ("Pila llena.... Saque un elemento."); return; } pp->top++; // Incrementar el índice

pp->elementos [ pp->top ] = dato; } // Fin de Push () La función para retirar un dato de la Pila, Pop( ), primero verifica si la pila tiene elementos para retirar. De ser así, se obtiene del array elemento con índice top, el dato que está al final de la pila y se almacena en una variable auxiliar; se escribe en esa misma posición el carácter de inicialización de la pila; se decrementa top en una unidad y se retorna la variable auxiliar. La definición de la función Pop ( ), es como sigue: int Pop ( Pila *pp ) { int x; if ( PilaVacia (*pp) ) { printf ("\n\t !!!!! PILA VACIA !!!!!"); printf ("\n\t Meta un elemento... "); return('@'); } x = pp->elementos [ pp->top ]; pp->elementos [ pp->top ] = '@'; pp->top--; return (x); } // Fin de Pop ()

Departamento de Computación UNAN - León

Page 405: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 89 de 89

Pilas usando listas lineales Una vez que se ha visto la implementación de una pila mediante un array, pasaremos ahora a ver cómo se implementa una pila usando una lista lineal. A como hemos dicho anteriormente, una pila es una lista lineal en la que todas las inserciones y supresiones (y normalmente todos los accesos), se hacen en un extremo de la lista. Las pilas son muy utilizadas por los compiladores para auxiliarse en el proceso de evaluar expresiones y, para generar código en lenguaje máquina. Las pilas tienen también utilidad cuando se programan juegos de azar. (para ver las aplicaciones de las pilas en los dos ejemplos mencionados, ver el apartado de Prácticas de Laboratorio) de diversas naturalezas. La Figura 7.3.7, muestra la representación de una pila.

Inserciones y Supresiones

Figura 7.3.7 Representación de una Pila

Las operaciones de insertar y suprimir en una pila, son conocidas en los lenguajes ensambladores como push y pop respectivamente. La operación de recuperación de un elemento de la pila, lo elimina de la misma. Como ejemplo de utilización de una pila, vamos a simular una calculadora capaz de realizar las operaciones de +, -, * y /. La mayoría de las calculadoras aceptan la notación infija y unas pocas la notación postfija. En estas últimas para sumar 10 y 20 introduciríamos primero 10, después 20 y por último el +. Cuando se introducen los operandos, se colocan en una pila y cuando se introduce el operador, se sacan dos operandos de la pila. La ventaja de la notación postfija es que expresiones complejas pueden evaluarse fácilmente sin mucho código. La calculadora de nuestro ejemplo utiliza la notación postfija, por lo que hemos desarrollado dos funciones: push y pop. La función push introduce un valor en la pila y la función pop saca un valor de la pila. El programa realiza las siguientes operaciones:

1. Leer un dato, operando u operador, y lo almacena en la variable op.

2. Analiza op; si se trata de un operando lo mete en la pila utilizando la función push(); y si se trata de un operador saca, utilizando la función pop(), los dos últimos operandos de la pila, realiza la operación indicada por dicho operador y mete el resultado en la pila para encadenarlo con otra posible operación.

Departamento de Computación UNAN - León

Page 406: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 90 de 90

/********** Programa Calculadora. Aplicación de pilas************/ #include <stdio.h> #include <stdlib.h> #define PilaVacia (cima==NULL) /*¿Pila Vacia?*/ typedef struct datos elemento; /*Tipo elemento*/ struct datos /*Estructura de un elemento de la pila*/ { float dato; elemento *siguiente; }; /*Funciones*/ void error(void) { perror("Error: insuficiente espacio en memoria."); exit(1); } elemento *NuevoElemento() { elemento *q=(elemento *)malloc(sizeof(elemento)); return (q); } void push(elemento **p, float x); /*añadir un dato a la pila*/ float pop(elemento **p); /*sacar un dato de la pila*/ void main() /*Funcion Princiapla*/ { elemento *cima = NULL; /*Pila Vacia*/ float a,b; char op[81]; system("cls"); printf("Calculadora con las operaciones + - * /\n"); printf("Los datos seran introducidos de la forma: \n"); printf(">operando 1\n"); printf(">operando 2\n"); printf("Para salir pulse q.\n\n"); do { printf("> "); gets(op); switch(*op) { case '+': b=pop(&cima); a=pop(&cima); printf("%g6\n",a+b); push(&cima,a+b); break; case '-':

Departamento de Computación UNAN - León

Page 407: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 91 de 91

b=pop(&cima); a=pop(&cima); printf("%g\n",a-b); push(&cima,a-b); break; case '*': b=pop(&cima); a=pop(&cima); printf("%g\n",a*b); push(&cima,a*b); break; case '/': b=pop(&cima); a=pop(&cima); if(b==0) { printf("\n\aDivision por cero\n"); break; } printf("%g\n",a/b); push(&cima,a/b); break; default: push(&cima,atof(op)); } } while(*op!='q'); } /*Añadir un dato a la pila*/ void push(elemento **p, float x) { elemento *q, *cima; cima = *p; /*cima de la pila*/ q=NuevoElemento(); q->dato=x; q->siguiente=cima; cima=q; *p=cima; } /*Recuperar un dato de la cima de la pila*/ float pop(elemento **p) { elemento *cima; float x; cima = *p; /*cima de la pila*/ if(PilaVacia) { printf("\nError: pop de una pila vacia"); return 0;

Departamento de Computación UNAN - León

Page 408: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 92 de 92

} else { x = cima->dato; *p = cima->siguiente; free (cima); return (x); } } Una instancia de este programa podría ser: Calculadora con las operaciones + - * / Los datos serán introducidos de la forma: >operando 1 >operando 2 >operador Para salir pulse q > 4.2 > 5 > * 21 >10 > - >11 > q Hay dos funciones que mercen atención, push() y pop(). La función push(), introduce un elemento al inicio de la pila. El método que sigue es simple y sencillo:

1. Crear un nuevo elemento y referenciarlo por q.

2. Apuntar con el puntero siguiente de q, a la cima de la pila.

3. Reasignar la cima de la pila, para que ahora apunte a q. La función pop() sigue estos pasos para obtener un elemento de la pila:

1. Guarda en una vraible auxiliar la cima de la pila.

2. Verifica el estado de la pila, y si está vacía, regresa 0. 3. Si la pila no está vacía, entonces

4. Obtiene en una variable x el dato que se encuentra en el elemento cima.

Departamento de Computación UNAN - León

Page 409: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 93 de 93

5. Reasigna la cima de la pila, para que ahora pase a apuntar adonde apunta su puntero siguiente. Luego de esta operación, la cima de la pila puede ser NULL, lo cual quiere decir que sólo había un elemento, o la cima es difente de NULL, lo cual indica que había al menos dos elementos.

6. Libera el espacio de memoria de la cima antigua, referenciado por la variable

auxiilar.

7. Regresa el valor de la variable x.

7.3.5.2 Colas. Una cola es una lista lineal en la que todas las inserciones se hacen por un extremo; todas las supresiones (y normalmente todos los accesos) se hacen por el otro extremo de la lista. Por ejemplo, una fila en un banco. Este tipo de listas reciben el nombre de listas FIFO (first in first out – primero en entrar; primero en salir). Este orden, es la única forma de insertar y recuperar un elemento de la cola. La Figura 7.3.8, muestra un esquema gráfico de una cola

Supresiones Inserciones

Figura 7.3.8 Representación de una Cola Tener en cuenta que la operación de recuperación de un elemento de la cola, lo elimina de la misma. Considérese el problema de almacenar las citas diarias, con el fin de ejecutarlas en el día y hora señalados. Cuando una de las citas se efectúa, se quita de la lista. El programa que se expone a continuación recoge este tipo de sucesos u otros. En él, empleamos dos funciones introducir() y realizar(). La función introducir() nos permite añadir nuevos sucesos a la cola y la función realizar() saca un suceso de la cola. El programa realiza las siguientes funciones:

1. Presenta un menú con las opciones de introducir suceso, realizar un suceso y salir. A continuación nos solicita que elijamos una opción, lo que da lugar a que se llame a la función correspondiente.

2. La función Introducir() comprenderá dos casos: añadir un elemento a

una cola vacía o añadir un elemento al final de la cola.

Departamento de Computación UNAN - León

Page 410: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 94 de 94

3. la función Retirar() devuelve como resultado el suceso recuperado al principio de la cola. Si la cola estuviese vacía, se indicará con un mensaje.

4. Se supone que el suceso recuperado, se ejecuta.

/****** Realización de sucesos. Aplicación de colas ******/ #include <stdio.h> #include <stdlib.h> #include <conio.h> #include <string.h> #include <crtdbg.h> typedef struct datos elemento; /* tipo elemento */ struct datos /* estructura de un elemento de la cola */ { char suceso[81]; elemento *sig; }; /* Prototipos de funciones */ void Error (void); elemento *NuevoElemento (void); int Menu (void); void Introducir (elemento **pc, elemento **fc, char suceso[]); char *Retirar ( elemento **pc, elemento **fc); void Visualizar (elemento *pc, elemento *fc); // Visualizar la cola void EliminarLagunas (elemento **pc, elemento **fc); void main (void) /* funcion principal */ { elemento *principio, *final; char suceso[81]; char *suceso_temp; int opcion; // opcion del menu elegida principio = final = NULL; /* Cola vacia */ while (1) { opcion = Menu(); switch (opcion) { case 1: // Introducir un suceso en la cola (al final) fflush(stdin); printf ("\n\t Introduzca suceso: "); gets (suceso); /* Introducir el suceso en la cola */

Departamento de Computación UNAN - León

Page 411: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 95 de 95

Introducir (&principio, &final, suceso); break; case 2: // Retirar a un elemento de la cola (del inicio) suceso_temp = Retirar (&principio, &final); strcpy (suceso, suceso_temp); if (*suceso != '\0') printf ("Realizando el suceso: %s \n", suceso); free (suceso_temp); // Liberar la memoria asignada // en la funcion Retirar() printf ("\n\t Pulse una tecla para continuar..\n"); getch(); break; case 3: // Visualizar la cola Visualizar (principio, final); break; case 4: // Salir /* Al salir, verificar si existen lagunas de memoria */ EliminarLagunas (&principio, &final); if ( _CrtDumpMemoryLeaks() ) printf ("\n\t Hay Lagunas de Memoria \n\n"); exit(1); } // Fin de switch } // Fin de while() } // Fin de main() /************* Escoger una opcion **************/ int Menu (void) { int opcion; do { printf ("\n\t ******* Operaciones con cola *****"); printf ("\n\t 1. Introducir un suceso."); printf ("\n\t 2. Realizar un suceso."); printf ("\n\t 3. Visualizar la cola."); printf ("\n\t 4. Salir."); printf ("\n\n\t Su opcion (1-4)? : ");

Departamento de Computación UNAN - León

Page 412: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 96 de 96

scanf ("%d", &opcion); }while (opcion < 1 || opcion > 4); return (opcion); } // Fin de Menu() /*************** Crear un nuevo elemento de la cola *************/ elemento *NuevoElemento () { elemento *temp; temp = (elemento *) malloc ( sizeof (elemento) ); if (temp == NULL) Error(); return (temp); } // Fin de NuevoElemento () /*********** Error al asignar memoria ************************/ void Error (void) { perror ("Error: insuficiente espacio de memoria"); exit (1); } // Fin de Error() /************* Anadir un dato a la cola (al final) *************/ void Introducir (elemento **p_cola, elemento **f_cola, char suceso[]) { elemento *pc, *fc, *q; pc = *p_cola; // Principio de la cola fc = *f_cola; // Final de la cola q = NuevoElemento (); strcpy (q->suceso, suceso ); q->sig = NULL; if (fc == NULL) // Cola vacia pc = fc = q; else // Cola con al menos 1 elemento { fc->sig = q; fc = fc->sig; } /* Actualizar el principio y el final de la cola */

Departamento de Computación UNAN - León

Page 413: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 97 de 97

*p_cola = pc; *f_cola = fc; } // Fin de Introducir() /****************** Sacar un elemento de la cola **************/ char *Retirar ( elemento **p_cola, elemento **f_cola) { elemento *pc, *fc, *q; char *suceso; // suceso a obtener pc = *p_cola; // pc --> principio de la cola fc = *f_cola; // fc --> fin de la cola if (fc != NULL) // Si la cola no esta vacia { q = pc; // q apunta al principio de la cola /* Le asignamos memoria al puntero suceso */ suceso = (char *) malloc ( strlen (q->suceso) + 1 ); /* Copiamos el suceso */ strcpy (suceso, q->suceso); pc = pc->sig; if (pc == NULL) fc = NULL; /* habia un solo elemento */ free (q); *p_cola = pc; *f_cola = fc; return (suceso); } else { /* Cola vacia. Retornar caracter de terminacion de cadena */ printf ("\n\t No hay elementos en la cola..."); suceso = (char *) malloc (2 * sizeof(char)); strcpy (suceso, "\0"); return (suceso); } } // Fin de Retirar() /************ Visualiza los elementos de la cola ******************/ void Visualizar (elemento *p_cola, elemento *f_cola)

Departamento de Computación UNAN - León

Page 414: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 98 de 98

{ elemento *pc, *fc; pc = p_cola; fc = f_cola; if (fc == NULL) { printf("\n\t Cola vacia...."); return; } printf("\n\n\t"); // Recorrer la cola desde el principio hasta el final while (pc != NULL) { printf (" %s --> ", pc->suceso); pc = pc->sig ; } printf("NULL"); } // Fin de Visualizar() /***************** Eliminar Lagunas de memoria ***************/ void EliminarLagunas (elemento **p_cola, elemento **f_cola) { elemento *pc, *fc, *aux; pc = *p_cola; fc = *f_cola; aux = pc; if (fc == NULL) return; // Si la cola está vacía, retornar else { // Recorrer la lista desde el principio y elminar los elementos while (pc != NULL) { aux = pc; pc = pc->sig; free (aux); } } // Fin del else pc = fc = aux = NULL; /* Actualizar los cambios */ *p_cola = pc;

Departamento de Computación UNAN - León

Page 415: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 99 de 99

*f_cola = fc; } // Fin de EliminarLagunas() La función EliminarLagunas(), recorre la lista hasta encontrarse con NULL, y libera cada elemento con la función free() La función Introducir(), inserta un elemento al final de la cola; para esto se hace uso de 2 punteros, uno que apunta al inicio de la lista y otro al final. Cuando se va a insertar un nuevo elemento a la cola, la función Introducir() crea un nuevo elemento y lo deja referenciado por la variable puntero q; a continuación se reasigna el puntero siguiente del final de la cola para que ahora apunte a q. La primera vez que se introduce un elemento, el principio de la cola y el final de la cola, apuntan a q. La función Retirar(), saca al elemento que se encuentra al incio de la cola, y lo elimina de la misma. El elemento sacado en este caso, corresponde a una cadena de caracteres.

7.3.5.3 Listas circulares. Una lista circular es una lista lineal, en la que el último elemento enlaza con el primero. Entonces es posible acceder a cualquier elemento de la lista desde cualquier punto dado. Las operaciones sobre listas circulares resultan ser más sencillas, ya que se evitan casos especiales. Cuando recorremos una lista circular, diremos que hemos llegado al final de la misma, cuando nos encontramos de nuevo en el punto de partida; suponiendo, desde luego, que el punto de partida se guarda de alguna manera en la lista, por ejemplo con u n puntero fijo al mismo. Otra posible solución al problema anterior sería poner en cada lista circular, un elemento especial como lugar de parada. Este elemento especial recibe el nombre de elemento de cabecera de la lista. Esto presenta la ventaja de que la lista circular no estará nunca vacía. Una lista circular con un puntero al último elemento, es equivalente a una lista lineal recta con dos punteros, uno al principio y otro al final.

CABECERA

+2+ 3 1 0

+4+ 1 3 0

-1+ 0 4 0

0- 0 0 1

Figura 7.3.9 Representación de una Lista Circular

Departamento de Computación UNAN - León

Page 416: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 100 de 100

Como ejemplo de utilización de listas circulares, realizaremos la suma de ecuaciones algebraicas o polinómicas de las variables x,y,z. Por ejemplo:

2x3y + 4xy3 – y4 más 2xy3 - xy

Cada polinomio será representado como una lista en la que cada elemento representa un término no nulo, como se indica a continuación:

COEFICIENTE

± A B C SIGUIENTE

Aquí COEFICIENTE es el coeficiente del término xAyBzC. Suponemos que los coeficientes y exponentes están dentro de los rangos permitidos. La notación A B C se utilizará para representar el campo ±ABC de cada elemento tratado como un número entero. El signo de ABC será siempre positivo, excepto para el elemento de cabecera, para este elemento, ABC=-1 y COEFICIENTE = 0. Los elementos de la lista aparecerán sobre la misma en orden decreciente del campo ABC, siguiendo la dirección de los enlaces. Por ejemplo, el 2x3y + 4xy3 – y4, se representaría:

CABECERA

+2+ 3 1 0

+4+ 1 3 0

-1+ 0 4 0

0- 0 0 1

A continuación se muestra el programa correspondiente para sumar dos polinomios, almacenados en dos listas circulares, denominadas por polP y polQ respectivamente. El campo ABC se corresponde con un entero igual A*100 + B*10 + C. Esto limita los exponentes a un dígito. Si deseamos utilizar dos dígitos, necesitaríamos un entero de 6 dígitos. Formando de esta manera el campo ABC, es muy sencillo para aplicaciones posteriores descomponerlo en los exponentes individuales.

El programa incluye:

1. Leer polinomio: esta función lee los términos correspondientes a un polinomio determinado. La lectura se hace en orden creciente de los exponentes ABC. Como consecuencia se crea una lista, que inicialmente constaba del elemento cabecera.

Departamento de Computación UNAN - León

Page 417: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 101 de 101

2. Inicializar: esta función sitúa un puntero (actual) sobre el primer término de un polinomio.

3. Comparar: esta función compara cada término del polinomio P con los

términos del polinomio Q con el fin de sumar sobre Q los términos de igual exponente, y añadir a Q en orden decreciente de ABC, los términos de P que no estén en Q. Para estas operaciones se utilizan las funciones “sumar coeficientes” e “insertar nuevo término” respectivamente.

4. Eliminar término: esta función elimina un término nulo del polinomio Q,

resultado de sumar un término de P con el correspondiente termino Q.

5. Escribir polinomio: visualiza el polinomio Q resultante. La terminología empleada en el programa se interpreta de la forma siguiente: polP: identifica el polinomio P. Es una estructura que contiene tres punteros: cabecera que apunta el elemento cabecera de la lista que contiene al polinomio P, actual que apunta el término del polinomio sobre el que estamos trabajando y anterior que apunta al término anterior de actual. polQ y polX: se definen de la misma forma que polP. polP->actual: hace referencia al puntero actual del polinomio P. polP->actual->siguiente: hace referencia al campo siguiente del elemento apuntado por el puntero actual del polinomio P. El resto de la terminología se interpreta análogamente. /*Listas circulares. Suma de ecuaciones algebraicas *Cada término es función de las variables x,y,z. *con exponentes a, b y c respectivamente, en el rango 0 a n */ #include<stdio.h> #include<stdlib.h> typedef struct datos elemento; /*tipo elemento*/ typedef elemento *pelemento; /*tipo puntero a un elememto*/ struct datos /*estructura de un elemento de la lisat*/ { float coeficiente; /*coeficiente del termino en xyz*/ int abc; /*exponente de x,y,z*/ pelemento siguiente; }; typedef struct lista ListCir; struct lista { pelemento cabecera; /*cabecera de la lista circular*/ pelemento anterior; /*elmento anterior al actual*/

Departamento de Computación UNAN - León

Page 418: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 102 de 102

pelemento actual; /*elemento actualmente apuntado*/ }; /*funciones*/ void error(void) { perror("Error: insuficiente espacio en memoria."); exit(1); } pelemento NuevoElemento() { pelemento q = (pelemento ) malloc (sizeof(elemento)); if (!q)

error(); return (q); } /*Funciones prototipos*/ void leer_polinomio(ListCir *); void inicializar(ListCir *); void comparar(ListCir *, ListCir *); void sumar_coeficientes(ListCir *, ListCir *); void insertar_nuevo_termino(ListCir *,ListCir *); void eliminar_termino(ListCir *); void escribir_polinomio(ListCir); void main() /*función principal*/ { ListCir polP,polQ; system("cls"); /*LEER POLINOMIOS polP y polQ*/ printf("\nIntroduzca los valores para el polinomio P: \n\n"); leer_polinomio (&polP); printf("\nIntroduzca los valores para el polinomio Q: \n\n"); leer_polinomio (&polQ); /*INICIALIZAR*/ inicializar (&polP); inicializar (&polQ); /*COMPARAR*/ comparar (&polP,&polQ); /*ESCRIBIR POLINOMIO RESULTANTE Q*/ escribir_polinomio (polQ); } void leer_polinomio(ListCir *polX) /*Los nodos de la lista se colocarán en orden decreciente *del campo abc, por lo que hay que introducirlos en *orden inverso, esto en orden creciente.

Departamento de Computación UNAN - León

Page 419: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 103 de 103

*/ { int abc; float coef; pelemento q; /*Elemento de cabecera */ polX->cabecera = NuevoElemento(); polX->cabecera->coeficiente = 0; polX->cabecera->abc = -001; polX->cabecera->siguiente = polX->cabecera; polX->anterior = polX->actual = NULL; /*Elementos restantes*/

printf("Introducir los términos del polinomio en orden creciente de abc\ (x^a.y^b.z^c)\n\n"); printf("Para finalizar, teclear coeficiente = 0\n\n"); printf("Coeficiente: "); scanf("%f", &coef); while (coef) { printf("Exponentes abc (sin espacios): "); scanf("%d", &abc); q = NuevoElemento(); q->coeficiente = coef; q->abc = abc; q->siguiente = polX->cabecera->siguiente; polX->cabecera->siguiente = q; printf("Coeficiente: "); scanf("%f", &coef); } } /*Inicializar proceso*/ void inicializar(ListCir *polX) { polX->anterior=polX->cabecera; polX->actual=polX->cabecera->siguiente; } /*Comparar los términos de los polinomios polPy polQ*/ void comparar(ListCir *polP, ListCir *polQ) { while (!(polP->actual->abc < 0)) { while(polP->actual->abc < polQ->actual->abc) { polQ->anterior = polQ->actual; polQ->actual = polQ->actual->siguiente; } if(polP->actual->abc == polQ->actual->abc)

Departamento de Computación UNAN - León

Page 420: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 104 de 104

sumar_coeficientes (polP, polQ); else /*polP->actual->abc>polQ->actual->abc*/ { insertar_nuevo_termino (polP, polQ); polP->actual = polP->actual->siguiente; } } } /*Sumar términos con exponentes iguales; uno a P y otro a Q*/ void sumar_coeficientes(ListCir *polP, ListCir *polQ) { if(polP->actual->abc < 0) return; else { polQ->actual->coeficiente += polP->actual->coeficiente; if(polQ->actual->coeficiente == 0) { eliminar_termino (polQ); polP->actual = polP->actual->siguiente; polQ->anterior = polQ->actual; polQ->actual = polQ->actual->siguiente; } } } /*El polinomio P contiene un termino que no existe en Q*/ void insertar_nuevo_termino(ListCir *polP,ListCir *polQ) { /*se inserta antes del actual*/ pelemento q; q = NuevoElemento(); q->coeficiente = polP->actual->coeficiente; q->abc = polP->actual->abc; q->siguiente = polQ->actual; polQ->anterior = polQ->anterior->siguiente=q; return; /*retornar a comparar*/ } /*Eliminar el término de coeficiente nulo*/ void eliminar_termino(ListCir *polQ) { pelemento q; q = polQ->actual; polQ->actual = polQ->actual->siguiente; polQ->anterior->siguiente = polQ->actual; free (q); /*liberar memoria ocupada por el termino nulo*/ return; /*retornar a sumar_coeficientes*/ } /*Escribir por pantalla el resultado (el polinomio Q)*/

Departamento de Computación UNAN - León

Page 421: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 105 de 105

void escribir_polinomio(ListCir polQ) { printf("\n\nSuma de los polinomios:\n\n"); polQ.cabecera = polQ.cabecera->siguiente; while (polQ.cabecera->abc != -1) { printf("coef: %+g exps. de x y z %03d\n", polQ.cabecera->coeficiente,polQ.cabecera->abc); polQ.cabecera = polQ.cabecera->siguiente; } }

7.3.5.4 Listas doblemente enlazadas Una lista doblemente enlazada, es una lista lineal en la que cada elemento tiene dos enlaces, uno al elemento siguiente y otro al anterior. Esto permite leer la lista en cualquier dirección. La Figura 7.3.10, muestra un esquema gráfico de una lista enlazada: F

NULL

P NULL

Figura 7.3.10 Lista doblemente enlazada. Las operaciones sobre una lista doblemente enlazada, normalmente se realizan sin ninguna dificultad. Sin embargo, casi siempre es mucho más fácil la manipulación de las mismas, cuando se añade un elemento de cabecera y existe un doble enlace entre el último elemento y el primero. Esta estructura recibe el nombre de lista circular doblemente enlazada. Como ejemplo, vamos a construir una lista doblemente enlazada ordenada ascendentemente; cada elemento introducido se colocará automáticamente en el lugar que le corresponde. El programa consta fundamentalmente de tres funciones: insertar(), borrar() y visualizar(). La función insertar() comprende los casos: insertar un elemento al principio, insertar un elemento entre otros dos e insertar un elemento al final. La función borrar() comprende: borrar el primer elemento y borrar un elemento cualquiera que no sea el primero.

Departamento de Computación UNAN - León

Page 422: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 106 de 106

/*********** Lista doblemente enlazada ordenada ascendentemente********/ #include<stdio.h> #include<stdlib.h> #include<string.h> #include<conio.h> #define ListaVacia (listaD->princ == NULL) typedef struct datos elemento; /*Tipo elemento*/ typedef elemento *pelemento; /*tipo puntero a un elemento*/ struct datos /* estructura de un elemento de la lista*/ { pelemento siguiente; char clave[12]; pelemento anterior; }; typedef struct lista ListDob; struct lista { pelemento princ; /*principio de la lista*/ pelemento final; /*final de la lista*/ }; /*Funciones*/ void error(void) { perror("Error: insuficiente espacio de memoria."); exit(1); } pelemento NuevoElemento() { pelemento q = (pelemento)malloc(sizeof(elemento)); if(!q) error(); return (q); } /*Funciones Prototipos*/ void insertar(ListDob *, char []); void borrar(ListDob *, char[]); void visualizar_lista(ListDob); void menu(); main() /*Funcion Principal*/ { ListDob listaD; char opcion, clave[12]; listaD.princ = listaD.final = NULL; /*Lista Vacia*/ while(1) { do{ system("cls");

Departamento de Computación UNAN - León

Page 423: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 107 de 107

menu(); opcion = toupper(getch()); }while(opcion != 'I' && opcion != 'B' && opcion != 'V' && opcion != 'S'); system("cls"); switch(opcion) { case 'I': printf("\nIntroduzca la clave a añadir: "); gets(clave); insertar(&listaD,clave); break; case 'B': printf("\nIntroduzca la clave a borrar: "); gets(clave); borrar(&listaD,clave); break; case 'V': visualizar_lista(listaD); printf("Pulse una tecla para continuar");getch(); break; case 'S': exit(0); } } } /*Añadir un dato a la lista*/ void insertar(ListDob *listaD, char clave[]) { pelemento q, pactual,panterior; /*generar un elemento*/ q = NuevoElemento(); strcpy (q->clave,clave); q->anterior = q->siguiente = NULL; if(ListaVacia) /*¿Lista vacía?*/ { listaD->princ = listaD->final = q; return; } /*buscar la posicion donde hay que insertar el pelemento*/ pactual = panterior = listaD->princ; while(pactual!=NULL && strcmp (clave,pactual->clave)>0) { panterior = pactual; pactual =pactual->siguiente;

Departamento de Computación UNAN - León

Page 424: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 108 de 108

} if (panterior == pactual) /*insertar al principio*/ { q->siguiente = listaD->princ; listaD->princ = pactual->anterior = q; } else /*insertar después de panterior*/ { /*incluye insertar al final*/ q->anterior = panterior; q->siguiente = pactual; panterior->siguiente = q; if(pactual)pactual->anterior = q; /* pactual será NULL cuando se inserta al final */ } } /*Encontrar una determinada clave y borrar el elemento*/ void borrar(ListDob *listaD, char clave[]) { pelemento panterior, pactual; if(ListaVacia) /*¿Lista vacia?*/ { printf("\nLa lista actualmente se encuentra vacia\n"); printf("\nPresione cualquier tecla para continuar "); getch(); return; } /*Entrar en la lista y encontrar el elemnto a borrar*/ panterior = pactual = listaD->princ; while(pactual != NULL && strcmp(pactual->clave,clave)!=0) { panterior = pactual; pactual = pactual->siguiente; } /*si el dato no se encuentra en la lista retornar*/ if(pactual == NULL) { printf("La clave %s no se encuentra en la lista.\n",clave); printf("\nPresione cualquier tecla para continuar "); getch(); return; } /*si el dato se encuentra, borrar el elento*/ if(panterior == pactual) /*el elemento esta en el principio*/ { listaD->princ = listaD->princ->siguiente; if(listaD->princ) listaD->princ->anterior = NULL; /*si principio apunta a NULL habia un solo elemento*/ }

Departamento de Computación UNAN - León

Page 425: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 109 de 109

else { /*modificar el enlace siguiente*/ panterior->siguiente = pactual->siguiente; /*modificar el enlace anterior excepto parar el ultimo*/ if (pactual->siguiente) panterior->siguiente->anterior = pactual->anterior; } free(pactual); } /*visualizar el contenido de la lista*/ void visualizar_lista(ListDob listaD) { pelemento pactual = listaD.princ; if(listaD.princ==NULL) /*Si la lista esta vacia retornar*/ { printf("\nLa lista actualmente se encuentra vacia\n"); return; } while(pactual != NULL) { printf("%s\n",pactual->clave); pactual = pactual->siguiente; } } /*Menu de opciones*/ void menu() { printf("\n\t (I) Introducir un nuevo elemento\n"); printf("\n\t (B) Borrar un elemento\n"); printf("\n\t (V) Visualizar la lista\n"); printf("\n\t (S) Salir"); } LsitDob es una estructura que identifica la lista doblemente enlazada que estamos creando. Contiene dos punteros que definen perfectamente la lista: princ que apunta al primer elemento, y final que apunta al último elemento. Para realizar las operaciones de inserción y borrado utilizamos dos punteros auxiliares: pactual que apunta al elemento identificado, y panterior que apunta al elemento anterior al identificado.

Departamento de Computación UNAN - León

Page 426: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 110 de 110

7.3.5.5 Arboles Un árbol es una estructura no lineal formada por un conjunto de nodos y un conjunto de ramas. En un árbol existe un nodo especial denominado raíz. Un nodo del que sale alguna rama, recibe el nombre de nodo de bifurcación o nodo rama y un nodo que no tiene ramas recibe el nombre de nodo terminal o nodo hoja. La Figura 7.3.11, muestra un árbol con los elementos que lo componen.

A

B

D E F

C

nivel 0

nivel 1

nivel 2

raíz

nodo de bifurcación

nodo terminal

Figura 7.3.11 Arbol De un modo más formal, diremos que un árbol es un conjunto finito de uno o más nodos tales que:

1. Existe un nodo especial llamado raíz del árbol. 2. Los nodos restantes están agrupados en n > 0 conjuntos disjuntos A1,....,An,

cada uno de los cuales es a su vez un árbol, que recibe el nombre de subárbol de la raíz.

La definición dada es recursiva, es decir, hemos definido un árbol como un conjunto de árboles. Esta es la forma más apropiada de definir un árbol. De la definición se desprende, que cada nodo de un árbol es la raíz de algún subárbol contenido en la totalidad del mismo. El número de ramas de un nodo recibe el nombre de grado del nodo. El nivel de un nodo respecto al nodo raíz se define diciendo que la raíz tiene nivel 0 y cualquier otro nodo tiene un nivel igual a la distancia de ese nodo al nodo raíz. El máximo de los niveles se denomina profundidad o altura de un árbol. Es útil limitar los árboles en el sentido de que cada nodo sea a lo sumo, de grado 2. De esta forma cabe distinguir entre subárbol izquierdo y derecho de un nodo. Los árboles así formados, se denominan árboles binarios.

Departamento de Computación UNAN - León

Page 427: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 111 de 111

Árboles binarios. Un árbol binario es un conjunto finito de nodos que consta de un nodo raíz que tiene dos subárboles binarios denominados subárbol izquierdo y subárbol derecho. Evidentemente, la definición dada es una definición recursiva, es decir, cada subárbol es un árbol binario. Las fórmulas algebraicas, debido a que los operadores que intervienen son operadores binarios, nos dan un ejemplo de estructura en árbol binario. La Figura 7.3.12 nos muestra un árbol que corresponde a la expresión aritmética:

(a + b / c) * (d – e * f) *

*

d

-

e f

*a

+

b c

/

Figura 7.3.12 Fórmulas algebraicas. Recorrido de árboles binarios Esta definición de árbol binario, sugiere una forma natural de representar árboles binarios en un ordenador: debemos tener dos enlaces (izq y dcho) en cada nodo, y una variable de enlace raíz que nos direccione el árbol. La Figura 7.3.13 ilustra lo dicho. Esto es: typedef struct datos nodo; struct datos; /*estructura de un nodo del árbol*/ { /*declaración de miembros */ nodo *izdo; nodo *dcho; }; nodo *raíz; /*dirección del árbol*/

Departamento de Computación UNAN - León

Page 428: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 112 de 112

Figura 7.3.13 Un árbol representado como una estructura de datos. Si el árbol está vacío, raíz es igual a NULL; en caso contrario, raíz es un puntero que direcciona la raíz del árbol, e izdo y dcho son punteros que direccionan los subárboles izquierdo y derecho de la raíz, respectivamente. Hay varios algoritmos para el manejo de estructuras en árbol. Una idea que aparece repetidamente en estos algoritmos es la noción de recorrido de un árbol. Este es un método para examinar sistemáticamente los nodos de un árbol, de forma que cada nodo sea visitado solamente una vez. Pueden utilizarse tres formas principales para recorrer un árbol binario: preorden, inorden, postorden. Cuando se visitan los nodos en preorden, primero se vista la raíz, después el subárbol izquierdo y por ultimo el subárbol derecho. Cuando se visitan los nodos en inorden, primero se vista el subárbol izquierdo, luego la raíz y por ultimo el subárbol derecho. Cuando se visitan los nodos en postorden, primero se visita el subárbol izquierdo, después el subárbol derecho y por último se vista la raíz. La Figura 7.3.14 ilustra lo expuesto.

Figura 7.3.14 Recorridos de un árbol.

Departamento de Computación UNAN - León

Page 429: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 113 de 113

Evidentemente, las definiciones dadas son definiciones recursivas, ya que, recorrer un árbol utilizando cualquiera de ellas, implica recorrer sus subárboles empleando la misma definición. Si se aplican estas definiciones al árbol binario de la figura “formulas algebraicas” anterior, se obtiene la siguiente solución: Preorden: * + a / b c – d * e f Inorden : a + b / c * d – e * f Postorden: a b c / + d e f * - * El recorrido en preorden produce la notación prefija; en inorden produce la notación convencional; y en postorden produce la notación postfija o inversa. Los nombres de preorden, inorden y postorden derivan del lugar en el que se visita la raíz con respecto a sus subárboles. Estas tres formas, se exponen a continuación como tres funciones recursivas. En ellas se utiliza la variable a significando la dirección de la raíz con el cual se opera. void preorden (nodo *a) { if (a != NULL) { /* operaciones con el nodo a */ preorden (a->izdo); preorden (a->dcho); } } void inorden (nodo *a) { if (a != NULL) { inorden (a->izdo); /* operaciones con el nodo a */ inorden (a->dcho); } } void postorden (nodo *a) { if (a != NULL) { postorden (a->izdo); postorden (a->dcho); /* operaciones con el nodo a */ } }

Departamento de Computación UNAN - León

Page 430: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 114 de 114

7.3.5.6 Árboles binarios de búsqueda Un árbol binario de búsqueda es un árbol ordenado. Las ramas de cada nodo están ordenadas de acuerdo con las siguientes reglas: para todo nodo ai, todas las claves del subárbol izquierdo de ai son menores que la clave de ai, y todas las claves del subárbol derecho de ai son mayores que la claveque la clave de ai.

Con un árbol de estas características encontrar si un encontrar si un nodo de una clave existe o no, e suna operación muy sencilla. Por ejemplo observando la Figura 7.3.15, localizar la clave 12 es aplicar la definición de árbol de búsqueda, esto es, si la clave buscada es menor que la clave del nodo en el que estamos, pasamos al subárbol izquierdo de este nodo, para continuar la búsqueda y si es mayor, pasamos al subárbol derecho. Este proceso continua hasta encontrar la clave o hasta llegar a un subárbol vacío cuya raíz tiene un valor NULL.

25

9811

3 20

12

Figura 7.3.15 Árbol de búsqueda. Como ejemplo, consideremos una secuencia de claves con el fin de determinar el número de veces que aparece cada una de ellas. Esto significa que empezando con un árbol vacío, se busca cada clave en el árbol. Si se encuentra, se incrementa su contador y si no se encuentra se inserta en el árbol como una nueva clave, con el contador correspondiente inicializado a 1. El desarrollo completo se muestra a continuación. El proceso de búsqueda, función Buscar(), se formula como una función recursiva. Observar que el parámetro formal raíz de la misma, se le pasa su correspondiente parámetro actual por referencia, con el fin de hacer posible los enlaces entre los nodos. Una vez construido el árbol, se utiliza la función Visualizar_Arbol() para visualizar el contenido del mismo. Los nodos se visitan en inorden y la solución se presenta en forma de árbol, de acuerdo con el siguiente esquema:

Departamento de Computación UNAN - León

Page 431: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 115 de 115

Subárbol izquierdo Raíz

Subárbol derecho.

Antes de finalizar el programa, se libera la memoria asignada a cada nodo en el momento de su inserción. Para esto, utilizamos una función EliminarLagunas(). /* Arbol binario de búsqueda */ #include <stdio.h> #include <stdlib.h> #include <crtdbg.h> typedef struct datos nodo; /* tipo nodo */ struct datos { int clave; int contador; nodo *izdo; /* puntero a la raíz del subárbol izquierdo */ nodo *dcho; /* puntero a la raíz del subárbol izquierdo */ }; /* Prototipos de funciones */ void Error(); nodo *NuevoNodo(); void Buscar (int, nodo **); void Visualizar_Arbol (nodo *, int); void EliminarLagunas (nodo **); nodo *raiz = NULL; /* Apunta a la raíz del árbol */ void main() /* Función principal */ { int k; system ("cls"); printf ("\n\t Introducir claves. Finalizar con ^Z \n"); printf ("\n\t Clave: "); while (scanf ("%d", &k) != EOF) { Buscar (k, &raiz); /* raíz se pasa por referencia */ printf ("\n\t Clave: "); } // Fin de while system ("cls"); Visualizar_Arbol (raiz, 0);

Departamento de Computación UNAN - León

Page 432: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 116 de 116

EliminarLagunas (&raiz); if (raiz != NULL) printf("Arbol no vacío"); if (_CrtDumpMemoryLeaks() ) printf ("\n\t Lagunas de memoria encontradas..."); } // Fin del main() //////////////////////////////////////////////////////////////////////// ////////////// Definición de Funciones ////////////////// //////////////////////////////////////////////////////////////////////// /* Mensaje de error y terminación del programa */ void Error (void) { perror ("Error: insuficiente espacio de memoria"); exit(1); } // Fin de Error() /* Construir un nuevo nodo */ nodo *NuevoNodo () { nodo *q; q = (nodo *) malloc (sizeof (nodo)); if (q == NULL) Error(); return (q); } // Fin de NuevoNodo() /******** Buscar una clave en el árbol **********/ /* Buscar por un determinado nodo, y si no está, insertarlo. * El valor para a es pasado por referencia para hacer posibles * los enlaces entre nodo y nodo cuando se crea uno de éstos. */ #define ArbolVacio (a == NULL) void Buscar (int x, nodo **raiz) { nodo *a; a = *raiz; /* raiz del árbol */ if (ArbolVacio) /* El nodo con clave x, no está en el árbol. */

Departamento de Computación UNAN - León

Page 433: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 117 de 117

{ /* Insertarlo */ a = NuevoNodo(); a->clave = x; a->contador = 1; a->izdo = a->dcho = NULL; } else if (x < a->clave) /* El valor buscado está a la izquierda de este nodo */ Buscar (x, &a->izdo); else { if (x > a->clave) /* El valor buscado está a la deerecha de este nodo */ Buscar (x, &a->dcho); else a->contador++; } *raiz = a; } // Fin de Buscar /******** Visualizar el árbol *************/ /* Visualizar el árbol a con margen n. * Se emplea la forma inorden, para recorrer el árbol. */ void Visualizar_Arbol (nodo *a, int n) { int i; if (!ArbolVacio) { Visualizar_Arbol (a->izdo, n + 1); /* Primero por la izq */ /* Operaciones con el nodo a */ for (i = 1; i <= n; i++) printf (" "); //printf ("%d (%d) \n", a->clave, a->contador); printf ("%d \n", a->clave); /* Ahora por la derecha */ Visualizar_Arbol (a->dcho, n + 1); } } // Fin de Visualizar_Arbol()

Departamento de Computación UNAN - León

Page 434: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 118 de 118

/* Eliminar lagunas de memoria */ void EliminarLagunas (nodo **raiz) { nodo *a, *aux; a = *raiz; /* Recorrer el árbol en postorden */ /* Primero por la izquierda */ if (!ArbolVacio) { EliminarLagunas (&a->izdo); /* Primero por la izquierda */ EliminarLagunas (&a->dcho); /* Luego por la derecha */ free (a); } a = NULL; *raiz = a; } // Fin de EliminarLagunas ()

7.3.5.7 Borrado en árboles A continuación se estudia el problema de borrar el nodo con clave x, de un árbol que tiene las claves ordenadas. Este proceso, es una tarea fácil si el nodo a borrar es un nodo terminal o si tiene un único descendiente. La dificultad se presenta cuando deseamos borrar un nodo que tiene dos descendientes, ya que con un solo puntero no puede apuntarse en dos direcciones. En este caso, el nodo a borrar debe ser reemplazado, bien por el nodo más a la derecha en el subárbol izquierdo de dicho nodo, o bien por el nodo más a la izquierda en el subárbol derecho. La Figura 7.3.16, ilustra lo expuesto.

Departamento de Computación UNAN - León

Page 435: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 119 de 119

3

1

p

z

El procemencion

1. N2. El3. El

La funcióse desciapuntadonodo apufuncio n Observareferenciserá de l typedef sborrar(x,...... /*funciónnodo *q; void(int x{ no

5

8

4

so detalados:

o hay un nodo co nodo co

n recursende a lo por q qntado po

free(q) lib

r que losa con el a forma:

truct dat&raiz);

para bor

, nodo **

do *p = *

raí

10

15

13 18

4

3 8

41

Figura 7.3.16 Borrar el nodo con clave 5.

lado, se presenta a continuación y comprend

nodo con clave igual a x. n clave x tiene un único descendiente. n clave x tiene dos descendientes.

iva borrar_nodo() se ejecuta solamente en el cas largo de la rama más a la derecha del subárbol iue se va borrar, y se reemplaza la informaciónr d, que es el nodo más a la derecha en el subáera memoria, del nodo que ya no forma parte del

valorespara los parámetros formales raíz y dr, fin de realizar los enlaces necesarios. La llama

os nodo; /*tipo nodo*/ /*llamada a la función*/

rar un nodo cualquiera del árbol*/ /*puntero al nodo a borrar*/

raiz)

raiz;

Departam

raíz

10

15

13 18

q q

e los tres casos

o 3. en este caso, zquierdode l nodo de interés en el rbol izquierdo. La árbol.

son pasados por da a esta función

ento de Computación UNAN - León

Page 436: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 120 de 120

/*descender por el árbol de raíz p, para buscar el nodo que se desea borrar*/ if(p==NULL) /*¿arbol vacio?*/ printf(“Esa componente no está en el árbol\n”); else if(x < p->clave); borrar(x,&p->izdo); else if(x > p->clave) borrar(x,&p->dcho); else /*borrar el nodo apuntado por p*/ { q = p; if(q->dcho==NULL) p=q->izdo; else if(q->izdo==NULL) p=q->dcho; else /*nodo con dos descendientes*/ borrar_nodo(&q->izdo); /*subárbol izquierdo*/ } free(q); *raíz = p; } void borrar_nodo(nodo **dr) { nodo *d = *dr; /*descender al nodo más a la derecha del subárbol d*/ if(d->dcho!=NULL) borrar_nodo(&d->dcho); else { q->clave = d->clave; q->contador = d->contador; q = d; d = d->izdo; } *dr=d; }

Departamento de Computación UNAN - León

Page 437: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 121 de 121

7.3.5.8 Árboles binarios perfectamente equilibrados Un árbol binario está perfectamente equilibrado si, para todo nodo, el número de nodos en el subárbol izquierdo y el número de nodos en el subárbol derecho, difieren como mucho en una unidad. La Figura 7.3.17, ilustra lo expuesto. n1 n=2 n=3 n=4 n=5

Figura 7.3.17 Árboles perfectamente equilibrados.

Como ejemplo, considérese el problema de construir un árbol perfectamente equilibrado, siendo los valores de los nodos, n números que se leen de fichero de datos, en nuestro caso del fichero predefinido stdin (fichero estándar de entrada). Esto puede realizarse fácilmente distribuyendo los nodos, según se leen, equivalentemente a la izquierda y a la derecha de cada nodo. El proceso recursivo que se indica a continuación es la mejor forma de realizar esta distribución. Para un número dado n de nodos y siendp ni (nodos a la izquierda) y nd (nodos a la derecha) dos enteros, el proceso es el siguiente:

1. Utilizar un nodo para la raíz.

2. Generar el subárbol izquierdo con ni = n /2.

3. Generar el subárbol con nd = n – ni –1. Cada nodo del árbol consta de los siguientes miembros_ clave, puntero al subárbol izquierdo, y un puntero al subárbol derecho. El proceso detallado se presenta a continuación y comprende una función recursiva denominada construir_arbol(), la cual construye un árbol de n nodos.

Departamento de Computación UNAN - León

Page 438: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 122 de 122

/*************Arbol perfectamente equilibrado***********/ #include<stdio.h> #include<stdlib.h> typedef struct datos nodo; /*tipo nodo*/ struct datos /*estructura de un nodo*/ { int clave; nodo *izdo; /*puntero al subarbol izquiedo*/ nodo *dcho; /*puntero al subarbol derecho*/ }; /*funciones*/ void error(void) { perror("Error: insuficiente espacio de memoria"); exit(1); } nodo *NuevoNodo() { nodo *q=(nodo *)malloc(sizeof(nodo)); if(!q) error(); return (q); } /*funciones prototipos*/ nodo *construir_arbol(int); void visualizar_arbol(nodo *, int); nodo *raiz; /*apunta a la raiz*/ /*funcion principal*/ main() { int n; system("cls"); printf("Nº de nodos: ");scanf("%d",&n); printf("Introducir claves: \n\n"); raiz = construir_arbol(n); /*construir arnol de n nodos*/ system("cls"); visualizar_arbol(raiz,0); } /**********funcion construir arbol************************/ /*construir arbol de n nodos perfectamente equilibrado */ nodo *construir_arbol(int n) { nodo *q; int ni,nd;

Departamento de Computación UNAN - León

Page 439: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 123 de 123

if(n==0) return (NULL); else { ni = n/2; /*nodos del subarbol izquierdo*/ nd = n - ni -1; /*nodos del subarbol derecho*/ q = NuevoNodo(); printf("Clave: ");scanf("%d",&q->clave); q->izdo = construir_arbol(ni); q->dcho = construir_arbol(nd); return (q); } } /***************visualizar el arbol**************************/ /*visualizar el arbol a con margen n. *se emplea la forma inorden, para recorrer el arbol */ #define ArbolVacio (a==NULL) void visualizar_arbol(nodo *a, int n) { int i; if(!ArbolVacio) { visualizar_arbol(a->izdo,n+1); for(i=1; i<=n;i++) printf(" "); printf("%d\n",a->clave); visualizar_arbol(a->dcho,n+1); } }

Departamento de Computación UNAN - León

Page 440: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 124 de 124

AALLGGOORRIITTMMOOSS DDEE OORRDDEENNAACCIIÓÓNN YY

BBÚÚSSQQUUEEDDAA

Departamento de Computación UNAN - León

Page 441: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 125 de 125

7.4 Algoritmos de ordenación y búsqueda

Título del tema 3: Algoritmos de ordenación y búsqueda.

Objetivos: • Exponer los diferentes tipos de algoritmos de ordenación y búsqueda.

• Comprobar la eficiencia de cada algoritmo de ordenación y búsqueda.

Contenido: • Introducción

• Recursividad

• Ordenación de datos

o Burbuja

o Inserción

o QuickSort

• Búsqueda de datos

o Búsqueda Secuencial

o Búsqueda Binaria.

Duración:

• 6 horas

Bibliografía básica: • Ceballos, Fco Javier. 1997. Enciclopedia del Lenguaje C. Alfaomega

RAMA.

Departamento de Computación UNAN - León

Page 442: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 126 de 126

7.4.1 Introducción En este capitulo vamos a exponer cómo resolver problemas muy comunes en la vida diaria. El primer problema que nos vamos a plantear es la recursión; estos son problemas cuyo planteamiento forma parte de su solución. El segundo problema que vamos a abordar es la ordenación de objetos en general; este es un problema tan común que no necesita explicación. Algo tan cotidiano como una guía telefónica, es un ejemplo de una lista clasificada. El localizar un determinado telefono exige una búsqueda por algún método. El problema de búsqueda será el último que resolveremos.

7.4.2 Recursividad Se dice que un proceso es recursivo si forma parte de sí mismo; o sea que se define en función de sí mismo. La recursion aparece en la vida diaria, en problemas matemáticos, en estructuras de datos y en muchos otros problemas. La recursion es un proceso extremadamente potente, por lo que la analizaremos detenidamente para saber cuándo y cómo aplicarla. Esto quiere decir que aunque un problema por definición sea recursivo, no siempre este será el método de solución más adecuado. En las aplicaciones prácticas, antes de poner en marcha un proceso recursivo, es necesario demostrar que el nivel máximo de recursión, esto es el número de veces que se va a llamar a sí mismo, es no solo finito, sino realmente pequeño. La razon es que se necesita cierta cantidad de memoria para almacenar el estado del proceso cada vez que se abandona, temporalmente, debido a una llamada para ejecutar un proceso que es él mismo. El estado en curso del proceso de cálculo hay que almacenarlo, para recuperarlo cuando se acabe la nueva ejecución del proceso y haya que reanudar la antigua. En términos de lenguaje de programación, una función es recursiva cuando se llama a sí misma. Un ejemplo es la función de Ackerman A, la cual está definida para todos los valores enterso no negativos “m” y “n” de la forma siguiente: A(0,n) = n + 1 A(m,0) = A(m-1, 1) (m > 0) A(m,n) = A(m-1, A(m, n-1)) (m,n>0) El pseudocódigo que nos muestra cómo solucionar este problema aplicando recursion es el siguiente:

Departamento de Computación UNAN - León

Page 443: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 127 de 127

<función A(m,n)> IF(m es igual a o) THEN Devolver como resultado n+1 ELSE IF (n es igual a 0) THEN Devolver como resultado A(m-1, 1) ELSE Devolver como resultado A(m-1, A(m,n-1)) ENDIF END<función A(m,n)> A continuación presentamos el programa correspondiente a este problema. Supongamos ahora que nos planteamos el problema de resolver la función de Ackerman, pero sin aplicar la recursion. Esto nos exigirá salvar las variables necesarias de proceso en curso, cada vez que la función se llame a sí misma, con el fin de poder reanudarlo cuando finalice el nuevo proceso invocado. La mejor forma de hacer esto es utilizar una pila, con le fin de almacenar los valores “m” y “n” cada vez que se invoque la función para una nueva ejecución y tomar estos valores de la cima de la pila, cuando esta nueva nueva ejecución finalice, con el fin de reanudar la antigua: El pseudocódigo para este programa puede ser el siguiente: <función A(m,n)>

Declarar un array para utilizarlo como una pila, con el fin de almacenar los valores de: m, n DO

Tomar los datos de la parte superior de la pila IF(m es igual a 0) THEN Meter en la pila el valor: n ELSE IF (n es igual a 0) THEN Meter en la pila los valores: m,n-1 ELSE Meter en la pila el valor: m-1 Meter en la pila los valores: m, n-1 ENDIF

WHILE(p sea distinto de 0) Devolver como resultado el valor n+1

END <función A(m,n)> A continuación se presenta el programa en lenguaje C:

Departamento de Computación UNAN - León

Page 444: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 128 de 128

/***********Funcion ackerman no recursiva**********/ #include<stdio.h> #include<stdlib.h> typedef struct datos elemento; typedef elemento *pelemento; struct datos { int m,n; pelemento siguiente; }; void error(void) { perror ("error: no hay suficiente espacio en la pila\n\n"); exit (1); } pelemento NuevoElemento() { pelemento q = (pelemento)malloc(sizeof(elemento)); if(!q) error(); return q; } int Ackerman (int, int); void mete_pila (pelemento *, int, int); void saca_pila (pelemento *, int *, int *); main() //funcion principal { int m, n, a; printf ("Calculo de A(m,n) = A(m-1,A(m,n-1))\n\n"); printf ("Valores de m y n: "); scanf ("%d %d", &m, &n); a = Ackerman (m,n); printf("\n\nA(%d ,%d) = %d",m,n,a); }//fin de la funcion principal ////////Ackerman////////// int Ackerman(int m, int n) { pelemento pila=NULL; int Ackerman_m_n; mete_pila(&pila, m, n); while(1) { /*tomar los datos de la cima de la pila*/ saca_pila (&pila, &m, &n); if(m == 0) /*resulatado para un elemento A(m,n) calculado */ { Ackerman_m_n = n+1;

Departamento de Computación UNAN - León

Page 445: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 129 de 129

if(pila) { saca_pila (&pila, &m, &n); mete_pila (&pila, m, n); } else return Ackerman_m_n; } else if(n == 0) mete_pila (&pila, m-1 ,1); else { mete_pila (&pila,m-1,Ackerman_m_n); /*n = Ackeman(m,n-1)*/ mete_pila (&pila, m ,n-1); } } }//fin de Akerman (m,n) ////////////////////////meter en la pila ////////////////// void mete_pila(pelemento *p, int m, int n) { pelemento q; q = NuevoElemento(); q->m = m, q->n = n; q->siguiente = *p; *p = q; } ///sacar de la pila///// void saca_pila(pelemento *p, int *pm, int *pn) { pelemento q = *p; //cabecera de la pila if(q == NULL) { printf("\n Pila Vacia \n"); exit(2); } else { *pm = q->m, *pn = q->n; *p = q->siguiente; free(q); } } Un proceso en el cual es realmente eficaz aplicar la recursion es el problema de las Torres de Hanoi. Este problema consiste en tres barras verticales A, B y C y “n” discos, de diferentes tamaños, apilados inicialmente sobre la barra A, en orden de tamaño decreciente. El objetivo es mover los discos de la barra A a la barra C, bajo las siguintes reglas;

Departamento de Computación UNAN - León

Page 446: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 130 de 130

1. Se moverá un solo disco a la vez. 2. Un disco no puede situarse sobre otro más pequeño. 3. Un disco debe encontrarse siempre en alguno de las barras. 4. Se utilizará la barra B como pila auxiliar.

Una posible solución, es el algoritmo recursivo que se muestra a continuación:

1. Mover n-1 discos de la barar A a la B. 2. Mover el n-esimo (el más grande) disco de la barra A a la C. 3. Mover los n-1 discos de la barra B a la C.

Resumiendo estas condiciones en un cuadro obtenemos:

Nº discos Origen Centro Destino Inicialmente n A B C Punto 1 n-1 A C B Punto 2 1 A B C Punto 3 n-1 B A C La funcion a realizar será mover n discos de origen a destino: mover(n_discos, origen, centro, destino) El pseudo código para este programa puede ser el siguiente: <función mover(n_discos, A, B, C)> IF(n_discos es mayor que 0) THEN mover(n_discos-1, A, C, B) mover disco de A a C mover(n_discos-1, B, A, C) ENDIf END<función mover(n_discos, A, B, C)> A continuación el codigo en lenguaje C: /************* Torres de Hanoi **********************/ #include<stdio.h> int mover(int, char, char, char); main() //función principal { int n_discos, movimientos; printf("No. de discos: "); scanf("%d",& n_discos); movimientos = mover(n_discos, 'A', 'B', 'C'); printf ("\nMovimientos efectuados: %d\n",movimientos); }// fin de la funcion principal

Departamento de Computación UNAN - León

Page 447: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 131 de 131

////// Funcion Mover /////// int mover(int n_discos, char a, char b, char c) { static int movimientos = 0; if (n_discos > 0) { mover (n_discos-1, a, c, b); printf ("Mover disco %d de %c a %c\n", n_discos,a,c); movimientos++; mover (n_discos - 1, b, a, c); } return movimientos; }

7.4.3 Ordenación de datos Uno de los procedimientos más comunes y útiles en el procesamiento de datos, es la clasificación u ordenación de los mismos. Se considera ordenar al proceso de reorganizar un conjunto dato de objetos en una secuencia determinada. El objetivo de este proceso generalmente es facilitar la búsqueda de uno o más elementos pertenecientes a un conjunto. Como ejemplo, considérense las listas de alumnos matriculados en una cierta asignatura, las listas del censo, los índices alfabéticos de los libros, las guías telefónicas, etc. Esto quiere decir que muchos problemas están relacionados de alguna forma con el proceso de ordenación. Es por lo que la ordenación es un problema importante a considerar. La ordenación, tanto numérica como alfanumérica, sigue las mismas reglas que empleamos nosotros en la vida normal. Esto es, un dato numerico es mayor que otro, cuando su valor es más grande, y una cadena de caracteres es mayor que otra, cuando por orden alfabético está después. Podemos agrupar los metodos de ordenación en dos categorías: ordenación de arrays u ordenación interna, y oredenacion de ficheros u ordenación externa, cuando los datos se guardan en memoria externa, generalmente discos. En este capitulo no tratamos de analizar exhaustivamente todos los métodos de ordenación y ver sus prestaciones de eficiencia, rapidez, etc.; nos vamos a centrar en los métodos más comunes para ordenación de arrays.

Departamento de Computación UNAN - León

Page 448: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 132 de 132

7.4.3.1 Método de la burbuja. Hay muchas formas de clasificar datos y una de las más conocidas es la clasificación por el método de la burbuja. Veamos a continuación el algoritmo correspondiente, para ordenar una lista de menor a mayor, partiendo de que los datos a ordenar están en una lista de n elementos:

1. Comparamos el primer elemento con el segundo, el segundo con el tercero el tercero con el cuarto, etc. Cuando el resultado de una comparación sea “mayor que”, se intercambian los valores de los elementos comparados. Con esto conseguimos llevar el valor mayor a la posciocin n.

2. Repetimos el punto 1, ahora para los n-1 primeros elementos de la lista y así

sucesivamente.

3. Repetimos el punto 1, ahora para los n-2 primeros elementos de la lista y así sucesivamente.

4. El proceso termina después de repetir el punto 1, n-1 veces, o cuando al

finalizar la ejecución del punto 1 no haya habido ningún cambio. Veamos con un ejemplo, cómo funciona el algoritmo: Supongamos el siguiente arreglo de enteros: {40, 21, 4, 9, 10, 35}: Primera pasada: {40, 21, 4, 9, 10, 35} {21, 40, 4, 9, 10, 35} <-- Se cambia el 21 por el 40. {21, 4, 40, 9, 10, 35} <-- Se cambia el 40 por el 4. {21, 4, 9, 40, 10, 35} <-- Se cambia el 9 por el 40. {21, 4, 9, 10, 40, 35} <-- Se cambia el 40 por el 10. {21, 4, 9, 10, 35, 40} <-- Se cambia el 35 por el 40. Segunda pasada: {21, 4, 9, 10, 35, 40} {4, 21, 9, 10, 35, 40} <-- Se cambia el 21 por el 4. {4, 9, 21, 10, 35, 40} <-- Se cambia el 9 por el 21. {4, 9, 10, 21, 35, 40} <-- Se cambia el 21 por el 10. {4, 9, 10, 21, 35, 40} <-- No hay cambio entre el 21 y el 35. {4, 9, 10, 21, 35, 40} <-- El 35 y el 40, no se comparan, porque el 40 es el mayor. En este ejemplo, los datos ya están ordenados, pero para comprobarlo habría que hacer una tercera, cuarta y quinta comprobación.

Departamento de Computación UNAN - León

Page 449: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 133 de 133

Si el array tiene N elementos, para estar seguro de que el array está ordenado, hay que hacer N -1 pasadas, por lo que habría que hacer (N-1)*(N-i-1) comparaciones, para cada i desde 1 hasta N - 1. El pseudocodigo para este algoritmo puede ser el siguiente: <funcion clasificar (array “a” de “n” elementos)> [“a” es un array cuyos elementos son a0, a1, ...., an-1] n=n-1 DO WHILE (“a” no esté ordenado y n>0) i=1 DO WHILE(i<=n) IF(a[I-1]>a[i]) THEN Permutar a[i-1] con a[i] ENDIF i=i+1 ENDDO n=n-1 ENDDO END<clasificar> El siguiente ejemplo presenta el codigo en lenguaje C correspondiente a este algoritmo: /* Implementación del algoritmo de la Burbuja */ #include <stdio.h> #define N_MAX_ELTOS 5 void Burbuja (int *, int n); void main() { int i; int vector[N_MAX_ELTOS] = {8, 2, 1, 4, 3}; Burbuja (vector, N_MAX_ELTOS); for (i = 0; i < N_MAX_ELTOS; i++) printf(" %2d", vector[i]); } // Fin del main() void Burbuja(int *vect, int N) { int i, j, aux; for (i = 0; i < N - 1; i++) // Hacer N-1 pasadas { for (j = 0; j < N - i - 1; j++) // Mirar los N-i-1 pares { if (vect[j+1] < vect[j]) // Si el elemento j+1 es menor que el elemento j: { aux = vect[j + 1]; // Se intercambian los elementos vect[j + 1] = vect[j]; // de las posiciones j y j+1

Departamento de Computación UNAN - León

Page 450: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 134 de 134

vect[j] = aux; // usando una variable auxiliar } } } } // Fin de Burbuja() En el método de la burbuja, en el caso más desfavorable se realizan (n-1)(n/2) = (n2 –n )/2 comparaciones, donde n es el número de elementos a ordenar. El número de intercambios es 0 para el caso más favorable (lista ordenada), 3(n2 - n)/4 para el caso medio y 3(n2 - n)/2 para el caso menos favorable (hay tres intercambios por cada elemento desordenado). El análisis matemático que conduce a estos valores, queda fuera del propósito de este plan docente. El tiempo de ejcucion es un múltiplo de n2 y está directamente relacionado con el número de comparaciones y de intercambios.

7.4.3.2 Método de inserción. El algoritmo para este método es le siguiente: inicialmente se ordenan los dos primeros elementos del array, luego se inserta el tercer elemento en la posición correcta con respecto a los tres primeros elementos ya clasificados y así sucesivamente hasta llegar al último elemento del array. Ejemplo: Valores inciales: 45 54 12 30 84 18 10 77

46 54 12 30 84 18 10 77

12 46 54 30 84 18 10 77

12 30 46 54 84 18 10 77

12 30 46 54 84 18 10 77

12 18 30 46 54 84 10 77

10 12 18 30 46 54 84 77

valores ordenados: 10 12 18 30 46 54 77 84

El pseudocódigo puede ser el siguiente:

Departamento de Computación UNAN - León

Page 451: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 135 de 135

<función inserción(array “a” de “n” elementos)> [“a” es un array cuyos elementos son a0, a1, ..... an-1] i=1 DO WHILE(i<=n) x=a[i] insertar x en la posición correcta entre a0 y ai ENDDO END<inserción> A continuación el codigo en lenguaje C del metodo de ordenación inserción: /*********** Ordenación por inserción **************/ #include<stdio.h> #include<stdlib.h> void insercion(int [], int); int lista[] = {46, 54, 12, 30, 84, 18, 10, 77}; int n_elementos = sizeof(lista) / sizeof(int); main() { register i; system ("cls"); inserción (lista, n_elementos); printf ("Lista ordenada: \n");

for (i = 0; i < n_elementos; i++) printf ("%6d",lista[i]); } /////////// Funcion inserción //////////////// void insercion(int lista[], int n_elementos) { int i, k,x; /*desde el segundo elemento*/ for(i=0; i<n_elementos; i++) /*para k=-1, se ha alcanzado*/ { x=lista[i]; /*el extremo izquierdp*/ k=i-1; while(k>=0 && x<lista[k]) /*x es menor que lista[k];*/ { lista[k+1] = lista[k]; k--; } lista[k+1]= x; /*insertar x en su lugar*/ } }

Departamento de Computación UNAN - León

Page 452: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 136 de 136

Análisis del método de inserción directa:

Comparaciones Intercambios Caso más favorables n-1 2 (n-1) Caso medio (n2 + n-2)/4 (n2 + 9n -10)/4 Caso más favorables (n2 + n)/2 - 1 (n2 + 3n -4)/2

Para el método de inserción, el tiempo de ejecución es función de n2 y está directamente relacionado con el número de comparaciones y de intercambios.

7.4.3.3 Método de Quicksort El metodo de ordenación Quicksort, está generalmente considerado como el mejor algoritmo de ordenación disponible actualmente. El algoritmo correspondiente a este método, es el siguiente:

1. Se selecciona un valor del array. Este valor se puede escoger aleatoriamenteo haciendo la media de un pequeño conjunto de valores tomados del array. El valor óptimo sería aquel que esté precisamente en medio del rango de valores (mediana). No obstante, incluso en el peor de los casos (el valor escogido está en un extremo), Quicksort funciona correctamente.

2. Se divide el array en dos partes, una con todos los elementos menores que el

valor seleccionado y otra con todos los elementos mayores o iguales.

3. Se repiten los puntos 1 y 2 para cada parte restante hasta que el array esté ordenado.

El proceso descrito es esencialmente recursivo. Veamos ahora un ejemplo práctico de cómo funciona este método de ordenamiento. Consideremos la siguiente lista de elementos:

7 – 5 – 3 – 8 – 9 – 10 -14 – 6 – 4 - 1 Supongamos que el elemento que se seleccionó al azar fue el 8, entonces nuestra lista se divide en dos partes, una con los mayores y una con los menores que el 8. 8

L1: 7 5 3 6 4 1 L2: 9 10 14

Departamento de Computación UNAN - León

Page 453: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 137 de 137

Si trabajamos con L1, supngamos que seleccionamos el elemento 4 al azar. Entonces nuestra lista se divide en dos partes, una con los mayores y una con los menores que el 4.

4

L1: 3 1 L2: 7 5 6 Y así sucesivamente vamos dividiendo, hasta que se llega a una lista con dos elementos, los cuales se comparan y se retornan en orden. Lo mismo sucede con la L2 del comienzo (L2: 9 - 10 - 14), dividimos hasta que se obtiene la lista con dos elementos, los cuales se ordenan y se retornan. Al finalizar, ambas listas estarán ordenadas (tanto la que tenía los mayores como la que tenía los menores que la llave seleccionada) y la lista completa estará ordenada. El pseudocódigo para este algoritmo puede ser el siguiente: <función qs(array “a”) se elige un valor x DO WHILE (“a” no esté ordenado) [dividir “a” en dos partes: a_inf y a_sup]

a_inf con los elementos ai < x a_sup con los elementos ai >= x

ENDDO IF(existe a_inf) THEN qs(a_inf) ENDIF IF(existe a_sup) THEN qs(a_sup) ENDIF END<qs> A continuación se muestra una versión de este algoritmo, el cual selecciona el elemento medio del array, lo cual resulta fácil de implementar, aunque no siempre da lugar a una buena elección. A pesar de ello, funciona correctamente. /************* Ordencion Quicksort. Método recursivo***************/ #include<stdio.h> #include<stdlib.h> void quicksort(int [], int); int lista[] = {10, 3, 7, 5, 12, 1, 27, 3, 8, 13};

Departamento de Computación UNAN - León

Page 454: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 138 de 138

int n_elementos = sizeof(lista)/sizeof(int); main() { register i; system ("cls"); quicksort (lista, n_elementos); printf (" Lista Ordenada: \n");

for (i = 0; i < n_elementos; i++) printf("%5d",lista[i]); } /////////////Quicksort//////////////////////// void qs(int [], int, int); void quicksort(int lista[], int n_elementos) { qs(lista, 0, n_elementos-1); } void qs(int lista[], int inf, int sup) { register izq, der; int mitad, x; izq = inf; der = sup; mitad = lista[(izq + der)/2]; do { while(lista[izq] < mitad && izq < sup) izq++; while(mitad < lista[der] && der > inf) der--; if(izq <= der) { x = lista[izq], lista[izq] = lista[der], lista[der] = x; izq++; der--; } }while(izq <= der); if(inf < der) qs(lista, inf, der); if(izq < sup) qs(lista, izq, sup); }

Departamento de Computación UNAN - León

Page 455: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 139 de 139

Análisis del método Quicksort: en el caso más favorable en que cada vez, se selecciona la mediana obteniéndose dos particiones iguales, se realizan n.log n comparaciones y n/6.log n intercambios, donde n es el número de elementos a ordenar; en el caso medio el rendimiento es inferior caso óptimo en un factor de 2.log 2; y en el caso menos favorable en que, cada vez, se selcciona el valor mayor obteniéndose una partición de n-1 elementos y otra de 1 elemento, el rendimiento es del orden n.n = n2. Con el fin de mejorar el caso menos favorable, se sugiere elegir, cada vez, un valor aleatorioamente o un valor que sea la mediana de un pequeño conjunto de valores tomados del array. El método de la burbuja es el peor de los métodos; el método de inserción directa, mejora considerablemente, y el método quicksort es el más rápido y mejor método de ordenación de arrays con diferencia.

7.4.4 Búsqueda de datos El objetivo de ordenar un conjunto de objetos, generalmente es facilitar la búsqueda de uno o más elementos pertenecientes a ese conjunto; aunque es posible realizar dicha búsqueda sin que el conjunto de objetos esté ordenado, pero esto trae como consecuencia un mayor tiempo de proceso.

7.4.4.1 Búsqueda secuencial. Este método de búsqueda, aunque válido, es el menos eficiente. Se basa en comparar el valor que se desea buscar con cada uno de los valores del array. El array no tiene por qué estar clasificado. El pseudocodigo puede ser: <función búsqueda_S(array a, valor que queremos buscar)> i=0 DO WHILE(no encontrado) IF(valor = a[i]) encontrado ENDIF i = i + 1 ENDDO END<Busqueda_S> A continuación se muestra una versión de este algoritmo en C. /* Búsqueda secuencial */ #include <stdio.h> #include <stdlib.h> #include <conio.h> #define TAM_LISTA 5 /* Prototipos de funciones */

Departamento de Computación UNAN - León

Page 456: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 140 de 140

void LeerDatos ( int a[] ); int BusquedaSec ( int b[], int valor); void main() { int i = 0; int a[TAM_LISTA]; int valor, result; /* Leer los valores para el arreglo a */ system ("cls"); LeerDatos (a); printf ("\n\t Valor a buscar: "); scanf ("%d", &valor ); result = BusquedaSec (a, valor); if (result != -1) printf ("\n %d encontrado en la posicion %d del arreglo \n", valor, result ); else printf ("\n %d no encontrado \n", valor ); } // Fin del main() /******************** LeerDatos ****************************/ void LeerDatos (int a[]) { int i = 0; for (i = 0; i < TAM_LISTA; i++) { printf ("\n\t a[%d]: ", i ); scanf ("%d", &a[i] ); } } // Fin de LeerDatos() /********************* Busqueda binaria **********************/ int BusquedaSec (int a[], int valor) { int i; for (i = 0; i < TAM_LISTA; i++) { if (a[i] == valor) return (i); // Retornamos el índice del valor encontrado }

Departamento de Computación UNAN - León

Page 457: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 141 de 141

return (- 1); /* valor no encontrado */ } // Fin de BusquedaSec()

DO WHILE( exista un intervalo donde buscar y no encontrado)

IF(valor = x) THEN

ELSE

ENDDO

Una versión en Lenguaje C de este algoritmo, se muestra a continuación:

#include <stdio.h>

7.4.4.2 Búsqueda Binaria Un método eficiente de búsqueda, que puede aplicarse a los arrays clasificados, es la búsqueda binaria. Partiendo de que los elementos de l array están almacenados en orden ascendente, la búsqueda binaria consiste en lo siguiente: Se selecciona el elemento del centro o aproximadamente del centro del array. Si el valor a buscar no coincide con el elemento seleccionado y es mayor que él, se continúa la búsqueda en la segunda mitad del array. Si, por el contrario, el valor a buscar es menor que el valor del elemento seleccionado, la búsqueda continúa en la primera parte del array. En ambos casos, se halla de nuevo el elemento central, correspondiente al nuevo intervalo de búsqueda, repitiéndose el ciclo. El proceso se repite hasta que se encuentra el valor a busca, o bien hasta que el intervalo de búsqueda sea nulo, lo que querrá decir que el elemento buscado no figura en el array. El pseudocódigo puede ser: <función Búsqueda_B(array a, el valor que queremos encontrar)>

x = elemento mitad del intervalo de búsqueda

Encontrado

IF(valor > x) THEN Buscar “x” en la segunda mitad del intervalo de búsqueda ENDIF IF (valor < x) THEN buscar “x” en la primera mitad del intervalo de búsqueda ENDIF ENDIF

END<Búsqueda_B>

#include <stdlib.h> #include <conio.h> #define TAM_LISTA 5 /* Prototipos de funciones */

Departamento de Computación UNAN - León

Page 458: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 142 de 142

void LeerDatos ( int a[] ); void OrdenarBurbuja ( int a[] ); void ImprimirCabecera ( void );

void main()

system ("cls");

printf ("\n\t El arreglo ordenado es: ");

ImprimirCabecera ();

result = BusquedaBin ( a, valor, 0, TAM_LISTA - 1 );

if (result != -1)

/******************** LeerDatos ****************************/

{

{ printf ("\n\t a[%d]: ", i );

void ImprimirFila ( int b[], int inf, int mitad, int sup ); int BusquedaBin ( int b[], int valor, int inf, int sup );

{ int i = 0; int a[TAM_LISTA]; int valor, result; /* Leer los valores para el arreglo a */

LeerDatos (a); OrdenarBurbuja ( a ); /* Clasificamos el arreglo */

for ( i = 0; i < TAM_LISTA; i++ ) printf ("%3d ", a[i]); printf ("\n\t Valor a buscar: "); scanf ("%d", &valor );

printf ("\n %d encontrado en la posicion %d del arreglo \n", valor, result ); else printf ("\n %d no encontrado \n", valor ); } // Fin del main()

void LeerDatos (int a[])

int i = 0;

for (i = 0; i < TAM_LISTA; i++)

scanf ("%d", &a[i] ); } } // Fin de LeerDatos()

Departamento de Computación UNAN - León

Page 459: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 143 de 143

/*************************** OrdenarBurbuja *****************/ void OrdenarBurbuja (int a[]) {

inf = mitad + 1;

int i, j, temp; for (i = 1; i <= TAM_LISTA - 1; i++) for ( j = 0; j <= TAM_LISTA - 2; j++ ) if ( a[j] > a[j + 1] ) { temp = a[j]; a[j] = a[j + 1]; a[j + 1] = temp; } } // Fin de OrdenarBurbuja() /********************* Busqueda binaria **********************/ int BusquedaBin ( int b[], int valor, int inf, int sup ) { int mitad;

while (inf <= sup) { mitad = (inf + sup) / 2; ImprimirFila ( b, inf, mitad, sup ); if (valor == b[mitad]) return ( mitad ); else if (valor < b[mitad]) sup = mitad - 1; else

} /* Fin del while */ return (- 1); /* valor no encontrado */ } // Fin de BusquedaBin() /********************** ImprimirCabecera *********************/ void ImprimirCabecera ( void ) { int i; printf ("\n Subindices: \n"); for (i = 0; i <= TAM_LISTA - 1; i++) printf ("%3d ", i); printf ("\n"); for (i = 1; i <= 4 * TAM_LISTA; i++)

Departamento de Computación UNAN - León

Page 460: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 144 de 144

printf ("-"); printf ("\n"); } // Fin de ImprimirCabecera() /************************ ImprimirFila ***************************/ void ImprimirFila ( int b[], int inf, int mitad, int sup ) { int i; for (i = 0; i <= TAM_LISTA - 1; i++) if ( i < inf || i > sup ) printf (" "); else if ( i == mitad ) printf ("%3d*", b[i]); /* marcar el valor mitad */ else printf ("%3d ", b[i]); printf ("\n"); } // Fin de ImprimirFila()

Departamento de Computación UNAN - León

Page 461: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 145 de 145

PPRRÁÁCCTTIICCAASS DDEE LLAABBOORRAATTOORRIIOO

Departamento de Computación UNAN - León

Page 462: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 146 de 146

8 PRACTICAS DE LABORATORIO A medida que se avanza en la asignatura en aspectos teóricos, también es importante ir realizando prácticas de laboratorio, para que el estudiante conozca que lo explicado en el aula de clases es aplicable a la realidad del computador. Estas prácticas también le servirán al alumno para afianzar y reforzar la visión que tienen de las cuestiones teóricas de libros y apuntes. En esta sección se describe el programa de prácticas de la asignatura Algoritmos y Estructuras de Datos. Objetivos de las prácticas de Laboratorio

• Familiarizar al estudiante en el manejo del entorno integrado de desarrollo que ofrece el compilador Microsoft Visual C++ 6.0, para la gestión los archivos de programas y para el tratamiento y depuración de errores.

Duración del laboratorio

Para el laboratorio se cuenta con 2 horas semanales. Cada grupo deberá haber leído y analizado previamente el contenido de la práctica para llegar al laboratorio con ideas claras de lo que hay que realizar. Al inicio del laboratorio el profesor explicará en qué consiste la práctica y estará en el laboratorio para responder dudas y ayudar a los alumnos.

• Desarrollar habilidades en los estudiantes que les permitan implementar, las propuestas de algoritmos teóricos, en programas eficientes escritos en Lenguaje C.

• Adquirir destrezas para comprender los distintos tipos de errores que se

puedan originar en la escritura de un programa, y la forma de cómo resolverlos.

Conformación de los grupos y criterios de evaluación

La conformación de los grupos será como máximo de dos alumnos. La asistencia a los laboratorios es obligatoria, ya que la evaluación es acumulativa. La nota total del laboratorio representa un 30% de las notas parciales de la asignatura. Los estudiantes deberán realizar todas las prácticas establecidas en tiempo y forma para poder tener derecho al porcentaje del laboratorio. Cada grupo deberá entregar cada práctica funcionando y responder a las preguntas hechas por el profesor.

Enunciados de las prácticas

Los enunciados de las prácticas, serán dados a conocer por el (los) profesor (es) de la práctica desde el primer día de clases. Dichos enunciados se publicarán en la

Departamento de Computación UNAN - León

Page 463: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 147 de 147

página web de la asignatura, y estarán disponibles en la secretaría del Departamento para reproducciones en fotocopias o mediante el servicio de impresión. Entrega de las prácticas asignadas Las prácticas deberán ser entregadas en el tiempo estipulado por el profesor de la práctica. Las memorias de las prácticas, deberán estar impresas en papel y serán entregadas en algún medio de almacenamiento como, diskettes, CDs, etc, junto con el código fuente de los programas correspondientes a dicha práctica. La memoria impresa, deberá tener contener los siguientes elementos: Apartado del documento

Contenido

Carátula • Titulo de la práctica.

• Nombre de los 2 integrantes.

• Nombre del profesor que imparte la práctica.

• Fecha de entrega.

Enunciado de la práctica

• Dado por el profesor (No es necesario incluirlo en el reporte).

Solución • Es la propuesta del estudiante para resolver el

problema planteado por el profesor.

• Dicha solución puede constar de gráficos o ilustraciones adicionales a las dadas por el profesor en el enunciado de la práctica; cuando éste sea el caso, dichos gráficos deberán llevar la explicación pertinente del por qué se utilizaron y cómo ayuda a la solución del problema.

• Todo el código que se presente, deberá ir debida y

profusamente comentado.

• El código deberá ser legible, de acuerdo a las recomendaciones éticas dadas por el profesor en clases.

Herramientas utilizadas • El Software utilizado para compilar y ejecutar los

programas; en este caso, el compilador Microsoft Visual C++ 6.0, o algún otro compilador que cumpla con estándar del ANSI C.

• Algún editor de texto utilizado para elaborar el

documento de entrega de la práctica.

Explicación de la • Incluir la explicación de los aspectos más relevantes o

Departamento de Computación UNAN - León

Page 464: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 148 de 148

donde se presentó mayor dificultad. solución

Presentación de Resultados

• Se deberá mostrar las entradas de datos (si es que las hay) por parte del usuario y las salidas que originan esas entradas. Se recomienda probar con 2 o 3 entradas diversas para observar con fiabilidad los resultados.

Conclusiones • Redactar las metas alcanzadas (debe ir de acorde con

los objetivos de la práctica, los cuales están en el enunciado proporcionado por el profesor).

Recomendaciones Aquí se escribirán las sugerencias que sobre el desarrollo

del programa tenga el alumno; podrá sugerir una mejora de su solución para futuras prácticas, etc.

Bibliografía • Referencias documentales que utilizó el estudiante para dar solución a la práctica (pueden ser libros, folletos, sitios de Internet, revistas, manuales, etc)

Software a utilizar Se utilizarán los siguientes software:

• Sistema Operativo Windows 2000 Proffesional.

• Microsoft Visual C++ 6.0

• Microsoft Word 2000.

Departamento de Computación UNAN - León

Page 465: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 149 de 149

8.1 Planificación temporal Como ya se ha mencionado en el apartado Temporización, para el desarrollo de las prácticas de laboratorio se cuenta con una sesión de dos horas por semana, para un total de 28 horas a lo largo de las 14 semanas netas con las que se cuenta para el laboratorio. El número de horas asignadas para cada práctica ha sido obtenido en base a la complejidad relativa y al tiempo total disponible. Se ha buscado en la medida de lo posible, que exista una concordancia entre la teoría y la práctica, de manera que al realizar cada práctica de laboratorio, ya se han impartido los conocimientos teóricos necesarios para poder desarrollarla. Sumado a esto, el alumno tendrá a disposición en la página web de la asignatura y en la secretaría del Departamento, toda la documentación adicional necesaria (tutoriales, manuales, etc) para no tener inconveniente alguno en el desarrollo de las prácticas. En la Tabla 8.1.1 se muestra la duración de las prácticas, su relación con la teoría y las horas necesarias para desarrollarlas:

Departamento de Computación UNAN - León

Page 466: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 150 de 150

Tabla 8.1.1 Temporización de las prácticas y su relación con la teoría.

Semana Teoría Práctica Semanas

necesarias 1 -Presentación de la asignatura 2 Introducción a los algoritmos.

Práctica 1 Cuadrado Mágico

1

3

Introducción a los algoritmos. Práctica 2 El Salto delCaballo.

1

4

Introducción a los algoritmos Práctica 3 Las Ocho Reinas

1

5 6

Estructuras Dinámicas de Datos Práctica 4 Aplicación de Listas Lineales: Diccionario Inglés – Español

2

7

Estructuras Dinámicas de Datos Práctica 5 Aplicación de Pilas : Evaluación de Expresiones PostFijas.

1

8 9 10

Estructuras Dinámicas de Datos Aplicación de Colas: Simulación de llegadas de clientes a un banco.

Práctica 6

3

11 Estructuras Dinámicas de Datos Práctica 7: Recorrido de un árbol binario

1

12

Búsqueda en arreglos de estructuras

Algoritmos de ordenación y búsqueda

Práctica 8: Juego del Tarot con 2 versiones recursivas.

1

13 Algoritmos de ordenación y búsqueda Ordenación y búsqueda en listas dinámicas.

14 Práctica 9:

2

Departamento de Computación UNAN - León

Page 467: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 151 de 151

8.2 Propuesta y solución de prácticas

8.2.1 Práctica 1

CUADRADRO MÁGICO

OBJETIVO

Aplicar los conocimientos de Lenguaje C adquiridos en los cursos de Programación I y II, así como el diseño eficiente de algoritmos, para dar solución al problema de la construcción del cuadrado mágico.

2

TIEMPO DE REALIZACIÓN DE LA PRÁCTICA

1 sesión de laboratorio (2 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN

Un cuadrado mágico se compone de números enteros comprendidos entre 1 y n2, donde n es un número impar que indica el orden de la matriz cuadrada que contiene los números que forman dicho cuadrado mágico. La matriz que forma este cuadrado mágico cumple que la suma de los valores que componen cada fila, cada columna y cada diagonal es la misma. Por ejemplo, un cuadrado mágico de orden 3 puede ser el siguiente: Un valor de n = 3 implica una matriz de 3 por 3. Por lo tanto, los valores de la matriz estarán comprendidos entre 1 y 9 y dispuestos como indica la Figura 8.2.1:

8 1 6 3 5 7 4 9

Figura 8.2.1 Cuadrado mágico para una matriz de 3 x 3.

Departamento de Computación UNAN - León

Page 468: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 152 de 152

DESARROLLO DE LA PRÁCTICA Una forma de construir un cuadrado mágico consiste en situar el número 1 en el centro de la primera línea, el número siguiente en la casilla situada encima a la derecha, y así sucesivamente. Es preciso tener en cuenta que el cuadrado mágico se cierra sobre sí mismo, esto es, la línea encima de la primera es la última y la columna a la derecha de la última es la primera. Siguiendo esta regla, cuando el número caiga en una casilla ocupada, se elige la casilla situada debajo del último número situado. El programa deberá implementar al menos las siguientes funciones: int esImpar(int n); Verifica que n sea un número impar. Devuelve 0 si el n es par y 1 si n es impar. void cuadradoMagico(int nElem); Crear un cuadrado mágico de nElem filas y nElem columnas. void mostrarCuadrado(int **cuadm, int nElem); Muestra en pantalla el cuadrado mágico creado por la función cuadradoMagico. Al correr el programa que crea el cuadrado mágico éste debe mostrar resultados como los siguientes: Datos para el cuadrado magico... Dimensiones del cuadrado: 3 8 1 6 3 5 7 4 9 2 Press any key to continue Datos para el cuadrado magico... Dimensiones del cuadrado: 5 17 24 1 8 15 23 5 7 14 16 4 6 13 20 22 10 12 19 21 3 11 18 25 2 9 Press any key to continue

Departamento de Computación UNAN - León

Page 469: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 153 de 153

Solución de la práctica 1 APARTADO SOLUCIÓN: /**************************** El Cuadrado Magico ****************************/ /* magico.c */ #include <stdio.h> #include <stdio.h> #include <conio.h> int esImpar(int n); void cuadradoMagico(int nElem); void mostrarCuadrado(int **cuadm, int nElem); int main (void) { int n = 0; do { system("cls"); printf("Datos para el cuadrado magico..."); printf("\nDimensiones del cuadrado: "); scanf("%d",&n); } while ((esImpar(n) != 0) && n >= 3 && n <= 15); cuadradoMagico(n); return(0); } int esImpar(int n) { if ((n % 2) == 0) return(1); else return(0); } void cuadradoMagico(int nElem) { int ** cuadm; int i = 0, j = 0; int num = 1; int lfil = 0, lcol = 0; if ((cuadm = (int **) malloc (nElem * sizeof(int *))) == NULL) { puts("\nNo se pudo asignar memoria..."); exit(-1); } for (i = 0; i < nElem; i++)

Departamento de Computación UNAN - León

Page 470: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 154 de 154

{ if ((cuadm[i] = (int *) malloc(nElem * sizeof(int))) == NULL) { puts("\nNo se pudo asignar memoria..."); exit(-1); } } for (i = 0; i < nElem; i++) for (j = 0; j < nElem; j++) cuadm[i][j] = 0; /* Iniciamos la construccion del cuadrado magico */ i = 0; j = nElem / 2; do { if (cuadm[i][j] == 0) { cuadm[i][j] = num; lfil = i; lcol = j; i--; if (i < 0) i = nElem - 1; j++; if (j > (nElem - 1)) j = 0; num++; } else { cuadm[lfil+1][lcol] = num; lfil = lfil + 1; if (lfil >= (nElem + 1)) lfil = -1; // Al verificar la fila se cambia a Cero lcol = lcol; i++; if (i > (nElem - 1)) i = 0; num++; } } while (num <= (nElem * nElem)); /* Imprimir el cuadrado magico :) */ mostrarCuadrado(cuadm,nElem);

Departamento de Computación UNAN - León

Page 471: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 155 de 155

/* Liberar la memoria */ for (i = 0; i < nElem; i++) free(cuadm[i]); free(cuadm); } void mostrarCuadrado(int **cuadm, int nElem) { int i = 0, j = 0; for (i = 0; i < nElem; i++) { for (j = 0; j < nElem; j++) printf(" %3d ", cuadm[i][j]); printf("\n"); } }

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Compilador Microsoft Visual C++ 6.0 para la compilación del archivo fuente y la construcción de archivo ejecutable.

• Microsoft Word XP para la edición del documento de entrega de la práctica.

La parte esencial de esta práctica se encuentra en la función cuadradoMagico.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN

void cuadradoMagico(int nElem) Esta función utiliza las siguientes variables locales para crear el cuadrado mágico: int ** cuadm; int i = 0, j = 0; int num = 1; int lfil = 0, lcol = 0; int ** cuadm es un arreglo de punteros a enteros. Este arreglo representa al cuadrado mágico. Las variables locales i y j son utilizadas como índices del cuadrado mágico. Int num es el número actual a colocar en el cuadrado mágico. lfil y

Departamento de Computación UNAN - León

Page 472: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 156 de 156

lcol son variables que alojan los índices de la última fila y la última columna respectivamente, en las que se colocó un número. Luego de asignar memoria y de inicializar todos los elementos del arreglo a cero se inicia el método de construcción del cuadrado mágico descrito en el enunciado de la práctica. /* Iniciamos la construccion del cuadrado magico */ i = 0; j = nElem / 2; do { if (cuadm[i][j] == 0) { cuadm[i][j] = num; lfil = i; lcol = j; i--; if (i < 0) i = nElem - 1; j++; if (j > (nElem - 1)) j = 0; num++; } else { cuadm[lfil+1][lcol] = num; lfil = lfil + 1; if (lfil >= (nElem + 1)) lfil = -1; // Al verificar la fila se cambia a Cero lcol = lcol; i++; if (i > (nElem - 1)) i = 0; num++; } } while (num <= (nElem * nElem)); Este ciclo es el encargado de construir el cuadrado mágico. Primero se inician los índices a la posición inicial recomendada en el enunciado de la práctica (a la mitad de la primera fila del cuadrado mágico). Luego se entra en un ciclo que termina cuando se haya rellenado todo el cuadrado mágico.

Departamento de Computación UNAN - León

Page 473: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 157 de 157

Para colocar un número dentro del cuadrado mágico, se verifica que la casilla no se ha utilizado antes, si no se ha utilizado entonces se coloca el número en esa posición y se incrementa num, se actualizan las variables lfil y lcol a la nueva posición y se repite el ciclo.

Si la casilla del cuadrado mágico ya estaba ocupada, entonces el número es colocado en la siguiente fila en la misma columna, se incrementa num, se actualizan las variables lfil y lcol y se repite el ciclo.

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS

En esta sección se presentará los resultados que ha originado la ejecución del programa.

Nota: Las entradas del usuario están en negritas cursivas y en subrayado. PRIMERA EJECUCIÓN: Datos para el cuadrado magico... Dimensiones del cuadrado: 7

30 39 48 1 10 19 28

46 6 8 17 26 35 37

Dimensiones del cuadrado: 9

38 47 7 9 18 27 29

5 14 16 25 34 36 45 13 15 24 33 42 44 4 21 23 32 41 43 3 12 22 31 40 49 2 11 20 Press any key to continue SEGUNDA EJECUCIÓN: Datos para el cuadrado magico...

47 58 69 80 1 12 23 34 45 57 68 79 9 11 22 33 44 46 67 78 8 10 21 32 43 54 56 77 7 18 20 31 42 53 55 66 6 17 19 30 41 52 63 65 76 16 27 29 40 51 62 64 75 5 26 28 39 50 61 72 74 4 15 36 38 49 60 71 73 3 14 25 37 48 59 70 81 2 13 24 35 Press any key to continue

Departamento de Computación UNAN - León

Page 474: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 158 de 158

BBIIBBLLIIOOGGRRAAFFÍÍAA

Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programar en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

Departamento de Computación UNAN - León

Page 475: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 159 de 159

8.2.2 Práctica 2

EL SALTO DEL CABALLO OBJETIVO

TIEMPO DE REALIZACIÓN DE LA PRÁCTICA

1 sesión de laboratorio (2 horas)

Aplicar los conocimientos de Lenguaje C adquiridos en los cursos de Programación I y II, así como el diseño eficiente de algoritmos, para dar solución al problema del salto del caballo.

SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN Uno de los acertijos más interesantes para los aficionados del ajedrez es el problema del salto del caballo, propuesto originalmente por el matemático Euler. La pregunta es la siguiente: ¿Puede la pieza de ajedrez conocida como el caballo moverse en el interior de un tablero de ajedrez vacío y entrar en contacto con cada una de las 64 casillas, una y sólo una vez? El caballo hace movimientos en forma de L (dos en una dirección y a continuación uno en una dirección perpendicular). Entonces a partir de una casilla en la mitad de un tablero de ajedrez vacío, el caballo puede efectuar ocho movimientos diferentes.

2 1 3 8 C 4 7 5 6

Figura 8.2.2 Un posible moivimiento del caballo.

Departamento de Computación UNAN - León

Page 476: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 160 de 160

Podemos describir los ocho movimientos posibles en términos tanto de sus componentes horizontales como verticales. Por ejemplo: un movimiento de tipo 1 (Figura 8.2.2), consiste en mover verticalmente dos casillas hacia arriba y horizontalmente 1 casilla a la derecha. Los movimientos horizontales a la izquierda y los movimientos verticales hacia abajo se indicarán con números negativos. Los ocho movimientos pueden ser descritos en dos arreglos de un solo subíndice, horizontal y vertical, como sigue:

horizontal[0] = 2; vertical[0] = -1; horizontal[1] = 1; vertical[1] = -2; horizontal[2] = -1; vertical[2] = -2; horizontal[3] = -2; vertical[3] = -1; horizontal[4] = -2; vertical[4] = 1; horizontal[5] = -1; vertical[5] = 2; horizontal[6] = 1; vertical[6] = 2; horizontal[7] = 2; vertical[7] = 1;

DESARROLLO DE LA PRÁCTICA La solución al problema del salto del caballo esta basada en el método de tanteo sistemático (prueba y error). La función más importante es: int testMove(int n, int posX, int posY); Esta función es la encargada de realizar el tanteo sistemático y su pseudocódigo es el siguiente:

REPETIR seleccionar el nuevo candidato de la lista de futuros movimientos SI aceptable ENTONCES

SI tablero no lleno ENTONCES LLAMAR ensayar nuevo movimiento SI no acertado ENTONCES

borrar la anotación anterior FINSI

FINSI FINSI

HASTA movimiento acertado O no hay más posibilidades int n indica el número de casillas que ha visitado el caballo. Este valor aumenta cada vez que el caballo realiza un movimiento acertado. int posX e int posY indican la posición actual del caballo, estos valores son actualizados cada vez que el caballo realiza un movimiento exitoso. void printBoard(void); Esta función muestra en pantalla el tablero por el que se ha desplazado el caballo durante su recorrido.

Departamento de Computación UNAN - León

Page 477: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 161 de 161

Además se deberá llevar un contador que varíe desde 1 hasta 64 (valores que tomará el parámetro n en la función testMove). Registre la última cuenta en cada casilla movida por el caballo. Recuerde probar cada movimiento potencial para asegurarse que el caballo no haya visitado ya esa casilla y naturalmente, pruebe cada movimiento potencial, para asegurar que el caballo no se ha salido del tablero de ajedrez.

20 7 24 41 50 3 58 43

A continuación se presentan los resultados generados por la ejecución de una solución al problema del salto del caballo. Introduzca las coordenadas de inicio (x,y): 0,0 El Resultado es: 1 24 9 62 39 26 45 60 10 63 2 25 44 61 38 27 23 8 11 40 21 42 59 46 64 3 22 43 58 47 28 37 7 12 5 20 41 36 57 48 4 17 14 31 50 29 54 35 13 6 19 16 33 52 49 56 18 15 32 51 30 55 34 53 TIEMPO DE EJECUCION DEL ALGORITMO: 15 segundos. Press any key to continue Introduzca las coordenadas de inicio (x,y): 0,7 El Resultado es: 64 9 18 31 34 39 60 1 17 30 63 10 61 32 35 38 8 19 28 33 40 37 2 59 29 16 11 62 27 42 49 36

15 12 21 26 55 46 51 48 6 25 14 23 4 53 44 57 13 22 5 54 45 56 47 52 TIEMPO DE EJECUCION DEL ALGORITMO: 4 segundos. Press any key to continue Introduzca las coordenadas de inicio (x,y): 7,0 El Resultado es: 64 19 14 5 30 21 34 47 13 4 63 20 33 48 31 36 18 15 6 29 22 35 46 49 3 12 17 62 51 32 37 60 16 7 28 23 38 61 50 45 11 2 9 52 25 42 59 56

Departamento de Computación UNAN - León

Page 478: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 162 de 162

8 27 24 39 54 57 44 41 1 10 53 26 43 40 55 58 TIEMPO DE EJECUCION DEL ALGORITMO: 151 segundos. Press any key to continue Introduzca las coordenadas de inicio (x,y): 7,7

22 19 36 3 34 55 38 1

Press any key to continue

El Resultado es: 7 28 63 14 61 30 43 50 64 13 8 29 42 51 60 31 27 6 15 62 25 58 49 44 12 9 26 41 52 45 32 59 5 16 11 24 57 40 53 48 10 21 18 35 46 33 56 39 17 4 23 20 37 2 47 54

TIEMPO DE EJECUCION DEL ALGORITMO: 1 segundos.

Departamento de Computación UNAN - León

Page 479: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 163 de 163

Solución de la práctica 2 APARTADO SOLUCIÓN: /************************* Salto del Caballo *************************/ /* caballo.c */ #include <stdio.h> #include <time.h> #define TRUE 1 #define FALSE 0 #define N_CUADROS 8 #define N_SALTOS 8 ////////////////////////////////////////// //Funciones Prototipos void initBoard(void); //Inicializa el Tablero void printBoard(void); //Visualiza el Tablero int testMove(int n, int posX, int posY); //Prueba los movimientos del caballo. int board[N_CUADROS][N_CUADROS]; //Tablero de Ajedrez //-->Maximo de Movimientos posibles desde una casilla en el Centro del Tablero static int vertical[N_SALTOS] = {2,1,-1,-2,-2,-1,1,2}; static int horizontal[N_SALTOS] = {-1,-2,-2,-1,1,2,2,1}; //<-- void main() { int horsemove = 1; int currentRow = 0; int currentColumn = 0; long t_inicio = 0; long t_fin = 0; system("cls"); initBoard(); printf("Introduzca las coordenadas de inicio (x,y): "); scanf("%d,%d",&currentRow,&currentColumn); printf("\n\t ESPERE POR FAVOR ..."); t_inicio = clock(); testMove(horsemove,currentRow,currentColumn); t_fin = clock();

Departamento de Computación UNAN - León

Page 480: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 164 de 164

printBoard(); printf("\n\n TIEMPO DE EJECUCION DEL ALGORITMO: %ld segundos.",(t_fin - t_inicio)/CLOCKS_PER_SEC); } ///////////////////////////////////////////////////////////////////////////// // Funciones void initBoard(void) { int i = 0, j = 0; for (i = 0; i < N_CUADROS; i++) for (j = 0; j < N_CUADROS; j++) board[i][j] = 0; } void printBoard(void) { int i = 0, j = 0; system("cls"); printf("\nEl Resultado es: \n\n"); for (i = 0; i < N_CUADROS; i++) { for (j = 0; j < N_CUADROS; j++) printf("%2d ",board[i][j]); printf("\n"); } } int testMove(int nMov, int x, int y) { int moveNumber = 0; int xPos = 0; int yPos = 0; board[x][y] = nMov; if (nMov == (N_CUADROS * N_CUADROS)) // No hay mas movimientos posibles return TRUE; else { for(moveNumber = 0; moveNumber < N_SALTOS; moveNumber++) { xPos = x + vertical[moveNumber]; yPos = y + horizontal[moveNumber];

Departamento de Computación UNAN - León

Page 481: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 165 de 165

//--Esta el caballo dentro del tablero? if ((xPos >= 0) && (xPos <= 7) && (yPos >= 0) && (yPos <= 7)) { //--Se ha visitado esta casilla antes? if (board[xPos][yPos] == 0) { if (testMove(nMov+1,xPos,yPos)) return TRUE; } } } } board[x][y] = 0; //Movimiento no valido return FALSE; }

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Compilador Microsoft Visual C++ 6.0 para la compilación del archivo fuente y la construcción de archivo ejecutable.

• Microsoft Word XP para la edición del documento de entrega de la práctica.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN El programa solicita al usuario la posición inicial del caballo dentro del tablero y a partir de esa posición calcula los posibles movimientos que el caballo puede realizar, este trabajo lo realiza la función testMove. int testMove(int nMov, int x, int y) La función recibe como argumentos el número de movimiento realizados por el caballo al momento de ser invocada la función (int nMov) y la posición del caballo en el tablero (int x, int y). Además la función testMove devuelve TRUE si se ha encontrado una solución (se ha realizado un recorrido completo) y FALSE en caso de no haber solución. Esta función utiliza la técnica de backtracking para “borrar” un movimiento no válido y probar una nueva opción.

Departamento de Computación UNAN - León

Page 482: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 166 de 166

Como se explicó en el enunciado de la práctica desde una posición central en el tablero el caballo solo pude realizar 8 movimientos distintos. Estos movimientos se representan con los arreglos: static int vertical[N_SALTOS] = {2,1,-1,-2,-2,-1,1,2}; static int horizontal[N_SALTOS] = {-1,-2,-2,-1,1,2,2,1}; El ciclo principal de la función tiene un máximo de ocho iteraciones que corresponden a los ocho movimientos representados por estos arreglos. Para cada movimiento se verifica que este no se salga del tablero, si el movimiento no se sale del tablero se verifica que no se haya visitado esta casilla antes y si no se ha visitado esta casilla antes se hace una llamada recursiva a la función testMove para buscar el siguiente “salto” del caballo. Si el ciclo realiza sus ocho iteraciones y encuentra un movimiento válido, se realiza backtracking esto es, se eliminan todos los movimientos anteriores hasta encontrar el último movimiento válido y probar con otro movimiento de los arreglos de movimientos a partir de este. for(moveNumber = 0; moveNumber < N_SALTOS; moveNumber++) { xPos = x + vertical[moveNumber]; yPos = y + horizontal[moveNumber]; //--Esta el caballo dentro del tablero? if ((xPos >= 0) && (xPos <= 7) && (yPos >= 0) && (yPos <= 7)) { //--Se ha visitado esta casilla antes? if (board[xPos][yPos] == 0) { if (testMove(nMov+1,xPos,yPos)) return TRUE; } } } } board[x][y] = 0; //Movimiento no valido return FALSE; } Una vez que se ha realizado un recorrido completo (se han realizado 64 movimientos) se imprime el resultado.

Departamento de Computación UNAN - León

Page 483: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 167 de 167

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. PRIMERA EJECUCIÓN: Nota: Las entradas del usuario están en negritas cursivas y en subrayado. Introduzca las coordenadas de inicio (x,y): 0,0 ESPERE POR FAVOR ... El Resultado es: 1 24 9 62 39 26 45 60 10 63 2 25 44 61 38 27 23 8 11 40 21 42 59 46 64 3 22 43 58 47 28 37 7 12 5 20 41 36 57 48 4 17 14 31 50 29 54 35 13 6 19 16 33 52 49 56 18 15 32 51 30 55 34 53 TIEMPO DE EJECUCION DEL ALGORITMO: 13 segundos. Press any key to continue SEGUNDA EJECUCIÓN: Introduzca las coordenadas de inicio (x,y): 7,7

10 21 18 35 46 33 56 39

ESPERE POR FAVOR ... El Resultado es: 7 28 63 14 61 30 43 50 64 13 8 29 42 51 60 31 27 6 15 62 25 58 49 44 12 9 26 41 52 45 32 59 5 16 11 24 57 40 53 48

17 4 23 20 37 2 47 54 22 19 36 3 34 55 38 1 TIEMPO DE EJECUCION DEL ALGORITMO: 1 segundos. Press any key to continue

Departamento de Computación UNAN - León

Page 484: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 168 de 168

CCOONNCCLLUUSSIIOONNEESS

Una vez finalizada la práctica, hemos concluido que los objetivos propuestos en el enunciado, el uso de la técnica de backtracking, se han cumplido satisfactoriamente. Esta técnica fue de gran utilidad para solución del problema del salto del caballo.

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programar en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

La resolución de este problema nos ha sido de mucha ayuda para la comprensión del uso de la programación para la solución de problemas en los que se requiere gran volumen de cálculos.

RREECCOOMMEENNDDAACCIIOONNEESS

Las recomendaciones que hacemos, es que en un futuro, este problema puede resolverse utilizando otros lenguajes de programación como Java para añadir una interfaz gráfica y por ejemplo poder ver al caballo desplazándose por el tablero de ajedrez.

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

Departamento de Computación UNAN - León

Page 485: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 169 de 169

8.2.3 Práctica 3

LAS OCHO REINAS OBJETIVO Aplicar los conocimientos de Lenguaje C adquiridos en los cursos de Programación I y II, así como el diseño eficiente de algoritmos, para dar solución al problema de las Ocho Reinas.

TIEMPO DE REALIZACIÓN DE LA PRÁCTICA

1 sesión de laboratorio (2 horas)

INTRODUCCIÓN

SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0

El problema de las ocho reinas consiste en situar ocho reinas en un tablero de ajedrez, de forma que ninguna dama pueda actuar sobre cualquiera de las otras. Dado que se sabe, por las reglas del ajedrez, que una reina actúa sobre todas las piezas situadas en la misma columna, fila y diagonal del tablero se deduce que cada columna puede contener una y sólo una reina, y que la elección de la situación de la reina i-ésima puede restringirse a los cuadros de la columna i. Por tanto, el parámetro i se convierte en el índice de columna, y por ello el proceso de selección de posiciones queda limitado a los ocho posibles valores del índice de fila j. Dicho simplemente: es o no posible colocar ocho reinas en un tablero de ajedrez vacío de tal forma que ninguna reina esté atacando a ninguna otra, esto es de tal forma que ¿ningún par de reinas estén en el mismo renglón, la misma columna o a lo largo de la misma diagonal? DESARROLLO DE LA PRÁCTICA La dificultad que plantea este problema es la representación de los datos. Se puede utilizar un array bidimensional de tamaño 8 x 8, pero las operaciones para encontrar una reina que amenace a otra son algo engorrosas Es lógico que cada reina deba ir en una fila distinta. Por tanto, en un array se guarda la posición de cada reina en la columna que se encuentre. Ejemplo: si en la tercera fila hay una reina situada en la quinta columna, entonces la tercera posición del array guardará un 5. A este array se le llamará col. Hace falta otro array que

Departamento de Computación UNAN - León

Page 486: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 170 de 170

determine si hay puesta una reina en la fila j-ésima. A este array se le llamará fila. Por último se utilizan dos arrays más para determinar las diagonales libres, y se llamarán diagb y diagc. El programa deberá implementar la siguiente función: void ensayar(int i, boolean *q, int col[], boolean fila[], boolean diagb[], boolean diagc[]); Esta es la función que determina cuando colocar una reina en una casilla cualquiera y además determina cuando ha encontrado una solución al problema.

FINSI

Q - - - - - - -

El pseudocódigo de la función ensayar se muestra a continuación:

inicializar el conjunto de posiciones de la reina i-ésima REPETIR hacer la selección siguiente

SI segura ENTONCES poner reina SI i < 8 ENTONCES

LLAMAR ensayar (i + 1) SI no acertado ENTONCES

quitar reina FINSI

FINSI HASTA acertada O no hay más posiciones

Una vez encontrada una solución esta debe presentarse en pantalla. A continuación se muestra una corrida de ejemplo para ilustrar las salidas que debe presentar el programa. Solucion:

- - - - Q - - - - - - - - - - Q - - - - - Q - - - - Q - - - - - - - - - - - Q - - Q - - - - - - - - - Q - - - - Press any key to continue

Departamento de Computación UNAN - León

Page 487: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 171 de 171

Solución de la práctica 3 APARTADO SOLUCIÓN: /******************************** LAS OCHO REINAS ********************************/ /* reinas.c */ #include <stdio.h> enum bool {FALSE, TRUE}; typedef enum bool boolean; void ensayar(int i, boolean *q, int col[], boolean fila[], boolean diagb[], boolean diagc[]); int main(void) { int i = 0, j = 0; boolean q; int col[8]; boolean fila[8],diagb[15], diagc[15]; for (i = 0; i < 8; i++) fila[i] = TRUE; for (i = 0; i < 15; i++) diagb[i] = diagc[i] = TRUE; ensayar(0,&q,col,fila,diagb,diagc); //Si se encontro una solucion, se imprime cada reina con su posicion en el tablero if (q) { printf("\nSolucion:\n\n"); for (i = 0; i < 8; i++) { for (j = 0; j < 8; j++) { /* * si la columna actual corresponde con la posicion * de la reina i, imprimir Q */ if (j == col[i]) printf(" Q "); else printf(" - "); } printf("\n"); } } else printf("\nNo hay solucion"); return 0; }

Departamento de Computación UNAN - León

Page 488: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 172 de 172

void ensayar(int i, boolean *q, int col[], boolean fila[], boolean diagb[], boolean diagc[]) { int j; j = 0; *q = FALSE; do { if (fila[j] && diagb[i+j] && diagc[7+i-j]) { col[i] = j; fila[j] = diagb[i+j] = diagc[7+i-j] = FALSE; if (i < 7) /* se ha encontrado una solucion? */ { ensayar(i+1,q,col,fila,diagb,diagc); if (!*q) fila[j] = diagb[i+j] = diagc[7+i-j] = TRUE; } else *q = TRUE; /* se encontro una solucion! */ } j++; } while (!*q && j < 8); }

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Compilador Microsoft Visual C++ 6.0 para la compilación del archivo fuente y la construcción de archivo ejecutable.

• Microsoft Word XP para la edición del documento de entrega de la práctica.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN La parte esencial de esta solución se encuentra en la función ensayar. void ensayar(int i, boolean *q, int col[], boolean fila[], boolean diagb[], boolean diagc[]);

Departamento de Computación UNAN - León

Page 489: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 173 de 173

Dentro de esta función se verifica si la reina en la posición actual no ataca a otras reinas en la misma fila y diagonales. Si esta condición se cumple entonces se coloca la reina en dicha posición. if (fila[j] && diagb[i+j] && diagc[7+i-j]) { col[i] = j; fila[j] = diagb[i+j] = diagc[7+i-j] = FALSE;

después se verifica si ya se han colocado en el tablero ocho reinas, si esta condición no es verdadera entonces se procede a buscar una posición para la siguiente reina y si no se encuentra una posición valida se realiza backtracking.

if (i < 7) /* se ha encontrado una solucion? */ { ensayar(i+1,q,col,fila,diagb,diagc); if (!*q) fila[j] = diagb[i+j] = diagc[7+i-j] = TRUE; } Si una reina ataca a otras reinas en la fila o en las diagonales, se prueba esta condición colocando a la reina en la siguiente casilla a su derecha hasta que se encuentre una solución.

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. PRIMERA EJECUCIÓN: Solucion: Q - - - - - - - - - - - Q - - - - - - - - - - Q - - - - - Q - - - - Q - - - - - - - - - - - Q - - Q - - - - - - - - - Q - - - - Press any key to continue

Departamento de Computación UNAN - León

Page 490: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 174 de 174

SEGUNDA EJECUCIÓN: Solucion: Q - - - - - - - - - - - Q - - - - - - - - - - Q - - - - - Q - - - - Q - - - - - - - - - - - Q - - Q - - - - - - - - - Q - - - - Press any key to continue

El uso de recursión y backtracking fueron de suma importancia para la realización de esta práctica. A través de estas técnicas se pueden recalcular las posibles posiciones de una reina en el tablero o remover una reina de una posición errónea y ubicarla en una mejor posición.

Libros:

CCOONNCCLLUUSSIIOONNEESS

Los objetivos planteados en el enunciado de la práctica se han alcanzado satisfactoriamente.

RREECCOOMMEENNDDAACCIIOONNEESS Para un futuro, nos parece buena idea agregar una interfaz gráfica a esta práctica para poder visualizar mejor los resultados generados por el programa. También nos sería interesante que esta práctica exija que el programa encuentre todas las posibles soluciones al problema de las ocho reinas. O utilizar un algoritmo determinístico para encontrar solo las soluciones a este problema que son completamente distintas entre sí.

BBIIBBLLIIOOGGRRAAFFÍÍAA

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programa en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

Departamento de Computación UNAN - León

Page 491: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 175 de 175

8.2.4 Práctica 4

APLICACIÓN DE LISTAS LINEALES: DICCIONARIO INGLÉS - ESPAÑOL

OBJETIVO En esta práctica se va a simular el funcionamiento de una lista enlazada. El objetivo es mostrar las operaciones básicas que se aplican sobre una lista lineal, y el comportamiento que tiene una lista clasificada cuando se hacen inserciones y supresiones en el transcurso del programa. Observaremos la utilidad que pueden tener cuando se programan aplicaciones de la vida real. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 2 sesiones de laboratorio (4 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0

INTRODUCCIÓN

Un array dinámico, una vez creado no permite alterar su tamaño. Si lo que deseamos es una lista de elementos u objetos de cualquier tipo, originalmente vacía, que durante la ejecución del programa vaya creciendo y decreciendo elemento a elemento, según las necesidades previstas en el programa, entonces tenemos que construir una lista lineal en la que cada elemento apunte o direccione al siguiente. Por este motivo, una lista lineal se le denomina lista enlazada. La Figura 8.2.3 ilustra la representación de una lista lineal:

p

Figura 8.2.3 Ejemplo de una lista.

Departamento de Computación UNAN - León

Page 492: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 176 de 176

Para construir una lista lineal primero tendremos que definir la clase de objetos que van a formar parte de la misma. De una forma genérica el tipo definido será de la forma:

typedef struct id tipo__objeto; struct id {

/* declaración de los miembros de la estructura */ tipo__objeto *siguiente;

}; Ejemplo:

int dato;

typedef struct datos elemento; struct datos {

elemento *siguiente; }; elemento *p; p = NuevoElemento( ); p->siguiente = NULL; Este ejemplo declara un tipo denominado elemento. Observamos que uno de sus miembros es un puntero a un objeto del mismo tipo. Esto permitirá a un elemento creado referenciar su sucesor. La sentencia elemento *p declara un puntero a un objeto de tipo elemento. La sentencia p = NuevoElemento( ); crea (asigna memoria para) un objeto de tipo elemento , genera un puntero (dirección de memoria) que referencia este nuevo objeto y asigna esta dirección a la variable p. La sentencia p->siguiente = NULL asigna al miembro siguiente del objeto apuntado por p el valor NULL, indicando así que después de este elemento no hay otro. El valor NULL, dirección nula, nos permite crear estructuras finitas.

Una declaración como p = NULL indica una lista vacía (suponiendo que p apunta al principio de la lista). Un objeto puede referenciarse por más de un puntero, y también un objeto de un determinado tipo puede copiarse en otro objeto del mismo tipo.

Departamento de Computación UNAN - León

Page 493: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 177 de 177

DISEÑANDO LA LISTA La aplicación a diseñar será un diccionario Inglés – Español, que permita seleccionar opciones como: Seleccionar el Idioma, y una vez seleccionado que sea posible añadir palabras, borrar palabras, traducir una palabra y visualizar el diccionario.

4. Visualizar el diccionario.

Cada vez que se introduce una palabra –según el idioma seleccionado-, se introduce también su traducción al otro idioma. Por simplicidad, la información a introducir para cada palabra, solamente será la palabra misma y su traducción al otro idioma. Todas las operaciones descritas anteriormente, serán controladas por un menú como el siguiente:

Idioma / Language 1. Español. 2. English. 3. Salir / Quit

Su opción / Your option ?:

Si el usuario selecciona el idioma Español (opción 1), entonces se presentará un menú con la siguiente forma:

***** Diccionario Español – Ingles **** 1. Añadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles.

5. Regresar. Su opción ?:

Si el usuario selecciona el idioma Inglés (opción 2), entonces se presentará un menú con la siguiente forma:

******* Dictionary English – Spanish ****** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?:

Departamento de Computación UNAN - León

Page 494: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 178 de 178

Una acción a ejecutar de acuerdo a la opción elegida, tanto para el idioma Español como para Inglés, será implementada por la misma función. Esto es, si el usuario selecciona el idioma Español, y decide introducir una nueva palabra al diccionario, dicha acción podrá ser llevada a cabo mediante una función llamada Anadir ( ). Esta misma función se invocaría si se quisiera introducir una nueva palabra desde el idioma Inglés. La aplicación constará de 2 listas enlazadas clasificadas, una para cada idioma. Habrá una relación entre ellas de acuerdo al campo traducción. Es decir, en el idioma Español, la palabra manzana tiene como traducción al Inglés, apple. En el idioma Inglés, la palabra apple, tiene como traducción al Español manzana. De acuerdo a lo expuesto, cada vez que el usuario introduce una palabra y su traducción en un idioma, habrá también que añadir esa palabra al otro idioma, con el respectivo cambio entre palabra y traducción. Ambas palabras se deben insertar en cada lista, de forma ordenada con respecto al campo que representa a la palabra en cuestión. La Figura 8.2.4 ilustra lo expuesto:

Figura 8.2.4 Estado del diccionario con 3 palabras introducidas. La Figura 8.2.4 muestra que, como consecuencia de la traducción de las palabras, las listas no poseen el mismo orden. Así, la curva punteada indica que la palabra

Departamento de Computación UNAN - León

Page 495: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 179 de 179

manzana, se ubica en el tercer puesto en la lista en Español, y su traducción, apple, se ubica primero en la lista en Inglés. DESARROLLO DE LA PRÁCTICA Cada una de las listas de palabras, deberá ser mantenida usando la siguiente estructura: enum Idiomas /* tipo enumerado */ { Espanol = 1, Ingles }; #define ListaVaciaE (cabecera_E == NULL) #define ListaVaciaI (cabecera_I == NULL) typedef struct dato palabra; struct dato { enum Idiomas idioma;

{

}; Los campos de la estructura de una palabra de la lista se explican a continuación:

char palabra [200]; char traduccion [200]; };

typedef struct palabras elemento; /* tipo elemento */ struct palabras

palabra pal; elemento *sig;

idioma: es un tipo de datos Idioma. Nos dice a qué idioma pertenece la palabra.

palabra: Es la palabra en el Idioma descrito por idioma. Es una cadena de caracteres de 200 elementos.

traduccion: Es la traducción de palabra al otro idioma. Es una cadena de caracteres de 200 elementos.

Los campos de la estructura de un elemento de la lista, se explican a continuación: pal: variable perteneciente a un tipo palabra. La estructura de este tipo ya fue explicada anteriormente. sig: es un apuntador a un objeto de tipo elemento; esencial para mantener y administrar la lista.

Departamento de Computación UNAN - León

Page 496: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 180 de 180

Declare y defina las siguientes funciones: elemento *NuevoElemento( void );

Esta función asigna memoria para un objeto de tipo elemento, genera un puntero (dirección de memoria) que referencia a este nuevo objeto, y retorna este puntero.

int Menu_Idiomas ( void ); Esta función permite seleccionar al usuario el idioma que desee, entre Inglés y Español. Regresa un entero con la opción elegida. De acuerdo al tipo enumerado Idiomas que se propone, el idioma Español se corresponde con un valor entero 1, y el Inglés con un valor entero 2. int Menu (int opcion_I); Esta función acepta como parámetro un entero que corresponde al idioma seleccionado, y de acuerdo al idioma, presenta uno u otro menú. Por ejemplo, si opción_I vale 1, lo cual significa que el Idioma es Español, entonces el menú es como sigue:

***** Diccionario Español – Ingles **** 1. Añadir una palabra.

2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opción ?:

Si en cambio, el parámetro opción_I vale 2, el menú que se le presentaría al usurario es.

******* Dictionary English – Spanish ****** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return.

Your option ?:

Departamento de Computación UNAN - León

Page 497: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 181 de 181

void LeerDatos ( palabra *pe, int opcion_I); Esta función solicita datos para una palabra en el idioma indicado por opción_I. Dicha función recibe dos argumentos: 1.Un puntero a un objeto de tipo palabra: el valor pasado será la dirección de una variable de tipo palabra. El valor de esta variable es pasado por referencia para que la lectura de los datos, sea efectiva también dicha variable 2.Un entero que se corresponde con el idioma seleccionado por el usuario. De acuerdo al valor que reciba el segundo argumento opción_I, se le presentará al usuario la solicitud de introducción de datos en el idioma elegido. void Anadir ( elemento **pe, palabra pal ); Esta función añade –en forma ordenada-, la palabra indicada en el argumento e, a la lista de palabras en el idioma elegido con anterioridad. Dicha función recibe 2 argumentos: 1.La dirección de una variable puntero a un objeto de tipo elemento. Esta dirección que se recibe puede corresponder al puntero a la lista en Español o a la lista en Inglés, de acuerdo al idioma con el que se esté trabajando. 2.Una variable de tipo palabra. En esta variable, la cual es pasada por valor-, se encuentra la información de la palabra a añadir a la lista. De nuevo se hace hincapié en que, la función Anadir ( ), será llamada 2 veces cada vez que el usuario introduzca una palabra en el idioma seleccionado. Así, por ejemplo, si el usuario está trabajando en el idioma Español e introduce la palabra libro, con su traducción correspondiente book, primero llamará al función Anadir ( ) para introducir la palabra en la lista de Español, y luego llamará de nuevo a Anadir ( ), pero ahora para introducir la palabra en la lista de Inglés. char *EncontrarPareja (elemento *pe, char *palabra); El propósito de esta función es encontrar la traducción de la palabra en el otro idioma. Esto se hace con el objetivo de que, por ejemplo, al borrar una palabra en Español, también se pueda borrar la palabra correspondiente en Inglés. Esta función recibe como argumento un puntero a una lista de objetos de tipo elemento y un puntero a una cadena de caracteres que se corresponde con la palabra de la cual se buscará su traducción. La función devuelve un puntero a la cadena de caracteres que indica la traducción de palabra.

Departamento de Computación UNAN - León

Page 498: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 182 de 182

void Borrar ( elemento **pe, char *palabara ); Esta función borra el elemento indicado por palabra, de la lista enlazada referenciada por el puntero que es pasado por referencia. Esta función recibe dos argumentos: la dirección de memoria de un puntero a una lista lineal con objetos de tipo elemento, y un puntero a una cadena de caracteres que hace referencia a la palabra contenida en el elemento a borrar. La funcionalidad de esta rutina se resume diciendo que, recorrerá la lista referenciada por el puntero que es pasado por referencia, y buscará el elemento indicado por palabra. Si el elemento se encuentra, entonces se procede a borrar dicho elemento de la lista. Si el elemento no se encuentra, entonces se imprime un mensaje indicando la no existencia del elemento y se retorna. Una vez más hay que destacar que cuando el usuario se decida a borrar, por ejemplo, una palabra en Español, deberá también borrar la correspondiente palabra que sería la traducción en Inglés de la palabra en Español. Esto es, deberá llamar 2 veces a la función Borrar ( ). elemento *Buscar ( elemento *pe, char *palabra ); Esta función busca en la lista enlazada referenciada por pe, el elemento que contiene la palabra referenciada por el puntero palabra. Si el dato se encuentra, la función retorna un puntero al elemento que contiene el dato encontrado. Si el dato no se encuentra, entonces lo que se devuelve es un puntero a NULL. Esta función es útil llamarla cuando se desea traducir una palabra. El procedimiento sería, buscar la palabra en la lista, y una vez que se encuentre, buscar la traducción de dicha palabra. void Visualizar ( elemento *pe ); Esta función visualiza la lista referenciada por el puntero pe. Se recorre la lista y por cada elemento distinto de NULL se imprime la palabra y su traducción. Cuando se llega a NULL, también se imprime la palabra NULL, indicando el fin de la lista. Se debe verificar si la lista está vacía y tratar esa posible situación. void LiberarMemoria (elemento **pe);

Esta función libera la memoria que pudo haber quedado sin liberar en una de las listas. Esta situación podría darse si introducimos palabras desde el menú, y nos salimos del programa sin eliminarlas. La funcionalidad de esta rutina será recorrer la lista, y liberar la memoria de cada elemento diferente de NULL que se encuentre. Esta función es importante llamarla justo antes de finalizar la aplicación.

Se pide:

Departamento de Computación UNAN - León

Page 499: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 183 de 183

De acuerdo a lo expuesto anteriormente, construya una función main( ), y desde ahí llame al menú para seleccionar el idioma, y luego llame al menú para operar con el diccionario. Ejecute el programa repetidas veces para observar si los resultados están de acorde a lo solicitado. A continuación, se presenta una corrida del programa para que el estudiante se de una idea de cómo es la funcionalidad de la aplicación.

Primera ejecución:

Nota: las entradas del usuario están en negritas cursivas y subrayadas. ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 1 ******* Diccionario Espanol - Ingles *******

1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar.

Su opción ?: 1 Palabra: manzana Traduccion al Ingles: apple Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 1 Word: bottle Translate to Spanish: botella Pulse una tecla para continuar

Departamento de Computación UNAN - León

Page 500: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 184 de 184

********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario.

5. Regresar.

Su opción ?: 1 Palabra: libro Traduccion al Ingles: book Pulse una tecla para continuar

Su opción / Your option ?: 2

********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit

******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 4apple, manzana --> book, libro --> bottle, botella --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opción ?: 4botella, bottle --> libro, book --> manzana, apple --> NULL

Departamento de Computación UNAN - León

Page 501: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 185 de 185

Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 2 Delete word: bottle Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opción ?: 4libro, book --> manzana, apple --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 4apple, manzana --> book, libro --> NULL

Departamento de Computación UNAN - León

Page 502: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 186 de 186

Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opción / Your option ?:3 Good bye .. Press any key to continue

Departamento de Computación UNAN - León

Page 503: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 187 de 187

Solución de la práctica 4 APARTADO SOLUCIÓN: /**** Diccionario Inglés – Español *****/ /* diccionario.c */ #include <stdio.h > #include <stdlib.h> #include <conio.h > #include <string.h> #include <crtdbg.h> enum Idiomas /* tipo enumerado */ { Espanol = 1, Ingles }; #define ListaVaciaE (cabecera_E == NULL) #define ListaVaciaI (cabecera_I == NULL) typedef struct dato palabra; struct dato { enum Idiomas idioma; char palabra [200]; char traduccion [200]; }; typedef struct palabras elemento; /* tipo elemento */ struct palabras { palabra pal; elemento *sig; }; /* Prototipos de funciones */ void Error (void); elemento *NuevoElemento( void ); int Menu (int opcion_I); int Menu_Idiomas ( void ); void LeerDatos ( palabra *pe, int opcion_I); void Anadir (elemento **pe, palabra pal); void Borrar (elemento **pe, char *palabara); elemento *Buscar (elemento *pe, char *palabra); void Visualizar (elemento *pe); void LimpiarElemento (palabra *pe); void LiberarMemoria (elemento **pe); char *EncontrarPareja (elemento *pe, char *palabra); void main (void) /* Función principal */ {

Departamento de Computación UNAN - León

Page 504: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 188 de 188

elemento *cabecera_E = NULL; /* lista vacía */ elemento *cabecera_I = NULL; palabra temporalE, temporalI; elemento *q; int opcion_I; // Seleccionar el Idioma int opcion; // Seleccionar la accion a realizar char palabra[200]; char *pareja, pareja_aux[200]; // Palabra correspondiente en el otro Idioma while (1) { opcion_I = Menu_Idiomas(); if (opcion_I == Espanol) { opcion = Menu (opcion_I); switch (opcion) { case 1: // Anadir una palabra LeerDatos( &temporalE, opcion_I ); /* Añadir temporal a la lista */ Anadir (&cabecera_E, temporalE); /* Anadir esa misma palabra en Español, al diccio- nario en Inglés. La traducción será ahora, la palabra en Inglés; y la palabra será ahora la traducción al Español. */ temporalI.idioma = Ingles; strcpy (temporalI.palabra, temporalE.traduccion); strcpy (temporalI.traduccion, temporalE.palabra); Anadir (&cabecera_I, temporalI); break; case 2: // Borrar una palabra fflush(stdin); if (ListaVaciaE) // Lista en Español vacía ? { printf ("\n\t Lista vacia !!!"); printf ("\n"); continue; } printf ("\n\t Borrar palabra: "); gets (palabra); /* Primero, encontramos la palabra correspondiente

Departamento de Computación UNAN - León

Page 505: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 189 de 189

en Inglés */ pareja = EncontrarPareja (cabecera_E, palabra); strcpy (pareja_aux, pareja ); // Borramos la palabra en Español Borrar (&cabecera_E, palabra); // Borramos la palabra correspondiente en Inglés Borrar (&cabecera_I, pareja_aux); break; case 3: // Traducir al Inglés fflush(stdin); if (ListaVaciaE) // Lista en Español vacía ? { printf ("\n\t Lista vacia !!!"); printf ("\n"); continue; } printf ("\n\t Traducir palabra: "); gets (palabra); q = Buscar (cabecera_E, palabra); if (q) { /* Buscamos la traduccion al Inglés */ pareja = EncontrarPareja (cabecera_E, palabra); strcpy (pareja_aux, pareja ); printf ("\n\t Traduccion: %s", pareja_aux); } else printf ("\n\t Dato no encontrado"); break; case 4: // Visualizar el diccionario Visualizar (cabecera_E); break; case 5: // Regresar al menu de Idiomas continue; } // fin de switch } // Cierre del if(opcion_I == Espanol) else if (opcion_I == Ingles) // Idioma Inglés

Departamento de Computación UNAN - León

Page 506: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 190 de 190

{ opcion = Menu (opcion_I); switch (opcion) { case 1: // Anadir una palabra LeerDatos( &temporalI, opcion_I ); /* Añadir temporal a la lista */ Anadir (&cabecera_I, temporalI); /* Anadir esa misma palabra en Inglés, al diccio- nario en Español. La traducción sera ahora, la palabra en Español; y la palabra sera ahora la traduccion al Inglés. */ temporalE.idioma = Espanol; strcpy (temporalE.palabra, temporalI.traduccion); strcpy (temporalE.traduccion, temporalI.palabra); Anadir (&cabecera_E, temporalE); break; case 2: // Borrar una palabra fflush(stdin); if (ListaVaciaI) // Lista en Inglés vacía ? { printf ("\n\t Empty List !!!"); printf ("\n"); continue; } printf ("\n\t Delete word: "); gets (palabra); /* Primero, encontramos la palabra correspondiente en Español */ pareja = EncontrarPareja (cabecera_I, palabra); strcpy (pareja_aux, pareja ); /* Borramos la palabra en Inglés */ Borrar (&cabecera_I, palabra); // Borramos la palabra correspondiente en Español Borrar (&cabecera_E, pareja_aux); break;

Departamento de Computación UNAN - León

Page 507: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 191 de 191

case 3: // Traducir el Español fflush(stdin); if (ListaVaciaI) // Lista en Inglés vacía ? { printf ("\n\t Empty List !!!"); printf ("\n"); continue; } printf ("\n\t Traduce word: "); gets (palabra); q = Buscar (cabecera_I, palabra); if (q) { // Dato encontrado /* Buscamos la traduccion al Inglés */ pareja = EncontrarPareja (cabecera_I, palabra); strcpy (pareja_aux, pareja ); printf ("\n\t Translation: %s", pareja_aux); } else printf ("\n\t Data no finded .."); break; case 4: // Visualizar la lista Visualizar (cabecera_I); break; case 5: // Regresar al menu de Idiomas continue; } // fin de switch } // Fin del else if else // Salir de la aplicacion break; /* Limpiar temporalE y temporalI */ LimpiarElemento (&temporalE); LimpiarElemento (&temporalI); printf ("\n Pulse una tecla para continuar"); getch(); printf("\n"); } // Fin del while()

Departamento de Computación UNAN - León

Page 508: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 192 de 192

/* Al salir de la aplicación, liberamos la memoria asignada */ LiberarMemoria (&cabecera_E); LiberarMemoria (&cabecera_I); /* Verificar la exsitencia de lagunas de memoria */ if ( _CrtDumpMemoryLeaks() ) printf ("\n\t Hay Lagunas de Memoria"); printf("\n\t Good bye ..\n"); } // Fin del main() //////////////// Definición de funciones ////////////////////////// /****************** Función Menu *****************************/ int Menu (int idioma) { /* Menu de las operaciones sobre el diccionario, tanto en Inglés, como en Español. */ int opcion; if (idioma == Espanol) // Idioma Español { do { printf("\n\t ******* Diccionario Espanol - Ingles *******"); printf("\n\t 1. Anadir una palabra."); printf("\n\t 2. Borrar una palabra."); printf("\n\t 3. Traducir palabra al Ingles."); printf("\n\t 4. Visualizar el diccionario."); printf("\n\t 5. Regresar. \n"); printf ("\n\t Su opcion ?: "); scanf ("%d", &opcion ); } while ( opcion < 1 || opcion > 5); } // Fin de if (idioma == Espanol) else // Idioma Inglés { do { printf("\n\t ******* Dictionary English - Spanish ***********"); printf("\n\t 1. Add a word."); printf("\n\t 2. Delete a word."); printf("\n\t 3. Traduce to Spanish."); printf("\n\t 4. Display dictionary."); printf("\n\t 5. Return. \n"); printf ("\n\t Your option ?: ");

Departamento de Computación UNAN - León

Page 509: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 193 de 193

scanf ("%d", &opcion ); } while ( opcion < 1 || opcion > 5); } // Fin de else return (opcion); } // Fin de Menu() /************** Funcion Anadir ************************/ void Anadir ( elemento **cab, palabra pal ) { elemento *cabecera = *cab; /* cabecera apunta al inicio de la lista */ elemento *actual = cabecera, *anterior = cabecera, *q; if (cabecera == NULL) /* Si está vacía, crear un elemento */ { cabecera = NuevoElemento(); /* Copiar pal en cabecera */ cabecera->pal = pal; cabecera->sig = NULL; *cab = cabecera; return; } /* Entrar en la lista y encontrar el punto de inserción */ while (actual != NULL && strcmp (pal.palabra, actual->pal.palabra) > 0 ) { anterior = actual; actual = actual->sig; } /* Dos casos: 1.Insertar al principio de la lista. 2.Insertar después de anterior (incluye insertar al final) */ q = NuevoElemento(); /* Se genera un nuevo elemento */ if (anterior == actual) /* insertar al principio */ { q->pal = pal; q->sig = cabecera; cabecera = q; } else /* Inserta después de anterior */ { q->pal = pal; q->sig = actual; anterior->sig = q; } *cab = cabecera;

Departamento de Computación UNAN - León

Page 510: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 194 de 194

} // Fin de Anadir() /**************** Función NuevoElemento ***********************/ elemento *NuevoElemento( void ) { elemento *temp = (elemento *) malloc ( sizeof (elemento) ); if ( temp == NULL ) Error(); return (temp); } // Fin de NuevoElemento() /***************** Funcion Error ****************************/ void Error (void) { perror ("error: insuficiente espacio de memoria"); exit(1); } /******************** Leer Datos *****************************/ void LeerDatos ( palabra *pe, int opcion_I) { fflush(stdin); if (opcion_I == Espanol) { pe->idioma = Espanol; printf ("\n\t Palabra: "); gets (pe->palabra); printf ("\n\t Traduccion al Ingles: "); gets (pe->traduccion); } else // Idioma Inglés { pe->idioma = Ingles; printf ("\n\t Word: "); gets (pe->palabra); printf ("\n\t Translate to Spanish: "); gets (pe->traduccion); } } // Fin de LeerDatos() /****************** Borra una palabra del diccionario ******************/ void Borrar ( elemento **cab, char *palabra )

Departamento de Computación UNAN - León

Page 511: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 195 de 195

{ elemento *cabecera = *cab; elemento *actual = cabecera, *anterior = cabecera; if (cabecera == NULL) { printf ("\n\t Lista Vacia"); return; } /* Entrar en la lista y encontrar el elemento a borrar */ while (actual != NULL && strcmp (palabra, actual->pal.palabra) != 0) { anterior = actual; actual = actual->sig; } /* Si el dato no se encuentra, retornar */ if (actual == NULL) return; /* Si el dato se encuentra, borrar el elemento */ if (anterior == actual) /* borrar el elemento de cabecera */ cabecera = cabecera->sig; else anterior->sig = actual->sig; /* Liberar la memoria del objeto apuntado por actual */ free (actual); *cab = cabecera; } // Fin de Borrar /*********** Buscar una palabra en el diccionario ****************/ elemento *Buscar ( elemento *cabecera, char *palabra ) { elemento *actual = cabecera; while (actual != NULL && strcmp (palabra, actual->pal.palabra) != 0) actual = actual->sig; return (actual); } // Fin de Buscar() /********************** Visualiza los elementos de la lista ****************/ void Visualizar ( elemento *cabecera ) { elemento *actual = cabecera; if (cabecera == NULL) printf ("Lista Vacia");

Departamento de Computación UNAN - León

Page 512: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 196 de 196

else { while (actual != NULL) { printf ("%s, %s --> ", actual->pal.palabra, actual->pal.traduccion); actual = actual->sig; } printf ("NULL \n"); } } // Fin de Visualizar() /****************** Seleccionar el Idioma ************************/ int Menu_Idiomas (void) { int opcion; do { printf("\n\t ********* Idioma / Language **********"); printf("\n\t 1. Espanol."); printf("\n\t 2. English."); printf("\n\t 3. Salir / Quit"); printf ("\n\t Su opcion / Your option ?: "); scanf ("%d", &opcion ); } while ( opcion < 1 || opcion > 3); return (opcion); } // Fin de Menu_Idiomas() /**** Inicializa un objeto elemento con valores apropiados *******/ void LimpiarElemento (palabra *pe) { pe->idioma = Espanol; // Poner un idioma por defecto strcpy (pe->palabra, "" ); strcpy (pe->traduccion, ""); } // Fin de LimpiarElemento() /*** Libera la memoria asignada a un objeto de tipo elemento ***/ void LiberarMemoria (elemento **cab) { elemento *cabecera = *cab; // cabecera de la lista elemento *anterior, *actual; anterior = actual = cabecera; /* Recorrer la lista, e ir eliminando cada elemento */

Departamento de Computación UNAN - León

Page 513: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 197 de 197

while ( actual != NULL ) { anterior = actual; actual = actual->sig; free (anterior); } /* Actualizar la cabecera, para que ahora apunte a NULL */ cabecera = actual = NULL; *cab = cabecera; } // Fin de LiberarMemoria () /********* Encontrar la palabra correspondiente en el otro Idioma ***/ char *EncontrarPareja (elemento *cab, char *palabra) { elemento *actual = cab; while (actual != NULL && strcmp (palabra, actual->pal.palabra) != 0) actual = actual->sig; return (actual->pal.traduccion); } // Fin de EncontrarPareja()

Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS

• Compilador Visual C++ 6.0, para la compilación del archivo fuente y la

construcción de archivo ejecutable.

• Microsoft Word 2000 para la edición del documento de entrega de la práctica.

• Microsoft Visio 2000 para la elaboración de las ilustraciones.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN Se ha hecho mucho énfasis a lo largo del enunciado, del cuidado que hay que tener con respecto las operaciones de insertar y eliminar elementos al diccionario.

Departamento de Computación UNAN - León

Page 514: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 198 de 198

Habíamos explicado que cada nueva palabra introducida en un idioma, se debía introducir también a la lista en el otro idioma (recordar que cada palabra se introducía de forma ordenada). Con el borrado sucede exactamente lo mismo: cuando se borra una palabra en un idioma, también se deber borrar en el otro; todo esto con el objetivo de llevar una igualdad de las palabras en ambos idiomas. En este apartado se explica una propuesta para resolver lo anteriormente expuesto. En el caso de la inserción de palabras, la estrategia es añadir la palabra en el idioma que se ha elegido, y a continuación, de acuerdo a la traducción que se dio, añadir esa traducción como palabra en la lista del otro idioma. Así, por ejemplo, si hemos elegido el idioma español, las líneas de código que equivaldrían a lo dicho antes serían: if (opcion_I == Espanol) { opcion = Menu (opcion_I); switch (opcion) { case 1: // Anadir una palabra LeerDatos( &temporalE, opcion_I ); /* Añadir temporal a la lista */ Anadir (&cabecera_E, temporalE); /* Añadir esa misma palabra en Español, al diccio- nario en Inglés. La traducción será ahora, la palabra en Inglés; y la palabra será ahora la traducción al Español. */ temporalI.idioma = Ingles; strcpy (temporalI.palabra, temporalE.traduccion); strcpy (temporalI.traduccion, temporalE.palabra); Anadir (&cabecera_I, temporalI); break; donde, opcion_I, opcion, temporalE, temporalI, cabecera_E, cabecera_I han sido previamente declarados al inicio de la función main ( ): void main (void) /* Función principal */

elemento *cabecera_I = NULL;

palabra temporalE, temporalI;

{

elemento *cabecera_E = NULL; /* lista vacía */

Departamento de Computación UNAN - León

Page 515: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 199 de 199

elemento *q;

int opcion_I; // Seleccionar el Idioma int opcion; // Seleccionar la acción a realizar El procedimiento a seguir cuando se trabaja con el idioma Inglés, es igual al de Español, con la única diferencia de que las variables temporalE y temporalI, cambian de lugar en los llamados a las funciones LeerDatos ( ) y Anadir ( ). Ver el código en el apartado Solución. En el caso del borrado de palabras, la estrategia a seguir es, buscar la traducción de la palabra a borrar en el idioma elegido, y una vez logrado esto, borrar la palabra de la lista del idioma, y su traducción de la lista correspondiente al otro idioma.

Si hemos elegido el idioma Español, y deseamos borrar una palabra, las líneas de código que resuelven el borrado, serían: case 2: // Borrar una palabra fflush(stdin); if (ListaVaciaE) // Lista en Español vacía ? { printf ("\n\t Lista vacia !!!"); printf ("\n"); continue; } printf ("\n\t Borrar palabra: "); gets (palabra); /* Primero, encontramos la palabra correspondiente en Inglés */ pareja = EncontrarPareja (cabecera_E, palabra); strcpy (pareja_aux, pareja ); //printf ("%s", pareja_aux); // Borramos la palabra en Español Borrar (&cabecera_E, palabra); // Borramos la palabra correspondiente en Inglés Borrar (&cabecera_I, pareja_aux); break; donde, palabra, pareja y pareja_aux, ya han sido definidos al inicio de la función main ( ) como sigue:

Departamento de Computación UNAN - León

Page 516: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 200 de 200

char palabra[200]; char *pareja, pareja_aux[200]; // Palabra correspondiente en el otro Idioma

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. PRIMERA EJECUCIÓN: Nota: Las entradas del usuario están en negritas cursivas y en subrayado. ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opcion ?: 1 Palabra: cuaderno Traduccion al Ingles: notebook Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 1

Departamento de Computación UNAN - León

Page 517: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 201 de 201

Word: business Translate to Spanish: negocio Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opcion ?: 1 Palabra: caja Traduccion al Ingles: box Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 2

4. Display dictionary.

******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish.

5. Return.

Your option ?: 1 Word: keyboard Translate to Spanish: teclado

1. Espanol.

3. Salir / Quit

Pulse una tecla para continuar

********* Idioma / Language **********

2. English.

Su opcion / Your option ?: 1 ******* Diccionario Espanol - Ingles *******

Departamento de Computación UNAN - León

Page 518: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 202 de 202

1. Anadir una palabra.

2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar.

Su opcion ?: 4caja, box --> cuaderno, notebook --> negocio, business --> teclado, keyboard -->

NULL

Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 4box, caja --> business, negocio --> keyboard, teclado --> notebook, cuaderno --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1 ******* Diccionario Espanol - Ingles *******

1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar.

Su opcion ?: 2 Borrar palabra: negocio Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1

Departamento de Computación UNAN - León

Page 519: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 203 de 203

******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opcion ?: 4caja, box --> cuaderno, notebook --> teclado, keyboard --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return. Your option ?: 2 Delete word: box Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 2

******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word. 3. Traduce to Spanish. 4. Display dictionary. 5. Return.

Your option ?: 4keyboard, teclado --> notebook, cuaderno --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1

Departamento de Computación UNAN - León

Page 520: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 204 de 204

******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario. 5. Regresar. Su opcion ?: 2 Borrar palabra: teclado Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol. 2. English. 3. Salir / Quit Su opcion / Your option ?: 1 ******* Diccionario Espanol - Ingles ******* 1. Anadir una palabra. 2. Borrar una palabra. 3. Traducir palabra al Ingles. 4. Visualizar el diccionario.

5. Regresar.

Su opcion ?: 4cuaderno, notebook --> NULL Pulse una tecla para continuar ********* Idioma / Language ********** 1. Espanol.

3. Salir / Quit 2. English.

Su opcion / Your option ?: 2 ******* Dictionary English - Spanish *********** 1. Add a word. 2. Delete a word.

Your option ?: 2

3. Traduce to Spanish. 4. Display dictionary. 5. Return.

Delete word: notebook Pulse una tecla para continuar

********* Idioma / Language ********** 1. Espanol.

3. Salir / Quit

2. English.

Su opcion / Your option ?: 2

Departamento de Computación UNAN - León

Page 521: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 205 de 205

******* Dictionary English - Spanish ***********

4. Display dictionary.

1. Add a word. 2. Delete a word. 3. Traduce to Spanish.

5. Return.

Your option ?: 4Lista Vacia

1. Espanol. 2. English.

Su opcion / Your option ?: 3

Pulse una tecla para continuar

********* Idioma / Language **********

3. Salir / Quit

Good bye ..

CCOONNCCLLUUSSIIOONNEESS

Press any key to continue

Una vez finalizada la práctica, hemos concluido que los objetivos propuestos, los cuales eran el manejo de las operaciones en una lista enlazada y el comportamiento de la lista misma cuando se introducían y retiraban elementos durante el tiempo de ejecución, se han cumplido satisfactoriamente.

RREECCOOMMEENNDDAACCIIOONNEESS Las recomendaciones que hacemos, es que en un futuro, el diccionario conste de varios idiomas; por lo cual, habrá que manejar una lista, en la cual cada uno de sus elementos, o sea un puntero a otra lista de idiomas.

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA. • Curso de Programación C/ C++. Fco Javier Ceballos. Ed-RAMA.

Departamento de Computación UNAN - León

Page 522: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 206 de 206

8.2.5 Práctica 5

APLICACIÓN DE PILAS: EVALUACIÓN DE EXPRESIONES POSTFIJAS

OBJETIVO

Figura 8.2.5 Representación de una pila.

En esta práctica se va a simular el funcionamiento de una pila a través de estructuras dinámicas. El objetivo es mostrar las operaciones básicas que se aplican sobre una pila. Observaremos la utilidad que pueden tener las pilas en el diseño de compiladores. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 1 sesión de laboratorio (2 horas)

SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN Una pila es una lista lineal en la que todas las inserciones y supresiones (y normalmente todos los accesos), se hacen en un extremo de la lista. Un ejemplo de esta estructura es una pila de platos. En ella, el añadir o quitar platos se hace siempre por la parte superior de la pila. Este tipo de listas reciben el nombre de listas LIFO (last in first out – último en entrar, primero en salir). La Figura 8.2.5 ilustra lo expuesto

Inserciones Y Supresiones

Las operaciones de insertar y suprimir en una pila, son conocidas en los lenguajes ensambladores como push y pop respectivamente.

La operación de recuperación de un elemento de la pila, lo elimina de la misma.

Departamento de Computación UNAN - León

Page 523: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 207 de 207

DISEÑANDO LA PILA Las pilas son utilizadas por los compiladores para auxiliarse en el proceso de evaluar expresiones y generar código en lenguaje máquina. En este ejercicio, investigamos cómo los compiladores evalúan expresiones aritméticas formadas únicamente por constantes, operadores y paréntesis. Los seres humanos normalmente escriben las expresiones como 3 + 4 y 7 / 9, en el cual el operador (aquí + o /) se escribe entre sus operandos –esto se conoce como notación infija. Las computadoras “prefieren” la notación postfija, en la cual el operador se escribe a la derecha de sus dos operandos. Las expresiones infijas anteriores aparecerían en notación postfija como 3 4 + y 7 9 /, respectivamente. En este ejercicio se pretende que usted escriba una versión en lenguaje C del algoritmo de evaluación de la expresión postfija. A manera de explicación, la siguiente expresión infija: ( 6 + 2 ) * 5 - 8 / 4 corresponde a la siguiente expresión postfija: 6 2 + 5 * 8 4 / - Escriba un programa que evalúe una expresión postfija (suponga que es válida) como: 6 2 + 5 * 8 4 / - El programa deberá leer una expresión postfija formada de dígitos y de operadores a un arreglo de caracteres. Utilizando las funciones de pila ya conocidas, el programa deberá rastrear la expresión y evaluarla. El algoritmo es como sigue:

1. Agregue el carácter NULL ( ‘\0’ ) al final de la expresión postfija. Cuando se encuentre el carácter NULL, ya no es necesario procesamiento adicional. 2. En tanto no se encuentre ‘\0’, lea la expresión de izquierda a derecha. Si el carácter actual es un dígito,

Inserte (push) su valor entero en la pila (el valor entero de un carácter dígito es su valor en el conjunto de caracteres de la computadora, menos el valor de ‘0’ en el conjunto de caracteres de la computadora).

De lo contrario, si el carácter actual es un operador, Retire (pop) los 2 elementos superiores de la pila a las variables x e y. Calcule y operator x ( Nota: operator es la operación a realizar). Inserte (push) el resultado del cálculo en la pila. 3. Cuando en la expresión se encuentre el carácter NULL, retire (pop) el valor superior de la pila. Ese es el resultado de la expresión postfija.

Departamento de Computación UNAN - León

Page 524: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 208 de 208

Nota: en el paso 2 del algoritmo descrito, si el operador es ‘/’, y la parte superior de la pila es 2, y el siguiente elemento en la pila es 8, entonces retira (pop) 2 a x, retira (pop) 8 a y, evalúa 8 / 2 e inserta (push) el resultado con 4, de regreso a la pila. Esta nota también se aplica al operador ‘-‘. Las operaciones aritméticas permitidas en una expresión son: Operando Operación + adición - substracción * multiplicación / división ^ exponenciación % módulo La pila deberá ser mantenida utilizando las declaraciones siguientes: typedef struct Pila Pila_Expr_PostF; // Pila de Expresión PostFija struct Pila

El programa deberá consistir de la función main( ) y de otras 7 funciones, con los siguientes encabezados de función:

// Insertar (push) un valor en la pila

{ int dato; Pila_Expr_PostF *sig; };

void LeerExprPostF ( char *expresion ); // Leer una expresión postfija desde el teclado int EvaluarExprPostF ( char *expresion ); // Evalúa la expresión postfija /* Evalúa la expresión: operando1 operador operando2 */ int Calcular ( int operando1, int operando2, char operador );

void push ( Pila_Expr_PostF **punt, int valor ); int pop ( Pila_Expr_PostF **punt ); // Retirar (pop) un valor de la pila int PilaVacia ( Pila_Expr_PostF *punt ); // Determinar si la pila está vacía void ImprimirPila ( Pila_Expr_PostF *punt ); // Imprimir la pila

A continuación, se presenta una corrida del programa para que el estudiante se de una idea de qué es lo que tiene que hacer a cada instante el programa en cuestión.

Nota: las entradas del usuario están en negritas cursivas y subrayadas.

Departamento de Computación UNAN - León

Page 525: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 209 de 209

****** APLICACION DE PILAS !!! ****** Evaluacion de expresiones postfijas.

Introduzca una expresion postfija valida (con espacios):

6 2 + 5 * 8 4 / - El resultado de la expresion es: 38 Press any key to continue

Departamento de Computación UNAN - León

Page 526: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 210 de 210

Solución de la práctica 5 APARTADO SOLUCIÓN: /* Evaluación de expresiones postfijas */ /* eval_pf.c*/ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> typedef struct pila elemento; /* Tipo elemento */ struct pila /* Estructura de un elemento de la pila */ { int dato; elemento *siguiente; }; typedef enum boolean booleano; enum boolean { Falso, Verdad }; /* Prototipos de funciones */ void Push(elemento **p, int x); /* Añadir un dato a la pila */ int Pop(elemento **p); /* Sacar un dato de la pila */ void Error(void); elemento *NuevoElemento(); booleano PilaVacia (elemento *p); void Visualizar(elemento *p); int Calcular (int op1, int op2, char operador); int EvaluarExpresion (char *expresion); void main() /* Función Principal */ { int resultado = 0; char expr_infija[100]; /* Expresion Postfija */ printf ("\n\t ****** APLICACION DE PILAS !!! ******"); printf ("\n\t Evaluacion de expresiones postfijas."); printf ("\n\n\t Introduzca una expresion postfija valida (con espacios):\n\n\t " ); gets(expr_infija); resultado = EvaluarExpresion (expr_infija); printf ("\n\t El resultado de la expresion es: %d\n\n", resultado); } // Fin del main()

Departamento de Computación UNAN - León

Page 527: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 211 de 211

///////////////////////////////////////////////////////////////////////////////// ///////////////// Definición de funciones ///////////////////////// ///////////////////////////////////////////////////////////////////////////////// int EvaluarExpresion (char *expresion) { elemento *cima = NULL; /* Pila Vacía */ int tam, a, b, r; int i = 0; char operador; tam = strlen (expresion); while (expresion[i] != '\0') { switch (expresion[i]) { case '+': case '-': case '*': case '/': case '^': case '%': operador = expresion[i]; // Guardamos el operador a = Pop (&cima); b = Pop (&cima); r = Calcular (b, a, operador); // Hacer b operador a Push (&cima, r); break; case ' ': // Si es un espacio en blanco, omitirlo i++; continue; break; default: // El caracter es un operando /* Meter en la pila el valor entero del carácter */ Push (&cima, (expresion[i] - 48)); break; } i++; // Leer el siguiente carácter } // Fin del while /* Cuando salimos del while, es porque ya encontramos el carácter de finalización de cadena en el array. Lo que tenemos que hacer es un Pop, y ese será el resultado de la expresión postfija. */ r = Pop (&cima); // Sacar el último valor return (r); } // Fin de EvaluarExpresion()

Departamento de Computación UNAN - León

Page 528: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 212 de 212

/*Añadir un dato a la pila*/ void Push(elemento **p, int x) { elemento *q, *cima; cima = *p; /* cima de la pila */ q = NuevoElemento(); q->dato = x; q->siguiente = cima; cima = q; *p = cima; } /*Recuperar un dato de la cima de la pila*/ int Pop(elemento **p) { elemento *cima; int x; cima = *p; /*cima de la pila*/ if( PilaVacia(cima) == Verdad ) { printf("\nError: pop de una pila vacia"); return 0; } else { x = cima->dato; *p = cima->siguiente; free (cima); return (x); } } // Fin de Pop() /** Manejador de error **/ void Error(void) { perror("Error: insuficiente espacio en memoria."); exit(1); } /* Asigna memoria para un nuevo elemento */ elemento *NuevoElemento() { elemento *q=(elemento *)malloc(sizeof(elemento)); return (q); } /* Verificar el estado de la pila */ booleano PilaVacia (elemento *p) { /* Regresa: Verdad (1), si la pila está vacia.

Departamento de Computación UNAN - León

Page 529: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 213 de 213

Falso (0), si la pila contiene elementos. */ elemento *cima; cima = p; if (cima == NULL) return (Verdad); else return (Falso); } // Fin de PilaVacia() /* Visualiza el contenido de la pila */ void Visualizar(elemento *p) { elemento *aux = p; if ( PilaVacia(aux) == Verdad) { printf ("\n\t PILA VACIA!!!"); return; } else { printf ("\n\t La PILA es: \n"); while (aux != NULL) { printf ("%d --> ", aux->dato); aux = aux->siguiente; } } printf ("NULL\n\n"); } // Fin de Visualizar() /** Calcula la operación op1 operador op2 **/ int Calcular (int op1, int op2, char operador) { /* Verificar el tipo de operación dado por operador */ int r = 0; switch (operador) { case '+': return (op1 + op2); break; case '-': return (op1 - op2); break;

Departamento de Computación UNAN - León

Page 530: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 214 de 214

case '*': return (op1 * op2); break; case '/': return (op1 / op2); break; case '^': // Exponenciacion -->op1 ^ op2 r = (int) ( pow ( (double) op1, (double) op2) ); return (r); break; case '%': return (op1 % op2); } // Fin de switch } // Fin de Calcular()

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS

• Compilador Microsoft Visual C++ 6.0 para la compilación del archivo fuente y la construcción de archivo ejecutable.

Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Microsoft Word XP para la edición del documento de entrega de la práctica.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN La parte más importante de este programa se encuentra en la función: int EvaluarExpresion (char *expresion); Esta función, recorre el arreglo expresión hasta encontrar el carácter de terminación de cadena y, por cada carácter obtenido, se verifica si es un operando, y de ser así, lo mete en la pila; si el carácter es un operador, saca 2 operandos de la pila, hace la operación que indica el carácter, y luego vuelve a llamar pop para introducir el resultado de la operación. Al momento de hacer un push de un operando, encontamos el valor entero del carácter, de la siguiente forma :

Departamento de Computación UNAN - León

Page 531: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 215 de 215

Push (&cima, (expresion[i] - 48));

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. ****** APLICACION DE PILAS !!! ****** Evaluacion de expresiones postfijas. Introduzca una expresion postfija valida (con espacios): 6 2 + 5 * 8 4 / - El resultado de la expresion es: 38 Press any key to continue

RREECCOOMMEENNDDAACCIIOONNEESS No hay recomendaciones.

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA. • Curso de Programación C/ C++. Fco Javier Ceballos. Ed-RAMA.

Departamento de Computación UNAN - León

Page 532: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 216 de 216

8.2.6 Práctica 6

APLICACIÓN DE COLAS: SIMULACIÓN DE LLEGADA DE CLIENTES A UNA COLA DE UN BANCO

OBJETIVO En esta práctica se va a simular el funcionamiento de una cola a través de estructuras dinámicas. El objetivo es mostrar las operaciones básicas que se aplican sobre una cola, y el comportamiento que tiene una cola cuando las inserciones y supresiones se hacen en tiempos variables. Observaremos la utilidad que pueden tener cuando se programan aplicaciones de la vida cotidiana. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 3 sesiones de laboratorio (6 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN Una cola es una lista lineal en la que todas las inserciones se hacen por un extremo y todas las supresiones (y normalmente todos los accesos) se hacen por el otro extremo de la lista. Por ejemplo, una fila en un banco. Este tipo de listas reciben también el nombre de listas FIFO (first in firts out – primero en entrar, primero en salir). Este orden, es la única forma de insertar y recuperar un elemento de la cola. En la Figura 8.2.6 se muestra un esquema de una cola:

Figura 8.2.6 Cola mediante listas lineales.

Departamento de Computación UNAN - León

Page 533: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 217 de 217

DISEÑANDO LA COLA La aplicación a diseñar simulará el funcionamiento de la cola de un banco. Normalmente en los bancos, hay una cola maestra, en la cual hacen cola los usuarios mientras son atendidos en una caja determinada. Para nuestro ejemplo suponemos que hay 3 cajas, numeradas de la 1 a la 3. Aunque en esta práctica usaremos tres cajas, el programa debe quedar preparado para usar cualquier número de cajas. La simulación que haremos obedece a la realidad cotidiana del funcionamiento de los bancos, la cual se puede formular así:

1. Un cliente llega al banco, busca la cola y se encola en dicha cola.

2. Si él es el único cliente en la cola y al menos una de las 3 cajas está vacía, entonces, se atenderá a dicho cliente en esa caja.

3. Si al momento de la llegada de un cliente a la cola, ya hay otros clientes

esperando (clientes encolados) a ser atendidos, entonces dicho cliente se pondrá al final de dicha cola.

4. Cada vez que una caja libera a un cliente (el cliente termina de ser

atendido), entonces, el cliente que está en el principio de la cola, pasa a ser atendido en esa caja liberada.

5. Para efectos de esta simulación se considerarán las siguientes

condiciones:

• Se iterará en el programa hasta agotar un tiempo TIEMPO_TOTAL que estará definido por el usuario. Dicho tiempo puede ser de 1, 2, 3,...n minutos.

• La llegada de los clientes será aleatoria, esto es: dentro del ciclo

principal, se generará un número aleatorio que esté en un intervalo determinado (lo decide el programador, pero puede ser por ejemplo: 4 <= tiempo_llegada <= 8, lo cual significa que un cliente puede aparecer como mínimo a los 4 segundos después del último, y como máximo a los 8 segundos después del último), y hasta que no se agote dicho tiempo, no se generará al cliente y no se introducirá en la cola maestra.

• Cada cliente generado, deberá también tener un tiempo de estancia

máximo a permanecer en caja (obviamente, este tiempo se controlará una vez que el cliente es atendido en una caja). Este tiempo también es generado aleatoriamente, y también lo decide el programador. Como ejemplo de este tiempo generado puede ser el intervalo: 12 <= t_caja_cliente <= 24, lo cual significa que un cliente como mínimo puede permanecer 12 segundos en caja, y como máximo, 24. A como puede verse, si nosotros aumentamos el tiempo de estancia que permanecerá un cliente en caja, y mantenemos constante o disminuimos el tiempo de llegada, la cola crecerá con bastante rapidez. Si por el contrario nosotros disminuimos el tiempo de

Departamento de Computación UNAN - León

Page 534: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 218 de 218

estancia, y aumentamos el tiempo de llegada, la cola casi siempre estará vacía, y los clientes serán atendidos en una caja, casi inmediatamente después que llegan a la cola.

• Para esta práctica se recomienda, en las diferentes corridas del

programa, aumentar el tiempo de estancia en caja y disminuir el tiempo de llegada, con el objetivo de lograr observar de qué manera la cola crece mientras algunos usuarios son atendidos en las cajas disponibles.

Una idea ilustrativa de lo expuesto puede verse en la Figura 8.2.7:

Figura 8.2.7 Funcionamiento de la cola a simular. Otro aspecto importante a tener en cuenta es que, cada cliente que va siendo atendido en una caja, deberá encolarse en una cola que la manejará cada caja, para efectos de llevar un control de qué clientes se han atendidos. Esto es, cada vez que un cliente pasa a ser atendido en una caja, dicha caja deberá tener la estructura y funcionalidad necesaria para crear y mantener una cola de clientes que han sido atendidos. Esto se hace con el objetivo de que luego de finalizada la ejecución de la aplicación, se pueda tener un listado de los clientes que han sido atendidos por caja. Se puede también buscar a un cliente determinado, y averiguar qué caja ha sido la más eficiente (la que ha atendido más clientes). La Figura 8.2.8 ilustra lo expuesto:

Departamento de Computación UNAN - León

Page 535: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 219 de 219

Figura 8.2.8 Clientes atendido en cada caja. Una vez explicado el diseño de la aplicación, pasaremos a observar las estructuras de datos necesarias para llevar a cabo la práctica.

Departamento de Computación UNAN - León

Page 536: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 220 de 220

DESARROLLO DE LA PRÁCTICA

struct datosCliente

int id_cliente; // identificador del cliente

int t_est_caja; // tiempo de estancia del cliente en caja

Los campos de la estructura de un cliente de la cola maestra, DatosCli, se explican a continuación:

t_lleg: Es el tiempo en el que llega el cliente a la cola maestra y está dado en segundos. El t_lleg se genera aleatoriamente dentro de un rango seleccionado por el programador. Cuando se agota ese tiempo de llegada, entonces ha llegado un nuevo cliente a la cola.

t_est_caja: Es el tiempo de estancia en caja y está dado en segundos. Se genera aleatoriamente dentro de un rango fijado por el programador. Este tiempo sólo será útil al momento en que el cliente empiece a ser atendido en la caja; entonces se deberá verificar a cada instante que el tiempo de estancia en caja, sumado al tiempo en que llegó a la caja, no exceda al tiempo actual como requisito fundamental para mantenerlo en la caja. Cuando el tiempo actual sea superior o igual al tiempo de llegada a caja más el tiempo de estancia en caja, el cliente deberá salir de la caja, y deberá ser atendido el cliente que está al inicio de la cola.

La cola maestra del banco deberá ser mantenida usando la siguiente estructura: typedef struct datosCliente DatosCli;

{

int t_lleg; // tiempo de llegada del cliente a la cola int t_lleg_caja; // tiempo de llegada del cliente a la caja

};

typedef struct Cola Cliente; // tipo Cliente struct Cola // estructura de un Cliente de la cola maestra { DatosCli cli; Cliente *sig; };

id_cliente: es un número entero que identifica a cada cliente. El valor que tomará el identificador del cliente será de auto incremento, es decir, usamos una variable contadora para asignársela a cada cliente que llega a la cola maestra. Así, el primer cliente en llegar a la cola, tendrá en su id_cliente el valor de 1, el siguiente cliente el valor de 2, y así.

t_lleg_caja: Es el tiempo en el que un cliente pasa a caja. Es decir, el tiempo en el que el cliente que estaba al inicio de la cola, comienza a ser atendido. Este tiempo es muy importante porque, sumado al tiempo en que el usuario estará en caja (se explica a continuación), se puede saber en qué momento el cliente abandonará la caja, para darle cabida a otro cliente.

Departamento de Computación UNAN - León

Page 537: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 221 de 221

Los campos de la estructura de un elemento de la cola maestra, Cliente, se explican a continuación: cli: es una variable de tipo DatosCli. El significado de DatosCli, es decir, los campos de los que consta, ya fueron explicados anteriormente. sig: es un apuntador a un objeto de tipo Cliente; esencial para mantener y administrar la cola. Las cajas deberán ser mantenidas usando la siguiente estructura: #define TIEMPO_TOTAL 2.0 * 60 // 2 minutos #define NUM_CAJAS 3 // Total de cajas #define OCUPADA 0 // Caja ocupada #define LIBRE 1 // Caja libra #define FALSO 0

Cliente *principio; // principio de Cola de Clientes atendidos

#define TRUE 1 enum ListaCajas /* tipo enumerado */ { Caja1 = 1, Caja2, Caja3 }; typedef struct datosCaja DatosCaja; struct datosCaja { int id_caja; // id_caja <- Caja1, Caja2, Caja3 int estado_caja; // OCUPADA <-- 0, LIBRE <-- 1 DatosCli cli; // cliente que está atendiendo }; typedef struct caja Caja; struct caja { DatosCaja dcaja; // datos de la caja

Cliente *final; // final de la Cola de Clientes atendidos }; Caja Cajas[NUM_CAJAS]; Los campos de la estructura correspondiente a los datos de una caja, DatosCaja, se listan a continuación: id_caja: Es el identificador de la caja. Es un número entero y puede tomar los valores del tipo enumerado ListaCajas. Ya que en el main( ) se define un arreglo de cajas de tres elementos, habrá que inicializar con una función (lo veremos más adelante) cada miembro de la estructura caja.

Departamento de Computación UNAN - León

Page 538: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 222 de 222

estado_caja: Representa al estado de la caja. Es un número entero y puede tomar los valores de OCUPADA o LIBRE. Cuando un cliente está siendo atendido, el estado es OCUPADA. Cuando no hay ningún cliente atendiéndose, el estado es LIBRE. cli: Es el cliente que está siendo atendido en ese momento. Los campos de dicho cliente ya fueron explicados en la estructura anterior. Los campos correspondientes a la estructura de una caja, Caja, se listan a continuación: dcaja: Es una variable de tipo DatosCaja. La estructura de DatosCaja, ya fue explicada anteriormente. principio: Es un apuntador a un objeto de tipo cliente. Cuando la caja ya ha atendido al menos a un cliente, apunta siempre al inicio de la cola de clientes atendidos. final: Es un apuntador a un objeto de tipo cliente. Cuando la caja ya ha atendido al menos a un cliente, apunta siempre al final de la cola de clientes atendidos. La directiz #define TIEMPO_TOTAL 2.0 * 60 define la constante TIEMPO_TOTAL que en este caso equivale a 120 segundos. Este es el tiempo total que durará el programa mientras genera clientes aleatoriamente y los atiende en las 3 cajas. Declare y defina las siguientes funciones: Cliente *NuevoCliente (void); Asigna memoria para un nuevo cliente. Es útil para crear nuevos clientes de la cola maestra. No acepta ningún valor como argumento y devuelve la dirección del objeto creado. void Introducir (Cliente **pc, Cliente **fc, DatosCli C); Introduce al cliente C, al final de la cola maestra. A como se ha venido diciendo, el cliente se introduce en la cola, una vez que el tiempo de llegada generado aleatoriamente, se agota.

Departamento de Computación UNAN - León

Page 539: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 223 de 223

DatosCli *RetirarClienteDeCola ( Cliente **pc, Cliente **fc); Retira al cliente que está al inicio de la cola para a continuación, darle atención en una caja que esté libre. Antes de retirar al cliente, se deberá comprobar que existe una caja disponible en donde atenderlo. Como sucede con las colas, el cliente que se retira del inicio de la cola, se elimina de la misma. Esta función, retorna un puntero a un objeto de tipo DatosCli, que se corresponde con la dirección del objeto retirado. void AtenderClienteEnCaja (Caja *pCaja, int num_caja_libre, DatosCli C); Atiende al cliente C que se ha sacado de la cola maestra, en la caja libre identificada por el argumento num_caja_libre. num_caja_libre es el índice con el que accederemos al arreglo cajas para atender al cliente. La funcionalidad de esta función puede ser resumida así: 1. Pone el estado de la caja num_caja_libre, a OCUPADA. 2. Copia al cliente en el campo dcaja.cli de la caja libre. 3. Crea y mantiene la cola de clientes atendidos. void ActualizarCajas (Caja *pCaja, int t_actual); Recorre el arreglo de cajas y verifica para cada caja que esté siendo ocupada por algún cliente, cuál cumple la condición de que el tiempo de llegada a caja, más el tiempo de estancia en caja, de ese cliente, sea mayor o igual que el tiempo actual que se pasa en el argumento t_actual. Cuando alguna de las cajas cumpla esa condición, su estado pasará de OCUPADA a LIBRE, y los campos correspondientes al cliente que se estaba atendiendo en ese momento, serán puestos a cero. void Visualizar (Cliente *pc, Cliente *fc); // Visualizar la cola Visualiza la cola de clientes. Puede ser llamada tanto para visualizar la cola maestra, como la cola de cada caja. Esta función no retorna nada, y acepta las direcciones de principio y fin de la cola. Verifica que la cola contenga elementos, y recorre la cola, mostrando los datos de cada cliente encontrado, hasta que llega a NULL. void EliminarLagunas (Cliente **pc, Cliente **fc); Elimina las posibles lagunas de memoria que pudiesen quedar, como consecuencia de un aborto del programa por parte del usuario antes que el programa finalice. La función no retorna nada, y acepta las direcciones de los punteros que apuntan al inicio y fin de la cola respectivamente. Si la cola está vacía, la función retorna si ejecutar ninguna acción. Si la cola contiene elementos, entonces, se recorre la cola y se va eliminando cada elemento hasta llegar a NULL.

Departamento de Computación UNAN - León

Page 540: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 224 de 224

void InicializarCajas (Caja *pCaja); // Inicializa las cajas Recorre el arreglo de cajas con una variable entera i, y hace las inicializaciones siguientes:

• dcaja.id_caja = i + 1; • dcaja.estado_caja = LIBRE; • dcaja.cli.id_cliente = 0; • dcaja.cli.t_lleg = 0; • dcaja.cli.t_lleg_caja = 0; • dcaja.cli.t_est_caja = 0; • principio = NULL; • final = NULL;

int CajaLibre (Caja *pCaja, int *num_caja_libre); Recorre el arreglo de cajas y verificar si alguna de ellas está libre, mediante la siguiente condición:

El campo estado_caja tienen el valor OCUPADO

La caja i-ésima está libre si:

Devuelve TRUE si alguna caja del arreglo apuntado por pCaja, está LIBRE. Devuelve FALSE en caso contrario. La caja libre se regresa por el argumento num_caja, el cual es un apuntador a un variable entera. int Menu(void); Presenta las siguientes opciones:

1. Listado de Clientes x Caja. 2. Búsqueda de Cliente.

3. Caja más eficiente. 4. Salir.

Hay que destacar que este menú es presentado, cuando se agota el tiempo dado por la constante TIEMPO_TOTAL. Se deja para el estudiante el diseño de las funciones que permitan ejecutar cada una de las órdenes del menú. A continuación, se presenta una corrida del programa para que el estudiante se de una idea de qué es lo que tiene que hacer a cada instante el programa en cuestión.

Nota: las entradas del usuario están en negritas cursivas y subrayadas.

Departamento de Computación UNAN - León

Page 541: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 225 de 225

---------------------------------------------------------------------------------------------------------- Thu Jul 01 16:18:27 2004 ****** SIMULACION DE LLEGADAS DE CLIENTES A UNA COLA ***** Cliente 1: --> Tiempo de llegada a la Cola: a los 3 seg Retirando al Cliente 1 de la cola... Cliente 1, paso a la CAJA 1 a los 3 seg. Tiempo en Caja: 17 seg Cliente 2: --> Tiempo de llegada a la Cola: a los 7 seg Retirando al Cliente 2 de la cola... Cliente 2, paso a la CAJA 2 a los 7 seg. Tiempo en Caja: 22 seg Cliente 3: --> Tiempo de llegada a la Cola: a los 11 seg Retirando al Cliente 3 de la cola... Cliente 3, paso a la CAJA 3 a los 11 seg. Tiempo en Caja: 19 seg Cliente 4: --> Tiempo de llegada a la Cola: a los 14 seg Cliente 5: --> Tiempo de llegada a la Cola: a los 16 seg Cliente 6: --> Tiempo de llegada a la Cola: a los 19 seg Cliente 1, finalizo su atencion en la CAJA 1, a los 20 seg Retirando al Cliente 4 de la cola... Cliente 4, paso a la CAJA 1 a los 20 seg. Tiempo en Caja: 13 seg Cliente 7: --> Tiempo de llegada a la Cola: a los 23 seg Cliente 8: --> Tiempo de llegada a la Cola: a los 26 seg Cliente 2, finalizo su atencion en la CAJA 2, a los 29 seg Cliente 9: --> Tiempo de llegada a la Cola: a los 29 seg Retirando al Cliente 5 de la cola... Cliente 5, paso a la CAJA 2 a los 29 seg. Tiempo en Caja: 15 seg Cliente 3, finalizo su atencion en la CAJA 3, a los 30 seg Retirando al Cliente 6 de la cola... Cliente 6, paso a la CAJA 3 a los 30 seg. Tiempo en Caja: 13 seg Cliente 10: --> Tiempo de llegada a la Cola: a los 31 seg Cliente 4, finalizo su atencion en la CAJA 1, a los 33 seg

Retirando al Cliente 8 de la cola...

Retirando al Cliente 7 de la cola... Cliente 7, paso a la CAJA 1 a los 33 seg. Tiempo en Caja: 23 seg Cliente 11: --> Tiempo de llegada a la Cola: a los 36 seg Cliente 12: --> Tiempo de llegada a la Cola: a los 38 seg Cliente 13: --> Tiempo de llegada a la Cola: a los 42 seg Cliente 6, finalizo su atencion en la CAJA 3, a los 43 seg

Cliente 8, paso a la CAJA 3 a los 43 seg. Tiempo en Caja: 22 seg Cliente 5, finalizo su atencion en la CAJA 2, a los 44 seg Retirando al Cliente 9 de la cola...

Departamento de Computación UNAN - León

Page 542: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 226 de 226

Cliente 9, paso a la CAJA 2 a los 44 seg. Tiempo en Caja: 13 seg Cliente 14: --> Tiempo de llegada a la Cola: a los 45 seg Cliente 15: --> Tiempo de llegada a la Cola: a los 50 seg Cliente 16: --> Tiempo de llegada a la Cola: a los 53 seg

Retirando al Cliente 12 de la cola...

Cliente 21: --> Tiempo de llegada a la Cola: a los 71 seg

Cliente 12, finalizo su atencion en la CAJA 3, a los 80 seg

Cliente 26: --> Tiempo de llegada a la Cola: a los 92 seg

Cliente 14, finalizo su atencion en la CAJA 1, a los 97 seg

Cliente 17: --> Tiempo de llegada a la Cola: a los 55 seg Cliente 7, finalizo su atencion en la CAJA 1, a los 56 seg Retirando al Cliente 10 de la cola... Cliente 10, paso a la CAJA 1 a los 56 seg. Tiempo en Caja: 23 seg

Cliente 9, finalizo su atencion en la CAJA 2, a los 57 seg Retirando al Cliente 11 de la cola... Cliente 11, paso a la CAJA 2 a los 57 seg. Tiempo en Caja: 17 seg Cliente 18: --> Tiempo de llegada a la Cola: a los 60 seg Cliente 8, finalizo su atencion en la CAJA 3, a los 65 seg Cliente 19: --> Tiempo de llegada a la Cola: a los 65 seg

Cliente 12, paso a la CAJA 3 a los 65 seg. Tiempo en Caja: 15 seg

Cliente 20: --> Tiempo de llegada a la Cola: a los 69 seg

Cliente 11, finalizo su atencion en la CAJA 2, a los 74 seg Retirando al Cliente 13 de la cola... Cliente 13, paso a la CAJA 2 a los 74 seg. Tiempo en Caja: 12 seg Cliente 22: --> Tiempo de llegada a la Cola: a los 76 seg Cliente 10, finalizo su atencion en la CAJA 1, a los 79 seg Cliente 23: --> Tiempo de llegada a la Cola: a los 79 seg Retirando al Cliente 14 de la cola... Cliente 14, paso a la CAJA 1 a los 79 seg. Tiempo en Caja: 18 seg

Retirando al Cliente 15 de la cola... Cliente 15, paso a la CAJA 3 a los 80 seg. Tiempo en Caja: 19 seg

Cliente 24: --> Tiempo de llegada a la Cola: a los 82 seg Cliente 13, finalizo su atencion en la CAJA 2, a los 86 seg Retirando al Cliente 16 de la cola... Cliente 16, paso a la CAJA 2 a los 86 seg. Tiempo en Caja: 16 seg

Cliente 25: --> Tiempo de llegada a la Cola: a los 87 seg

Cliente 27: --> Tiempo de llegada a la Cola: a los 94 seg

Retirando al Cliente 17 de la cola... Cliente 17, paso a la CAJA 1 a los 97 seg. Tiempo en Caja: 12 seg

Departamento de Computación UNAN - León

Page 543: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 227 de 227

Cliente 15, finalizo su atencion en la CAJA 3, a los 99 seg Cliente 28: --> Tiempo de llegada a la Cola: a los 99 seg Retirando al Cliente 18 de la cola... Cliente 18, paso a la CAJA 3 a los 99 seg. Tiempo en Caja: 16 seg

Cliente 31: --> Tiempo de llegada a la Cola: a los 114 seg

Cliente 21, paso a la CAJA 2 a los 114 seg. Tiempo en Caja: 14 seg

Cliente 20, finalizo su atencion en la CAJA 1, a los 125 seg

Cliente 16, finalizo su atencion en la CAJA 2, a los 102 seg Retirando al Cliente 19 de la cola... Cliente 19, paso a la CAJA 2 a los 102 seg. Tiempo en Caja: 12 seg Cliente 29: --> Tiempo de llegada a la Cola: a los 104 seg Cliente 17, finalizo su atencion en la CAJA 1, a los 109 seg Cliente 30: --> Tiempo de llegada a la Cola: a los 109 seg Retirando al Cliente 20 de la cola... Cliente 20, paso a la CAJA 1 a los 109 seg. Tiempo en Caja: 16 seg Cliente 19, finalizo su atencion en la CAJA 2, a los 114 seg

Retirando al Cliente 21 de la cola...

Cliente 18, finalizo su atencion en la CAJA 3, a los 115 seg Retirando al Cliente 22 de la cola... Cliente 22, paso a la CAJA 3 a los 115 seg. Tiempo en Caja: 15 seg Cliente 32: --> Tiempo de llegada a la Cola: a los 117 seg Cliente 33: --> Tiempo de llegada a la Cola: a los 119 seg Cliente 34: --> Tiempo de llegada a la Cola: a los 124 seg

Retirando al Cliente 23 de la cola... Cliente 23, paso a la CAJA 1 a los 125 seg. Tiempo en Caja: 22 seg Cliente 21, finalizo su atencion en la CAJA 2, a los 128 seg Retirando al Cliente 24 de la cola... Cliente 24, paso a la CAJA 2 a los 128 seg. Tiempo en Caja: 15 seg

Cliente 22, finalizo su atencion en la CAJA 3, a los 130 seg Retirando al Cliente 25 de la cola... Cliente 25, paso a la CAJA 3 a los 130 seg. Tiempo en Caja: 18 seg Cliente 24, finalizo su atencion en la CAJA 2, a los 143 seg Retirando al Cliente 26 de la cola... Cliente 26, paso a la CAJA 2 a los 143 seg. Tiempo en Caja: 16 seg Cliente 23, finalizo su atencion en la CAJA 1, a los 147 seg Retirando al Cliente 27 de la cola...

Departamento de Computación UNAN - León

Page 544: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 228 de 228

Cliente 27, paso a la CAJA 1 a los 147 seg. Tiempo en Caja: 18 seg Cliente 25, finalizo su atencion en la CAJA 3, a los 148 seg Retirando al Cliente 28 de la cola... Cliente 28, paso a la CAJA 3 a los 148 seg. Tiempo en Caja: 17 seg Cliente 26, finalizo su atencion en la CAJA 2, a los 159 seg Retirando al Cliente 29 de la cola... Cliente 29, paso a la CAJA 2 a los 159 seg. Tiempo en Caja: 22 seg Cliente 27, finalizo su atencion en la CAJA 1, a los 165 seg Cliente 28, finalizo su atencion en la CAJA 3, a los 165 seg

Retirando al Cliente 32 de la cola...

Cliente 33, paso a la CAJA 2 a los 181 seg. Tiempo en Caja: 13 seg

Retirando al Cliente 34 de la cola... Cliente 34, paso a la CAJA 1 a los 186 seg. Tiempo en Caja: 16 seg Cliente 33, finalizo su atencion en la CAJA 2, a los 194 seg Cliente 32, finalizo su atencion en la CAJA 3, a los 201 seg Cliente 34, finalizo su atencion en la CAJA 1, a los 202 seg Tiempo total en ejecutar el programa: 202 segundos Ultimo tiempo generado: 5

3. Caja mas eficiente.

Retirando al Cliente 30 de la cola... Cliente 30, paso a la CAJA 1 a los 165 seg. Tiempo en Caja: 21 seg Retirando al Cliente 31 de la cola... Cliente 31, paso a la CAJA 3 a los 165 seg. Tiempo en Caja: 15 seg Cliente 31, finalizo su atencion en la CAJA 3, a los 180 seg

Cliente 32, paso a la CAJA 3 a los 180 seg. Tiempo en Caja: 21 seg Cliente 29, finalizo su atencion en la CAJA 2, a los 181 seg Retirando al Cliente 33 de la cola...

Cliente 30, finalizo su atencion en la CAJA 1, a los 186 seg

****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente.

4. Salir.

Su opcion: 1

Departamento de Computación UNAN - León

Page 545: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 229 de 229

CAJA 1 Clte 1, T_Lleg_Cola: 3, T_Lleg_Caja: 3, T_est_caja: 17 -->

Clte 23, T_Lleg_Cola: 79, T_Lleg_Caja: 125, T_est_caja: 22 -->

Su opcion: 2

Clte 4, T_Lleg_Cola: 14, T_Lleg_Caja: 20, T_est_caja: 13 --> Clte 7, T_Lleg_Cola: 23, T_Lleg_Caja: 33, T_est_caja: 23 --> Clte 10, T_Lleg_Cola: 31, T_Lleg_Caja: 56, T_est_caja: 23 --> Clte 14, T_Lleg_Cola: 45, T_Lleg_Caja: 79, T_est_caja: 18 --> Clte 17, T_Lleg_Cola: 55, T_Lleg_Caja: 97, T_est_caja: 12 --> Clte 20, T_Lleg_Cola: 69, T_Lleg_Caja: 109, T_est_caja: 16 -->

Clte 27, T_Lleg_Cola: 94, T_Lleg_Caja: 147, T_est_caja: 18 --> Clte 30, T_Lleg_Cola: 109, T_Lleg_Caja: 165, T_est_caja: 21 --> Clte 34, T_Lleg_Cola: 124, T_Lleg_Caja: 186, T_est_caja: 16 --> NULL CAJA 2 Clte 2, T_Lleg_Cola: 7, T_Lleg_Caja: 7, T_est_caja: 22 --> Clte 5, T_Lleg_Cola: 16, T_Lleg_Caja: 29, T_est_caja: 15 --> Clte 9, T_Lleg_Cola: 29, T_Lleg_Caja: 44, T_est_caja: 13 --> Clte 11, T_Lleg_Cola: 36, T_Lleg_Caja: 57, T_est_caja: 17 --> Clte 13, T_Lleg_Cola: 42, T_Lleg_Caja: 74, T_est_caja: 12 --> Clte 16, T_Lleg_Cola: 53, T_Lleg_Caja: 86, T_est_caja: 16 --> Clte 19, T_Lleg_Cola: 65, T_Lleg_Caja: 102, T_est_caja: 12 --> Clte 21, T_Lleg_Cola: 71, T_Lleg_Caja: 114, T_est_caja: 14 --> Clte 24, T_Lleg_Cola: 82, T_Lleg_Caja: 128, T_est_caja: 15 --> Clte 26, T_Lleg_Cola: 92, T_Lleg_Caja: 143, T_est_caja: 16 --> Clte 29, T_Lleg_Cola: 104, T_Lleg_Caja: 159, T_est_caja: 22 --> Clte 33, T_Lleg_Cola: 119, T_Lleg_Caja: 181, T_est_caja: 13 --> NULL CAJA 3 Clte 3, T_Lleg_Cola: 11, T_Lleg_Caja: 11, T_est_caja: 19 --> Clte 6, T_Lleg_Cola: 19, T_Lleg_Caja: 30, T_est_caja: 13 --> Clte 8, T_Lleg_Cola: 26, T_Lleg_Caja: 43, T_est_caja: 22 --> Clte 12, T_Lleg_Cola: 38, T_Lleg_Caja: 65, T_est_caja: 15 --> Clte 15, T_Lleg_Cola: 50, T_Lleg_Caja: 80, T_est_caja: 19 --> Clte 18, T_Lleg_Cola: 60, T_Lleg_Caja: 99, T_est_caja: 16 --> Clte 22, T_Lleg_Cola: 76, T_Lleg_Caja: 115, T_est_caja: 15 --> Clte 25, T_Lleg_Cola: 87, T_Lleg_Caja: 130, T_est_caja: 18 --> Clte 28, T_Lleg_Cola: 99, T_Lleg_Caja: 148, T_est_caja: 17 --> Clte 31, T_Lleg_Cola: 114, T_Lleg_Caja: 165, T_est_caja: 15 --> Clte 32, T_Lleg_Cola: 117, T_Lleg_Caja: 180, T_est_caja: 21 --> NULL ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir.

Id del Cliente a buscar ?: 8

Cliente encontrado en la CAJA 3

Departamento de Computación UNAN - León

Page 546: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 230 de 230

****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente.

3. Caja mas eficiente. 4. Salir.

Su opcion: 3 La caja mas eficiente es la CAJA 2 ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir. Su opcion: 4 Press any key to continue

Departamento de Computación UNAN - León

Page 547: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 231 de 231

Solución de la práctica 6 APARTADO SOLUCIÓN: /* Simulación de llegadas de clientes a una cola de un banco*/ /* banco.c */ #include <stdio.h> #include <stdlib.h> #include <time.h> #include <conio.h> #include <string.h> #include <crtdbg.h> #define TIEMPO_TOTAL 2.0 * 60 // 2 minutos #define NUM_CAJAS 3 // Total de cajas #define OCUPADA 0 // Caja ocupada #define LIBRE 1 // Caja libra #define FALSO 0 #define TRUE 1 typedef struct datosCliente DatosCli; struct datosCliente { int id_cliente; // identificador del cliente int t_lleg; // tiempo de llegada del cliente a la cola int t_lleg_caja; // tiempo de llegada del cliente a la caja int t_est_caja; // tiempo de estancia del cliente en caja }; typedef struct Cola Cliente; // tipo Cliente struct Cola // estructura de un Cliente de la cola maestra { DatosCli cli; Cliente *sig; }; enum ListaCajas /* tipo enumerado */ { Caja1 = 1, Caja2, Caja3 }; typedef struct datosCaja DatosCaja; struct datosCaja { int id_caja; // id_caja <- Caja1, Caja2, Caja3 int estado_caja; // OCUPADA <-- 0, LIBRE <-- 1 DatosCli cli; // cliente que se está atendiendo };

Departamento de Computación UNAN - León

Page 548: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 232 de 232

typedef struct caja Caja; struct caja { DatosCaja dcaja; // datos de la caja Cliente *principio; // principio de Cola de Clientes atendidos Cliente *final; // final de la Cola de Clientes atendidos }; /* Prototipos de funciones */ void Error (void); Cliente *NuevoCliente (void); void Introducir (Cliente **pc, Cliente **fc, DatosCli C); void Visualizar (Cliente *pc, Cliente *fc); // Visualizar la cola void EliminarLagunas (Cliente **pc, Cliente **fc); void InicializarCajas (Caja *pCaja); // Inicializa las cajas int CajaLibre (Caja *pCaja, int *num_caja_libre); void AtenderClienteEnCaja (Caja *pCaja, int num_caja_libre, DatosCli C); DatosCli *RetirarClienteDeCola ( Cliente **pc, Cliente **fc); void ActualizarCajas (Caja *pCaja, int t_actual); int HayAlgunaCajaOcupada (Caja *pCaja); // Verifica si hay alguna caja ocupada int MayorTiempoEnCaja(Caja *pCaja); // Obtiene el mayor tiempo en caja int Menu(void); int BuscarClienteEnCajas (Caja *pCaja, int id_cliente); int BuscarClienteEnCola (Cliente *pc, Cliente *fc, int id_cliente); int CajaMasEficiente (Caja *pCaja); // Caja con más clientes atendidos int CantidadClientesCaja (Caja c); // Cantidad de Clientes x Caja void main (void) /* Función principal */ { int i, j, tm, tiempo_llegada, tiempo; time_t segundos; int t_in, t_fin; int t_caja_cliente; // tiempo que tardará el cliente en caja int num_veces; // Cantidad de veces que se ha generado un cliente int num_caja_libre; int t_ucl; // tiempo del último cliente en cola int id_cliente; int opcion; Cliente *principio, *final; // principio y final de la cola DatosCli C; DatosCli Cl_aux, *pCliente = NULL; Caja Cajas[NUM_CAJAS]; // Cajas de atención al cliente: 3 en total principio = final = NULL; /* cola vacía */ time (&segundos); printf("\n%s\n", ctime(&segundos) ); srand ((unsigned int) time(NULL)) ; printf("\n\t ****** SIMULACION DE LLEGADAS DE CLIENTES A UNA COLA *****\n\n");

Departamento de Computación UNAN - León

Page 549: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 233 de 233

i = 1; tiempo_llegada = 0; // 0 segundos al comenzar num_veces = 0; InicializarCajas (Cajas); num_caja_libre = -1; t_in = clock() / CLK_TCK; while ( ( clock() / CLK_TCK ) <= TIEMPO_TOTAL ) { num_veces++; tiempo = rand() % 4 + 2; // 2 <= tiempo <= 5 tiempo_llegada = tiempo_llegada + tiempo; do // Tiempo de espera igual a tiempo de llegada { tm = clock(); if (num_veces > 1) // Si ya hubo al menos un cliente en cola { if (principio != NULL && CajaLibre (Cajas, &num_caja_libre) == TRUE) { /* Hay una caja libre, atender al cliente en la caja: Esto implica: 1.Sacar a un cliente de la cola. 2.Poner el estado de la caja num_caja_libre a OCUPADA. 3.Crear un nuevo cliente en la cola de Clientes para esa caja. */ pCliente = RetirarClienteDeCola(&principio, &final); if (pCliente != NULL) printf("\n\tRetirando al Cliente %d de la cola...", pCliente->id_cliente); Cl_aux = *pCliente; // Copiar el contenido de pCliente // Atender al cliente Cl_aux en la caja num_caja_libre AtenderClienteEnCaja (Cajas, num_caja_libre, Cl_aux); /* Liberar la memoria del objeto referenciado por pCliente */ free (pCliente); } /* Actualizar las cajas: Comprobar qué cajas han cum- plido ya con su tiempo de atención al cliente, y que por lo tanto pasarán al estado de LIBRE. */

Departamento de Computación UNAN - León

Page 550: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 234 de 234

ActualizarCajas (Cajas, tm / CLK_TCK); } // Fin de if (num_veces > 1) } while (tm / CLK_TCK < tiempo_llegada); // fin de do while() /* Se genera un nuevo cliente en la cola después de tiempo_espera */ C.id_cliente = i; C.t_lleg = tiempo_llegada; /* Se genera un número aleatorio, que se corresponderá con el tiempo de estancia del cliente en caja. Suponemos que un cliente puede estar como mínimo, 12 segundos en caja y como máximo, 23 */ t_caja_cliente = rand() % 12 + 12; // 12 <= t_caja_cliente <= 23 C.t_est_caja = t_caja_cliente; C.t_lleg_caja = 0; /* Introducimos al cliente en la cola */ Introducir (&principio, &final, C); printf("\n\aCliente %d: --> Tiempo de llegada a la Cola: a los %2d seg", C.id_cliente, C.t_lleg); i++; } // Fin del while /* Si hay clientes que lograron entrar en las cajas y en la cola antes de que el banco cerrara, habrá terminar de atenderlos. */ /* La primera verificación será comprobar si hay clientes en cola. Si hubiese al menos 1 cliente en cola, significa que también los hay en cajas. Luego habrá que atenderlos a ambos. El último cliente en cola será el último en ser atendido. */ if (principio != NULL) { /* Iterar hasta el tiempo más alto que tenga un cliente que queda en caja. */ while ( (clock() / CLK_TCK) <= (MayorTiempoEnCaja(Cajas)) ) { if (principio != NULL && CajaLibre (Cajas, &num_caja_libre) == TRUE) { pCliente = RetirarClienteDeCola(&principio, &final); if (pCliente != NULL) printf("\n\tRetirando al Cliente %d de la cola...", pCliente->id_cliente); Cl_aux = *pCliente; // Copiar el contenido de pCliente

Departamento de Computación UNAN - León

Page 551: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 235 de 235

AtenderClienteEnCaja (Cajas, num_caja_libre, Cl_aux); free (pCliente); } else ActualizarCajas (Cajas, (clock() / CLK_TCK)); } // Fin del while() } // Cierre del if (principio != NULL) else { /* Si no hay clientes 1.Buscar en las cajas que quedaron con un cliente (OCUPADAS), el cliente que más tiempo tardará en ser atendido. 2.Una vez que conocemos ese tiempo, iteramos con el en un bucle hasta que dicho tiempo se agote. Entonces, todos los clientes habrán sido atendidos. */ if (HayAlgunaCajaOcupada(Cajas) == TRUE) { /* Obtener el tiempo más grande de los clientes que quedan en caja. */ t_ucl = MayorTiempoEnCaja(Cajas); while ( (clock() / CLK_TCK) <= t_ucl ) ActualizarCajas(Cajas, (clock() / CLK_TCK) ); } } t_fin = clock() / CLK_TCK; printf ("\n\nTiempo total en ejecutar el programa: %d segundos ", t_fin - t_in ); printf ("\n\nUltimo tiempo generado: %d \n", tiempo); while ( (opcion = Menu()) != 4) { switch (opcion) { case 1: // Listado de Clientes * Caja for (i = 0; i < NUM_CAJAS; i++) { printf("\n\n\t CAJA %d", i + 1); Visualizar(Cajas[i].principio, Cajas[i].final); } break; case 2: // Búsqueda de un cliente por id_cliente printf ("\n\t Id del Cliente a buscar ?: "); scanf ("%d", &id_cliente); i = BuscarClienteEnCajas (Cajas, id_cliente);

Departamento de Computación UNAN - León

Page 552: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 236 de 236

if (i != -1) printf ("\n\tCliente encontrado en la CAJA %d", i + 1); else printf ("Cliente no encontrado..."); break; case 3: j = CajaMasEficiente (Cajas); printf("\n\t La caja mas eficiente es la CAJA %d\n", j + 1); break; } // Fin de switch } /* Al salir, verificar si existen lagunas de memoria */ /* Eliminar posibles lagunas de la cola principal */ EliminarLagunas (&principio, &final); /* Eliminar posibles lagunas de cada caja */ for (j = 0; j < NUM_CAJAS; j++) EliminarLagunas ( &(Cajas[j].principio), &(Cajas[j].final) ); /* Verificar lagunas de memoria */ if ( _CrtDumpMemoryLeaks() ) printf ("\n\t Hay Lagunas de Memoria \n\n"); } // Fin del main() //////////////////////////////////////////////////////////////////////////////////////// //////////////////// Definición de funciones ///////////////////////// //////////////////////////////////////////////////////////////////////////////////////// /*************** Crear un nuevo Cliente de la cola *************/ Cliente *NuevoCliente () { Cliente *temp; temp = (Cliente *) malloc ( sizeof (Cliente) ); if (temp == NULL) Error(); return (temp); } // Fin de NuevoCliente () /*********** Error al asignar memoria ************************/ void Error (void) { perror ("Error: insuficiente espacio de memoria");

Departamento de Computación UNAN - León

Page 553: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 237 de 237

exit (1); } // Fin de Error() /************* Añadir un Cliente a una cola (al final) *************/ void Introducir (Cliente **p_cola, Cliente **f_cola, DatosCli C) { Cliente *pc, *fc, *q; pc = *p_cola; // Principio de la cola fc = *f_cola; // Final de la cola q = NuevoCliente (); q->cli = C; // Copiamos el nuevo cliente en q q->sig = NULL; if (fc == NULL) // Cola vacía pc = fc = q; else // Cola con al menos 1 Cliente { fc->sig = q; fc = fc->sig; } /* Actualizar el principio y el final de la cola */ *p_cola = pc; *f_cola = fc; } // Fin de Introducir() /************ Visualiza los Clientes de la cola ******************/ void Visualizar (Cliente *p_cola, Cliente *f_cola) { Cliente *pc, *fc; pc = p_cola; fc = f_cola; if (fc == NULL) { printf("\n\t Cola vacia...."); return; } // Recorrer la cola desde el principio hasta el final while (pc != NULL) { printf ("\nClte %2d, T_Lleg_Cola: %3d, T_Lleg_Caja: %3d, T_est_caja: %3d --> ", pc->cli.id_cliente, pc->cli.t_lleg, pc->cli.t_lleg_caja, pc->cli.t_est_caja);

Departamento de Computación UNAN - León

Page 554: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 238 de 238

pc = pc->sig; } printf("NULL"); } // Fin de Visualizar() /*********** Eliminar Lagunas de Memoria *******************/ void EliminarLagunas (Cliente **p_cola, Cliente **f_cola) { Cliente *pc, *fc, *aux; pc = *p_cola; fc = *f_cola; aux = pc; if (fc == NULL) return; // Si la cola está vacía, retornar else { // Recorrer la lista desde el principio y eliminar los Clientes while (pc != NULL) { aux = pc; pc = pc->sig; free (aux); } } // Fin del else pc = fc = aux = NULL; /* Actualizar los cambios */ *p_cola = pc; *f_cola = fc; } // Fin de EliminarLagunas()

Departamento de Computación UNAN - León

Page 555: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 239 de 239

/********** Inicializa las cajas de atención al cliente *********/ void InicializarCajas (Caja *pCaja) { int i = 0; for (i = 0; i < NUM_CAJAS; i++) { pCaja[i].dcaja.id_caja = i + 1; pCaja[i].dcaja.estado_caja = LIBRE; pCaja[i].dcaja.cli.id_cliente = 0; pCaja[i].dcaja.cli.t_lleg = 0; pCaja[i].dcaja.cli.t_lleg_caja = 0; pCaja[i].dcaja.cli.t_est_caja = 0; pCaja[i].principio = NULL; pCaja[i].final = NULL; } } // Fin de InicializarCajas() /*********** Verificar si hay alguna caja libre *****************/ int CajaLibre (Caja *pCaja, int *num_caja_libre) { int i; /* Recorrer el arreglo de cajas y verificar si alguna de ellas está libre, mediante la siguiente condición: La caja i-ésima está libre si: 1.El campo estado_caja tienen el valor OCUPADO */ for (i = 0; i < NUM_CAJAS; i++) { if (pCaja[i].dcaja.estado_caja == LIBRE) { *(num_caja_libre) = i; return (TRUE); } } // No hay ninguna caja dispobnible return (FALSO); } // Fin de CajaLibre()

Departamento de Computación UNAN - León

Page 556: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 240 de 240

/*************** Atender a un cliente en una caja libre *************/ void AtenderClienteEnCaja (Caja *pCaja, int num_caja_libre, DatosCli C) { /* num_caja_libre es el índice de la caja en el arreglo. La funcionalidad de esta función es como sigue: 1. Pone el estado de la caja num_caja_libre, a OCUPADA. 2. Copia al cliente en el campo dcaja.cli de la caja libre. 3. Crea y mantiene la cola de clientes atendidos. */ /* Accedemos al índice de la caja con el parámetro num_caja_libre */ pCaja[num_caja_libre].dcaja.estado_caja = OCUPADA; C.t_lleg_caja = clock() / CLK_TCK; // Tiempo en que el cliente pasa a la caja pCaja[num_caja_libre].dcaja.cli = C; // Atender al cliente C en la caja /* Llamar a la función Introducir, para introducir al cliente C en la cola de la caja. */ printf ("\n\tCliente %d, paso a la CAJA %d a los %d seg. Tiempo en Caja: %d seg \n", C.id_cliente, num_caja_libre + 1, C.t_lleg_caja, C.t_est_caja); Introducir ( &(pCaja[num_caja_libre].principio), &(pCaja[num_caja_libre].final), C ); } // Fin de AtenderClienteEnCaja() /*************** Sacar un elemento de la cola de Clientes **********/ DatosCli *RetirarClienteDeCola ( Cliente **p_cola, Cliente **f_cola) { Cliente *pc, *fc, *q; DatosCli *pDatosCli; pc = *p_cola; // pc --> principio de la cola fc = *f_cola; // fc --> fin de la cola if (fc != NULL) // Si la cola no esta vacía { q = pc; // q apunta al principio de la cola /* Le asignamos memoria a pCliente */ pDatosCli = (DatosCli *) malloc (sizeof (DatosCli)); if (pDatosCli == NULL) Error(); /* Copiamos el cliente del principio de la cola */ *pDatosCli = q->cli; pc = pc->sig; if (pc == NULL)

Departamento de Computación UNAN - León

Page 557: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 241 de 241

fc = NULL; /* había un solo cliente */ free (q); *p_cola = pc; *f_cola = fc; return (pDatosCli); } else { printf ("\n\t No hay clientes en la cola..."); return (NULL); } } // Fin de RetirarClienteDeCola() /********** Actualizar las cajas de acuerdo al tiempo *************/ void ActualizarCajas (Caja *pCaja, int t_actual) { int i; /* Recorrer las cajas y verificar qué cajas están OCUPADAS. A aquellas que estén ocupadas, verificar que el tiempo establecido de atención al cliente en relación con el tiempo de llegada a la caja, sea menor o igual al tiempo actual: tiempo de llegada a la caja + tiempo de estancia <= t_actual */ for (i = 0; i < NUM_CAJAS; i++) { if (pCaja[i].dcaja.estado_caja == OCUPADA) { /* Si la caja está OCUPADA, comprobar su tiempo */ if ( t_actual >= (pCaja[i].dcaja.cli.t_lleg_caja + pCaja[i].dcaja.cli.t_est_caja) ) { /* Poner el estado de la caja a LIBRE */ printf ("\n\tCliente %d, finalizo su atencion en la CAJA %d, a los %d seg \n", pCaja[i].dcaja.cli.id_cliente, pCaja[i].dcaja.id_caja, t_actual); pCaja[i].dcaja.estado_caja = LIBRE; pCaja[i].dcaja.cli.id_cliente = 0; pCaja[i].dcaja.cli.t_est_caja = 0; pCaja[i].dcaja.cli.t_lleg = 0; pCaja[i].dcaja.cli.t_lleg_caja = 0; } }

Departamento de Computación UNAN - León

Page 558: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 242 de 242

} // Fin del for } // Fin de ActualizarCajas() /*********** Verificar si hay alguna caja ocupada *****************/ int HayAlgunaCajaOcupada (Caja *pCaja) { /* Recorrer el arreglo de cajas, y verificar si alguna de ellas está ocupada. Si eso es así, retornar TRUE. */ int i; for (i = 0; i < NUM_CAJAS; i++) { if (pCaja[i].dcaja.estado_caja == OCUPADA) return (TRUE); } return (FALSO); } // Fin de HayAlgunaCajaOcupada() /**** Obtener el mayor tiempo de los clientes que quedan en caja ******/ int MayorTiempoEnCaja(Caja *pCaja) { int i, mayor, tiempo; mayor = 0; for (i = 0; i < NUM_CAJAS; i++) { if (pCaja[i].dcaja.estado_caja == OCUPADA) { tiempo = pCaja[i].dcaja.cli.t_lleg_caja + pCaja[i].dcaja.cli.t_est_caja; if ( tiempo >= mayor ) mayor = tiempo; } } return (mayor); } // Fin de MayorTiempoEnCaja() /***** Mirar Listado de Clientes x Caja y búsqueda de un cliente *****/ int Menu(void) { int opcion; do

Departamento de Computación UNAN - León

Page 559: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 243 de 243

{ printf ("\n"); printf ("\n\t ****** Opciones de Cajas ******"); printf ("\n\t 1. Listado de Clientes x Caja."); printf ("\n\t 2. Busqueda de Cliente."); printf ("\n\t 3. Caja mas eficiente."); printf ("\n\t 4. Salir."); printf ("\n\n\t Su opcion: "); scanf("%d", &opcion); } while (opcion < 1 || opcion > 4); return (opcion); } // Fin de Menu() /******** Buscar un Cliente por id_cliente en las cajas *********/ int BuscarClienteEnCajas (Caja *pCaja, int id_cliente) { int i, encontrado; for (i = 0; i < NUM_CAJAS; i++) { encontrado = BuscarClienteEnCola (pCaja[i].principio, pCaja[i].final, id_cliente); if (encontrado == TRUE) return (i); // retornar la caja i-ésima } return (-1); } // Fin de BuscarClienteEnCajas() /********* Busca al cliente id_cliente en la cola *********/ int BuscarClienteEnCola (Cliente *p_cola, Cliente *f_cola, int id_cliente) { int encontrado; Cliente *pc, *fc; pc = p_cola; fc = f_cola; if (fc == NULL) { printf("\n\t Cola vacia...."); return (FALSO); } // Recorrer la cola desde el principio hasta el final while (pc != NULL && pc->cli.id_cliente != id_cliente) pc = pc->sig ; if (pc != NULL) encontrado = TRUE;

Departamento de Computación UNAN - León

Page 560: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 244 de 244

else encontrado = FALSO; return (encontrado); } // Fin de BuscarClienteEnCola() /**** Caja con más clientes atendidos *****/ int CajaMasEficiente (Caja *pCaja) { int atenciones[NUM_CAJAS]; int i, j, mayor; for (i = 0; i < NUM_CAJAS; i++) atenciones[i] = CantidadClientesCaja (pCaja[i]); j = 0; mayor = atenciones[0]; for (i = 0; i < NUM_CAJAS; i++) { if (atenciones[i] > mayor) { mayor = atenciones[i]; j = i; } } return (j); } // Fin de CajaMasEficiente() //////////////////// CantidadClientesCaja //////////////////////////// int CantidadClientesCaja (Caja c) { int cont; Cliente *pc, *fc; pc = c.principio; fc = c.final; if (fc == NULL) { printf("\n\t Cola vacia...."); return (-1); } cont = 0; // Recorrer la cola desde el principio hasta el final while (pc != NULL) { cont++; pc = pc->sig;

Departamento de Computación UNAN - León

Page 561: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 245 de 245

} return (cont); } // Fin de CantidadClientesCaja()

Departamento de Computación UNAN - León

Page 562: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 246 de 246

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS

Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Compilador Visual C++ 6.0, para la compilación del archivo fuente y la construcción de archivo ejecutable.

• Microsoft Word 2000 para la edición del documento de entrega de la práctica.

• Microsoft Visio 2000 para la elaboración de las ilustraciones.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN Una cuestión primordial para controlar la ejecución del programa es la utilización de las funciones de tiempo y de generación de números aleatorios. Para llevar un control de cuánto tiempo ha pasado desde que se comenzó a ejecutar el programa, nosotros usamos la función clock( ) como sigue: while ( ( clock() / CLK_TCK ) <= TIEMPO_TOTAL ) { ................................ ................................ } donde TIEMPO_TOTAL es una constante definida de la siguiente forma: #define TIEMPO_TOTAL 2.0 * 60 // 2 minutos La función clock( ) indica el tiempo empleado por el procesador en el proceso llamado, en el momento en que dicha función es ejecutada. Ya que este tiempo es dado en milésimas de segundos, habrá que dividirlo entre el valor de la macro CLK_TCK o CLOCK_PER_SEC (versión ANSI), las cuales tienen el valor de 1000. Para generar un cliente en la cola, nosotros lo hacemos de forma aleatoria. Es decir, generamos un número en el rango [2 – 6], y esperamos a que el tiempo llegue a ese valor generado. Cuando esto sucede, entonces habrá entrado un nuevo cliente a la cola. Lo expuesto anteriormente queda plasmado en el siguiente código:

Departamento de Computación UNAN - León

Page 563: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 247 de 247

tiempo = rand() % 4 + 2; // 2 <= tiempo <= 5 tiempo_llegada = tiempo_llegada + tiempo; do // Tiempo de espera igual a tiempo de llegada { tm = clock(); if (num_veces > 1) // Si ya hubo al menos un cliente en cola { if (principio != NULL && CajaLibre (Cajas, &num_caja_libre) == TRUE) { /* Hay una caja libre, atender al cliente en la caja: Esto implica: 1.Sacar a un cliente de la cola. 2.Poner el estado de la caja num_caja_libre a OCUPADA. 3.Crear un nuevo cliente en la cola de Clientes para esa caja. */ pCliente = RetirarClienteDeCola(&principio, &final); if (pCliente != NULL) printf("\n\tRetirando al Cliente %d de la cola...", pCliente->id_cliente); Cl_aux = *pCliente; // Copiar el contenido de pCliente // Atender al cliente Cl_aux en la caja num_caja_libre AtenderClienteEnCaja (Cajas, num_caja_libre, Cl_aux); /* Liberar la memoria del objeto referenciado por pCliente */ free (pCliente); } /* Actualizar las cajas: Comprobar qué cajas han cum- plido ya con su tiempo de atención al cliente, y que por lo tanto pasarán al estado de LIBRE. */ ActualizarCajas (Cajas, tm / CLK_TCK); } // Fin de if (num_veces > 1) } while (tm / CLK_TCK < tiempo_llegada); // fin de do while()

Hay 2 funciones muy importantes que podemos aclarar en este punto; ellas son:

Departamento de Computación UNAN - León

Page 564: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 248 de 248

AtenderClienteEnCaja (Cajas, num_caja_libre, DatosCli C); Esta función se ejecuta luego que se comprueba que hay al menos una caja disponible para atender al cliente. Esta función cambia el estado de la caja de LIBRE a OCUPADA, copia al cliente en el campo cli de la caja, e introduce al cliente en la cola correspondiente en esa caja. La definición de esta función es como sigue: void AtenderClienteEnCaja (Caja *pCaja, int num_caja_libre, DatosCli C) { pCaja[num_caja_libre].dcaja.estado_caja = OCUPADA; C.t_lleg_caja = clock() / CLK_TCK; // Tiempo en que el cliente pasa a la //caja pCaja[num_caja_libre].dcaja.cli = C; // Atender al cliente C en la caja printf ("\n\tCliente %d, paso a la CAJA %d a los %d seg. Tiempo en Caja: %d seg \n", C.id_cliente, num_caja_libre + 1, C.t_lleg_caja, C.t_est_caja); Introducir ( &(pCaja[num_caja_libre].principio), &(pCaja[num_caja_libre].final), C ); } // Fin de AtenderClienteEnCaja() La segunda función, y quizá la más importante, es la que se encarga de actualizar las cajas. ActualizarCajas (Cajas, tm / CLK_TCK); Ya que el tiempo transcurre entre la llegada de clientes a la cola maestra y la atención en las cajas, habrá que vigilar a cada momento cuando un cliente ha agotado su tiempo de estancia en caja. A como se ha dicho anteriormente, este tiempo se ha generado de forma aleatoria. La estrategia será recorrer cada caja y verificar si su tiempo de estancia en caja (al cual debe sumarse el tiempo de llegada, para obtener el tiempo total que el cliente lleva desde que llegó a la cola) se ha agotado. Si esto fuese así, el estado de la caja se actualiza a LIBRE, y cuando se regrese de la función y el ciclo while( ) itere de nuevo, se verificará que hay una caja disponible para atender al cliente. La definición de la función es como sigue: void ActualizarCajas (Caja *pCaja, int t_actual) { int i; /* Recorrer las cajas y verificar qué cajas están OCUPADAS. A aquellas que estén ocupadas, verificar que el tiempo establecido de atención al cliente en relación con el tiempo de llegada, sea menor o igual al tiempo actual: tiempo de llegada + tiempo de estancia < t_actual */ for (i = 0; i < NUM_CAJAS; i++) {

Departamento de Computación UNAN - León

Page 565: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 249 de 249

if (pCaja[i].dcaja.estado_caja == OCUPADA) { /* Si la caja está OCUPADA, comprobar su tiempo */ if ( t_actual >= (pCaja[i].dcaja.cli.t_lleg_caja + pCaja[i].dcaja.cli.t_est_caja) ) { /* Poner el estado de la caja a LIBRE */ printf ("\n\tCliente %d, finalizo su atencion en la CAJA %d, a los %d seg \n", pCaja[i].dcaja.cli.id_cliente, pCaja[i].dcaja.id_caja, t_actual); pCaja[i].dcaja.estado_caja = LIBRE; pCaja[i].dcaja.cli.id_cliente = 0; pCaja[i].dcaja.cli.t_est_caja = 0; pCaja[i].dcaja.cli.t_lleg = 0; pCaja[i].dcaja.cli.t_lleg_caja = 0; } } } // Fin del for } // Fin de ActualizarCajas()

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. Ya que por la naturaleza del programa, no existen entradas por parte del usuario, sólo se presentará la salida que se genera al momento de ejecutarlo. PRIMERA EJECUCIÓN: Nota: Las entradas del usuario están en negritas cursivas y en subrayado. -------------------------------------------------------------------------------------------------------- Thu Jul 01 16:18:27 2004 ****** SIMULACION DE LLEGADAS DE CLIENTES A UNA COLA ***** Cliente 1: --> Tiempo de llegada a la Cola: a los 3 seg Retirando al Cliente 1 de la cola... Cliente 1, paso a la CAJA 1 a los 3 seg. Tiempo en Caja: 17 seg Cliente 2: --> Tiempo de llegada a la Cola: a los 7 seg Retirando al Cliente 2 de la cola... Cliente 2, paso a la CAJA 2 a los 7 seg. Tiempo en Caja: 22 seg Cliente 3: --> Tiempo de llegada a la Cola: a los 11 seg Retirando al Cliente 3 de la cola... Cliente 3, paso a la CAJA 3 a los 11 seg. Tiempo en Caja: 19 seg

Departamento de Computación UNAN - León

Page 566: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 250 de 250

Cliente 4: --> Tiempo de llegada a la Cola: a los 14 seg Cliente 5: --> Tiempo de llegada a la Cola: a los 16 seg Cliente 6: --> Tiempo de llegada a la Cola: a los 19 seg Cliente 1, finalizo su atencion en la CAJA 1, a los 20 seg Retirando al Cliente 4 de la cola... Cliente 4, paso a la CAJA 1 a los 20 seg. Tiempo en Caja: 13 seg Cliente 7: --> Tiempo de llegada a la Cola: a los 23 seg Cliente 8: --> Tiempo de llegada a la Cola: a los 26 seg Cliente 2, finalizo su atencion en la CAJA 2, a los 29 seg Cliente 9: --> Tiempo de llegada a la Cola: a los 29 seg Retirando al Cliente 5 de la cola... Cliente 5, paso a la CAJA 2 a los 29 seg. Tiempo en Caja: 15 seg Cliente 3, finalizo su atencion en la CAJA 3, a los 30 seg Retirando al Cliente 6 de la cola... Cliente 6, paso a la CAJA 3 a los 30 seg. Tiempo en Caja: 13 seg Cliente 10: --> Tiempo de llegada a la Cola: a los 31 seg Cliente 4, finalizo su atencion en la CAJA 1, a los 33 seg Retirando al Cliente 7 de la cola... Cliente 7, paso a la CAJA 1 a los 33 seg. Tiempo en Caja: 23 seg Cliente 11: --> Tiempo de llegada a la Cola: a los 36 seg Cliente 12: --> Tiempo de llegada a la Cola: a los 38 seg Cliente 13: --> Tiempo de llegada a la Cola: a los 42 seg Cliente 6, finalizo su atencion en la CAJA 3, a los 43 seg Retirando al Cliente 8 de la cola... Cliente 8, paso a la CAJA 3 a los 43 seg. Tiempo en Caja: 22 seg Cliente 5, finalizo su atencion en la CAJA 2, a los 44 seg Retirando al Cliente 9 de la cola... Cliente 9, paso a la CAJA 2 a los 44 seg. Tiempo en Caja: 13 seg Cliente 14: --> Tiempo de llegada a la Cola: a los 45 seg Cliente 15: --> Tiempo de llegada a la Cola: a los 50 seg Cliente 16: --> Tiempo de llegada a la Cola: a los 53 seg Cliente 17: --> Tiempo de llegada a la Cola: a los 55 seg Cliente 7, finalizo su atencion en la CAJA 1, a los 56 seg Retirando al Cliente 10 de la cola... Cliente 10, paso a la CAJA 1 a los 56 seg. Tiempo en Caja: 23 seg Cliente 9, finalizo su atencion en la CAJA 2, a los 57 seg Retirando al Cliente 11 de la cola... Cliente 11, paso a la CAJA 2 a los 57 seg. Tiempo en Caja: 17 seg Cliente 18: --> Tiempo de llegada a la Cola: a los 60 seg Cliente 8, finalizo su atencion en la CAJA 3, a los 65 seg

Departamento de Computación UNAN - León

Page 567: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 251 de 251

Cliente 19: --> Tiempo de llegada a la Cola: a los 65 seg Retirando al Cliente 12 de la cola... Cliente 12, paso a la CAJA 3 a los 65 seg. Tiempo en Caja: 15 seg Cliente 20: --> Tiempo de llegada a la Cola: a los 69 seg Cliente 21: --> Tiempo de llegada a la Cola: a los 71 seg

Retirando al Cliente 17 de la cola...

Cliente 19, paso a la CAJA 2 a los 102 seg. Tiempo en Caja: 12 seg

Cliente 29: --> Tiempo de llegada a la Cola: a los 104 seg

Cliente 11, finalizo su atencion en la CAJA 2, a los 74 seg Retirando al Cliente 13 de la cola... Cliente 13, paso a la CAJA 2 a los 74 seg. Tiempo en Caja: 12 seg Cliente 22: --> Tiempo de llegada a la Cola: a los 76 seg Cliente 10, finalizo su atencion en la CAJA 1, a los 79 seg Cliente 23: --> Tiempo de llegada a la Cola: a los 79 seg Retirando al Cliente 14 de la cola... Cliente 14, paso a la CAJA 1 a los 79 seg. Tiempo en Caja: 18 seg Cliente 12, finalizo su atencion en la CAJA 3, a los 80 seg Retirando al Cliente 15 de la cola... Cliente 15, paso a la CAJA 3 a los 80 seg. Tiempo en Caja: 19 seg Cliente 24: --> Tiempo de llegada a la Cola: a los 82 seg Cliente 13, finalizo su atencion en la CAJA 2, a los 86 seg Retirando al Cliente 16 de la cola... Cliente 16, paso a la CAJA 2 a los 86 seg. Tiempo en Caja: 16 seg Cliente 25: --> Tiempo de llegada a la Cola: a los 87 seg Cliente 26: --> Tiempo de llegada a la Cola: a los 92 seg Cliente 27: --> Tiempo de llegada a la Cola: a los 94 seg Cliente 14, finalizo su atencion en la CAJA 1, a los 97 seg

Cliente 17, paso a la CAJA 1 a los 97 seg. Tiempo en Caja: 12 seg Cliente 15, finalizo su atencion en la CAJA 3, a los 99 seg Cliente 28: --> Tiempo de llegada a la Cola: a los 99 seg Retirando al Cliente 18 de la cola... Cliente 18, paso a la CAJA 3 a los 99 seg. Tiempo en Caja: 16 seg Cliente 16, finalizo su atencion en la CAJA 2, a los 102 seg Retirando al Cliente 19 de la cola...

Cliente 17, finalizo su atencion en la CAJA 1, a los 109 seg

Cliente 30: --> Tiempo de llegada a la Cola: a los 109 seg Retirando al Cliente 20 de la cola... Cliente 20, paso a la CAJA 1 a los 109 seg. Tiempo en Caja: 16 seg

Departamento de Computación UNAN - León

Page 568: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 252 de 252

Cliente 19, finalizo su atencion en la CAJA 2, a los 114 seg Cliente 31: --> Tiempo de llegada a la Cola: a los 114 seg Retirando al Cliente 21 de la cola... Cliente 21, paso a la CAJA 2 a los 114 seg. Tiempo en Caja: 14 seg

Cliente 22, paso a la CAJA 3 a los 115 seg. Tiempo en Caja: 15 seg

Cliente 32: --> Tiempo de llegada a la Cola: a los 117 seg

Cliente 25, finalizo su atencion en la CAJA 3, a los 148 seg

Cliente 29, paso a la CAJA 2 a los 159 seg. Tiempo en Caja: 22 seg

Cliente 27, finalizo su atencion en la CAJA 1, a los 165 seg

Cliente 28, finalizo su atencion en la CAJA 3, a los 165 seg

Cliente 18, finalizo su atencion en la CAJA 3, a los 115 seg

Retirando al Cliente 22 de la cola...

Cliente 33: --> Tiempo de llegada a la Cola: a los 119 seg Cliente 34: --> Tiempo de llegada a la Cola: a los 124 seg Cliente 20, finalizo su atencion en la CAJA 1, a los 125 seg Retirando al Cliente 23 de la cola... Cliente 23, paso a la CAJA 1 a los 125 seg. Tiempo en Caja: 22 seg Cliente 21, finalizo su atencion en la CAJA 2, a los 128 seg

Retirando al Cliente 24 de la cola... Cliente 24, paso a la CAJA 2 a los 128 seg. Tiempo en Caja: 15 seg Cliente 22, finalizo su atencion en la CAJA 3, a los 130 seg

Retirando al Cliente 25 de la cola... Cliente 25, paso a la CAJA 3 a los 130 seg. Tiempo en Caja: 18 seg Cliente 24, finalizo su atencion en la CAJA 2, a los 143 seg Retirando al Cliente 26 de la cola... Cliente 26, paso a la CAJA 2 a los 143 seg. Tiempo en Caja: 16 seg

Cliente 23, finalizo su atencion en la CAJA 1, a los 147 seg Retirando al Cliente 27 de la cola... Cliente 27, paso a la CAJA 1 a los 147 seg. Tiempo en Caja: 18 seg

Retirando al Cliente 28 de la cola... Cliente 28, paso a la CAJA 3 a los 148 seg. Tiempo en Caja: 17 seg Cliente 26, finalizo su atencion en la CAJA 2, a los 159 seg Retirando al Cliente 29 de la cola...

Retirando al Cliente 30 de la cola... Cliente 30, paso a la CAJA 1 a los 165 seg. Tiempo en Caja: 21 seg

Departamento de Computación UNAN - León

Page 569: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 253 de 253

Retirando al Cliente 31 de la cola... Cliente 31, paso a la CAJA 3 a los 165 seg. Tiempo en Caja: 15 seg Cliente 31, finalizo su atencion en la CAJA 3, a los 180 seg Retirando al Cliente 32 de la cola...

Cliente 33, paso a la CAJA 2 a los 181 seg. Tiempo en Caja: 13 seg

Cliente 32, finalizo su atencion en la CAJA 3, a los 201 seg

Cliente 32, paso a la CAJA 3 a los 180 seg. Tiempo en Caja: 21 seg

Cliente 29, finalizo su atencion en la CAJA 2, a los 181 seg

Retirando al Cliente 33 de la cola...

Cliente 30, finalizo su atencion en la CAJA 1, a los 186 seg Retirando al Cliente 34 de la cola... Cliente 34, paso a la CAJA 1 a los 186 seg. Tiempo en Caja: 16 seg Cliente 33, finalizo su atencion en la CAJA 2, a los 194 seg

Cliente 34, finalizo su atencion en la CAJA 1, a los 202 seg Tiempo total en ejecutar el programa: 202 segundos Ultimo tiempo generado: 5 ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir.

Su opcion: 1 CAJA 1 Clte 1, T_Lleg_Cola: 3, T_Lleg_Caja: 3, T_est_caja: 17 -->

Clte 4, T_Lleg_Cola: 14, T_Lleg_Caja: 20, T_est_caja: 13 --> Clte 7, T_Lleg_Cola: 23, T_Lleg_Caja: 33, T_est_caja: 23 --> Clte 10, T_Lleg_Cola: 31, T_Lleg_Caja: 56, T_est_caja: 23 --> Clte 14, T_Lleg_Cola: 45, T_Lleg_Caja: 79, T_est_caja: 18 --> Clte 17, T_Lleg_Cola: 55, T_Lleg_Caja: 97, T_est_caja: 12 --> Clte 20, T_Lleg_Cola: 69, T_Lleg_Caja: 109, T_est_caja: 16 --> Clte 23, T_Lleg_Cola: 79, T_Lleg_Caja: 125, T_est_caja: 22 --> Clte 27, T_Lleg_Cola: 94, T_Lleg_Caja: 147, T_est_caja: 18 --> Clte 30, T_Lleg_Cola: 109, T_Lleg_Caja: 165, T_est_caja: 21 --> Clte 34, T_Lleg_Cola: 124, T_Lleg_Caja: 186, T_est_caja: 16 --> NULL

Departamento de Computación UNAN - León

Page 570: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 254 de 254

CAJA 2 Clte 2, T_Lleg_Cola: 7, T_Lleg_Caja: 7, T_est_caja: 22 --> Clte 5, T_Lleg_Cola: 16, T_Lleg_Caja: 29, T_est_caja: 15 --> Clte 9, T_Lleg_Cola: 29, T_Lleg_Caja: 44, T_est_caja: 13 --> Clte 11, T_Lleg_Cola: 36, T_Lleg_Caja: 57, T_est_caja: 17 --> Clte 13, T_Lleg_Cola: 42, T_Lleg_Caja: 74, T_est_caja: 12 --> Clte 16, T_Lleg_Cola: 53, T_Lleg_Caja: 86, T_est_caja: 16 --> Clte 19, T_Lleg_Cola: 65, T_Lleg_Caja: 102, T_est_caja: 12 --> Clte 21, T_Lleg_Cola: 71, T_Lleg_Caja: 114, T_est_caja: 14 --> Clte 24, T_Lleg_Cola: 82, T_Lleg_Caja: 128, T_est_caja: 15 --> Clte 26, T_Lleg_Cola: 92, T_Lleg_Caja: 143, T_est_caja: 16 --> Clte 29, T_Lleg_Cola: 104, T_Lleg_Caja: 159, T_est_caja: 22 --> Clte 33, T_Lleg_Cola: 119, T_Lleg_Caja: 181, T_est_caja: 13 --> NULL CAJA 3 Clte 3, T_Lleg_Cola: 11, T_Lleg_Caja: 11, T_est_caja: 19 --> Clte 6, T_Lleg_Cola: 19, T_Lleg_Caja: 30, T_est_caja: 13 --> Clte 8, T_Lleg_Cola: 26, T_Lleg_Caja: 43, T_est_caja: 22 --> Clte 12, T_Lleg_Cola: 38, T_Lleg_Caja: 65, T_est_caja: 15 --> Clte 15, T_Lleg_Cola: 50, T_Lleg_Caja: 80, T_est_caja: 19 --> Clte 18, T_Lleg_Cola: 60, T_Lleg_Caja: 99, T_est_caja: 16 --> Clte 22, T_Lleg_Cola: 76, T_Lleg_Caja: 115, T_est_caja: 15 --> Clte 25, T_Lleg_Cola: 87, T_Lleg_Caja: 130, T_est_caja: 18 --> Clte 28, T_Lleg_Cola: 99, T_Lleg_Caja: 148, T_est_caja: 17 --> Clte 31, T_Lleg_Cola: 114, T_Lleg_Caja: 165, T_est_caja: 15 --> Clte 32, T_Lleg_Cola: 117, T_Lleg_Caja: 180, T_est_caja: 21 --> NULL ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir. Su opcion: 2 Id del Cliente a buscar ?: 8 Cliente encontrado en la CAJA 3 ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir. Su opcion: 3 La caja mas eficiente es la CAJA 2 ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir.

Departamento de Computación UNAN - León

Page 571: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 255 de 255

Su opcion: 4Press any key to continue SEGUNDA EJECUCIÓN: ---------------------------------------------------------------------------------------------------------- Thu Jul 01 16:31:03 2004 ****** SIMULACION DE LLEGADAS DE CLIENTES A UNA COLA ***** Cliente 1: --> Tiempo de llegada a la Cola: a los 4 seg Retirando al Cliente 1 de la cola... Cliente 1, paso a la CAJA 1 a los 4 seg. Tiempo en Caja: 20 seg Cliente 2: --> Tiempo de llegada a la Cola: a los 9 seg Retirando al Cliente 2 de la cola... Cliente 2, paso a la CAJA 2 a los 9 seg. Tiempo en Caja: 20 seg Cliente 3: --> Tiempo de llegada a la Cola: a los 11 seg Retirando al Cliente 3 de la cola... Cliente 3, paso a la CAJA 3 a los 11 seg. Tiempo en Caja: 23 seg Cliente 4: --> Tiempo de llegada a la Cola: a los 15 seg Cliente 5: --> Tiempo de llegada a la Cola: a los 19 seg Cliente 6: --> Tiempo de llegada a la Cola: a los 21 seg Cliente 7: --> Tiempo de llegada a la Cola: a los 23 seg Cliente 1, finalizo su atencion en la CAJA 1, a los 24 seg Retirando al Cliente 4 de la cola... Cliente 4, paso a la CAJA 1 a los 24 seg. Tiempo en Caja: 17 seg

Cliente 10: --> Tiempo de llegada a la Cola: a los 29 seg

Cliente 5, paso a la CAJA 2 a los 29 seg. Tiempo en Caja: 20 seg

Cliente 11: --> Tiempo de llegada a la Cola: a los 32 seg

Cliente 6, paso a la CAJA 3 a los 34 seg. Tiempo en Caja: 16 seg

Cliente 12: --> Tiempo de llegada a la Cola: a los 35 seg

Cliente 4, finalizo su atencion en la CAJA 1, a los 41 seg

Retirando al Cliente 7 de la cola...

Cliente 8: --> Tiempo de llegada a la Cola: a los 25 seg Cliente 9: --> Tiempo de llegada a la Cola: a los 27 seg Cliente 2, finalizo su atencion en la CAJA 2, a los 29 seg

Retirando al Cliente 5 de la cola...

Cliente 3, finalizo su atencion en la CAJA 3, a los 34 seg

Retirando al Cliente 6 de la cola...

Cliente 13: --> Tiempo de llegada a la Cola: a los 39 seg

Cliente 7, paso a la CAJA 1 a los 41 seg. Tiempo en Caja: 21 seg Cliente 14: --> Tiempo de llegada a la Cola: a los 44 seg Cliente 5, finalizo su atencion en la CAJA 2, a los 49 seg

Departamento de Computación UNAN - León

Page 572: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 256 de 256

Cliente 15: --> Tiempo de llegada a la Cola: a los 49 seg

Cliente 9, paso a la CAJA 3 a los 50 seg. Tiempo en Caja: 22 seg

Cliente 16: --> Tiempo de llegada a la Cola: a los 54 seg

Cliente 24: --> Tiempo de llegada a la Cola: a los 85 seg

Retirando al Cliente 8 de la cola... Cliente 8, paso a la CAJA 2 a los 49 seg. Tiempo en Caja: 22 seg Cliente 6, finalizo su atencion en la CAJA 3, a los 50 seg Retirando al Cliente 9 de la cola...

Cliente 17: --> Tiempo de llegada a la Cola: a los 57 seg Cliente 7, finalizo su atencion en la CAJA 1, a los 62 seg Cliente 18: --> Tiempo de llegada a la Cola: a los 62 seg Retirando al Cliente 10 de la cola... Cliente 10, paso a la CAJA 1 a los 62 seg. Tiempo en Caja: 13 seg Cliente 19: --> Tiempo de llegada a la Cola: a los 65 seg Cliente 20: --> Tiempo de llegada a la Cola: a los 68 seg Cliente 8, finalizo su atencion en la CAJA 2, a los 71 seg Retirando al Cliente 11 de la cola... Cliente 11, paso a la CAJA 2 a los 71 seg. Tiempo en Caja: 22 seg Cliente 9, finalizo su atencion en la CAJA 3, a los 72 seg Retirando al Cliente 12 de la cola... Cliente 12, paso a la CAJA 3 a los 72 seg. Tiempo en Caja: 22 seg Cliente 21: --> Tiempo de llegada a la Cola: a los 73 seg Cliente 10, finalizo su atencion en la CAJA 1, a los 75 seg Retirando al Cliente 13 de la cola... Cliente 13, paso a la CAJA 1 a los 75 seg. Tiempo en Caja: 18 seg Cliente 22: --> Tiempo de llegada a la Cola: a los 77 seg Cliente 23: --> Tiempo de llegada a la Cola: a los 82 seg

Cliente 25: --> Tiempo de llegada a la Cola: a los 90 seg Cliente 13, finalizo su atencion en la CAJA 1, a los 93 seg Cliente 11, finalizo su atencion en la CAJA 2, a los 93 seg Retirando al Cliente 14 de la cola... Cliente 14, paso a la CAJA 1 a los 93 seg. Tiempo en Caja: 15 seg Retirando al Cliente 15 de la cola... Cliente 15, paso a la CAJA 2 a los 93 seg. Tiempo en Caja: 16 seg Cliente 12, finalizo su atencion en la CAJA 3, a los 94 seg Cliente 26: --> Tiempo de llegada a la Cola: a los 94 seg Retirando al Cliente 16 de la cola... Cliente 16, paso a la CAJA 3 a los 94 seg. Tiempo en Caja: 22 seg

Departamento de Computación UNAN - León

Page 573: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 257 de 257

Cliente 27: --> Tiempo de llegada a la Cola: a los 98 seg Cliente 28: --> Tiempo de llegada a la Cola: a los 100 seg Cliente 29: --> Tiempo de llegada a la Cola: a los 102 seg Cliente 30: --> Tiempo de llegada a la Cola: a los 106 seg Cliente 14, finalizo su atencion en la CAJA 1, a los 108 seg Retirando al Cliente 17 de la cola... Cliente 17, paso a la CAJA 1 a los 108 seg. Tiempo en Caja: 14 seg Cliente 15, finalizo su atencion en la CAJA 2, a los 109 seg Retirando al Cliente 18 de la cola... Cliente 18, paso a la CAJA 2 a los 109 seg. Tiempo en Caja: 18 seg Cliente 31: --> Tiempo de llegada a la Cola: a los 111 seg Cliente 32: --> Tiempo de llegada a la Cola: a los 114 seg Cliente 16, finalizo su atencion en la CAJA 3, a los 116 seg Retirando al Cliente 19 de la cola... Cliente 19, paso a la CAJA 3 a los 116 seg. Tiempo en Caja: 13 seg Cliente 33: --> Tiempo de llegada a la Cola: a los 118 seg Cliente 17, finalizo su atencion en la CAJA 1, a los 122 seg Retirando al Cliente 20 de la cola... Cliente 20, paso a la CAJA 1 a los 122 seg. Tiempo en Caja: 20 seg Cliente 34: --> Tiempo de llegada a la Cola: a los 123 seg Cliente 18, finalizo su atencion en la CAJA 2, a los 127 seg Retirando al Cliente 21 de la cola... Cliente 21, paso a la CAJA 2 a los 127 seg. Tiempo en Caja: 21 seg Cliente 19, finalizo su atencion en la CAJA 3, a los 129 seg Retirando al Cliente 22 de la cola... Cliente 22, paso a la CAJA 3 a los 129 seg. Tiempo en Caja: 20 seg Cliente 20, finalizo su atencion en la CAJA 1, a los 142 seg Retirando al Cliente 23 de la cola... Cliente 23, paso a la CAJA 1 a los 142 seg. Tiempo en Caja: 14 seg Cliente 21, finalizo su atencion en la CAJA 2, a los 148 seg Retirando al Cliente 24 de la cola... Cliente 24, paso a la CAJA 2 a los 148 seg. Tiempo en Caja: 21 seg Cliente 22, finalizo su atencion en la CAJA 3, a los 149 seg Retirando al Cliente 25 de la cola... Cliente 25, paso a la CAJA 3 a los 149 seg. Tiempo en Caja: 13 seg Cliente 23, finalizo su atencion en la CAJA 1, a los 156 seg

Departamento de Computación UNAN - León

Page 574: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 258 de 258

Retirando al Cliente 26 de la cola... Cliente 26, paso a la CAJA 1 a los 156 seg. Tiempo en Caja: 14 seg Cliente 25, finalizo su atencion en la CAJA 3, a los 162 seg Retirando al Cliente 27 de la cola... Cliente 27, paso a la CAJA 3 a los 162 seg. Tiempo en Caja: 19 seg Cliente 24, finalizo su atencion en la CAJA 2, a los 169 seg Retirando al Cliente 28 de la cola... Cliente 28, paso a la CAJA 2 a los 169 seg. Tiempo en Caja: 19 seg Cliente 26, finalizo su atencion en la CAJA 1, a los 170 seg

Cliente 29, finalizo su atencion en la CAJA 1, a los 187 seg

Tiempo total en ejecutar el programa: 222 segundos

Retirando al Cliente 29 de la cola... Cliente 29, paso a la CAJA 1 a los 170 seg. Tiempo en Caja: 17 seg Cliente 27, finalizo su atencion en la CAJA 3, a los 181 seg Retirando al Cliente 30 de la cola... Cliente 30, paso a la CAJA 3 a los 181 seg. Tiempo en Caja: 15 seg

Retirando al Cliente 31 de la cola... Cliente 31, paso a la CAJA 1 a los 187 seg. Tiempo en Caja: 20 seg Cliente 28, finalizo su atencion en la CAJA 2, a los 188 seg Retirando al Cliente 32 de la cola... Cliente 32, paso a la CAJA 2 a los 188 seg. Tiempo en Caja: 23 seg

Cliente 30, finalizo su atencion en la CAJA 3, a los 196 seg

Retirando al Cliente 33 de la cola... Cliente 33, paso a la CAJA 3 a los 196 seg. Tiempo en Caja: 15 seg Cliente 31, finalizo su atencion en la CAJA 1, a los 207 seg

Retirando al Cliente 34 de la cola... Cliente 34, paso a la CAJA 1 a los 207 seg. Tiempo en Caja: 15 seg Cliente 32, finalizo su atencion en la CAJA 2, a los 211 seg

Cliente 33, finalizo su atencion en la CAJA 3, a los 211 seg Cliente 34, finalizo su atencion en la CAJA 1, a los 222 seg

Ultimo tiempo generado: 5

Departamento de Computación UNAN - León

Page 575: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 259 de 259

****** Opciones de Cajas ******

4. Salir. Su opcion: 1

1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente.

CAJA 1

Clte 4, T_Lleg_Cola: 15, T_Lleg_Caja: 24, T_est_caja: 17 -->

Clte 10, T_Lleg_Cola: 29, T_Lleg_Caja: 62, T_est_caja: 13 --> Clte 13, T_Lleg_Cola: 39, T_Lleg_Caja: 75, T_est_caja: 18 -->

Clte 17, T_Lleg_Cola: 57, T_Lleg_Caja: 108, T_est_caja: 14 -->

Clte 23, T_Lleg_Cola: 82, T_Lleg_Caja: 142, T_est_caja: 14 -->

Clte 29, T_Lleg_Cola: 102, T_Lleg_Caja: 170, T_est_caja: 17 -->

Clte 34, T_Lleg_Cola: 123, T_Lleg_Caja: 207, T_est_caja: 15 --> NULL

CAJA 2

2. Busqueda de Cliente.

Clte 1, T_Lleg_Cola: 4, T_Lleg_Caja: 4, T_est_caja: 20 -->

Clte 7, T_Lleg_Cola: 23, T_Lleg_Caja: 41, T_est_caja: 21 -->

Clte 14, T_Lleg_Cola: 44, T_Lleg_Caja: 93, T_est_caja: 15 -->

Clte 20, T_Lleg_Cola: 68, T_Lleg_Caja: 122, T_est_caja: 20 -->

Clte 26, T_Lleg_Cola: 94, T_Lleg_Caja: 156, T_est_caja: 14 -->

Clte 31, T_Lleg_Cola: 111, T_Lleg_Caja: 187, T_est_caja: 20 -->

Clte 2, T_Lleg_Cola: 9, T_Lleg_Caja: 9, T_est_caja: 20 --> Clte 5, T_Lleg_Cola: 19, T_Lleg_Caja: 29, T_est_caja: 20 --> Clte 8, T_Lleg_Cola: 25, T_Lleg_Caja: 49, T_est_caja: 22 --> Clte 11, T_Lleg_Cola: 32, T_Lleg_Caja: 71, T_est_caja: 22 --> Clte 15, T_Lleg_Cola: 49, T_Lleg_Caja: 93, T_est_caja: 16 --> Clte 18, T_Lleg_Cola: 62, T_Lleg_Caja: 109, T_est_caja: 18 --> Clte 21, T_Lleg_Cola: 73, T_Lleg_Caja: 127, T_est_caja: 21 --> Clte 24, T_Lleg_Cola: 85, T_Lleg_Caja: 148, T_est_caja: 21 --> Clte 28, T_Lleg_Cola: 100, T_Lleg_Caja: 169, T_est_caja: 19 --> Clte 32, T_Lleg_Cola: 114, T_Lleg_Caja: 188, T_est_caja: 23 --> NULL CAJA 3 Clte 3, T_Lleg_Cola: 11, T_Lleg_Caja: 11, T_est_caja: 23 --> Clte 6, T_Lleg_Cola: 21, T_Lleg_Caja: 34, T_est_caja: 16 --> Clte 9, T_Lleg_Cola: 27, T_Lleg_Caja: 50, T_est_caja: 22 --> Clte 12, T_Lleg_Cola: 35, T_Lleg_Caja: 72, T_est_caja: 22 --> Clte 16, T_Lleg_Cola: 54, T_Lleg_Caja: 94, T_est_caja: 22 --> Clte 19, T_Lleg_Cola: 65, T_Lleg_Caja: 116, T_est_caja: 13 --> Clte 22, T_Lleg_Cola: 77, T_Lleg_Caja: 129, T_est_caja: 20 --> Clte 25, T_Lleg_Cola: 90, T_Lleg_Caja: 149, T_est_caja: 13 --> Clte 27, T_Lleg_Cola: 98, T_Lleg_Caja: 162, T_est_caja: 19 --> Clte 30, T_Lleg_Cola: 106, T_Lleg_Caja: 181, T_est_caja: 15 --> Clte 33, T_Lleg_Cola: 118, T_Lleg_Caja: 196, T_est_caja: 15 --> NULL ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja.

3. Caja mas eficiente. 4. Salir. Su opcion: 2

Departamento de Computación UNAN - León

Page 576: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 260 de 260

Id del Cliente a buscar ?: 24 Cliente encontrado en la CAJA 2

****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir.

Su opcion: 3 La caja mas eficiente es la CAJA 1 ****** Opciones de Cajas ****** 1. Listado de Clientes x Caja. 2. Busqueda de Cliente. 3. Caja mas eficiente. 4. Salir. Su opcion: 4Press any key to continue

CCOONNCCLLUUSSIIOONNEESS Una vez finalizada la práctica, hemos concluido que los objetivos propuestos, los cuales eran el manejo de las operaciones en una cola y el comportamiento de la cola misma cuando se introducían y retiraban elementos en tiempos variables, se han cumplido satisfactoriamente.

RREECCOOMMEENNDDAACCIIOONNEESS Las recomendaciones que hacemos, es que en un futuro, el programa pueda contar con gráficos para mostrar con una ilustración, de qué manera los clientes salen y entran de la cola

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA. • Curso de Programación C/ C++. Fco Javier Ceballos. Ed-RAMA.

Departamento de Computación UNAN - León

Page 577: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 261 de 261

8.2.7 Práctica 7

RECORRIDO DE ARBOLES BINARIOS OBJETIVO Comprender las características de los árboles de búsqueda binarios a través de la implementación de una pequeña aplicación que utilice éste tipo de estructuras de datos.

Conocer y aplicar las distintas técnicas para el recorrido de árboles de búsqueda binarios. Reafirmar los conocimientos teóricos sobre árboles binarios adquiridos en clase. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 1 sesión de laboratorio (2 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN Las listas enlazadas, las pilas y las colas son estructuras lineales de datos. Un árbol es una estructura no lineal y de dos dimensiones de datos, con propiedades especiales. Los nodos de los árboles contienen dos o más enlaces. Los árboles binarios son aquellos cuyos nodos contienen dos enlaces, ninguno, uno o ambos de los cuales pudieran ser NULL. El nodo raíz es el primer nodo de un árbol. Cada enlace en el nodo raíz se refiere a un hijo. El hijo izquierdo es el primer nodo en el subárbol izquierdo y el hijo derecho es el primer nodo en el subárbol derecho, los hijos de un nodo se conocen como descendientes. Un nodo sin hijo se conoce como nodo hoja.

Departamento de Computación UNAN - León

Page 578: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 262 de 262

Figura 8.2.9 Representación gráfica de un árbol binario

Un árbol de búsqueda binario es un árbol especial que no contiene duplicados y además tiene la característica que los valores en cualquier subárbol izquierdo son menores que el valor en sus nodos padre, y los valores en cualquier subárbol derecho son mayores que el valor en sus nodos padre. DESARROLLO DE LA PRÁCTICA Esta práctica consiste en crear un árbol de búsqueda binario y recorrer el árbol en pre-orden en-orden y en post-orden. El árbol será construido a partir de la siguiente estructura:

};

typedef struct arbol nodo; struct arbol { char datos[32]; nodo * izq; nodo * der;

char datos[32] almacenará datos en cada nodo del árbol de búsqueda binario.nodo * izq es un puntero al descendiente izquierdo del nodo actual. nodo * der es un puntero al descendiente derecho del nodo actual. Las funciones para crear un árbol de búsqueda binario y recorrer el árbol son recursivas. El programa deberá implementar las siguientes funciones: nodo * nuevoNodo(void); Esta función asignará memoria para un nuevo nodo que luego será insertado en el árbol de búsqueda binario. Retorna un puntero a la zona de memoria asignada.

Departamento de Computación UNAN - León

Page 579: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 263 de 263

void insertarNodo(nodo ** root, char * dato); Recibe como argumentos la dirección del nodo raíz del árbol y una cadena de caracteres para almacenarse en el nuevo nodo del árbol de búsqueda binario. En un árbol de búsqueda binario un nodo pude ser únicamente insertado como nodo hoja. Los pasos para insertar un nodo en un árbol de búsqueda binario son como sigue:

1- Si *root es NULL, crea un nuevo nodo, asignar a (*root)->data la cadena de caracteres a almacenarse, asignar a (*root)->izq y (*root)->der el valor NULL.

2- Si el valor de *root no es NULL y la cadena a insertar es menor que (*root)-

>datos, se llama a la función insertarNodo con la dirección de (*root)->izq. De no ser así, se llama a la función insertarNodo con la dirección de (*root)->der. Se continúan los pasos recursivos hasta que se encuentre un apuntador NULL, entonces se ejecutará el paso 1- para insertar el nuevo nodo.

void preOrden(nodo *root); Recibe un puntero al nodo raíz del árbol de búsqueda binario. Los pasos para el recorrido en pre-orden son:

1- Procesar el valor en el nodo.

2- Recorrer el subárbol izquierdo en pre-orden.

3- Recorrer el subárbol derecho en pre-orden.

void enOrden(nodo *root); Recibe un puntero al nodo raíz del árbol de búsqueda binario. Los pasos para un recorrido en-orden son:

4- Recorrer el subárbol izquierdo en-orden.

5- Procesar el valor en el nodo.

6- Recorrer el subárbol derecho en -orden.

void postOrden(nodo *root); Recibe un puntero al nodo raíz del árbol de búsqueda binario. Los pasos para un recorrido en post-orden son:

7- Recorrer el subárbol izquierdo en post-orden.

8- Recorrer el subárbol derecho en post-orden.

9- Procesar el valor en el nodo.

Departamento de Computación UNAN - León

Page 580: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 264 de 264

A continuación se muestra una corrida de ejemplos con los resultados que deberá mostrar el programa un vez finalizado.

Introduzca una frase: Los arboles son estructuras no lineales

Recorrido del arbol en pre-orden Los arboles son estructuras no lineales Recorrido del arbol en en-orden Los arboles estructuras lineales no son Recorrido del arbol en post-orden lineales no estructuras son arboles Los Press any key to continue

Departamento de Computación UNAN - León

Page 581: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 265 de 265

Solución de la práctica 7 APARTADO SOLUCIÓN: /*************************** Arbol Binario de Busqueda ***************************/ #include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct arbol nodo; struct arbol { char datos[32]; nodo * izq; nodo * der; }; nodo * nuevoNodo(void); void insertarNodo(nodo **, char *); void preOrden(nodo *); void enOrden(nodo *); void postOrden(nodo *); int main (void) { nodo * raiz = NULL; static char string[1204]; char * token = NULL; printf("Introduzca una frase: "); gets(string); token = strtok(string," "); while(token != NULL) { insertarNodo(&raiz,token); token = strtok(NULL," "); } printf("\n\nRecorrido del arbol en pre-orden\n"); preOrden(raiz); printf("\n\nRecorrido del arbol en en-orden\n"); enOrden(raiz); printf("\n\nRecorrido del arbol en post-orden\n"); postOrden(raiz); }

Departamento de Computación UNAN - León

Page 582: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 266 de 266

nodo * nuevoNodo(void) { nodo * q = NULL; q = (nodo *) malloc(sizeof(nodo)); if (!q) { printf("\nERROR: Memoria Insuficiente!!!\n"); exit(-1); } else { q->izq = NULL; q->der = NULL; } return(q); } void insertarNodo(nodo ** root, char * dato) { nodo * n = NULL; if (*root == NULL) { n = nuevoNodo(); strcpy(n->datos,dato); *root = n; } else { if (strcmp((*root)->datos,dato) < 0) { insertarNodo(&((*root)->der),dato); } else { if (strcmp((*root)->datos,dato) > 0) { insertarNodo(&((*root)->izq),dato); } else { printf("\nValor Duplicado\n"); } } } } void preOrden(nodo * arbol) { if (arbol != NULL) { printf("\n%s",arbol->datos);

Departamento de Computación UNAN - León

Page 583: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 267 de 267

preOrden(arbol->izq); preOrden(arbol->der); } } void enOrden(nodo * arbol) { if (arbol != NULL) { enOrden(arbol->izq); printf("\n%s",arbol->datos); enOrden(arbol->der); } } void postOrden(nodo * arbol) { if (arbol != NULL) { postOrden(arbol->izq); postOrden(arbol->der); printf("\n%s",arbol->datos); } }

HHEERRRRAAMMIIEENNTTAASS UUTTIILLIIZZAADDAASS Las herramientas utilizadas fueron:

• Editor Microsoft Visual C++ 6.0 para la edición del programa.

• Compilador Microsoft Visual C++ 6.0 para la compilación del archivo fuente y la construcción de archivo ejecutable.

• Microsoft Word XP para la edición del documento de entrega de la práctica.

EEXXPPLLIICCAACCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN Para construir el árbol binario de búsqueda se solicita al usuario una frase que luego se descompone en palabras, las cuales serán los datos de cada nodo del árbol. Una vez que se obtiene un palabra esta se pasa a la función insertarNodo que inserta un nodo en el árbol.

Departamento de Computación UNAN - León

Page 584: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 268 de 268

printf("Introduzca una frase: "); gets(string); token = strtok(string," "); while(token != NULL) { insertarNodo(&raiz,token); token = strtok(NULL," "); } La función insertarNodo recibe como argumentos el puntero a la raíz del árbol y una cadena de caracteres. Si el puntero a la raíz del árbol es NULL entonces se le asigna memoria y se copia en el la cadena de caracteres. Si el puntero a la raíz del árbol no está vació entonces se compra el dato del nodo raíz con la cadena de caracteres a insertar y si esta es menor que el dato se hace una llamada recursiva a insertarNodo y esta vez se pasa como nodo raíz uan referencia all puntero izquierdo del nodo raíz. Si la cadena de caracteres a insertar es mayor que el dato del nodo raíz entonces se realiza una llamada recursiva a la función insertarNodo y se le pasa como nodo raíz una referencia al puntero derecho del nodo raíz. Si las dos cadenas son iguales la cadena a insertar es descartada. void insertarNodo(nodo ** root, char * dato) { nodo * n = NULL; if (*root == NULL) { n = nuevoNodo(); strcpy(n->datos,dato); *root = n; } else { if (strcmp((*root)->datos,dato) < 0) { insertarNodo(&((*root)->der),dato); } else { if (strcmp((*root)->datos,dato) > 0) { insertarNodo(&((*root)->izq),dato); } else { printf("\nValor Duplicado\n"); } } } }

Departamento de Computación UNAN - León

Page 585: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 269 de 269

Para el recorrido en pre-orden primero se procesan los datos del nodo y se llama a la función pre-orden en el sub árbol izquierdo del nodo raíz y luego en el sub árbol derecho. void preOrden(nodo * arbol) { if (arbol != NULL) { printf("\n%s",arbol->datos); preOrden(arbol->izq); preOrden(arbol->der); } } El recorrido en-orden del árbol se realiza recorriendo el subárbol izquierdo del nodo raíz en-orden, procesando los datos y luego recorriendo el subárbol derecho del nodo raíz en-orden. void enOrden(nodo * arbol) { if (arbol != NULL) { enOrden(arbol->izq); printf("\n%s",arbol->datos); enOrden(arbol->der); } } El recorrido en post-orden se puede decir que es la forma opuesta al recorrido en pre-orden. Primero se recorre el sub árbol izquierdo en post-orden, luego se recorre el sub árbol derecho en post-orden y por último se procesan los datos. void postOrden(nodo * arbol) { if (arbol != NULL) { postOrden(arbol->izq); postOrden(arbol->der); printf("\n%s",arbol->datos); } }

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. Las entradas del usuario están en negritas cursivas y subrayadas.

Departamento de Computación UNAN - León

Page 586: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 270 de 270

PRIMERA EJECUCIÓN: Introduzca una frase: Los arboles son estructuras no lineales Recorrido del arbol en pre-orden Los arboles son estructuras no

lineales Recorrido del arbol en en-orden Los arboles estructuras lineales no son Recorrido del arbol en post-orden lineales no estructuras son arboles Los Press any key to continue SEGUNDA EJECUCIÓN:

Introduzca una frase: Las pilas y listas son estructuras lineales Recorrido del arbol en pre-orden Las pilas listas estructuras lineales y son Recorrido del arbol en en-orden Las estructuras

Departamento de Computación UNAN - León

Page 587: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 271 de 271

lineales listas pilas son y Recorrido del arbol en post-orden lineales estructuras listas son y

RREECCOOMMEENNDDAACCIIOONNEESS

También sería interesante comparar los tiempos de búsqueda en una lista lineal y un árbol binario.

BBIIBBLLIIOOGGRRAAFFÍÍAA

pilas Las Press any key to continue

CCOONNCCLLUUSSIIOONNEESS Al finalizar la práctica se han cumplido con los objetivos propuestos, se ha comprendido el mecanismo de creación de árboles de búsqueda binarios así como el recorrido de árboles en pre-orden, en-orden y en post-orden.

El uso de la recursión para la construcción y recorrido de árboles hace que dichas tareas sean muy simples.

En un futuro esta práctica se podría ampliar para construir un árbol con registros leídos de un fichero y realizar operaciones de búsquedas.

Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programar en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

Departamento de Computación UNAN - León

Page 588: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 272 de 272

8.2.8 Práctica 8

RECURSIVIDAD ORDENACIÓN Y BÚSQUEDA EN ARREGLOS DE ESTRUCTURAS

OBJETIVO Comprender el proceso de recursividad y su importancia para atacar problemas complejos.

Sugerencia: Compilador Microsoft Visual C++ 6.0

Ordenar por alguno de los métodos visto en clases, un arreglo de estructuras. Programar los tipos de búsqueda vistas en clase en arreglos de estructuras, y medir los tiempos de ejecución de cada una. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 1 sesión de laboratorio (2 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C.

INTRODUCCIÓN Se dice que un proceso es recursivo si forma parte de sí mismo; o sea que se define en función de sí mismo. La recursion aparece en la vida diaria, en problemas matemáticos, en estructuras de datos y en muchos otros problemas. La recursion es un proceso extremadamente potente, por lo que la analizaremos detenidamente para saber cuándo y cómo aplicarla. Esto quiere decir que aunque un problema por definición sea recursivo, no siempre este será el método de solución más adecuado. Uno de los procedimientos más comunes y útiles en el procesamiento de datos, es la clasificación u ordenación de los mismos. Se considera ordenar al proceso de reorganizar un conjunto dato de objetos en una secuencia determinada. El objetivo de este proceso generalmente es facilitar la búsqueda de uno o más elementos pertenecientes a un conjunto. Como ejemplo, considérense las listas de alumnos matriculados en una cierta asignatura, las listas de empleados en una empresa, los índices alfabéticos de los libros, etc. Esto quiere decir que muchos problemas están relacionados de alguna forma con el proceso de ordenación. Es por lo que la ordenación es un problema importante a considerar.

Departamento de Computación UNAN - León

Page 589: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 273 de 273

DESARROLLO DE LA PRÁCTICA 1ª apartado (Recursividad – Número de Tarot): Si quiere averiguar su número de Tarot, sume los números de su fecha de nacimiento y a continuación redúzcalos a un único dígito; por ejemplo, si su fecha de nacimiento fuera 17 de Octubre de 1970, los cálculos a realizar serían: 17 + 10 + 1970 = 1997 1 + 9 + 9 + 7 = 26 2 + 6 = 8. Realizar un programa que pida una fecha, de la forma: día, mes, año; donde día, mes y año son enteros, y dé como resultado el número de Tarot. El cálculo del número de Tarot, deberá ser implementado de forma recursiva. El programa verificará si la fecha es correcta, esto es, los valores están dentro de los rangos permitidos.

4. Salir.

Nota: El estudiante deberá realizar 2 propuestas de solución recursiva para este apartado. 2º apartado (Ordenación y búsqueda en arreglos de estructuras): La práctica consiste en introducir datos de empleados mediante un menú como el que sigue: ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula).

Su opcion (1-4) ?: Los datos de un empleado serán manejados mediante la siguiente estructura: struct empleado { char cedula[12]; // documento de identidad char nombre[50]; float salario; // salario devengado }; La cantidad máxima de empleados, puede ser definida mediante la constante: #define N_MAX_EMPL 100 Para cada una de las opciones del menú, se definirán en el orden, las siguienes funciones:

Departamento de Computación UNAN - León

Page 590: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 274 de 274

void IngresarEmpl ( struct empleado e[], int i ); Esta función solicita datos para un empleado, y lo almacena en la posición i de arreglo dado por el argumento formal e. void OrdenarBurbuja ( struct empleado e[], int NE ); Esta función ordena el arreglo de estructuras e, mediante el campo cédulga. El método usado para ordenar es el de la burbuja. Esta función será llamada luego de introducir un empleado. int BusquedaSec ( struct empleado e[], char *cedula, int sup ); Esta función busca, usando el método de búsqueda secuencial, a un empleado mediante el campo cédula. int BusquedaBin ( struct empleado e[], char *cedula, int inf, int sup ); Esta función busca, usando el método de búsqueda binaria, a un empleado mediante el campo cédula. void Visualizar( struct empleado e[] , int No_empl ); Esta función visualiza los empleados introducidos en el arreglo de estructuras. Sólo deben visualizarse los empleados introducidos. Un requisito que debe cumplir el programa es que, cuando se desee buscar a un empleado, dicha búsqueda se hará mediante las 2 formas de búsqueda vistas en clase: la secuencial y la binaria. Para cada tipo de búsqueda se deberá medir el tiempo de ejecución que duró, y mostrar un mensaje de qué método de búsqueda ha durado menos.

Departamento de Computación UNAN - León

Page 591: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 275 de 275

Solución de la práctica 8 APARTADO SOLUCIÓN: 1er apartado Primera versión del cálculo del número de Tarot /* Número de Tarot */ /*tarot.c*/ #include <stdio.h> #include <stdlib.h> #include <conio.h> typedef enum boolean booleano; enum boolean { Falso, Verdad }; /* Prototipos de funciones */ int Tarot (unsigned int dd, unsigned int mm, unsigned int aa); int CalcularTarot (unsigned int suma); booleano EsFechaCorrecta (unsigned int dd, unsigned int mm, unsigned int aa); void main() /* Funcion principal */ { unsigned int dia, mes, anyo, tarot; booleano fv; /* Fecha valida ? */ printf ("\n\t ******* BIENVENIDO A SU NUMERO DE TAROT ******"); printf ("\n\t Introduzca su fecha de nacimiento (dd mm aa): \n"); do { fv = Verdad; /* fv = Verdad, indica fecha válida */ /* fv = Falso, indica fecha inválida */ printf ("\n\t Dia: "); scanf ("%u", &dia); printf ("\n\t Mes: "); scanf ("%u", &mes); printf ("\n\t Anyo: "); scanf ("%u", &anyo); fv = EsFechaCorrecta (dia, mes, anyo); /* Verificar la fecha */ if (fv == Falso) { printf ("\n\t Presione una tecla para continuar..");

Departamento de Computación UNAN - León

Page 592: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 276 de 276

getch(); system("cls"); } } while (fv == Falso); tarot = Tarot (dia, mes, anyo); printf ("\n\t\a Su numero de Tarot es: %u", tarot); printf("\n\n"); } // Fin del main() /////////////////////////////////////////////////////////////////////////////// ///////////////////// Definción de funciones //////////////////// /////////////////////////////////////////////////////////////////////////////// /* Calcula el número de Tarot */ int Tarot (unsigned int dd, unsigned int mm, unsigned int aa) { int suma = 0, tarot = 0; suma = dd + mm + aa; /* Sumar los valores iniciales de la fecha */ tarot = CalcularTarot (suma); /* Calculamos el número Tarot */ return (tarot); } // Fin de Tarot() /* Realizar el cálculo del número de Tarot, de forma recursiva */ int CalcularTarot (unsigned int suma) { /* La estrategia a seguir es, convertir el valor que viene en el argumento formal, suma, a una cadena de caracteres. A continuación, recorremos la cadena de caracteres, hasta encontrar el carácter de terminación de cadena, y obtenemos cada caracter y calculamos su valor entero, vamos acumulando la suma de dichos valores en una variable temporal y, cuando finalicemos, volvemos a llamar a la función CalcularTarot(), pasándole como argumento, la suma obtenida. El caso base de esta función recursiva, se da si el valor del argumento formal, suma, es menor que 10, es decir, un número de un sólo dígito. */ char cadena[10], *pcad = NULL; int sum = 0, i = 0; if (suma < 10) return (suma); /* Si es el caso base, retornar la suma */

Departamento de Computación UNAN - León

Page 593: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 277 de 277

else { pcad = itoa (suma, cadena, 10); /* Convertir a una cadena de caracteres, el valor de suma. */ while (pcad[i] != '\0') { sum = sum + (pcad[i] - 48); /* Acumular el valor entero de cada caracter. */ i++; } return ( CalcularTarot(sum) ); /* LLamada recursiva */ } } // Fin de CalcularTarot () /* Verifica que la fecha dada por dd, mm y aa, sea correcta */ booleano EsFechaCorrecta (unsigned int dd, unsigned int mm, unsigned int aa) { unsigned int dias_por_mes; /* Dias por meses */ int condicion1, condicion2; /* Calcular los días del mes */ switch (mm) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: dias_por_mes = 31; break; case 4: case 6: case 9: case 11: dias_por_mes = 30; break; case 2: /* Comprobar si el año es bisiesto */ if ( (aa % 4 == 0) && (aa % 100 != 0) || (aa % 400 == 0) ) dias_por_mes = 29; else dias_por_mes = 28; break; default: putchar ('\7'); /* carácter bell */ return (Falso); /* Fecha no válida */ } condicion1 = dd >= 1 && dd <= dias_por_mes; condicion2 = aa >= 1900 && aa <= 2100; if (condicion1 && condicion2) { printf ("\n\t Fecha valida..."); return (Verdad);

Departamento de Computación UNAN - León

Page 594: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 278 de 278

} else { printf ("\n\t FECHA INCORRECTA..."); putchar ('\7'); /* caracter bell */ return (Falso); } } // Fin de EsFechaCorrecta() Segunda versión del cálculo del número de Tarot /* Número de Tarot */ /* tarot.c*/ #include <stdio.h> #include <stdlib.h> #include <conio.h> #include <string.h> #include <math.h> typedef enum boolean booleano; enum boolean { Falso, Verdad }; /* Prototipos de funciones */ int Tarot (unsigned int dd, unsigned int mm, unsigned int aa); booleano EsFechaCorrecta (unsigned int dd, unsigned int mm, unsigned int aa); void main() /* Funcion principal */ { unsigned int dia, mes, anyo, tarot; booleano fv; /* Fecha valida ? */ printf ("\n\t ******* BIENVENIDO A SU NUMERO DE TAROT ******"); printf ("\n\t Introduzca su fecha de nacimiento (dd mm aa): \n"); do { fv = Verdad; /* fv = Verdad, indica fecha válida */ /* fv = Falso, indica fecha inválida */ printf ("\n\t Dia: "); scanf ("%u", &dia); printf ("\n\t Mes: "); scanf ("%u", &mes);

Departamento de Computación UNAN - León

Page 595: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 279 de 279

printf ("\n\t Anyo: "); scanf ("%u", &anyo); fv = EsFechaCorrecta (dia, mes, anyo); /* Verificar la fecha */ if (fv == Falso) { printf ("\n\t Presione una tecla para continuar.."); getch(); system("cls"); } } while (fv == Falso); tarot = Tarot (dia, mes, anyo); printf ("\n\t\a Su numero de Tarot es: %u", tarot); printf("\n\n"); } // Fin del main() /////////////////////////////////////////////////////////////////////////////// ///////////////////// Definción de funciones //////////////////// /////////////////////////////////////////////////////////////////////////////// /* Calcula el número de Tarot */ int Tarot (unsigned int dd, unsigned int mm, unsigned int aa) { int tar; tar = dd + mm + aa; if (tar >= 0 && tar < 10) return (tar); dd = mm = aa = 0; if (tar > 1000) { dd = tar / 1000; tar = tar % 1000; } if (tar > 100) { mm = tar / 100; tar = tar % 100; } if (tar > 10) { aa = tar / 10; tar = tar % 10; aa = aa + tar;

Departamento de Computación UNAN - León

Page 596: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 280 de 280

} tar = Tarot (dd, mm, aa); return (tar); } // Fin de Tarot() /* Verifica que la fecha dada por dd, mm y aa, sea correcta */ booleano EsFechaCorrecta (unsigned int dd, unsigned int mm, unsigned int aa) { unsigned int dias_por_mes; /* Dias por meses */ int condicion1, condicion2; /* Calcular los días del mes */ switch (mm) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: dias_por_mes = 31; break; case 4: case 6: case 9: case 11: dias_por_mes = 30; break; case 2: /* Comprobar si el año es bisiesto */ if ( (aa % 4 == 0) && (aa % 100 != 0) || (aa % 400 == 0) ) dias_por_mes = 29; else dias_por_mes = 28; break; default: putchar ('\7'); /* carácter bell */ return (Falso); /* Fecha no válida */ } condicion1 = dd >= 1 && dd <= dias_por_mes; condicion2 = aa >= 1900 && aa <= 2100; if (condicion1 && condicion2) { printf ("\n\t Fecha valida..."); return (Verdad); } else { printf ("\n\t FECHA INCORRECTA..."); putchar ('\7'); /* caracter bell */ return (Falso); }

Departamento de Computación UNAN - León

Page 597: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 281 de 281

} // Fin de EsFechaCorrecta()

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS

En esta sección se presentará los resultados que ha originado la ejecución del programa. Las entradas del usuario están dada en negritas cursivas y subrayadas.

******* BIENVENIDO A SU NUMERO DE TAROT ****** Introduzca su fecha de nacimiento (dd mm aa):

Dia: 17 Mes: 10 Anyo: 1970 Fecha valida... Su numero de Tarot es: 8 Press any key to continue ******* BIENVENIDO A SU NUMERO DE TAROT ****** Introduzca su fecha de nacimiento (dd mm aa): Dia: 17 Mes: 07 Anyo: 1979 Fecha valida... Su numero de Tarot es: 2 Press any key to continue

Departamento de Computación UNAN - León

Page 598: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 282 de 282

2º apartado SOLUCIÓN /* empleado.c */ #include <stdio.h> #include <time.h> #include <stdlib.h> #include <string.h> #define N_MAX_EMPL 100 struct empleado { char cedula[12]; // documento de identidad char nombre[50]; float salario; // salario devengado }; // Prototipos de funciones void IngresarEmpl ( struct empleado e[], int i ); void OrdenarBurbuja ( struct empleado e[], int NE ); void ImprimirCabecera ( ); void ImprimirFila ( struct empleado e[], int inf, int mitad, int sup ); int BusquedaBin ( struct empleado e[], char *cedula, int inf, int sup ); int BusquedaSec ( struct empleado e[], char *cedula, int sup ); void Visualizar( struct empleado e[] , int No_empl ); int Menu(); void main() /* Función principal */ { int i = 0, op; static struct empleado Empl[N_MAX_EMPL]; char cedula[12]; int result, result1; int No_empl = 0; int t_in, t_fin; // manejo de los tiempos int t_bb; // tiempo de busqueda binaria int t_bs; // tiempo de busqueda secuencial /* Leer los valores para el arreglo a */ system ("cls"); while(1) { op = Menu(); // Menu de operaciones switch(op) {

Departamento de Computación UNAN - León

Page 599: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 283 de 283

case 1: // Ingresar un nuevo empleado if (No_empl == N_MAX_EMPL - 1) // Empleados agotados { printf("\n\t Cantidad de empleados agotados....."); continue; } IngresarEmpl (Empl, No_empl); No_empl++; // Ordenar el arreglo si hay más de un empleado if ( No_empl > 1) OrdenarBurbuja ( Empl, No_empl ); /* Clasificamos el arreglo */ break; case 2: // Visualizar lista de empleados Visualizar( Empl, No_empl ); break; case 3: // Buscar a un empleado por su cédula fflush(stdin); printf("\n\t Empleado a buscar (cedula): "); gets(cedula); ImprimirCabecera (); // Búsqueda binaria t_in = clock() / CLK_TCK; result = BusquedaBin ( Empl, cedula, 0, No_empl ); t_fin = clock() / CLK_TCK; t_bb = t_fin - t_in; // Búsqueda Secuencial t_in = clock() / CLK_TCK; result1 = BusquedaSec ( Empl, cedula, No_empl ); t_fin = clock() / CLK_TCK; t_bs = t_fin - t_in; if ( result != -1 && result1 != -1 ) { printf ("\n\t %s encontrado en la posicion %d del arreglo \n", cedula, result ); printf ("\n\t Tiempo total con Busqueda Binaria : %d segundos ", t_bb ); printf ("\n\t Tiempo total con Busqueda Secuencial : %d segundos ", t_bs ); // Imprimir el menor tiempo if ( t_bb < t_bs ) printf("\n\t Tiempo de Busq Bin menor que tiempo de Busq Sec"); else printf("\n\t Tiempo de Busqueda Secuencial menor que tiempo de Busqueda Binaria");

Departamento de Computación UNAN - León

Page 600: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 284 de 284

} else printf ("\n %s no encontrado \n", cedula ); break; case 4: // Salir exit(0); } // switch } // Fin de while } // Fin del main ///////////////////////////////////////////////////////////////////////////////// ///////////////// Definición de funciones ///////////////////////// ///////////////////////////////////////////////////////////////////////////////// ///////////////// OrdenarBurbuja ///////////////// void OrdenarBurbuja ( struct empleado e[], int NE ) { // Ordena a los empleados por la cedula int i, j; struct empleado temp; for ( i = 0; i < NE - 1; i++ ) for ( j = 0; j < NE - i - 1; j++ ) if ( strcmp ( e[j].cedula, e[j + 1].cedula ) > 0 ) { temp = e[j]; e[j] = e[j + 1]; e[j + 1] = temp; } } // Fin de OrdenarBurbuja() /********************* Busqueda binaria **********************/ int BusquedaBin ( struct empleado e[], char *valor, int inf, int sup ) { int mitad; while ( inf <= sup ) { mitad = ( inf + sup ) / 2; ImprimirFila ( e, inf, mitad, sup ); // if ( valor == b[mitad] ) if ( strcmp ( valor, e[mitad].cedula ) == 0 )

Departamento de Computación UNAN - León

Page 601: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 285 de 285

return ( mitad ); // else if ( valor < b[mitad] ) else if ( strcmp ( valor, e[mitad].cedula) < 0 ) sup = mitad - 1; else inf = mitad + 1; } /* Fin del while */ return ( - 1 ); /* valor no encontrado */ } // Fin de BusqedaBin () ///////////////////// ImprimirCabecera //////////////////////// void ImprimirCabecera () { int i; printf ("\n Subindices: \n"); for ( i = 0; i <= N_MAX_EMPL - 1; i++ ) printf ("%3d ", i); printf ("\n"); for ( i = 1; i <= 4 * N_MAX_EMPL; i++ ) printf ("-"); printf ("\n"); } // Fin de ImprimirCabecera () ///////////////////////// ImprimirFila ////////////////////////////// void ImprimirFila ( struct empleado e[], int inf, int mitad, int sup ) { int i; for ( i = 0; i <= N_MAX_EMPL - 1; i++ ) if ( i < inf || i > sup ) printf (" "); else if ( i == mitad ) printf ("%3s*", e[i].cedula ); /* marcar el valor mitad */ else printf ("%3s ", e[i].cedula ); printf ("\n"); } // Fin de ImprimirFila()

Departamento de Computación UNAN - León

Page 602: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 286 de 286

////////////////////// Menu //////////////////////////// int Menu(void) { int op; do { printf("\n\n\t ******** Empleados ***************"); printf("\n\t 1. Ingresar un nuevo empleado. "); printf("\n\t 2. Visualizar lista de empleados. "); printf("\n\t 3. Buscar a un empleado (cedula). "); printf("\n\t 4. Salir. "); printf("\n\n\t Su opcion (1-4) ?: "); scanf("%d", &op); } while ( op < 1 || op > 4 ); return (op); } // Fin de Menu() /////////////////////// IngresarEmpl /////////////////////////// void IngresarEmpl ( struct empleado e[], int i ) { fflush(stdin); printf("\n\t Datos del empleado %d ....", i + 1 ); printf("\n\t Cedula: "); gets(e[i].cedula); printf("\n\t Nombre: "); gets(e[i].nombre); printf("\n\t Salario: "); scanf("%f", &e[i].salario); } // Fin de IngresarEmpl() //////////////////// Visualizar Empleados //////////////////////// void Visualizar( struct empleado e[], int No_empl ) { int i = 0; for ( i = 0; i < No_empl; i++ ) { printf("\n\t DATOS DEL EMPLEADO %d: \n", i + 1 ); printf("\n\t Cedula: %3s", e[i].cedula ); printf("\n\t Nombre: %3s", e[i].nombre ); printf("\n\t Salario: %3f\n\n", e[i].salario ); }

Departamento de Computación UNAN - León

Page 603: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 287 de 287

} // Fin de Visualizar ////////////// Busqeda Secuencial de la cédula de un Empleado ///////// int BusquedaSec ( struct empleado e[], char *cedula, int No_empl ) { int i; for ( i = 0; i < No_empl; i++ ) { if ( strcmp( e[i].cedula, cedula ) == 0 ) return i; } // Si cedula no se encuentra, retornar -1 return (-1); } // Fin de BusqedaSec()

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS En esta sección se presentará los resultados que ha originado la ejecución del programa. Las entradas del usuario están dada en negritas cursivas y subrayadas.

1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados.

******** Empleados ***************

3. Buscar a un empleado (cedula). 4. Salir.

Su opcion (1-4) ?: 1 Datos del empleado 1 .... Cedula: ronie026 Nombre: Ronaldo Salario: 20000 ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula).

4. Salir.

Su opcion (1-4) ?: 1

Departamento de Computación UNAN - León

Page 604: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 288 de 288

Datos del empleado 2 .... Cedula: fig030 Nombre: Figo Salario: 12000 ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula). 4. Salir. Su opcion (1-4) ?: 1 Datos del empleado 3 .... Cedula: zid032 Nombre: Zidane Salario: 30000 ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula). 4. Salir. Su opcion (1-4) ?: 1 Datos del empleado 4 .... Cedula: rau028 Nombre: Raul Salario: 18000 ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados.

3. Buscar a un empleado (cedula). 4. Salir.

Su opcion (1-4) ?: 2 DATOS DEL EMPLEADO 1:

Nombre: Figo Cedula: fig030

Salario: 12000.000000

Departamento de Computación UNAN - León

Page 605: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 289 de 289

DATOS DEL EMPLEADO 2: Cedula: rau028

Nombre: Raul Salario: 18000.000000 DATOS DEL EMPLEADO 3: Cedula: ronie026 Nombre: Ronaldo Salario: 20000.000000 DATOS DEL EMPLEADO 4: Cedula: zid032 Nombre: Zidane Salario: 30000.000000 ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula). 4. Salir.

Su opcion (1-4) ?: 3 Empleado a buscar (cedula): ronie026 Subindices: 0 1 2 3 4 -------------------- fig030 rau028 ronie026*zid032 ronie026 encontrado en la posicion 2 del arreglo Tiempo total con Busqueda Binaria : 0 segundos Tiempo total con Busqueda Secuencial : 0 segundos Tiempo de Busqueda Secuencial menor que tiempo de Busqueda Binaria ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Visualizar lista de empleados. 3. Buscar a un empleado (cedula). 4. Salir. Su opcion (1-4) ?: 4Press any key to continue

Departamento de Computación UNAN - León

Page 606: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 290 de 290

CCOONNCCLLUUSSIIOONNEESS

Al finalizar la práctica se han cumplido con los objetivos propuestos, se ha comprendido el proceso recursivo y se ha implementado los dos tipos de búsqueda en arreglos de estructuras.

RREECCOOMMEENNDDAACCIIOONNEESS No hay recomendaciones.

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programar en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

Departamento de Computación UNAN - León

Page 607: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 291 de 291

8.2.9 Práctica 9

ORDENACIÓN Y BÚSQUEDA EN LISTAS LINEALES OBJETIVO El objetivo de esta práctica es que el estudiante implemente algún método de ordenación en listas lineales. Comprobar que los algoritmos de ordenación, no sólo son aplicables a arrays. TIEMPO DE REALIZACIÓN DE LA PRÁCTICA 2 sesiones de laboratorio (4 horas) SOFTWARE A UTILIZAR Cualquier compilador de C, que cumpla con el estándar ANSI C. Sugerencia: Compilador Microsoft Visual C++ 6.0 INTRODUCCIÓN Un array dinámico, una vez creado no permite alterar su tamaño. Si lo que deseamos es una lista de elementos u objetos de cualquier tipo, originalmente vacía, que durante la ejecución del programa vaya creciendo y decreciendo elemento a elemento, según las necesidades previstas en el programa, entonces tenemos que construir una lista lineal en la que cada elemento apunte o direccione al siguiente. Por este motivo, una lista lineal se le denomina lista enlazada. La Figura 8.2.10 ilustra la representación de una lista lineal:

p

Figura 8.2.10 Ejemplo de una lista lineal.

Departamento de Computación UNAN - León

Page 608: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 292 de 292

Para construir una lista lineal primero tendremos que definir la clase de objetos que van a formar parte de la misma. De una forma genérica el tipo definido será de la forma:

typedef struct id tipo__objeto; struct id {

/* declaración de los miembros de la estructura */ tipo__objeto *siguiente;

}; Ejemplo: typedef struct datos elemento; struct datos { int dato;

elemento *siguiente; }; elemento *p; p = NuevoElemento( ); p->siguiente = NULL; Este ejemplo declara un tipo denominado elemento. Observamos que uno de sus miembros es un puntero a un objeto del mismo tipo. Esto permitirá a un elemento creado referenciar su sucesor. La sentencia elemento *p declara un puntero a un objeto de tipo elemento. La sentencia p = NuevoElemento( ); crea (asigna memoria para) un objeto de tipo elemento , genera un puntero (dirección de memoria) que referencia este nuevo objeto y asigna esta dirección a la variable p. La sentencia p->siguiente = NULL asigna al miembro siguiente del objeto apuntado por p el valor NULL, indicando así que después de este elemento no hay otro. El valor NULL, dirección nula, nos permite crear estructuras finitas. Una declaración como p = NULL indica una lista vacía (suponiendo que p apunta al principio de la lista). Un objeto puede referenciarse por más de un puntero, y también un objeto de un determinado tipo puede copiarse en otro objeto del mismo tipo. DESARROLLO DE LA PRÁCTICA La práctica consiste en introducir datos de empleados mediante un menú como el que sigue:

Departamento de Computación UNAN - León

Page 609: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 293 de 293

******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir. Su opcion (1-5) ?: Los datos de un empleado serán mantenidos mediante las siguientes estructura: typedef struct empleado { char cedula[12]; // documento de identidad char nombre[50]; // nombre de la persona float salario; // salario devengado }TEmpleado; typedef struct datos { TEmpleado empl; struct datos *sig; }TElemento; El programa será mantenido mediante las siguientes funciones: void Anadir (TElemento **pc, TElemento **fc, TEmpleado e); Esta función añade a un empleado al final de la lista. La elección de ubicarlo al final de la lista, no obedece a ninguna razón particular. Se podría igual, haberlo ubicado al inicio de la lista. La idea es almacenar a los empleados en el orden en que van llegando, para después, ordenarlos mediante la función OrdenarBurbuja. void Borrar (TElemento **pc, char *cedula); Esta función elimina de la lista al empleado con cédula “cedula”. Luego de eliminar al empleado, se deberá actualizar la lista, volviendo a llamar a la función OrdenarBurbuja. TElemento *Buscar (TElemento *pc, char *cedula); Esta función buaca al empleado con cédula “cedula”. Si el empleado se encuentra, la función devuelve un puntero al objeto que representa al empleado encontrado. Si no se encuentra, la función regresa NULL.

Departamento de Computación UNAN - León

Page 610: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 294 de 294

void Visualizar (TElemento *pc); Esta función visualiza los elementos de la lista. Recibe como parámetro el inicio de la lista. Si la lista está vacía, la función deberá avisarnos y retornar. void EliminarLagunas (TElemento **pc); El objetivo de esta función es liberar la memoria asignada y no liberada. La existencia de lagunas se puede dar cuando, el usuario decide salir de la aplicación y no ha eliminado a todos los usuarios que previamente ha introducido. void LeerDatosEmpleado (TEmpleado *pe); Esta función lee datos para un empleado. El argumento es un puntero a un objeto de tipo TEmpleado. void OrdenarBurbuja (TElemento **pe);

El propópsito de esta función es ordenar por el método de la burbuja, la lista de empleados. Recibe como único argumento el inicio de la lista.

TElemento *NuevoElemento (void); El objetivo de esta función es asignar memoria memoria para un objeto de tipo TElemento. La función retorna un puntero al objeto asignado. int Menu(); Esta función presenta el siguiente menú: ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir. Su opcion (1-5) ?: Regresa la opción seleccionada.

Departamento de Computación UNAN - León

Page 611: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 295 de 295

Solución de la práctica 9 APARTADO SOLUCIÓN: /** Gestión de empleados, usando listas dinámicas **/ #include <stdio.h> #include <time.h> #include <stdlib.h> #include <string.h> #include <conio.h> #include <crtdbg.h> typedef struct empleado { char cedula[12]; // documento de identidad char nombre[50]; // nombre de la persona float salario; // salario devengado }TEmpleado; typedef struct datos { TEmpleado empl; struct datos *sig; }TElemento; typedef enum boolean booleano; enum boolean { True = 1, False = 0 }; // Prototipos de funciones // Los elementos se introducirán siempre al fina de la lista void Anadir (TElemento **pc, TElemento **fc, TEmpleado e); void Borrar (TElemento **pc, char *cedula); TElemento *Buscar (TElemento *pc, char *cedula); void Visualizar (TElemento *pc); void EliminarLagunas (TElemento **pc); void LeerDatosEmpleado (TEmpleado *pe); void OrdenarBurbuja (TElemento **pe); TElemento *NuevoElemento (void); void Error (void); int Menu(); booleano ListaVacia (TElemento *pe); void main() { TElemento *principio, *final; // principio y final de la lista TElemento *q;

Departamento de Computación UNAN - León

Page 612: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 296 de 296

TEmpleado E; int opcion; char cedula[12]; principio = final = NULL; /* Lista vacia */ while ( (opcion = Menu()) != 5) { switch (opcion) { case 1: // Ingresar un nuevo empleado LeerDatosEmpleado (&E); Anadir (&principio, &final, E); // Si hay más de un empleado en la lista, ordenarla if (principio->sig != NULL) OrdenarBurbuja(&principio); break; case 2: // Borrar a un empleado fflush (stdin); printf ("\n\t Cedula del Empleado a borrar: "); gets (cedula); Borrar (&principio, cedula); /* Ordenar después de borrar */ if (principio->sig != NULL) OrdenarBurbuja(&principio); break; case 3: // Buscar a un empleado fflush (stdin); printf ("\n\t Cedula del Empleado a buscar: "); gets (cedula); q = Buscar (principio, cedula); if (q != NULL) /* El empleado se encuentra */ printf ("\n\t Empleado encontrado..."); else printf ("\n\t Empleado no encontrado..."); break; case 4: // Visualizar la lista de empleados Visualizar (principio); break; } // Fin de switch printf ("\n\t Presione una tecla para continuar"); getch(); } // Fin de while

Departamento de Computación UNAN - León

Page 613: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 297 de 297

/* Eliminar lagunas de memoria */ EliminarLagunas (&principio); /* Verificar lagunas de memoria */ if ( _CrtDumpMemoryLeaks() ) printf ("\n\t Hay Lagunas de Memoria \n\n"); } // Fin del main() ///////////////////////////////////////////////////////////////////////////////// ///////////////// Definición de funciones ///////////////////////// ///////////////////////////////////////////////////////////////////////////////// ////////////////////// Menu //////////////////////////// int Menu(void) { int op; do { printf("\n\n\t ******** Empleados ***************"); printf("\n\t 1. Ingresar un nuevo empleado. "); printf("\n\t 2. Borrar un empleado. "); printf("\n\t 3. Buscar a un empleado (cedula). "); printf("\n\t 4. Visualizar lista de empleados. "); printf("\n\t 5. Salir. "); printf("\n\n\t Su opcion (1-5) ?: "); scanf("%d", &op); } while ( op < 1 || op > 5 ); return (op); } // Fin de Menu() /*************** Crear un nuevo Cliente de la cola *************/ TElemento *NuevoElemento () { TElemento *temp; temp = (TElemento *) malloc ( sizeof (TElemento) ); if (temp == NULL) Error(); return (temp); } // Fin de NuevoCliente ()

Departamento de Computación UNAN - León

Page 614: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 298 de 298

/*********** Error al asignar memoria ************************/ void Error (void) { perror ("Error: insuficiente espacio de memoria"); exit (1); } // Fin de Error() /*************** Leer datos de un empleado **********************/ void LeerDatosEmpleado (TEmpleado *pe) { printf("\n\t Datos del empleado"); fflush (stdin); printf("\n\t Cedula: "); gets(pe->cedula); printf("\n\t Nombre: "); gets(pe->nombre); printf("\n\t Salario: "); scanf("%f", &pe->salario); } // Fin de LeerDatosEmpleado() /************* Anadir un Cliente al final de la lista *************/ void Anadir (TElemento **p_lista, TElemento **f_lista, TEmpleado e) { TElemento *pc, *fc, *q; pc = *p_lista; // Principio de la cola fc = *f_lista; // Final de la cola q = NuevoElemento (); q->empl = e; // Copiamos el empleado e en q q->sig = NULL; if (fc == NULL) // Cola vacía pc = fc = q; else // Cola con al menos 1 Cliente { fc->sig = q; fc = fc->sig; } /* Actualizar el principio y el final de la cola */

Departamento de Computación UNAN - León

Page 615: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 299 de 299

*p_lista = pc; *f_lista = fc; } // Fin de Introducir() /**** Borra al empleado de la lista con cedula 'cedula' ****/ void Borrar (TElemento **principio, char *cedula) { TElemento *cabecera = *principio; TElemento *actual = cabecera, *anterior = cabecera; if (ListaVacia(cabecera) == True) { printf ("\n\t LISTA VACIA !!!"); return; } /* Entrar en la lista y encontrar el elemento a borrar */ while (actual != NULL && strcmp (actual->empl.cedula, cedula) != 0) { anterior = actual; actual = actual->sig; } /* Si el dato no se encuentra, retornar */ if (actual == NULL) return; /* Si el dato se encuentra, borrar el elemento. */ if (anterior == actual) /* borrar el elemento de cabecera */ cabecera = cabecera->sig; else /* borrar un elemento no cabecera */ anterior->sig = actual->sig; free (actual); printf ("\n\tEmpleado borrado...."); getch(); *principio = cabecera; } // Fin de Borrar () /********** Ordena la lista por el método de la burbuja *********/ void OrdenarBurbuja ( TElemento **principio ) { // Ordena los empleados por la cédula TElemento *cabecera, *anterior, *actual; cabecera = *principio; // cabecera de la lista anterior = cabecera;

Departamento de Computación UNAN - León

Page 616: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 300 de 300

actual = cabecera->sig; TEmpleado temp; for ( actual = cabecera->sig; actual != NULL; actual = actual ->sig) { for (anterior = cabecera; anterior->sig != NULL; anterior = anterior->sig) if ( strcmp (anterior->empl.cedula, (anterior->sig)->empl.cedula) > 0 ) { temp = anterior->empl; anterior->empl = (anterior->sig)->empl; (anterior->sig)->empl= temp; } } /* Actualizar la cabecera de la lista */ *principio = cabecera; } // Fin de OrdenarBurbuja() /* Verificar si la lista está vacía */ booleano ListaVacia (TElemento *pe) { if (pe == NULL) return (True); else return (False); } // Fin de ListaVacia() /* Buscar a un empleado por la cedula */ TElemento *Buscar (TElemento *principio, char *cedula) { TElemento *actual = principio; while (actual != NULL && strcmp (actual->empl.cedula, cedula) != 0) actual = actual->sig; return (actual); } // Fin de Buscar() /* Visualiza los elementos de la lista */ void Visualizar (TElemento *pc) { TElemento *recorredor = pc; if (ListaVacia(recorredor) == True) { printf ("\n\t LISTA VACIA !!!"); return;

Departamento de Computación UNAN - León

Page 617: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 301 de 301

} while (recorredor != NULL) { printf (" %s %s %f --> ", recorredor->empl.cedula, recorredor->empl.nombre, recorredor->empl.salario); recorredor = recorredor->sig; } printf ("NULL"); } // Fin de Visualizar() /*********** Eliminar Lagunas de Memoria *******************/ void EliminarLagunas (TElemento **principio) { TElemento *pl, *aux; pl = *principio; // principio de la cola aux = pl; if (ListaVacia(pl) == True) return; // Si la cola está vacía, retornar else { // Recorrer la lista desde el principio y elminar los Clientes while (pl != NULL) { aux = pl; pl = pl->sig; free (aux); } } // Fin del else pl = aux = NULL; /* Actualizar los cambios */ *principio = pl; } // Fin de EliminarLagunas()

Departamento de Computación UNAN - León

Page 618: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 302 de 302

PPRREESSEENNTTAACCIIÓÓNN DDEE RREESSUULLTTAADDOOSS

En esta sección se presentará los resultados que ha originado la ejecución del programa. Las entradas del usuario están dada en negritas cursivas y subrayadas. ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir. Su opcion (1-5) ?: 1 Datos del empleado Cedula: ronie026 Nombre: Ronaldo Salario: 20000 Presione una tecla para continuar ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir. Su opcion (1-5) ?: 1 Datos del empleado Cedula: fig030 Nombre: Figo Salario: 12000 Presione una tecla para continuar

******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir.

Departamento de Computación UNAN - León

Page 619: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 303 de 303

Su opcion (1-5) ?: 1 Datos del empleado Cedula: zid032 Nombre: Zidane Salario: 45000 Presione una tecla para continuar ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir. Su opcion (1-5) ?: 4 fig030 Figo 12000.000000 --> ronie026 Ronaldo 20000.000000 --> zid032 Zidane 45000.000000 --> NULL

Presione una tecla para continuar

******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir.

Su opcion (1-5) ?: 2 Cedula del Empleado a borrar: fig030 Empleado borrado.... Presione una tecla para continuar

Su opcion (1-5) ?: 4

******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir.

ronie026 Ronaldo 20000.000000 --> zid032 Zidane 45000.000000 --> NULL Presione una tecla para continuar ******** Empleados *************** 1. Ingresar un nuevo empleado. 2. Borrar un empleado.

3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir.

Departamento de Computación UNAN - León

Page 620: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 304 de 304

Su opcion (1-5) ?: 3 Cedula del Empleado a buscar: zid032

Presione una tecla para continuar

******** Empleados *************** 1. Ingresar un nuevo empleado.

Empleado encontrado...

2. Borrar un empleado. 3. Buscar a un empleado (cedula). 4. Visualizar lista de empleados. 5. Salir.

Su opcion (1-5) ?: 5Press any key to continue

Al finalizar la práctica se han cumplido con los objetivos propuestos, se ha implementado el algoritmo de la burbuja usando listas lineales y se ha reforzado el manejo de las operaciones sobre listas.

CCOONNCCLLUUSSIIOONNEESS

RREECCOOMMEENNDDAACCIIOONNEESS Desarrollar otra versión de esta práctica, usando los demás métodos de ordenación vistos en clases.

BBIIBBLLIIOOGGRRAAFFÍÍAA Libros:

• Enciclopedia de Lenguaje C. Fco Javier Ceballos. Ed. RAMA.

• Cómo programar en C / C++. Deitel y Deitel. Ed. McGraw – Hill.

Departamento de Computación UNAN - León

Page 621: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 305 de 305

AANNEEXXOOSS

Departamento de Computación UNAN - León

Page 622: PLAN DOCENTE DE ANÁLISIS Y DISEÑO DE SISTEMAS DE …

Plan docente de Algoritmos y Estructuras de Datos Página 306 de 306

9 Anexos

ANEXO A BIBLIOGRAFÍA

• Ceballos, Fco Javier. 1997. Enciclopedia del Lenguaje C. Alfaomega RAMA.

• Ceballos, Fco Javier. 1995. Curso de Programación C/C++. RAMA. • Deitel y Deitel. 1999. Cómo programar en C/C++. 1 Edición. Prentice Hall. • Joyanes, Luis. 1999. "Metodología de la programación" Mc Graw Hill. • Wirth, Niklaus. 1994. Algoritmos y Estructuras de Datos. 1a Edición. Prentice

Hall. • Tenenbaum, Langsam, Augenstein. 1993. Estructuras de Datos en C.

Prentice Hall.

Departamento de Computación UNAN - León