Unidad 5 DESARROLLO DE SISTEMAS DE TIEMPO REAL (STR)

República Bolivariana De Venezuela
Ministerio Del Poder Popular Para La Defensa

Universidad Nacional Experimental Politécnica
De La Fuerza Armada Nacional Bolivariana
Unefa Miranda Extensión Ocumare Del Tuy
UNIDAD 5: Desarrollo de sistemas

de tiempo real. (STR)
Carrera Bachiller Cédula de Identidad
Ing. Sistemas
Cuarto Semestre Jean Gracia V 22530725
04S-2642-D1
Ocumare del Tuy. Edo. Mirada. Mpio. Lander. 11 de mayo de 2020

Índice
Sistema embebido...........................................................................................................................3
Sistemas de tiempo real..................................................................................................................3
Tecnologías de software para sistemas de tiempo real..................................................................4
Sistemas de bases de datos con requerimientos de tiempo real................................................4
Sistemas Operativos en Tiempo real...........................................................................................5
Lenguajes de programación.........................................................................................................5
Sistemas CASE para (STR).............................................................................................................6
Introducción a la Calidad del Software............................................................................................8
Métricas de calidad de software.....................................................................................................8
ISO 9000 0.2...................................................................................................................................11
Calidad de proceso y producto......................................................................................................12
Ingeniería de software orientado a objeto....................................................................................13
Análisis y diseño orientado a objetos............................................................................................17
Pruebas orientadas a objetos........................................................................................................17
Patrones orientados a objetos......................................................................................................18
2
Sistema embebido
Como el término lo sugiere, es solo una parte de un “todo” más grande que consiste en
muchos componentes, no sólo módulos de computadora, sino también sensores y actuadores.
Sistemas de tiempo real
Surge de la exigencia a sistemas que cumplan con la ejecución en sus respuestas bajo
ciertas restricciones de tiempo. Si no las respeta, se dirá que el sistema ha fallado. Para
garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea
predecible.
Un ejemplo que ilustra los puntos anteriores es el de un robot que necesita tomar una
pieza de una banda sinfín. Si el robot llega tarde, la pieza ya no estará donde debía recogerla,
por tanto, el trabajo se llevó a cabo incorrectamente, aunque el robot haya llegado al lugar
adecuado. Si el robot llega antes de que la pieza llegue, la pieza aún no estará ahí y el robot
puede bloquear su paso.
Los sistemas en tiempo real están presentes en nuestra vida diaria, prácticamente en
todo lo que nos rodea: en los aviones, trenes y automóviles, en el televisor, la lavadora o
el horno de microondas, en los teléfonos celulares y en las centrales telefónicas digitales. Son
un elemento imprescindible para garantizar la generación, transmisión y distribución de
la energía eléctrica y para asegurar la calidad y la seguridad de incontables procesos
industriales.
Un STR tiene tres condiciones básicas:
1) Interactúa con el mundo real (proceso físico)

2) Emite respuestas correctas
3) Cumple restricciones temporales
Los STR pueden ser de dos tipos:
 Estrictos: Son aquellos en los que el tiempo de respuesta es vital, y se vuelve imperativo
que lo cumpla.
 No estrictos: El tiempo de respuesta es importante, pero se puede seguir operando

correctamente en caso de que ocasionalmente no se cumplan los plazos especificados.
3
Tecnologías de software para sistemas de tiempo real
Sistemas de bases de datos con requerimientos de tiempo real
s Sistemas de Base de Datos (SBD) se

han perfeccionado apuntando a
determinados aspectos como:
performance, capacidad de
procesamiento de
transacciones, propiedades ACID
( Atomicidad, Consistencia,
Aislamiento y
Durabilidad) de las transacciones y
disponibilidad de los datos. Este
desarrollo ha
tomado forma a medida que las
empresas fueron aumentando las
exigencias hacia los
4
sistemas que manejan sus datos,
debido a que en el presente, gestionar
datos es
gestionar uno de los principales
activos de las compañías. A estos
sistemas se les
deriva cada vez más responsabilidades
de negocio y son un aspecto clave en
la
calidad de servicio ofrecida a clientes
como: datos seguros, correctos y
disponibles
siempre.
Los Sistemas de Base de Datos (SBD)
se han perfeccionado apuntando a
procesamiento de
5
Aislamiento y
desarrollo ha
datos es
sistemas se les
la
6
disponibles
siempre.
procesamiento de
Aislamiento y
desarrollo ha
7
datos es
sistemas se les
la
disponibles
siempre.
procesamiento de
8
Aislamiento y
desarrollo ha
datos es
sistemas se les
la
9
disponibles
siempre.
procesamiento de
Aislamiento y
desarrollo ha
10
datos es
sistemas se les
la
disponibles
siempre.
procesamiento de
11
Aislamiento y
desarrollo ha
datos es
sistemas se les
la
12
disponibles
siempre.
procesamiento de
Aislamiento y
desarrollo ha
13
datos es
sistemas se les
la
disponibles
siempre.
procesamiento de
14
Aislamiento y
desarrollo ha
datos es
sistemas se les
la
15
disponibles
siempre.
procesamiento de
Aislamiento y
desarrollo ha
16
datos es
sistemas se les
la
disponibles
siempre.
procesamiento de
17
Aislamiento y
desarrollo ha
datos es
sistemas se les
la
18
disponibles
siempre.
procesamiento de
Aislamiento y
desarrollo ha
19
datos es
sistemas se les
la
disponibles
siempre.
Un SBD maneja datos persistentes garantizando durabilidad y consistencia a través de
gestión de transacciones. Una transacción es un conjunto de operaciones que implementan una
función lógica indivisible dentro de un SBD.
Se define a una transacción como: “Una parte de un programa que accede y

