INSTITUTO TECNOLOGICO DE ACAPULCO

INGENIERIA EN SISTEMAS COMPUTACIONALES

DESARROLLO DE PROYECTOS DE SOFTWARE UNIDAD 1 CONCEPTOS INTRODUCTORIOS

INTEGRANTES DEL EQUIPO: Bazan Tornez David Alberto Abrajan Jimenez Cristian Ponciano Rgules Carlos Ivn Oliver Garibo Urias Eduardo Espino Reyes 09320890 09320809 09320777 09320845 09320828

HORA:

1:00 2:00 pm.

Acapulco, gro. A 17 de Febrero del 2014 Acapulco, Gro. A 13 de Febrero del 2014

1.1 LA ARQUITECTURA SOFTWARE EL MODELO 4+1 Algunas notas breves sobre la arquitectura software y su modelizacin en 4+1... La arquitectura software trata el diseo e implementacin de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos para satisfacer la funcionalidad y ejecucin de los requisitos del sistema; as como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc. Perry y Wolf describen una arquitectura software como: Arquitectura Software = {Elementos, Formas, Fundamento/Restricciones} Es muy complejo capturar la arquitectura software en un slo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y caractersticas de la arquitectura en mltiples vistas. Una vista es una presentacin de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva. El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1. Este modelo define 4 vistas principales: Vista Lgica (Logical View), modelo de objetos, clases, entidad relacin, etc. Vista de Proceso (Process View), modelo de concurrencia y sincronizacin.

Vista de Desarrollo (Development View), organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.). Vista Fsica (Physical View), modelo de correspondencia software - hardware (aspectos de distribucin en mquinas, por ejemplo)

Y una vista ms, la "+1", que se muestra y traza en cada una de las anteriores y que est formada por las necesidades funcionales que cubre el sistema, y que en ocasiones identificamos como vista de "casos de uso". De donde deducimos que segn este modelo, la arquitectura es en realidad evolucionada desde escenarios El modelo 4+1 aplica la ecuacin de Perry y Wolf (1992) de forma independiente para cada vista, por ejemplo, cada vista puede definir un conjunto de elementos para su uso (componentes, contenedores y conectores).

Cada vista es descrita usando su particular y ms adecuada notacin (por ejemplo, existen diagramas UML que se adaptan ms a una vista que otra). Para cada vista los arquitectos pueden escoger cierto esquilo arquitectnico (patrn arquitectnico), permitiendo la coexistencia de mltiples estilos en un sistema.

Y por ltimo, tambin comentar que el modelo de vistas 4+1 es genrico: otras notaciones y herramientas a parte de UML pueden usarse, y cualquier mtodo de diseo, especialmente para las descomposiciones lgicas y de proceso. Entonces, para hacer un diseo completo de la Arquitectura de Software debemos documentar nuestro sistema en diferentes Vistas o ngulos, aqu es donde viene el uso del modelo 4 + 1 de Pilippe Kruchten. En la Vista Lgica hablamos principalmente de los requerimientos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y servicios que se han definido. Nos vamos a enfocar a lo que hemos definido como dominio de la aplicacin, lo que son las clases y objetos principales que formaran el corazn o "core" de nuestra aplicacin. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Clases Diagrama de Paquetes

En la Vista de Despliegue o Vista de Desarrollo se va a mostrar principalmente como est dividido nuestro sistema de software en componentes, y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Tambin va a mostrar la organizacin y las dependencias entre el conjunto de componentes, y como se comunican entre ellos. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Componentes Diagrama de Paquetes

En la Vista de Procesos representamos los flujos de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Tambin va a mostrar algunos de los requisitos no funcinales, como son ejecucin, disponibilidad, tolerancia a fallas, integridad, seguridad, confiabilidad entre otros. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Actividad

En la Vista Fsica representamos como estn distribuidos los componentes entre los distintos equipos que conforman la solucin incluyendo los servicios. Los elementos definidos en la vista lgica se mapean a componentes de software o de hardware. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Deployment

Por ultimo tenemos la Vista +1 o Vista de Escenarios, esta vista va a ser representada por los casos de uso, que nos van a ayudar a unir las otras cuatro vistas, as desde un caso de uso podemos ver cmo se van ligando las otras cuatro vistas, con esto tenemos una trazabilidad de componentes, clases, equipo, paquetes, etc., para realizacin cada caso de uso. Esta vista la vamos a complementar con los diagramas UML: Diagrama de Casos de Uso

