MODELO ANALÍTICO PARA EL DISEÑO DE

PROYECTO DE GRADO

Presentado ante la ilustre UNIVERSIDAD DE LOS ANDES como requisito parcial para

obtener el Título de INGENIERO DE SISTEMAS

MODELO ANALÍTICO PARA EL DISEÑO DE

MICROPROCESADORES

Por

Br. Diego Armando Páez Martínez

Tutor: Dr. Gerard Páez Monzón

Marzo 2009

©2009 Universidad de Los Andes Mérida, Venezuela

MODELO ANALÍTICO PARA EL DISEÑO DE MICROPROCESADORES

Br. Diego Armando Páez Martínez

Proyecto de Grado — Sistemas Computacionales, 81 páginas

Resumen:

En esta tesis se desarrolló un ambiente analítico genérico para apoyar la fase arquitectónica en el diseño

de microprocesadores. En un primer paso, se definieron las ecuaciones matemáticas que representaron

las conductas de los elementos funcionales principales que componen un microprocesador y su correcta

combinación definida por la arquitectura. El siguiente paso consistió en ofrecer un ambiente de interfaz

programado que permita al diseñador especificar una arquitectura a evaluar. Así como también, una

capacidad básica de graficar curvas de los valores resultantes. Estos valores indican las tendencias de los

factores de evaluación seleccionados en una arquitectura definida, siendo uno de estos indicadores el

número de instrucciones que se ejecutan por ciclo, así como otros que nos permiten cuantificar el

diseño. Se explicó finalmente, la metodología de software utilizada como parte de la formación en

Ingeniería de Sistemas de la Universidad de Los Andes.

Palabras clave: modelo, analítico, microprocesadores, arquitectura del computador, ingeniería de

sistemas, ingeniería de software.

iii

A mis padres y mis hermanos.

iv

Índice

Índice ...................................................................................................................... iv

Índice de Figuras ......................................................................................................... vi

Capítulo 1 ................................................................................................................ 9

Introducción ............................................................................................................... 9

1.1 Antecedentes .................................................................................... 11

1.2 Planteamiento del Problema .................................................................. 12

1.3 Definición y Delimitación del Problema .................................................... 12

1.4 Objetivos ......................................................................................... 13

1.5 Metodología ..................................................................................... 14

1.6 Definición del Lenguaje de Programación .................................................. 14

1.7 Cronograma de Trabajo ....................................................................... 15

1.8 Cronograma de Evaluación .................................................................... 16

Capítulo 2 Fundamentos para el Desarrollo del Sistema ............................................... 17

2.1 Estado del arte ................................................................................... 17

2.2 Marco Teórico ................................................................................... 17

2.2.1 Circuitos Integrados ............................................................................ 17

2.2.2 Microprocesadores ............................................................................. 18

2.2.3 Arquitectura del Computador ................................................................ 18

2.2.4 Definiciones de Arquitectura ................................................................. 21

2.3 Sistema validador de arquitecturas de microprocesadores ............................... 33

Capítulo 3 Desarrollo del Sistema ......................................................................... 34

3.1 Modelo Analítico................................................................................ 34

3.1.1 Definición y Modelado del Negocio ......................................................... 35

3.1.2 Definición de requisitos de software ...................................................... 36

3.1.3 Especificación de requisitos de software ................................................. 39

3.1.4 Diseño del Producto de Software .......................................................... 49

3.1.5 Implementación y Pruebas .................................................................. 57

v

3.2 Archivo Caracterizador (PROFILER) ....................................................... 58

3.3 Archivo de Salida ................................................................................ 61

Capítulo 4 Conclusiones ..................................................................................... 63

APENDICE A: Java .................................................................................................... 66

APENDICE B: UML ................................................................................................... 68

APENDICE C: Metodología Watch ................................................................................ 69

Bibliografía ............................................................................................................... 80

vi

Índice de Figuras

Figura 1 Cronograma de Trabajo .................................................................................... 15

Figura 2 Cronograma de Evaluaciones .............................................................................. 16

Figura 3 Microprocesadores .......................................................................................... 18

Figura 4 Pipelining ..................................................................................................... 20

Figura 8 Ecuación: DBBSZ............................................................................................ 27

Figura 9 Ecuación: Ciclos de Corrida ............................................................................... 27

Figura 10 Ecuación: IPC de corrida ................................................................................. 28

Figura 11 Ecuación: IPC de saltos ................................................................................... 28

Figura 12 Ecuación: IPC del Microprocesador .................................................................... 29

Figura 13 Ecuación: Ciclos I Cache N1 ............................................................................. 29



Figura 16 Ecuación: Ciclos D Cache N1 ........................................................................... 30



Figura 19 Ecuación: Ciclos ITLB N1 ................................................................................ 31



Figura 22 Ecuación: Ciclos DTLB N1 .............................................................................. 32



Figura 22 Clasificación de Requisitos del Sistema ................................................................ 38

Figura 23 Caso de Uso: General ..................................................................................... 42

Figura 24 Caso de Uso: Ver Manual de Usuario .................................................................. 43

Figura 25 Caso de Uso: Introducir Arquitectura ................................................................. 43

Figura 26 Caso de Uso: Leer Variables ............................................................................. 44

Figura 27 Caso de Uso: Correr Arquitectura ..................................................................... 45

Figura 28 Caso de Uso: Graficar ..................................................................................... 46

vii

Figura 29 Caso de Uso: Salir ......................................................................................... 47

Figura 30 Diagrama de Secuencia General ......................................................................... 48

Figura 31 Diagrama de Secuencia Correr Arquitectura ......................................................... 48

Figura 32 Arquitectura de la Aplicación ............................................................................ 49

Figura 33 Estructura de Nodos ...................................................................................... 50

Figura 34 Diseño de la Interfaz....................................................................................... 51

Figura 35 Pantalla Principal........................................................................................... 52

Figura 36 Módulo de Memoria de Instrucciones ................................................................. 52

Figura 37 Módulo de Memoria de Datos ........................................................................... 53

Figura 38 Modulo de Micro-Arquitectura ......................................................................... 53

Figura 39 Modulo de Caracterización del Código ................................................................ 54

Figura 40 Módulo de Configuración de archivos y gráficos ..................................................... 54

Figura 41 Módulo de Resultados .................................................................................... 54

Figura 42 Pantalla Acerca de ......................................................................................... 55

Figura 43 Pantalla de Gráficos ....................................................................................... 55

Figura 44 Pantalla de Información ................................................................................... 56

Figura 45 Pantalla Mensaje de Error de Gráfico .................................................................. 56

Figura 46 Pantalla Mensaje de Archivo no disponible ............................................................ 56

Figura 47 Ventana Error de validación de la Arquitectura ingresada .......................................... 57

Figura 48 Ventana de Mensaje de error de selección de parámetro de gráfico .............................. 57

Figura 49 Ejemplo archivo de entrada al sistema ................................................................. 61

Figura 50 Ejemplo Archivo de Salida ............................................................................... 62

Figura 51 Logo Java .................................................................................................... 66

Figura 52 Duke, la mascota de Java ................................................................................. 66

Figura 53 Método Watch ............................................................................................. 69

Figura 54 Arquitectura de 3 capas ................................................................................... 71

Figura 55 Etapas del Modelado del Negocios...................................................................... 73

Figura 56 Etapas Definición y especificación de requisitos ...................................................... 74

Figura 57 Diseño de la Aplicación ................................................................................... 75

Figura 58 Etapas de Diseño de la Aplicación ...................................................................... 76

Figura 59 Etapas de Especificación de Componentes ............................................................ 76

viii

Figura 60 Etapas de Aprovisionamiento del Componente ...................................................... 77

Figura 62 Etapas de Pruebas de la Aplicación ..................................................................... 78

Figura 61 Etapas de Ensamblaje del Componente ................................................................ 78

Figura 63 Etapas de Entrega de la Aplicación ..................................................................... 79

Capítulo 1

Introducción

El proceso tecnológico para desarrollar un microprocesador está compuesto por varias etapas de

abstracciones de diseño. La fase inicial de ingeniería es conocida como la etapa de Arquitectura que

consiste en la exploración del espacio de diseño, definición, validez y evaluación de la concepción

funcional del microprocesador. Su base central es la construcción de modelos programados de la

arquitectura en desarrollo para cumplir con las responsabilidades antes mencionadas. Estos modelos

además, presentan diferentes aspectos y niveles de abstracciones requeridos por el proceso de

definición del diseño, existiendo así varias clases: modelos de precisión al reloj, modelos de precisión al

bit, modelos de simulación de alto nivel, modelos de transferencia de registros, de transacciones,

modelos analíticos, entre otros. Los mismos ofrecen una simulación de la arquitectura en desarrollo

con ciertos grados de exactitud.

La fase de Arquitectura en el diseño de un microprocesador ó sistema de procesamiento tiene

como fundamento una orientación cuantitativa con el objetivo de ofrecer al arquitecto la calidad del

diseño en definición. La calidad está dado por unos valores que pueden ser sobre rendimiento (qué

rápido ejecuta el sistema procesador una aplicación), sobre disipación de potencia, energía, así como

otros factores importantes que influyen en la concepción de un microprocesador.

Los modelos analíticos están principalmente basados en ecuaciones matemáticas donde cada

bloque funcional importante de un microprocesador es representado por una expresión matemática. El

algoritmo del modelo analítico especifica la organización del sistema de procesamiento bajo desarrollo

Capítulo 1 10

que viene dada por la correcta combinación de las ecuaciones matemáticas definidas. Estas ecuaciones

matemáticas son alimentadas por unos valores de entrada especificados por el arquitecto en un primer

momento. El segundo momento de entrega de valores a las ecuaciones matemáticas viene de la

caracterización de las aplicaciones que serían ejecutadas por el microprocesador diseñado. Estas

aplicaciones ó programas son caracterizados bajo los criterios válidos de cada bloque funcional del

microprocesador.

El modelo analítico al ser manejado es una herramienta práctica por su rápida especificación de la

organización del microprocesador y la respuesta dada como resultado.

Es importante señalar que los modelos analíticos no son muy precisos pero son rápidos de

calibrar. Además, al ser usados los modelos analíticos por expertos en microprocesadores, los

resultados entonces muestran una tendencia de procesamiento.

Los pasos de desarrollo de esta herramienta programada serán: Revisión de la arquitectura del

microprocesador, Definición de las ecuaciones matemáticas, Ventana de interfaz gráfica que permita al

arquitecto especificar la organización a ser ensayado de una manera amistosa.

Capítulo 1 11

1.1 Antecedentes

El profesor tutor, el Dr. Gerard Páez Monzón, es un experto en el campo de los microprocesadores, su

diseño y desarrollo con una experiencia industrial de unos 8 años en el centro tecnológico mundial,

conocido como el ¨Silicon Valley¨, California, EE.UU. En su actividad industrial, el Dr. Páez Monzón

fue Jefe de Arquitectos en el desarrollo de un número de circuitos integrados desde el diseño de un

microprocesador x86 de alta prestaciones para aplicaciones de multimedia (competidor directo al

Pentium III), un Chip Neuronal, y un Chip CMOS Sensor Inteligente, y como arquitecto de apoyo, un

microprocesador x86 para el mercado Encajado (“Embedded”) y un Chip MP3 utilizado en el primer

IPOD de la compañía Apple. Las etapas de desarrollo de esta variedad de productos exigen

constantemente la validación, optimización y especificación inicial del producto que se hacen a través de