posiblemente actualiza varios datos con un fin específico.”. Todo conjunto de acciones
ordenadas que debe llevarse a cabo para lograr un resultado en una BD está comprendido
dentro de una transacción.
Las transacciones se definen con cuatro propiedades fundamentales, conocidas como

propiedades ACID:
20
 Atomicidad: Una transacción se ejecuta por completo o no se ejecuta. Confirma todas
sus operaciones satisfactoriamente (commit) o deshace sus operaciones si no pudo
completarse (rollback).
 Consistencia: Una transacción que altera datos garantiza que la BD pasa de un estado
consistente a otro, cumpliendo las reglas de integridad.
 Aislamiento: Las actualizaciones parciales de los datos no son visibles por otras
transacciones hasta que la transacción se confirme.
 Durabilidad: Una vez que una transacción se ha confirmado el resultado debe persistir
en la BD aunque se produzcan fallas posteriores.
En un ambiente de multiprogramación se garantiza además que la ejecución

concurrente de transacciones no ponga en riesgo la consistencia.
Permite controlar las secuencias de operaciones que acceden a datos compartidos para
que sean ejecutadas en serie y no concurran en casos de conflictos.
A esto se le llama serialización. Además de la calidad de los datos, un SBD tiene objetivos
de rendimiento que apuntan a reducir el tiempo de respuesta promedio de las transacciones
del sistema.
Por ejemplo, para el ámbito de las aplicaciones web, un sitio de subasta electrónica,
donde varios, tal vez miles de participantes subastan simultáneamente un producto, la
actualización de la mejor oferta debe ser publicada a todos los interesados al mismo tiempo
para no dar ventajas. A su vez, las ofertas tienen un tiempo límite o vencimiento. El ranking de
ofertas se debe realizar en tiempo real, entre todas las ofertas, antes de que éstas envejezcan.
Además, se debe considerar que el sistema debe atender concurrentemente múltiples subastas
electrónicas con las mismas condiciones de exigencia.
Supongamos en el ámbito industrial, un ejemplo de un sistema que debe identificar y

guiar un objeto sobre una cinta transportadora de una fábrica. Debe capturar la posición del
objeto e imágenes periódicas del mismo, compararlas con patrones almacenados en una BD,
identificarlo y, de acuerdo al tipo de objeto, tomar la acción que corresponda registrando en la
BD la decisión tomada y el tipo de objeto identificado de manera que el sistema de
monitorización muestre el estado de la cinta y la cantidad de objetos guiados.
En las situaciones planteadas se puede ver que hay STR con requerimientos de BD.
Sistemas Operativos en Tiempo real
 ADEOS.
21
 RT-LINUX.
 KURT.
 QNX.
 WINDOWS CE.
 VX WORKS.
 SYMBIA.
 SPECTRA.
 SOLARIS.
 REDLINUX.
Lenguajes de programación
Un lenguaje de programación de sistemas de tiempo real debe facilitar la realización de

sistemas:
 Concurrentes.
 Fiables.
 Y con un comportamiento temporal analizable.
Hay varias clases de lenguajes de interés para STR:
 Lenguajes ensambladores:
Son flexibles y eficientes, pero costosos y poco fiables.
 Lenguajes secuenciales:
(Fortran, C, C++)» necesitan un SO para concurrencia y tiempo real.

 Lenguajes concurrentes:
(Ada, Java, ...)» concurrencia y tiempo real incluidos en el lenguaje.
 C: Es un lenguaje muy utilizado para programación de sistemas:
1) Estructurado, con bloques.

2) Sin tipado fuerte.
3) Muy flexible (pero a veces poco seguro).
No tiene integrada la concurrencia ni el tiempo real: Se consigue invocando servicios del

sistema operativo de forma explícita.
No facilita la descomposición en módulos ni la programación con objetos.
22
Se puede hacer con C++:
» extensión de C para programar con objetos.

» no se suele usar en STR por problemas de fiabilidad.
 Ada: Es un lenguaje multipropósito orientado a objetos y concurrente se usa

principalmente en entornos que se necesitan gran seguridad.
 Occam: Lenguaje de programación imperativo y estructurado, es un lenguaje de
procedimiento en paralelo.
 Fortran: Lenguaje de alto nivel que está especialmente adaptado al cálculo numérico y a
la computación científica.
 Java: Lenguaje que soporta la programación orientada a objetos. Para sistemas en
tiempo real RTS1: (Real-Time Specification for java).
 Modula: Es un lenguaje de programación estructurado y modulado, su característica