Relacin entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa s que "sugiere" un mtodo de trabajo. Parece lgico que la vista de escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecucin. Para con todo concluir en la vista fsica. Todo ello, obviamente, con sus correspondientes y tpicas iteraciones. Las distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista estn conectados a los elementos de las otras vistas siguiendo ciertas reglas y heursticas de diseo.

De la vista lgica a la vista de procesos. Identificamos varias caractersticas importantes de las clases de la arquitectura lgica: Autnoma: Los objetos son activos, pasivos o protegidos? Un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus propias operaciones, y tiene el control completo sobre la invocacin de sus operaciones por parte de otros objetos. Un objeto pasivo nunca invoca espontneamente ninguna operacin y no tiene ningn control sobre la invocacin de sus operaciones por parte de otros objetos. un objeto protegido nunca invoca espontneamente ninguna operacin pero ejecuta cierto arbitraje sobre la invocacin de sus operaciones. Persistencia: Los objetos son permanentes o temporales? Qu hacen ante la falla de un proceso o un procesador? Subordinacin: La existencia o persistencia de un objeto depende de otro objeto? Distribucin: Estn el estado y las operaciones de un objeto accesibles desde varios nodos de la arquitectura fsica, y desde varios procesos de la arquitectura de procesos? En la vista lgica de la arquitectura consideramos que cada objeto es activo y potencialmente concurrente, teniendo comportamiento en paralelo con otros objetos, y no prestamos ms atencin al grado preciso de concurrencia que requerimos para alcanzar este efecto. Por lo tanto, la arquitectura lgica tiene en cuenta slo el aspecto funcional de los requisitos. Sin embargo, cuando definimos la arquitectura de procesos, implementar cada objeto con su propio thread de control (e.g., su propio proceso Unix o tarea Ada) no es muy prctico en el estado actual de la tecnologa debido a la gran sobrecarga que esto impone. Ms an, si los objetos son concurrentes, debera haber alguna forma de arbitraje para invocar sus operaciones.

Arquitectura y UML Se ha ido exponiendo a lo largo de la explicacin de cada una de las vistas su translacin a un lenguaje de modelado concreto como UML. Hay que tener en cuenta que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no exista una clara relacin entre ambos, lo que a menudo produce confusin al diseador que en la actualidad quiere modelar una arquitectura con ambas herramientas. A modo de resumen la translacin se presenta en la siguiente tabla: Vista Escenarios Lgica Desarrollo Fsica Procesos UML Casos de Uso Clases, de Estados y Colaboracin Componentes Despliegue Actividad, Estados, Secuencia

Bibliografia Perry D. E., Wolf A. L., Fundamentos para el estudio de la Arquitectura de Software 17, 4, October 1992, P: 40-52.

