3.1 Descomposicion Modular

3.1 Descomposicion Modular

El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. 

Sus ventajas:   Claridad, reducción de costos y re utilización.

 Los pasos a seguir son:

1. Identificar los módulos

2. Describir cada módulo

3. Describir las relaciones entre módulos

Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad.

1. Independencia funcional

2. Acoplamiento

3. Cohesión

4. Comprensibilidad

5. Adaptabilidad

Independencia Funcional

Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.

Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión

Acoplamiento

El acoplamiento es una medida de la interconexión entre módulos en la estructura del programa. Se tiende a que el acoplamiento sea lo menor  posible, esto es a reducir las interconexiones entre los distintos  módulos en que se estructure nuestra aplicación. El grado de   acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interfaces:

Fuerte

• Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.

• Común, se emplea una zona común de datos a la que tienen acceso varios módulos.

Moderado

• De control, la zona común es un dispositivo externo al que están ligados los módulos, esto implica  que un cambio en el formato de datos los afecta a todos.

Débil

• De datos, viene dado por los datos que intercambian los módulos. Es el mejor.

• Sin acoplamiento directo, es el acoplamiento que no existe

Cohesión

Un módulo coherente ejecuta una tarea sencilla en un procedimiento y requiere  poca interacción con procedimientos  que se ejecutan en otras partes de un  programa. Podemos decir que un módulo coherente es aquel que intenta  realizar solamente una cosa.

Comprensibilidad

Para facilitar los cambios, el mantenimiento y  la reutilización de módulos es necesario que  cada uno sea comprensible de forma aislada. 

Para ello es bueno que posea independencia funcional, pero además es deseable:

• Identificación, el nombre debe ser adecuado y descriptivo

• Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código

Adaptabilidad

La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad:

Previsión, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles

Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación

Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados.

3.2 Patrones De Diseño

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Objetivo De Los Patrones De Diseño

Los patrones de diseño pretenden:

·         Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

·         Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

·         Formalizar un vocabulario común entre diseñadores.

·         Estandarizar el modo en que se realiza el diseño.

·         Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

·         Imponer ciertas alternativas de diseño frente a otras.

·         Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Plantillas O Estructuras De Patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

·         Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).

·         Clasificación del patrón: creacional, estructural o de comportamiento.

·         Intención: ¿Qué problema pretende resolver el patrón?

·         También conocido como: Otros nombres de uso común para el patrón.

·         Motivación: Escenario de ejemplo para la aplicación del patrón.

·         Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

·         Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

·         Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.

·         Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

·         Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.

·         Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.

·         Código de ejemplo: Código fuente ejemplo de implementación del patrón.

·         Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

·         Patrones relacionados: Referencias cruzadas con otros patrones.

Aplicación En Ámbitos Concretos

Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose "lenguajes de patrones" y extensos "catálogos" de la mano de diversos autores.

En particular son notorios los esfuerzos en los siguientes ámbitos:

·         Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina.

·         Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.

·         Patrones para la integración de sistemas, es decir, para la intercomunicación y coordinación de sistemas heterogéneos.

·         Patrones de flujos de trabajo, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales.

3.3 Arquitectura de dominio específico

El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios.
Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa.
Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes.
Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema.
Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación.
Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.

Existen dos modelos de dominio específico:

1. Modelos genéricos que son abstracciones de varios sistemas reales.
2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.
Modelo genérico: flujo de datos de un compilador
Modelo de Referencia: La arquitectura OSI.
Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. Arquitecturas de objetos distribuidos.
Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios.
Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa. Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. 
Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos.
Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.

3.4 Diseño de software de arquitectura multiprocesador

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.

El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional. Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software. Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.

Ventajas

Es económica.

El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de máquinas con procesadores especialmente diseñados (como por ejemplo las máquinas de procesadores vectoriales y de propósito específico).

Adicionalmente, las computadoras paralelas son inherentemente escalables, permitiendo actualizarlas para adecuarlas a una necesidad creciente.