principal es su simplicidad y la seguridad.
Sistemas CASE para (STR)
¿Qué es la Herramienta CASE?
Son diversas aplicaciones informáticas destinadas a aumentar la productividad en el

desarrollo de software reduciendo el coste de las mismas en términos de tiempo y dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida del desarrollo de
software en tareas como el proceso de realizar el diseño del proyecto, cálculo de costes,
implementación de parte del código automáticamente con el diseño dado, compilación
automática, documentación o detección de errores, entre otras.
Las herramientas CASE orientadas al diseño de aplicaciones abordan el diseño desde
diferentes puntos de vista: datos, interfaz, flujo de datos y navegación.
Wireframes y herramientas de prototipado
Son herramientas que nos permiten realizar el diseño y representaciones esquemáticas

de los componentes gráficos de nuestras aplicaciones.
Un ejemplo es la herramienta “mockingbird”, herramienta online que permite realizar

wireframes de una forma sencilla y permite compartir los resultados de los trabajos realizados
en ella con diferentes personas.
Otro ejemplo es la herramienta “gliffy”, muy potente, que permite crear gran cantidad
de diagramas, pero también permite crear wireframes de aplicaciones Web, ya sean estáticos o
23
interactivos para simular la navegación entre páginas. Permite el trabajo colaborativo y
exportar los diseños en diferentes formatos para su presentación o almacenamiento.
Herramientas para el modelado UML
UML sin duda alguna se ha convertido en una herramienta indispensable al momento de

diseñar una aplicación y diseñar correctamente su arquitectura, existe un sin número de
herramientas como ArgoUML, Umbrello, Enterprise Architect o BOUML que facilitan esta labor,
pero ninguna de ella utiliza los servicios de la web.
Existen herramientas de prototipado que nos permiten diseñar nuestra webapp en

forma colaborativa que pueden ser muy útiles y aquí mostraremos y recomendaremos algunas
de ellas.
Diseño
 HotGloo: Permite diseñar de forma gratuita y permite el diseño colaborativo si se

contrata un plan premium.
 Mockingbird web design: Otra herramienta de diseño de wireframes muy fácil de usar,
no permite el diseño colaborativo, pero se puede compartir el resultado a quien se
desee.
 Photo share ideas made interactive: Una poderosa herramienta con la que podemos
realizar prototipos interactivos de aplicaciones web y móviles. Permite el diseño
colaborativo.
 Balsamiq: es otra herramienta de prototipado, útil para realizar maquetas de webs

simples.
Diseño de datos
 WWW SQL DESIGNER: De manera muy intuitiva podemos diagramar y estructurar los
datos que utilizaremos en nuestra webapp y las relaciones entre ellos.
Modelado
 Para el modelado recomendamos Gliffy, permite crear variedad de diagramas,

incluyendo al UML.
Introducción a la Calidad del Software

24
El glosario de estándares de computación IEEE Std. 610 – 1991, define la calidad del
software como “el grado con el que un sistema, componente o proceso cumple los
requerimientos especificados y las necesidades o expectativas del cliente o usuario”.
En la actualización de la Norma ISO, 9000:2000, la definición quedó como el “Grado en

el que un conjunto de características inherentes cumple con los requisitos”. En esta definición
se hace especial énfasis en cumplir los requerimientos de los consumidores”.
En el libro Ingeniería del Software de Pressman, 1998, se afirma que la calidad es la

“Concordancia del software producido con los requerimientos explícitamente establecidos, con
los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos
formalmente, que desea el usuario.
Este debe contener las siguientes capacidades:
 Fiabilidad: Capacidad de operar sin errores.

 Modificable: Capacidad de hacer los cambios necesarios de una forma sencilla.
 Comprensible: Capacidad de comprender el software operativo, de cara a un cambio o
arreglo.
 Rendimiento: Velocidad y compacidad del software.
 Utilizable: Capacidad de uso sencillo del software.
 Probable: Capacidad de construir y ejecutar fácilmente casos de prueba.
 Portable: Capacidad de mover el software fácilmente de un entorno de trabajo a otro.
Métricas de calidad de software
¿Cuáles son los beneficios de aplicar métricas? Una organización que aplica métricas en
sus procesos busca incrementar el retorno de la inversión, identificar las áreas a mejorar,
optimizar el tiempo invertido en el proceso, y reducir los costos de operación.
Lamentablemente, ni siquiera las mejores métricas garantizarán una aplicación exitosa.
Sin embargo, la combinación de estas, un buen proceso de trabajo, la aplicación de buenas
prácticas al programar y pasión por nuestro proyecto, nos ayudará a entregar una aplicación de
calidad al usuario final.
Complejidad
“Cualquier tonto puede escribir código que un ordenador entiende. Los buenos
programadores escriben código que los humanos pueden entender”. Martin Fowler
25
Una de las métricas más importantes es la complejidad ciclomática, que puede ser usada
en las fases de desarrollo o mantenimiento.
Esta métrica, propuesta por Thomas McCabe en 1976, se basa en el diagrama de flujo
determinado por las estructuras de control de un código. Del análisis de esta estructura se
obtendrán las medidas cuantitativas que nos facilitarán la comprensión y mejora de las mismas.
La complejidad ciclomática está relacionada a un algoritmo claro y eficaz, que, a su vez,