un juego de herramientas de software y hardware. El Dr. Páez Monzón creo y dirigió varios desarrollos

de herramientas de software para el análisis de prestaciones de los diferentes circuitos integrados

mencionados arriba, así como también para su validación y optimización. Estas herramientas fueron

desde modelos analíticos hasta modelos a precisión de reloj, y otros mas como plataformas de desarrollo

en modo de “plug&play”. El desarrollo de esta tesis es el paso inicial en la transferencia tecnológica de

todo el proceso de diseño, modelización y evaluaciones, especificación de hardware y tecnológica,

fabricación y la validación perenne que se requiere para la concepción de un Circuito Integrado de

procesamiento (microprocesadores, computadores, sistemas-en-un-chip, multi-cpus, etc.).

.

Ahora de regreso en la Universidad de Los Andes, inicia el esfuerzo de reconstruir los ambientes

necesarios para el diseño de circuitos integrados en semiconductor en el seno del Centro de Estudios

en Microcomputación y Sistemas Distribuidos (CEMISID) de la Universidad de Los

Andes. Esta tesis es parte del desarrollo de construcción del proceso tecnológico requerido para esta

misión de realizar circuitos integrados en nuestra universidad.

El valor de esta tesis de pregrado consiste en construir un modelo analítico orientado al diseño de

microprocesadores. Los modelos analíticos sufren de un grado de cuidado en los resultados que ofrecen

debido a que sus especificaciones de diseño, ya que están basadas en el conocimiento y experticia de la

personal que lo origina, además de ser per-se unos modelos muy generalizados en el espacio de análisis

Capítulo 1 12

debido a su base matemática genérica, a lo contrario de un modelo de precisión de reloj ó un modelo

emulador hardware en FPGA (Field-Programmable Gate Arrays) donde se simula o se realiza cada

transferencia lógica de registro. El modelo analítico desarrollado en esta tesis está completamente

basado en los conocimientos y experticias del Dr. Páez Monzón. Hasta el momento no se había

propuesto ningún modelo evaluador de arquitecturas de Microprocesadores en la Universidad de los

Andes.

1.2 Planteamiento del Problema

Para definir una arquitectura microprocesador se debe explorar un espacio de diseño de ideas y

funciones que cumplan con el objetivo de procesamiento. Esta fase de definición viene acompañada por

evaluaciones que indicarán la valía de la misma. Un ambiente analítico ofrece unos indicadores sobre el

factor que se desea evaluar en tiempos inmediatos. La rapidez de sus respuestas se debe a que son un

conjunto de ecuaciones matemáticas que reflejan el comportamiento de los diferentes bloques

importantes en la arquitectura en desarrollo.Por lo tanto, debemos identificar y construir cada ecuación

matemática importante relacionada a cada bloque funcional del microprocesador definido.

Estas ecuaciones tendrán como variables, aquellas especificaciones de arquitectura definida por el

diseñador. En una fase posterior, un conjunto de estos valores serán ofrecidos por otras herramientas

(ver capítulo final de conclusiones).

1.3 Definición y Delimitación del Problema

En la actualidad y gracias al avance existente en el campo tecnológico, se hace cada vez más necesario el

uso de circuitos integrados en cada uno de los componentes tecnológicos que se creen. Además de esto

la cantidad de datos y procesos que cada uno de estos debe manejar es de gran volumen y se necesitan

respuestas inmediatas por parte de los microprocesadores que controlan dichos procesos. Es por esto

que al momento de diseñar un microprocesador, el mismo debe cumplir con una serie de características

propias de los circuitos integrados así como de arquitectura.

Capítulo 1 13

Teniendo en cuenta que el rendimiento y alcance actual en el campo de los microprocesadores

se deben más al avance en el estudio de la arquitectura de los computadores que a la misma

miniaturización de los equipos electrónicos, se hace necesario que dichas arquitecturas sean validadas

antes de llevar a producción un diseño.

El sistema a ser implementado deberá ser capaz de permitirle al grupo de arquitectos

encargados del diseño del microprocesador definir y especificar las características de arquitectura que

desean para un modelo específico. Una vez hecho esto, los diseñadores podrán hacer uso del modelo

analítico para obtener las tendencias de prestaciones producidas por los factores de evaluación

seleccionados en cada arquitectura definida; por ejemplo el número de instrucciones ejecutadas por

ciclo de reloj.

1.4 Objetivos

Objetivo General

Implementar un ambiente programado que apoye el diseño de un microprocesador de una forma

amistosa y genérica, utilizando un modelo analítico. Queriendo esto decir, variar fácilmente aspectos de

la arquitectura y obtener resultados de respuesta inmediatamente.

Objetivo Específicos

Definir las ecuaciones matemáticas necesarias para modelar y representar el comportamiento

de los microprocesadores.

Identificar el lenguaje idóneo para la implementación del sistema.

Implementación del ambiente interfaz que permita la modificación del diseño de la arquitectura

de un microprocesador.

Desarrollar un producto de software multiplataforma y portable.

Apoyar a nivel didáctico la materia de arquitectura del computador del postgrado de

computación de la Universidad de los Andes, así como de su similar en pregrado.

Capítulo 1 14

Formar parte del grupo de ambientes necesarios para el diseño de circuitos integrados en

semiconductor en el CEMISID.

1.5 Metodología

Para cumplir con los objetivos propuestos anteriormente se han definidos las siguientes etapas de

trabajo:

Etapa 1: Revisión bibliográfica de contenidos relacionados con circuitos integrados, así

como de la arquitectura y diseño de microprocesadores, sumando a esto las diferentes

formas de validación existentes, específicamente el modelo analítico o matemático.

Etapa 2: Identificación de las ecuaciones matemáticas relacionadas a cada bloque

funcional del microprocesador

Etapa 3: Revisión de los lenguajes de programación que puedan servir para la

implementación del sistema, teniendo en cuenta sus capacidades específicas a nivel

gráfico para el sistema a implementar.

Etapa 4: Implementación del ambiente de Interfaz que permita modificar las

características de una arquitectura de microprocesador

Etapa 5: Implementación de la capacidad básica de gráficas de curvas de los resultados.

Etapa 6: Pruebas y depuración del Sistema.

Etapa 7: Conclusiones finales del sistema implementado y redacción del documento de

Proyecto de Grado.

Dado que se va a implementar un producto de software, se utilizara el método para producción

de software, el Método WATCH (Montilva, 2004), llevando a cabo dicha implementación en el

lenguaje de programación orientado a objetos JAVA de SUN Microsystems.

1.6 Definición del Lenguaje de Programación

Dadas las características requeridas en los objetivos en cuanto a portabilidad, y ejecución, se seleccionó

el Lenguaje de programación JAVA de SUN MycroSystems(ver Apéndice A) por sus características de

Capítulo 1 15

portabilidad, ejecución en distintos sistemas operativos, así como también por tener como meta

académica que se pueda integrar fácilmente en el internet.

De la misma forma, dado que el diseño del sistema se realizó utilizando la metodología Watch, se

hace necesario el uso de herramientas de modelado. En este caso se realizó basándose en UML (por sus

siglas en ingles Unified Modeling Language), el cual permitió el análisis y el diseño para el desarrollo el

sistema de software de este trabajo (ver apéndice B)

1.7 Cronograma de Trabajo

El diagrama de Gantt mostrado a continuación en la Figura 1 Cronograma de Trabajo, permite

visualizar la distribución y planificación temporal de las actividades a cumplir para la realización del

proyecto de grado.

Figura 1 Cronograma de Trabajo

Capítulo 1 16

1.8 Cronograma de Evaluación

En el diagrama de Gantt que se muestra en la Figura 2 Cronograma de Evaluaciones, se observa la

planificación de las evaluaciones del proyecto de grado.

Figura 2 Cronograma de Evaluaciones

Capítulo 2 Fundamentos para el Desarrollo del

Sistema

2.1 Estado del arte

Actualmente, a nivel mundial, cada uno de las empresas u organizaciones que desarrollan e

implementan microprocesadores poseen sus propios métodos para la validación de sus diseños de

arquitecturas, haciendo uso de un proceso de caja negra. En este ámbito los avances en dicha tecnología

son amplios, existiendo una gran variedad de simuladores utilizados para este fin.

Como se mencionó anteriormente, el Prof. Gerard Páez desea crear los módulos necesarios

para la implementación de circuitos integrados de microprocesadores en el CEMISID.

2.2 Marco Teórico

Teniendo en cuenta que esta tesis se encuentra ubicada en el campo tecnológico, mas específicamente

en el mundo de los circuitos integrados, es imperativo comenzar haciendo una reseña de los mismos, así

como los dispositivos más avanzados en este campo como son los microprocesadores.

2.2.1 Circuitos Integrados

Según (Wikipedia, La enciclopedia Libre), un circuito integrado es una pastilla muy delgada en la que se

encuentra una enorme cantidad (del orden de miles o millones) de dispositivos microelectrónicos

interconectados, principalmente diodos y transistores, además de componentes pasivos como

resistencias o condensadores. Su área es de tamaño reducido, del orden de un cm² o inferior. Algunos

Capítulo 2 Fundamentos para el Desarrollo del Sistema 18

de los circuitos integrados más avanzados son los microprocesadores, que son usados en múltiples

artefactos, desde computadoras hasta electrodomésticos, pasando por los teléfonos móviles.

2.2.2 Microprocesadores

Un microprocesador es un circuito integrado construido en un solo chip, que contiene todos los

elementos de una "unidad central de procesamiento" o CPU, es decir que puede ser capaz de

interpretar instrucciones y procesar los datos contenidos en los programas de computadora

proporcionando el control de las operaciones de cálculo. Los microprocesadores también se utilizan en

otros sistemas informáticos avanzados, como impresoras, automóviles o aviones. A pesar de ser el

“cerebro” de estos sistemas, en la figura 3 se muestran unos dispositivos microprocesadores de los

computadores actuales donde el circuito integrado interno, tiene la dimensión de una uña del dedo

anular de un adulto, integrando cientos y/o miles de millones de transistores para esta época.

Figura 3 Microprocesadores

2.2.3 Arquitectura del Computador

En ingeniería, la arquitectura del computador es el diseño conceptual y fundamental de la estructura

operacional de un sistema computacional, donde se describen los requerimientos de funcionabilidad y el

diseño de implementación del mismo, centrándose específicamente en la Unidad Central de

Procesamiento (CPU) y la jerarquía de memoria en esta tesis.


2.2.3.1 Objetivos de Diseño

La forma en que se construye y se diseña un microprocesador depende de los objetivos que se desean

alcanzar con la optimización del mismo. Generalmente la arquitectura de computador busca cumplir

ciertos estándares como confiabilidad, costo, rendimiento en el procesamiento, disipación de potencia,

ahorro de energía, tipo de mercado, etc. El CEMISID tiene como objetivo principal el manejo del

proceso tecnológico en el desarrollo de un circuito integrado en general, por lo que nos empuja a cubrir

y elaborar diferentes herramientas de apoyo al mismo para que en un futuro cercano podamos diseñar

sistemas de procesamiento en un chip respondiendo a las exigencias iníciales mencionadas arriba.

2.2.3.2 Rendimiento

El rendimiento de un computador depende directamente del rendimiento del microprocesador, el cual

se puede describir en términos de velocidad de reloj (medido en MHz o GHz). Esto se refiere a la

cantidad de ciclos por segundo del reloj principal del microprocesador. Sin embargo esta medida no

depende totalmente del microprocesador, ya que una máquina que tenga un alto rango de reloj no

