INGENIERIA INDUSTRIAL

1. Direccionamiento de canales de entrada y salida:

Los canales de E/S son una mejora de los controladores de DMA. Pueden ejecutar
instrucciones que leen directamente de memoria. Eso permite gestionar con más
autonomía las operaciones de E/S y de esta manera se pueden controlar múltiples
operaciones de E/S con dispositivos con una mínima intervención del procesador.

Estos canales todavía se pueden hacer más complejos añadiendo una memoria local
propia que los convierte en procesadores específicos de E/S.

La programación de la operación de E/S por parte del procesador se realiza

escribiendo en memoria los datos y las instrucciones que necesita el canal de E/S
para gestionar toda la operación de E/S. La información que se especifica incluye el
dispositivo al que tenemos que acceder, la operación que se debe realizar indicando
el nivel de prioridad, la dirección del bloque de datos donde tenemos que leer o
escribir los datos que se han de transferir, el tamaño del bloque de datos que se
tienen que transferir, cómo se tiene que hacer el tratamiento de errores y cómo se ha
de informar al procesador del final de la operación de E/S. Cuando se acaba la
operación de E/S, el canal de E/S informa al procesador de que se ha acabado la
transferencia y de posibles errores mediante la memoria. También se puede indicar
el final de la transferencia mediante interrupciones.

Las dos configuraciones básicas de canales de E/S son las siguientes:

 Canal selector: está diseñado para periféricos de alta velocidad de transferencia

y solo permite una operación de transferencia simultánea.
 Canal multiplexor: está diseñado para periféricos más lentos de transferencia y
puede combinar la transferencia de bloques de datos de diferentes dispositivos.

Las ventajas principales de los canales de E/S respecto a los controladores de E/S
son las siguientes:

AUTOMATIZACION INDUSTRIAL 1
 INGENIERIA INDUSTRIAL

− Permiten controlar operaciones de

E/S simultáneas.

− Se pueden programar múltiples

operaciones de E/S sobre diferentes
dispositivos o secuencias de
operaciones sobre el mismo
dispositivo, mientras el canal de E/S
efectúa otras operaciones de E/S.

2. Principios básicos de programación:

2.1. Principios S.O.L.I.D:

Son cinco principios fundamentales, uno por cada letra, que hablan del diseño
orientado a objetos en términos de la gestión de dependencias. Las dependencias
entre unas clases y otras son las que hacen al código más frágil o más robusto y
reutilizable. Quién decidió resaltar estos principios y darles nombre a algunos de
ellos fue Robert C. Martin, a principios del año 2000.

Uncle Bob identificó estos cinco principios, algunos de ellos ya existentes y expuso
que estos deberían ser los principales principios a tener en cuenta en el momento
de desarrollar software utilizando el paradigma de la orientación a objetos.

Estos principios no son leyes o reglas inalterables que se tengan que cumplir, pero
si son una serie de recomendaciones prácticas que de ser aplicadas en su
conjunto ayudan a nuestro software a obtener los siguientes beneficios:

 Facilidad en el mantenimiento.
 Facilidad para hacer testing.
 Rapidez para de extender funcionalidades.
 Buena refactorización.
 Tolerancia frente a errores.

Antes de desglosar las letras de SOLID y ver que nos dice cada principio, tenemos
que repasar dos conceptos importantes en el desarrollo de cualquier software, que
son el acoplamiento y la cohesión.

AUTOMATIZACION INDUSTRIAL 2
 INGENIERIA INDUSTRIAL

 Acoplamiento: En desarrollo de software

se define como el grado en que un
módulo, clase, método o cualquier otra
entidad de software, está directamente
vinculada a las demás. Este grado de
acoplamiento también puede ser visto
como un grado de dependencia. Por
ejemplo, cuando se quiere utilizar una
clase que esté estrechamente unida
(tiene un alto acoplamiento) a una o más
clases, acabaremos utilizando o
modificando parte de estas clases de las
cuales somos dependientes.
 Cohesión: La cohesión es la medida en que se relacionan dos o más
partes de un sistema y cómo trabajan en conjunto para lograr mejores
objetivos que las partes individuales.

2.1.1. Principio de responsabilidad única (SPR):

Una clase, modulo, método, etc., debe tener una y solo una razón para cambiar.
Esto significa que una entidad de software debe tener solo una responsabilidad
y hacer únicamente la tarea para la cual ha sido diseñada. De lo contrario si
asume más de una responsabilidad existirá un alto acoplamiento provocando
que nuestra lógica de programación sea frágil ante cualquier cambio.

2.1.2. Principio de abierto y cerrado (OCP):

Las entidades de software deben estar abiertas para su extensión, pero
cerradas para su modificación. Esto significa que una entidad de software debe

AUTOMATIZACION INDUSTRIAL 3
 INGENIERIA INDUSTRIAL

ser fácilmente extensible sin necesidad de modificar su código existente. Si

diseñamos sistemas extensibles serán menos propensos a errores ante
cambios en los requerimientos. Podemos recurrir a la herencia para que nos
ayude a la hora de aplicar este principio.

2.1.3. Principio de sustitución de Liskov (LSP):

Este principio fue elaborado por Barbara Liskov y viene a decir que los objetos
deben ser reemplazables por instancias de sus subtipos sin alterar el correcto
funcionamiento del sistema. Por ejemplo, si tenemos una clase “Coche” que
tiene un método “arrancar Motor” y también tenemos una clase “Deportivo” que
extiende de “Coche”, podemos sustituir las referencias de “Coche” por
referencias de “Deportivo”. Aplicando este principio conseguimos validar que
nuestras abstracciones sean correctas.

2.1.4. Principio de segregación de la interfaz (ISP):

Tener interfaces específicas es mejor que tener una interfaz de propósito
general. Este principio nos dice que nunca debemos implementar una interfaz
que no vayamos a necesitar. Incumplir este principio conlleva que en nuestras
implementaciones tengamos dependencias de métodos que no necesitamos,
pero nos vemos obligados a definir. Por lo tanto, una interfaz la define el cliente
que la consume, y no debe tener métodos que este no vaya a implementar.

2.1.5. Principio de inversión de la dependencia (DIP):

Se debe depender de abstracciones, y no de implementaciones (concreciones).
Significa que una clase concreta, no debe depender directamente de otra clase
sino de una abstracción (interfaz) de esta. Aplicar este principio nos ayuda a
reducir la dependencia en implementaciones específicas y así lograr que el
código sea más reutilizable. No hay que confundir este principio con la
“inyección de dependencias” que es una técnica que nos ayuda a la hora de
aplicar este principio y conseguir que las colaboraciones entre clases no
conlleven dependencias entre ellas.

En definitiva, seguir los principios SOLID se convierte en una parte esencial en

nuestros desarrollos si queremos construir software de calidad que sea
modificable, escalable y fácil de testear.

AUTOMATIZACION INDUSTRIAL 4