Ingenierı́a De Software En El Modelado De Una

Red Neuronal

Orjuela Gracia Andrés David-20152020923

Ricaurte Mora José Marı́a-20162020099

19 de junio de 2019
2
Índice general

I PROYECTO 7

1. Caso De Estudio 9
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Descripcion del problema . . . . . . . . . . . . . . . . . . . . 10
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Metodologı́a 13
2.1. Modelo Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2. Fases para el modelo prototipo . . . . . . . . . . . . . . . . . 14
2.3. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

II DISEÑO 19

3. Requerimientos C 21
3.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Casos de uso de Perceptron . . . . . . . . . . . . . . . . . . . 22
3.2.1. Formulario . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2. Generar predicción . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Entrenar Red neuronal . . . . . . . . . . . . . . . . . . 24

4. Interacción 25
4.1. Diagrama de secuencias . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Formulario . . . . . . . . . . . . . . . . . . . . . . . . 25

5. Clases 27
5.1. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Diagrama de Clases del proyecto . . . . . . . . . . . . . . . . 28

3
4 ÍNDICE GENERAL

5.3. Diagrama de Clases del Formulario . . . . . . . . . . . . . . . 28

5.4. Diagrama de Clases de la red Neuronal . . . . . . . . . . . . . 29

6. Patrones 31
6.1. Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Patrones aplicados al proyecto . . . . . . . . . . . . . . . . . . 32

7. Estados 35
7.1. Diagramas de estados . . . . . . . . . . . . . . . . . . . . . . 35
7.2. Diagrama de estados aplicado al proyecto . . . . . . . . . . . 35

8. Componentes 37
8.1. Componente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Componentes para el proyecto . . . . . . . . . . . . . . . . . . 38

9. Nodos 39
9.1. Nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2. Nodos para el proyecto . . . . . . . . . . . . . . . . . . . . . . 40

10.Actividades 41
10.1. Diagrama Workflow . . . . . . . . . . . . . . . . . . . . . . . 41
10.2. Diagrama Workflow para el proyecto . . . . . . . . . . . . . . 42

III REFLEXIONES 45

11.Conclusiones 47
Índice de figuras

1.1. Notación de casos de uso . . . . . . . . . . . . . . . . . . . . . 9

1.2. Ecuacion de salida . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3. Modelo del perceptron . . . . . . . . . . . . . . . . . . . . . . 12

2.1. Tiempo estimado del desarrollo . . . . . . . . . . . . . . . . . 15

2.2. Modelo prototipo Visualmente . . . . . . . . . . . . . . . . . 16
2.3. Modelo ASD Visualmente . . . . . . . . . . . . . . . . . . . . 18

3.1. Casos de uso en general . . . . . . . . . . . . . . . . . . . . . 21

3.2. Casos de uso en general . . . . . . . . . . . . . . . . . . . . . 22
3.3. Especificación detallada . . . . . . . . . . . . . . . . . . . . . 23
3.4. Especificación detallada . . . . . . . . . . . . . . . . . . . . . 23
3.5. Especificación detallada . . . . . . . . . . . . . . . . . . . . . 24

4.1. Diagrama de secuencia del escenario primario . . . . . . . . . 26

4.2. Diagrama de secuencia del escenario secundario . . . . . . . 26
4.3. Diagrama de secuencia del escenario excepcional . . . . . . . 26

5.1. Relación entre clases para el formulario . . . . . . . . . . . . 28

5.2. Relación entre clases para la red neuornal . . . . . . . . . . . 29

6.1. Patron R-comunicación para el formulario . . . . . . . . . . . 32

6.2. Patron R-comunicación para el formulario . . . . . . . . . . . 33

7.1. Diagrama de estados de la neurona . . . . . . . . . . . . . . . 36

7.2. Patron estado aplicado a la neurona . . . . . . . . . . . . . . 36

8.1. Ejemplo de un componente en UML . . . . . . . . . . . . . . 37

8.2. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . 38