necesariamente va a tener el mejor rendimiento, debido a que el mismo depende a su vez de la

arquitectura diseñada. Los elementos de memoria (Ej. Tamaño de las memorias caches), porcentaje de

fallo del saltos, precisiones de los datos, capacidades de procesamientos, paralelismo, etc. Gracias a la

arquitectura, los microprocesadores actuales pueden ejecutar múltiples instrucciones por ciclo de reloj

bien por el uso de multi-cpus o de técnicas de diseño como la segmentación (pipeline), el cual no es más

que la ejecución simultanea de un conjunto de instrucciones de un programa pero en segmentos

paralelos para cada instrucción (Ej. Decodificación de la instrucción i+1 y la Suma de la instrucción i,

ver Figura 4 Pipelining).


Figura 4 Pipelining

Existen dos aspectos principales de velocidad en la ejecución de programas en un microprocesador: a) la

latencia y b) la producción. La latencia es el tiempo entre el comienzo de ejecutar una instrucción y su

culminación. Por otra parte, la producción es la suma de instrucciones ejecutadas en una unidad de

tiempo. En este caso el concepto de segmentación pueda que afecte la latencia de las instrucciones pero

puede ofrecer una gran mejora de producción.

El modelo analítico que desarrollamos en esta tesis, tratará de recorrer los diferentes detalles

que suceden al ejecutar un programa sobre una arquitectura segmentada. Por ejemplo, el factor del

número de etapas que está organizado el encauce influirá en el rendimiento final de su ejecución

(cuantas instrucciones en paralelo pueden existir en un momento dado, etc.). Otro factor muy sensitivo

al número de etapas de una arquitectura encauzada, es la dependencia de datos. Para atender esta

sensibilidad, creamos un archivo que será leído por el analizador y tomará los datos expuestos de los

diferentes grados de sensibilidad en base donde se encuentra una instrucción en el encauce (ver Figura

49. Ejemplo de Archivo de entrada al sistema). Así como estos factores, el tamaño seleccionado por el

arquitecto del Primer Nivel de la Memoria Cache, el número de instrucciones que podemos buscar en

un ciclo de lectura de memoria, el porcentaje de falla de un predictor en las instrucciones de saltos

condicionales, etc., afectaran en sus posibilidades al rendimiento de la ejecución de un programa. En la

próxima sección, se especifican todos los factores que fueron utilizados para este Modelo Analítico.


2.2.4 Definiciones de Arquitectura

2.2.4.1 Variables del Sistema

En la naturaleza existen una infinidad de comportamientos que se basan en modelos matemáticos o

analíticos, los cuales se representan por medio de fórmulas que simulan el comportamiento de un

determinado fenómeno, de igual manera ocurre con los microprocesadores.

Al momento de diseñar un modelo matemático, es necesario, al principio tomar en cuenta las

variables de importancia en el sistema, las cuales serán las encargadas de afectar e incidir de una u otra

forma dicho comportamiento.

A continuación se presenta la lista de variables que se consideraron para realizar el modelado de

las ecuaciones que representarían más adelante un microprocesador por medio del modelo analítico.

Tasa de Fallo de N1 ICache: Tasa de fallos que existe en el nivel 1 de la cache de

instrucciones en la ejecución de un programa.

N1 ICache: La memoria cache más cercana y pequeña construida en base a la micro

arquitectura del CPU. Esta permite acceder rápidamente a instrucciones

frecuentemente utilizadas, siendo requerida en la ejecución de programas.

Penalidad de Fallo de N1 ICache: costo en ciclos de reloj al fallar en conseguir una

instrucción en el nivel 1 ICache.

Tasa de Fallos de N2 ICache: Tasa de fallos que existe en el nivel 2 de la cache de

instrucciones.

N2 ICache: es la memoria cache que tiene como objetivo cubrir el porcentaje de fallas

del nivel superior inmediato de ICache (Nivel 1).


Penalidad de Fallo de N2 ICache: Costo en ciclos de reloj al fallar en conseguir una


Tasa de Fallos de N3 ICache: Tasa de fallos que existe en el nivel 3 de la cache de

instrucciones.

N3 ICache: esta memoria de cache trata de cubrir por completo alguna falla en la

búsqueda de instrucciones durante la ejecución de un programa, logrando así evitar

salir del circuito integrado a un nivel inferior de memoria diseñado externa al chip

microprocesador.

Penalidad de Fallo N3 ICache: Costo en ciclos de reloj al fallar en conseguir una


Tamaño de la línea de I-Cache: Número de bytes leídos en un solo acceso a la Cache de

instrucciones.

Número de bytes por instrucción: Número de bytes en promedio de las instrucciones.

Por ejemplo: En el ISA X86 el número de bytes de las instrucciones es variable, por

lo que se solicita un promedio.

Ciclos por búsqueda: Número de ciclos de reloj que demora el microprocesador en la

búsqueda de instrucciones.

Tamaño del bloque básico: Número promedio de instrucciones que existen entre dos

instrucciones de salto.

Probabilidad de fallo del salto: Tasa de equivocación al momento de predecir una

instrucción de salto.


Penalidad del salto tomado: Número de ciclos requeridos para recuperar el seguimiento

correcto de la ejecución de un programa al fallar en la predicción de saltos.

Número de micro operaciones por instrucción: es la cantidad de operaciones en las

que se puede transformar una instrucción dentro del microprocesador. Por ejemplo

las instrucciones del ISA X86 normalmente se convierten internamente en el

microprocesador en un conjunto de micro operaciones para llevar a cabo su

ejecución.

Número de decodificadores: Cantidad de instrucciones que pueden ser

decodificadas simultáneamente.

Número de etapas: Número de segmentos del cauce micro arquitectónico (PIPELINE)

para la ejecución de las instrucciones.

Tamaño de la cola de instrucciones: Número de instrucciones decodificadas

disponibles en cola, en espera de recursos ó solución de dependencia.

Ejecución Fuera de Orden (EFO): Capacidad de ejecutar las instrucciones de un

programa sin seguir el estricto orden de la compilación, sino explotando la ventaja

de independencia que existe en las instrucciones del programa.

Ejecución En Orden (EO): ejecución de un programa según el orden dictado por la

compilación.

Unidades Funcionales: Número de recursos funcionales necesarios para la ejecución de

la operación indicada en cada instrucción.


Tasa de Falla de N1 DCache: Tasa de fallos que existe en el nivel 1 de la cache de datos

en la ejecución de un programa.

Penalidad de Fallo de N1 DCache: costo en ciclos de reloj al fallar en conseguir un dato

en el nivel 1 DCache.









Factor de protección de L1-D$ por EFO: Porcentaje que esconde la ejecución fuera de

orden al fallar la búsqueda de una dato en el nivel 1 de la cache de datos. La EFO

permite adelantar instrucciones que no dependen de la falla de N1 - DCache. El

factor está directamente relacionado al número de instrucciones presentes en el

cauce micro arquitectónico.

Factor de protección de L2-D$ por EFO: Porcentaje que esconde la ejecución fuera de

orden al fallar la búsqueda de una dato en el nivel 2 de la cache de datos. La EFO

permite adelantar instrucciones que no dependen de la falla de N2 - DCache. El

factor está directamente relacionado al número de instrucciones presentes en el

cauce micro arquitectónico.


Porcentaje de acceso a memoria: Porcentaje de instrucciones que requieren solicitudes a

memoria de datos.

Ciclos de acceso N1 DCache: Total de ciclos de solicitudes al nivel 1 DCache.

Porcentaje de acceso a carga: Porcentaje de instrucciones que requieren de algún tipo de

carga de datos. Por ejemplo instrucciones Loads.

Tasa de Falla de N1 I-TLB: Tasa de fallos a la cache de instrucciones de la tabla de

traducción de páginas de memoria de direcciones virtuales en el nivel 1.

N1 I-TLB: Translation Lookaside Buffer (TLB) es una memoria caché administrada por la

MMU, que contiene partes de la tabla de paginación, es decir, relaciones entre

direcciones virtuales y reales. Posee un número fijo de entradas y se utiliza para

obtener la traducción rápida de direcciones. Si no existe una entrada buscada, se

deberá revisar la tabla de paginación y tardará varios ciclos más, sobre todo si la

página que contiene la dirección buscada no está en memoria primaria.

Penalidad de Fallo de N1 I-TLB: costo en ciclos de reloj al fallar en conseguir un

dirección en el nivel 1 I-TLB.


traducción de páginas de memoria de direcciones virtuales en el nivel 2. Si en la tabla

de paginación N1 no se encuentra la dirección buscada, saltará una interrupción

conocida como fallo de página, es en este momento cuando se busca la dirección en

N2 I-TLB.





traducción de páginas de memoria de direcciones virtuales en el nivel 3. Si en la tabla

de paginación N2 no se encuentra la dirección buscada, saltará una interrupción


N3 D-TLB.



Tasa de Falla de N1 D-TLB: Tasa de fallos a la cache de datos de la tabla de traducción

de páginas de memoria de direcciones virtuales en el nivel 1.

Penalidad de Fallo de N1 D-TLB: costo en ciclos de reloj al fallar en conseguir un

dirección en el nivel 1 D-TLB.


de páginas de memoria de direcciones virtuales en el nivel 2. Si en la tabla de

paginación N1 no se encuentra la dirección buscada, saltará una interrupción


N2 D-TLB.

Penalidad de Fallo de N2 D-TLB: costo en ciclos de reloj al fallar en conseguir un

dirección en el nivel 2 D-TLB.


de páginas de memoria de direcciones virtuales en el nivel 3. Si en la tabla de

paginación N2 no se encuentra la dirección buscada, saltará una interrupción


N3 D-TLB.


Penalidad de Fallo de N3 D-TLB: costo en ciclos de reloj al fallar en conseguir un dirección

en el nivel 3 D-TLB.

2.2.4.2 Valores de Salida de la Simulación

Todo sistema que modela el comportamiento de un fenómeno físico, ya sea natural o artificial, tiene

como principal interés los resultados que arroja, las cuales son a fin de cuenta los valores que decidirán

la eficacia o no de una arquitectura especifica.

Es este segmento se mostrarán las variables calculadas en este sistema, las cuales darán validez al

modelo de arquitectura de un microprocesador. Para realizar estos cálculos se procede a realizar una

simulación de un cauce arquitectónico (PIPELINE), el cual se comporta de tal manera que va iterando a

medida que se van cargando instrucciones en memoria, ejecutándolas y tomando en cuenta las

probabilidades de salto y el tipo de ejecución que se diseño. A continuación se muestran las variables de

salida, así como las formulas matemáticas que se utilizan para su cálculo.

DBBSZ: número de bytes del bloque básico de datos.

Siendo: bbs = Tamaño del bloque básico

bpp = Probabilidad del fallo del salto

Ciclos de Corrida: Número de ciclos en ejecución.

La ecuación que se utilizó para realizar el cálculo de este valor es:

Siendo: Ciclos = total de veces que se adelanto el pipeline

Il1cyc= Total de ciclos de I$-N1

𝑟𝑐𝑦𝑐 = 𝐶𝑖𝑐𝑙𝑜𝑠 + 𝑖𝑙1𝑐𝑦𝑐 + 𝑖𝑙2𝑐𝑦𝑐 + 𝑖𝑙3𝑐𝑦𝑐 + 𝑡𝑖𝑙1𝑐𝑦𝑐

+ 𝑡𝑖𝑙2𝑐𝑦𝑐 + 𝑡𝑖𝑙3𝑐𝑦𝑐