1.1 La Arquitectura de 4+1 vistas. Este es un modelo para describir la arquitectura de los sistemas intensivos en software, basado en el uso de puntos de vista mltiples, simultneos. este uso de mltiples puntos de vista se pueden abordar por separado las preocupaciones de los diferentes 'stakeholders' (clientes) de la arquitectura. Cada uno de los cinco puntos de vista se describe, junto con una anotacin para capturarlo. Palabras clave: software, punto de vista, diseo orientado a objetos, el proceso de desarrollo de software. A menudo, tambin en la arquitectura no se ocupa de las preocupaciones de todos sus "clientes" Un modelo de arquitectura La Arquitectura de software se refiere al diseo e implementacin de la estructura de alto nivel del software. Arquitectura de software = {elementos, formas, justificacin / restricciones} Arquitectura de software se refiere a la abstraccin, con descomposicin y composicin, con el estilo y la esttica. Para describir una arquitectura de software, se utiliza un modelo compuesto de mltiples puntos de vista o perspectivas. Para finalmente la direccin arquitecturas grandes y difciles, el modelo que proponemos se compone de cinco vistas principales: El punto de vista lgico, que es el modelo de objetos de diseo, cuando un mtodo de diseo orientado a objetos se utiliza, el proceso de ver, que captura los aspectos de concurrencia y la sincronizacin del diseo, el punto de vista fsico, que describe la asignacin del software en el hardware y refleja su aspecto distribuidos, el punto de vista de desarrollo, que se describe la organizacin esttica del software en su desarrollo el medio ambiente. La descripcin de una arquitectura-las decisiones-pueden ser organizados en torno a estos cuatro puntos de vista, y continuacin, se muestra por un grupo selecto casos de uso o escenarios que se convierten en un quinto punto de vista. Cada vista se describe por un modelo con su notacin particular. Para cada punto de vista tambin, los arquitectos pueden elegir un estilo arquitectnico determinado, por lo tanto, lo que permite la convivencia de mltiples estilos en un solo sistema. El "4 +1" modelo de vista es ms bien "genricas": otras notaciones y herramientas se pueden utilizar otros mtodos de diseo puede utilizar, especialmente para los y las descomposiciones lgica y el proceso, sino que han indicado que los han utilizado con xito. La arquitectura lgica La descomposicin orientada a objetos La arquitectura lgica apoya principalmente los requisitos funcionales lo que el sistema deber incluir en los trminos de servicios a sus usuarios. El sistema se descompone en una serie de posibles abstracciones clave, tomadas (en su mayora) del dominio del problema, en forma de objetos o clases de objetos. Que explotan los principios de la abstraccin, encapsulacin y la herencia. Sirve para identificar los mecanismos y elementos comunes de diseo a travs de las distintas partes del sistema. Un diagrama de clases muestra un conjunto de clases y sus relaciones lgicas: la asociacin, el uso, composicin, herencia, etc. grupos de clases relacionadas se pueden agrupar en categoras de clase.

Notacin para el punto de vista lgico La notacin de la vista lgica se deriva de la booch notation. Que se simplifica considerablemente para tomar en cuenta nicamente los elementos que son de gran importancia arquitectnica. En particular, los adornos son numerosas no es muy til en este nivel de diseo. Utilizamos rational rose para apoyar el diseo de arquitectura lgica.

La arquitectura de procesos La descomposicin del proceso la arquitectura de procesos se tienen en cuenta algunos requerimientos no funcionales, tales como el rendimiento y disponibilidad. Se ocupa de cuestiones de la concurrencia y distribucin, de la integridad del sistema, de la tolerancia a fallos, y cmo la abstraccin principal desde el punto de vista lgico incluirse en el proceso de la arquitectura en el que hilo del control es una operacin de un objeto realmente ejecutados. Un proceso es un conjunto de tareas que forman una unidad ejecutable. Los procesos representan el nivel en que la arquitectura de procesos puede ser tcticamente controlado (es decir, comenzar, recuperar, reconfigurar, y apagado). El software se divide en un conjunto de tareas independientes. Una tarea es un hilo de control separado, que pueden ser programadas de forma individual en el nodo de procesamiento. Podemos distinguir entonces: las tareas ms importantes, que son los elementos arquitectnicos que se pueden abordar nicamente y tareas de menor importancia, que son tareas adicionales introducidas a nivel local por razones de aplicacin. La arquitectura de desarrollo Subsistema de descomposicin la arquitectura de desarrollo se centra en la organizacin mdulo de software real en el software medio ambiente y desarrollo. El software est empaquetado en pequeos trozos programa de bibliotecas, o de los subsistemas que pueden ser desarrollados por una o un pequeo nmero de desarrolladores. La arquitectura de desarrollo del sistema est representada por el mdulo y los diagramas de subsistema, que muestra la "exportacin" y las relaciones de importacin. La arquitectura de desarrollo completo slo se puede describir cuando todos los elementos del software han sido identificados. Es, sin embargo, posible a la lista de las normas que rigen la arquitectura de desarrollo: divisin, agrupacin, la visibilidad. La arquitectura fsica Mapeo del software en el hardware la arquitectura fsica tiene en cuenta principalmente los requisitos no funcionales del sistema, tales como disponibilidad, fiabilidad (tolerancia a fallos), el rendimiento (throughput), y la escalabilidad. El software se ejecuta en una red de ordenadores o nodos de procesamiento (o slo los nodos, para abreviar). Los diversos elementos identificadosredes, procesos, tareas y objetos deben ser proyectadas en los distintos nodos.