se relaciona a, la complejidad cognitiva.
Existen diferentes prácticas que ayudan a bajar esta complejidad cognitiva, la que más
agradecemos, como desarrolladores, son los comentarios en el código.
La Complejidad Cognitiva mide que tan difícil es entender intuitivamente un bloque de

código, a diferencia de la Complejidad Ciclomática, que determina qué dificultad tiene probar el
código.
Algunos estudios han probado una correlación directa entre la complejidad ciclomática y
la cantidad de bugs de un trozo de código, o el número de líneas de este. Por esto podemos
concluir que, a mayor complejidad y dimensión, se presentan mayores problemas y fallos en
nuestro código.
Code Churn
Es la frecuencia con la que se añade, quita o altera el código a través del tiempo. En
palabras simples, es la cantidad de veces en la que el fichero ha sido modificado. Esta métrica
presenta una relación directa con código defectuoso.
Esto quiere decir, mientras más modificaciones sufra un código, mayor es la posibilidad
de introducir un bug. Esta métrica es fácil de calcular usando un sistema de control de versiones
(git, mercurial). Basta contabilizar el número de commits que modificaron un dato, fichero, o
toda una clase.
Code Coverage
Mide el porcentaje de código que se encuentra testeado. Tener test de calidad en

nuestro proyecto, ayudará a incrementar el valor de esta métrica y, a su vez, será menos
probable que el código contenga bugs.
Código Muerto
(Dead code). Es una parte del código fuente que se ejecuta, pero sus resultados nunca
se usan. La ejecución de este tipo de código consume tiempo de cómputo en algo que jamás se
utiliza.
26
Algunos IDE (como Visual Studio y Eclipse) poseen la habilidad de detectar código
muerto durante tiempo de compilación.
Algunos desarrolladores tienen la técnica «borrar, cerrar y cruzar» y que no es más que
borrar el código sospechoso, cerrar los ojos y cruzar los dedos para que nada se caiga…
Claramente esta no es una técnica recomendable. Tener pruebas automatizadas nos

ayudarán a detectar potenciales errores al borrar código.
Duplicación de Código
Medir el progreso de la programación por líneas de código es como medir el

progreso en la construcción de aviones por el peso. Bill Gates.
(Code duplication) es el término utilizado para una estructura de código que se declara
más de una vez dentro de una aplicación. Ocurre frecuentemente cuando el programador no
está familiarizado con el código, lo que lo lleva a replicar trozos de código.
Es importante entender que código duplicado no es exactamente un código igual, sino

que puede ser un código con ligeras adaptaciones.
La existencia de código duplicado afecta a los costos del proceso, ya que provocará una

mayor complejidad ciclomática, un mayor número de pruebas unitarias, aumenta
innecesariamente el tamaño del proyecto, y es más difícil de modificar, ya que hacerlo implica
cambiar todas las copias, lo que podría inducir al error ya que el programador podría olvidar
realizar las modificaciones correspondientes donde se encuentra el código duplicado.
ISO 9000 0.2.
0.2 Principios de gestión de la calidad
Para conducir y operar una organización en forma exitosa se requiere que ésta se dirija y
controle en forma sistemática y transparente. Se puede lograr el éxito implementando y
manteniendo un sistema de gestión que esté diseñado para mejorar continuamente su
desempeño mediante la consideración de las necesidades de todas las partes interesadas. La
gestión de una organización comprende la gestión de la calidad entre otras disciplinas de
gestión.
27
Se han identificado ocho principios de gestión de la calidad que pueden ser utilizados
por la dirección con el fin de conducir a la organización hacia una mejora en el desempeño.
 Enfoque al cliente: Las organizaciones dependen de sus clientes y por lo tanto deberían
comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos
de los clientes y esforzarse en exceder las expectativas de los clientes.
 Liderazgo: Los líderes establecen la unidad de propósito y la orientación de la

organización. Ellos deberían crear y mantener un ambiente interno, en el cual el
personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la
organización.
 Participación del personal: El personal, a todos los niveles, es la esencia de una

organización, y su total compromiso posibilita que sus habilidades sean usadas para el
beneficio de la organización.
 Enfoque basado en procesos: Un resultado deseado se alcanza más eficientemente

cuando las actividades y los recursos relacionados se gestionan como un proceso.
 Enfoque de sistema para la gestión: Identificar, entender y gestionar los procesos

interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una
organización en el logro de sus objetivos.
 Mejora continua: La mejora continua del desempeño global de la organización debería

ser un objetivo permanente de ésta.
 Enfoque basado en hechos para la toma de decisión: Las decisiones eficaces se basan
en el análisis de los datos y la información.
 Relaciones mutuamente beneficiosas con el proveedor: Una organización y sus

proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta la
capacidad de ambos para crear valor.
Estos ocho principios de gestión de la calidad constituyen la base de las normas de

