Republica Bolivariana De Venezuela

Ministerios Del Poder Popular Para La Defensa

Universidad Nacional Experimental Politcnica De Las Fuerzas Armadas
(UNEFA)
Maracaibo Edo. Zulia

Estilo de Cdigo
Mvil

Integrantes
Jhonatan Cuamo
Cindy Padillla
Jenifer Balza
Leslie

Esquema

Introduccin..3

Estilo de cdigo mvil4

Arquitectura de maquinas
virtuales...4

Arquitecturas basadas en
eventos....6

Patrones arquitectnicos...9

Conclusin13

Bibliografia.....14

Introduccin

En la presente investigacin se estudiara los siguientes de puntos:

Estilos de Cdigo Mvil que no es ms que una familia de estilos que enfatiza
la portabilidad un ejemplo de ello son los mismos intrpretes, donde los
sistemas estn basados en reglas y los procesadores de lenguaje de comando.

La Arquitectura de Mquinas Virtuales llamado tambin intrpretes basados en

tabla donde todo intrprete involucra una mquina virtual implementada en
software.

Las arquitecturas basadas en evento llamado tambin de invocacin implcita

donde su funcin es de invocar un componente que se puede anunciar
mediante difusin uno o ms eventos.

Patrones arquitectnicos son los que definen la estructura de un sistema

software, los cuales a su vez se componen de subsistemas con sus
responsabilidades.

Estilos de Cdigo Mvil

Esta familia de estilos enfatiza la portabilidad. Ejemplos de la misma son los

intrpretes, los sistemas basados en reglas y los procesadores de lenguaje de
comando. Fuera de las mquinas virtuales y los intrpretes, los otros miembros
del conjunto han sido rara vez estudiados desde el punto de vista estilstico.

Los sistemas basados en reglas, que a veces se agrupan como miembros de la

familia de estilos basados en datos, han sido estudiados particularmente por
Murrell, Gamble, Stiger y Plant [MPG96] [SG97] [GSP99]

Arquitectura de Mquinas Virtuales

La arquitectura de mquinas virtuales se ha llamado tambin intrpretes

basados en tablas [GS94] [SC96]. De hecho, todo intrprete involucra una
mquina virtual implementada en software. Se puede decir que un intrprete
incluye un seudo-programa a interpretar y una mquina de interpretacin. El
seudo-programa a su vez incluye el programa mismo y el anlogo que hace el
intrprete de su estado de ejecucin (o registro de activacin). La mquina de
interpretacin incluye tanto la definicin del intrprete como el estado actual
de su ejecucin. De este modo, un intrprete posee por lo general cuatro
componentes:(1) una mquina de interpretacin que lleva a cabo la tarea, (2)
una memoria que contiene el seudo-cdigo a interpretar, (3) una
representacin del estado de control de la mquina de interpretacin, y (4) una
representacin del estado actual del programa que se simula. El estilo
comprende bsicamente dos formas o sub-estilos, que se han llamado
intrpretes y sistemas basados en reglas. Ambas variedades abarcan, sin duda,
un extenso espectro que va desde los llamados lenguajes de alto nivel hasta
los paradigmas declarativos no secuenciales de programacin, que todo el
mundo sabe que implementan un proxy (una especie de nivel de impostura)
que encubren al usuario operaciones que en ltima instancia se resuelven en
instrucciones de mquinas afines al paradigma secuencial imperativo de
siempre

El estilo es su conjunto se utiliza habitualmente para construir mquinas

virtuales que reducen el vaco que media entre el engine de computacin
esperado por la semntica del programa y el engine fsicamente disponible. Las
aplicaciones inscriptas en este estilo simulan funcionalidades no nativas al
hardware y software en que se implementan, o capacidades que exceden a (o
que no coinciden con) las capacidades del paradigma de programacin que se
est implementando. Dado que hasta cierto punto las mquinas virtuales no
son una opcin sino que devienen inevitables en ciertos contextos, nadie se ha
entretenido identificando sus ventajas y demritos

Las mquinas virtuales no son una invencin reciente ligada a Java, sino que
existen desde muy antiguo. En la dcada de 1950, los precursores de los
ingenieros de software sugirieron una mquina virtual basada en un lenguaje
de mquina universal de bytecodes(un ejemplo fue UNCOL), de manera que las
aplicaciones podan escribirse en las capas
En la nueva estrategia arquitectnica de Microsoft la mquina virtual por
excelencia guarda relacin con el Common Language Runtime, acaso unas de
las dos piezas esenciales del framework .NET (la otra es la biblioteca de
clases). El CLR admite, en efecto, diversos paradigmas puros y templados:
programacin funcional (Lisp, Scheme,F#, Haskell), programacin imperativa
orientada a objetos (C#, J#, C++, Python) y estructurada en bloques (Oberon),
ambientes de objetos puros (Smallscript / Smalltalk),programacin lgica
declarativa (Prolog, P#), diseo basado en contratos (Eiffel),modelado
matemtico (Fortran), scripting interpretado (Perl), meta-programacin (SML,
Mondrian), programacin cercana a la semntica de negocios (Cobol),
programacin centrada en reportes (Visual ASNA RPG), adems de todos los
matices y composiciones heterogneas a que haya lugar. Si bien el lenguaje
final de implementacin se encuentra en un punto del proceso bastante alejado
de la ideacin arquitectnica en que se despliegan los estilos, el efecto de la
disponibilidad de estas capacidades en el diseo inicial de un sistema no es
para nada trivial. Con una mquina virtual comn el proceso evita la
redundancia de motores compitiendo por recursos y unifica debuggers y
profilers. La congruencia entre la naturaleza semntica y sintctica del modelo
y la de los lenguajes de programacin concretos ha sido, despus de todo, una
de las banderas del modelado orientado a objetos, desde OMT hasta UML,
pasando por el modelado no slo de las aplicaciones sino de las bases de datos
[RBP+91]

Arquitecturas Basadas en Eventos

Las arquitecturas basadas en eventos se han llamado tambin de invocacin

implcita [SG96]. Otros nombres propuestos para el mismo estilo han sido
integracin reactiva o difusin (broadcast) selectiva. Por supuesto que existen
estrategias de programacin basadas en eventos, sobre todo referidas a
interfaces de usuario, y hay adems eventos en los modelos de objetos y
componentes, pero no es a eso a lo que se refiere primariamente el estilo,
aunque esa variedad no est del todo excluida. En trminos de patrones de
diseo, el patrn que corresponde ms estrechamente a este estilo es el que
se conoce como Observer, un trmino que se hizo popular en Smalltalk a

principios de los ochenta; en el mundo de Java se le conoce como modelo de

delegacin de eventos [Lar03].

Las arquitecturas basadas en eventos se vinculan histricamente con sistemas

basados en actores, daemons y redes de conmutacin de paquetes
(publicacin-suscripcin). Los conectores de estos sistemas incluyen
procedimientos de llamada tradicionales y vnculos entre anuncios de eventos
e invocacin de procedimientos. La idea dominante en la invocacin implcita
es que, en lugar de invocar un procedimiento en forma directa (como se hara
en un estilo orientado a objetos) un componente puede anunciar mediante
difusin uno o ms eventos.

Un componente de un sistema puede anunciar su inters en un evento

determinado asociando un procedimiento con la manifestacin de dicho
evento. Un caso clsico en ambientes Microsoft sera el Servicio de Notificacin
de SQL Server. Cuando el evento se anuncia, el sistema invoca todos los
procedimientos que se han registrado para l. De este modo, el anuncio de un
evento implcitamente ocasiona la invocacin de determinados procedimientos
en otros mdulos.
Tambin hay elementos de arquitectura de publicacin-suscripcin en el
modelo de replicacin de SQL Server (definido en su documentacin como una
metfora de industria), en el PublishSubscribe Toolkit de BizTalk Server 2002 [Chu02] o el Publish-Subscribe API de
Windows CE .NET 4.2.

Desde el punto de vista arquitectnico, los componentes de un estilo de

invocacin implcita son mdulos cuyas interfaces proporcionan tanto una
coleccin de procedimientos (igual que en el estilo de tipos de datos
abstractos) como un conjunto de eventos. Los procedimientos se pueden
invocar a la manera usual en modelos orientados a objeto, o mediante el
sistema de suscripcin que se ha descripto.

Los ejemplos de sistemas que utilizan esta arquitectura son numerosos. El

estilo se utiliza en ambientes de integracin de herramientas, en sistemas de
gestin de base de datos para asegurar las restricciones de consistencia (bajo
la forma de disparadores, por ejemplo), en interfaces de usuario para separar
la presentacin de los datos de los procedimientos que gestionan datos, y en

editores sintcticamente orientados para proporcionar verificacin semntica

incremental.

Un estilo perteneciente a esta clase es C2 o Chiron-2. Una aplicacin de

arquitectura C2 est constituida por componentes que se comunican a travs
de buses; la comunicacin est basada en eventos. Un componente puede
enviar o recibir eventos hacia o desde los buses a los que est conectado.
Componentes y buses se pueden componer topolgicamente de distintas
maneras, siguiendo reglas y restricciones particulares. Cada componente
posee dos puntos de conexin, llamados respectivamente top y bottom. El
esquema no admite ciclos, de modo que un componente no puede recibir una
notificacin generada por l mismo [DNR99].

En la estrategia arquitectnica de Microsoft, este estilo (llamado ms bien un

patrn recurrente de diseo) juega un papel de alguna importancia [MS02a].
En este estilo y en ese contexto, los eventos se disparan bajo condiciones de
negocios particulares, debindose escribir cdigo para responder a esos
eventos. Este patrn puede utilizarse cuando se desea que sucedan varias
actividades, tal que todas ellas reciben los mismos datos de iniciacin y no
pueden comunicarse entre s. Diferentes implementaciones del evento pueden
o no ejecutarse, dependiendo de informacin de filtro especfica. Si las
implementaciones se han configurado para que corran secuencialmente, el
orden no puede garantizarse. Las prescripciones de Microsoft para el uso del
modelo de eventos sealan que este estilo puede utilizarse cuando:

Se desea manejar independientemente y de forma aislada diversas

implementaciones de una funcin especfica.

Las respuestas de una implementacin no afectan la forma en que

trabajan otras implementaciones.

Todas las implementaciones son de escritura solamente o de dispararsey-olvidar, tal que la salida del proceso de negocios no est definida por ninguna
implementacin, o es definida slo por una implementacin de negocios
especfica.
Entre las ventajas enumeradas en relacin con el modelo se sealan:

Se optimiza el mantenimiento haciendo que procesos de negocios que

no estn relacionados sean independientes.


Se alienta el desarrollo en paralelo, lo que puede resultar en mejoras de
performance.

Es fcil de empaquetar en una transaccin atmica.

Es agnstica en lo que respecta a si las implementaciones corren

sincrnica o asincrnicamente porque no se espera una respuesta.
Se puede agregar un componente registrndolo para los eventos del sistema;
se pueden reemplazar componentes.
Entre las desventajas:
El estilo no permite construir respuestas complejas a funciones de negocios.
Un componente no puede utilizar los datos o el estado de otro componente
para efectuar su tarea.
Cuando un componente anuncia un evento, no tiene idea sobre qu otros
componentes estn interesados en l, ni el orden en que sern invocados, ni el
momento en que finalizan lo que tienen que hacer. Pueden surgir problemas de
performance global y de manejo de recursos cuando se comparte un
repositorio comn para coordinar la interaccin.

En esta estrategia juega un rol importante el Servicio de Eventos, el cual a su

vez proporciona un buen punto de partida para la implementacin del estilo o
patrn, segn se est concibiendo la arquitectura o implementndola.

Patrones arquitectnicos

son los que definen la estructura de un sistema software, los cuales a su vez se
componen de subsistemas con sus responsabilidades, tambin tienen una serie
de directivas para organizar los componentes del mismo sistema, con el
objetivo de facilitar la tarea del diseo de tal sistema.

De esta manera decimos que el estilo est asociado a formas generales de

organizacin sistemas orientados al objeto- mientras que los patrones estarn
asociados a formas ms concretas, que tienen que ver con la especializacin
que adoptan los objetos y clases de acuerdo al tipo de aplicacin o entorno
tecnolgico, a tcnicas conocidas por su eficiencia para resolver ciertos
problemas, etc.

Por ejemplo, pensando que el entorno de ejecucin de una aplicacin puede

estar distribuido en distintos elementos nodos- es aconsejable y beneficioso
descomponer la aplicacin en capas, correspondientes a los nodos donde
podra tener que ejecutarse. Los beneficios de dicha descomposicin son
varios, entre los cuales se mencionan:
1) Se puede comprender una capa como un todo coherente, sin necesidad de
conocer las restantes.
2) Se puede sustituir una capa con implementaciones alternativas de los
mismos servicios bsicos.
3) Se minimizan las dependencias entre las capas.
4) Las capas son un buen sitio para la estandarizacin.
5) Una vez implementada una capa, se la puede utilizar para muchos servicios
de alto nivel.

La descomposicin ms habitual es decir el patrn usualmente empleado- es

dividir la aplicacin en tres capas: 1) Lgica de presentacin, que se ocupa de
toda la interaccin entre el usuario y el software, pudiendo tratarse de un
sistema de mens muy simple o una interfaz grfica de usuario relativamente
compleja; 2) La lgica del dominio, tambin conocida como la lgica de
negocio, que es todo lo que necesita conocer la aplicacin para poder trabajar
con el dominio en cuestin. Implica realizar clculos basados en datos de
entrada o almacenados, validacin de cualquier dato proveniente de la capa de
presentacin y la ejecucin de algoritmos especficos en funcin de los
comandos de la presentacin; y 3) la lgica de fuente de datos, que se ocupa
de comunicarse con otros sistemas que se encargan de tareas en
representacin de la aplicacin. Estos pueden ser monitores de transacciones,
otras aplicaciones, sistemas de mensajes, etc.

Otro ejemplo de patrn arquitectnico podra ser el de Mdulo Tabla, uno de los
mltiples patrones presentado por Martin Fowler en Patterns of Enterprise
Application Architecture (2003). El enfoque tradicional de la orientacin al
objeto est basado en objetos que tienen una identidad. Es decir que si
tenemos una clase Empleado, cualquier instancia de la misma corresponde a
un empleado particular. Este esquema funciona bien porque una vez que
tenemos una referencia a un empleado, podemos ejecutar operaciones, seguir
relaciones y recoger informacin sobre el mismo.

Pero uno de los problemas con este modelo es la interfaz con las bases de
datos relacionales. En muchos casos este enfoque se asemeja al del pariente
loco, que vive encerrado en un tico y del cual nadie quiere hablar: con
frecuencia este enfoque requiere un trabajo considerable de programacin
para llevar los datos y extraerlos de la base de datos y transformarlos a otro
tipo diferente de representacin.

La ventaja de este patrn es que organizamos la lgica del dominio con slo
una clase por tabla de la base de datos, ya que una nica instancia de la clase
contiene los diversos procedimientos que se aplicarn a los datos. La diferencia
fundamental con un esquema clsico llamado tambin Modelo de Dominio- es
que, si tenemos varios pedidos, este ltimo modelo emplear un objeto por
cada pedido, mientras que el Mdulo Tabla tendr slo un objeto para manejar
todos los pedidos, con lo cual aumentamos la granularidad de los objetos de la
aplicacin.

Como hemos podido ver, la diferencia entre los estilos y patrones

arquitectnicos est en el nivel de abstraccin en el que nos movemos. Los
estilos se aplican a un nivel muy alto de abstraccin, en el cual no interesa
saber cul es la semntica de los elementos que estamos utilizando, slo
hablamos de filtros, tubos u objetos sin interesarnos por lo que estn
representando. En el caso de los patrones, tenemos en cuenta el significado de
los filtros, tubos u objetos, tal como hemos visto en los patrones de
descomposicin en capas en el que se habla de presentacin, dominio de
aplicacin y de datos- o en el de Mdulo Tabla, que diferencia entre un objeto
que representa un elemento -una lnea de una tabla o registro- u otro objeto
que representa la totalidad de la tabla.

Otro aspecto importante que menciona Fowler pero que adjudica a Ralph
Johnson- es que la arquitectura es algo subjetivo, una comprensin compartida
del diseo de un sistema por parte de los desarrolladores de un sistema. En
general, esta comprensin compartida est expresada en trminos de los
principales componentes del sistema y de sus interacciones. Pero es tambin
sobre las decisiones, en especial aquellas que deben tomar correctamente al
principio del proyecto porque se las considera difciles de cambiar. Este
componente de subjetividad se debe al hecho de que si algo resulta ms fcil
de cambiar de lo que imaginbamos al comienzo, deja de ser una decisin
arquitectnica o sobre la arquitectura.

Conclusin

Bibliografa

http://homepage.mac.com/imaz/iblog/C612772037/E20050907222635/Media/Al
gunos%20Tipos%20de%20Arquitecturas.pdf.

Estilos y Patrones en la Estrategia de Arquitectura de Microsoft.

Carlos Reynoso Nicols Kicillof
Universidad De Buenos Aires