Escenarios Los escenarios son en cierto sentido, una abstraccin de los requisitos ms importantes. su diseo es expresarse utilizando diagramas de objetos y escenario diagrams4 interaccin de objetos. Este punto de vista es redundante con los otros (de ah el "1"), pero tiene dos propsitos principales: Como conductor para descubrir los elementos arquitectnicos en el diseo de la arquitectura como describiremos ms adelante Como una validacin y papel ilustracin despus de este diseo de la arquitectura es completa, tanto en papel como en la punto de partida para las pruebas de un prototipo de la arquitectura. Notacin para los escenarios La notacin es muy similar a la vista lgica de los componentes, pero utiliza los conectores del punto de vista del proceso de interaccin entre los objetos. Tenga en cuenta que las instancias de objetos se denotan con lneas slidas. Ejemplo de un escenario. El script correspondiente se lee: 1. el controlador de telfono de joe detecta y valida la transicin de colgado ha descolgado y enva un mensaje para despertar el objeto terminal correspondiente. 2. el terminal asigna algunos recursos, y le dice al controlador que emiten algunos de tono de marcado. 3. el controlador recibe los dgitos y los transmite a la terminal. 4. el terminal utiliza el plan de numeracin para analizar el flujo de dgitos. 5. cuando una secuencia vlida de dgitos ha sido introducido, el terminal se abre una conversacin. La documentacin de la arquitectura La documentacin producida durante el diseo arquitectnico es capturada en dos documentos: Un documento de arquitectura de software, cuya organizacin sigue de cerca el "4 +1" vistas. Una gua de software de diseo, que captura el diseo ms importante decisiones que deben ser respetados para mantener la integridad de la arquitectura del sistema. Teniendo como contenido lo siguiente: Ttulo de la pgina Historial de cambios Tabla de contenido

Lista de figuras: 1. Alcance 2. Referencias 3. Arquitectura de software 4. Objetivos de la arquitectura y las limitaciones 5. Arquitectura lgica 6. Proceso de arquitectura 7. Desarrollo de la arquitectura 8. Arquitectura fsica 9. Escenarios 10. Tamao y rendimiento 11. Calidad

1.2 Caractersticas de las tareas Tipos de Tareas de acuerdo a su tiempo de arribo Las Tareas Peridicas son TTR que se activan regularmente con periodo Ti y tiempo de clculo ci conocidos y constantes. La restriccin principal es el plazo de ejecucin (di) donde di Ti. Las tareas peridicas son encontradas comnmente en aplicaciones como aviones y procesos de control donde se requiere un continuo monitoreo y procesamiento de datos. Las Tareas Aperidicas son activadas irregularmente con un periodo desconocido (y tal vez no existente). La restriccin de tiempo es generalmente el plazo di. Las tareas espordicas se caracteriza por un tiempo de ejecucin Ci y un mnimo tiempo de inter-arribo Ti entre tiempos de activacin. Las tareas espordicas son asociadas con procesamiento de eventos que responden a entradas de dispositivos no peridicos; esos eventos ocurren repetidamente, pero el intervalo de tiempo entre ocurrencias consecutivas vara y puede ser arbitrariamente largo.

Modelos de Tareas en Tiempo Real James Martn hace un anlisis de los sistemas de cmputo para realizar tareas en tiempo real, sin embargo, aunque hace una breve descripcin de lo que es un sistema de cmputo en TiempoReal, Se puede definir un sistema de computador en Tiempo -Real como aquel que controla el medio a travs de la recepcin y proceso de datos y que acta o devuelve los resultados con la suficiente rapidez para afectar el funcionamiento del medio en ese momento no menciona como definir las restricciones de tiempo, no presenta ningn modelo de tareas en tiempo real. Menciona las causas por las que un sistema puede ser lento, tomando en cuenta desde los discos duros hasta los sistemas de comunicacin con un modelo de peticin de servicio usando teora de colas y confiabilidad de sistemas.

Condiciones de Liu y Layland Liu y Layland dan las bases para el modelado de STR partiendo de conceptos diferentes a los utilizados por Martn en. En su artculo se hace una mencin a las TTR en donde se asumen ciertas caractersticas en el ambiente. Las tareas en tiempo real se restringen a un conjunto de condiciones: 1) se considera que las tareas crticas son las peridicas con tiempos de arribo constantes entre solicitudes, 2) el plazo consiste solamente en la restriccin de capacidad de ejecucin, esto es, cada tarea debe ser completada antes de que ocurra la prxima solicitud. 3) las tareas son independientes en cuanto a que los tiempos de arribo para ciertas tareas no dependen de la iniciacin o terminacin de solicitudes de otras tares,