sistemas de la familia ISO 9000.
Calidad de proceso y producto
No es lo mismo calidad del producto software, que calidad del proceso software, que
calidad del equipo.
La calidad del proceso
28
Por proceso se entienden las actividades, tareas, entrada, salida, procedimientos, etc.,
para desarrollar y mantener un software.
Modelos, normas y metodologías típicas son los CMMI, ISO 15504 / ISO 12207, el ciclo
de vida usado, e incluso las metodologías ágiles entran aquí.
Un buen proceso sin duda asegura un buen producto, pero, claro, también podemos
seguir un modelo de procesos famoso, y que no sea el más adecuado para nuestra organización
y que por ello el producto no acabe siendo el mejor. Por ello, una mala, algunas veces perversa,
interpretación es asumir que, cumpliendo cierto modelo, nivel de madurez, norma,
metodología, ciclo de vida, o cualquier otra cosa relacionada con el proceso… se ASEGURA por
ello directamente productos de calidad. ¿Realmente es garantía suficiente? ¿Una certificación
sobre la calidad del proceso garantiza un producto de calidad?…
La calidad del producto
Comentaban en IEEE software que hay poca evidencia en que cumplir un modelo de

procesos (CMMI, ISO 12207, una metodología ágil o no, etc.) asegure la calidad del producto.
Y en Computer, que las evaluaciones de calidad deberían estar basadas en evidencias del
producto (auditando el software), y no en evidencias circunstanciales o suposiciones.
Y es por ello que existen los modelos de calidad de producto, destacando entre ellos
la ISO 9126, o la nueva serie ISO 25000, que especifica diferentes dimensiones de la calidad de
producto. Aunque aquí la dura tarea de evaluación recae en el uso de métricas software.
Sí una empresa que desarrolla software debe preocuparse de la calidad del proceso y
del producto que desarrolla y entrega, una empresa que solo compra software (el típico cliente)
debería, principalmente, preocuparse de la calidad del producto que compra. Aunque vemos
que, en la realidad, las empresas que compran software lo hacen al revés, se preocupan por el
proceso que usa su proveedor (CMMI, ISO, etc.) y apenas del producto que les llega. Cosas de la
industria.
La calidad del equipo y/o personas
Lo más determinante, complejo, y sobre lo que menos “guías” hay. Aquí podemos
encontrar decenas de aproximaciones para mejorar, que van desde el tan de moda coaching, a
la filosofía ágil de lograr la auto-organización de los equipos, estrategias de motivación,
combinaciones de los anteriores, etc.
No hay que olvidar que las personas son las que hacen el software. Las herramientas
ayudan, las técnicas también, los procesos, etc. “Las personas son la clave del éxito”, que dijera
Davis en su libro 201 Principles of Software Development.
29
“El equipo humano es el
componente no lineal de
primer orden en el desarrollo
software. Las personas son
lo que tiene más potencial
para recortar el tiempo de
un proyecto, y quienes han
trabajo en software “han
observado las enormes
diferencias que hay en los
resultados que producen
desarrolladores medios,
mediocres y geniales”.
Ingeniería de software
orientado a objeto.
Los programas se modelan en torno a objetos que aglutinan toda la funcionalidad

relacionada con ellos. En POO se crean clases, que representan entidades que quieres manejar
en tu programa. Por ejemplo, facturas, líneas de factura, clientes, coches... o cualquier entidad
que necesites gestionar conceptualmente. En ese sentido, la POO gira más en torno a los datos
que en torno a la lógica, que se delega a un segundo plano, ya que forma parte de dichos datos.
Clases, objetos e instancias

El primer concepto y más importante de la POO es la distinción entre clase y objeto.
Una clase es una plantilla. Define de manera genérica cómo van a ser los objetos de
determinado tipo. Por ejemplo, en un juego, una clase para representar a personas puede
llamarse Persona y tener una serie de atributos como Nombre, Apellido o Edad (que
normalmente son propiedades), y una serie de comportamientos que pueden tener,
como Hablar(), Caminar() o Comer() y que se implementan como métodos de la
clase (funciones).
Una clase por sí sola no sirve de nada, pues no es más que un concepto, sin entidad real.
Para poder utilizar una clase en un programa lo que hay que hacer es instanciarla.
Instanciar una clase consiste en crear un nuevo objeto concreto de la misma.
Es decir, un objeto es ya una entidad concreta que se crea a partir de la plantilla que es
la clase.
Este nuevo objeto tiene ya "existencia" real, puesto que ocupa memoria y se puede
utilizar en el programa. Así un objeto puede ser una persona que se llama Cristina López,
30
de 37 años y que en nuestro programa podría hablar, caminar o comer, que son los
comportamientos que están definidos en la clase.
De este modo, si tenemos que manejar personas podemos ir creándolas a medida que
las necesitemos, y actuar sobre ellas individualmente. Cada una tiene sus propios datos y sus
propias acciones.
Encapsulación
Es la característica de un lenguaje POO que permite que todo lo referente a un objeto
quede aislado dentro de éste. Sólo se puede acceder a ellos a través de los miembros que la
clase proporcione (propiedades y métodos).
Por ejemplo, en el caso de las personas que estábamos viendo, toda la información
sobre éstas (nombre, apellidos, edad... y cualquier otro dato interno que se utilice y que no
necesariamente se ve desde el exterior del objeto) está circunscrito al ámbito de dicha persona.
Así, internamente tenemos un dato que es el nombre de la persona y accedemos a él a

través de la propiedad pública Nombre que define la clase que representa a las personas. De
este modo damos acceso sólo a lo que nos interese y del modo que nos interese.
Abstracción
Como la propia palabra indica, nos disuelve de la complejidad que haya dentro
dándonos una serie de atributos y comportamientos (propiedades y funciones) que podemos
usar sin preocuparnos de qué pasa por dentro cuando lo hagamos.
Así, una clase (y por lo tanto todos los objetos que se crean a partir de ella) debe
exponer para su uso solo lo que sea necesario. Cómo se haga "por dentro" es irrelevante para
los programas que hagan uso de los objetos de esa clase.
En nuestro ejemplo de las personas en un juego, puede ser que tengamos un dato
interno que llamamos energía y que nunca es accesible directamente desde fuera. Sin
embargo, cada vez que la persona anda (o corre, si tuviésemos un método para ello) gasta
energía y el valor de este dato disminuye. Y cuando la persona come, el valor sube en función
de lo que haya comido.
Otro ejemplo incluso más claro podría ser la acción Hablar(). Ésta puede suponer
que se genere una voz sintética a partir de un texto que se le indica como parámetro de la
acción para lo cual quizá ocurran un montón de cosas: se llama a un componente para síntesis
de voz que está en la nube, se lanza la síntesis de voz en el dispositivo local de audio y se anota
en una base de datos la frase que se ha pronunciado para guardar un histórico entre otras
cosas. Pero todo esto es indiferente para el programa que hace uso de esta funcionalidad. El
programa simplemente tiene acceso a un objeto Cristina y llama a la función Hablar().
No tiene ni idea de toda la complejidad interna que puede suponer. Si mañana cambiamos el
31
modo de sintetizar la voz o cualquier otra acción interna, es indiferente para el programa que
usa nuestros objetos de tipo Persona.
Herencia
Desde el punto de vista de la genética, cuando una persona obtiene de sus padres
ciertos rasgos (el color de los ojos o de la piel, una enfermedad genética, etc...) se dice que los
hereda. Del mismo modo en POO cuando una clase hereda de otra obtiene todos los rasgos que
tuviese la primera.
Dado que una clase es un patrón que define cómo es y cómo se comporta una cierta
entidad, una clase que hereda de otra obtiene todos los rasgos de la primera y añade otros
nuevos y además también puede modificar algunos de los que ha heredado.
A la clase de la que se hereda se le llama clase base, y a la clase que hereda de ésta se le

llama clase derivada.
Así, en nuestro juego que involucra personas, podemos tener clases de personas más
especializadas para representar personajes especiales del juego. Por ejemplo, podríamos definir
clases como Pirata, Piloto o Estratega que heredan de la clase Persona. Todos
los objetos de estas clases heredan las propiedades y los métodos de Persona, pero pueden
particularizar algunos de ellos y además añadir cosas propias.
Por ejemplo, los objetos de la clase Pirata tienen un método nuevo que

es Abordar() que en el juego sirve para asaltar un barco enemigo. Pero además presentan
una propiedad que solo tienen los piratas llamada Sobrenombre, que es el nombre por el
que se les conoce (un pirata puede ser de nombre Hector y de apellido Barbossa pero su
sobrenombre es Barbaroja.
No solo eso. Lo bueno de la herencia es que podemos reutilizar todo lo que tuviésemos
en la clase base. Supongamos que en nuestro juego, los piratas hablan de forma diferente a los
demás. El método Hablar() se modifica para que le añada un ¡Arrrr! o un ¡nadie
lo nota pero el ron se agota! aleatoriamente a la frase y que así parezca más
un pirata. Para que el pirata hable no tendríamos que volver a hacer todo el código relacionado
con hablar. Eso ya sabe cómo hacerlo por el mero hecho de ser una persona (por heredar de la
clase Persona).
Lo único que tendríamos que hacer es añadir esas interjecciones de pirata a la frase y
luego delegar la síntesis de voz y todo lo demás a la clase base. Sería facilísimo y
conseguiríamos consistencia entre todas las clases a la hora de particularizar la forma de hablar.
Polimorfismo
32
La palabra polimorfismo viene del griego "polys" (muchos) y "morfo" (forma), y quiere
decir "cualidad de tener muchas formas".
En POO, el concepto de polimorfismo se refiere al hecho de que varios objetos de

diferentes clases, pero con una base común, se pueden usar de manera indistinta, sin tener que
saber de qué clase exacta son para poder hacerlo.
Supongamos que en nuestro juego tenemos un montón de personajes que están juntos
en un mismo escenario. Hay varios piratas, algunos estrategas y un montón de otros tipos de
personas.
En un momento dado necesitamos que todos se pongan a hablar. Cada uno lo hace de
una forma diferente, ya que son tipos de personajes distintos. Sería algo bastante tedioso tener
que localizar primero a los de un tipo y hacerlos hablar, luego a los de otro y así sucesivamente.
La idea es que puedas tratarlos a todos como personas, independientemente del tipo específico
de persona que sean y simplemente decirles que hablen.
Al derivar todos de la clase Persona todos pueden hablar, y al llamar al

método Hablar() de cada uno de ellos se utilizará el proceso adecuado según el tipo (los
piratas meterán sus expresiones adicionales que hemos visto, los pilotos dirán "Entrando en
pista" o lo que sea, y los estrategas añadirán a todo "Déjame que lo piense bien"). Todo esto de
manera transparente para el programador. Esto es el polimorfismo.
De hecho, el polimorfismo puede ser más complicado que eso ya que se puede dar
también mediante la sobrecarga de métodos y, sobre todo, a través del uso de interfaces, pero
el concepto puntual es este.
Análisis y diseño orientado a objetos.
El proverbio “El hábito no hace el monje” se aplica perfectamente a la tecnología de

objetos. El hecho de conocer un lenguaje orientado a objetos (por ej. Java) y además tener
acceso a una rica biblioteca (como la de Java) es un primer paso necesario pero insuficiente
para crear sistemas de objetos. Se requiere además analizar y diseñar un sistema desde la
perspectiva de objetos.
El análisis se centra en la investigación del problema, no en la manera de definir la

solución.
Por ejemplo, si se necesita un nuevo sistema de biblioteca, ¿Cuáles procesos de la

institución se relacionan con su uso? El diseño pone de relieve una solución lógica: cómo el
33
sistema cumple con los requerimientos. ¿De qué manera el sistema de la biblioteca capturará y
registrará los préstamos de libros?
La esencia de estas actividades consiste en situar el dominio de un problema y su
solución lógica dentro de la perspectiva de los objetos.
 Durante el análisis orientado a objetos se procura ante todo identificar y describir los
objetos o conceptos dentro del dominio del problema.
 Durante el diseño orientado a objetos, se procura definir objetos lógicos del software.
 Finalmente, durante la programación orientada a objetos, se implementan los

componentes de diseño.
Pruebas orientadas a objetos
El objetivo general es encontrar el número de errores máximo con el mínimo de

esfuerzo; es el mismo objetivo de las pruebas del software convencional. Pero las estrategias y
táctica para la prueba OO difieren significativamente. La visión de la prueba se amplía hasta
incluir los modelos de análisis y diseño
Como dichos modelos están semánticamente enlazados las pruebas comienzan durante
estas actividades de ingeniería (análisis- diseño).
Una vez realizada la programación Orientada a objeto, la prueba de la unidad se aplica a

cada clase. Estas pruebas de clases usan una variedad de métodos: pruebas basadas en errores,
pruebas aleatorias y de partición. Cada uno de estos métodos ejercita las operaciones
encapsuladas por la clase.
Se diseñan secuencias de pruebas para asegurar que se ejerciten operaciones

relevantes. El estado de una clase, representado por valores de sus atributos, se examina para
determinar si existen errores.
Las pruebas de integración pueden realizarse usando estrategias basadas en hilos o

basadas en el uso. Las pruebas basadas en hilos integran el conjunto de clases que colaboran
para dar respuesta a una entrada o evento. Las pruebas basadas en uso construyen el sistema
por capas, comenzando con aquellas que no hacen uso de las clases servidores. Los métodos de
diseño de pruebas de integración pueden también hacer uso de pruebas aleatorias y de
partición.
Patrones orientados a objetos.
34
Hacer software no es fácil, Diseñar software orientado a objetos es difícil, y diseñar
software orientado a objetos reutilizable es todavía más difícil.
...y un software capaz de evolucionar tiene que ser reutilizable (al menos para las
versiones futuras)
¿Como hacerlos?
 Primero aprender las reglas: algoritmos, estructuras de datos, lenguajes de

programación, etc.
 A continuación, aprender los principios: programación estructurada, programación

modular, programación OO, programación genérica, etc.
 Hay que estudiar los diseños de otros programadores: Estos diseños contienen patrones
que deben ser entendidos, memorizados y aplicados repetidamente.
Christopher Alexander (1977): Cada patrón describe un problema que ocurre una y
otra vez en nuestro entorno, y describe la esencia de la solución a ese problema, de
tal modo que pueda utilizarse esta solución un millón de veces más, sin siquiera
hacerlo de la misma manera dos veces
 Un patrón es: una solución a un problema en un contexto particular.

 Recurrente (lo que hace la solución relevante a otras situaciones).
 Permite entender cómo adaptarlo a la variante particular del problema.
 Facilitan la reutilización de diseños y arquitecturas software que han tenido éxito.
¿Qué tipos de patrones existen?
Existen diversas maneras de agrupar los patrones de diseño. Quizá la más extendida es
agruparlos según su propósito. En este caso tendríamos las siguientes categorías:
 Patrones creacionales: utilizados para instanciar objetos, y así separar la

implementación del cliente de la de los objetos que se utilizan. Con ellos
intentamos separar la lógica de creación de objetos y encapsularla.
 Patrones de comportamiento: se utilizan a la hora de definir como las clases y objetos

interaccionan entre ellos.
35
 Patrones estructurales: utilizados para crear clases u objetos que incluidos dentro de
estructuras más complejas.
Clasificación de patrones de diseño:
 Patrones de diseño creacionales: Son los que dan solución a cómo gestionar la creación
de objetos proporcionando la mejor solución para cada situación. En esta categoría
encontramos; Factory, Object Pool, Singleton.
 Patrones de diseño estructurales: Son aquellos que facilitan el diseño identificando

formas sencillas de relacionar entidades. Algunos ejemplos son, patrón Decorator, Proxy
o Wrapper.
 Patrones de diseño de comportamiento: Estos son los que identifican patrones comunes
de comunicación entre objetos. El más famoso puede que sea el Observer, pero también
patrones como Chain of responsibility o Memento
 Patrones de concurrencia: Estos son los que ofrecen soluciones para paradigmas de

desarrollo multi-hilo. En este último grupo encontramos el patrón Active Object o
el Reactor.
Conclusión
Es sencillo, si no usas patrones, deberías hacerlo. Los patrones ayudan a estandarizar el

código, haciendo que el diseño sea más comprensible para otros programadores.
36

Unidad 5 DESARROLLO DE SISTEMAS DE TIEMPO REAL (STR)

Cargado por

Copyright:

Formatos disponibles

Unidad 5 DESARROLLO DE SISTEMAS DE TIEMPO REAL (STR)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 5 DESARROLLO DE SISTEMAS DE TIEMPO REAL (STR)

Cargado por

Copyright:

Formatos disponibles

República Bolivariana De Venezuela

Ministerio Del Poder Popular Para La Defensa

UNIDAD 5: Desarrollo de sistemas

Carrera Bachiller Cédula de Identidad

Ocumare del Tuy. Edo. Mirada. Mpio. Lander. 11 de mayo de 2020

Sistemas de tiempo real

Un STR tiene tres condiciones básicas:

1) Interactúa con el mundo real (proceso físico)

Los STR pueden ser de dos tipos:

 No estrictos: El tiempo de respuesta es importante, pero se puede seguir operando

Sistemas de bases de datos con requerimientos de tiempo real

s Sistemas de Base de Datos (SBD) se

Se define a una transacción como: “Una parte de un programa que accede y

Las transacciones se definen con cuatro propiedades fundamentales, conocidas como

En un ambiente de multiprogramación se garantiza además que la ejecución

Supongamos en el ámbito industrial, un ejemplo de un sistema que debe identificar y

Sistemas Operativos en Tiempo real

Un lenguaje de programación de sistemas de tiempo real debe facilitar la realización de

Hay varias clases de lenguajes de interés para STR:

Son flexibles y eficientes, pero costosos y poco fiables.

(Fortran, C, C++)» necesitan un SO para concurrencia y tiempo real.

(Ada, Java, ...)» concurrencia y tiempo real incluidos en el lenguaje.

 C: Es un lenguaje muy utilizado para programación de sistemas:

1) Estructurado, con bloques.