9.1. Ejemplo visual de un nodo en UML . . . . . . . . . . . . . . 40

5
6 ÍNDICE DE FIGURAS

9.2. Diagrama de nodos del proyecto . . . . . . . . . . . . . . . . 40

10.1. Ejemplo visual de una actividad de un programa . . . . . . . 42

10.2. Diagrama Workflow para Perceptron . . . . . . . . . . . . . . 42
 Parte I

PROYECTO

7
Capı́tulo 1

Caso De Estudio

1.1. Introducción

La inteligencia artificial es una de las ciencias que avanza con bastante

fuerza en la actualidad, debido a que genera nuevas técnicas y conceptos
para la solución de diferentes problemas. Para facilitar el proceso de desa-
rrollo de soluciones mediante la inteligencia artificial, se puede dar uso a la
ingenierı́a de software, el cual permitirı́a modelar las diferentes soluciones
de la inteligencia artificial.

Figura 1.1: Notación de casos de uso

9
10 CAPÍTULO 1. CASO DE ESTUDIO

Para aprovechar las virtudes de la IA en la informática es necesario

considerar la aplicación de sus técnicas en ambientes multiplataforma. Por
ende, el uso de la ingenierı́a de software serı́a una excelente solución frente
a la abstracción del modelo de aplicación en una red neuronal que busca
clasificar nuevos datos a partir de su entrenamiento previo.

1.2. Descripcion del problema

En cualquier tipo de sistema informático la entrada de datos por parte del
usuario en ocasiones representa una labor tediosa para el mismo, por ende, la
reutilización de datos previos para percibir patrones de respuesta en campos
posteriores, permitirı́a darle un tratamiento a los datos de entrada de un
sistema para lograr una predicción en las sugerencias dadas al usuario en el
momento de ingresar futuros datos; implementando un algoritmo inteligente
(red neuronal) alimentado por un conjunto de datos obtenido de ingresos de
información por parte del usuario en ocasiones anteriores.

1.3. Objetivos
Reducir el tiempo empleado por parte del usuario al momento de uti-
lizar una herramienta informática de recolección de datos.

Proporcionar al usuario una predicción lo más acertada posible a partir

de su entrenamiento previo.

Desarrollar un software que respete todos los principios de programa-

ción, que sea sólido y extendible para facilitar su implementación en
diferentes entornos de manejo de la información

1.4. Alcance del proyecto

El software que planeamos desarrollar podrá ser implementado en for-
mularios extensos en donde se cuente con un target no tan disperso. Además
se implementarán un número pequeño de neuronas que conformarán una red
neuronal simple.

El ”Perceptron”nos permitiria proporcionar al usuario una predicción a

partir de su entrenamiento previo, para esto necesitaremos enviarle mues-
tras de datos donde se evidencien caracterı́sticas propias de las clases que
1.5. CONTEXTO 11

queremos predecir; por ejemplo, podrı́amos dar ciertas caracterı́sticas de

peso,altura, edad y genero, para entrenar nuestra red, y su objetivo seria
identificar según los datos de entrada, si nuestro target es hombre o mujer
y su edad aproximada.

1.5. Contexto

La ingenieria de software y la inteligencia artificial

El diseño y desarrollo bien elaborado en su arquitectura, junto a la ex-

pansibilidad a herramientas o aplicaciones de cualquier tipo, requiere tener
en cuenta principios logico-racionales y las normas de ingenierı́a de software.
Los sistemas inteligentes o Herramientas IA, no son una excepción.

Evidentemente la inteligencia artificial (IA) está en pleno desarrollo por

ello debemos adoptar maneras de interpretar y abstraer de una manera
eficaz, la ingenierı́a de software ha adoptado este papel, sus herramientas y
las de la IA se deben integrar para permitir que este crecimiento continúe y
se facilite, además de hacerse más universal.

La red neuronal ”Perceptron”

Uno de los primeros modelos artificiales de una neurona fue inventado