𝐷𝐵𝐵𝑠𝑧 =𝑏𝑏𝑠 ∗ 100

𝑏𝑝𝑝

Figura 5 Ecuación: DBBSZ

Figura 6 Ecuación: Ciclos de Corrida




til1cyc= Total de ciclos de ITLB-N1



IPC de corrida: número total de instrucciones por reloj durante la ejecución del

programa.

La ecuación que rige el valor de esta variable es la siguiente:

Siendo: DBBsz = Tamaño del bloque básico de datos

rcyc = Ciclos de corrida

IPC de saltos: número total de instrucciones por reloj que ejecutaron un salto

(branch).

La siguiente ecuación muestra su cálculo:



brp = Penalidad del salto tomado

IPC del microprocesador:

Este valor se encuentra definida por la formula que se presenta a continuación:

𝑅𝐼𝑃𝐶 =𝐷𝐵𝐵𝑠𝑧

𝑟𝑐𝑦𝑐

𝐵𝐼𝑃𝐶 =𝐷𝐵𝐵𝑠𝑧

𝑟𝑐𝑦𝑐 + 𝑏𝑟𝑝

Figura 7 Ecuación: IPC de corrida

Figura 8 Ecuación: IPC de saltos




brp = Penalidad del salto tomado

l1cyc= Total de ciclos de D$-N1



tl1cyc= Total de ciclos de DTLB-N1



Ciclos I Cache N1: total de ciclos de ejecución de la ICache N1.

La ecuación para realizar el cálculo de esta variable es la siguiente:


cimr1 = Tasa de fallo de N1 ICache

cimp1 = Penalidad de falla de N1 ICache


La ecuación siguiente muestra el cálculo de

𝑀𝐼𝑃𝐶 =𝐷𝐵𝐵𝑠𝑧

𝑟𝑐𝑦𝑐 + 𝑏𝑟𝑝 + 𝑙1𝑐𝑦𝑐 + 𝑙2𝑐𝑦𝑐 + 𝑙3𝑐𝑦𝑐 + 𝑡𝑙1𝑐𝑦𝑐 + 𝑡𝑙2𝑐𝑦𝑐 + 𝑡𝑙3𝑐𝑦𝑐

il1cyc= 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑐𝑖𝑚𝑟 1

100 ∗ 𝑐𝑖𝑚𝑝1

Figura 9 Ecuación: IPC del Microprocesador

Figura 10 Ecuación: Ciclos I Cache N1

𝑖𝑙2𝑐𝑦𝑐 = 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑐𝑖𝑚𝑟2

100 ∗ 𝑐𝑖𝑚𝑝2




Cimr2 = Tasa de fallo de N2 ICache

Cimp2 = Penalidad de falla de N2 ICache


Su comportamiento se representa por la siguiente fórmula.


Cimr3 = Tasa de fallo de N3 ICache

Cimp3 = Penalidad de falla de N3 ICache

Ciclos D Cache N1: total de ciclos de ejecución de la DCache N1.

La ecuación que rige el valor de esta variable es la siguiente:


macc = % de acceso a memoria

cl1mr= Tasa de fallo de N1 DCache

cl1mp = Penalidad de falla de N1 DCache


Representada por la siguiente ecuación:

𝑖𝑙3𝑐𝑦𝑐 = 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑐𝑖𝑚𝑟3

100 ∗ 𝑐𝑖𝑚𝑝3

𝑙1𝑐𝑦𝑐 = 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑚𝑎𝑐𝑐

100 ∗

𝑐𝑙1𝑚𝑟

100 ∗ 𝑐𝑙1𝑚𝑝


Figura 13 Ecuación: Ciclos D Cache N1


100 ∗

𝑐𝑙2𝑚𝑟

100 ∗ 𝑐𝑙2𝑚𝑝








La cual sigue el siguiente comportamiento:





Ciclos ITLB N1: total de ciclos de ejecución de la ITLB N1.

Teniendo como ecuación para su cálculo la siguiente:


timr1 = Tasa de fallo de N1 I-TLB

timp1 = Penalidad de falla de N1 I-TLB



100 ∗

𝑐𝑙2𝑚𝑟

100 ∗ 𝑐𝑙2𝑚𝑝


𝑡𝑖𝑙1𝑐𝑦𝑐 = 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑡𝑖𝑚𝑟1

100 ∗ 𝑡𝑖𝑚𝑝1

Figura 16 Ecuación: Ciclos ITLB N1


100 ∗ 𝑡𝑖𝑚𝑝2










Ciclos DTLB N1: total de ciclos de ejecución de la DTLB N1.



tl1mr = Tasa de fallo de N1 D-TLB

tb1mp = Penalidad de falla de N1 D-TLB



100 ∗ 𝑡𝑖𝑚𝑝3

𝑡𝑙1𝑐𝑦𝑐 = 𝐷𝐵𝐵𝑠𝑧 ∗ 𝑚𝑎𝑐𝑐

100 ∗

𝑡𝑙1𝑚𝑟

100 ∗ 𝑡𝑏1𝑚𝑝


Figura 19 Ecuación: Ciclos DTLB N1


100 ∗

𝑡𝑙2𝑚𝑟

100 ∗ 𝑡𝑏2𝑚𝑝












2.3 Sistema validador de arquitecturas de microprocesadores

Para llevar a cabo la teoría expuesta anteriormente, es necesario el diseño y la implementación de una

herramienta de software que permita demostrar y ejecutar los cálculos matemáticos necesarios para

validar una arquitectura de microprocesador especifica. De esta manera se hace necesario utilizar una

técnica que facilite la especificación y el desarrollo de dicha aplicación, en este caso se utilizará la

metodología expuesta en el Apéndice C. El producto final de esta metodología será un ambiente

analítico genérico para apoyar la fase arquitectónica en el diseño de microprocesadores, lo que

corresponde a la descripción de los elementos comunes elaborados al final de aplicar el método. Debido

a que actualmente el servicio de Internet se ha hecho de gran dependencia al momento de desarrollar un

sistema de software se seguirá la metodología Watch extendido (para web).


100 ∗

𝑡𝑙2𝑚𝑟

100 ∗ 𝑡𝑏2𝑚𝑝


Capítulo 3 Desarrollo del Sistema

El sistema de software el cual fue llamado “Modelo Analítico” en su versión 1.0, es el objeto

fundamental de esta investigación, en el presente capitulo se presentan las actividades que se llevaron a cabo

para el diseño e implementación del mismo.

3.1 Modelo Analítico

El objetivo principal de este Proyecto de Grado es ofrecer un ambiente gráfico programado que

ofrezca al diseñador de microprocesadores especificar una arquitectura a evaluar, el mismo debe ser

implementado de una forma amistosa y genérica, permitiendo variar fácilmente los aspectos de la

arquitectura y obtener resultados de respuestas inmediatamente. Estos valores resultantes, finalmente,

indicarán las tendencias de los factores de evaluación seleccionados.

Al momento del desarrollo se tomaron en cuenta varios aspectos de gran importancia en la

actualidad como son la portabilidad y el aspecto didáctico de la aplicación, ya que el mismo deberá

servir de apoyo en la materia de arquitectura del computador del postgrado de computación de la

Universidad de los Andes, así como de su similar en pregrado.

El producto de software “Modelo Analítico” se desarrollo siguiendo las especificación de la

Metodología Watch (ver Apéndice C). En la presente sección se muestran las actividades de especificación,

diseño, implementación y validación del software, necesarias para generar el producto final presentado en

este proyecto.

Capítulo 3 Desarrollo del Sistema 35

3.1.1 Definición y Modelado del Negocio

Esta etapa como su nombre lo indica, es la etapa inicial del proceso de desarrollo de un producto de

software, en el cual se definen las características principales que regirán el mismo. Es en esta fase en la

que se obtiene un conocimiento global del dominio de la aplicación, ya que se determinan los objetivos,

procesos, actores, objetos y eventos que formarán parte de la aplicación.

Objetivo General:

Implementar un ambiente programado que apoye el diseño de un microprocesador de una forma

amistosa y genérica, utilizando un modelo analítico. Queriendo esto decir, variar fácilmente aspectos de

la arquitectura y obtener resultados de respuesta inmediatamente.

Objetivos Específicos

Desarrollar un producto de software multiplataforma y portable.

Apoyar a nivel didáctico la rama de arquitectura del computador del postgrado de computación

de la Universidad de los Andes, así como de su similar en pregrado.

Formar parte del grupo de ambientes necesarios para el diseño de circuitos integrados en

semiconductor del CEMISID.

Crear una interfaz de software agradable y de fácil manipulación.

Desarrollar un menú que le permita al usuario final del producto visualizar un documento de

especificación de uso de la aplicación (Manual de Usuario), el cual debe ser de fácil

entendimiento.

ACTORES

Cliente: en este caso el cliente será el Profesor Tutor de este Proyecto de Grado, el PhD.

Gerard Páez Monzón, el cual será la persona encargada de dar los parámetros y características

deseadas para la aplicación.


Usuarios: será todo aquella persona que desea hacer uso del “Modelo Analítico”, ya sean

profesores al momento de utilizar la aplicación de manera didáctica, o estudiantes como vía de

aprendizaje o analistas que hagan uso del mismo como apoyo al momento de realizar el diseño

de un microprocesador.

Desarrollador: Persona encargada de especificar, diseñar e implementar la aplicación que cumpla

con las expectativas planteadas por el cliente, en este caso dicho rol será cumplido por el Br.

Diego Armando Páez Martínez.

3.1.2 Definición de requisitos de software

Durante esta etapa se muestra la especificación de las necesidades demandadas por los usuarios, a partir

de la definición de sus requisitos.

3.1.2.1 Definición de requisitos según actores

De acuerdo a los actores involucrados en el sistema, se especifican los siguientes requisitos:

Cliente:

1) Permitir modificar y especificar fácilmente las variables que afectan la arquitectura de un

microprocesador.

2) Mostrar información didáctica de cada uno de las variables que afectan la arquitectura de un

microprocesador.

3) Permitir graficar el comportamiento de las variables con respecto al tiempo para asi observar

de una mejor manera como va siendo su rendimiento.

4) Crear una aplicación con una interfaz agradable a la vista e institucional.

5) Debe arrojar resultados inmediatos al momento de una simulación.


6) Tener el sistema tanto en español como en inglés.

Usuarios:

1) Crear un menú que permita mostrar el manual de usuario de la aplicación.

2) Crear una aplicación de fácil uso y entendimiento.

3) Usar colores que no resulten contrastantes ni muy llamativos.

4) Crear una interfaz de fácil navegación y sin complicaciones relevantes, haciéndola

suficientemente intuitiva para su utilización.

Desarrollador:

1) Llevar a cabo el desarrollo del software a través de un Modelo de Procesos de Software, a fin

de crear un producto de calidad.

2) Desarrollar el Modelo Analítico haciendo uso del lenguaje de programación JAVA (ver

sección 2.2.5), para animación de aplicaciones web.

3) Utilizar UML (ver sección 2.2.6) para especificar los componentes de desarrollo del

producto final.

4) Entregar la aplicación acompañada de un CD de instalación que permita instalar el sistema en

cualquier computador de forma rápida y eficaz.

5) Debe ser portable y multiplataforma, lo que implica que puede ser ejecutado bajo cualquier

ambiente operativo.


3.1.2.2 Clasificación de los requisitos y definición de sus prioridades

Los requisitos de una aplicación deben ser clasificados según su carácter funcional, se consideran