4) el tiempo de ejecucin de cada tarea es constante para esa tarea y no vara con el tiempo. Este tiempo de ejecucin se refiere al tiempo que se tome el procesador para ejecutar la tarea sin interrupcin, 5) cualquier tarea aperidica en el sistema es especial; estas son rutinas de inicializacin o recuperacin de fallas; stas tareas desplazan tareas peridicas mientras ellas mismas son ejecutadas y no tienen restricciones de tiempo crticas o tipo hard.

El Modelo general de tareas de Mok y Chen En este modelo se define una tarea en tiempo real como la pareja (, P), donde es un arreglo de tiempos de ejecucin ( 1, 2,.), y P es el tiempo mnimo de separacin, el plazo de cada periodo es P despus de su tiempo de arribo. La desventaja de este modelo es que es necesario conocer los tiempos de ejecucin para cada una de las tareas, pero se pueden tomar en cuenta cualquier tipo de tareas ya que se especifica explcitamente el tiempo de ejecucin de cada una de ellas en cada instante, pero tiene el inconveniente de tener que llevar explcitos los tiempos de ejecucin y por lo tanto su implementacin es complicada.

El modelo Multiframe de Mok y Chen Mok y Chen en proponen que las tareas en tiempo real tipo multiframe quedan definidas con la pareja (,P) donde es un arreglo de N tiempos de ejecucin ( C1, C2,. CN-1), para 1N y P es el tiempo mnimo de separacin. El tiempo de ejecucin del i-simo elemento es ((i 1)mod(N)) C , donde 1 i. El plazo para cada instancia es P despus de su tiempo de arribo.

Caracterizacin de tareas espordicas de Baruah, Mok y Rosier Se explica que un sistema de tareas espordicas es una coleccin de tareas espordicas ,T1, T2,-. Una tarea espordica Ti est caracterizada por tres elementos: tiempo de ejecucin ei, un plazo crtico di, y un periodo mnimo de separacin pi, con ei di y ei pi, de tal forma que Ti=( ei, di, pi), i1 n. En este caso, las tareas se representan con tres valores. No presenta ninguna relacin temporal con las otras tareas.

El modelo de tareas peridicas y espordicas de Ramanathan y Kang Ramanathan y Kang en [15] Define un modelo de tareas espordicas, en donde los tiempos de ejecucin tienen una variacin estocstica y la funcin de distribucin probabilstica de la variacin es conocida para el sistema. Adems cada tarea espordica es asociada con dos costos, Ke y Kl. Ke representa el costo del sistema en caso que la tarea sea rechazada tan pronto como llegue. Kl es el costo del sistema en caso que la tarea no cumpla con su plazo crtico despus de ser aceptada por el sistema. En este caso el costo para el sistema depende de cuando es rechazada la tarea espordica. Las tareas son definidas por su tiempo plazo como (t, Ds), donde t es el tiempo actual y Ds es el tiempo crtico. El tiempo crtico caracterstico de la tarea PS, donde P es el conjunto de tareas peridicas del sistema y S es el conjunto de tareas espordicas del sistema Ds.

El modelo de tareas aperidicas y espordicas de Choi y Agrawala Choi y Agrawala proponen que las tareas aperidicas i (del conjunto de tareas aperidicas =, 1, 2,, N- ) se representan con lo siguiente: Tiempo de arribo Ri Plazo absoluto Di Peor tiempo de ejecucin Ci Variable de ejecucin ei denotando el tiempo de procesamiento ya hecho para i en cualquier instante de tiempo Variable de ejecucin wi denotando el ltimo de comienzo o de i, que es una funcin del tiempo actual t y el valor de ei Tiempo de arribo menor est(i) Tiempo de arribo mayor lst(i) Para las tareas espordicas de tipo crtico se asume que el tiempo de inicio es igual al tiempo de arribo. Se considera que la planificacin inicial de las instancias se da en una ventana de planificacin *0,L+, denotada por . T= ,1, 2, N- es un conjunto de instancias de tarea en , donde i aparece antes que i+1 en . Se define un conjunto S=,S1, S2,,Sm- como el conjunto de tareas espordicas que tienen que ser planificadas con T. Para cada tarea espordica Si se asume que se conocen el tiempo mnimo de interarribo i , el tiempo mximo de ejecucin Si c y el deadline relativo S di (i). Tambin se asume que las Si estn ordenadas ascendentemente por su plazo relativo, S di , ejem, S di S di+1 .