en 1957 por Frank Rosenblatt, un profesor de psicologı́a en la Universidad
de Cornell. Rosenblatt diseñó un algoritmo de clasificación con aprendizaje
supervisado, es decir, un algoritmo que aprende a clasificar nuevos datos
basado en datos conocidos.

Un perceptrón es un modelo con varias entradas, que su vez son ponde-

radas, tiene un término independiente y una salida binaria que depende de
si la suma ponderada de las entradas es mayor o menor a cero. En la figura
1 podemos ver cómo se calcula la salida de un perceptrón simple.

El producto punto entre el vector W y las entradas X es el promedio

ponderado de las entradas.
Una visualización de nuestro perceptrón serı́a:
12 CAPÍTULO 1. CASO DE ESTUDIO

Figura 1.2: Ecuacion de salida

Figura 1.3: Modelo del perceptron

Los Datos
Las entradas del perceptrón pueden ser números que cuantifiquen cual-
quier cosa, teniendo en cuenta caracterı́sticas especificas de una clase (tipo
de objeto o cosa a clasificar) y algunas muestras de dichas clases.
Capı́tulo 2

Metodologı́a

2.1. Modelo Prototipo

Definición
La idea básica en el modelo ’Prototype’ es que, en lugar de congelar
los requisitos antes de que pueda proceder un diseño o codificación, se crea
un prototipo desechable para comprender los requisitos. Este prototipo está
desarrollado en base a los requisitos actualmente conocidos.

Al usar el modelo prototipo, el cliente puede tener una ”sensación real”del

sistema, ya que las interacciones con el prototipo pueden permitirle al cliente
comprender mejor los requisitos del sistema deseado. La creación de proto-
tipos es una idea atractiva para sistemas grandes y complicados para los
cuales no existe un proceso manual o un sistema existente para ayudar a
determinar los requisitos.

Justificación
Debido a que la red neuronal “Perceptron” requiere ser entrenada cons-
tantemente, el generar un nuevo prototipo ayudará a tener una mayor capa-
cidad de predicción al momento de realizar una sentencia acerca del próximo
campo del formulario, alimentando la red con los datos que ha ingresado has-
ta el momento el usuario. Esta reiteración en la revisión de sus requerimien-
tos en cada actualización del prototipo le dará un entrenamiento constante
con información crucial para disminuir el margen de error de las prediccio-
nes.

13
14 CAPÍTULO 2. METODOLOGÍA

2.2. Fases para el modelo prototipo

Diseño Rapido
El primer modelo de sistema según los requisitos y las capas de la red,
lo enfocarı́amos en especular las áreas, secciones y campos en un formulario
básico, dicho formulario permitirá la intervención del usuario de manera
parcial con el fin de controlar las entradas más importantes de la interfaz, los
datos seleccionados constituirán las neuronas que introducirán los patrones
que alimentan la red y serán utilizados posteriormente por las siguientes
capas en la red neuronal.

Desarrollo del prototipo

El desarrollo del primer prototipo será basado en los mejores resultados
obtenidos en el diseño rápido, permitiéndonos moldear la aplicación según
la experiencia de los usuarios teniendo en cuenta exactitud de predicción y
la viabilidad en el tratamiento de los datos.

Para dar un entrenamiento optimo se buscará dar la mayor flexibilidad

posible al interfaz de usuario, esto a su vez nos dará diferentes opciones
de entrenamiento a la red y la capacidad de relacionar lo aprendido por
la misma en diferentes ambientes. La constante retroalimentación de la red
nos asegura dar el mejor entrenamiento posible interrelacionando lo apren-
dido por los diferentes prototipos, el rendimiento y los comentarios de los
usuarios de prueba. Por otra parte, nos enfocaremos el tratamiento de los
inconvenientes presentados con mayor frecuencia en las diferentes versiones
y sus posibles soluciones o propagaciones.

Evaluación del prototipo por el usuario