funcionales aquellos requisitos que proveen los servicios de la aplicación, a diferencia de los no

funcionales que reflejan las restricciones de los servicios o funciones ofrecidos por el sistema. Además

de esto se debe asignar una prioridad a cada uno de estos requisitos para así llevar a cabo la

programación de actividades al momento de implementar el código. A continuación se muestra dicha

clasificación. Los atributos pueden tener una prioridad de uno (1) para el valor más bajo y cinco (5) para

el valor más alto.

Requisito F/NF Tipo de Requisito Prioridad

Modificar y especificar fácilmente las variables que

afectan la arquitectura de un microprocesador.

F Funcionalidad 5

Mostrar información didáctica NF Atributo 3

Graficar el comportamiento de las variables con respecto al tiempo

NF Atributo 3

Interfaz agradable e institucional F Funcionalidad 4

Crear un menú que permita mostrar el manual de usuario de la aplicación

NF Atributo 3

Crear una aplicación de fácil uso y entendimiento

F Atributo 4

Crear una interfaz de fácil navegación y sin complicaciones relevantes, haciéndola suficientemente intuitiva para su utilización

NF Atributo 3

Soportes requeridos para el juego:

Recursos de hardware

Recursos de software

NF Ambiente Físico 5

Lenguaje en el cual se implementará o codificará el

juego

NF Ambiente Físico 4

Tiempo de respuesta NF Atributo 4

Entregar la aplicación acompañada de un CD de

instalación que permita instalar el sistema en

cualquier computador de forma rápida y eficaz.

NF Atributo 5

Portable y multiplataforma F Funcionalidad 5

Sistema en español e inglés NF Atributo 2 Figura 22 Clasificación de Requisitos del Sistema


3.1.3 Especificación de requisitos de software

Los requisitos anteriormente expuestos por los actores que influyen en el desarrollo de la aplicación son

expuestos en lenguaje natural, a continuación se explicara textualmente cada uno de ellos haciendo uso

de un lenguaje formal a fin de profundizarlos.

Permitir modificar y especificar fácilmente las variables que afectan la arquitectura de un

microprocesador: es la característica principal que debe tener el Modelo Analítico, ya que

de esta manera el diseñador tendrá la posibilidad de definir arquitecturas distintas de

microprocesadores con facilidad y rapidez.

Mostrar información didáctica de cada uno de las variables que afectan la arquitectura de un

microprocesador: debido a que el Modelo Analítico será utilizado didácticamente en la

materia de Arquitectura del Computador tanto de postgrado como de pregrado de la

carrera Ingeniería de Sistemas de la Universidad de loa Andes, el mismo debe presentar

información conceptual de las variables que existen en el validador. Lo mismo se

realizará creando botones de acción que levanten una ventana de información que

presente el concepto al cual se está accediendo.

Permitir graficar el comportamiento de las variables con respecto al tiempo: para poder observar

el rendimiento de las variables de la arquitectura se crea esta herramienta gráfica, que

permitirá observar el cambio de una variable específica con respecto al tiempo. Lo

mismo se realizará levantando una ventana en la que se observara dicho gráfico,

habiendo seleccionado previamente la variable que se desea observar, así mismo como

el rango y salto que se desea.

Crear una aplicación con una interfaz agradable a la vista e institucional: al momento del

diseño de la interfaz se debe tener en cuenta este aspecto, ya que los usuarios de la

mismas serán profesores, estudiantes y personas asociadas a la rama de la investigación;

lo que implica hacer un uso de colores adecuados, así como una estructura adecuada de

botones, paneles y secciones que conformen el sistema.


Arrojar resultados inmediatos al momento de una simulación: gracias a las ecuaciones

matemáticas que rigen el comportamiento de un microprocesador se puede obtener

esta característica, ya que los cálculos y resultados se obtendrán de forma casi

inmediata.

Crear un menú que permita mostrar el manual de usuario de la aplicación: para lograr esto se

creará un simple menú en la barra de herramientas, la cual será capaz de levantar una

ventana en la que se muestre un pequeño manual de usuario que especifique las

características que proporcionará la aplicación.

Usar colores que no resulten contrastantes ni muy llamativos: El color predominante dentro

de la interfaz ha de ser adecuado a fin de no provocar fatiga en el usuario ya que el

mismo deberá concentrar su mirada en la aplicación por un tiempo considerable.

Crear una interfaz de fácil navegación y sin complicaciones relevantes, haciéndola

suficientemente intuitiva para su utilización: la aplicación debe presentar un carácter

intuitivo para la interacción directa del usuario con la misma, haciendo obvias sus

utilidades y secciones.

Llevar a cabo el desarrollo del software a través de un Modelo de Procesos de Software, a fin de

crear un producto de calidad: Se requerirá hacer uso de una metodología de desarrollo de

aplicaciones, en este caso como ya se ha dicho anteriormente se utilizará el modelados

Watch (ver Apéndice C) como marco de referencia para la creación de la aplicación.

Desarrollar el Modelo Analítico haciendo uso del lenguaje de programación JAVA (ver

Apéndice A), para animación de aplicaciones web: se realizará en dicho lenguaje para

aprovechar al máximo sus características en gráficos 2D y de cálculos cíclicos.


Utilizar UML (ver Apéndice B) para especificar los componentes de desarrollo del producto final:

para la especificación de los componentes de la aplicación se hará uso del Unified

Modeling Language (UML), y de esta manera documentar plenamente el diseño,

desarrollo e implementación de esta aplicación.

Entregar la aplicación acompañada de un CD de instalación: el mismo permitirá realizar la

instalación de la aplicación en cualquier computador de forma rápida y eficaz,

permitiendo esto la portabilidad del mismo.

Debe ser portable y multiplataforma, lo que implica que puede ser ejecutado bajo cualquier

ambiente operativo: este último requisito se obtendrá, como ya se indico anteriormente,

gracias a la implementación de la aplicación en el Lenguaje de programación

multiplataforma JAVA, dándole de esta manera la posibilidad de ser ejecutado en el

ambiente operativo que se desee, siempre y cuando se tenga la versión indicada de la

maquina virtual de Java (JVM).

Sistema en español e inglés: debido a que los términos utilizados en el argot del área de los

microprocesadores en su mayoría son mayormente conocidos en su término en inglés,

se presentará este atributo extra, para así permitir que el usuario tenga la posibilidad de

trabajar en el idioma de su preferencia.

3.1.3.1 Modelo de Casos de Uso

Los casos de uso son una técnica para la captura de requisitos potenciales de un nuevo sistema. Cada

caso de uso proporciona uno o más escenarios que indicaran cómo debería interactuar el sistema con el

usuario o con otro sistema para conseguir un objetivo específico, en esta sección se exponen los casos de

uso de la aplicación, además de la descripción relacionada con cada uno de ellos y los diagramas

correspondientes en UML.

a) Caso de uso General:


Función: Mostrar al usuario las opciones principales del sistema.

Descripción: Permite al usuario hacer uso de las funciones del sistema de software. Al

momento de iniciar el sistema, el usuario, estará en la capacidad de ingresar unos nuevos

valores de arquitectura, de salir del sistema o de visualizar el manual de usuario. Una vez haya

ingresado el diseño deseado deberá presionar el botón de aceptación, lo que le dará la

posibilidad de correr el sistema o de graficar una variable deseada.

Figura 23 Caso de Uso: General

b) Caso de Uso Ver Manual de Usuario:

Función: Mostrar el Manual de Usuario del sistema.

Descripción: esta función le mostrara al usuario el manual de usuario del Modelo Analítico,

los pasos que debe seguir para su correcto funcionamiento, así mismo como recomendaciones

de uso.


Figura 24 Caso de Uso: Ver Manual de Usuario

c) Caso de Uso Introducir Arquitectura:

Función: Permitir ingresar una nueva arquitectura de microprocesador.

Descripción: esta función le dará al usuario la posibilidad de ingresar y variar una arquitectura

de microprocesador de forma fácil y sencilla. El mismo sólo debe ubicarse en la casilla de la

variable que desee modificar y cambiarla a su gusto.

Figura 25 Caso de Uso: Introducir Arquitectura


d) Caso de Uso Leer Variables:

Función: Leer la arquitectura ingresada por el usuario.

Descripción: al momento de ejecutarse este comando, el sistema automáticamente realizará

una lectura de la arquitectura ingresada y colocara los espacios de resultados en blanco. Una vez

realizado esto el sistema estará preparado, ya sea para realizar una simulación o para graficar

una variable deseada.

Figura 26 Caso de Uso: Leer Variables

e) Caso de Uso Correr Arquitectura:

Función: Calcular los resultados dada una arquitectura

Descripción: una vez leída una arquitectura se ejecuta la misma, aquí empieza el proceso de

cálculo de resultados por medio de las ecuaciones que rigen el comportamiento de un

microprocesador. Una vez terminado el proceso de iteración de dichas ecuaciones se presentan

en el modulo de resultados del sistema.


Figura 27 Caso de Uso: Correr Arquitectura

f) Caso de Uso Graficar:

Función: Calcular los resultados dada una arquitectura

Descripción: una vez leída una arquitectura se ejecuta la misma, aquí empieza el proceso de

cálculo de resultados por medio de las ecuaciones que rigen el comportamiento de un


microprocesador. Una vez terminado el proceso de iteración de dichas ecuaciones se presentan

en el módulo de resultados del sistema.

Figura 28 Caso de Uso: Graficar

g) Caso de Uso Salir:

Función: permite salir de la aplicación

Descripción: esta función permite cerrar el sistema, haciendo primero un respaldo de los

resultados obtenidos, guardándolos en un archivo de salida.


Figura 29 Caso de Uso: Salir

3.1.3.2 Modelo de Diagrama de Secuencia

Los diagramas de secuencia muestran la interacción de un conjunto de objetos en una aplicación a

través del tiempo, los mismos contienen detalles de implementación del escenario, incluyendo los

objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. A

continuación se presenta los dos diagramas principales de la aplicación como son el diagrama de

secuencia general o principal, y el diagrama de secuencia de correr una arquitectura.


a) Diagrama de Secuencia General:

Figura 30 Diagrama de Secuencia General

b) Diagrama de Secuencia Correr Arquitectura

Figura 31 Diagrama de Secuencia Correr Arquitectura

Modelo Analitico AnaSim Archivo entrada Archivo SalidaDataFileErrorDialog ErrorDialog

1 : Leer_Archivo()

2 : respuesta()

3 : Mensaje_error()

4 : Comprobar_consistencia()

5 : Consistencia()

6 : Simular()

7 : Mensaje_error()

8 : Guardar_info()

9 : respuesta()

10 : Mostrar_resultados()


3.1.4 Diseño del Producto de Software

El diseño arquitectural del software tiene la responsabilidad de establecer el conjunto de patrones y

abstracciones coherentes que permitan proporcionar el marco de referencia necesario para guiar la

implementación del sistema.

El estilo arquitectónico del Modelo Analítico, se presenta en un modelo de arquitectura en tres

capas, la primera, la capa de presentación, en la que se presenta la interfaz del sistema y permite la

interacción del usuario con los contenidos de la aplicación. La segunda capa, corresponde a la capa

lógica, en ella se centra el procesamiento de la información y la ejecución de las actividades necesarias

para poner en marcha el sistema. La tercera y última capa, es la capa de datos, en ella se ubica la

información correspondiente a archivos de contenido multimedia e información textual en general.

3.1.4.1 Estructura de la aplicación