El modelo de tareas peridicas y espordicas de Jeffay, Stanat y Martell Se expone que una tarea peridica se invoca con periodos regulares mientras que una tarea espordica se invoca con perodos arbitrarios de tiempo pero este periodo tiene un valor mnimo conocido. Una tarea T es una pareja (c,p) donde: c es el tiempo de ejecucin mximo de terminacin de la tarea, p es el perodo o intervalo mnimo entre invocaciones de T. Si T es peridico p especifica un intervalo constante entre invocaciones. Si T es espordico p especfica el intervalo mnimo entre invocaciones. Se asume que las invocaciones de las tareas espordicas son independientes y dependen solamente del momento de la ltima invocacin.

Modelo para tareas aperidicas de Spuri y Buttazzo El modelo propuesto da una relacin entre arribos contiguos de dos instancias en una TTR sin llegar a ser un modelo dinmico. Las consideraciones son: Todas la tareas i: i=1,,n tienen plazos crticos; Todas las tareas aperidicas Ji: i=1,,m no tienen plazos; Cada tarea peridica i tiene un periodo constante Ti y un tiempo mximo de ejecucin Ci, qu e se considera conocido y puede ser derivado por un anlisis esttico del cdigo fuente; Todas las tareas peridicas son activada simultneamente al tiempo t=0; por ejemplo, la primer instancia de cada tarea peridica tiene un tiempo de arribo ri(0)=0; El tiempo de arribo de la k-sima instancia peridica est dado por ri(k)=ri(k-1)+Ti; El plazo de la k-sima instancia peridica est dado por di(k)=ri(k)+Ti; El tiempo de arribo de cada tarea aperidica es desconocido; El peor tiempo de ejecucin de cada tarea aperidica se considera conocido en su tiempo de arribo.

Modelo de tareas de Patricia Balbastre Balbastre propone un modelo de tareas peridicas utilizado para el manejo de sistemas de control en tiempo real; divide al sistema en dos fases: la parte del control, definida por el algoritmo de control y su calidad de respuesta y la fase de la Tarea en Tiempo Real. El modelo de tareas que se plantea en esta tesis parte de la definicin de actividad de control. La actividad de control son todas aquellas tareas o procesos relacionados con un mismo bucle de control.

Como respuesta a los problemas expuestos en las secciones anteriores, en este trabajo se presenta un Modelo General para Tiempos de Arribo en Tareas de Tiempo Real basado en un Modelo Recursivo con Promedios Mviles (MRPM) que caracteriza a las TTR: a) peridicas, b) aperidicas y c) espordicas. Para tal fin se propone que el un sistema lineal, de primer orden, variante en el tiempo y no estacionario considerando que el jitter y las perturbaciones externas al procesador no estn correlacionados y obedecen a una funcin de distribucin normal. El modelo propuesto es monovariable, esto quiere decir que solo se caracteriza el tiempo de arribo de una tarea. Se considera que los tiempos de ejecucin mximos; los plazos mnimo y mximos son conocidos; las tareas son crticas; el jitter est acotado dentro de un intervalo conocido.

1.3 Diagramacin Modelos. Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes: Diagrama de Estructura Esttica. Diagrama de Casos de Uso. Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estados.

Diagramas de clases Los diagramas de clases proporcionan una perspectiva esttica del sistema (representan su diseo estructural), son los bloques de construccin ms importantes de cualquier sistema orientado a objetos y es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Como muestra la Figura 1.7 Esta notacin (UML) permite visualizar una abstraccin independientemente de cualquier lenguaje de programacin especfico y de forma que permite resaltar las partes ms importantes de una abstraccin: su nombre, sus atributos y sus operaciones.

Figura 1.7: Clase Cada clase ha de tener un nombre que la distinga de otras clases. El Nombre es una cadena de texto. Ese nombre slo se denomina nombre simple. Una clase puede dibujarse mostrando slo su nombre. Un atributo es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad.

Una operacin es la implementacin de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento, En otras palabras, una operacin es una abstraccin de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase, Una clase puede tener cualquier nmero de operaciones o ninguna, en la figura 1.8 muestra el diagrama completo del dominio conceptual de una aplicacin.

Figura. 1.8. Diagrama de clases Diagrama de Casos de Uso. Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior como se muestra en la figura 1.9. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea.

Figura 1.9: Diagrama de casos de uso

Diagramas de interaccin En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboracin. Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. Figura 1.10.

Figura 1.10: Diagrama de secuencia Un Diagrama de Colaboracin muestra una interaccin organizada basndose en los objetos que toman parte en la interaccin y los enlaces entre los mismos (en cuanto a la interaccin se refiere vase figura 1.11). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboracin muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecucin concurrentes deben determinarse explcitamente mediante nmeros

de secuencia.

Figura 1.11: Diagrama de colaboracin En cuanto a la representacin, un Diagrama de Colaboracin muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que circulan, y con el nombre del mensaje y los parmetros (si los tiene) entre parntesis. Cada mensaje lleva un nmero de secuencia que denota cul es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva nmero de secuencia. Se pueden indicar alternativas con condiciones entre corchetes. Diagramas de Estado. Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En l se indican qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera. En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transicin se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado vase figura 1.12. El segundo compartimento es opcional, y en l pueden aparecer acciones de entrada, de salida y acciones internas.

Figura 1.12: Diagrama de Estados Modelado Fsico De Un Sistema OO. Componentes. Los componentes pertenecen al mundo fsico, es decir, representan un bloque de construccin al modelar aspectos fsicos de un sistema. Una caracterstica bsica de un componente es que debe definir una abstraccin precisa con una interfaz bien definida, y permitiendo reemplazar fcilmente los componentes ms viejos con otros ms nuevos y compatibles. En UML todos los elementos fsicos se modelan como componentes. UML proporciona una representacin grfica para estos como se puede ver en la Figura 1.13, en la que XXXX.dll, es el nombre del componente.

Figura 1.13. Componente fsico Cada componente debe tener un nombre que lo distinga de los dems. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la Figura 1.14.

Figura 1.14. especifico.

Componente

fsico

Agrupacin de Elementos Mediante Paquetes Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Cualquier grupo de elementos, sean estructurales o de comportamiento, puede incluirse en un paquete. Incluso pueden agruparse paquetes dentro de otro paquete. Un paquete se representa como un rectngulo grande con un pequeo rectngulo sobre la esquina superior izquierda a modo de lengeta. Si no se muestra el contenido del paquete entonces el nombre del paquete se coloca dentro del rectngulo grande. Si, por el contrario, se quiere mostrar el contenido del paquete, entonces el contenido va dentro del rectngulo grande y el nombre del paquete va en la lengeta.

Figura 1.15. Agrupacin por Paquetes.

1.3 Diagramacin.

Campos de la Arquitectura de Software La AS es hoy en da un conjunto inmenso y heterogneo de reas de investigacin terica y de formulacin prctica, por lo que conviene aunque ms no sea enumerar algunos de sus campos y sus focos. Una semblanza semejante (de la que aqu se proporciona slo un rudimento) dudosamente debera ser esttica.

La AS comenz siendo una abstraccin descriptiva puntual que en los primeros aos no investig de manera sistemtica ni las relaciones que la vinculaban con los requerimientos previos, ni los pasos metodolgicos a dar luego para comenzar a componer el diseo. Pero esa sincronicidad estructuralista no pudo sostenerse. Por el contrario, dara la impresin que, a medida que pasa el tiempo, la AS tiende a redefinir todos y cada uno de los aspectos de la disciplina madre, la ingeniera de software, slo que a un mayor nivel de abstraccin y agregando una nueva dimensin reflexiva en lo que concierne a la fundamentacin formal del proceso.

Hay unas pocas caracterizaciones (y mucha actividad de copiado y pegado) en torno de las reas que componen el territorio. David Garlan y Dewayne Perry, en su introduccin al volumen de abril de 1995 de IEEE Transactions on Software Engineering dedicado a la AS, en el cual se delinean las reas de investigacin ms promisorias, enumeran las siguientes: Lenguajes de descripcin de arquitecturas Fundamentos formales de la AS (bases matemticas, caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidad, teoras de la interconexin, etctera). Tcnicas de anlisis arquitectnicas Mtodos de desarrollo basados en arquitectura Recuperacin y reutilizacin de arquitectura Codificacin y gua arquitectnica Herramientas y ambientes de diseo arquitectnico Estudios de casos

Fundamental en la concepcin de Clements y Northrop [CN96] es el criterio de reusabilidad como uno de los aspectos que ms hacen por justificar la disciplina misma. Segn estos autores, el estudio actual de la AS puede ser visto como un esfuerzo ex post facto para proporcionar un almacn estructurado de este tipo de informacin reutilizable de diseo de alto nivel propio de una familia (en el sentido de Parnas).

De tal manera, las decisiones de alto nivel inherentes a cada miembro de una familia de programas no necesitan ser re-inventadas, re-validadas y re-descriptas.

Un razonamiento arquitectnico es adems un argumento sobre las cuestiones estructurales de un sistema. Se dira tambin que el concepto de estilo es la encarnacin principal del principio de reusabilidad en el plano arquitectnico. Paul Clements [Cle96b] define cinco temas fundamentales en torno de los cuales se agrupa la disciplina: Diseo o seleccin de la arquitectura: Cmo crear o seleccionar una arquitectura en base de requerimientos funcionales, de rendimiento o de calidad. Representacin de la arquitectura: Cmo comunicar una arquitectura. Este problema se ha manifestado como el problema de la representacin de arquitecturas utilizando recursos lingsticos, pero el problema tambin incluye la seleccin del conjunto de informacin a ser comunicada. Evaluacin y anlisis de la arquitectura: Cmo analizar una arquitectura para predecir cualidades del sistema en que se manifiesta. Un problema semejante es cmo comparar y escoger entre diversas arquitecturas en competencia. Desarrollo y evolucin basados en arquitectura: Cmo construir y mantener un sistema dada una representacin de la cual se cree que es la arquitectura que resolver el problema correspondiente.

Recuperacin de la arquitectura: Cmo hacer que un sistema legacy evolucione cuando los cambios afectan su estructura; para los sistemas de los que se carezca de documentacin confiable, esto involucra primero una arqueo loga arquitectnica que extraiga su arquitectura.

Mary Shaw considera que en el 2001 los campos ms promisorios de la AS siguen teniendo que ver con el tratamiento sistemtico de los estilos, el desarrollo de lenguajes de descripcin arquitectnica, la formulacin de metodologas y (ahora) el trabajo con patrones de diseo. Se requieren todava modelos precisos que permitan

razonar sobre las propiedades de una arquitectura y verificar su consistencia y completitud, as como la automatizacin del proceso de anlisis, diseo y sntesis.

Sugiere que debe aprenderse una leccin a partir de la experiencia de la ingeniera de software, la cual no obstante haberse desenvuelto durante treinta aos no ha logrado plasmar un conjunto de paradigmas de investigacin comparable al de otras reas de las ciencias de la computacin. Estima que la AS se encuentra ya en su fase de desarrollo y extensin, pero que tanto las ideas como las herramientas distan de estar maduras. Un campo que no figura en estas listas pero sobre el cual se est trabajando intensamente es en el de la coordinacin de los ADLs que sobrevivan con UML 2.0 por un lado y con XML por el otro.

Ningn lenguaje de descripcin arquitectnica en el futuro prximo (excepto los que tengan un nicho tcnico muy particular) ser viable si no satisface esos dos requisitos. Los ejercicios que pueden hacerse para precisar los campos de la AS son incontables. Ahora que la AS se ha abismado en el desarrollo de metodologas, hace falta, por ejemplo, establecer con ms claridad en qu difieren sus elaboraciones en torno del diseo, del anlisis de requerimientos o de justificacin econmica de las llevadas a cabo por la ingeniera de software.

Asimismo, se est esperando todava una lista sistemtica y exhaustiva que describa los dominios de incumbencia de la disciplina, as como un examen del riesgo de duplicacin de esfuerzos entre campos disciplinarios mal comunicados, una situacin que a primera vista parecera contradictoria con el principio de reusabilidad.