SECRETARA DE EDUCACIN PBLICA

DIRECCIN GENERAL DE EDUCACIN SUPERIOR

TECNOLOGICA
INSTITUTO TECNOLGICO DE VERACRUZ.

MATERIA:
FUNDAMENTOS DE INGENIERA DE SOFTWARE

ALUMNO
AZAMAR GREGORIO VICTOR ANTONIO

MAESTRO TITULAR DE LA MATERIA:

ALMEIDA GONZALEZ SANTIAGO MARTIN

FECHA DE ENTREGA:
8 JUNIO DE 2016

TEMA:
ARQUITECTURAS DE SOFTWARE

INTRODUCCIN
En este trabajo veremos diferentes tipos de conceptos y caractersticas que nos hablan sobre las arquitecturas de software,
descomposicin modular, patrones de diseo as como tambin diseos de software.
Antes de empezar, hay que tener en claro que una arquitectura de software es un conjunto de patrones que proporcionan un
marco de referencia necesario para guiar la construccin de un software, permitiendo a los programadores, analistas y todo
el conjunto de desarrolladores del software compartir una misma lnea de trabajo y cubrir todos los objetivos y restricciones
de la aplicacin. Es considerada el nivel ms alto en el diseo de la arquitectura de un sistema puesto que establecen la
estructura, funcionamiento e interaccin entre las partes del software.
El diseo de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software
producir varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la
solucin de la aplicacin. Estos modelos pueden evaluarse en relacin con su calidad y mejorarse antes de generar cdigo,
de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseo es el sitio en el que se
establece la calidad del software.
En el transcurso del contenido le explicaremos ms detalladamente cada uno de estos temas.

DESCOMPOSICIN MODULAR
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces.
Sus ventajas: claridad, reduccin de costos y reutilizacin Los pasos a seguir son:
1.
2.
3.

Identificar los mdulos

Describir cada mdulo
Describir las relaciones entre mdulos

Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficiente validad.
1.
2.
3.
4.
5.

Independencia funcional
Acoplamiento
Cohesin
Comprensibilidad
Adaptabilidad

a) INDEPENDENCIA FUNCIONAL
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones
entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin.
b) ACOPLAMIENTO
El acoplamiento es una medida de la interconexin entre mdulos en la estructura del programa. Podemos graduara en un
amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las
interconexiones entre los distintos mdulos en que se estructure nuestra aplicacin. El grado de acoplamiento mide la
interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de la interface:
Fuerte
Por contenido, cuando desde un mdulo se puede cambiar datos locales de otro.
Comn, se emplea una zona comn de datos a la que tienen acceso varios mdulos.
Moderado
De control, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio
en el formato de datos los afecta a todos.
Por etiqueta, en intercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector,
pila, rbol, grafo,).
Dbil
De datos, viene dado por los datos que intercambian los mdulos.
Es el mejor sin acoplamiento directo, es el acoplamiento que no existe.
c) COHESIN
Un mdulo coherente ejecuta una tarea sencilla en un procedimiento de sw y requiere poca interaccin con procedimientos
que se ejecutan en otras partes de un programa. Podemos decir que un mdulo coherente es aquel que intenta realizar
solamente una cosa.
Para que n de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y
relacionados en un mismo mdulo.
ALTA
Cohesin abstraccional, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de
objetos.
Cohesin funcional, el mdulo realiza una funcin concreta y especfica.

MEDIA
Cohesin secuencial, los elementos del mdulo trabajan de forma secuencial.
Cohesin de comunicacin, elementos que operan con el mismo conjunto de datos de entrada o de salida.
Cohesin temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos.
BAJA
Cohesin lgica, se agrupan elementos que realizan funciones similares.
Cohesin coincidental, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna.
La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin:

Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA.

Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal o secuencial.
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica.
Si aparece inicializar, preparar, configurar, probablemente sea temporal.

