librería criptogr´afica basada en componentes utilizando el lenguaje

LIBRERÍA CRIPTOGRÁFICA BASADA EN COMPONENTES UTILIZANDO
EL LENGUAJE DE PROGRAMACIÓN OZ
YULIBAN FERNANDO PENAGOS GÓMEZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ
2015
LIBRERÍA CRIPTOGRÁFICA BASADA EN COMPONENTES UTILIZANDO
EL LENGUAJE DE PROGRAMACIÓN OZ
Yuliban Fernando Penagos Gómez
Informe Final
Director:
Ing. Henry Alberto Diosa, Ph.D.
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ
2015
Tabla de Contenido
1 Introducción
1.1 Descripción del problema . . . . . . . . .
1.2 Objetivos . . . . . . . . . . . . . . . . . .
1.2.1 Objetivo general . . . . . . . . . .
1.2.2 Objetivos especı́ficos . . . . . . . .
1.3 Marco teórico . . . . . . . . . . . . . . . .
1.3.1 Seguridad . . . . . . . . . . . . . .
1.3.2 Tipos de Criptografı́a según el tipo
1.3.3 Algoritmos de Codificación . . . .
1.3.4 Fundamentos Matemáticos . . . .
1.4 Marco metodológico . . . . . . . . . . . .
1.4.1 Reutilización de Software . . . . .
1.4.2 Componentes . . . . . . . . . . . .
1.4.3 Metodologı́a de diseño: Proceso
Adaptado al DSBC . . . . . . . . .
1.4.4 UML 2.x . . . . . . . . . . . . . .
1.5 Marco tecnológico . . . . . . . . . . . . .
1.5.1 Lenguaje Oz . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
de clave . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
de Desarrollo
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Unificado
. . . . . .
. . . . . .
. . . . . .
. . . . . .
1
2
3
3
3
3
3
4
5
6
9
9
9
13
22
23
23
2 Fase de Requerimientos: Modelo funcional basado en casos de Uso
2.1 Especificación de requerimientos . . . . . . . . . . . . . . . . . . . .
2.1.1 Requerimientos funcionales . . . . . . . . . . . . . . . . . . .
2.1.2 Requerimientos no funcionales . . . . . . . . . . . . . . . . .
2.2 Diagrama general de casos de uso . . . . . . . . . . . . . . . . . . . .
2.2.1 Descripción de los casos de uso, modelo extendido . . . . . .
2.3 Modelo conceptual de negocio . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Descripción de Conceptos . . . . . . . . . . . . . . . . . . . .
26
26
26
27
29
29
36
36
3 Fase de Especificación:
Identificación de Componentes y
Arquitectura Prescriptiva
3.1 Identificación de interfaces . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Interfaces del sistema . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Interfaces del negocio . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Identificación de las operaciones de negocio . . . . . . . . . .
3.2 Especificación de la arquitectura (prescriptiva) basada en componentes
3.3 Especificación de componentes . . . . . . . . . . . . . . . . . . . . .
3.3.1 Especificación de interfaces . . . . . . . . . . . . . . . . . . .
39
39
39
39
40
46
48
48
iii
4 Fase de Provisión y Ensamble de Componentes
4.1 Arquitectura descriptiva de componentes . . . . .
4.2 Diagramas intercomponentes: refinamiento . . .
4.3 Modelos de Realización de Interfaces . . . . . . .
4.4 Modelado intra-componente . . . . . . . . . . . .
4.4.1 Modelos estructurales . . . . . . . . . . .
4.5 Modelos dinámicos intra-componente . . . . . . .
.
.
.
.
.
.
55
55
57
62
65
65
68
5 Modelado de la Interfaz Gráfica de Usuario y estructura de CD
5.1 Diagrama de navegación . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Estructura de CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
72
6 Manual de instalación y de usuario Librerı́a Criptográfica
6.1 Manual de configuración (dirigido a desarrolladores) . . . . . . . .
6.1.1 Requerimientos hardware para instalación . . . . . . . . . .
6.1.2 Requerimientos de software para instalación . . . . . . . . .
6.1.3 Procedimiento para instalación (dirigido a desarrolladores)
6.1.4 Código fuente y generación de ejecutable . . . . . . . . . .
6.2 Manual de instalación (orientado a usuario final) . . . . . . . . . .
6.3 Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
73
73
73
74
75
75
75
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Conclusiones
80
8 Trabajo Futuro
85
Anexos
87
A Casos de uso
88
B Diagramas intercomponentes: Fase de especificación, Arquitectura
Prescriptiva
119
C Refinamiento Diagramas intercomponentes
121
D Modelos de realización de interfaces
123
E Modelos estructurales intra-componente
125
iv
Lista de Tablas
1.1
Subclaves (Zi ) empleadas en el algoritmo IDEA. . . . . . . . . . . .
7
2.1
2.2
Tabla de requerimientos funcionales para el algoritmo genético. . . .
Tabla de requerimientos no funcionales . . . . . . . . . . . . . . . . .
27
28
v
Lista de Figuras
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
Sistema Simétrico. [Adaptado de [1]] . . . . . . . . . . . . . . . . . .
Criptografı́a con clave pública. [Adaptado de [1]] . . . . . . . . . . .
Algoritmo IDEA [Adaptado de [2] ] . . . . . . . . . . . . . . . . . . .
Interfaces de requerimiento y de servicio [Elaboración propia] . . . .
Meta modelo de un componente [Tomado de [3, p.8]] . . . . . . . . .
Flujos de trabajo en el proceso de desarrollo [Adaptado de [4, p. 27]]
Capas de Arquitectura en el DSBC [Adaptado de [4, p. 11]] . . . . .
Dependencias entre componentes [Adaptado de [4, p. 13]] . . . . . .
Diagrama de componentes para un sistema de comercio electrónico.
[Tomado de [5, p.133]] . . . . . . . . . . . . . . . . . . . . . . . . . .
1.10 Estereotipado de notación de componentes en UML 2.x como functor
[Elaboración propia]. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
7
12
14
15
19
20
2.1
2.2
Diagrama general de casos de uso . . . . . . . . . . . . . . . . . . . .
Diagramas de casos de uso para la carga de archivos [Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
Diagramas de casos de uso para codificación de texto [Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
Diagramas de casos de uso para la decodificación [Elaboración propia
basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Modelo de tipos inicial . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura basada en componentes . . . . . . . . . . . . . . . . . .
Diagrama de secuencia CU017. Almacenar Archivo [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operaciones IGestorArchivo . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia CU002. Codificar [Elaboración propia] . . . .
Diagrama de secuencia CU006. Decodificar [Elaboración propia] . .
Operaciones interfaces de negocio . . . . . . . . . . . . . . . . . . . .
Arquitectura prescriptiva basada en componentes . . . . . . . . . . .
Modelo de tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface de sistema ICodificar [Elaboración propia] . . . . . . . . . .
Interface de sistema IDecodificar [Elaboración propia] . . . . . . . .
Interface de sistema ICargarArchivo [Elaboración propia] . . . . . .
Interface de sistema IGenerarLlaves [Elaboración propia] . . . . . . .
Interface de sistema IConsultarAyuda [Elaboración propia] . . . . .
41
42
2.3
2.4
2.5
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.9
3.8
3.10
3.11
3.14
3.15
3.12
vi
23
25
30
32
34
38
42
43
44
45
46
46
47
48
48
48
48
49
3.13 Interface de sistema AlmacenarArchivo [Elaboración propia] . . . . .
3.16 Interface de negocio IGestorOperacionesMatematicas [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.17 Interface de negocio IGestorArchivo [Elaboración propia] . . . . . . .
3.18 Interface de negocio IGeneradorClave [Elaboración propia] . . . . . .
3.19 Interface de negocio ICodificadorIDEA [Elaboración propia] . . . . .
3.20 Interface de negocio ICodificadorRSA [Elaboración propia] . . . . . .
3.21 Interface de negocio IGestorNumero [Elaboración propia] . . . . . .
4.1
4.2
4.3
4.4
4.5
4.6
49
50
50
51
52
53
54
Arquitectura descriptiva del sistema [Elaboración propia] . . . . . .
Refinamiento CU001. Cargar Archivo [Elaboración propia] . . . . . .
Refinamiento CU017. Almacenar Archivo [Elaboración propia] . . .
Refinamiento CU002. Codificar [Elaboración propia] . . . . . . . . .
Refinamiento CU006. Decodificar [Elaboración propia] . . . . . . . .
Diagrama de realización componente CodificadorIDEA [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de realización componente CodificadorRSA [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de realización componente GeneradorClave [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo estructural CodificadorIDEA [Elaboración propia] . . . . . .
Modelo estructural componente CodificadorRSA [Elaboración propia]
Modelo estructural componente GeneradorClave [Elaboración propia]
Diagrama de secuencia para la codificación utilizando RSA
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
Diagrama de secuencia para la codificación usando IDEA[Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencia para la generación de llaves [Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
56
58
59
60
61
5.1
5.2
Mapa de navegación Sistema de codificación . . . . . . . . . . . . . .
Estructura CD anexo . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
72
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
Generación de claves RSA [Elaboración propia] . .
Generación de claves RSA [Elaboración propia] . .
Selección archivo [Elaboración propia] . . . . . . .
Selección archivo [Elaboración propia] . . . . . . .
Contenido del archivo cargado [Elaboración propia]
Codificación [Elaboración propia] . . . . . . . . . .
Selección de la clave requerida [Elaboración propia]
Contenido codificado [Elaboración propia] . . . . .
Decodificación [Elaboración propia] . . . . . . . . .
Selección de la clave requerida [Elaboración propia]
Archivo decodificado [Elaboración propia] . . . . .
76
76
76
77
77
77
78
78
78
79
79
7.1
7.2
7.3
Arquitectura prescriptiva basada en componentes . . . . . . . . . . . 81
Arquitectura prescriptiva basada en componentes [Elaboración propia] 82
El generador de claves deja de funcionar [Elaboración propia] . . . . 83
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
65
65
66
67
68
69
70
A.1 Diagramas de casos de uso para codificación de texto mediante RSA
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
A.2 Diagramas de casos de uso para codificación de texto por bloques
mediante RSA [Elaboración propia basada en UML] . . . . . . . . .
A.3 Diagramas de casos de uso para codificación de texto mediante IDEA
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
A.4 Diagramas de casos de uso para codificación de texto por bloques
mediante el algoritmo IDEA [Elaboración propia basada en UML] .
A.5 Diagramas de casos de uso para la decodificación [Elaboración propia
basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6 Diagramas de casos de uso para la decodificación usando el algoritmo
RSA [Elaboración propia basada en UML] . . . . . . . . . . . . . . .
A.7 Diagramas de casos de uso para la decodificación usando el algoritmo
IDEA [Elaboración propia basada en UML] . . . . . . . . . . . . . .
A.8 Diagramas de casos de uso para la consulta de ayuda [Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
A.9 Diagramas de casos de uso para la generación de llaves RSA
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
A.10 Diagramas de casos de uso para generación de números aleatorios
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
A.11 Diagramas de casos de uso para la generación de claves del algoritmo
IDEA [Elaboración propia basada en UML] . . . . . . . . . . . . . .
A.12 Diagramas de casos de uso para la generación de subclaves de
codificación del algoritmo IDEA [Elaboración propia basada en UML]
A.13 Diagramas de casos de uso para la generación de subclaves de
decodificación algoritmo IDEA [Elaboración propia basada en UML]
A.14 Diagramas de casos de uso para el almacenamiento de archivos
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
A.15 Diagramas de casos de uso para la generación de llaves [Elaboración
propia basada en UML] . . . . . . . . . . . . . . . . . . . . . . . . .
A.16 Diagramas de casos de uso para procesamiento del texto de entrada
[Elaboración propia basada en UML] . . . . . . . . . . . . . . . . . .
B.1
B.2
B.3
B.4
Arquitectura prescriptiva basada en componentes . . . . . .
Operaciones IConsultarAyuda [Elaboración propia] . . . . .
Diagrama de secuencia CU018. Generar Llaves [Elaboración
Operaciones interfaces de negocio . . . . . . . . . . . . . . .
. . . . .
. . . . .
propia]
. . . . .
88
90
92
94
96
98
100
101
103
105
107
109
111
113
115
117
119
119
120
120
C.1 Refinamiento CU010. Consultar Ayuda [Elaboración propia] . . . . . 121
C.2 Diagrama de secuencia CU018. Generar Llaves [Elaboración propia] 122
D.1 Diagrama de realización componente GestorArchivo [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
D.2 Diagrama de realización componente GestorInformacion [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
D.3 Diagrama de realización componente ComponenteMatematico
[Elaboración propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
E.1 Diagrama intra-componente del GestorArchivo [Elaboración propia]
viii
125
E.2 Diagrama intra-componente del GestorInformacion [Elaboración
propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
E.3 Diagrama
intra-componente
del
ComponenteMatematico
[Elaboración propia] . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
ix
c 2015 Yuliban Fernando Penagos., Henry A. Diosa
Copyright A mi familia que con esfuerzo me ha ayudado a llegar más lejos de lo que ellos
mismos esperaban, a mis hijos, fuente diaria de motivación,a Lorena, fantástica
casualidad, apoyo incondicional y, especialmente, al director de este proyecto que
ofreció su guı́a, dedicación y tiempo para su realización.
Capı́tulo 1
Introducción
En la actualidad los sistemas de software hacen parte de la mayorı́a de actividades
que se realizan en el mundo que habitamos. Actividades que van desde ofrecer
publicidad o información hasta gestionar procesos más complejos en diferentes tipos
de compañı́as.
Este uso generalizado ha impactado en el tamaño y en el grado de complejidad
de los sistemas que a su vez ha incurrido en el surgimiento de diferentes tecnologı́as
que se adapten a las diferentes necesidades, dentro de las cuáles ha surgido el
Desarrollo de Software Basado en Componentes (DSBC) que propone la construcción
de grandes sistemas a partir de partes que puedan ser ensambladas y dar respuesta
a los requerimientos de determinado modelo de negocio.
Esta manera de desarrollo (componentes) se asimila a la manera en que se
construyen otros productos en otras áreas [6] como la industria automotriz, la
electrónica o incluso el sector de la construcción de grandes estructuras, entre
otras; por ejemplo ampliar las capacidades de un computador o repararlo es posible
sustituyendo componentes del mismo.
Lo que pretende el DSBC es generar componentes que se encarguen de ofrecer
una funcionalidad para posteriormente ensamblarse en una estructura completa.
Esta metodologı́a no solo busca disminuir la complejidad en la construcción del
sistema, gracias al uso de componentes es posible aumentar el factor de reuso del
software ya que un componente podrı́a ser usado en más de un dominio o modelo
de negocio.
La seguridad de la información es el otro aspecto que ha sido estudiado durante
las décadas recientes, especialmente a partir del surgimiento y gran auge del Internet.
El hecho es que la información viaja grandes distancias y está expuesta a ser
interceptada por personas que podrı́an resultar indeseables, y aunque la idea inicial
es impedir que se logre tener dicho acceso, el caso es que la posibilidad de que
suceda siempre está presente, por lo que se han creado algoritmos que se encargan
de esconder información a un posible atacante por medio de codificación de la misma.
1
Por medio de estos algoritmos las compañı́as pretenden proteger aquella
información que es fundamental para su continuidad y crecimiento, como por
ejemplo los estados financieros, los clientes con que cuentan, los planes de negocio,
entre otros tantos. De esta manera, en caso de que la información sea interceptada,
el tiempo y recursos que se deberán emplear para el descifrado de su contenido,
serán mayores al valor que se pueda obtener de ella.
Este proyecto se enfoca en la aplicación del DSBC a un caso particular
relacionado con la creación de una librerı́a de algoritmos criptográficos, de forma que
se vean reflejadas las bondades y caracterı́sticas que nos ofrece esta metodologı́a. En
la fase de construcción se hará uso del lenguaje de programación Oz para corroborar
su fortaleza en la realización de componentes de software.
1.1
Descripción del problema
El problema consiste en generar una abstracción que modele los algoritmos RSA e
IDEA usando el DSBC, abarcando análisis, diseño y construcción de los componentes
que se identifiquen y sean necesarios para obtener la funcionalidad que estos
algoritmos ofrecen y sirvan como artefactos iniciales que harán parte de una
librerı́a de componentes de codificación que pueda ser extendida añadiendo nuevos
componentes y reutilizando o reemplazando otros para la creación de nuevos
algoritmos o la mejora de los existentes. Los algoritmos escogidos, en un análisis
inicial comparten algunas funcionalidades que pueden ser modeladas dentro de
alguno de los componentes que se identifiquen permitiéndonos aprovechar el reuso
de componentes, una de las principales caracterı́sticas del modelo de desarrollo que
seguiremos.
2
1.2
1.2.1
Objetivos
Objetivo general
Diseñar y construir una librerı́a de componentes de codificación con los reconocidos
algoritmos RSA e IDEA usando el DSBC de manera que podamos aprovechar las
diferentes caracterı́sticas y beneficios descritos por su autor [4]. La implementación
de esta librerı́a será realizada en el lenguaje OZ usando la abstracción de componente
mediante el uso de functores propuesta por Henry Diosa [7].
1.2.2
Objetivos especı́ficos
• Analizar, diseñar, construir y, de ser posible, realizar aprovisionamiento de
los componentes que cumplirán con la funcionalidad de los algoritmos de
codificación antes mencionados.
• Construir una versión inicial de una librerı́a que en su inicio contará con
los algoritmos IDEA y RSA para que, en posteriores etapas o incluso en
otros proyectos, se desarrollen mejoras o se extiendan funcionalidades de la
librerı́a, ya sea incluyendo nuevos algoritmos o modificando y/o añadiendo
funcionalidades a los componentes existentes.
• Utilizar el lenguaje de programación OZ y su implementación de componente
mediante la definición de functor para crear y alambrar los componentes que se
identifiquen y sean requeridos para alcanzar el objetivo descrito anteriormente.
1.3
1.3.1
Marco teórico
Seguridad
Los conceptos descritos a lo largo de esta Sección, contextualizan la importancia y
principales caracterı́sticas que conllevan la seguridad, para un mejor entendimiento
de la necesidad de crear y usar algoritmos de codificación.
1.3.1.1
Criptologı́a
La criptologı́a [1] se puede definir simplemente como el estudio de dos ramas ligadas:
la criptografı́a y el criptoanálisis, que se definirán posteriormente.
1.3.1.2
Criptosistema
Un criptosistema comprende el lugar y elementos necesarios para que la codificación
y decodificación sea llevada a cabo. Si se desea ser un poco más riguroso, se define
un criptosistema como una quı́ntupla (M, C, K, E, D) [8], en donde:
• M representa los mensajes en texto claro, lo que comúnmente es llamado texto
plano.
• C representa el conjunto de los mensajes que han sido cifrados, llamados
criptogramas.
3
Figura 1.1: Sistema Simétrico. [Adaptado de [1]]
• K se refiere a las posibles claves de codificación, usadas en el criptosistema.
• E es la transformación (algoritmo de codificación) aplicada al elemento
mensaje M, para convertirlo en el mensaje cifrado C.
• D se refiere a la transformación de descifrado, es decir, el proceso inverso de
la transformación E.
Todo criptosistema cumple con la siguiente condición:
Dk (Ek (m)) = m
1.3.2
Tipos de Criptografı́a según el tipo de clave
Las técnicas de criptografı́a moderna se pueden clasificar en dos tipos, según el tipo
de clave [1], estas son: Criptografı́a simétrica y criptografı́a asimétrica. En el caso de
estudio actual, el algoritmo RSA utiliza los dos tipos de criptografı́a. Esta Sección
contiene descripciones breves de las caracterı́sticas de estas técnicas.
1.3.2.1
Criptografı́a simétrica o de clave privada
La criptografı́a simétrica es el sistema más antiguo que se ha empleado. Su principal
caracterı́stica es el uso de una misma clave para codificar y para decodificar [1], como
se puede ver en la Figura 1.1.
1.3.2.2
Criptografı́a asimétrica o de clave pública
El concepto fue introducido por Whitfield Diffie y Martin Hellman a mediados de
los 70’s, con su artı́culo New directions in cryptography [9]. La criptografı́a de clave
pública propone el uso de una clave para codificar y otra para decodificar. La idea
principal de este tipo de criptografı́a, es que cualquier usuario puede tener acceso a
cualquier clave pública de otro, en una comunidad (como se puede ver en la gráfica
1.2) esta clave le servirá al usuario (por ejemplo Yuliban) para codificar un mensaje y
que solo el dueño de la clave privada pueda decodificar el mensaje. Con este sistema
se asegura la confidencialidad, al igual que con los sistemas simétricos, autenticación
y se puede realizar firma digital, además de evitar el problema de la distribución de
las claves simétricas.
4
Figura 1.2: Criptografı́a con clave pública. [Adaptado de [1]]
1.3.3
1.3.3.1
Algoritmos de Codificación
Algoritmo RSA
El algoritmo de codificación RSA, llamado ası́ por sus creadores Ron Rivest, Adi
Shamir y Led Adleman en MIT y tuvo su primera publicación en 1978 [10], y estuvo
bajo patente por los Laboratorios RSA hasta el 20 de septiembre del 2000. El
algoritmo RSA es muy popular para trasmitir datos a través de canales inseguros,
es tal vez uno de los algoritmos asimétricos mas sencillos de entender e implementar
Funcionamiento:
Los pasos para describir el algoritmo RSA, son:
1. Se escogen dos números primos p y q significativamente grandes (de más de
doscientas cifras), y se multiplican, obteniendo n = p ∗ q.
2. El receptor obtiene el valor de la función multiplicativa de Euler (ver Sección
5.7.3) (Φ(n)), que será calculada por: Φ(n) = Φ(p ∗ q) = Φ(p)Φ(q) =
(p − 1) ∗ (q − 1), esta igualdad se cumple, dado que p y q son primos entre sı́,
y cada uno de ellos es un número primo.
3. El receptor escoge un número e tal que 1 < e < Φ(n) de manera que sea primo
relativo con Φ(n), y calcula su inverso en módulo Φ(n), que será llamado d:
d = [(e(−1) )](Φ(n) )
4. La combinación de los números generados (d, n), es la llamada clave privada,
y el par de números (e, n), es la llamada clave pública.
5. El mensaje es codificado mediante la ecuación:
Enc(x) = xe (mod n),
siendo x el valor a codificar.
6. Para recuperar el mensaje, se utiliza el par de llaves privadas, y la ecuación:
Des(y) = y d (mod n),
siendo y el valor a decodificar.
5
1.3.3.2
Algoritmo IDEA
El algoritmo IDEA (International Data Encryption Algorithm) tuvo su primera
publicación en 1990 por Lai y Massey del Swiss Federal Institute of Technology. En
1992 se publicó la segunda versión, la cual es resistente a ataques de criptografı́a
diferencial, no presenta claves débiles (existe una excepción pero la probabilidad de
hallarlas es de 1 entre 296 , por lo que no es considerado como un peligro real) y
su longitud de clave hace imposible practicar un ataque por fuerza bruta [8]. Una
de sus mayores bondades es que es un algoritmo de libre distribución, lo cual lo ha
convertido en uno de los algoritmos más populares, sobre todo en Europa. Es un
algoritmo de cifrado por bloque. Usa bloques de 64 bits y claves de 128 bits. El
corazón del algoritmo son tres operaciones básicas que son:
• XOR: Operación bit a bit, que retorna 1 solo cuando uno de los dos bits es 1.
• Suma módulo 216 : Suma normal, y luego se aplica el módulo 216 .
• Producto módulo 216 + 1: Se realiza la multiplicación y se calcula el módulo
216 + 1.
Funcionamiento:
Generación de subclaves: A partir de la clave de 128 bits se generan 52 claves,
cada una de 16 bits, representadas como K0,1..i..,51 , que se necesitarán a lo largo del
algoritmo. Las primeras 8 sub claves se generan dividiendo en grupos de 16 bits la
clave de 128 bits. Para obtener las siguientes 8 sub claves (9 a la 16) se realiza una
rotación de 25 posiciones a la izquierda y se toman igual que las 8 primeras. Para
las siguientes se realiza el mismo proceso.
Pasos del algoritmo: El texto X de 64 bits a codificar, se divide en 4 partes
(XA , XB , XC , XD ) cada una de 16 bits [8]. En la Figura 1.3 se muestra el diagrama
bloques que muestra el flujo de operaciones del algoritmo.
Decodificación El proceso de descifrado se logra básicamente con la misma
estructura descrita en la Figura 1.3, solo que se utiliza una diferente selección de
subclaves. Las claves de descifrado Z0,1..i..,51 son obtenidas según lo definido en la
Tabla 1.1 [11]:
Primero es necesario cambiar de orden las subclaves (Zi ) para luego calcular
sus inversas multiplicativas (Zi−1 ) y aditivas −Zi [11] [8]. Es decir que a partir de
cada subclave debe obtenerse su inverso, sea multiplicativo o aditivo, de acuerdo a
la Tabla 1.1. En el caso de la subclave (Z49 ), por ejemplo, la tabla nos indica que
−1
se debe calcular su inverso multiplicativo que serı́a notado como (Z49
).
1.3.4
1.3.4.1
Fundamentos Matemáticos
Algoritmo de Euclides
El algoritmo de Euclides permite el cálculo del máximo común divisor (MCD) entre
dos números enteros. El algoritmo parte del teorema de la división, el cual nos dice
6
Figura 1.3: Algoritmo IDEA [Adaptado de [2] ]
Ronda
1
2
3
4
5
6
7
8
Final
Subclaves de Cifrado
Z1
Z7
Z 13
Z 19
Z 25
Z 31
Z 37
Z 43
Z 49
Z2
Z8
Z 14
Z 20
Z 26
Z 32
Z 38
Z 44
Z 50
Z3
Z9
Z 15
Z 21
Z 27
Z 33
Z 39
Z 45
Z 51
Z4
Z 10
Z 16
Z 22
Z 28
Z 34
Z 40
Z 46
Z 52
Z5
Z 11
Z 17
Z 23
Z 29
Z 35
Z 41
Z 47
Subclaves de Descifrado
Z6
Z 12
Z 18
Z 24
Z 30
Z 36
Z 42
Z 48
Z −1
49
Z −1
43
Z −1
37
Z −1
31
Z −1
25
Z −1
19
Z −1
13
Z −1
7
Z −1
1
−Z 50
−Z 45
−Z 39
−Z 33
−Z 27
−Z 21
−Z 15
−Z 9
−Z 2
−Z 51
−Z 44
−Z 38
−Z 32
−Z 26
−Z 20
−Z 14
−Z 8
−Z 3
Tabla 1.1: Subclaves (Zi ) empleadas en el algoritmo IDEA.
7
Z −1
52
Z −1
46
Z −1
40
Z −1
34
Z −1
28
Z −1
22
Z −1
16
Z −1
10
Z −1
4
Z 47
Z 41
Z 35
Z 29
Z 23
Z 17
Z 11
Z5
Z 48
Z 42
Z 36
Z 30
Z 24
Z 18
Z 12
Z6
[8]:
∀ a Z, b N existen unos únicos q, r Z, tales que : a = q • b + r, 0 ≤ r < b
La idea básica del algoritmo es realizar la división de a entre b, si el ri = 0 entonces
se dice que M.C.D.(a, b) = b. Si no, se divide q (el coeficiente) entre ri , si ri = 0
entonces M.C.D.(a, b) = ri , si no, se continúa hasta hallar un ri = 0.
El Algoritmo 1 describe una forma de implementar lo mencionado en los párrafos
anteriores[8]:
Algoritmo 1 Algoritmo de Euclides [Tomado de [8]]
i ← 1;
g[0] ← a;
g[1] ← b;
while g[i] 6= 0 do
g[i + 1] ← g[i − 1]%g[i];
end while
return (g[i − 1]);
1.3.4.2
Algoritmo Extendido de Euclides
El algoritmo extendido de Euclides, es un algoritmo muy eficiente para calcular el
MCD de dos números a y b. Para aplicar este algoritmo[8]:
• Se realiza la división de a entre b (y se deja expresado), donde a > b,
a = b • r + q.
• Si q es 0 se toma el mcd(a, b) = mcd(b, r), sino se toma b y se divide por q. Y
se continúa hasta que q = 0.
A continuación se presenta una posible implementación del algoritmo.
Algoritmo 2 Algoritmo extendido de Euclides [Tomado de [8]]
g[0] ← n; g[1] ← a;
u[0] ← 1; u[1] ← 0;
v[0] ← 0; v[1] ← 1;
i←1
while g[i] 6= 0 do
c ← g[i − 1] ÷ g[i];
g[i + 1] ← g[i − 1]%g[i];
u[i + 1] ← u[i − 1] − (c ∗ u[i]);
v[i + 1] ← v[i − 1] − (c ∗ v[i]);
i++
end while
while v[i − 1] ≥ 1 do
v[i − 1] ← v[i − 1] + n;
end while
return (v[i − 1]%n);
8
1.3.4.3
Función Multiplicativa de Euler
El objetivo de la función multiplicativa de Euler es determinar cuántos primos
relativos posee un número r.
Definición: Se define la función multiplicativa de Euler, φ(r), como el número de
números enteros mayores o iguales que 1 y menores que r que son primos relativos
con él, es decir[8]:
φ(r) = #f {s/s ≥ 1 y s < r , con : mcd(s, r) = 1}
donde # denota el cardinal conjunto.
Veamos ahora como, dado un número r, podemos calcular el valor de φ(r):
1. Si r es primo, φ(r) = r − 1
2. Si r es el producto de dos números primos entre s, o sea, r = p ∗ q con
mcd(p, q) = 1, entonces φ(r) = φ(p) ∗ φ(q)
3. Si r = p ∗ k con p primo, entonces φ(r) = pk − pk−1 = pk (p − 1)
1.4
1.4.1
Marco metodológico
Reutilización de Software
El uso de componentes de software en la construcción de sistemas permite que
software prefabricado pueda ser usado en nuevos desarrollos, contribuyendo de
manera positiva en una caracterı́stica deseable en todo software, denominada
reutilización, lo que implica que los componentes y la reutilización de software
son temas complementarios [12]; sin embargo, la reutilización de software no
necesariamente depende de si se usan o no componentes ya que es posible alcanzar
este aspecto a través de otros enfoques.
En torno al concepto de reutilización de software existen varios conceptos
generados por diferentes autores, para nuestro propósito entenderemos este concepto
de manera concreta como la capacidad de utilizar software previamente elaborado
para crear nuevos sistemas de software sin tener que partir de cero o para extender
la funcionalidad de un sistema existente.
1.4.2
Componentes
Definiciones para este concepto dentro de la literatura se encuentran muchas y
aunque existen bastantes similitudes entre cada una, es posible que la interpretación
que cada autor asigne a los aspectos descritos en su definición sea diferente.
Otro problema que surge con este término es la confusión que existe entre lo que
es un componente y lo que es un objeto y las caracterı́sticas y propiedades que los
diferencian. Posteriormente hablaremos un poco más acerca de esta cuestión. Lo
que si es posible afirmar dentro del DSBC es que el término componente es su bloque
de desarrollo fundamental. A continuación expondremos algunas definiciones.
9
1.4.2.1
Definición de componente
En esta Sección presentamos algunas definiciones de componente de diferentes
autores:
• Un componente es una unidad de composición reutilizable con interfaces de
requerimiento y de servicio y atributos de calidad, que denota una abstracción
sencilla y puede ser compuesta sin modificación [3].
• Los componentes de software reutilizables son artefactos independientes
claramente identificables que describen y desarrollan funciones especı́ficas con
interfaces claras, documentación y estado de reúso definido [12].
• Un componente es una unidad de producción de composición con interfaces
especı́ficas y dependencias explı́citas solo de contexto. Un componente puede
ser desplegado independientemente y está sujeto a composición por terceras
partes [13].
• Un componente reusable es una unidad de software independiente, desplegable,
reemplazable y reutilizable por terceras partes de acuerdo a la implementación,
especificación e interfaces bien definidas de la unidad [14].
• Un componente es una unidad de desarrollo independiente, sujeta a
composición por un tercero sin estado persistente [15].
1.4.2.2
Componentes y objetos
Szyperski define a un objeto como una unidad de ejemplificación que tiene una única
identidad y encapsula su estado y comportamiento [13], por lo que aparentemente, y
de acuerdo con las definiciones anteriores, los componentes y la tecnologı́a de objetos
cuentan con los mismos principios fundamentales, tales como los de encapsulación,
modularidad e identificadores únicos.
Sin embargo, los componentes pueden contener múltiples objetos, clases y otros
componentes, además, una caracterı́stica esencial de un componente es la capacidad
de ser usado en contextos que inicialmente pueden no haber sido anticipados por el
productor del componente, solo el usuario del componente decide si el mismo sirve
o no para un propósito particular [3]. Un componente puede contener múltiples
clases pero una clase puede ser desarrollada solamente dentro de un componente, el
desarrollo parcial de una clase dentro de un componente carece de mucho sentido
[13]; por otro lado, siendo clases pueden depender de otras clases usando el concepto
de herencia, de la misma manera que componentes dependen de otros componentes.
En este caso las superclases de una clase no necesariamente deben residir en el mismo
componente, lo que generarı́a una relación entre los componentes.
1.4.2.3
Caracterı́sticas de un componente
Como sucede con la definición, las caracterı́sticas de un componente también pueden
variar en relación al autor y la definición dada por dicho autor. A continuación
exponemos algunas de estas caracterı́sticas [12] [13] [14]:
10
• Independiente
Separado de su entorno y de otros componentes. No puede ser desarrollado de
manera parcial.
• Autocontenido
Debe ser reutilizable sin la necesidad de incluir otros componentes. Además
debe contar con especificaciones claras de lo que requiere y de los servicios que
ofrece.
• Con identificador único
Un componente debe tener una identificación clara y consistente que facilite
su catalogación y búsqueda en repositorios de componentes.
• Modularidad y encapsulación
Se refiere a la propiedad de alcance de un componente como ensamblador de
servicios que están relacionados a través de datos comunes.
• Accesible sólo a través de su interfaz
El componente debe exponer al público únicamente el conjunto de operaciones
que lo caracteriza (interfaz) y ocultar sus detalles de implementación. Esta
caracterı́stica permite que un componente sea reemplazado por otro que
implemente la misma interfaz.
• Sus servicios son invariantes
Las operaciones que ofrece un componente, a través de su interfaz, no deben
variar. La implementación de estos servicios puede ser modificada, pero no
deben afectar la interfaz.
• Documentado
Un componente debe tener una documentación adecuada que facilite su
búsqueda en repositorios de componentes, evaluación, adaptación a nuevos
entornos, integración con otros componentes y acceso a información de soporte.
Otras propiedades o caracterı́sticas deseables y que favorecen la capacidad de
reutilización de los componentes son [14]:
- La interfaz para un componente es diferente a una en un sistema de
comunicación concurrente, el cual requiere la interfaz para incluir una
descripción del protocolo de comunicación, en los componentes no es requerida
dicha descripción.
- La interfaz para un componente en una aplicación de tiempo real, debe proveer
las restricciones de tiempo real.
11
Figura 1.4: Interfaces de requerimiento y de servicio [Elaboración propia]
- Los componentes en sistemas distribuidos, móviles o basados en Internet
requieren que sus interfaces incluyan información acerca de su ubicación o
dirección.
- La interfaz de un componente no debe tener estado cuando el componente
es solicitado para ser usado dinámica e independientemente de otros
componentes.
1.4.2.4
Interfaces como contratos
Una interfaz puede ser vista como un contrato entre un cliente y un proveedor de
servicios [16], en el que se establece lo que el cliente necesita o debe hacer para usar la
interfaz de requerimiento y las implementaciones que el proveedor debe realizar para
cumplir con la funcionalidad prometida por la interfaz de servicio. Esta interacción
podemos verla en la Figura 1.4.
Un método de especificación de contratos es el de pre y poscondiciones (ver
Sección 5.1.6) para una operación, en el que el proveedor establece las pre y
poscondiciones. El cliente debe conocer y cumplir con las precondiciones antes
de solicitar un servicio, de manera que el proveedor se compromete a cumplir con
las poscondiciones estipuladas.
La funcionalidad de las operaciones depende de las pre y pos condiciones. Una
precondición limita las entradas y define un estado inicial el estado de un componente
que debe ser válido antes de que la operación sea invocada. Una poscondición
limita los parámetros de salida y define el estado final del componente que se vuelve
válido después de la invocación de la operación. La combinación de precondiciones,
invocación de la operación y poscondiciones representa la transición de un estado a
otro [3].
12
1.4.2.5
Metamodelo de componente
La Figura 1.5 muestra los conceptos asociados al metamodelo 1 de un componente.
Es un meta modelo porque no describe un componente fı́sico; muestra los principales
conceptos y relaciones de un componente. Presenta máximo dos tipos de interfaz,
una de requerimiento y otra de servicio, ambas interfaces deben ser declaradas
como públicas permitiendo de esta manera que pueda efectuarse la integración
de un componente con el entorno, de otra manera no se podrı́a conocer cómo un
componente será conectado a otro. La interfaz de servicio representa todo lo que el
componente provee a su entorno en términos de su funcionalidad (poscondiciones).
La interfaz de requerimiento constituye lo que el componente espera obtener de su
entorno para ofrecer sus servicios (precondiciones).
A partir de la definición de componente es natural que la funcionalidad o
implementación del componente deba ser efectuada de manera privada, ocultando los
algoritmos por medio de los cuales un componente logra cumplir con sus objetivos.
Las interfaces descritas se encargan de efectuar operaciones; en el caso de una
interfaz de servicio las operaciones son puntos de acceso por medio de los cuales
un cliente puede acceder a la funcionalidad de un proveedor. En una interfaz de
requerimiento las operaciones son puntos de acceso hacia proveedores asociados de
los que depende para realizar sus operaciones.
Otras actividades que influyen en la operatividad de un componente, aunque no
son partes fı́sicas del mismo, son las descripciones o documentación adicional que
conformarı́a la parte lógica del componente, como la especificación del componente
en la que se describe la capacidad funcional del componente (lo que un componente
puede hacer), las pre y pos condiciones y las excepciones, por lo que en la Figura
1.5 estas actividades se muestran diferenciadas en la parte superior de la misma.
1.4.3
Metodologı́a de diseño:
Adaptado al DSBC
Proceso de Desarrollo Unificado
En esta Sección se describen los flujos de trabajo a seguir para desarrollar software
basado en componentes. Algunos de los flujos tienen como salida modelos que a su
vez son insumos para otros. [4].
1.4.3.1
Niveles de Modelos
Los modelos son importantes si se asegura que pueden ser entendidos por varias
personas, estableciendo ciertas reglas o estándares que lo hagan comprensible. Para
este fin existe UML, una herramienta usada desde hace bastante tiempo además de
ser globalmente aceptada [4]. En este lenguaje de modelado existen tres niveles de
modelos principales:
1
El modelo es representado mediante UML [17] (Ver Sección 5.3.1).
13
Figura 1.5: Meta modelo de un componente [Tomado de [3, p.8]]
14
Figura 1.6: Flujos de trabajo en el proceso de desarrollo [Adaptado de [4, p. 27]]
1. Modelos Conceptuales:
problema.
Identifican los conceptos sobre el dominio del
2. Modelos de Especificación:
Especificación del software más no su
implementación. Descripción del exterior de los componentes.
3. Modelos de Implementación: Descripción del interior de los componentes, sus
caracterı́sticas y su implementación.
En cada uno de los flujos que se enumeran a continuación se describen los modelos
creados como insumos y salidas de cada uno.
1.4.3.2
Flujos de Trabajo
Un flujo de trabajo es una secuencia de actividades que produce un resultado
observable [18]. En la Figura 1.6 se muestra el proceso de desarrollo enmarcado
en cada uno de los flujos, además de las entradas y salidas que produce cada flujo.
En las fases que producen modelos se usará UML para la creación de los mismos.
Flujo de Requerimientos Analiza y encuentra los requerimientos funcionales
del negocio para generar el o los modelos conceptuales. En este flujo se intenta
crear una idea de las responsabilidades que el sistema tendrá y de otras que pueden
dejarse por fuera. Este flujo de trabajo genera el modelo conceptual y los modelos
de casos de uso.
UML: Casos de uso Son diagramas que representan una interacción del
usuario con el sistema y que muestran las relaciones entre el usuario y los casos
de uso que lo involucran [19].
A partir de estos diagramas pueden identificarse nuevos requerimientos
funcionales del sistema y al final de la creación de estos modelos, todos los
requerimientos deben ser cumplidos por uno o más casos de uso.
15
UML: Modelo conceptual Nos permite tener una vista más acertada del
problema que intentamos resolver y de los conceptos que están involucrados. Cuando
se desarrolle este modelo en secciones posteriores se hará una descripción más
detallada de este modelo.
Flujo de Especificación A partir del modelo de negocio y los casos de uso se
generan las primeras especificaciones y arquitecturas de componentes. También
puede tomar como entradas posibles sistemas legales, bases de datos o restricciones
técnicas existentes. A partir del análisis hecho sobre el modelo de negocio es posible
establecer la información que debe ser administrada, además de las interfaces que
son necesarias para manejar dicha información, también es posible identificar los
componentes que se necesitan para proveer determinada funcionalidad.
Modelo de Tipos del Sistema Es un modelo de especificación. Su objetivo
principal es modelar la información relevante del sistema que se prevé desarrollar.
Se efectúa con un diseño de clases pero no tiene el mismo significado del modelo
conceptual de negocio. Los principales conceptos y caracterı́sticas de este modelo
son:
• Tipo: Estereotipo usado para indicar que las clases en este modelo representan
tipos. Los tipos en este modelo no pueden contener operaciones ya que en el
solo se describe información y no software.
• Tipos de datos estructurados: En este caso es usado el estereotipo datatype
que define ciertas restricciones: el tipo de dato no puede tener asociaciones u
operaciones.
• Interfaz Tipo: Debido a que el estándar UML no permite la definición de
atributos o asociaciones dentro de su concepto de interfaz, es necesario usar una
clase estereotipada que permita que estas caracterı́sticas puedan ser descritas
dentro de la interfaz.
• Invariantes: Una invariante es lo mismo que una restricción dentro del
UML. Es como una regla que rige sobre las ejemplificaciones y a nivel de
especificación corresponde a reglas del negocio. Además, es una restricción
que aplica sobre todas las ejemplificaciones de un tipo. Es decir para cualquier
objeto componente que apoye una interfaz o cierta especificación la restricción
debe cumplirse.
Especificación de interfaces En esta especificación se describe la interfaz
junto con cualquier especificación requerida para definir lo que el componente que
ofrece dicha interfaz debe hacer.
En esta especificación debe incluirse el tipo de la interfaz, los atributos y roles de
asociación, pre y pos condiciones para las operaciones de la interfaz (especificación
de operaciones), las invariantes requeridas en la interfaz. Los principales conceptos
que se manejan dentro de la especificación de interfaces son:
16
• Paquetes de interfaz: Aquı́ se agrupa toda la especificación de una interfaz.
Es posible que este paquete requiera información de especificación de otros
paquetes por lo que puede realizar una relación de import con dichos paquetes.
Para efectuar herencia entre interfaces es necesario importar el paquete padre
dentro del paquete hijo.
• Modelo de información: Al especificar interfaces se busca definir modelos
de tipo independientes para cada interfaz, a diferencia de cuando se desea
especificar el modelo de tipo del negocio en donde se genera un modelo
integrado.
En este caso los tipos que se especifican son exclusivos para cada interfaz, por
lo que cada interfaz tiene su propia vista de la información que maneja. Por
esta razón, en la especificación los que serı́an tipos en el modelo de tipos del
negocio son Tipos de información en la especificación de interfaces.
Describe las caracterı́sticas y el comportamiento de las operaciones ası́ como las
condiciones para que las mismas se cumplan. Los principales aspectos a tener en
cuenta son:
• Firma: La firma de una operación comprende cero o más tipos de parámetros.
Este tipo puede ser una referencia a un objeto componente (generalmente a una
interfaz), un tipo de dato simple como un entero, un tipo de dato estructurado
o una colección de todos.
• Pre y pos condiciones: Expresiones booleanas que son evaluadas antes y
después de ejecutar una operación. Si la precondición no se cumple el
comportamiento es inesperado, si se cumple entonces la poscondición debe
ser cierta.
• Comportamiento transaccional: Este aspecto se refiere a conocer cuándo una
operación inicia una nueva transacción y cuando se ejecuta sobre una existente.
Si se presenta el primer caso se usará es estereotipo transaction, de lo contrario
no se inserta ningún estereotipo.
Especificación
de
operaciones
Describe las caracterı́sticas y el comportamiento de las operaciones ası́ como las
condiciones para que las mismas se cumplan. Los principales aspectos a tener en
cuenta son:
• Firma: La firma de una operación comprende cero o más tipos de parámetros.
Este tipo puede ser una referencia a un objeto componente (generalmente a una
interfaz), un tipo de dato simple como un entero, un tipo de dato estructurado
o una colección de todos.
• Pre y pos condiciones: Expresiones booleanas que son evaluadas antes y
después de ejecutar una operación. Si la precondición no se cumple el
comportamiento es inesperado, si se cumple entonces la poscondición debe
ser cierta.
17
• Comportamiento transaccional: Este aspecto se refiere a conocer cuándo una
operación inicia una nueva transacción y cuando se ejecuta sobre una existente.
Si se presenta el primer caso se usará es estereotipo transaction, de lo contrario
no se inserta ningún estereotipo.
Arquitectura Prescriptiva, Modelo de Componentes del Sistema
• Especificación de componentes:
Debido a que se desea efectuar la especificación del componente (no definir la
implementación), es necesario usar (de manera similar al caso de la interfaz)
una clase estereotipada con comp spec. En el caso de las interfaces ofrecidas
por un componente es posible usar una relación realize para describir este
aspecto. Sin embargo a nivel de especificación es más apropiado crear un
estereotipo offer que capture esta relación.
Además de describir el conjunto de interfaces que ofrece, esta especificación
debe incluir las interfaces que usa o requiere (la cuál es una restricción
arquitectural y no una elección en el diseño del componente), modelado en
este caso por una relación de uso sencilla ofrecida por UML. Esta dependencia
indica que todas las realizaciones de un componente deben usar esas interfaces.
• Modelado de Componentes mediante UML:
La extensión de UML para modelado de componentes fue propuesta Cheesman
& Daniels [4]; en ella se describen algunos aspectos a tener en cuenta cuando
se desea seguir un DSBC en un proyecto de software. Para comenzar es
importante empezar a definir una arquitectura del sistema que nos permitirá
tener una visión general del lo que será el sistema final. A continuación se
describirán brevemente algunos aspectos relacionados con este aspecto:
– Capas de arquitectura:
El uso de componentes permite mantener diferentes aspectos de un
sistema separados, de manera que sea más sencillo analizar el propósito
de cada uno de los componentes utilizados en una aplicación. Las capas
que conforman esta arquitectura son:
∗ Interfaz de usuario: Presentación de la información al usuario.
Aunque se usan componentes de interfaz no son los mismos
componentes que se desarrollarán para construir los algoritmos.
∗ Diálogo de usuario: Administración de diálogo de un usuario en su
sesión.
∗ Servicios del sistema: Capa que provee un contexto en el que
servicios generales se usan para alcanzar servicios y necesidades
particulares del sistema.
∗ Servicios de negocios: Implementación del núcleo del negocio,
información, reglas y transformaciones.
18
Figura 1.7: Capas de Arquitectura en el DSBC [Adaptado de [4, p. 11]]
La Figura 1.7 muestra una primera vista de las capas en las que podrı́an
encajarse los diferentes componentes asignando de esta manera ciertas
responsabilidades. No es necesario que la comunicación se haga siempre
entre capas adyacentes pero es importante que para acceder a la capa
de negocios se utilice un objeto componente de la capa de servicios
para mantener un bajo nivel de acoplamiento de componentes objeto
y aumentar su reusabilidad.
– Arquitectura de Componentes:
Una arquitectura de componentes es un conjunto de componentes a
nivel de aplicación, sus relaciones estructurales y sus dependencias de
comportamiento, además de ser independiente de la tecnologı́a. La
descripción de estas caracterı́sticas es la siguiente:
∗ Relaciones
estructurales:
Asociaciones
y
herencia
entre especificaciones de componentes e interfaces, y relaciones de
composición entre componentes.
∗ Dependencias de comportamiento: Relaciones entre componentes,
entre componentes e interfaces y entre interfaces. La Figura 1.8
muestra las diferentes dependencias posibles entre componentes.
• Especificación de Contratos:
Lo ideal en el uso de componentes es que las partes de un proyecto sean
exitosas al momento de ser ensambladas y empezar a trabajar juntas. Para
tal fin es necesario especificar contratos que deben cumplirse por parte del
componente y los que deben ser cumplidos por parte del cliente.
En este punto existe gran similitud con lo que sucede en empresas existentes
en el mundo real, en donde se manejan relaciones con clientes o con otras
compañı́as por medio de documentos en los que se indican las responsabilidades
y obligaciones de las partes, aunque sin especificar la manera como lo harán.
19
Figura 1.8: Dependencias entre componentes [Adaptado de [4, p. 13]]
También se incluyen las consecuencias que pueden surgir si alguna de las partes
incumple con su responsabilidad.
– Tipos de contrato (UML):
El uso de contratos en UML no es un tema nuevo, en realidad en el
diseño orientado a objetos es común el uso de estas relaciones. Los tipos
de contratos son:
1. De uso: Contrato entre el componente y sus clientes.
2. De realización: Contrato entre el componente (especificación) y su
implementación.
Al mantener estos aspectos aparte se pretende facilitar los posibles
cambios que surjan posteriormente en el sistema. De esta manera, un
cambio en un contrato de realización no afecta un contrato de uso por lo
que el cliente no sufre con cada modificación al sistema. A continuación
se describen con mayor claridad los tipos de contrato existentes:
Contratos de Uso:
Describe la relación entre un cliente y la interfaz de un componente.
Dentro de la especificación de una interfaz se debe incluir:
∗ Operaciones: Lista de operaciones que la interfaz provee.
∗ Modelo de información:
Definición abstracta de cualquier
información o estado y cualquier restricción sobre dicha información.
Cada operación se trata como si fuese un contrato. Por lo que es necesario
definir entradas, salidas, relación entre operaciones y las condiciones bajo
las cuales aplica. Las operaciones están definidas por:
∗ Precondición: Definición de condiciones sobre las cuáles la post
condición aplicará.
∗ Post condición: Descripción de los efectos de la operación sobre sus
parámetros y el modelo de información.
20
El cliente debe asegurar que cumple la precondición de una operación,
al aceptar un contrato está de acuerdo en que, si la precondición no se
cumple, los resultados esperados no se darán. Por otro lado, el proveedor
debe asegurar el cumplimiento de la postcondición si la precondición se
cumple.
Contratos de Realización:
Son contratos que se efectúan entre una especificación de un componente
y su implementación y se incluye dentro de la propia especificación del
componente.
Es posible que se defina como la implementación debe interactuar con
otros componentes. Estas interacciones pueden ser definidas por medio
de diagramas de colaboración o usando restricciones entre los modelos de
información de las interfaces usadas.
Flujo de Provisión A partir de la especificación de componentes este flujo
debe encargarse de establecer qué componentes es necesario construir o adquirir
(comprar). También es posible analizar si los componentes existentes requieren
modificaciones para satisfacer la funcionalidad que requiere el problema. En caso
que el componente no exista se deben efectuar los diseños correspondientes además
de la construcción del mismo.
Diagramas inter-componente Diagramas que describen las relaciones
existentes entre componentes, principalmente las relaciones entre las interfaces de
sistema y la respectiva interfaz de negocio.
Diagramas intra-componente Flujo de mensajes entre los objetos que
existen dentro de los componentes que se implementan.
Modelos estructurales intra-componente Son modelos que describen los
objetos que hacen parte de cada componente. Se desarrollarán como diagramas de
clases.
Diagramas de realización A partir de la arquitectura prescriptiva y de la
tecnologı́a en la que se va a desarrollar la solución, surgen estos diagramas que nos
indican cuál será la implementación tecnológica de las abstracciones de cada uno de
los componentes obtenidos en el flujo de especificación.
Arquitectura Descriptiva Finalmente se obtiene la arquitectura descriptiva,
muchas veces similar a la prescriptiva pero con las caracterı́sticas, detalles y
restricciones de la tecnologı́a que se haya seleccionado para la implementación. En
estos modelos se ensamblan los componentes detallando aspectos tecnológicos del
sistema.
21
Flujo de Ensamble En esta etapa se integran los componentes junto con sistemas
de software existente y con la interfaz del cliente que satisfaga y cumpla las
condiciones del negocio.
Finalmente el sistema es liberado.
1.4.4
UML 2.x
Debido al veloz desarrollo de la industria del software la versión de UML
debió ser actualizada como respuesta a dicha evolución [17]. En esta Sección
describiremos brevemente algunos aspectos actualizados que se centran en los
diagramas de componentes, tema principal de nuestro proyecto, razón por la cual
las modificaciones a otros modelos serán tenidas en cuenta dentro del diseño pero
no serán descritas aquı́.
1.4.4.1
Diagramas de Componentes en UML
Estos diagramas muestran las dependencias entre componentes de software
[5]. Permiten modelar la arquitectura del dominio del problema, el diseño de
conFiguración y la infraestructura técnica del sistema [Ambler 1998].
Directrices: Los principales aspectos a tener en cuenta al momento de modelar
componentes son:
• Aplicar nombres descriptivos a los componentes arquitecturales.
• Aplicar estereotipos consistentes.
• No usar estos diseños para modelar datos e interfaces de usuario.
• Usar el estereotipo component o el sı́mbolo de componente para todo el diseño
de manera consistente. También es posible usar tanto el sı́mbolo como el
estereotipo a la vez para identificar a un componente, como se ve en el
componente order de la Figura 1.9. Lo importante es mantener la misma
notación durante todo el diseño.
• Mostrar solo las interfaces relevantes (por ejemplo las relacionadas al objetivo
del modelo) para mantener el diseño lo más simple posible.
La Figura 1.9 muestra algunos elementos gráficos del UML utilizados en el
modelamiento de un diagrama de componentes.
Directrices para las relaciones de dependencia y de herencia: Los
componentes tendrán relaciones entre sı́ o con otras interfaces, además las interfaces
pueden tener relaciones con otras interfaces. Las relaciones se representan con lı́neas
discontinuas y con puntas de flechas abiertas. Las principales directrices que se
aplican a este aspecto del diseño son:
• Modelar dependencias de derecha a izquierda.
• Poner los componentes padres sobre los componentes hijos (herencia).
• Los componentes solo deben tener dependencia con interfaces.
22
Figura 1.9: Diagrama de componentes para un sistema de comercio electrónico.
[Tomado de [5, p.133]]
1.5
1.5.1
Marco tecnológico
Lenguaje Oz
Este lenguaje no es un lenguaje corriente ya que no se centra en un solo paradigma
de programación como otros, sino que soporta varios. Las principales caracterı́sticas
de este lenguaje son:
- Oz combina las principales caracterı́sticas de la programación orientada a
objetos (POO): estado, tipos de datos abstractos, clases, objetos y herencia.
- Oz provee caracterı́sticas de la programación funcional como sintaxis
compositiva y procedimientos de primera clase.
- Oz provee las principales caracterı́sticas de la programación lógica y la
programación por restricciones por medio de variables lógicas, construcciones
disyuntivas y estrategias de búsqueda.
- Oz es un lenguaje concurrente donde los usuarios pueden crear dinámicamente
cualquier número de hilos secuenciales que pueden interactuar entre sı́.
Estas caracterı́sticas permiten utilizar las bondades, facilidades y potencial que
ofrece cada paradigma dentro de un mismo desarrollo de software. Este lenguaje
posee una implementación conocida como Sistema de Programaciòn Mozart [20].
1.5.1.1
Reseña histórica (Sistema de Programación Mozart)
Mozart está basado en el lenguaje de programación Oz.
Fué desarrollado
inicialmente por Gert Smolka y su grupo de investigación en la Saarland University
a inicios de los 90’s y bautizado en sus inicios como DFKI OZ. Posteriormente surgió
un grupo denominado Mozart Consortium integrado por representantes de varias
universidades del mundo. En 2005 la responsabilidad de administración de esta
plataforma se transfirió a la Mozart Board (Junta de Mozart), un grupo pequeño de
personas que se encarga de decidir cambios y mejoras sobre la plataforma y hacerlos
conocer a los desarrolladores.
Las mejoras pueden ser propuestas por cualquier persona en el mundo, después de
23
pasar ciertos filtros las propuestas llegan a la junta para que decida cuáles serán
implementadas.
1.5.1.2
Functores
Un functor es la realización tecnológica de lo que en Ingenierı́a de Software
se denomina como componente: Es una unidad de instalación o despliegue
independiente, con autonomı́a de ejecución ası́ sea desarrollada por terceros y no
tiene estado persistente [13]. En la terminologı́a del lenguaje de programación Oz,
los functores son unidades de compilación que pueden ser manejadas en archivos,
tanto en forma de código fuente como en forma de código objeto; el código fuente
puede ser compilado para traducirlo a código objeto [21]
Las partes de un functor son:
1. Una parte import que especifica otros componentes que requiere para su
ejecución.
2. Una parte export que indica la interfaz del componente.
3. Una parte define en donde se especifica la funcionalidad ofrecida por el
componente.
A continuación presentamos la propuesta elaborada por Diosa [7], que
implementa la abstracción de un functor :
functor
import OtroComp1 at Archivo1.ozf
OtroComp2 at Archivo2.ozf
.
.
.
OtroCompN at ArchivoN.ozf
export op1:Operacion1 op2:Operacion2...opK: OperacionK
define
proc Operacion1...end
proc Operacion2...end
.
.
.
proc OperacionK...end
end
Esta abstracción será utilizada para la ejemplificación de los componentes
desarrollados a lo largo del proyecto, es decir que cada componente que deba ser
desarrollado (un algoritmo puede contar con mas de un componente) se basará
en esta abstracción; en la Figura 1.10 se puede ver un modelo que describe la
abstracción y su relación con functores que requiere (definida por su sección import).
24
Figura 1.10: Estereotipado de notación de componentes en UML 2.x como functor
[Elaboración propia].
25
Capı́tulo 2
Fase de Requerimientos:
Modelo funcional basado en
casos de Uso
A continuación se detalla el modelo funcional del sistema a través de los casos de uso
que lo describen, además de los requerimientos tanto funcionales como no funcionales
que se identifican a partir del caso de estudio planteado para este proyecto. La
especificación de los casos de uso se realizará mediante diagramas de actividades
[22]
2.1
Especificación de requerimientos
2.1.1
Requerimientos funcionales
En esta Sección se realiza la descripción de los requerimientos funcionales
identificados:
ID
REQF 1
REQF 1.1
REQF 1.2
REQF 1.3
REQF 1.4
REQF
REQF
REQF
REQF
REQF
REQF
REQF
REQF
2
3
3.1
3.2
4
4.1
4.2
5
DESCRIPCIÓN DE REQUERIMIENTOS
El sistema debe permitir al usuario cargar archivos en el sistema.
El sistema debe permitir al usuario seleccionar un archivo para codificar.
El sistema debe estar en la capacidad de cargar un archivo con extensión txt y mostrarlo al
usuario.
El usuario debe poder cargar los archivos de las claves que desea usar de acuerdo al tipo de
codificación (RSA o IDEA) a realizar.
El usuario debe poder cargar los archivos de las claves que desea usar de acuerdo al tipo de
decodificación (RSA o IDEA) a realizar.
El usuario debe poder almacenar archivos de texto planos.
El sistema debe permitir al usuario seleccionar el tipo de codificación a efectuar.
El sistema debe permitir al usuario seleccionar IDEA para realizar la codificación..
El sistema debe permitir al usuario seleccionar RSA para realizar la codificación.
El sistema debe permitir al usuario seleccionar el tipo de decodificación a efectuar.
El sistema debe permitir al usuario seleccionar IDEA para realizar la decodificación.
El sistema debe permitir al usuario seleccionar RSA para realizar la codificación. txt.
El sistema debe codificar archivos de texto. txt.
26
ID
DESCRIPCIÓN DE REQUERIMIENTOS
REQF 5.1
REQF 5.2
REQF 5.3
El sistema debe permitir realizar la codificación mediante el algoritmo IDEA.
El sistema debe permitir realizar la codificación mediante el algoritmo RSA.
El sistema debe mostrar al usuario el resultado de la codificación.
El sistema debe permitir al usuario almacenar en un archivo de texto plano el resultado de la
codificación.
El sistema debe decodificar archivos de texto. txt.
El sistema debe permitir realizar la decodificación mediante el algoritmo IDEA.
El sistema debe permitir realizar la decodificación mediante el algoritmo RSA.
El sistema debe mostrar al usuario el resultado de la decodificación.
El sistema debe permitir al usuario almacenar en un archivo de texto plano el resultado de la
decodificación.
El sistema debe permitir al usuario seleccionar el tipo de las claves que deben generarse para
posteriormente realizar la codificación - decodificación.
El sistema debe permitir seleccionar IDEA para generar las claves de codificación.
El sistema debe permitir seleccionar RSA para generar las claves de codificación.
El sistema debe generar las claves necesarias para realizar la codificación. txt.
El sistema debe generar la clave pública del algoritmo RSA.
El sistema debe crear un archivo de texto con extensión rsak cuyo contenido sea la clave pública
para el algoritmo RSA.
El sistema debe generar un número aleatorio que posteriormente será usado para obtener la
matriz de claves para la codificación de texto mediante IDEA.
El sistema debe crear un archivo de texto con extensión ideak cuyo contenido sea el número
aleatorio que servirá como insumo para crear las claves del algoritmo IDEA.
El sistema debe generar las claves necesarias para realizar la decodificación seleccionada por
el usuario. txt.
El sistema debe generar la clave privada del algoritmo RSA.
El sistema debe crear un archivo de texto con extensión rsak cuyo contenido sea la clave
privada para el algoritmo RSA.
El sistema debe permitir al usuario acceder a una ayuda asociada con el funcionamiento el
mismo.
El sistema debe ofrecer al usuario información asociada a los algoritmos que hacen parte de la
librerı́a.
REQF 5.4
REQF
REQF
REQF
REQF
6
6.1
6.2
6.3
REQF 6.4
REQF 7
REQF
REQF
REQF
REQF
7.1
7.2
8
8.1
REQF 8.2
REQF 8.3
REQF 8.4
REQF 9
REQF 9.1
REQF 9.2
REQF 10
REQF 11
Tabla 2.1: Tabla de requerimientos funcionales para el algoritmo genético.
2.1.2
Requerimientos no funcionales
ID
REQNF 1
REQNF 1.1
REQNF
REQNF
REQNF
REQNF
1.2
2
2.1
3
REQNF 3.1
REQUERIMIENTOS NO FUNCIONALES
IMPLEMENTACIÓN.
El aplicativo debe desarrollarse bajo el paradigma de la programación basada
en componentes.
Los componentes deben ser desarrollados en el lenguaje de programación OZ.
INTERFAZ DE USUARIO.
Las interfaces de usuario del aplicativo estarán en idioma español.
EXTENSIBILIDAD.
Será posible añadir fácilmente nuevos algoritmos u otras funcionalidades
mediante la creación de nuevos componentes.
27
ID
REQNF 4
REQNF 4.1
REQNF 5
REQNF 5.1
REQNF 5.2
REQNF 5.3
REQNF 5.4
REQNF 6
REQNF 6.1
REQUERIMIENTOS NO FUNCIONALES
MANTENIBILIDAD.
La optimización o mejoramiento de funcionalidades se podrá hacer sin
grandes impactos ya sea cambiando un componente por otro o cambiando
funcionalidades dentro de los componentes desarrollados.
DOCUMENTACIÓN.
Se deben documentar los requerimientos del sistema; estos estarán
modularizadas describiendo aspectos tanto funcionales como no funcionales
del sistema.
Se especificarán los artefactos de casos de uso, para lo cual se usará el
formato extendido que incluye los escenarios del mismo usando diagramas
de actividades.
Se especificarán las interfaces del sistema detallando las operaciones de las
mismas.
Se especificarán los artefactos de la arquitectura prescriptiva y su
correspondiente arquitectura descriptiva.
REUSABILIAD.
Debe ser posible reutilizar componentes, tanto para los algoritmos aquı́
desarrollados como en la inclusión de algoritmos nuevos en el ambiente MozartOZ.
Tabla 2.2: Tabla de requerimientos no funcionales
28
2.2
Diagrama general de casos de uso
A continuación se describe el modelo genera de los casos de uso identificados
Figura 2.1 a partir del análisis de requerimientos efectuados anteriormente.
Figura 2.1: Diagrama general de casos de uso del AG [Elaboración propia]
2.2.1
Descripción de los casos de uso, modelo extendido
A continuación haremos una descripción detallada de los CU CU001 - Cargar
Archivo, CU002 - Codificar y CU007 - Decodificar. Los diagramas relacionados
con los demás cases de uso pueden ser consultados en el Anexo A.
29
CU001 - Cargar Archivo La Figura 2.2 muestra el diagrama de casos de uso
para la carga de archivos en el sistema, tanto para que el usuario aplique alguna
codificación o decodificación como para cargar las llaves de cada algoritmo.
Figura 2.2: Diagramas de casos de uso para la carga de archivos [Elaboración propia
basada en UML]
30
Formato extendido
Nombre Caso de Uso: Cargar Archivo
Código Caso de Uso: CU001
Actores: Usuario
Descripción: El usuario desea cagar un archivo, el sistema le provee una ventana para
que el usuario pueda realizar la búsqueda del archivo que desea cargar.
Referencias Cruzadas a Requerimientos: REQF1, REQF1.1, REQF1.2, REQF1.3,
REQF1.4
Referencias Cruzadas a CU: CU002, CU007
Precondiciones: Ninguna
Escenario:
Poscondiciones: El archivo es cargado por el sistema y mostrado al usuario usando el
componente GUI apropiado.
Prioridad: Normal
31
CU002 - Codificar La Figura 2.3 muestra el diagrama de casos de uso para la
codificación de texto.
Figura 2.3: Diagramas de casos de uso para codificación de texto [Elaboración propia
basada en UML]
32
Formato extendido
Nombre Caso de Uso: Codificar
Código Caso de Uso: CU002
Actores: Usuario
Descripción: El usuario desea codificar el archivo que ha cargado en el sistema.
Referencias Cruzadas a Requerimientos: REQF1, REQF1.1, REQF5, REQF5.1,
REQF5.2, REQF5.3
Referencias Cruzadas a CU: CU001, CU003, CU004, CU005, CU006
Precondiciones: Debe existir un archivo cargado en el sistema. Deben cargarse las llaves
con las que se desea codificar.
Escenario:
Poscondiciones: El archivo es codificado y mostrado al usuario en un componente GUI
apropiado.
Prioridad: Normal
33
CU007 - Decodificar La Figura 2.4 muestra el diagrama de casos de uso para
la decodificación de texto.
Figura 2.4: Diagramas de casos de uso para la decodificación [Elaboración propia basada
en UML]
34
Formato extendido
Nombre Caso de Uso: Decodificar
Código Caso de Uso: CU007
Actores: Usuario
Descripción: El usuario desea decodificar el archivo que ha cargado en el sistema.
Referencias Cruzadas a Requerimientos: REQF4, REQF4.1, REQF4.2, REQF5.3,
REQF6, REQF6.1, REQF6.2, REQF6.3, REQF6.4
Referencias Cruzadas a CU: CU001, CU003, CU004, CU005, CU006
Precondiciones: Debe existir un archivo cargado en el sistema. Deben cargarse las llaves
con las que se desea decodificar.
Escenario:
Poscondiciones: El archivo es decodificado y mostrado al usuario en un componente
GUI apropiado.
Prioridad: Normal
35
2.3
Modelo conceptual de negocio
En este modelo identificamos los principales conceptos del problema que se encuentra
en desarrollo y está representado por medio de un diagrama de clases (UML) que
nos permite también establecer las relaciones entre los conceptos obtenidos; no es
un modelo de software pero es importante para realizar un acercamiento inicial al
problema y a los conceptos involucrados en el mismo. El modelo conceptual de
nuestro negocio puede verse en la Figura 2.5.
2.3.1
Descripción de Conceptos
• Librerı́a Criptográfica: Contiene diferentes algoritmos para codificación y
decodificación (IDEA y RSA inicialmente). Por medio de ella el usuario puede
acceder a los diferentes tipos de cifrado.
• Algoritmo de codificación: Generalización, concepto que agrupa los
diferentes algoritmos que pueden ser usados para codificar / decodificar.
• IDEA: Algoritmo de codificación por bloque, se encarga del cifrado de
archivos y textos cortos.
• RSA: Algoritmo asimétrico de codificación, funciona para codificar textos
cortos.
• Aleatorio: Las claves de los algoritmos seleccionados se basan en la
generación de números aleatorios.
• p, q: Valores que deben ser primos entre sı́ y son utilizados para la generación
de las llaves.
• n, d, e: Valor que debe obtenerse para la generación de claves en el algoritmo
RSA.
• Clave: Generalización, concepto que agrupa el concepto de claves, concepto
presente en todo algoritmo de codificación.
• ClaveRSA: Contiene las claves necesarias para el funcionamiento del
algoritmo RSA.
• ClavePublicaRSA, ClavePrivadaRSA: Claves que se usan para codificar
- decodificar usando el algoritmo RSA.
• ClaveIDEA: Contiene las claves necesarias para el funcionamiento del
algoritmo IDEA.
• ClaveCodificacionIDEA: Como su nombre lo indica, concepto que se refiere
a la clave que es usada al realizar una codificación con el algoritmo IDEA.
• ClaveDecodificacionIDEA: Como su nombre lo indica, concepto que se
refiere a la clave que es usada al realizar una decodificación con el algoritmo
IDEA.
36
• Subclave: Concepto en el que se basa toda el proceso de generación de claves
de codificación - decodificación del algoritmo IDEA.
• AlgoritmoMatematico: Generalización, concepto que agrupa los algoritmos
que se requieren para alcanzar la funcionalidad de los algoritmos.
• Función de Euler: Operación que permite generar un número primo
necesario para el proceso de codificación.
• Inverso: Generación del número (denominado como ”d” en el algoritmo RSA)
utilizado para el proceso de decodificación.
• Multiplicacion: Operación en la que se realiza la multiplicación entre dos
variables y se calcula el modulo 216 + 1.
• Suma: Similar a la multiplicación, se realiza una suma en lugar de una
multiplicación.
• XOR: Operación bit a bit, que retorna 1 solo cuando uno de los dos bits es 1.
• TestDeFermat: Verifica si dos números son probablemente primos.
• Archivo: Concepto relacionado con la carga y almacenamiento de archivos.
37
Figura 2.5: Modelo conceptual [Elaboración propia basada en UML]
38
Capı́tulo 3
Fase de Especificación:
Identificación de Componentes
y Arquitectura Prescriptiva
En esta Sección se describen las interfaces y componentes que harán parte del sistema
y se realizará la arquitectura prescriptiva a partir de los elementos identificados a
partir de este análisis.
3.1
Identificación de interfaces
A continuación se describen las interfaces y operaciones que el sistema debe proveer
para cumplir con el objeto del negocio, que en nuestro caso se centra en la
codificación y decodificación de archivos.
3.1.1
Interfaces del sistema
Las interfaces del sistema se obtienen a partir de los casos de uso identificados en el
análisis efectuado en la Sección 2.
De acuerdo a la metodologı́a de diseño escogida para este proyecto (DSBC [4])
son estas las interfaces con las que la interfaz gráfica del usuario debe interactuar en
la capa de lógica de negocio. Es decir, cuando la lógica de un caso de uso requiera
mostrar información o notificar al sistema de una acción de usuario, la capa de
diseño (interfaz gráfica o GUI) debe usar la interfaz del sistema que contenga la
operación que cumpla con el flujo del caso de uso. Esta a su vez usa la respectiva
interfaz y operación definida en la lógica del negocio.
En la Sección 3.3.1 se describen estas interfaces.
3.1.2
Interfaces del negocio
Las interfaces de negocio son independientes de la interfaz gráfica del usuario; son
abstracciones de la información que debe ser administrada por el sistema.
39
Para identificar estas interfaces debemos refinar el modelo de conceptos descrito
en la Sección 2.3 y que solo describe la información importante del dominio del
problema y convertirlo en un modelo en el que se especifique la información que
debe ser sostenida y monitoreada por el sistema. Este último se denomina modelo
de “tipos” del sistema.
3.1.2.1
Modelo de Tipos
El modelo de tipos se representa por un diagrama de clases en el que cada clase es
un tipo por lo que cada una se encuentra marcada con el estereotipo “type”. En
este diagrama debemos identificar los elementos “core” o núcleos del sistema que
son aquellas entidades que no tienen dependencias obligatorias. Para cada una de
estas entidades “core” se añaden la interfaces de negocio que posteriormente serán
refinadas para añadir las operaciones que soportarán.
Las entidades núcleo del sistema nos permiten además, identificar algunos
posibles componentes que harán parte de la arquitectura inicial del sistema. La
Figura 3.1 muestra el diagrama de tipos obtenido a partir del modelo conceptual.
3.1.3
Identificación de las operaciones de negocio
Con el fin de identificar las operaciones para las interfaces de negocio identificadas
en la Sección 3.1.2, se toma cada operación de las interfaces del sistema y se elaboran
uno o más diagramas de secuencia que muestren los flujos de ejecución que resultan
en llamados a las interfaces de negocio y se especifica la operación (junto con
su firma) que debe existir en dicha interface para cumplir con la funcionalidad
requerida.
Estos diagramas son conocidos como diagramas de secuencia intercomponentes
y se detallan a continuación, teniendo en cuenta que hacen parte de la arquitectura
prescriptiva por lo que serán refinadas en al Sección 4.2 para incluir las restricciones
de la tecnologı́a seleccionada además de otros detalles que puedan no ser incluidos
en la etapa que actualmente nos ocupa.
3.1.3.1
Diagramas de secuencia intercomponente
En esta Sección se muestra la interacción existente entre la vista y las interfaces de
negocio que responden a la funcionalidad requerida. Partiendo de estos diagramas
nos es posible establecer las operaciones que deben existir en cada una de las
interfaces de negocio y su firma respectiva.
A continuación se muestran los diagramas de las interacciones para las interfaces
de sistema ICargarArchivo, IAlmacenarArchivo, ICodificar e IDecodificar, si desea
información asociada a las demás interfaces dirı́jase al Anexo B.
Diagramas intercomponente ICargarArchivo e IAlmacenarArchivo
Como se puede ver las Figuras 3.2 y 3.3 muestran las operaciones que debe soportar
la interface de negocio IGestorArchivo y que se resumen en la Figura 3.4.
40
Figura 3.1: Modelo de tipos elementos core y sus interfaces de negocio [Elaboración
propia]
41
Figura 3.2: Diagrama de secuencia CU001. Cargar Archivo [Elaboración propia]
Figura 3.3: Diagrama de secuencia CU017. Almacenar Archivo [Elaboración propia]
42
Figura 3.4: Operaciones IGestorArchivo [Elaboración propia]
Diagramas intercomponente ICodificar e IDecodificar Las Figuras 3.5 y 3.6
nos permiten obtener las operaciones de las interfaces de negocio ICodificadorRSA
e ICodificadorIDEA y que podemos ver en la Figura 3.7.
43
Figura 3.5: Diagrama de secuencia CU002. Codificar [Elaboración propia]
44
Figura 3.6: Diagrama de secuencia CU006. Decodificar [Elaboración propia]
45
Figura 3.7: Operaciones ICodificadorRSA e ICodificadorIDEA [Elaboración propia]
3.1.3.2
Modelo de ”tipos” refinado
En la Figura 3.1 se identificaron las interfaces de negocio de nuestro sistema,
posteriormente, en la sección 3.1.3, se identificaron las operaciones de las interfaces
identificadas. En la Figura 3.8 podemos ver el modelo de tipos refinado que ya
cuenta con las firmas de las operaciones que deberán soportar nuestras interfaces de
negocio.
3.2
Especificación de la arquitectura (prescriptiva)
basada en componentes
Partiendo del análisis efectuados en los apartados anteriores, en donde se realizó la
identificación de conceptos, interfaces de sistema e interfaces de negocio, se procede a
realizar el diagrama conceptual de los componentes que harán parte del sistema, ası́
como la relación existente entre dichos componente para, de esta manera, obtener la
arquitectura prescriptiva de nuestro sistema. La Figura 3.9 muestra la arquitectura
obtenida.
Cabe destacar que ninguno de los diseños en esta etapa contienen restricciones
de tipo tecnológico por lo que pueden ser implementados en cualquier plataforma
y/o lenguaje de programación.
Figura 3.9: Arquitectura prescriptiva basada en componentes [Elaboración propia]
En azul podemos identificar componentes que podrán ser reutilizados cuando se
46
Figura 3.8: Modelo de tipos [Elaboración propia]
47
esté realizando la implementación de la librerı́a.
3.3
3.3.1
Especificación de componentes
Especificación de interfaces
A continuación se muestran los diagramas con las interfaces tanto de negocio como
del sistema, sus operaciones y la información que mantendrán.
3.3.1.1
Interfaces de sistema
Figura 3.10: Interface de sistema ICodificar [Elaboración propia]
Figura 3.11: Interface de sistema IDecodificar [Elaboración propia]
Figura 3.14: Interface de sistema ICargarArchivo [Elaboración propia]
Figura 3.15: Interface de sistema IGenerarLlaves [Elaboración propia]
48
Figura 3.12: Interface de sistema IConsultarAyuda [Elaboración propia]
Figura 3.13: Interface de sistema AlmacenarArchivo [Elaboración propia]
49
3.3.1.2
Interfaces de negocio
Figura 3.16: Interface de negocio IGestorOperacionesMatematicas [Elaboración propia]
Figura 3.17: Interface de negocio IGestorArchivo [Elaboración propia]
50
Figura 3.18: Interface de negocio IGeneradorClave [Elaboración propia]
51
Figura 3.19: Interface de negocio ICodificadorIDEA [Elaboración propia]
52
Figura 3.20: Interface de negocio ICodificadorRSA [Elaboración propia]
53
Figura 3.21: Interface de negocio IGestorNumero [Elaboración propia]
54
Capı́tulo 4
Fase de Provisión y Ensamble
de Componentes
Esta etapa consiste en la creación de los componentes descritos durante el desarrollo
del documento para cumplir los requerimientos del sistema. En esta etapa es posible
también que, dentro de lo posible, se adquieran componentes ya desarrollados y se
adapten al sistema diseñado, sin embargo inicialmente todos los componentes aquı́
descritos serán desarrollados en su totalidad.
4.1
Arquitectura descriptiva de componentes
Del análisis realizado en el capı́tulo anterior, más especı́ficamente en la Sección
3.2 en donde se muestra el modelo de componentes sin incluir información
sobre la tecnologı́a a utilizar (arquitectura prescriptiva) partimos para realizar un
acercamiento a la tecnologı́a sobre la cuál desarrollaremos los componentes, OZ en
este caso, especificando de esta manera la arquitectura descriptiva del sistema que
puede verse en la Figura 4.1.
Podemos notar en este modelo una diferenciación de los componentes existentes;
al iniciar el paso desde el mundo conceptual hacia el mundo de la implementación
(incluyendo aspectos tecnológicos a nuestros análisis conceptuales), encontramos que
es posible crear functores orientados a entregar estructuras de datos que pueden ser
ejemplificadas y que ofrecen un conjunto de operaciones que no son expuestas en la
interfaz pero que pueden ser accedidas al ejemplificar el functor. En el la Figura
4.1, dichos componentes se encuentran en color azul.
En sı́ntesis, los componentes en color amarillo me exponen la interfaz del
componente y me permiten realizar el alambrado con el resto del sistema por
medio de puertos. Los componentes en azul contienen la implementación de la
funcionalidad expuesta en dicha interfaz.
55
Figura 4.1: Arquitectura descriptiva del sistema [Elaboración propia]
56
A continuación se utilizarán modelos de realización para modelar algunos detalles
de la tecnologı́a de implementación de los componentes teniendo en cuenta:
• En OZ los componentes se modelan utilizando el concepto de functor mostrado
en la Sección 1.5.1.2
• Las interfaces se exponen usando el tipo de dato abstracto (ADT ): Port. Esta
estructura ofrece dos operaciones, una para crear el puerto y la otra para enviar
mensajes a dicho puerto. Estos puertos serán usados para que los componentes
reciban peticiones y se encarguen de resolverlas.
• La implementación de las funciones se realizará utilizando objetos
ejemplificados partiendo de clases, concepto que es igual al de otros lenguajes
de programación como Java.
• Aprovecharemos una de las principales caracterı́sticas del lenguaje; usaremos
unidos los paradigmas de POO junto con programación funcional. La razón
principal se basa en el hecho de que los algoritmos que hacen parte de la
definición de RSA e IDEA son algoritmos matemáticos y se hace más sencillo
implementarlos como funciones que como métodos de una clase. Por ejemplo
el siguiente método:
meth textToASCIICode ( Texto ? A s c i i C o d e )
A s c i i C o d e = { TextToAscii Texto }
end
En realidad se encuentra implementado en la siguiente función:
fun { TextToAscii Texto }
case
Texto o f H| n i l then { AddLeadingZeros { I n t T o S t r i n g H}
Constant }
[ ] H| T then {Append { AddLeadingZeros { I n t T o S t r i n g H}
Constant } { TextToAscii T}}
end
end
• Los nombres de las variables en OZ se declaran en formato UpperCamelCase.
4.2
Diagramas intercomponentes: refinamiento
A continuación se refinan los diagramas intercomponentes incluyendo las
restricciones tecnológicas del lenguaje y las tecnologı́as seleccionadas.
Los diagramas que se muestran a continuación son los de las interfaces de sistema
ICargarArchivo Figura 4.2, IAlmacenarArchivo Figura 4.3, ICodificar e IDecodificar.
Los demás diagramas pueden ser consultados en el Anexo C.
Refinamiento Diagramas intercomponente Refinamiento de los diagramas
intercomponente de ICargarArchivo Figura 4.2 e IAlmacenarArchivo Figura 4.3.
57
Figura 4.2: Refinamiento CU001. Cargar Archivo [Elaboración propia]
Refinamiento Diagramas intercomponente Refinamiento de los diagramas
intercomponente de ICodificar 4.4 e IDecodificar 4.5.
58
Figura 4.3: Refinamiento CU017. Almacenar Archivo [Elaboración propia]
59
Figura 4.4: Refinamiento CU002. Codificar [Elaboración propia]
60
Figura 4.5: Refinamiento CU006. Decodificar [Elaboración propia]
61
4.3
Modelos de Realización de Interfaces
Estos modelos muestran cómo, en la tecnologı́a de componentes que usaremos para
el desarrollo del sistema, un componente “realiza” una especificación de componente
y cómo una interfaz “realiza” un tipo de interfaz. El objetivo es modelar detalles
de la implementación de los componentes que serán desarrollados.
En esta Sección se muestran los diagramas de realización de interfaces
de los componentes CodificadorIDEA, CodificadorRSA y GeneradorClave; para
información acerca de los otros componentes dirigirse al Anexo D.
Componente CodificadorIDEA En la Figura 4.6 podemos ver el modelo de
realización del CodificadorIDEA.
Componente CodificadorRSA En la Figura 4.7 podemos ver el modelo de
realización del CodificadorRSA.
Componente GeneradorClave
realización del GeneradorClave.
En la Figura 4.8 podemos ver el modelo de
62
Figura 4.6: Diagrama de realización componente CodificadorIDEA [Elaboración propia]
63
Figura 4.7: Diagrama de realización componente CodificadorRSA [Elaboración propia]
64
Figura 4.8: Diagrama de realización componente GeneradorClave [Elaboración propia]
4.4
4.4.1
Modelado intra-componente
Modelos estructurales
Los modelos estructurales representan las clases que harán parte de cada uno de los
componentes del sistema y las relaciones existentes entre ellas. De manera análoga
a la Sección Figura 4.3 en las Figuras 4.9, Figura 4.10 y Figura 4.11 se presentan
los modelos estructurales de los componentes CodificadorIDEA, CodificadorRSA y
GeneradorClave. En el Anexo E se encuentran los modelos restantes.
4.4.1.1
Diagramas de clases
Figura 4.9: Modelo estructural CodificadorIDEA [Elaboración propia]
65
Figura 4.10: Modelo estructural componente CodificadorRSA [Elaboración propia]
66
Figura 4.11: Modelo estructural componente GeneradorClave [Elaboración propia]
67
4.5
Modelos dinámicos intra-componente
Para modelar el comportamiento interno de los componentes usaremos diagramas de
secuencia. Estos diagramas nos permitirán detallar las interacciones entre los objetos
que hacen parte del componente y el intercambio de mensajes entre que existen entre
ellos de manera secuencial para lograr alguna funcionalidad del sistema.
Los diagramas que se muestran a continuación muestran el flujo de mensajes para
las funcionalidades del sistema de codificar usando el algoritmo RSA Figura 4.12,
decodificar usando el algoritmo RSA Figura 4.13 y generar llaves Figura 4.14.
Figura 4.12: Diagrama de secuencia para la codificación utilizando RSA [Elaboración
propia basada en UML]
68
Figura 4.13: Diagrama de secuencia para la codificación usando IDEA[Elaboración
propia basada en UML]
69
Figura 4.14: Diagrama de secuencia para la generación de llaves [Elaboración propia
basada en UML]
70
Capı́tulo 5
Modelado de la Interfaz Gráfica
de Usuario y estructura de CD
5.1
Diagrama de navegación
El componente visual del sistema es sencillo, con las funcionalidades necesarias para
permitir al usuario codificar, decodificar, cargar y guardar archivos, además de
realizar la generación de llaves.
El desarrollo de este aspecto del sistema se realizó con QTk, módulo que usa
descripciones (descriptions) para definir interfaces de usuario [23].
En la Figura 5.1 podemos ver el diagrama que resume las posibles interacciones
del usuario con el sistema.
Figura 5.1: Mapa de navegación Sistema de codificación [Elaboración propia]
71
5.2
Estructura de CD
El CD anexo a este documento contiene el código fuente y las fuentes de los
diagramas generados en cada una de las fases de desarrollo.
La estructura del mismo se puede ver en la figura 5.2.
Figura 5.2: Estructura del CD anexo [Elaboración propia]
72
Capı́tulo 6
Manual de instalación y de
usuario Librerı́a Criptográfica
6.1
6.1.1
Manual
de
desarrolladores)
configuración
(dirigido
a
Requerimientos hardware para instalación
El sistema desarrollado requiere un hardware convencional ya que no usa demasiados
recursos para su ejecución:
• Procesadores Intel Pentium 4, Intel Core Duo o Xeon; SSE2 como mı́nimo.
• Velocidad de procesamiento 2,2 GHz como mı́nimo; se recomienda Hyperthreading (HHT) o multinúcleo.
• Memoria RAM de 2GB mı́nimo, recomendado 4GB dependiendo del sistema
operativo se requiere hasta 8GB.
• 150MB para instalación de las herramientas en disco duro.
También es posible la ejecución sobre una máquina virtual que reúnan las
caracterı́sticas anteriores.
6.1.2
Requerimientos de software para instalación
Los requerimientos básicos para el funcionamiento de la librerı́a son:
• Mozart 1.4.0.
• GNU Emacs.
• ant (Opcional, para compilación y creación del ejecutable).
La instalación ha sido probada en los siguientes sistemas operativos:
• Windows 7 Sp1.
• Ubuntu 14.04 (32 bits).
73
6.1.3
Procedimiento para instalación (dirigido a desarrolladores)
El procedimiento para la instalación varı́a dependiendo del sistema operativo sobre
el cual se realizará la instalación, de esta manera para sistemas basados en Linux
se hace uso de la terminal y del administrador de paquetes correspondiente (Yum o
APT).
6.1.3.1
Instalación Ant
Para la compilación del software y la generación del ejecutable se crean un conjunto
de instrucciones que son ejecutadas usando [24]. Esta instalación es opcional ya que
la compilación puede hacerse functor por functor o clase por clase, al igual que la
generación del ejecutable.
Debido a que no es una parte crucial en el funcionamiento del software no se
detalla su instalación en el presente documento, la instalación se puede encontrar
en: http://ant.apache.org/manual/install.html.
6.1.3.2
Instalación Mozart OZ 1.4.0 sobre Linux (Ubuntu)
Las instrucciones de instalación junto con todos sus fuentes están en [25]; a
continuación referenciamos dicha documentación para la versión 1.4.0. Es necesario
comentar que la documentación oficial tiene los links desactualizado.
• Abra el Ubuntu Software Center (USC de ahora en adelante) busque e instale
el paquete mozart.
• Abra el USC busque e instale el paquete mozart-stdlib.
• Opcional: Abra el USC busque e instale el paquete mozart-docs
• Desde el mismo USC, busque e instale GNU/EMACS.
Solución de problemas
Could not load functor at URL: x-oz://system/wp/QTk.ozf Es posible
que el paquete con la librerı́a estándar de Mozart OZ no haya sido instalado,
asegúrese de haberlo hecho.
6.1.3.3
Instalación Mozart OZ 1.4.0 sobre Windows
• Descargue el ejecutable http://sourceforge.net/projects/mozart-oz/
files/v1/1.4.0-2008-07-04-windows/
• Instale el archivo descargado tal como lo harı́a con cualquier otra aplicación.
• Dirı́jase a la url http://ftp.gnu.org/gnu/emacs/windows/ y descargue
Emacs (emacs-24.3-bin-i386.zip).
• Descomprima el archivo en C:\Program Files (x86)\y cambie el nombre a
”Emacs”. De la misma manera a la carpeta dentro de esta dele el nombre de
”emacs”.
74
• Vaya al ”Panel de Control” ”Sistema y Seguridad” y seleccione la opción
”Configuración Avanzada del Sistema”.
• De click en ”Variables de Entorno” y cree una nueva entrada con
esta información:
Variable:
OZEMACS Valor:
C:\Program Files
(x86\Emacs\emacs\bin\runemacs.exe
6.1.4
Código fuente y generación de ejecutable
El código fuente del aplicativo puede ser encontrado en https://github.com/
yupegom/ComponentesCriptograficos. Se puede descargar un archivo .zip o usar
git [26] para obtenerlo.
Si se cuenta con ant simplemente hay que ir a la ruta en la que se descargó
o descomprimió el programa, ingresar a la carpeta ”ComponentesCriptograficos” y
ejecutar ant.
Lo que hace ant es leer el archivo compilarFunctores.compile y ejecutar las lı́neas
descritas en ese archivo. En caso de que se encuentre en Linux debe renombrar el
archivo compilarFunctores ubuntu.compile a ”compilarFunctores.compile” para
que la compilación y la generación del ejecutable se haga desde ahı́.
6.2
Manual de instalación (orientado a usuario final)
En este caso simplemente dirı́jase al CD anexo, ingrese al folder
ComponentesCriptograficos/Interfaz/Gui.
Si está sobre Windows lance el ejecutable GHI.exe. Si está sobre Ubuntu abra
la terminal y ejecute el comando ./GUI.exe.
El uso del sistema es bastante sencillo, sin embargo, en caso de requerir ayuda
adicional, el sistema contiene una opción de Ayuda que podrá resolver inconvenientes
relacionados con la usabilidad del mismo o el funcionamiento de los algoritmos
desarrollados.
6.3
Manual de usuario
A continuación se muestra un ejercicio de codificación y decodificación usando el
algoritmo RSA para ilustrar el uso de la librerı́a.
1. Generar las claves usando RSA
75
Figura 6.1: Generación de claves RSA [Elaboración propia]
Figura 6.2: Generación de claves RSA [Elaboración propia]
2. Seleccionar el archivo a codificar
Figura 6.3: Selección archivo [Elaboración propia]
76
Figura 6.4: Selección archivo [Elaboración propia]
Figura 6.5: Contenido del archivo cargado [Elaboración propia]
3. Dar click en Codificar y selecciona la clave necesaria para codificar (para RSA
debe ser la clave pública).
Figura 6.6: Codificación [Elaboración propia]
77
Figura 6.7: Selección de la clave requerida [Elaboración propia]
Figura 6.8: Contenido codificado [Elaboración propia]
4. Dar click en Decodificar y selecciona la clave necesaria para codificar (para
RSA debe ser la clave privada).
Figura 6.9: Decodificación [Elaboración propia]
78
Figura 6.10: Selección de la clave requerida [Elaboración propia]
Figura 6.11: Archivo decodificado [Elaboración propia]
79
Capı́tulo 7
Conclusiones
A lo largo de este documento y con base en los artefactos asociados y generados
a partir del problema que se planteó resolver, se buscó principalmente desarrollar
un producto de software utilizando una metodologı́a que en la teorı́a nos ofrecı́a
una variedad de caracterı́sticas deseables en cualquier proyecto de este tipo como
la extensibilidad, la mantenibilidad, la reusabilidad, entre otras, y verificar en la
práctica los beneficios de seguir este proceso de desarrollo.
A partir del modelo de la arquitectura descriptiva descrita en la Sección 4.1
podemos notar que estas caracterı́sticas pueden ser aplicables disminuyendo los
riesgos de modificar o agregar funcionalidades al sistema; Un ejemplo puede asociarse
al aspecto relacionado con el mantenimiento del sistema, ya que es posible, a
partir del diagrama desarrollado (y su correspondiente implementación), afirmar
que cada componente puede manipularse de manera aislada sobre uno o más
componentes afectando de manera mı́nima el resto de funcionalidades que no
requieran modificaciones. Otro claro ejemplo tiene que ver con la reusabilidad; en
este caso existen varios componentes que son reutilizados, disminuyendo la creación
de funcionalidades que puedan existir ya en alguno de los componentes. De la
misma manera podemos imaginar un escenario realista en el que se desee agregar un
nuevo algoritmo de codificación, es posible que alguna de las operaciones requeridas
para codificar o generar las claves del mismo se encuentren ya implementadas en
el componente matemático. En caso de no ser ası́ es posible entonces tomar este
componente, extenderlo y reemplazarlo sin necesidad de manipular o afectar los
demás componentes del sistema.
Para ilustrar los aspectos relacionados con la extensibilidad y la mantenibilidad
del sistema podrı́amos devolvernos unos cuantos capı́tulos en el documento hasta
la Sección 3.2 donde obtuvimos nuestra arquitectura prescriptiva, Figura 3.9 y que,
para facilitar la lectura incluimos nuevamente en la Figura 7.1. Como vemos en dicha
figura, hay algunos componentes en color verde que fácilmente sustentan nuestra
afirmación de la capacidad de reutilización de los componentes del sistema. Pero,
¿Qué hay con la mantenibilidad y la extensibilidad?
80
Figura 7.1: Arquitectura prescriptiva basada en componentes [Elaboración propia]
Para responder dicha pregunta podrı́amos pensar en un escenario relacionado
con el componente GestorArchivo. Este componente ofrece una caracterı́stica más
que deseada y es que no solo puede ser usado para la Librerı́a que desarrollamos si no
que serı́a de utilidad para cualquier sistema que requiriera cargar un archivo de texto
en memoria y mostrarlo en algún componente visual o hacer algún procesamiento
con el mismo. Sin embargo tiene una limitante, solo carga archivos de texto plano
(*.txt), que para el alcance de nuestro sistema es una limitante aceptable. Si, por
ejemplo se desea realizar la codificación de otro tipo de archivos, digamos, *.pdf, el
mismo componente puede ser extendido para cumplir esta funcionalidad sin afectar
la funcionalidad actual.
Para lograrlo el componente deberı́a ser extendido con una nueva interfaz que
permita a los clientes de la misma, indicar qué tipo de archivos desea procesar. La
implementación de dicha interfaz podrı́a reusar la funcionalidad de la interfaz actual,
añadiendo el algoritmo necesario para alcanzar el procesamiento de los nuevos tipos
de archivo. El diseño por componentes nos permite que este artefacto no solo sea
extendido con una funcionalidad nueva sino que los componentes que operan con
la funcionalidad actual sigan operando hasta que se decida migrar hacia la nueva
implementación. La Figura 7.2 ilustra la idea descrita.
¿Y si encontramos un componente nuevo, con mayores funcionalidades? Si
la interfaz es igual, serı́a tan sencillo como cambiar un componente por otro (en
OZ serı́a modificar un archivo *.ozf por otro). En otro caso los componentes que
requieren a este nuevo componente deben alinear sus interfaces de requerimiento
con las interfaces de provisión de este nuevo componente. Este procedimiento
puede realizarse de manera incremental hasta reemplazar totalmente el componente
”antiguo” haciendo que el funcionamiento del sistema no se vea afectado durante el
acoplamiento del nuevo componente, de la misma manera a como fue descrito en el
apartado anterior, con la diferencia de que no es solo la interfaz la que cambia sino
el componente en su totalidad.
81
Figura 7.2: Arquitectura prescriptiva basada en componentes [Elaboración propia]
En cuanto a extender la Librerı́a con nuevos algoritmos, lo primero que se deberı́a
identificar es aquellos componentes que serı́an reutilizables, aunque probablemente
requieran ser extendidos, para las nuevas implementaciones. En este sentido es
posible que los tres componentes en verde (Figura 3.9) sean, la mayorı́a de veces,
los candidatos más evidentes; entonces incluir un nuevo algoritmo implica extender
componentes existentes (si es requerido), reutilizar funcionalidades que tal vez estén
ya desarrolladas (si es posible), y finalmente crear y alambrar los nuevos algoritmos.
De nuevo, todo esto sin afectar las funcionalidades actuales de la Librerı́a.
Todos los ejemplos descritos aplican también en la mantenibilidad del sistema.
Como se detalló en dichos ejemplos, realizar cambios en alguno de los componentes
ya sea para extender funcionalidades o para corregir errores en las existentes, no
implica afectar a todo el sistema, sino, a partes del mismo. Adicionalmente es
mucho más sencillo ubicar el pedazo del sistema que está fallando, aislarlo y corregirlo
mientras el resto de sus capacidades continúan operativas.
Para ilustrarlo vamos ahora al componente GestorClaves. En un escenario
extremo el componente deja de fallar y no me permite generar nuevas claves; sin
embargo esto no impide que con llaves que se han generado anteriormente el sistema
funcione correctamente mientras se repara el componente dañado. En la Figura 7.3
se puede ver este escenario. Adicionalmente la Figura muestra cómo el componente
puede ser aislado para ser corregido.
82
Figura 7.3: El generador de claves deja de funcionar [Elaboración propia]
Ahora bien, obtener tantos beneficios implica también mayores esfuerzos; las
etapas de diseño y creación de los componentes que harán finalmente parte del
producto en su totalidad requieren de mayor esfuerzo debido a que se debe crear
una visión del comportamiento y estructura no solo de cada uno de los componentes
si no del sistema en general y es necesario modelar y entender las interacciones que
deben existir tanto a nivel de cada componente del sistema como a nivel externo del
componente, es decir las relaciones que hay entre cada componente y que permiten
alcanzar la funcionalidad requerida.
Es ası́ que este esfuerzo puede notarse a lo largo del desarrollo del presente
documento y sus anexos, en donde se describen los diferentes artefactos generados
83
tanto a nivel externo del componente como a nivel interno (intra-componente). Cada
uno de estos modelos describe el sistema y puede ser visto y analizado tanto de
una manera general o global como de una manera un poco más individualizada.
El sistema cuenta no solo con una estructura completa si no con los modelos
estructurales de cada una de sus partes haciendo que no se requiera entender el
sistema en su totalidad para realizar cambios sobre el mismo; para tal fin basta
con conocer las interfaces que ofrece y las firmas de las mismas para mantener la
funcionalidad para la que fue construido evitando afectar las interacciones con otros
componentes del sistema.
Entonces la pregunta es, ¿Vale la pena este esfuerzo en relación a los beneficios
obtenidos? En el caso del problema que nos lanzamos a resolver podemos afirmar
que haber escogido esta metodologı́a ofrece al sistema una flexibilidad y una mayor
simplicidad en el mantenimiento del mismo, por nombrar algunas caracterı́sticas,
que no se puede obtener comparada con otras metodologı́as. Y no hablamos solo
del código generado sino de la documentación que soporta lo producido.
Sin embargo hay una limitante al desarrollar software siguiendo esta metodologı́a
y tiene que ver con la capacidad de obtener retroalimentación de las funcionalidades
que se van creando; al centrarnos en la generación de un componente durante la fase
de provisión e implementación se hace difı́cil ofrecer al usuario final una vista que
genere valor de negocio y a partir de la cual se pueda disminuir esa brecha siempre
existente entre lo que el usuario desea y lo que el sistema realmente hace.
En este sentido se podrı́a pensar en desarrollar funcionalidades en las que
intervengan varios componentes y que puedan ser socializadas en tiempos cortos
para lograr la finalidad comentada en el párrafo anterior y no dedicarse a desarrollar
un componente en particular que no pueda ser razonado y entendido por el cliente
y que al final tal vez no hace lo que realmente se esperaba, uno de los fallos más
recurrentes en la creación de software.
84
Capı́tulo 8
Trabajo Futuro
• Alambrado de componentes mediante una interface visual y que permita
hacerlo de una manera más dinámica. Una idea que surgió durante el
desarrollo era crear una herramienta que funcione de manera similar a Orange
[27] una herramienta de visualización de datos en la que existen widgets que
son arrastrados a un canvas y conectados entre si. La idea consiste en crear
los componentes de la librerı́a simulando los widgets y asociando sus interfaces
de provisión y de requerimiento mediante conectores visuales.
Orange está escrito en Phyton, un lenguaje interpretado igual que OZ por
lo que intuitivamente podrı́a ser una buena opción implementar la idea con
Orange; no se descarta que puedan haber otras herramientas visuales que
podrı́an interactuar con OZ para alcanzar este obejtivo.
• Existen bastantes y variados algoritmos de codificación, incluso versiones
mejoradas de los desarrollados en esta versión de la librerı́a. A continuación
describimos brevemente algunos algoritmos que pueden ser incluidos:
– Diffie-Hellman: Algoritmo de clave pública. Se considera seguro
cuando llaves suficientemente largas y generadores apropiados son usados.
Más información relacionada con este algoritmo en [28].
– LUc: Algoritmo de clave pública, alternativa que dice ser más segura
que el RSA. Descrito por primera vez en [29]
– SAFER: Diseñado principalmente por James Massey, quién también
hizo parte del diseño del algoritmo IDEA. Los anteriores SAFER+ y
SAFER SK usan la misma función de codificación pero difieren en el
número de rondas [30] [30].
• Caché de los archivos codificados, añadiendo un mecanismo que permita
establecer si un archivo fue codificado anteriormente y entregarlo al usuario
sin necesidad de volver a realizar el proceso completo.
• Aplicar el modelo de distribución de Mozart-OZ haciendo que los componentes
de la librerı́a se encuentren en diferentes locaciones. Aunque la librerı́a
actualmente no realiza un consumo notable de recursos, eventualmente podrı́a
crecer lo suficiente para pensar en que los componentes más exigentes pueden
estar distribuidos en máquinas con menor carga de trabajo o con mayores
capacidades. Es posible también pensar en un escenario con varias instancias
85
de un mismo componente en diferentes máquinas que son balanceadas
mediante un proxy u otro mecanismo.
Sin embargo este trabajo no solo implica lograr conectar los componentes
remotos entre si, también deben establecerse mecanismos de recuperación y
de reintentos, entre muchos otros aspectos a tener en cuenta cuando se trabaja
en un ambiente distribuido. Este serı́a el resultado más valioso ya que servirı́a
de base para otros sistemas que requieran más recursos y por lo tanto sea
inevitable que el ambiente en el que se desenvuelva sea distribuido.
• Realizar la codificación de archivos en otros formatos (pdf, xls, docx, etc).
• Implementar la librerı́a en escenarios como los de las Figuras 1.1 y 1.2 haciendo
que codifique/decodifique los paquetes de datos transferidos en un canal de
comunicación; la librerı́a actualmente está concebida solo para codificación y
decodificación de archivos localmente.
86
Anexos
87
Anexo A
Casos de uso
CU003. Codificar Mediante RSA La Figura A.1 muestra el diagrama de casos
de uso para la codificación de texto utilizando el algoritmo RSA.
Figura A.1: Diagramas de casos de uso para codificación de texto mediante RSA
[Elaboración propia basada en UML]
88
Formato extendido
Nombre Caso de Uso: Codificar Mediante RSA
Código Caso de Uso: CU003
Actores: Usuario
Descripción: El usuario codificar un texto con el algoritmo de codificación RSA.
Referencias Cruzadas a Requerimientos: REQF1, REQF1.1, REQF1.3, REQF3,
REQF3.2, REQF5, REQF5.2, REQF5.3
Referencias Cruzadas a CU: CU019, CU004
Precondiciones: Debe existir un archivo cargado en el sistema. Deben cargarse las llaves
con las que se desea codificar.
Escenario:
Poscondiciones: El archivo es codificado con el algoritmo RSA mostrado al usuario en
un componente GUI apropiado.
Prioridad: Normal
89
CU004. Codificar Bloques RSA La Figura A.2 muestra el diagrama de casos
de uso para la codificación por bloques realizada al usar el algoritmo RSA.
Figura A.2: Diagramas de casos de uso para codificación de texto por bloques mediante
RSA [Elaboración propia basada en UML]
90
Formato extendido
Nombre Caso de Uso: Codificar Bloques RSA
Código Caso de Uso: CU004
Actores: Sistema
Descripción: El sistema divide los bloques del texto insertado por el usuario y los codifica
uno a uno para al final concatenarlos de nuevo ya con el texto completo codificado.
Referencias Cruzadas a Requerimientos: REQF3, REQF3.2
Referencias Cruzadas a CU: CU003
Precondiciones: Debe existir un archivo cargado en el sistema. Deben haberse cargado
las llaves con las que se desea codificar.
Escenario:
Poscondiciones: Se concatenan los bloques codificados y genera el texto
Prioridad: Normal
91
CU005. Codificar Mediante IDEA La Figura A.3 muestra el diagrama de
casos de uso para la codificación por bloques realizada al usar el algoritmo IDEA.
Figura A.3: Diagramas de casos de uso para codificación de texto mediante IDEA
[Elaboración propia basada en UML]
92
Formato extendido
Nombre Caso de Uso: Codificar Mediante IDEA
Código Caso de Uso: CU005
Actores: Usuario, Sistema
Descripción: El usuario selecciona y carga un archivo para codificar, selecciona el tipo
de codificación con la que desea procesar el texto y da click en codificar.
Referencias Cruzadas a Requerimientos: REQF1, REQF1.1, REQF1.2, REQF1.3,
REQF3, REQF3.1, REQF5, REQF5.1, REQF5.3
Referencias Cruzadas a CU: CU006
Precondiciones: Debe existir un archivo cargado en el sistema. Deben haberse cargado
las llaves con las que se desea codificar.
Escenario:
Poscondiciones: Se muestra al usuario el resultado de la codificación
Prioridad: Normal
93
CU006. Codificar Bloque IDEA La Figura A.4 muestra el diagrama de casos
de uso para la codificación por bloques realizada al usar el algoritmo RSA.
Figura A.4: Diagramas de casos de uso para codificación de texto por bloques mediante
el algoritmo IDEA [Elaboración propia basada en UML]
94
Formato extendido
Nombre Caso de Uso: Codificar Bloque IDEA
Código Caso de Uso: CU006
Actores: Sistema
Descripción: El sistema recibe los bloques del texto seleccionado por el usuario y los
codifica uno a uno para concatenarlos al final.
Referencias Cruzadas a Requerimientos: REQF3, REQF3.1, REQF5, REQF5.1
Referencias Cruzadas a CU: CU005, CU010
Precondiciones: Debe existir un texto para codificar, deben existir las llaves adecuadas
para realizar la codificación.
Escenario:
Poscondiciones: Se muestra al usuario el resultado de la codificación
Prioridad: Normal
95
CU008.Decodificar Mediante RSA La Figura A.5 muestra el diagrama de
casos de uso para la decodificación de texto utilizando el algoritmo de decodificación
RSA.
Figura A.5: Diagramas de casos de uso para la decodificación [Elaboración propia
basada en UML]
96
Formato extendido
Nombre Caso de Uso: Decodificar Mediante RSA
Código Caso de Uso: CU008
Actores: Usuario, Sistema
Descripción: El usuario carga un archivo en el sistema y da click en decodificar mediante
RSA.
Referencias Cruzadas a Requerimientos: REQF4, REQF4.2, REQF6, REQF6.2,
REQF6.3
Referencias Cruzadas a CU: CU009, CU019
Precondiciones: Debe existir un texto para decodificar, deben existir las llaves adecuadas
para realizar la decodificación.
Escenario:
Poscondiciones: Se muestra al usuario el resultado de la decodificación
Prioridad: Normal
97
CU009. Decodificar Bloques RSA La Figura A.6 muestra el diagrama de
casos de uso para la decodificación de texto por bloques cuando se utiliza RSA para
decodificar.
Figura A.6: Diagramas de casos de uso para la decodificación usando el algoritmo RSA
[Elaboración propia basada en UML]
98
Formato extendido
Nombre Caso de Uso: Decodificar Bloques RSA
Código Caso de Uso: CU009
Actores: Sistema
Descripción: El sistema toma los bloques del texto y los decodifica uno a uno para al
final concatenarlos.
Referencias Cruzadas a Requerimientos: REQF4, REQF4.2, REQF6, REQF6.2,
REQF6.3
Referencias Cruzadas a CU: CU008
Precondiciones: Debe existir un texto para decodificar, deben existir las llaves adecuadas
para realizar la decodificación.
Escenario:
Poscondiciones: Se obtienen los bloques decodificados y concatenados
Prioridad: Normal
99
CU010. Decodificar Mediante IDEA La Figura A.7 muestra el diagrama de
casos de uso para la decodificación de texto mediante IDEA.
Figura A.7: Diagramas de casos de uso para la decodificación usando el algoritmo IDEA
[Elaboración propia basada en UML]
100
Formato extendido
Nombre Caso de Uso: Decodificar Mediante IDEA
Código Caso de Uso: CU010
Actores: Usuario, Sistema
Descripción: El usuario selecciona un texto y da click en decodificar mediante IDEA.
Referencias Cruzadas a Requerimientos: REQF4, REQF4.1, REQF6, REQF6.1,
REQF6.3, REQF6.4
Referencias Cruzadas a CU: CU006
Precondiciones: Debe existir un texto para decodificar, deben existir las llaves adecuadas
para realizar la decodificación.
Escenario:
Poscondiciones: Se muestra al usuario el resultado de la decodificación realizada.
Prioridad: Normal
CU011. Consultar Ayuda La Figura A.8 muestra el diagrama de casos de uso
para mostrar información relacionada con los algoritmos.
Figura A.8: Diagramas de casos de uso para la consulta de ayuda [Elaboración propia
basada en UML]
101
Formato Extendido
Nombre Caso de Uso: Consultar Ayuda
Código Caso de Uso: CU011
Actores: Usuario, Sistema
Descripción: El usuario consulta la descripción de alguno de los algoritmos de la librerı́a
o con el funcionamiento del sistema.
Referencias Cruzadas a Requerimientos: REQF10, REQF11
Referencias Cruzadas a CU: CU001
Precondiciones: Ninguna
Escenario:
Poscondiciones: Se muestra al usuario la información solicitada.
Prioridad: Normal
102
CU012. Generar Llaves RSA La Figura A.9 muestra el diagrama de casos de
uso para generar las llaves del algoritmo RSA.
Figura A.9: Diagramas de casos de uso para la generación de llaves RSA [Elaboración
propia basada en UML]
103
Formato extendido
Nombre Caso de Uso: Generar Llaves RSA
Código Caso de Uso: CU012
Actores: Usuario, Sistema
Descripción: El usuario desea genera las claves para el algoritmo RSA.
Referencias Cruzadas a Requerimientos: REQF7, REQF7.2, REQF8, REQF8.1,
REFQ8.2, REFQ9, , REFQ9.1, REFQ9.2
Referencias Cruzadas a CU: CU013, CU018
Precondiciones: Seleccionar RSA para generar las llaves
Escenario:
Poscondiciones: Se crea un archivo con las claves privada y pública del algoritmo RSA.
Prioridad: Normal
104
CU013. Generar Numero Aleatorio La Figura A.10 muestra el diagrama de
casos de uso para generar números aleatorios que posteriormente serán usados en la
generación de claves.
Figura A.10: Diagramas de casos de uso para generación de números aleatorios
[Elaboración propia basada en UML]
105
Formato extendido
Nombre Caso de Uso: Generar Numero Aleatorio
Código Caso de Uso: CU013
Actores: Sistema
Descripción: El sistema genera números aleatorios para la generación de las llaves.
Referencias Cruzadas a Requerimientos: REQF7, REQF7.1, REQF7.2, REQF8,
REQF8.1, REFQ8.2, REFQ9, REFQ9.1, REFQ9.2
Referencias Cruzadas a CU: CU012, CU014
Precondiciones: Ninguna
Escenario:
Poscondiciones: Se generan aleatorios en memoria.
Prioridad: Normal
106
CU014. Generar clave IDEA La Figura A.11 muestra el diagrama de casos de
uso para generar las claves del algoritmo IDEA.
Figura A.11: Diagramas de casos de uso para la generación de claves del algoritmo
IDEA [Elaboración propia basada en UML]
107
Formato extendido
Nombre Caso de Uso: Generar clave IDEA
Código Caso de Uso: CU014
Actores: Usuario, Sistema
Descripción: El usuario desea generar las claves para la codificación con IDEA.
Referencias Cruzadas a Requerimientos: REQF7, REQF7.1, REQF8, REQF8.3,
REFQ9
Referencias Cruzadas a CU: CU013, CU015, CU016
Precondiciones: Ninguna
Escenario:
Poscondiciones: Se genera el archivo con un aleatorio que posteriormente será usado
para crear las subclaves de codificación y decodificación
Prioridad: Normal
108
CU015. Generar Subclaves IDEA La Figura A.12 muestra el diagrama de
casos de uso para generar las subclaves para realizar la codificación con el algoritmo
IDEA.
Figura A.12: Diagramas de casos de uso para la generación de subclaves de codificación
del algoritmo IDEA [Elaboración propia basada en UML]
109
Formato extendido
Nombre Caso de Uso: Generar Subclaves IDEA
Código Caso de Uso: CU015
Actores: Sistema
Descripción: El sistema toma como entrada un número aleatorio generado previamente,
a partir de el genera las claves descritas en el algoritmo.
Referencias Cruzadas a Requerimientos: REQF7, REQF7.1, REQF8, REQF8.3,
REFQ9
Referencias Cruzadas a CU: CU014
Precondiciones: Tener cargado en memoria el número del que se parte para generar las
claves
Escenario:
Poscondiciones: Se generan el arreglo de claves necesarias para la codificación
Prioridad: Normal
110
CU016. Generar Subclaves Descifrado IDEA La Figura A.13 muestra el
diagrama de casos de uso para generar las subclaves para realizar la decodificación
con el algoritmo IDEA.
Figura A.13: Diagramas de casos de uso para la generación de subclaves de
decodificación algoritmo IDEA [Elaboración propia basada en UML]
111
Formato extendido
Nombre Caso de Uso: Generar Subclaves Descifrado IDEA
Código Caso de Uso: CU016
Actores: Sistema
Descripción: El sistema toma como entrada un número aleatorio generado previamente,
a partir de el genera las claves descritas en el algoritmo y luego aplica el procedimiento
requerido para, a partir de las claves de cifrado, obtener las de descifrado.
Referencias Cruzadas a Requerimientos: REQF7, , REQF7.1, REQF8, REQF8.3,
REFQ9
Referencias Cruzadas a CU: CU014
Precondiciones: Tener cargado en memoria el número del que se parte para generar las
claves
Escenario:
Poscondiciones: Se generan el arreglo de claves necesarias para la decodificación
Prioridad: Normal
112
CU017. Almacenar Archivo La Figura A.14 muestra el diagrama de casos de
uso para almacenar archivos.
Figura A.14: Diagramas de casos de uso para el almacenamiento de archivos
[Elaboración propia basada en UML]
113
Formato extendido
Nombre Caso de Uso: Almacenar Archivo
Código Caso de Uso: CU017
Actores: Usuario, Sistema
Descripción: El usuario decide almacenar un archivo.
Referencias Cruzadas a Requerimientos: REQF2
Referencias Cruzadas a CU: CU002, CU007, CU018
Precondiciones: Seleccionar el path de almacenamiento
Escenario:
Poscondiciones: Se crea un archivo en el path seleccionado por el usuario
Prioridad: Normal
114
CU018. Generar Llaves La Figura A.15 muestra el diagrama de casos de uso
para generación de archivos.
Figura A.15: Diagramas de casos de uso para la generación de llaves [Elaboración propia
basada en UML]
115
Formato extendido
Nombre Caso de Uso: Generar Llaves
Código Caso de Uso: CU018
Actores: Usuario, Sistema
Descripción: El usuario desea genera las llaves de codificación y decodificación
Referencias Cruzadas a Requerimientos: REQF7, REQF7.1, REQF7.2, REQF8,
REQF8.1, REQF8.2, REQF8.3, REQF8.4, REQF9, REQF9.1, REQF9.2
Referencias Cruzadas a CU: CU011, CU012, CU017
Precondiciones: Ninguna
Escenario:
Poscondiciones: Se crea un archivo en el path seleccionado por el usuario con el contenido
de las laves que seleccionó generar.
Prioridad: Normal
116
CU019. Procesar Texto La Figura A.16 muestra el diagrama de casos de uso
para procesar el texto de codificación o decodificación.
Figura A.16: Diagramas de casos de uso para procesamiento del texto de entrada
[Elaboración propia basada en UML]
117
Formato extendido
Nombre Caso de Uso: Procesar Texto
Código Caso de Uso: CU019
Actores: Sistema
Descripción: El sistema procesa el texto para convertirlo a sı́mbolos numéricos o
viceversa
Referencias Cruzadas a Requerimientos: REQF5, REQF6
Referencias Cruzadas a CU: CU003, CU008
Precondiciones: Ninguna
Escenario:
Poscondiciones: Ninguna
Prioridad: Normal
118
Anexo B
Diagramas intercomponentes:
Fase de especificación,
Arquitectura Prescriptiva
Diagramas intercomponente IConsultarAyuda La Figura B.1 describe la
interacción que realiza el sistema con la interface de negocio IConsultarAyuda.
Figura B.1: Diagrama intercomponente CU010. Consultar Ayuda [Elaboración propia]
La Figura B.2 describe las operaciones identificadas para la interface
IConsultarAyuda a partir del diagrama anterior.
Figura B.2: Operaciones IConsultarAyuda [Elaboración propia]
Diagramas intercomponente IGeneradorClave Finalmente y de manera
similar, elaboramos el diagrama de secuencia para la interface de negocio
IGeneradorClave que se puede ver en la Figura B.3.
119
Figura B.3: Diagrama de secuencia CU018. Generar Llaves [Elaboración propia]
En la Figura B.4 se encuentran las operaciones de negocio de la interface
IGeneradorClave.
Figura B.4: Operaciones IGeneradorClave [Elaboración propia]
120
Anexo C
Refinamiento Diagramas
intercomponentes
Refinamiento Diagramas intercomponente IConsultarAyuda
diagrama intercomponente de la interface IConsultarInformacion
Figural C.1,
Figura C.1: Refinamiento CU010. Consultar Ayuda [Elaboración propia]
Refinamiento Diagramas intercomponente IGeneradorClave Figural C.2,
diagrama intercomponente de la interface IGenerarLlaves
121
Figura C.2: Diagrama de secuencia CU018. Generar Llaves [Elaboración propia]
122
Anexo D
Modelos de realización de
interfaces
Gestor Archivo: Figura D.1,
GestorArchivo
diagrama de realización del componente
Figura D.1: Diagrama de realización componente GestorArchivo [Elaboración propia]
Gestor Información:
GestorInformacion
Figura D.2:
propia]
Figura D.2, diagrama de realización del componente
Diagrama de realización componente GestorInformacion [Elaboración
Componente Matemático:
ComponenteMatematico
Figura D.3, diagrama de realización del componente
123
Figura D.3: Diagrama de realización componente ComponenteMatematico [Elaboración
propia]
124
Anexo E
Modelos estructurales
intra-componente
Gestor Archivo: Figura E.1, diagrama intra-componente del GestorArchivo
Figura E.1: Diagrama intra-componente del GestorArchivo [Elaboración propia]
Gestor
Información:
GestorInformacion
Figura
E.2,
Diagrama
intra-componente
del
Figura E.2: Diagrama intra-componente del GestorInformacion [Elaboración propia]
Componente Matemático:
ComponenteMatematico
Figura E.3,
125
Diagrama intra-componente del
Figura E.3:
propia]
Diagrama intra-componente del ComponenteMatematico [Elaboración
126
Bibliografı́a
[1] M. P. Martorell, Criptologı́a.
2000.
Escuela Universitária Politécnica de Mataró,
[2] “Instituto de Ingenierı́a Eléctrica (IIE),” http://iie.fing.edu.uy/ense/asign/
dsp/proyectos/1999/cripto/descripcion.html, Octubre 2011.
[3] H.-G. Gross, Component-Based Software Testing with UML Component-Based
Software Testing with UML. Springer, 2005.
[4] J. Cheesman and J. Daniels, UML Components: A Simple Process for
Specifying Component-Based Software, ser. Component Software Series.
Londres: Addison-Wesley, 2000.
[5] W. A. Scott, The elements of UML 2.0 Style. Press Syndicate of the Cambridge
University, 2005.
[6] A. Hedley, “The component industry metaphor,” in Component-based software
engineering, G. T. Heineman and W. T. Councill, Eds. Oxford: AddisonWesley Longman Publishing Co., Inc, 2001.
[7] H. A. Diosa, “Tesis de doctorado: Especificación de un modelo de
referencia arquitectural de software a nivel de configuración, estructura y
comportamiento,” Tesis de Doctorado, vol. Universidad del Valle, 2009.
[8] M. J. L. López, “E-book - criptografı́a y seguridad en computadores,” 2009.
[9] W. Diffie and M. E. Hellman, “New directions in cryptography,” IEEE
Computer Society, 1976.
[10] A. S. R.L. Rivest and L. Adleman, A method for obtaining digital signatures and
public-key cryptosystems. Communications of the ACM, 1978, pp. 120–126.
[11] W. Stallings, Cripthography and Network Security: Principles and Practice.
Prentice Hall, 1998.
[12] J. Samentinger, Software Engineering with Reusable Components.
Verlag, 1997.
Springer-
[13] C. Szyperski, Component Software, Beyond Object-Oriented Programming,
2nd ed. Addison-Wesley, 2002.
[14] J. T. Jerry Zesy Gao and Y. Wu, Testing and Quality Assurance for ComponentBased Software. Artech House, 2003.
127
[15] G. T. Leaven and M. Sitaraman, Foundations of component-based systems.
Press Syndicate of the Cambridge University, 2000.
[16] H. Jifeng, X. Li, and Z. Liu, Component-based software engineering, the need
to link methods and their theories. Springer, 2005.
[17] UML 2.0 Superstructure, 3rd Revision, OMG Object Management Group, 2004.
[18] P. Kruchten, The Rational Unified Process An Introduction, 3rd ed. Pearson,
2004.
[19] “Use case diagram,” https://en.wikipedia.org/wiki/Use Case Diagram, 2015.
[20] “The Mozart Programming System,” http://www.mozart-oz.org/, Octubre
2011.
[21] P. V. Roy and S. Haridi, Concepts, Techniques, and Model of Computer
Programming, ser. McGraw-Hill series on computer communications. MIT
Pressl, 2004. [Online]. Available: https://www.info.ucl.ac.be/∼pvr/book.html
[22] Unified Modeling Language Specification,
Management Group, 1997.
Version 1.5,
OMG Object
[23] “Qtk graphical user interface design for oz,” https://mozart.github.io/
mozart-v1/doc-1.4.0/mozart-stdlib/wp/qtk/html/index.html, 2004.
[24] “Apache ant,” http://ant.apache.org/, 2015.
[25] “Instalación mozar oz,” https://help.ubuntu.com/community/Mozart, 2015.
[26] “Git,” https://github.com/, 2015.
[27] “Data mining - fruitful and fun,” https://http://orange.biolab.si, 2015.
[28] M. Rhee, Cryptography and Secure Communications, ser. McGraw-Hill
series on computer communications. McGraw-Hill, 1994. [Online]. Available:
https://books.google.com.co/books?id=7gFrQgAACAAJ
[29] P. Smith, “Luc public key encryption: a secure alternative to rsa,” Dr. Dobb’s
Journal, vol. 18, no. 1, pp. 44–49, October 1993.
[30] “Safer,” http://en.wikipedia.org/wiki/SAFER, 2015.
128