Según la distribución del sistema de software en tres capas, se demuestra la división de las mismas, en la

siguiente figura:

Figura 32 Arquitectura de la Aplicación


3.1.4.2 Modelo de Despliegue-Estructura de Nodos

El modelo de despliegue permite señalar los recursos de hardware requeridos, así como la implantación

del sistema en dichos recursos. El Modelo Analítico, requiere del uso de tres nodos, los cuales son: el

ambiente operativo, la maquina virtual de Java (JVM), y la aplicación como tal donde se encuentran los

componentes que integran el sistema.

Figura 33 Estructura de Nodos

3.1.4.3 Diseño Interfaz

En el contexto del proceso de interacción persona - computador, la interfaz gráfica de usuario es el

artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del

lenguaje visual, una interacción amigable con un sistema informático. Generalmente la interfaz de

usuario utiliza un conjunto de imágenes y objetos gráficos para representar la información y acciones

disponibles del sistema.

En este caso, la interfaz grafica de la aplicación se diseño pensando principalmente en los

usuarios finales del sistema. Debido a que estas personas están plenamente ligadas al área

computacional, se pudo crear una interfaz que presenta directamente las variables que pueden ser


modificadas y las opciones de ejecución del software. Además de este factor, se tomo en cuenta la

funcionalidad deseada por el cliente de que la arquitectura especificada sea visible junto con los

resultados de la simulación, es por esta razón que dichos datos o variables se encuentran reflejados en la

misma ventana.

En conclusión el sistema de software Modelo Analítico, cuenta con una sola ventana principal

de interfaz, el resto de las ventanas existentes en el sistema son: “Mensajes de Errores”, ventana de

“Gráficos”, ventana de “Manual de Usuario”, y la ventana “Acerca de”.

Por último, al momento de escoger los colores que predominarían la aplicación, se realizó una

selección de contrastes muy sutiles que proporcionan un impacto visual leve al usuario, manteniendo a

su vez una imagen institucional que represente a la Universidad de Los Andes.

Figura 34 Diseño de la Interfaz


3.1.4.4 Diseño de Pantallas

A continuación se presentan cada una de las pantallas de visualización de la aplicación.

Pantalla Principal: la siguiente imagen muestra nuevamente la pantalla principal de la aplicación,

las figuras que le siguen muestran cada una de las secciones en las que se divide dicha vista.

Figura 35 Pantalla Principal

- Memoria de Instrucciones

Figura 36 Módulo de Memoria de Instrucciones


- Memoria de datos

Figura 37 Módulo de Memoria de Datos

- Micro-Arquitectura:

Figura 38 Modulo de Micro-Arquitectura


- Caracterización del Código

Figura 39 Modulo de Caracterización del Código

- Configuración de archivos y gráficos

Figura 40 Módulo de Configuración de archivos y gráficos

- Resultados

Figura 41 Módulo de Resultados

Pantalla Acerca de: en esta pantalla se muestra la información básica del sistema, como

es: su titulo, autor, tutor, versión entre otras informaciones.


Figura 42 Pantalla Acerca de

Pantalla de gráficos: la siguiente figura muestra un ejemplo de gráfico generado por la

aplicación.

Figura 43 Pantalla de Gráficos


Pantalla de información: las pantallas de información muestran teorías varias de cada una

de las variables que forman parte del sistema. A continuación se muestra un ejemplo

de la misma.

Figura 44 Pantalla de Información

Pantallas de Errores: en la aplicación Modelo Analítico, existen varios casos en que el

usuario puede caer en errores de ejecución, por lo que se hace necesario crear

ventanas que le muestren el error que está cometiendo y alguna sugerencia.

Figura 45 Pantalla Mensaje de Error de Gráfico

Figura 46 Pantalla Mensaje de Archivo no disponible


Figura 47 Ventana Error de validación de la Arquitectura ingresada

Figura 48 Ventana de Mensaje de error de selección de parámetro de gráfico

3.1.5 Implementación y Pruebas

El proceso de implementación se llevó a cabo integrando los componentes de cada una de las capas de la

arquitectura de la aplicación, con la finalidad de lograr el producto final y un correcto funcionamiento

del mismo. Esta implementación se llevó a cabo en este caso sobre las herramientas computacionales

escogidas para ello, y la programación necesaria para llegar a los objetivos definidos en las etapas de

diseño y especificación detalladas con antelación a esta sección.

La fase de pruebas de la aplicación se relacionó con la realización de pruebas de

funcionamiento, comportamiento y aceptación por parte de los usuarios del sistema y los clientes,

fundamentalmente, se realizó una medición de logros y de calidad del producto resultante, contando

con la aceptación satisfactoria del cliente.


3.2 Archivo Caracterizador (PROFILER)

Para el correcto funcionamiento del sistema, y para llevar a cabo la simulación de un microprocesador

utilizando un Modelo Analítico se necesita alimentar al sistema con un archivo que haga las veces de un

archivo caracterizador. El cual no es más que un archivo que contenga la información respectiva de un

programa que puede ser ejecutado.

Para definir dicho archivo, se deben tener en cuenta las siguientes definiciones:

RAW - Read After Write

Una dependencia RAW hace referencia a una situación donde se necesita un dato que

aún no ha sido calculado, por ejemplo:

i1. R2 R1 + R3

i2. R4 R2 + R3

La primera instrucción calcula un valor que será guardado en el registro R2, mientras

que la segunda necesita este valor para computarlo y almacenar el resultado en el registro R4.

Sin embargo, en un procesador segmentado, cuando se capturan los operandos para realizar la

segunda instrucción, los resultados de la primera aún no han sido guardados, de forma que

aparece una dependencia de datos.

Se dice que existe una dependencia de datos en la instrucción 2, la cual depende de la

finalización de la instrucción 1.

WAR - Write After Read

Una dependencia WAR representa un problema de ejecución concurrente, por

ejemplo:


i1. r1 r2 + r3

i2. r3 r4 x r5

Si por alguna razón la instrucción 2 puede finalizar antes de que lo haga la 1 (por

ejemplo, en ejecución concurrente), es necesario asegurarse de que no se almacenará el

resultado en el registro R3 antes de que la instrucción 1 haya podido leer sus operandos.

WAW - Write After Write

Una dependencia WAW es otra de las posibles situaciones problemáticas en un

entorno de ejecución concurrente, por ejemplo:

i1. r2 <- r1 + r3

i2. r2 <- r4 x r7

En este caso debe retrasarse la escritura (etapa WB) de la instrucción 2 hasta que la

instrucción 1 haya finalizado.

Una vez conocidos estos conceptos se puede realizar la especificación del archivo caracterizador. El

archivo debe contener la siguiente estructura de manera inequívoca para garantizar la ejecución del

sistema. Los pasos a seguir son los siguientes:

1. La primera línea debe ser una línea en blanco, es decir que debe existir un salto de

línea (ENTER).

2. La siguiente línea debe contener la siguiente frase, seguido del número de instrucciones

que va a manejar el programa.

Total instructions: 50000

3. Las dos siguiente líneas debe ser una línea en blanco, es decir que debe existir un salto

de línea (ENTER).

4. Las dos siguientes líneas deben ser una fiel copia de lo siguiente, esto solo para mostrar

un orden en la presentación del archivo.


Register dependencies

---------------------

5. Las dos siguiente líneas debe ser una línea en blanco, es decir que debe existir un salto

de línea (ENTER).

6. Luego se debe escribir la siguiente línea, en la cual se escriben los rótulos de las

dependencias existentes.

Dist. RAW % WAW % WAR % Total %

7. La siguiente línea debe ser una línea en blanco, es decir que debe existir un salto de

línea (ENTER).

8. En esta línea y en las subsiguientes se llevara a cabo la distribución de datos que se

desea para las pruebas, tomando en cuenta las diferentes distancias entre instrucciones

que pueden existir entre las dependencias, todo esto empezando desde la distancia uno

(1), e incrementando de ahí en adelante hasta el valor que se desee. Siempre teniendo

en cuenta que se debe conservar la alineación con los rótulos de la tabla. Estos valores

serán calculados de la siguiente forma, el cálculo se realizará para una dependencia de

distancia 1.

Se definen el número de instrucciones que presentan dependencias de RAW,

WAW y WAR, por ejemplo, 6621, 5826, 3699, respectivamente. Luego de

realizar dicha definición se calcula el porcentaje que representan dichas

cantidades con respecto al número total de instrucciones. Por último se realiza

la suma de dichas cantidades para ser expresadas en la columna de Total. Se

debe realizar este procedimiento las veces que se desee dependiendo de la

distancia que se tenga en cuenta.

9. A continuación se debe colocar la siguiente frase, la cual representará el final del

archivo.

End of Results

10. Por último se debe guardar el archivo y ser colocado en la misma carpeta donde se esta

ejecutando el programa.

A continuación se presenta un ejemplo de un archivo caracterizador de entrada al sistema Modelo

Analítico.


3.3 Archivo de Salida

Al momento de realizar la ejecución de una arquitectura modelada, el sistema arrojará varios resultados

de interés, los cuales en algún momento pueden ser utilizados por el usuario para documentación u

algún otro interés personal. Es por ello que se hace necesario que el sistema este en la capacidad de

almacenar dichos resultados en un archivo de texto. A continuación se muestra como sería una salida

típica de dicho archivo.

Total instructions: 50000

Register dependencies

---------------------

Dist. RAW % WAW % WAR % Total %

1 6621 13.24 5826 11.65 3699 7.40 16146 32.29

2 4689 9.38 5382 10.76 3782 7.56 13853 27.71

3 3875 7.75 4353 8.71 3340 6.68 11568 23.14

4 3233 6.47 4522 9.04 2978 5.96 10733 21.47

5 2837 5.67 5620 11.24 2955 5.91 11412 22.83

6 3216 6.43 5036 10.07 3083 6.17 11335 22.67

7 3547 7.09 4685 9.37 3011 6.02 11243 22.49

8 2564 5.13 5215 10.43 2962 5.92 10741 21.49

9 3334 6.67 5417 10.84 3151 6.30 11902 23.81

10 3436 6.87 7387 14.78 3385 6.77 14208 28.42

11 3774 7.55 3789 7.58 3861 7.72 11424 22.85

12 3176 6.35 5030 10.06 2627 5.26 10833 21.67

13 2474 4.95 3924 7.85 2998 6.00 9396 18.80

14 3234 6.47 4969 9.94 2553 5.11 10756 21.52

15 2559 5.12 4948 9.90 2542 5.09 10049 20.10

16 2693 5.39 4491 8.98 3118 6.24 10302 20.61

17 2849 5.70 3804 7.61 2760 5.52 9413 18.83

18 2200 4.40 4421 8.85 2779 5.56 9400 18.81

19 3219 6.44 4129 8.26 2863 5.73 10211 20.43

20 2770 5.54 5226 10.46 2792 5.59 10788 21.58

21 2770 5.54 4049 8.10 3108 6.22 9927 19.86

22 2552 5.11 3970 7.94 2107 4.22 8629 17.27

23 2294 4.59 3900 7.80 2332 4.67 8526 17.06

End of Results

Figura 49 Ejemplo archivo de entrada al sistema


IMPRIMIENDO CONFIGURACIONES Y RESULTADOS

***************

CONFIGURACIONES

***************

L1 ICache Miss Ratio = 0.5

L1 ICache Miss Penalty = 4.0

L2 ICache Miss Ratio = 0.0

L2 ICache Miss Penalty = 20.0