Las arquitecturas “tradicionales” se actualizan haciendo los procesadores existentes obsoletos por la introducción de nueva tecnología a un costo posiblemente elevado. Por otro lado, una arquitectura paralela se puede actualizar en términos de rendimiento simplemente agregando más procesadores.

Desventajas

 En ocasiones se menciona también la limitante física; existen factores que limitan la velocidad máxima de un procesador, independientemente del factor económico.

Barreras físicas infranqueables, tales como la velocidad de la luz, efectos cuánticos al reducir el tamaño de los elementos de los procesadores, y problemas causados por fenómenos eléctricos a pequeñas escalas, restringen la capacidad máxima de un sistema uniprocesador, dejando la opción obvia de colocar muchos procesadores para realizar cálculos cooperativamente.

Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

3.5 Diseño de software de Cliente – Servidor

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el procesamiento se distribuye a lo largo de varios procesadores. Es una forma de dividir las responsabilidades de un sistema de información separando la interfaz del usuario de la gestión de la información. El funcionamiento básico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta. Características de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son: • Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). • Espera y recibe las respuestas del servidor. • Por lo general, puede conectase a varios servidores a la vez. • Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

Características de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son: • Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). • Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. • Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado). • No es frecuente que interactúen directamente con los usuarios finales.

Ventajas • Centralización del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. • Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado. • Fácil mantenimiento

Desventajas • La congestión del tráfico (a mayor número de clientes, más problemas para el servidor). • El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el costo

Características

• ·          En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:
• ·         Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
• ·         Espera y recibe las respuestas del servidor.  Por lo general, puede conectarse a varios servidores a la vez.

 Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

• ·         Al receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son:
• ·         Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
• ·         Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
• ·         Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
• ·         No es frecuente que interactúen directamente con los usuarios finales.

3.7 Diseño de software de arquitectura de tiempo real arquitectura

El software de tiempo real está muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.

Los sistemas de tiempo real generan alguna acción en respuesta a sucesos externos. Para realizar esta función, ejecutan una adquisición y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real están frecuentemente dedicados a una única aplicación.

Globalmente, un sistema de tiempo real enfrenta al ingeniero de sistemas con difíciles decisiones sobre el software. Una vez que el elemento software ha sido asignado, se establecen los requisitos detallados del software y debe desarrollarse un diseño fundamental de software.

Entre los muchos aspectos relativos al diseño de tiempo real están: la coordinación entre las tareas de tiempo real, el procesamiento de interrupciones del sistema, el manejo de E/S para asegurar que no se pierden datos, la especificación de las ligaduras de tiempo externas e internas del sistema y el asegurar la precisión de su base de datos.

Cada diseño de tiempo real relativo al software debe ser aplicado en el contexto del rendimiento de sistema. En la mayoría de los casos, el rendimiento de un sistema de tiempo real se mide con una o más características relativas al tiempo, pero también se utilizan otras medidas, tales como la tolerancia al fallo. Algunos sistemas de tiempo real se han diseñado para aplicaciones en las que solo el tiempo de repuesta o la trasferencia de datos es crítica.

Las computadoras se utilizan para controlar una amplia variedad de sistemas desde maquinas domesticas sencillas hasta plantas enteras de fabricación. Estas computadoras interactúan directamente con dispositivos hardware. El software de dichos sistemas es software de tiempo real embebido que debe reaccionar a eventos generados por el hardware y emitir señales de control como respuesta a estos eventos. Está embebido en sistemas hardware maquina y debe responder, en tiempo real, a eventos del entorno del sistema.

Los sistemas de tiempo real embebidos son diferentes de otros tipos de sistemas de software. Su correcto funcionamiento depende de que el sistema responda a los eventos dentro de un corto intervalo de tiempo. Se puede definir un sistema de tiempo real como sigue:

Un sistema de tiempo real es un sistema software cuyo correcto funcionamiento depende de los resultados producidos por el mismo y del instante del tiempo en el que se producen estos resultados. Un sistema de tiempo real blando (soft) es un sistema cuyo funcionamiento se degrada si los resultados no se producen de acuerdo con los requerimientos temporales especificados. Un sistema de tiempo real duro (hard) es un sistema cuyo funcionamiento es incorrecto si los resultados no se producen de acuerdo con la especificación temporal.

Una respuesta a tiempo es un factor importante en todos los sistemas embebidos, pero en algunos casos, no necesita una respuesta rápida. Por ejemplo, el sistema de bombeo de insulina es un sistema embebido. Sin embargo, aunque se necesita comprobar el nivel de glucosa a intervalos periódicos no es necesario responder muy rápidamente a los eventos externos.

Una forma de ver un sistema de tiempo real es como un sistema de estimulo/respuesta. Dando un determinado estimulo de entrada, el sistema debe producir la correspondiente salida. Se puede, por lo tanto, definir el comportamiento de un sistema de tiempo real haciendo una lista de los estímulos recibidos por el sistema, las respuestas asociadas y el tiempo en que dichas respuestas deben producirse.

Los estímulos pueden pertenecer a dos clases:

Estímulos periódicos. Ocurren a intervalos de tiempo predecibles. Por ejemplo, si el sistema debe examinar un sensor cada 50 milisegundos y realizar una acción (respuesta) dependiendo del valor de ese sensor (estímulo).

Estímulos aperiódicos. Ocurren de forma regular. Normalmente son provocados utilizando el mecanismo de interrupciones de la computadora. Un ejemplo de dicho estímulo podría ser una interrupción para indicar que una transferencia de E/S se ha completado y que los datos están disponibles en el búfer.

Los estímulos periódicos en un sistema de tiempo real son generados normalmente por sensores asociados al sistema. Estos proporcionan información sobre el estado del entorno del sistema. Las respuestas son dirigidas a un conjunto de actuadores que controlan algún equipo como una bomba, que influye en el entorno del sistema. 

Los estímulos aperiódicos pueden generarse por actuadores o por sensores. A menudo indican alguna condición excepcional como un fallo en el hardware, que debe ser manejado por el sistema. Este modelo sensor-sistema actuador de un sistema de tiempo real embebido se ilustra en la figura 2.2.

Un sistema de tiempo real tiene que responder a estímulos que ocurren en diferentes instantes de tiempo. Por lo tanto, se tiene que organizar su arquitectura para que, tan pronto como se reciba un estímulo, el control sea transferido al manejador adecuado. Esto no es práctico en programas secuenciales. Por consiguiente, los sistemas de tiempo real se diseñan como un conjunto de procesos concurrentes que cooperan entre sí. Con el objetivo de soportar la gestión de estos procesos, la plataforma de ejecución para la mayoría de los sistemas de tiempo real incluye un sistema operativo de tiempo real. Las facilidades que proporciona este sistema operativo son accedidas a través  del sistema de soporten tiempo de ejecución (run-time system) para el lenguaje de programación de tiempo real utilizado.

La generalidad de este modelo estímulo-respuesta de un sistema de tiempo real conduce a un modelo arquitectónico genérico abstracto  en el que hay tres tipos de procesos. Para cada tipo de sensor, hay un proceso de gestión del sensor; los procesos computacionales calculan la respuesta requerida para el estimulo recibido por el sistema; los procesos de control de actuadores controlan el funcionamiento del actuador. Este modelo permite recoger rápidamente los datos desde el sensor (antes de que la siguiente entrada esté disponible) y permite que su procesamiento y la respuesta asociada al actuador se realicen más tarde.

La arquitectura genérica puede instanciarse a varias arquitecturas de aplicaciones diferentes que amplían el conjunto  de arquitecturas. Las arquitecturas de aplicaciones de tiempo real son instancias de la arquitectura conducida por eventos en la cual el estimulo, directa o indirectamente. Provoca la generación de eventos.