d) COMPRENSIBILIDAD
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de
forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable:
Identificacin, el nombre debe ser adecuado y descriptivo.
Documentacin, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el
propio cdigo.
SIMPLICIDAD, las soluciones sencillas son siempre las mejores.
e) ADAPTABILIDAD
La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir, con alto acoplamiento y
baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad:
Previsin, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner
estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos
posibles.
Accesibilidad, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para
obtener un conocimiento suficiente del sistema antes de proceder a su adaptacin.
Consistencia, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los
documentos afectados.

PATRONES DE DISEO
Los patrones de diseo son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros
mbitos referentes al diseo de interaccin o interfaces.
Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe
poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en
ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en
distintas circunstancias.
OBJETIVOS DE LOS PATRONES
Los patrones de diseo pretenden:

Proporcionar catlogos de elementos reusables en el diseo de sistemas software.

Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

Formalizar un vocabulario comn entre diseadores.

Estandarizar el modo en que se realiza el diseo.

Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.

Asimismo, no pretenden:

Imponer ciertas alternativas de diseo frente a otras.

Eliminar la creatividad inherente al proceso de diseo.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el
patrn, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones
puede ser un error".
CATEGORAS DE PATRONES
Segn la escala o nivel de abstraccin:

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de
software.

Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las
que construir sistemas de software.

Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto.

Adems, tambin es importante resear el concepto de "antipatrn de diseo", que con forma semejante a la de un patrn,
intenta prevenir contra errores comunes de diseo en el software. La idea de los antipatrones es dar a conocer los problemas

que acarrean ciertos diseos muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo
callejn sin salida por haber cometido los mismos errores.

ARQUITECTURA DE DOMINIO ESPECFICO

Los modelos arquitectnicos de dominio especfico son abstracciones sobre un dominio de aplicacin.
Estos pueden ser modelos genricos que se constituyen de forma ascendente a partir de sistemas existentes o modelos de
referencia, los cuales son modelos abstractos idealizados del dominio.
MODELO GENERICO
Son atracciones de varios sistemas reales. Encapsulan caractersticas principales de estos sistemas. Por ejemplo, en sistemas
de tiempo real, existen modelos arquitectnicos genricos de diversos tipos de sistemas, como los sistemas de recoleccin
de datos, los sistemas de supervisin etc.
Un ejemplo de este modelo sera un compilador el cual debe incluir los siguientes mdulos:
1. Un analizador lxico.
2. Una tabla de smbolos.
3. Un analizador sintctico.
4. Un rbol sintctico.
5. Un analizador semntico.
6. Un generador de cdigo.
Este modelo an se utiliza ampliamente es efectivo en entornos de lotes donde los programas se compilan y ejecutan sin la
interaccin del usuario. sin embargo es menos efectivo cuando el compilador se integra con otras herramientas de
procesamiento de lenguajes, como un sistema estructurado de edicin, depurador interactivo, un programa de impreciso
etc., despus, los componentes genricos del sistema se pueden organizar en un modelo basado en depsito, como se
muestra a continuacin:

ARQUITECTURA DE REFERENCIA
Los modelos arquitectnicos genricos reflejan la arquitectura de sistemas existentes. En contraste los modelos de
referencia por lo regular se derivan de un estudio de dominio de aplicacin. Representa la arquitectura ideal que incluyen
todas las caractersticas que un sistema podra tener.
La arquitectura de referencia se utiliza como una base para la implementacin de los sistemas. Esta fue la intencin original
del modelo de referencia OSI para la interconexin de sistemas abierto.
La funcin principal es:
1.
2.
3.

Es servir como medio de comparacin de diversos sistemas en un dominio.

Un modelo de referencia provee un vocabulario para la comparacin.
Actan como un estndar, contra el cual se debe evaluar los sistemas.

DISEO SOFTWARE ARQUITECTURA