Luego de tener un prototipo funcional, el usuario será quien basándose
únicamente en su propia información evalúe el buen funcionamiento del soft-
ware. Evidentemente en las primeras pruebas no se le dará aprobación debido
a que no existe suficiente información relevante para el buen funcionamiento
del algoritmo interno. La red neuronal irá creciendo y enriqueciéndose con
la actualización de sus versiones lo que nos permitirá evaluar y categorizar
a los prototipos que lleguen a tener un margen de error más pequeño que
los anteriores
2.2. FASES PARA EL MODELO PROTOTIPO 15

Tiempo para la realización del proyecto

Figura 2.1: Tiempo estimado del desarrollo

16 CAPÍTULO 2. METODOLOGÍA

Modelo prototipo

Figura 2.2: Modelo prototipo Visualmente

2.3. METODOLOGÍA 17

2.3. Metodologı́a
El método ágil ASD (Adaptive Software Development) en español sig-
nifica: Desarrollo Adaptable de Software, es un modelo de implementación
de patrones ágiles para desarrollo de software. Al igual que otras metodo-
logı́as ágiles, su funcionamiento es cı́clico y reconoce que en cada iteración
se producirán cambios e incluso errores.

Ciclo de vida:
Especular: Debido a que trabajaremos el procesamiento de datos por
medio de una red neuronal, tendremos como prioridad encontrar el
camino que mejor se adapte a los requerimientos del proyecto utili-
zando la misma red neuronal; para lograr esto generaremos distintos
prototipos de la aplicación, cabe aclarar que no se trataran de cambios
drásticos entre los distintos prototipos, estos últimos están encamina-
dos a encontrar los campos en donde mejor se desempeña el algoritmo
inteligente.

Colaborar: El gran flujo de información que se requiere para el entrena-

miento y funcionamiento de una red neuronal, nos lleva al tratamiento
de los datos por medio de capas y dentro de las mismas nodos que per-
mitan un fácil seguimiento a los procesos que se están llevando a cabo
en las diferentes transiciones entre capas; por otra parte el tratamiento
de información varia en las distintas capas, lo que nos permitirı́a sec-
cionar el comportamiento de entrada, salida y las capas ocultas además
de facilitar el diseño e inclusión de nuevas capas de ser necesario.

Aprender: El continuo entrenamiento de la red neuronal es vital para

el progreso del proyecto, por este motivo el seguimiento de resulta-
dos tanto positivos como negativos en la interacción del sistema con
usuarios y desarrolladores, debe darse de una manera minuciosa con
el fin de re evaluar los valores (pesos) con los que se re alimentara la
red. Un re entrenamiento a veces requiere del reestructuramiento de
prototipos o versiones con el fin de encaminar los procesos y eventos
de la mejor manera.
18 CAPÍTULO 2. METODOLOGÍA

Figura 2.3: Modelo ASD Visualmente

Integración del Open Source

Se encuentra conveniente y casi obligatorio que el código destinado a la
creación de la red de neuronas Perceptron comience a crecer en base al mode-
lo de desarrollo de software Bazar, esto debido a la filosofı́a que tiene frente
a la manera en que se construye el software. El desarrollo de una inteligencia
artificial conlleva a que se agilice el proceso de creación del software deman-
dando una verificación continua de su funcionamiento para hallar facilmente
inminentes errores, para ası́ permanecer en corrección y verificación desde el
punto de vista de diferentes usuarios. Es por eso que con el uso de platafor-
mas como GitHub se estará subiendo el código fuente para recibir crı́ticas
constructivas y seguramente mejoras para la implementación del software.
Además, debido a que la red necesita ser alimentada y el tiempo que toma
esto es representativo para cualquier desarrollador, es muy conveniente que
sea un trabajo colectivo.
Parte II

DISEÑO

19
Capı́tulo 3

Requerimientos C

3.1. Casos de uso

Definición
Un caso de uso es la descripción de una acción o actividad. Un diagra-
ma de caso de uso es una descripción de las actividades que deberá realizar
alguien o algo para llevar a cabo algún proceso. Los personajes o entidades
que participarán en un diagrama de caso de uso se denominan actores. En
el contexto de ingenierı́a del software, un diagrama de caso de uso repre-
senta a un sistema o subsistema como un conjunto de interacciones que se
desarrollarán entre casos de uso y entre estos y sus actores en respuesta a
un evento que inicia un actor principal.