No tiene integrada la concurrencia ni el tiempo real: Se consigue invocando servicios del

No facilita la descomposición en módulos ni la programación con objetos.

» extensión de C para programar con objetos.

 Ada: Es un lenguaje multipropósito orientado a objetos y concurrente se usa

Sistemas CASE para (STR)

¿Qué es la Herramienta CASE?

Son diversas aplicaciones informáticas destinadas a aumentar la productividad en el

Wireframes y herramientas de prototipado

Son herramientas que nos permiten realizar el diseño y representaciones esquemáticas

Un ejemplo es la herramienta “mockingbird”, herramienta online que permite realizar

Herramientas para el modelado UML

UML sin duda alguna se ha convertido en una herramienta indispensable al momento de

Existen herramientas de prototipado que nos permiten diseñar nuestra webapp en

 HotGloo: Permite diseñar de forma gratuita y permite el diseño colaborativo si se

 Balsamiq: es otra herramienta de prototipado, útil para realizar maquetas de webs

 Para el modelado recomendamos Gliffy, permite crear variedad de diagramas,

Introducción a la Calidad del Software

En la actualización de la Norma ISO, 9000:2000, la definición quedó como el “Grado en

En el libro Ingeniería del Software de Pressman, 1998, se afirma que la calidad es la

Este debe contener las siguientes capacidades:

 Fiabilidad: Capacidad de operar sin errores.

Métricas de calidad de software

La complejidad ciclomática está relacionada a un algoritmo claro y eficaz, que, a su vez,

La Complejidad Cognitiva mide que tan difícil es entender intuitivamente un bloque de

Mide el porcentaje de código que se encuentra testeado. Tener test de calidad en

Claramente esta no es una técnica recomendable. Tener pruebas automatizadas nos

Medir el progreso de la programación por líneas de código es como medir el

Es importante entender que código duplicado no es exactamente un código igual, sino

La existencia de código duplicado afecta a los costos del proceso, ya que provocará una

ISO 9000 0.2.

0.2 Principios de gestión de la calidad

 Liderazgo: Los líderes establecen la unidad de propósito y la orientación de la

 Participación del personal: El personal, a todos los niveles, es la esencia de una

 Enfoque basado en procesos: Un resultado deseado se alcanza más eficientemente

 Enfoque de sistema para la gestión: Identificar, entender y gestionar los procesos

 Mejora continua: La mejora continua del desempeño global de la organización debería