MULTIPROCESADOR

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razn es
porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten
de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin consiste en quitar
a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada. El multiproceso no es
algo difcil de entender: ms procesadores significa ms potencia computacional.
Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de proceso ejecutndolas en paralelo.
Esa es la teora, pero otra historia es la prctica, como hacer funcionar el multiproceso, lo que requiere unos profundos
conocimientos tanto del hardware como del software.
Es necesario conocer ampliamente como estn interconectados dichos procesadores, y la forma en que el cdigo que se
ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al mximo sus prestaciones.

DISEO SOFTWARE ARQUITECTURA CLIENTE SERVIDOR

Esta arquitectura consiste bsicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta.
Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es ms ventajosa en un sistema
operativo multiusuario distribuido a travs de una red de computadoras.
En esta arquitectura la capacidad de proceso est repartida entre los clientes y los servidores, aunque son ms importantes
las ventajas de tipo organizativo debidas a la centralizacin de la gestin de la informacin y la separacin de
responsabilidades, lo que facilita y clarifica el diseo del sistema.

Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el procesamiento se distribuye a lo largo
de varios procesadores. Es una forma de dividir las responsabilidades de un sistema de informacin separando la interfaz del
usuario de la gestin de la informacin. El funcionamiento bsico de este modelo consiste en que un programa cliente
realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta. Caractersticas de un cliente En la
arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus caractersticas son: Es quien inicia solicitudes
o peticiones, tienen por tanto un papel activo en la comunicacin (dispositivo maestro o amo). Espera y recibe las
respuestas del servidor. Por lo general, puede conectase a varios servidores a la vez. Normalmente interacta
directamente con los usuarios finales mediante una interfaz grfica de usuario.
Caractersticas de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor.
Sus caractersticas son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un papel
pasivo en la comunicacin (dispositivo esclavo). Tras la recepcin de una solicitud, la procesan y luego envan la respuesta
al cliente. Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos casos el nmero mximo de
peticiones puede estar limitado). No es frecuente que interacten directamente con los usuarios finales.
Ventajas Centralizacin del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de
forma que un programa cliente defectuoso o no autorizado no pueda daar el sistema. Escalabilidad: Se puede aumentar la
capacidad de clientes y servidores por separado. Fcil mantenimiento
Desventajas La congestin del trfico (a mayor nmero de clientes, ms problemas para el servidor). El software y el
hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no
poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware especfico, sobre todo en el lado del
servidor, para satisfacer el trabajo. Por supuesto, esto aumentar el costo.

DISEO DE SOFTWARE DE ARQUITECTURA

DISTRIBUIDA

Un sistema distribuido se define como una coleccin de computadores autnomos conectados por una red, y con el software
distribuido adecuado para que el sistema sea visto por los usuarios como una nica entidad capaz de proporcionar
facilidades de computacin.
Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo
conectadas por una red de rea local, hasta Internet, una coleccin de redes de rea local y de rea extensa interconectados,
que en lazan millones de ordenadores.
Las aplicaciones de los sistemas distribuidos varan desde la provisin de capacidad de cmputo a grupos de usuarios, hasta
sistemas bancarios, comunicaciones multimedia y abarcan prcticamente todas las aplicaciones comerciales y tcnicas de
los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias
externas y privacidad de la informacin que el sistema mantiene.
Un sistema distribuido es un sistema de informacin en el cual las funciones se reparten por reas de trabajo diferentes que
trabajan de forma coordinada para asumir los objetivos que la organizacin asigna a ese sistema de informacin.
ELEMENTOS DE UN SISTEMA DISTRIBUIDO
En l se integran.
La plataforma de proceso. Una vez diseado el sistema, es el elemento encargado de proporcionar los recursos fsicos y el
software de base para ejecutarlo. Est formado por los Mainframe, PCs, PDAs, telfonos, etc Los elementos de la
conectividad. Son los encargados se proporcionar el transporte para comunicar e integrar los elementos de la plataforma de
proceso. Son bsicamente las redes y las comunicaciones. El almacenamiento de datos, formado por los datos en s y los
gestores donde se localizan. Los elementos de software donde se incluyen las aplicaciones, los servicios que ayudan a
crearlas y las interfaces que ayudan a usarlas.
En este componente se integran las arquitecturas posibles para crearlas: centralizada, Batch, transaccional, cliente /
servidor basado en sistema operativo, cliente / servidor basada en Internet y aplicaciones Web Internet. A lo largo de la
exposicin pondremos especial cuidado en presentar las caractersticas y posibilidades las tres ltimas. Sistemas de
seguridad. Finalmente, debe realizarse la gestin del sistema como un conjunto integrado y coordinado a travs de los
recursos de direccin y administracin. La gestin del sistema debe permitir la coexistencia de varios centros de gestin
diferentes. Parte fundamental del sistema de gestin es el cuadro de mandos. Hay dos cuadros de mandos diferentes: El
cuadro de mandos de seguimiento de los objetivos de negocio pensado para proporcionar informacin automtica a los
gestores de como la realidad se mueve respecto a las previsiones de los objetivos de negocio en tiempo real. El cuadro
de mandos de explotacin desde donde se centraliza y coordina toda la administracin, supervisin y explotacin del
sistema.
CARACTERSTICAS

