3.1 DESCOMPOSICIÓN MODULAR
El diseño
modular es una metodología de desarrollo de programas complejos, que utiliza la
filosofía TOP-DOWN, conocida también como diseño descendente o refinamiento por
pasos sucesivos; o comúnmente conocido por los programadores como “Divide y
Vencerás”; puesto que enfrenta un problema desde lo abstracto (TOP) hacia lo
particular (DOWN).
Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.
Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.
La descomposición modular contribuye a las características deseables para la programación estructurada; y que permite resolver cada módulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignársele un nombre y pasar al desarrollo de otro módulo y, más adelante retomar el módulo incompleto para darle solución al obtener mayor conocimiento sobre dicho proceso, es decir, la solución del problema no se detiene por falta de conocimiento de algún proceso en particular.
3.2 PATRONES DE DISEÑO
Los
patrones de diseño son el esqueleto de las soluciones a problemas comunes en el
desarrollo de software.”
En otras
palabras, brindan una solución ya probada y documentada a problemas de
desarrollo de software que están sujetos a contextos similares. Debemos tener
presente los siguientes elementos de un patrón: su nombre, el problema (cuando
aplicar un patrón), la solución (descripción abstracta del problema) y las
consecuencias (costos y beneficios).
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".
· Según la escala o nivel de abstracción:
· Patrones de arquitectura: Aquéllos que expresan un
esquema organizativo estructural fundamental para sistemas de software.
· Patrones de diseño: Aquéllos que expresan esquemas
para definir estructuras de diseño (o sus relaciones) con las que construir
sistemas de software.
· Dialectos: Patrones de bajo nivel
específicos para un lenguaje de programación o entorno concreto.
Estructuras o plantillas 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.
Características:
· Las plantillas son de bajo costo.
· Se utilizan en diferentes tipos de aplicaciones:
web, escritorio, app móviles.
· El código es reutilizable;
comprada la plantilla, se adquiere la propiedad intelectual de la misma.
Patrones orientados a objetos (Análisis
y diseño a objetos)
Tareas del patrón:
· Identificación de casos de uso.
· Definición del modelo conceptual.
· Especificación de diagrama de servicio.
· Definición de clases.
Identificación de casos de uso
Definición: el caso de uso describe una
funcionalidad parcial del sistema que se desarrolla.
Notación: Diagrama de casos de uso.
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.
Son modelos de arquitectura los cuales son específicos para algún dominio de aplicación.
Dos tipos de modelos de dominio específico son:
Modelos Genéricos. Estos son abstracciones de un número de sistemas reales y que encapsulan las características principales de estos sistemas.
Modelos de Referencia. Estos son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.
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.
Son modelos de arquitectura los cuales son específicos para algún dominio de aplicación.
Dos tipos de modelos de dominio específico son:
Modelos Genéricos. Estos son abstracciones de un número de sistemas reales y que encapsulan las características principales de estos sistemas.
Modelos de Referencia. Estos son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.
Modelos
genéricos
Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:
Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:
•Analizador Léxico.
• Tabla de Símbolos.
• Analizador de Sintaxis
• Analizador Semántico.
• Generador/Optimizador de Código.
• Un modelo de compilador genérico puede ser organizado de acuerdo a diversos modelos de arquitectura.
ARQUITECTURAS DE REFERENCIA
Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes.
Pueden ser utilizados como una base para… la implementación de un sistema o para comparar sistemas diversos.
Actúan como un estándar, contra el cual los sistemas que pueden ser evaluados.
El modelo OSI es un modelo en capas para sistemas de comunicación, y además, es un modelo de referencia.
La arquitectura de software es la responsable de la derivación de un modelo de sistema estructural, un modelo de control y un modelo de descomposición en subsistemas.
Los sistemas grandes rara vez conforman un modelo simple de arquitectura.
Los modelos de estructuración de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de máquina abstracta.
Los modelos de control incluyen control centralizado y modelos manejadores de eventos. Los modelos de descomposición modular incluyen los modelos orientados a objetos y los modelos de flujo de datos.
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.
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.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.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.
3.5 DISEÑO DE SOFTWARE DE CLIENTE – SERVIDOR
La
arquitectura cliente-servidor es una forma de dividir las responsabilidades de
un Sistema de Información separando la interfaz de usuario (Nivel de
presentación) de la gestión de la información (Nivel de gestión de datos).
Esta arquitectura consiste básicamente en que un programa, el Cliente informático realiza peticiones a otro programa, el servidor, que les da respuesta.
Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.
Esta arquitectura consiste básicamente en que un programa, el Cliente informático realiza peticiones a otro programa, el servidor, que les da respuesta.
Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.
Ventajas
de la arquitectura cliente-servidor
› 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.
Se reduce el tráfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL.
3.6 DISEÑO DE SOFTWARE DE ARQUITECTURA DISTRIBUIDA
Estos recursos
técnicos suelen catalogarse en:
- Infraestructura.
-Plataforma.
-Comunicaciones.
-Datos.
- Software:
- Aplicaciones.
-Interfícies.
-Servicios.
- Seguridad.
-Plataforma.
-Comunicaciones.
-Datos.
- Software:
- Aplicaciones.
-Interfícies.
-Servicios.
- Seguridad.
Pero no olvidemos que detrás
del sistema operativo hay personas que lo usan y los gestionan. El factor
humano será fundamental como nos cuidaremos de recordar a lo largo del todo el
diseño.
Diseñar un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido.
Los servicios permitirán usar todos los recursos técnicos y el sistema distribuido resulto ante no será nada más, ni nada menos, que un conjunto de servicios que interoperan entre ellos colaborando para cumplir los objetivos que se han establecido para el sistema.
Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor coste en las estructuras informáticas que dan soporte.
No olvide nunca estos tres puntos. El objetivo es siempre alinear tecnología y negocio.
El sistema resultante debe ser adaptable, ofrecer el rendimiento necesario con el coste más barato que seamos capaces de conseguir. Con este objetivo final, empezamos nuestro viaje para el cual le voy a pedir un esfuerzo. Las tecnologías llegan, se consolidan o desaparecen, y al final mueren. Y siempre con facilidad y rapidez. Pero las estrategias, las tácticas y las técnicas de diseño tienen un ciclo de vida mucho más lento y robusto. Y están por encima de las tecnologías en que se implementan. Intente poner en su mochila solo las primeras. Este es un viaje por el mundo del diseño de sistemas distribuidos, no sus técnicas de implementación aunque haremos las necesarias salidas a ese mundo cuando sea necesario.
Arquitecturas en un sistema distribuido. La arquitectura de Empresa. La palabra arquitectura es de aquellos términos utilizados ampliamente dentro del mundo informático. Cuando atacamos sistemas distribuidos, la palabra aparece continuamente.
Esta constatación de la realidad no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término: “Arquitectura es la organización fundamental de un sistema, donde se integran sus componentes, se establecen las relaciones e interdependencias entre esos componentes y su entorno y se establecen los principios para su diseño, gestión y evolución”.
Así, en el mundo de los sistemas distribuidos donde conviven tantos factores y tan diferentes, es lógico que el término se utilice profusamente en varios lugares. Veamos la primera aparición. El objetivo fundamental de cualquier sistema distribuido será aportar valor añadido. Y para empezar eficientemente el camino conviene organizar de alguna forma todos los factores que intervienen. La forma de hacerlo es proponer una Arquitectura de Empresa, conocida también por EA desde su nombre en inglés, Enterprise Architecture. La arquitectura de la empresa permite a la compañía conocer como es su estructura y la forma en que trabaja. Es el plano de ruta para el desarrollo de los negocios y de la tecnología que va ha apoyarlos, tanto en lo nuevo como en la evolución.
Es en este último aspecto por el que nos conviene acercarnos a ella. Sus contenidos son prerrequisitos que los sistemas distribuidos deberán cumplir. Es de aquí donde se origina el Plan Estratégico Distribuido de la Compañía, donde se registrarán todos los prerrequisitos de desarrollo y gestión que los sistemas distribuidos de la compañía deberán seguir y cumplir. Veremos que este documento se utilizará en la segunda parte dedicada al diseño, como base de muchas decisiones a tomar durante el desarrollo del sistema distribuido.
Diseñar un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido.
Los servicios permitirán usar todos los recursos técnicos y el sistema distribuido resulto ante no será nada más, ni nada menos, que un conjunto de servicios que interoperan entre ellos colaborando para cumplir los objetivos que se han establecido para el sistema.
Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor coste en las estructuras informáticas que dan soporte.
No olvide nunca estos tres puntos. El objetivo es siempre alinear tecnología y negocio.
El sistema resultante debe ser adaptable, ofrecer el rendimiento necesario con el coste más barato que seamos capaces de conseguir. Con este objetivo final, empezamos nuestro viaje para el cual le voy a pedir un esfuerzo. Las tecnologías llegan, se consolidan o desaparecen, y al final mueren. Y siempre con facilidad y rapidez. Pero las estrategias, las tácticas y las técnicas de diseño tienen un ciclo de vida mucho más lento y robusto. Y están por encima de las tecnologías en que se implementan. Intente poner en su mochila solo las primeras. Este es un viaje por el mundo del diseño de sistemas distribuidos, no sus técnicas de implementación aunque haremos las necesarias salidas a ese mundo cuando sea necesario.
Arquitecturas en un sistema distribuido. La arquitectura de Empresa. La palabra arquitectura es de aquellos términos utilizados ampliamente dentro del mundo informático. Cuando atacamos sistemas distribuidos, la palabra aparece continuamente.
Esta constatación de la realidad no resulta extraña si acudimos a la definición que ANSI/IEEE hace del término: “Arquitectura es la organización fundamental de un sistema, donde se integran sus componentes, se establecen las relaciones e interdependencias entre esos componentes y su entorno y se establecen los principios para su diseño, gestión y evolución”.
Así, en el mundo de los sistemas distribuidos donde conviven tantos factores y tan diferentes, es lógico que el término se utilice profusamente en varios lugares. Veamos la primera aparición. El objetivo fundamental de cualquier sistema distribuido será aportar valor añadido. Y para empezar eficientemente el camino conviene organizar de alguna forma todos los factores que intervienen. La forma de hacerlo es proponer una Arquitectura de Empresa, conocida también por EA desde su nombre en inglés, Enterprise Architecture. La arquitectura de la empresa permite a la compañía conocer como es su estructura y la forma en que trabaja. Es el plano de ruta para el desarrollo de los negocios y de la tecnología que va ha apoyarlos, tanto en lo nuevo como en la evolución.
Es en este último aspecto por el que nos conviene acercarnos a ella. Sus contenidos son prerrequisitos que los sistemas distribuidos deberán cumplir. Es de aquí donde se origina el Plan Estratégico Distribuido de la Compañía, donde se registrarán todos los prerrequisitos de desarrollo y gestión que los sistemas distribuidos de la compañía deberán seguir y cumplir. Veremos que este documento se utilizará en la segunda parte dedicada al diseño, como base de muchas decisiones a tomar durante el desarrollo del sistema distribuido.
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.
La computadora digital se ha convertido en una maquina omnipresente en la vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos.
Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora está controlando algo que interactúa con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.
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.
Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación médica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial.
Consideraciones Sobre los Sistemas.
Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, para conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles de hacer con seguridad.
¿Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo?
¿Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real.
La computadora digital se ha convertido en una maquina omnipresente en la vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos.
Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora está controlando algo que interactúa con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.
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.
Durante muchos años, los principales consumidores de sistemas de tiempo real eran militares. Sin embargo, hoy la significativa reducción del coste del hardware ha hecho posible para la mayoría de las compañías, proporcionar sistemas (y productos) de tiempo real para diversas aplicaciones, que incluyen control de procesos, automatización industrial, investigación médica y científica, gráficos de computadoras, comunicaciones locales y de largo alcance, sistemas aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentación industrial.
Consideraciones Sobre los Sistemas.
Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar hardware, software, hombres y elementos de una base de datos, para conseguir adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignación importante como la función, pero las decisiones de asignación relativas al rendimiento son frecuentemente difíciles de hacer con seguridad.
¿Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse un hardware especial para hacer el trabajo?
¿Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de interrupciones multitareas y comunicaciones, o especificado, acoplado con el software propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser respondidas por el ingeniero de sistemas de tiempo real.
