ANALISIS DE SISTEMAS DE TIEMPO REAL

Proceso del Software proporciona un Marco de trabajo de las tareas que se requieren para
construir software de alta calidad. estabilidad, control y organizacin a una actividad. Depende del
Software que se est construyendo. Los Productos obtenidos son: programas, documentos y
datos.

Modelo de proceso software:

Estrategia de desarrollo que acompaa al proceso. Se selecciona un modelo de proceso para la
IS segn la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse
y los controles y entregas que se requieren.
Todo el desarrollo del software se puede caracterizar como un bucle de resolucin de problemas:

Est
ado
act
ual

Defi
nici
n de
Integ
probl
raci
nemas
de
soluc
iones

Desa
rroll
o
tcni
co

Anlisis y Diseo Estructurado

El anlisis estructurado para STR se basa en la nocin del flujo de datos entre sucesivas
transformaciones y provee un pequeo soporte para identificar procesos concurrentes que deben
ser implementados en una aplicacin dada.
El anlisis estructurado de Yourdon describe un sistema a travs de:
Modelo ambiental
Modelo de comportamiento
Modelo de implementacin.

El anlisis estructurado usa herramientas graficas y mtodos de descomposicin funcional TOPdown para definir los requerimientos del sistema. Este trata solo con aspectos del anlisis que
pueden ser estructurados: especificaciones funcionales y las interfaces de usuario.
Es usado para modelar el contexto del sistema, el proceso (cuales funciones lleva a cabo el
sistema, cmo interactan las funciones y como las entradas son transformadas en salidas), y el
contenido (los datos que necesita el sistema para ejecutar las funciones).

Anlisis de Requisitos
La ingeniera de Requerimientos es la subdisciplina de la ingeniera de software a la que le
concierne determinar los objetivos, funciones y restricciones del sistema y la representacin de
esos aspectos para el modelado y el anlisis. El objetivo es crear una especificacin de
requerimientos que sea completa, correcta y comprensible tanto para los clientes como los
desarrolladores.
Permite a los clientes asegurarse que el producto bajo desarrollo cumple con sus necesidades y
expectativas y para los desarrolladores es una completa representacin de las funciones y
restricciones del sistema.
En el dominio de los STR esto es mas complicado por la necesidad de representar las
restricciones temporales y de rendimiento tan pronto como se determinan los requerimientos
funcionales.
El proceso de la ing. de requerimientos comienza con un estudio preliminar que una investigacin
respecto a la motivacin del proyecto y la naturaleza del problema. Esta investigacin puede
consistir en las perspectivas y restricciones de los stakeholder, determinar el alcance del proyecto
y la naturaleza de las prioridades y en los STR un anlisis temprano de las restricciones
temporales impuestas al sistema.
La elicitacin de requerimientos involucra obtener requerimientos a travs de una variedad de
tcnicas tales como entrevistas y cuestionarios con los stakeholder, reuniones grupales,
Workshops y prototipado.
Los requisitos pueden ser expresados en muchas formas desde narrativas textuales a
formalismos matemticos, es usual ser representados en la forma de un modelo del dominio, que
puede incluir artefactos como casos de uso, diagramas de entidad relacin o diagramas de
contexto.
El resultado de este proceso es un documento de especificacin de requisitos de software, el cual
es una descripcin de las caractersticas, comportamiento y restricciones del sistema final
El estndar para los STR es el IEEE830 que define las siguientes clases de requisitos:
Funcionales
No funcionales:
Interfaces externas
Desempeo
Bases de datos lgicas
Restricciones de diseo: estndares y atributos del sistema software
Atributos del Sist. software:
Confiabilidad
Disponibilidad
Seguridad
2

Mantenibilidad
Portabilidad
Requisitos funcionales: incluyen una descripcin de todas las entradas del sistema y la
secuencia de operaciones asociadas con cada conjunto de entradas.
Requerimientos de interfaces externas: son una descripcin de todas las entradas y salidas
para el sistema.
Requerimientos de desempeo: incluyen los requerimientos estticos y dinmicos ubicados en
el software o en la iteracin humana con el software como un todo. Para un STR, los req estticos
podran incluir el nmero de usuarios simultneos que pueden ser soportados. Los req dinmicos
podran incluir el nmero de transacciones y tareas y la cantidad de datos a ser procesados en
cierto periodo de tiempo para condiciones normales y de sobrecarga.
Requerimientos de bases de datos lgicas: incluyen los tipos de informacin usada por las
funciones, tales como frecuencia de uso, capacidades de acceso, entidades de datos y sus
relaciones, restricciones de integridad y req. de retencion de datos.
Requerimientos de restricciones de diseo: estn relacionados con el cumplimiento de
estndares y limitaciones de hardware.
Como se representan los requisitos para los STR: se puede usar una o una combinacin de
las siguientes aproximaciones:
Proceso de descomposicin TOP/down o anlisis estructurado.
Aproximaciones orientadas a objetos
Lenguajes de descripcin de programas (PDL) o pseudocdigo
Especificaciones funcionales de alto nivel
Tcnica ad hoc, incluyendo lenguaje natural y descripciones matemticas.

Clasificacin de tcnicas de especificacin:

Formal: tienen una base matemtica rigurosa. Estos desarrollan formulaciones y expresiones
mediante el uso y extensin de aproximaciones matemticas tales como lgica proposicional,
calculo de predicado y teora de conjuntos.
Esta tcnica ofrece la posibilidad de descubrir errores en etapas tempranas del ciclo de vida de
desarrollo donde se pueden corregir rpidamente y aun bajo costo.
Limitaciones de los mtodos formales: estos tienen dos limitaciones que son de especial inters
para los desarrolladores de STR:
Aunque los formalismos frecuentemente son usados para buscar correctitud y seguridad
absoluta, no pueden garantizar ninguna.
Las tcnicas formales todava no ofrecen una buena manera de razonar acerca de diseos
o arquitecturas alternativas.
Semiformales: emplean notacin grfica bien definidos. Dichos esquemas se construyen a partir
de un pequeo nmero de componentes predefinidos que pueden conectarse de una forma
controlada.
Informal: hacen uso del lenguaje natural y de grficos no estructurados. Ejemplo diagramas de
flujo.

Modelado
Los modelos se crean para entender mejor la entidad que se va a construir.
Es la representacin o abstraccin formal y simplificada de un aspecto de la realidad en un
lenguaje especfico.
Abstraccin: solo toma aquellos aspectos que son relevantes, en funcin del objetivo.
Simplificacin o reduccionismo: se basa en:
Finalidad: determinar con qu objetivo se desea conocer y estudiar la realidad.
Caractersticas (factores objetivos y subjetivos) del observador: capacidad de
abstraccin y experiencia.
Tipos de modelos

Funcionales: el soft transforma la informacin y, para hacerlo, debe realizar al menos tres
funciones genricas: entrada, procesamiento y salida.
El modelo funcional comienza con un modelo a nivel contexto, luego de una serie de iteraciones
se consiguen mas detalles funcionales.
Modelos de comportamiento: la mayora del software responde a los acontecimientos del mundo
exterior. Esta caracterstica estmulo-respuesta forma la base del modelo del comportamiento. Un
programa de computadora siempre est en un estado, un modo de comportamiento observable
exteriormente (por ej, esperando, calculando, imprimiendo, haciendo cola) que cambia slo
cuando ocurre algn suceso.

Diagrama de Contexto
Modelo fundamental del sistema o DFD nivel 0. Representa al sistema completo como una sola
burbuja. Muestra:
-Las personas, organizaciones, equipamiento y subsistemas con los que se comunica el sistema:
entidades externas.
-Las interfaces con las entidades externas:
Los datos que el sistema recibe del mundo exterior y que deben procesarse de
alguna forma.
Los datos que el sistema produce y que se envan al mundo exterior.
Las entradas y salidas especificadas en este nivel deben permanecer constantes en los
diagramas subsecuentes.
-Los almacenes de datos que el sistema comparte con las entidades externas.
-La frontera entre el sistema y el resto del mundo.
Los Diagramas de Flujos de Datos pueden ser divididos en niveles que representen un mayor
flujo de informacin y un mayor detalle funcional.

Eventos
Lista de Eventos
Los eventos (sucesos) se implementan como valores lgicos (ej: V o F, si o no, 1 o 0) o como una
lista discreta de condiciones (vaca, atascada, llena).
Para seleccionar posibles candidatos a eventos, se pueden sugerir las siguientes directrices:
Listar:
Todos los sensores que son ledos por el soft.
Todas las condiciones de interrupcin.
Todos los interruptores que son accionados por el operador.
Todas las condiciones de datos.
Revisar todos los elementos de control como posibles
entradas/salidas de
Especificaciones de Controles.
Describir el comportamiento del sistema identificando sus estados; identificar cmo se
alcanza cada estado y definir las transiciones entre los estados.
Los eventos pueden ser.
Datos (D): llega algn dato o varios.
Temporales (T): no se inician con flujo de datos de entrada.
Control ( C): Caso especial del evento temporal: estmulo externo que ocurre en algn
momento impredecible.
Flujo de control: puede considerarse como un flujo de datos binario: est encendido o apagado
y puede cambiar de un estado a otro en cualquier momento, sealando as al sistema que se
necesita tomar alguna accin inmediata.

Diagrama de Entidad Relacin (DER)

Define todos los datos que se introducen, se almacenan, se transforman y se producen dentro de
una aplicacin. El modelado de datos estudia los datos independientemente del procesamiento
que los transforma.
Su propsito es representar objetos de datos y sus relaciones.
Se compone de: objeto de datos, atributos que describen el objeto de datos y la relacin que
conecta objetos de datos entre s.
Objeto de datos: puede ser una entidad externa (ej cualquier cosa que produce o
consume informacin), una cosa (ej un informe, una pantalla), una ocurrencia (ej una
llamada telefnica) o suceso (ej una alarma).
*Atributos: los atributos definen las propiedades de un objeto de datos.
Relaciones: como se conectan los objetos de datos.
Cardinalidad: nmero de ocurrencias de objetos que se dan en una relacin. Se expresa
como uno o muchos. Uno a uno (1:1); uno a muchos (1:N); muchos a muchos (M:N).
Modalidad: de una relacin es cero si no hay una necesidad explcita de que ocurra una
relacin, o que sea opcional.
Es uno si una ocurrencia de la relacin es obligatoria.

Metodologa Ward-Mellor Hasytley-Pirbhai

Metodologa Ward-Mellor
Amplia la notacin del anlisis estructurado
para adaptarlo a los sistemas de tiempo real
permitiendo:
la representacin de datos discretos y
continuos en el tiempo.
La informacin de control que pasa del
sistema al proceso asociado.
Estados del sistema y transiciones de
estos.
Ocurrencias mltiples de transformaciones
que se encuentran en situacin de
multitarea.
Para su representacin grfica utiliza:
Flujo de datos continuo en el tiempo, un
flecha dos puntas.
Flujo de datos discreto en el tiempo, una
flecha con una punta.
Flujo de datos, flecha de trazo continuo.
Flujo de control, flecha de trazo
discontinuo.
Proceso de Control con una burbuja de
trazo discontinuo.
Almacn de datos de control con lneas
paralelas discontinuas.
Almacn de datos con lneas paralelas
continas.
Se incluyen en el diagrama de flujo una
representacin para el diagrama de flujo de
control, en el cual los flujos de control pueden
ser una entrada directa de un proceso
convencional o de un proceso de control. El
5

Metodologa Hastley-Pirbhai
La representacin consiste en un modelo de
procesos y uno de control.
El modelo de proceso permite representar los
datos y los procesos que los manejan.
El modelo de control ilustra como los
sucesos externos hacen que se activen los
procesos.

Para su representacin grfica utiliza:

Flechas de trazos discontinuos para
representar el flujo de control.
Una especificacin de control se
representa con una barra slida.
Los procesos se representa por medio de
una burbuja de trazo continuo.
Los estados del sistema con rectngulos.
Las transiciones entre los estados con
flechas

Se usa una especificacin de control para

indicar el comportamiento del software
cuando se detecta un evento y que procesos
se invocan a partir de este. La especificacin
de control se puede representar de dos

procesamiento de control tambin se introdujo formas:

en el diagrama de flujo debido a que en Tabla de activacin de proceso: para
indicar que procesos se activan por un
algunas situaciones en un STR puede haber
evento que fluye por la barra vertical.
ocurrencias mltiples del mismo proceso de
Diagrama de transicin de estados:
control o de transformacin de datos.
representa
el
comportamiento
del
sistema, los estados de este y sus
cambios debido a los eventos que se
producen.
Se usa una especificacin de proceso para
describir el procesamiento interno de los
procesos representados en el diagrama de
flujo, por medio de una narrativa textual,
ecuaciones matemticas, diagramas o
grficos.

DICCIONARIO DE DATOS
Describe el contenido de los objetos definidos durante el anlisis estructurado. Contiene la
siguiente informacin:
Nombre: nombre principal del elemento de datos o de control, del almacn de datos o de
una entidad externa.
Alias: otros nombres usados para la primera entrada.
Dnde se usa / cmo se usa: listado de los procesos que usan el elemento de datos o de
control y como lo usan.
Descripcin del contenido: contenido representado mediante una notacin.
Informacin adicional: ej valores implcitos. Restricciones, limitaciones etc.