Comparticin de Recursos
Apertura (opennesss)
Concurrencia
Escalabilidad
Tolerancia a Fallos
Transparencia

DISEO DE SOFTWARE DE ARQUITECTURA DE TIEMPO

REAL
El software de tiempo real est muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al
mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el software de tiempo real debe operar
bajo restricciones de rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la
arquitectura del hardware como por la del software, por las caractersticas del sistema operativo, por los requisitos de la
aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo.
La computadora digital se ha convertido en una maquina omnipresente en la vida diaria de todos nosotros. Las
computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ltimas
generaciones de coches y programar a nuestros aparatos.
Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La
computadora est controlando algo que interacta con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia
de la interaccin.
Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para realizar esta funcin, ejecutan una
adquisicin y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad.
Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real estn frecuentemente dedicados a una nica
aplicacin.

CONCLUSIN
La arquitectura tambin juega un papel importante en otros aspectos del desarrollo de software como el mejoramiento de la
comprensin de sistemas grandes y complejos, toma en cuenta la posible evolucin del sistema, la arquitectura del software
nos proporciona una visin global del sistema a construir.
Nos queda claro que la arquitectura de software ha emergido como una disciplina de gran importancia dentro de la
ingeniera de software. En la arquitectura de un sistema de software puede compararse con la estructura de un edificio. Si
esta estructura est mal diseada, el edificio puede derrumbarse. De igual manera, un sistema de software que carece de
diseo arquitectnico de calidad puede funcionar de forma muy deficiente o simplemente no funcionar. Peor an, podra
generar consecuencias catastrficas para la organizacin o los usuarios que sirve. Para las empresas que dependen de los
sistemas de informacin, que actualmente no son pocas, las arquitecturas de software son fundamentales para el logro de sus
objetivos organizacionales, lo que incluye el poder evolucionar rpidamente segn las condiciones altamente cambiantes de
los mercados actuales.

PREGUNTAS

Qu es la arquitectura de software?
Es un conjunto de patrones que proporcionan un marco de referencia necesario para guiar la construccin de un software
Cules son cualidades mnimas para que se pueda considerar suficiente validad en la descomposicin modular?
1.
2.
3.
4.
5.

Independencia funcional
Acoplamiento
Cohesin
Comprensibilidad
Adaptabilidad

Qu funcin tiene los patrones de diseo?

Son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al
diseo de interaccin o interfaces.
Menciona los cuatro diseos de software de arquitectura
1.
2.
3.
4.

Diseo de software de arquitectura multiprocesador

Diseo de software de arquitectura Cliente Servidor
Diseo de software de arquitectura distribuida
Diseo de software de arquitectura de tiempo real

En qu consiste la arquitectura Cliente Servidor?

Consiste bsicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta.