Software Architecture Analysis Method DANIEL
Click here to load reader
-
Upload
daniel-healy -
Category
Documents
-
view
199 -
download
0
Transcript of Software Architecture Analysis Method DANIEL
UNIDAD 5 1
TECNOLÓGICO DE ESTUDIOS SUPERIORES DE COACALCO
NOMBRE: DANIEL SANCHEZ SANCHEZ
GRUPO: 3822
TRABAJO: METODOS DE EVALUACION DE ARQUITECTURA DE SOFTWARE
PROFESOR: LIC.NESTOR APOLO LOPEZ GONZALEZ
MATERIA: ARQUITECTURA Y DISEÑO DE SOFTWARE
UNIDAD 5 2
INDICE
INTRODUCCION…………………………………………………………………….………3
ATAM – ARCHITECTURE TRADEOFF ANALYSIS METHOD……………….…4
DESCRIPCIÓN EN DETALLE DE LOS PASOS DEL ATAM…………………….……4
SAAM - SOFTWARE ARCHITECTURE ANALYSIS METHOD……………....…7
DESCRIPCIÓN DE LA ARQUITECTURA……………………………………………….9
CLASIFICACIÓN DE ESCENARIOS……………………………………………………..9
EVALUACIÓN DE ESCENARIOS………………………………………………………..9
INTERACCIÓN DE ESCENARIOS……………………………………………….…….10
ARID - ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS……………..….10
ARID: UN ADR/ATMA HÍBRIDO…………………………………………………...…11
FASE1: PRE-REUNIÓN…………………………………………………………..…..…12
ROLES EN ARID……………………………………………………………………….….12
ALMA ARCHITECTURE LEVEL MODIFIABILITY ANALYSIS………….…13
SNA - SURVIVABLE NETWORK ANALYSIS..................................................14
CONCLUSION……………………………………………………………….…...17
REFERENCIAS………………………………………………………………….18
UNIDAD 5 3
INTRODUCCION
La Arquitectura de Software de un programa o sistema de computación es la
estructura o las estructuras del sistema, que contienen componentes de software, las
propiedades externamente visibles de dichos componentes y las relaciones entre ellos.
Implicancias de la definición La arquitectura es una abstracción de un sistema o
sistemas Como la arquitectura es abstracta, esta elimina la información local, los
detalles de componentes privados no son arquitectónicos Los sistemas están
compuestos por muchas estructuras.
UNIDAD 5 4
ATAM – ARCHITECTURE TRADEOFF ANALYSIS METHOD
El ATAM también puede ser utilizado para analizar sistemas legados. Esta
necesidad nace cuando el sistema legado necesita ser modificado, integrado con otro
sistema, entre otras necesidades. Aplicar el ATAM incrementa el entendimiento de los
atributos de calidad del sistema legado.
El líder del equipo de evaluación describe el método a los participantes, fija
las expectativas y responde las preguntas que puedan surgir .Presentar las pautas del
negocio En este paso se reitera las actividades del paso 6 utilizando el ranking de
escenarios del paso 7. Estos escenarios se consideran casos de prueba para confirmar
el análisis realizado hasta ahora. Este análisis puede descubrir nuevas propuestas
arquitectónicas, riesgos, no riesgos, sensitivity points y tradeoff points, que son
documentados.
Descripción en detalle de los pasos del ATAM
Paso 1: Presentar el ATAM
En el primer paso el líder del equipo de evaluación presenta el ATAM a los
stakeholders. Este tiempo es utilizado para explicar el proceso que todos seguirán,
responder preguntas, y fijar el contexto y las expectativas para el resto de las
actividades. En particular, el líder describe
Paso 2: Presentar las pautas del negocio
Los participantes de la evaluación, los stakeholders así como el equipo de
evaluación, necesitan entender el contexto del sistema y las principales pautas del
negocio que motivan el desarrollo. En este paso, una decisión maker del proyecto
UNIDAD 5 5
(por ejemplo, el director de proyecto o el cliente del sistema) presenta el sistema
desde la perspectiva del negocio. La presentación debería describir:
Paso 3: Presentar la arquitectura
En este paso, el arquitecto líder (o equipo de arquitectura) realiza una
presentación describiendo la arquitectura en un nivel apropiado de detalle. Cual es el
“nivel apropiado” depende de muchos factores: cuanto de la arquitectura ha sido
diseñada y documentada, cuanto tiempo hay disponible, y de los requerimientos de
calidad. La información arquitectónica presentada afectará directamente el posible
análisis y la calidad del mismo.
Paso 4: Identificar las propuestas arquitectónicas
El ATAM centraliza el análisis de una arquitectura en el entendimiento de sus
propuestas arquitectónicas. En este paso, son capturadas por el equipo de evaluación
pero no son analizadas. El equipo le pedirá al arquitecto que explícitamente nombre
toda propuesta usada, pero ellos también capturarán todas las propuestas que hayan
escuchado durante la presentación del arquitecto en el paso previo.
Paso 5: Generar el árbol de utilidad de los atributos de calidad
En este paso el equipo de evaluación trabaja junto con los decisión makers (el
equipó de arquitectura, el director y los clientes representativos) para identificar,
priorizar y refinar las metas de los atributos de calidad más importantes del sistema.
Este paso crucial guía el resto del análisis. Sin esta guía, los evaluadores pueden
perder su tiempo analizando aspectos de la arquitectura que no son de interés para los
stakeholders. Debe haber una manera en la cual los evaluadores y los stakeholders
concentren su atención en los aspectos de la arquitectura que son más críticos para el
éxito del sistema. Esto es conseguido construyendo un árbol de utilidad
UNIDAD 5 6
Paso 6: Analizar las propuestas arquitectónicas
Este paso mide cuan adecuados son el uno para el otro. Aquí, el equipo de
evaluación puede probar las propuestas arquitectónicas que realizan los atributos de
calidad más importantes. Esto es hecho en detalle documentando estas propuestas
arquitectónicas e identificando sus riesgos, no riesgos, sensitivity points y tradeoff
points. La meta del equipo de evaluación es estar convencidos que la propuesta
instanciada en la arquitectura que esta siendo evaluada, es la apropiada para satisfacer
los requerimientos de un atributo específico.
Paso 7: Lluvia de ideas y priorización de escenarios
Los escenarios guían la fase de pruebas del ATAM. Está probado que generar
un conjunto de escenarios facilita la discusión y la lluvia de ideas, cuando un gran
número de stakeholders han sido reunidos para participar en el ATAM. Los escenarios
son utilizados para, analizar las propuestas arquitectónicas que se utilizan en la
metodología.
Paso 8: Analizar las propuestas arquitectónicas
Después que los escenarios han sido recolectados y analizados, el equipo de
evaluación guía al arquitecto en el proceso de llevar a cabo los escenarios con ranking
más alto del paso 7 en todas las descripciones arquitectónicas que se han presentado.
El arquitecto explica como las decisiones arquitectónicas relevantes contribuyen a
realizar el escenario.
Paso 9: Presentar los resultados
Finalmente, la información recogida por el ATAM necesita ser resumida y
presentada a los stakeholders. En esta presentación el líder de la evaluación recapitula
UNIDAD 5 7
los pasos del ATAM y toda la información recogida en cada paso, incluyendo el
contexto del negocio, los requerimientos guías, las restricciones, y la arquitectura.
Pero más importante son las salidas del ATAM.
SAAM -SOFTWARE ARCHITECTURE ANALYSIS METHOD
El primer método de evaluación basado en escenarios que surgió. El foco de
este método es la modificabilidad. Esta noción de evaluación basada en el contexto,
nos ha llevado a adoptar a los escenarios como los medios descriptivos para
especificar y evaluar atributos de calidad. Podemos definir un escenario como una
breve descripción de la interacción entre un interesado y el sistema. El interesado
puede ser un cliente, usuario final, desarrollador, empresa desarrolladora,
administrador, inversor, etc.
Los escenarios son clasificados en escenarios directos e indirectos. (Son
equivalentes en notación UML a casos de uso y casos de cambio). Un escenario
directo no requiere que el sistema sea modificado para soportarlo (consideramos que
el sistema es modificado cuando se cambia la función asignada a un componente o se
agrega un componente o conector). Un escenario indirecto requiere que el sistema sea
modificado para soportarlo.
Cuando dos o más escenarios indirectos requieren cambios sobre la misma
entidad o componente, se dice que interactúan en dicho componente. En este caso, los
componentes afectados necesitan ser modificados o divididos en subcomponentes
para evitar la interacción de diferentes escenarios. Podemos decir que a mayor
interacción de escenarios, menor separación de conceptos.
UNIDAD 5 8
SAAM utiliza el agrupamiento de escenarios como criterio para evaluar la
arquitectura. Esto significa que si se agrupa un conjunto de escenarios por ser
similares y luego se observa que son equivalentes, la agrupación ha sido exitosa,
porque significa que la funcionalidad del sistema ha sido modula rizada
adecuadamente. Por el contrario, si la agrupación de estos escenarios similares, afecta
diferentes componentes (no son equivalentes), la arquitectura posiblemente debe ser
corregida.
Determinando el nivel de detalle apropiado para una descripción
arquitectónica, mediante escenarios. Resulta útil reflejar en un ejemplo la relación
entre los escenarios y la descripción arquitectónica. Uno de los beneficios de la
arquitectura es la habilidad de visualizar el software desde un nivel más alto de
abstracción. ¿Cómo saben los diseñadores cual debe ser este nivel con exactitud? La
respuesta está determinada por lo que los escenarios identificados en el sistema
determinen. Para ilustrar este concepto veamos el ejemplo siguiente. (Figura 1)
(FIGURA 1) .Descripción inicial de la arquitectura.
La figura anterior muestra una descripción inicial de una arquitectura.
Necesitamos mapear los escenarios hacia ella. En particular, para cada escenario
11
visdiff
12
msarn200
12
make
11, 12, 13
main
11
1313
13
11, 12
UNIDAD 5 9
indirecto, debemos reflejar los componentes que son afectados. Nos interesaremos
principalmente en los escenarios indirectos, pues representan los atributos que la
arquitectura deberá satisfacer. Los escenarios directos, representan las
funcionalidades del sistema Para este ejemplo consideramos que existen tres
escenarios indirectos: 11, 12 y 13. Se pueden observar en la figura, los componentes
afectados por cada uno de ellos.
Descripción de la Arquitectura
En este paso se presentan las arquitecturas candidatas. Es fundamental que la
notación empleada sea bien entendida por todos los involucrados y la granularidad
sea común para todas las arquitecturas candidatas presentados. Se deben indicar los
principales elementos de la arquitectura. Usualmente alcanza con:
Las estructuras de uso, de importación y de flujo de datos y control, más un
documento de asignación de funcionalidad. Hay una cantidad apreciable de
investigación sobre las notaciones y representaciones posibles para estos
componentes. Una representación típica distingue entre componentes que son activos
(transforman datos) y pasivos (datos almacenados). También podemos describir
agrupaciones de componentes en subsistemas o capas. Acompañando el punto
anterior debe existir una descripción de cómo el sistema se comporta con el paso del
tiempo: una descripción dinámica. Puede realizarse mediante lenguaje natural o algún
otro método más formal.
Clasificación de escenarios
En este paso debemos clasificar los escenarios como directos o indirectos
utilizando la definición antes detallada (en la sección “Contexto y escenarios de
SAAM”)
Evaluación de escenarios
UNIDAD 5 10
Para cada escenario indirecto, se deben listar los cambios necesarios en la
arquitectura para soportarlo, y el costo de llevarlos a cabo debe ser estimado. Notar
que el solo hecho de clasificar los escenarios implica un análisis de la arquitectura. Si
se da el hecho de que la información necesaria para llevar a cabo la clasificación no
está disponible, puede indicar que ciertos componentes de la arquitectura requieran
un mayor análisis y estudio. Usualmente el resultado de este paso se documenta en
forma tabular.
Interacción de escenarios
Debemos determinar las interacciones de escenarios sobre cada componente
de cada arquitectura. Está claro, que el resultado puede interpretarse de varias formas,
tal como se observó en el ejemplo de la sección “Contexto y escenarios de SAAM”.
Paso 6. Evaluación general: Un peso es asignado a cada escenario en términos de su
influencia para que el sistema sea exitoso. El peso puede ser elegido de acuerdo a los
objetivos del negocio, costos, riesgos, etc.
ARID ACTIVE REVIEWS FOR INTERMEDIATE DESIGNS
El método ARID es conveniente para realizar la evaluación de diseños parciales en las
etapas tempranas del desarrollo. ADRs son técnicas efectivas para asegurar la calidad
dando diseños detallados del software. El método se basa en que los participantes
realicen tareas que son cuidadosamente estructuradas para que el entrevistado no
pueda responder si o no, sino que obliga a utilizar el diseño y las respuestas nos dan
el estado actual y no algo fingido. ADR es utilizado para la evaluación de diseños
detallados de unidades del software como los componentes o módulos. Las preguntas
giran en torno a la calidad y completitud de la documentación y la suficiencia, el
ajuste y la conveniencia de los servicios que provee el diseño propuesto.
UNIDAD 5 11
ARID: un ADR/ATMA híbrido
Las revisiones de diseño activas y los ATAM tienen características útiles para resolver
el problema de evaluar diseños preliminares. En el ADR, los interesados reciben
documentación detallada del diseño y realizan los ejercicios en forma individual, pero
en las etapas preliminares de diseño no hay documentación detallada. Además unos
de los objetivos del ARID es crear intereses en los inversionistas a través de reuniones
centrales y esto no se lograría con los trabajos individuales.
Por otra parte, el ATAM se está pensado para evaluar una arquitectura entera,
y no a una porción de la misma. Además, el interés de la calidad fue limitada a la
viabilidad de la totalidad de la arquitectura. Las otras características que se centra el
ATAM no nos interesan. ARID surge de combinar las mejores cualidades de los
métodos ADRs y los métodos basados en escenarios.
De los ADRs nos quedamos con la participación activa de los entrevistados los
cual es ideal por dos motivos: Nos asegura alta fidelidad en las respuestas (evita
sentarse en un lado y no hacer nada).La participación activa puede captar la atención
del grupo de compradores. Del ATAM nos quedamos con la idea de la generación de
los escenarios por parte de todos los interesados, los usuarios le dirán a los
diseñadores que los que ellos necesitan o mejor dicho que es lo que ellos esperan y si
los diseñadores demuestran en la pruebas que el diseño cumple con los
requerimientos también va a atraer el interés de los compradores.
Roles en ARID
Se identifican tres grupos de participante en una evaluación ARID: El equipo
de verificación, el cual está formado por tres roles: líder de la evaluación que se
encarga de preparar conjuntamente con el arquitecto la evaluación, un secretario que
se encarga de recolectar los resultados y realizar las anotaciones; y un conjunto de
interrogadores que ayudan a obtener los escenarios durante las entrevistas.
UNIDAD 5 12
Opcionalmente se podrá tener un observador para mejorar el proceso de evaluación
El arquitecto, el cual es responsable de presentar el diseño y a quien se la dará los
resultados de la evaluación. Revisores, son los interesados en la viabilidad y
adecuación del diseño que se presentan. Son las personas que van a utilizar el diseño
(software engineers) y son las personas más adecuadas para juzgar su calidad.
Fase1: PRE-reunión
Primero una reunión entre el arquitecto y el líder de la evaluación se lleva a
cabo para preparar el ejercicio. Esta reunión dura un día aproximadamente y en la
misma se llevan a cabo los primeros 4 pasos. Identificar los revisores, son los
ingenieros de software que van a usar el diseño reparar la presentación del diseño, el
arquitecto prepara un informe que explica el diseño, el mismo deberá ser lo
suficientemente detallado como para que una capacitada audiencia pueda usar el
diseño.
El arquitecto presenta el informe al líder de la evaluación, esta presentación es
provechosa por varios motivos, preparar los escenarios, el arquitecto y el líder
prepara los escenarios que sirven para ilustrar los conceptos a lo revisado. Preparar
los materiales, copias de la presentaciones, escenarios, se realiza la agenda invitando
a interesados externos y asegurando la presencia de los revisores.
Fase 2: Evaluación
Durante la fase dos, los revisores son reunidos y la evaluación comienza. Esta
durará un día y medio y las 5 actividades restantes son completadas. Presentación del
ARID, el líder utiliza 30 minutos para explicar los pasos de la evaluación a los
participantes. Presentación del diseño, el arquitecto realiza una presentación de dos
horas del diseño mostrando los ejemplos. Durante la presentación no se podrán hacer
preguntas concernientes a la implementación ni tampoco se proponen diseños
UNIDAD 5 13
alternativos. El objetivo es ver si el diseño es adecuado no saber porque el diseño se
hizo de esa manera u obtener tips para la futura implementación. Preguntas para
clarificar el diseño son permitidas. El secretario es el encargado de recolectar las
preguntas y registrar las veces que el arquitecto evadió una respuesta afirmando que
estaba pensado pero no disponible.
Lluvia de ideas y priorización de escenarios, entre todos los presentes se
proponen escenarios relevantes para solucionar problemas que esperan hacer frente.
Luego los revisores pueden sugerir que dos escenarios son versiones del mismo o un
escenario es parte de otro y deben ser unidos. A continuación cada revisor puede
votar, siendo la cantidad de votos un 30% de la totalidad de los escenarios, los
revisores pueden utilizar todo sus votos en un escenario o repartirlos entre varios. Los
escenarios con más votos son usados para testear la adecuación del diseño.
Se realiza la revisión, comenzando con el escenario que tuvo la mayor
cantidad de votos, el líder de la evaluación pide a los revisores que trabajando como
grupo usen el diseño para resolver el problema presentado en el escenario. Durante
este trabajo el arquitecto no podrá ayudar a los revisores, sin embargo si el líder ve
que los revisores van por un mal camino, puede pedirle al arquitecto que los guíe o le
brinde cierta información para no perder el tiempo (todo esto debe ser registrado por
el secretario). Todas las discrepancias también son registradas. La etapa continúa
hasta que alguno de los siguientes eventos ocurre: El tiempo reservado para la
revisión se acaba. Los escenarios con más votos han sido analizados. El grupo se
siente satisfecho tanto porque vio que el diseño era correcto o porque no lo aprobó.
ALMA Architecture Level Modifiability Analysis
ALMA es un método de evaluación orientado a metas; dependiendo de la
meta, este método puede ser usado para predecir el costo de mantenimiento en una
arquitectura, evaluar los riesgos al haber una modificación en esta, o comparar un
UNIDAD 5 14
conjunto de arquitecturas para determinar cuál es la más apropiada en soportar
cambios. Este método se compone de cinco pasos que se muestran en la Figura 1 y
que a continuación se describen.
Definir la meta de evaluación. Dependiendo del objetivo de la evaluación se
selecciona alguna de las tres metas.
Describir la arquitectura de software. En este punto se colecta la información
de las partes más relevantes de la arquitectura como son la descomposición de
ésta en componentes, las relaciones entre componentes así como las relaciones
que existen en el entorno del sistema.
Obtener escenarios. Una vez que se cuenta con la información de la
arquitectura se procede a encontrar y definir los escenarios de cambio, estos
escenarios son agrupados en categorías.
Evaluar escenarios. En este punto se realiza un análisis de impacto que
consiste en identificar los componentes afectados por los escenarios
previamente definidos, determinar el efecto del cambio sobre los componentes
así como determinar los efectos del cambio en otros componentes. Los
resultados de este análisis se deben expresar ya sea de manera cuantitativa o
cualitativa.
Interpretar resultados. Finalmente se interpretan los resultados así como las
conclusiones del análisis dependiendo de la meta de evaluación seleccionada.
SNA Survivable Network Analysis
SNA es un método desarrollado por el CERT (Computer Emergency
Response Team) que forma parte del SEI (Software Engineering Institute). Este
método ayuda a identificar la capacidad de supervivencia en un sistema analizando su
arquitectura. La supervivencia es la capacidad que tiene un sistema para completar su
UNIDAD 5 15
misión a tiempo ante la presencia de ataques, fallas o accidentes. Un ejemplo de la
definición anterior es la siguiente: un cajero automático debe garantizar al usuario los
servicios esenciales aun cuando este se encuentre en presencia de algún ataque
externo o falla interna. SNA utiliza tres propiedades clave para evaluar la
supervivencia en un sistema. Estas son:
Resistencia. Es la capacidad del sistema para repeler ataques, fallas o
accidentes.
Reconocimiento. Es la capacidad de detectar ataques, fallas o accidentes y si
estos ocurren evaluar los daños.
Recuperación. Es la capacidad de mantener en operación los servicios
esenciales en presencia de ataques, fallas o accidentes. Este método puede ser
usado en el proceso de construcción de la arquitectura (evaluación temprana),
una vez que la construcción de esta ha terminado o si la arquitectura se
encuentra implementada.
La técnica de evaluación que utiliza SNA es el uso de escenarios. SNA hace
uso de dos tipos de escenarios. El primer tipo son los escenarios normales de uso,
éstos se componen de una serie de pasos donde los usuarios invocan a servicios y
obtienen acceso a activos tales como bases de datos. El segundo tipo de escenarios
son los de intrusión, en los que se representan diferentes tipos de ataques al sistema.
Para llevar a cabo la evaluación, se requiere que se cuente con la especificación de la
arquitectura. Si hace falta documentación de la especificación se procede a
completarla.
SNA está compuesto de cuatro pasos que a continuación se describen:
1. Definición del sistema. En este paso se obtiene la misión del sistema, se
discute el entorno de uso en términos de capacidades y ubicaciones de los
usuarios, se analizan posibles riesgos que el sistema pueda presentar en
condiciones adversas, finalmente se analiza la arquitectura de software.
UNIDAD 5 16
2. Definición de las capacidades esenciales. A continuación se seleccionan los
servicios esenciales y los activos que usan. Se deben de seleccionar aquellos
servicios y activos que sean críticos para garantizar en condiciones adversas la
misión del sistema. Una vez seleccionados, estos se trazan a través de la
arquitectura para identificar los componentes que participan en proporcionar
los servicios esenciales.
3. Definición de las capacidades que comprometen al sistema. En este paso se
selecciona un conjunto representativo de posibles ataques basados en el
entorno de operación del sistema. Se definen los escenarios de intrusión y se
trazan a través de la arquitectura para identificar componentes que
comprometan la supervivencia del sistema logrando así el acceso y daño a
éste.
4. Analizar la supervivencia. Finalmente se identifican los escenarios de
intrusión que contienen los componentes esenciales y que comprometen la
supervivencia del sistema. Por cada componente identificado se procede a
analizarlo en términos de las capacidades de resistencia, reconocimiento y
recuperación. Estos análisis se colocan en una tabla llamada mapa de
supervivencia que contiene porcada escenario de intrusión las estrategias de
supervivencia actuales y las recomendadas con respecto a cada una de las
capacidades.
UNIDAD 5 17
CONCLUSIONES
UNIDAD 5 18
REFERENCIAS
Por Omar S. Gómez, (2008), Evaluando la arquitectura de software Parte 2. Métodos de evaluación, Consulto el 03 de julio del 2012, Recuperado de http://www.osgg.net/omarsite/resources/papers/ev_arch_02.pdf
Mauricio Dávila, Evaluación de Arquitecturas de Software, Universidad de la republica Facultad de ingeniería, Consulta el 04 de julio del 2012, Recuperado de http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CEwQFjAA&url=http%3A%2F%2Fwww.fing.edu.uy%2Finco%2Fcursos%2Fgestsoft%2FPresentaciones%2FEvaluacion%2520de%2520Arquitecturas%2520-%2520G10%2FEvaluacion%2520de%2520Arquitecturas.doc&ei=dd_zT9vMO-SU2AWV0P3zBg&usg=AFQjCNFoBEY6JCqN5lCs9i8PVtEnt8OdUg&sig2=0F1iurWqYrVKxUkLrYpgAQ
Omar Salvador Gómez (2005), Proceso de evaluación para arquitecturas de software usadas en el sector empresarial (PEASSE), CIMAT, Consulto el 03 de julio del 2012, Recuperado de http://osgg.net/omarsite/resources/proceedings/PEASSE.pdf
Arriola Navarrete, O., & Garmendia Bonilla, L. Evaluación de software para bibliotecas: requerimientos técnicos, 1997. In Bibliotecas y archivos: órgano de la Escuela Nacional de Biblioteconomía y Archivonomía. Escuela Nacional de Biblioteconomía y Archivonomía. pp.23-31. (Published) [Journal Article (Print/Paginated)]. http://eprints.rclis.org/handle/10760/11257#.T_R62KsqB1E
Andrea Delgado, Alberto Castro, Martín Germán, Evaluación de Arquitecturas de Software con ATAM (Architecture Tradeoff Analysis Method): un caso de estudio,
UNIDAD 5 19
Universidad de la República, Facultad de Ingeniería, Instituto de Computación, Consulto el día 04 de julio del 2012, Recuperado de http://www.bvs.hn/cu-2007/ponencias/CAL/CAL027.pdf