I-Cache Line Size = 32.0

Number of Bytes per Instruction =2.2

Number of micro-ops per Instruction =1.3

Cycles per fetch = 2.0

Basic Block Size = 6.0

Branch Miss Probability = 20.0

Branch Taken Penalty = 12.0

Number of Stages = 1.0

Size of Instruction Queue = 5.0

OOO/IO = 0.0

Functional Units = 2.0

L1 Cache Miss Ratio = 5.0

L1 Cache Miss Penalty = 4.0

% of Memory Access = 52.0

% of L1 Miss Penalty for OOO = 0.0

L1 Access cycles = 2.0



% of L2 Miss Penalty for OOO = 0.0



% of Load Access = 30.0

***************

RESULTADOS

***************

NIPC = 2.124

DBBSZ = 30.0

Run-cycles = 23.600

L1-cycles = 3.120

L2-cycles = 14.040

L3-cycles = 0.000

Running-ipc = 1.271

BIPC = 0.843

MIPC = 0.569

*************************************************

Figura 50 Ejemplo Archivo de Salida

Capítulo 4 Conclusiones

Esta tesis es la primera herramienta desarrollada en el proceso de reconstrucción de un ambiente

académico y profesional para el estudio, desarrollo e investigación en el campo del diseño de

computadores y circuitos integrados. Este modelo analítico permitirá entonces desde el CEMISID hacer

tomas de decisiones organizacionales de las microarquitecturas dentro del espacio de diseño en un

sistema de procesamiento computacional en cortos tiempos. Es ya bien señalado, que un modelo

analítico debe ser tomado con suma precaución y en especial con conocimientos de causa de los

resultados que ofrecerá según los cambios de parámetros explicados en el Capítulo 3 de esta tesis. Una

vertiente fundamental en el desarrollo de este modelo analítico, es el gran valor académico que aportará

al aprendizaje y formación a los estudiantes y profesores que estudian el campo de las arquitecturas de

computadores de una forma práctica y real.

Esta herramienta, como todo producto, requerirá de un proceso constante de alineación para

lograr una mayor precisión en sus valores de resultado según las ecuaciones actuales (experiencia y

conocimiento del Dr. Gerard Páez Monzón) , o nuevos aspectos a integrar en el modelo, o nuevas ideas

de arquitectura, etc. Este Modelo Analítico que trata de cubrir los aspectos de la arquitectura de un

microprocesador, deberá ir creciendo con la evolución del CEMISID en el desarrollo de modelos

analíticos en aspectos como Multi-CPUs, o en Sistemas-en-un-Integrado (System-on-a-Chip-SoC) que

sus naturalezas organizacionales escapan del actual de esta tesis. Así como también, en modelos

analíticos detallados de bloques funcionales que componen nuestro modelo, i.e. La Jerarquía de

Memoria.

.

En el proceso tecnológico del diseño de circuitos integrados de microprocesadores, la fase de

arquitectura exige una evaluación profunda y a un ritmo de evolución tecnológica y mercadeo que

herramientas como un modelo analítico cumple una tarea de apoyo en su desarrollo. El objetivo

señalado de la fase de arquitectura debe ser apoyada por herramientas de mayor confianza en las tomas

Capítulo 4 Conclusiones 64

de decisiones para el diseño de un microprocesador. Para esto debemos ahora iniciar el desarrollo de

modelos mas precisos en sus resultados pero más lentos para obtener los resultados de salidas que se

buscan, tanto en funcionalidad como en el análisis de prestaciones del microprocesador. La profundidad

de especificación de los diferentes detalles en el diseño se usaran lenguajes tecnológicos como el

SystemC o lenguajes de programación como el “C” o “C++”. Estos modelo son simuladores de

ejecución con la tendencia como objetivo de tener una precisión a reloj. Cada transferencia lógica de

registro del diseño será simulada al ciclo de reloj. También en el seno del CEMISID, contamos ya con

algunas herramientas desarrolladas en otros centros universitarios ó compañías que nos harán recortar el

camino de responsabilidad en la reconstrucción del ambiente de diseño de circuitos integrados, i.e.

SoClib, Corialis (LIP6-Paris 6), tarjetas de FPGA (Digilent Inc/Xilinx), etc.

Un aspecto importante que continuara en el desarrollo a esta tesis, es la creación de una

herramienta programada que nos permita caracterizar un programa. La caracterización a la que nos

referimos es poder generar un conjunto de valores que dibujen la ejecución genérica de un programa en

base a distinguir los siguientes aspectos: a) total de instrucciones del programa, b) total de instrucciones

ejecutadas del programa, c) Porcentajes de instrucciones Aritméticas, Punto Flotante, Lectura de

Memoria, Escritura de Memoria, Entrada y Salida, Saltos incondicionales, Saltos condicionales, etc., d)

Porcentajes en las diferentes precisiones de datos, e) promedios de bytes de las instrucciones, f)

promedios de bloques básicos, etc. Seguirán otros modelos de caracterización como la detección de

“hot-spots” en los programas, ejecuciones vectoriales/matriciales, tamaño de lazos de ejecución en

código y en número de iteraciones, etc. Estas herramientas alimentarán el actual Modelo Analítico con

valores de mayor precisión, y así obtener valores más confiables en la orientación del diseño evaluado y

resultados per se del Modelo Analítico. La ventana de salida presenta esta oferta de valores

caracterizados, aunque el código caracterizador se debe desarrollar.

En el futuro, se debe desarrollar como apoyo estructural a este Modelo Analítico y a los otros

modelos mencionados arriba, una plataforma de hardware que permita capturar trazas de ejecución de

programas reales. Esta ejecución en caliente de un programa, luego seria caracterizada como datos de

entrada a los modelos, además de ser utilizada en los simuladores como objetivo principal de una

evaluación de prestación más real del mundo de las aplicaciones y su ejecución en el microprocesador

Capítulo 4 Conclusiones 65

en desarrollo. Estos resultados ofrecen una mayor confianza en las tomas de decisiones de las funciones

digitales a seleccionar de todo el espacio de diseño.

Por último, se puede certificar en este esfuerzo que hemos podido transferir una herramienta

tecnológica de gran valor y que el Modelo Analítico implementa correctamente una pieza de trabajo

fundamental en el diseño de circuitos integrados de microprocesadores.

APENDICE A: Java

Lenguaje de programación conocido en los círculos profesionales como OAK desde 1991 y en 1995

dado a conocer como JAVA. Es un lenguaje de programación orientado a objeto desarrollado por la

empresa Sun Microsystems que se utiliza para crear aplicaciones en Internet. Su origen es anterior a

Internet cuando se trataba de conseguir un lenguaje multitarea, seguro y que fuera capaz de ejecutar el

código desde diferentes plataformas (Mac, PC, Amiga, UNIX, etc.) (OLARTE). Ha despertado gran

interés por la posibilidad de integrar multimedia, convirtiéndose en un lenguaje fundamental para el

desarrollo de Internet.

Figura 51 Logo Java

Figura 52 Duke, la mascota de Java

Apéndice A: Java 67

El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más

simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la

manipulación directa de punteros o memoria. La implementación original y de referencia del

compilador, la máquina virtual y las librerías de clases de Java fueron desarrolladas por Sun

Microsystems en 1995. Desde entonces, Sun ha controlado las especificaciones, el desarrollo y

evolución del lenguaje a través del Java Community Process (Harvey M. Deitel, 2004).

El lenguaje Java fue creado desde sus inicios buscando cumplir con las siguientes filosofías

(Wikipedia, La enciclopedia Libre):

1. Usar la metodología de la programación orientada a objetos.

2. Permitir la ejecución de un mismo programa en múltiples sistemas operativos.

3. Incluir por defecto soporte para trabajo en red.

4. Diseñarse para ejecutar código en sistemas remotos de forma segura.

5. Ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos, como C++.

De estas características se puede decir que la que más ventajas aporta a este lenguaje de

programación es la posibilidad de que un mismo programa pueda ser ejecutado en distintos sistemas

operativos, esto siguiendo una de sus más conocidas frases: “Escríbalo una vez, úselo donde quiera”. Por

esta razón se ha escogido a Java para llevar a cabo la implementación de este sistema, así de esta manera

conseguir que el producto de software final sea multiplataforma y totalmente portable.

APENDICE B: UML

UML (por sus siglas en inglés Unified Modeling Language), es un conjunto de herramientas que

permiten el modelado de sistemas orientados a objetos. Es el lenguaje de modelado de sistemas de

software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management

Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML

ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales

tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de

lenguajes de programación, esquemas de bases de datos y componentes reutilizables. En la actualidad

UML, está considerado como el lenguaje estándar en el análisis y diseño de sistemas de cómputo.

Mediante este lenguaje se presenta la posibilidad de establecer requerimientos y estructuras necesarias

al momento de crear un sistema de software, colaborando previamente con el proceso intensivo de la

programación codificada.

Así como al momento de crear una red eléctrica se necesitan los planos estructurales de la misma

para poder llevara a cabo, el desarrollo de sistemas de software, cuenta con el diseño en UML previo a

la codificación, empleando para ello características visuales que permiten la participación y

comunicación entre los que integran el proceso de desarrollo del sistema.

Los diagramas empleados por UML son:

Diagramas de caso de uso

Diagrama de clases

Diagrama de actividades

Diagrama de interacción

Diagrama de estado.

APENDICE C: Metodología Watch

El enfoque de desarrollo a emplear durante la elaboración de este proyecto será el Modelo de Procesos

“WATCH” (RELOJ), el cual fue un modelo propuesto por (Montilba & Barrios, 2003). Dicho modelo

sigue los pasos que se observan en la Figura 53 Método Watch.

Figura 53 Método Watch

Análisis del Dominio: Obtención de un conocimiento global del dominio de la

aplicación empresarial, del sistema de negocio para el que se desarrolla la aplicación.

Procesos gerenciales

Modelado de negocio

Definición y especificación de requisitos

Diseño arquitectural de

la aplicación

Especificación de

componentes

Aprovisiona-miento de los componentes

Ensamble de los componentes

Prueba de la aplicación web

Entrega de la aplicación

Procesos de post desarrollo

Apéndice C: Metodología Watch 70

Determinación de Requisitos: Determinación de las necesidades de los usuarios de la

aplicación empresarial en desarrollo, especificando y definiendo sus requisitos.

Análisis y Especificación de Requisitos: especificación en detalle de las funciones y servicios que el sistema está en capacidad de prestar.

Diseño del Sistema: en esta etapa del desarrollo se define la estructura de cómo se presentará la arquitectura del software.

Diseño de Componentes: Durante esta fase del modelado de procesos, se deberá implementar el diseño de cada una de las partes que conformarán la aplicación. en este caso diseño del código fuente, para ello diseño de los objetos, clases y mecanismos a implementar de orientación a objetos, diseño de interfaz, colores, animaciones, iconos, ventanas, diseño del manejo de archivos.

Construcción del Sistema: Se codifican todos y cada uno de los componentes, en esta fase, además de crearse los archivos de datos, en añadidura, se realizan pruebas individuales de los componentes y otras pruebas de integración de los mismos.

Pruebas de Sistema: Se aplican pruebas de funcionamiento del sistema, pruebas de rendimiento del software y finalmente, pruebas de aceptación por parte del cliente.

Entrega del Sistema: El equipo se encarga de la instalación del sistema de software, de comprobar que se ejecute perfectamente, y de la distribución de la documentación del mismo.

El proceso para solicitar un servicio web se produce cuando un usuario realiza una petición a

través de un navegador, el usuario interactúa con el sistema introduciendo y obteniendo información,

esto se hace a través de funciones o servicios que provee un servidor de aplicaciones conjuntamente con

el servidor web.

Se observa que la arquitectura que se utiliza comúnmente para servicios web es la arquitectura

de n-capas, en este caso está definido en tres capas, la primera la capa de presentación que es aquella

con la cual el usuario interactúa, la capa intermedia o de lógica de negocios, que corresponde a la capa

donde se encuentran las aplicaciones web, y por último la capa donde son guardados los datos de las

aplicaciones.


Capa de Presentación

Esta capa es responsable de la interacción con los usuarios, así mismo se encarga de capturar los datos

introducidos por los usuarios y el manejo de los diálogos a los usuarios. Esta capa comprende dos tipos

de componentes:

Componentes del lado del Cliente: señala los componentes de la aplicación web que van a

ser desplegados en las máquinas de los usuarios. Los mismos se ejecutan en la

máquina del cliente y permiten interacción con la lógica del negocio.

Los componentes del Servidor Web: son los que se ejecutan del lado del servidor web

enviando las respuestas de las solicitudes de páginas y de datos a la capa de lógica del

negocio.

Figura 54 Arquitectura de 3 capas


Capa de lógica de negocios

Esta capa representa el enlace entre la interfaz del usuario y el sistema en sí, generalmente son

componentes compilados los cuales corren en un servidor de aplicaciones. Esta está dividida en dos

capas:

Componentes del proceso de negocios: se encarga de llevar a cabo las transacciones

requeridas por los usuarios a través de la interfaz.

Componentes de entidades de negocios: son los relacionados con la persistencia del

dominio que deben ser almacenados.

Capa de datos

Corresponden al medio de almacenamiento donde las entidades de negocios son almacenadas. Esto

pueden ser Bases de Datos, archivos de texto, XML o bases de datos que manejan XML.

Modelo de Procesos

Para representar el Modelo de Procesos WATCH se utiliza una metáfora de un reloj de manecillas, esto

debido a que el desarrollo de una aplicación puede ser vista como un reloj el cual va avanzando en

sentido a las agujas de dicho reloj. El mismo puede ser controlado por el líder del proyecto, el cual es el

encargado de decidirse cuando se avanza a una nueva fase o cuando es necesario ir atrás para mejorar o

revisar un producto. Los números representan las fases y el orden en el cual esas fases deben ser

ejecutadas.

El proceso de desarrollo esta divido en dos:

Los procesos gerenciales: enmarcan las actividades relacionadas con los procesos de

manejo del proyecto, asegurar la calidad de la aplicación, manejo de cambios y

riesgos, adiestramiento del personal.


Los procesos de desarrollo: corresponde a las actividades técnicas que son necesarias para

modelar el dominio de aplicación, descubrir y especificar los requerimientos,

diseñar, codificar, probar y entregar la aplicación.

Modelado de Negocios

Representa la primera fase del proceso de desarrollo de aplicaciones dentro de la metodología Watch,

es la encargada de identificar y describir el dominio de negocios en el que se enmarca la aplicación web,

en dicha fase se definen los procesos estáticos y dinámicos que se relacionan con la aplicación así como

se define el vocabulario que sirve para aclarar los términos y acrónimos que se emplearán durante el

desarrollo de la aplicación. Es la etapa en la que se define el líder del proyecto y un representante de los

usuarios a fin de proveer la información necesaria acerca del dominio de la aplicación.

Definición y Especificación de Requisitos

Es en ésta fase en la que se define y especifica los requerimientos funcionales y no funcionales de la

mejor manera posible, la participación de los representantes de usuarios es imprescindible en esta fase,

ya que son quienes sirven de puente entre los usuarios y los desarrolladores del sistema.

Definición del Alcance del

Dominio

Definición del Modelo de

Negocios

Definición del Vocabulario

del dominio

Figura 55 Etapas del Modelado del Negocios


En esta etapa se realiza la elaboración de dos documentos, uno con contenido informal en

lenguaje natural, que resume los servicios que debe proveer la aplicación, el estrés y velocidad a la que

puede estar sometida la aplicación (requisitos funcionales y no funcionales respectivamente), y otro más

formal que permite el uso de lenguajes formales o semiformales, a fin de representar el modelo

funcional, estructural y dinámico del sistema, para ser entendido por el o los desarrollador(es).

Diseño de la Aplicación

Es la fase en la cual se presenta una solución a los anteriores documentos de definición de requisitos, en

ella se describe la arquitectura de la aplicación, la interfaz de usuario y las bases de datos a ser utilizadas.

Descubrir los Requisitos

Especificar los Requisitos

Figura 56 Etapas Definición y especificación de requisitos


Figura 57 Diseño de la Aplicación

En esta etapa, se cumplen los aspectos de diseño de acuerdo a los componentes de una aplicación), las

actividades se resumen de la siguiente manera:

Diseño de la interfaz de usuario: Se definen los aspectos relacionados con la capa de presentación,

el diseño, navegación, presentación y estilo.

Diseño de la arquitectura del sistema: Se define en ésta actividad la capa lógica de negocio, los

componentes y sus responsabilidades, las interfaces y la interacción entre los componentes, la

localización de recursos físicos, la coordinación de componentes, los componentes en tiempo

de ejecución.

Diseño de la base de datos: Durante el desarrollo de esta actividad se define la estructura y el

contenido de la base de datos que se asocia a los componentes.


Especificación de los Componente

Es la fase en la que se especifican los componentes y las interacciones entre ellos y donde van a ser

implementados, si se emplean bases de datos, en esta etapa se especifican las tablas y sus relaciones. Se

define el tiempo de construcción, de composición y de ejecución del sistema. Se especifica el estándar

de implementación de los componentes, las operaciones, los parámetros de entrada y salida, los

cambios en los estados de los componentes, las interacciones entre los mismos, las interfaces necesarias,

las restricciones a las que se deben someter y se concluye esta fase con la especificación y modelado de

las bases de datos.

Aprovisionamiento del Componente

Durante el desarrollo de esta fase se pone de manifiesto la implementación del diseño que se ha creado

en fases anteriores, los principales productos de esta etapa son los componentes de la capa de

presentación y de la lógica de negocios, implementados y listos para la fase de integración. Se refina la

interfaz de usuario, culminando su implementación y se solventa cualquier inconveniente.

Diseño de la interfaz

del usuario

Diseño de la

Arquitectura

Diseño de la Base de

Datos

Especificación de

la Base de Datos

Diseño de la

Infraestructura

Modelado del

Componente

Especificación del

Componente

Figura 58 Etapas de Diseño de la Aplicación

Figura 59 Etapas de Especificación de Componentes


Otra actividad de esta fase, se refiere a la adquisición, suscripción, desarrollo, adaptación de

componentes que estén listos para ser ensamblados en la siguiente fase del proceso, para finalizar la

construcción de la aplicación web. Deben realizarse pruebas de los componentes y una certificación de

los mismos a fin de saber si se encuentran en cumplimiento de los contratos de uso. Por último, la

implantación y prueba de la base de datos debe de realizarse.

Ensamblaje del Componente

En el desarrollo de esta etapa, los componentes que han sido adquiridos o producidos en fases

anteriores, han de ser ensamblados, enlazados y probados, han de practicarse pruebas de integración y

verificación del sistema. Finalmente se realiza una actividad de documentación de la aplicación, los

procesos y todo aquello que indique el plan de documentación de la empresa.

Refinamiento de las

interfaces

Aprovisionamiento

de componentes

Pruebas de los

Componentes

Implementación de la data

de los componentes

Figura 60 Etapas de Aprovisionamiento del Componente


Pruebas de la Aplicación

La fase de pruebas, es aquella que se corresponde con la realización de pruebas funcionales, de

comportamiento y de aceptación por parte de los usuarios.

Figura 62 Etapas de Pruebas de la Aplicación

Entrega de la aplicación

Es en esta fase en la que se procede a la instalación de la aplicación en presencia de los usuarios, se

prueba el funcionamiento de la aplicación en el ambiente operacional, los usuarios reciben

entrenamiento de acuerdo al plan de adiestramientos, y por último, se hace entrega formal de la

aplicación.

Pruebas

Funcionales

Pruebas de

Comportamiento

Pruebas de

Aceptación

Refinamiento de la

arquitectura de la aplicación

Enlazar las Capas

Pruebas de la aplicación

Documentación de la Aplicación

Figura 61 Etapas de Ensamblaje del Componente


Figura 63 Etapas de Entrega de la Aplicación

Instalación de la

Apliación

Pruebas de la

Instalación

Adiestramiento de los

Usuarios

Entrega de la

Aplicación

Bibliografía

ComputaciónUBAWiki. [En línea] [Citado el: 15 de Marzo de 2009.]

http://cuba.dc.uba.ar/w/Glosario_de_t%C3%A9rminos_t%C3%A9cnicos_(Organizaci%C3%B3n_d

el_Computador_II).

Configurar Equipos. [En línea] [Citado el: 05 de Marzo de 2009.]

http://www.configurarequipos.com/doc585.html.

Deitel, Harvey y Deitel, Paul. 2004. Como Programar en JAVA. Mexico : PEARSON EDUCACIÓN,

2004.

Hamar, Vanessa. Universidad de los Andes. [En línea] [Citado el: 15 de Enero de 2009.]

http://www.ing.ula.ve/~vanessa/.

Hennessy, John y Patterson, David. 2007. Computer Architecture A Quantitative Approach. San

Francisco, CA : Elsevier, Inc, 2007.

MailXmail. (s.f.). [En línea] [Citado el: 05 de Abril de 2008.]

http://www.mailxmail.com/curso/informatica/mantenerordenador/capitulo44.htm.

Montilva, Jonás A. 2004. Desarrollo de aplicaciones empresariales, el Método WATCH. Mérida :

Universidad de los Andes, Facultad de Ingeniería, 2004.

OLARTE, R. H. Monografias. [En línea] [Citado el: 11 de Abril de 2008.]

http://www.monografias.com/trabajos22/diccionario-informatico/diccionario-informatico.shtml.

Bibliografía 81

OMG. 2008. Object Management Group. [En línea] 2008. [Citado el: 20 de Noviembre de 2008.]

http://www.uml.org/#UML2.0.

Páez Monzón, Gerard. 1993. Arquitectura y Organización del Computador. Mérida : Senda Sol, 1993.

TechFAQ. [En línea] [Citado el: 02 de Marzo de 2009.] http://www.tech-faq.com/l1-cache.shtml.

Wikipedia, La Enciclopedia Libre. [En línea] [Citado el: 20 de Abril de 2008.]

http://es.wikipedia.org/wiki/Circuito_integrado.

—. [En línea] [Citado el: 15 de Mayo de 2008.] http://es.wikipedia.org/wiki/Microprocesador.

—. [En línea] [Citado el: 25 de Mayo de 2008.] http://en.wikipedia.org/wiki/Branch_predictor.

—. [En línea] [Citado el: 25 de Mayo de 2008.]

http://en.wikipedia.org/wiki/Java_%28programming_language%29.

—. [En línea] [Citado el: 25 de Enero de 2009.]

http://es.wikipedia.org/wiki/Translation_Lookaside_Buffer.

—. [En línea] [Citado el: 10 de Marzo de 2009.]

http://es.wikipedia.org/wiki/Dependencia_de_datos.

Documents

MODELO ANALÍTICO PARA EL DISEÑO DE