Los lenguajes de programación desarrollados para sistemas de tiempo real tienen que incluir facilidades para acceder al hardware del sistema, y debería ser posible predecir la duración de operaciones particulares realizadas en estos leguajes.los sistemas de tiempo real duros todavía se programan algunas veces en ensamblador para que puedan cumplirse los estrechos plazos de tiempo (deadline). Los lenguajes a nivel de sistemas como C, que permiten generar código eficiente también se utilizan en general.

La ventaja de utilizar un lenguaje de programación de sistemas de bajo nivel como C es que permite el desarrollo de programas muy eficientes. Sin embargo, estos lenguajes no incluyen construcciones para soportar la concurrencia o la gestión de recursos compartidos. Estas se implementan atreves de llamadas al sistema operativo de tiempo real que no pueden ser comprobados por el compilador, de forma que los errores de programación son más probables. Los programas son también más a menudo más difícil de comprender debido a que las características  de tiempo real no están explicitas en el programa.

3.8 SEGURIDAD DE SOFTWARE

El concepto de la seguridad en los sistemas de software es un área de investigación que ha pasado a ser vital dentro de la Ingeniería de Software. Con el crecimiento de Internet, y otras aplicaciones sobre redes, como el comercio electrónico, correo electrónico, etc., la posibilidad de ataques se ha incrementado notablemente, como también lo han hecho las consecuencias negativas de estos ataques.


En la actualidad prácticamente todo sistema debe incorporar cuestiones de seguridad para defenderse de ataques maliciosos. El desarrollador ya no sólo debe concentrarse únicamente en los usuarios y sus requerimientos, sino también en los posibles atacantes. 


Esto ha motivado cambios importantes en el proceso de diseño y desarrollo de software para incorporar a la seguridad dentro de los requerimientos críticos del sistema.


Estos cambios son los primeros pasos en la concientización  de los ingenieros de software acerca de la importancia de obtener un software seguro. Como todo gran cambio, no se logra de un día para otro, sino que es un proceso gradual que requiere tiempo y maduración. Todavía la Ingeniería de Software no ha dado una respuesta eficaz, coherente y aplicable que satisfaga plenamente a la comunidad informática, sino que las aproximaciones actuales están plagadas de fallas y debilidades fruto de que todavía es un proceso que se encuentra en su infancia.


Siempre que utilicemos un sistema informático, sin importar cuál sea la razón, es importante que tengamos como prioridad la instalación de un software de seguridad, teniendo en cuenta la cantidad de riesgos que corremos con un sistema informático sin protección.


Justamente por la importancia acerca de lo que es un software de seguridad para cualquier usuario, la mayoría de los sistemas operativos con los que podemos trabajar suelen traer incorporado en ellos un software de seguridad básico, pero es importante que sepamos ante todo qué es un software de seguridad y la diferencia entre éste software y uno que es especialmente desarrollado para prevenir problemas en el funcionamiento del sistema, es que el mismo, simplemente nos advierte cuando estamos frente a algún riesgo.


•        Tipos de software de seguridad

 Sin duda, el tipo de software de seguridad más conocido son los programas antivirus, que se encargan de detectar y eliminar virus informáticos. Un buen programa antivirus dispone de un archivo de firmas de virus que se actualiza automáticamente y detecta virus nuevos. Este tipo de actualización se realiza periódicamente, varias veces al día. 


El software de seguridad suele venderse en las denominadas suites. Son paquetes compuestos de:

•        Programa antivirus
•        Cortafuegos
•        Filtro antispam
•        Software para filtrar contenidos
•        Software contra publicidad no deseada
•        Control de sitios web


Actualmente, la seguridad es un concepto que todo sistema debe incorporar.  La Ingeniería del Software todavía no es capaz de brindar un mecanismo para  implementar adecuadamente la seguridad: los lenguajes tienen primitivas inseguras, el código relativo a la seguridad es siempre un código confuso y complejo debido a técnicas de abstracción insuficientes, etc.