Figura 3.1: Casos de uso en general

21
22 CAPÍTULO 3. REQUERIMIENTOS C

Los diagramas de casos de uso sirven para especificar la comunicación y

el comportamiento de un sistema mediante su interacción con los usuarios
y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación
entre los actores y los casos de uso en un sistema. Una relación es una
conexión entre los elementos del modelo, por ejemplo la especialización y la
generalización son relaciones. Los diagramas de casos de uso se utilizan para
ilustrar los requisitos del sistema al mostrar cómo reacciona a eventos que
se producen en su ámbito o en él mismo.

3.2. Casos de uso de Perceptron

Debido a que tenemos dos grandes sistemas que se comunican entre si,
encontramos 1 caso de uso para el formulario en el que se aplicará el algorit-
mo del segundo sistema que es el Perceptron, en donde encontramos 2 casos
de uso fundamentales que son requeridos por el formulario.

Figura 3.2: Casos de uso en general

3.2. CASOS DE USO DE PERCEPTRON 23

3.2.1. Formulario

Figura 3.3: Especificación detallada

3.2.2. Generar predicción

Figura 3.4: Especificación detallada

24 CAPÍTULO 3. REQUERIMIENTOS C

3.2.3. Entrenar Red neuronal

Figura 3.5: Especificación detallada

Capı́tulo 4

Interacción

4.1. Diagrama de secuencias

Para cualquier caso de uso existen siempre 3 escenarios distintos, los
cuales se clasifican en: Primario, Secundario y Excepcional. Es por eso que es
necesario tener un diagrama de secuencias para cada uno de estos. El sistema
Preceptron tiene una particularidad y es que en su mismo funcionamiento
existe un riguroso control por lo que todos los escenarios son manejados
implı́citamente dentro de cada capa, por esto existe una única secuencia
general que lo que hace es explicar detalladamente su funcionamiento. El
sistema formulario si cuenta con distintos escenarios, y desencadena una
secuencia distinta para cada uno.

4.1.1. Formulario
Escenario Primario
Cuando el formulario está debidamente diligenciado y los datos tienen
sentido para ser procesados.

Escenario Secundario
Cuando el formulario no es llenado por completo o un dato está erronea-
mente escrito.

Escenario Excepcional
Cuando no hay conexión con la red neuronal Perceptron.

25
26 CAPÍTULO 4. INTERACCIÓN

Figura 4.1: Diagrama de secuencia del escenario primario

Figura 4.2: Diagrama de secuencia del escenario secundario

Figura 4.3: Diagrama de secuencia del escenario excepcional

Capı́tulo 5

Clases

5.1. Diagrama de Clases

Definición
Un diagrama de clases es una herramienta para comunicar el diseño de
un programa que se creó para orientar objetos y que permite modelar rela-
ciones entre diferentes entidades.

En UML, una clase se representa con un rectángulo que posee tres divi-
siones, nombre de la clase, abributos que tiene y mensajes que entiende.

En el primero de los cuadros se anota el nombre de la clase. Si es abs-

tracta, se escribe en letra cursiva o también se utiliza un estereotipo como
¡¿arriba del nombre de la clase.

En la segunda parte van los atributos o variables de instancia; las varia-

bles de clase van subrayados.

En el último cuadro se escriben las operaciones, es decir, los mensajes

que puede entender. Lo importante es documentar los mensajes más rele-
vantes y no todos los mensajes de un solo objeto.

Debemos tener en cuenta que una clase que no tiene comportamiento

no está comunicando qué tipo de rol cumple en la solución, ası́ que o está
faltando definir qué es lo que le puedo pedir o entonces esa clase no deberı́a
estar en el diagrama.

27
28 CAPÍTULO 5. CLASES

5.2. Diagrama de Clases del proyecto

Con respecto al proyecto encontramos que se puede sintetizar en dos
grandes sistemas, los cuales son el formulario y la red neuronal Perceptron.
Para el formulario existen distintas relaciones entre clases para tratar la
información proporcionada por el usuario. Mientras que en la red neuronal
se encuentra todo el proceso extenso entre capas para que se haga una
correcta predicción. Por lo anterior, se han creado entonces dos diagramas
de clases que interactúan de tal manera que solo se encarguen de su función
sin importar que tenga que hacer su contraparte.

5.3. Diagrama de Clases del Formulario

Figura 5.1: Relación entre clases para el formulario

Clase control:Esta clase será instanciada una sola vez y va a imple-

mentar la interfaz IControl quien le dará los métodos necesarios para
envı́o y recepción de datos
Clase Formulario:Representa el formulario que vaya comunicarse con
la clase Neurona quien se encuentra ya en otro diagrama y usará la
información proporcionada independientemente
Clase Documento:Es un objeto que se instancia a partir del formulario,
el cual representa toda la información necesaria como son los espacios
completados por el usuario, para ser tratados por el Perceptron
5.4. DIAGRAMA DE CLASES DE LA RED NEURONAL 29

IControl:: Interfaz que da los métodos necesarios para un Comunicador

concreto que será intermediario en la comunicación entre el emisor y
el receptor

IFormulario: Interfaz que da los métodos necesarios para un Emisor

concreto que será quien envı́a el mensaje (en este caso un objeto Do-
cumento) al Receptor que esté esperando por un aviso por el Emisor

5.4. Diagrama de Clases de la red Neuronal

Figura 5.2: Relación entre clases para la red neuornal

Los anteriores diagramas representan la abstraccion principal del pro-

yecto, donde identificamos claramente el modelo: representado por la red
neuronal, la vista: implementada con el formulario y finalmente encontra-
mos el controlador: representado por la clase çontrol”.
30 CAPÍTULO 5. CLASES
Capı́tulo 6

Patrones

6.1. Patrones de diseño

Definición
Cuando se desarrolla una aplicación software es frecuente encontrarse en
la situación de tener que volver a resolver problemas similares a otros que
ya hemos solucionado anteriormente, y debemos volver a hacerlo partiendo
de cero una y otra y otra vez (incluso dentro del mismo proyecto).
Debido a ello y basándose en la programación orientada a objetos surgie-
ron los patrones de diseño, donde cada uno de ellos define la solución para
resolver un determinado problema, facilitando además la reutilización del
código fuente.
Dependiendo de su finalidad pueden ser:

Patrones de creación: utilizados para crear y configurar de clases y

objetos.

Patrones estructurales: su objetivo es desacoplar las interfaces e im-

plementar clases y objetos. Crean grupos de objetos.

Patrones de comportamiento: se centran en la interacción entre aso-

ciaciones de clases y objetos definiendo cómo se comunican entre sı́.

31
32 CAPÍTULO 6. PATRONES

6.2. Patrones aplicados al proyecto

En desarrollo de software, el modelamiento por medio de diagramas jun-
to a la implementación de patrones son unas de las herramientas más útiles
con las que contamos; para desarrollar el perceptron decidimos apoyarnos en
el popular modelo-vista-controlador como patrón base del proyecto, acom-
pañado de patrones de comportamiento, creacionales y estructurales, además
en algunos puntos buscaremos implementar los patrones re-estructurados
planteados en el software coloso y propuestos por el profesor(ver referen-
cias).

Patrón R-comunicación
Este patrón además de permitir identificar claramente el emisor y recep-
tor de un “mensaje” entre dos entes, para nuestro caso permite crear una
fuerte comunicación entre el formulario y la primera neurona donde se em-
pezará a estructurar de manera ordenada la información, clasificándola de
tal forma que identifique los espacios que sean relevantes para su respectivo
tratamiento por parte de las distintas capas. Es necesario que la información
viaje de manera segura y de forma dinámica, haciendo que el patrón Comu-
nicación sea un firme candidato para el envı́o y recepción de los distintos
datos del usuario a tratar.

Figura 6.1: Patron R-comunicación para el formulario

6.2. PATRONES APLICADOS AL PROYECTO 33

Patrón R-Acumulador

Figura 6.2: Patron R-comunicación para el formulario

En otras abstracciones del proyecto decidimos apoyarnos en otros pa-

trones de diseño, el patron estado nos ayuda a controlar los diferentes esta-
dos de las neuronas presentes en las capas de la red neuronal, otro patron
que se decide implementar se evidencia en la creacion de las neuronas y su
asignacion de espacio en las capas de la red, esta incluido en los patrones
re-estructurado PRS.
34 CAPÍTULO 6. PATRONES
Capı́tulo 7

Estados

7.1. Diagramas de estados

Los diagramas de estado son útiles para describir el comportamiento de
clases y sistemas que han sido concebidos haciendo uso de un modelo de
estados. En este se identifican las situaciones en la que el comportamiento
es cambiante o si existen eventos o condiciones bajo las que se pasa de una
situación a otra.

Los diagramas de estados son intensivamente utilizados en:

Sistemas de tiempo real y crı́ticos

La descripción de sistemas reactivos

La descripción de sistemas basados en protocolos

7.2. Diagrama de estados aplicado al proyecto

Para el proyecto encontramos un elemento clave que debe estar en cons-
tante cambio y es bastante beneficioso aplicarle el patrón estado, este ele-
mento es la neurona como tal, ya que depende siempre de las salidas de otras
neuronas y de su estado anterior para realizar un cambio, en este caso de
.Activada.a ”Desactivada”.

35
36 CAPÍTULO 7. ESTADOS

Figura 7.1: Diagrama de estados de la neurona

Figura 7.2: Patron estado aplicado a la neurona

Capı́tulo 8

Componentes

8.1. Componente
Definición
Un componente de software es una unidad modular de un programa
software con interfaces y dependencias bien definidas que permiten ofertar o
solicitar un conjunto de servicios o funcionales. Un componente de software
debe poseer las siguientes caracterı́sticas:

Ser reutilizable.
Ser intercambiable.
Poseer interfaces definidas.
Ser cohesivos

Figura 8.1: Ejemplo de un componente en UML

37
38 CAPÍTULO 8. COMPONENTES

8.2. Componentes para el proyecto

En el momento de modelar un sistema y los subsistemas dentro de este
es necesario identificar los componentes que representan cómo el sistema de
software está dividido; El diagrama de componentes nos permite representar
cada división independiente o subsistema como un componente y muestra las
dependencias que genere este con otros componentes. Este tipo de diagramas
son utilizados para modelar la vista estética y dinámica de un sistema mos-
trando la organización y las dependencias entre un conjunto de componentes.

Figura 8.2: Diagrama de componentes

El diagrama anterior representa los distintos componentes que se gene-

ran dentro del proyecto, cada uno enlazado a una interfaz encargada de
comunicarse con el controlador con el fin de acoplar el patrón modelo-vista
controlador. El primer componente es el “Formulario”, el cual es el encar-
gado de interactuar directamente con el usuario y capturar la información,
el formulario está directamente ligado a la interfaz correspondiente “iFor-
mulario” y esta se comunica directamente con la interfaz del controlador
“iControlador”; el segundo componente representa a la red neuronal, la cual
recibe y procesa los datos ingresados por medio de la interacción que realizan
la interfaz de la red “iRedNeuronal” y la interfaz del controlador; el compo-
nente que representa al repositorio está directamente ligado al controlador,
y se encarga de la persistencia de la aplicación.
Capı́tulo 9

Nodos

9.1. Nodo
Definición
Un nodo es un elemento fı́sico que existe en tiempo de ejecución y repre-
senta un recurso computacional con memoria y capacidad de procesamiento.
En general los nodos se utilizan para modelar la topologı́a del hardware sobre
el que se ejecuta el sistema, además cumplen con las siguientes caracterı́sti-
cas:

Representa tı́picamente un procesador o un dispositivo sobre el que se

pueden desplegar componentes.

Se pueden estereotipar y se pueden agrupar en paquetes.

Se parecen a las clases en que pueden tener atributos (velocidadPro-

cesador) y operaciones (encender).

39
40 CAPÍTULO 9. NODOS

Figura 9.1: Ejemplo visual de un nodo en UML

9.2. Nodos para el proyecto

Un diagrama de nodos o de implementación se cataloga como diagra-
ma estructural porque describe un aspecto del sistema en sı́. En este caso,
el diagrama de nodos describe la implementación fı́sica de la información
generada por el sistema de software en los componentes de hardware. A la
información que el software genera se la conoce como artefacto.

En el anterior diagrama presentamos los recursos necesarios para la im-

plementación y ejecución de la aplicación, el principal recurso para ejecución
será un equipo de cómputo (P.C), el cual se apoya en la memoria RAM para
intercambiar información, se liga a la base de datos para la persistencia del
sistema.

Figura 9.2: Diagrama de nodos del proyecto

Capı́tulo 10

Actividades

10.1. Diagrama Workflow

Definición
El Diagrama de Actividad es un diagrama de flujo del proceso multi-
propósito que se usa para modelar el comportamiento del sistema. Los dia-
gramas de actividad se pueden usar para modelar un Caso de Uso, o una
clase, o un método complicado.

Un diagrama de actividad es parecido a un diagrama de flujo; la dife-

rencia clave es que los diagramas de actividad pueden mostrar procesado
paralelo (parallel processing). Esto es importante cuando se usan diagra-
mas de actividad para modelar procesos ’bussiness’ algunos de los cuales
pueden actuar en paralelo, y para modelar varios hilos en los programas
concurrentes.

Beneficios de los diagramas de actividades

Los diagramas de actividades presentan una serie de beneficios para los
usuarios. Considera crear un diagrama de actividades para:

Demostrar la lógica de un algoritmo.

Describir los pasos realizados en un caso de uso UML.

Ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y

el sistema.

41
42 CAPÍTULO 10. ACTIVIDADES

Simplificar y mejorar cualquier proceso clarificando casos de uso com-

plicados.

Modelar elementos de arquitectura de software, tales como método,

función y operación.

Figura 10.1: Ejemplo visual de una actividad de un programa

10.2. Diagrama Workflow para el proyecto

Figura 10.2: Diagrama Workflow para Perceptron

10.2. DIAGRAMA WORKFLOW PARA EL PROYECTO 43

En el diagrama anterior se representa el flujo de trabajo y las actividades

principales que se realizan en cada uno de los componentes del sistema,
estas actividades principales están ligadas a subrutinas dentro de las clases
respectivas que se comunicaran por medio de las interfaces entre ellas para
completar el flujo de procesos
44 CAPÍTULO 10. ACTIVIDADES
 Parte III

REFLEXIONES

45
Capı́tulo 11

Conclusiones

La ingenierı́a de software, y más especı́ficamente los diagramas que

implementa, son un recurso primordial para desarrollar un software
de manera estable y eficiente, los distintos diagramas nos permiten
realizar un seguimiento del sistema desde diferentes puntos de vista

Los diagramas UML nos permiten presentar diversas perspectivas de

un sistema, a las cuales conocemos como modelo. Los modelos por su
parte nos permiten realizar una representación de una abstracción de
la realidad y como se comportarán dentro de nuestro sistema.

Al plantear este proyecto logramos evidenciar las claras relaciones que

se ven marcadas entre la inteligencia artificial, la ingenierı́a de software
y el continuo crecimiento y desarrollo de las mismas.

La red neuronal Perceptron es relativamente sencilla y por ende nos

permite una mayor flexibilidad a la hora de implementar y desarrollar
ingenierı́a de software con el fin de abarcar la mayorı́a de temas del
curso.

47