7.

Arquitectura del
software
Experto web y multimedia para e-commerce II
Índice
de la unidad

Análisis.
Transformación de requerimientos en
especificaciones funcionales. Especificaciones
técnicas. Proceso de transformación.
Arquitectura empresarial.
Herramientas TOGAF certificadas.
Arquitecturas centralizadas, 2-tier, 3-tier y basadas
en web.
Arquitectura orientada a web (WOA, Web Oriented
Architecture).
Protocolo SOAP.
Middleware.
Diseño físico de una arquitectura.
Análisis
Arquitectura del software
La arquitectura de software es el diseño de más
alto nivel de la estructura de un sistema.
Consiste en un conjunto de patrones y abstracciones
coherentes que proporcionan un marco definido y claro
para interactuar con el código fuente del software.
Se selecciona y diseña con base en objetivos (requisitos) y restricciones.
Los objetivos son aquellos prefijados para el sistema de información, pero no solamente
los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de información.
Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para
implementar sistemas de información. Unas arquitecturas son más recomendables de
implementar con ciertas tecnologías, mientras que otras tecnologías no son aptas para
determinadas arquitecturas.
La arquitectura de software define, de manera
abstracta, los componentes que llevan a cabo
alguna tarea de computación, sus interfaces y
la comunicación entre ellos. Toda arquitectura
debe ser implementable en una arquitectura física,
que consiste simplemente en determinar
qué computadora tendrá asignada cada tarea.
Análisis
El análisis es el proceso de comprender el entorno en el que operarán un sistema o
sistemas propuestos y determinar los requisitos del mismo. Las entradas de requisitos
para el análisis pueden provenir de cualquier parte interesada e incluir elementos tales como:

◉ Qué hará el sistema cuando esté operativo (requisitos funcionales).

◉ Cómo de bien cumplirá el sistema con los requisitos no
funcionales en tiempo de ejecución, como fiabilidad,
operabilidad, eficiencia de rendimiento, seguridad, etc.
Transformación de
requerimientos en
especificaciones funcionales.
Especificaciones técnicas.
Proceso de transformación.
Transformación de requerimientos
en especificaciones funcionales
Es necesario recabar información para que los requerimientos
describan las necesidades del cliente. Las necesidades y
los requerimientos de los clientes cambian con el tiempo, por
ello, es necesario revisar y modificar cuando sea necesario las
copias que hemos guardado con la documentación original del
cliente.
Para identificar con éxito las necesidades de los clientes, se
deben realizar las actividades que explicamos a continuación.
Obtener información del cliente
Para recabar y analizar información adecuadamente sobre las
necesidades del cliente, se recomienda implementar una serie de
técnicas:

◉ Técnicas generales para la

identificación de requerimientos
Mediante estas técnicas podemos investigar información
sobre los clientes de manera general, para después
especificar algunos aspectos y concretar resultados. Es
recomendable mantener conversaciones y un diálogo
fluido entre las empresas de desarrollo de software y los
clientes, de esta manera podremos conseguiremos optimizar
al máximo estas técnicas. Por ejemplo: brainstorming,
cuestionarios, entrevistas, grupos de discusión…
◉ Técnicas específicas para la
identificación de requerimientos
Estas complementan a las anteriores, las técnicas generales.
A través de las técnicas específicas podremos concretar y
centrarnos en aquellas especificaciones e informaciones de
interés relevante que demanda el cliente. Podemos resaltar
las siguientes:
Observación: es necesario revisar que no se está omitiendo
información importante o se está interpretando la información de
forma equivocada. El cliente debe autorizar esta técnica, mediante
la que se obtiene información directa sobre la realización de las
actividades.
Escenarios: si hacemos una valoración del comportamiento de
un producto ante diferentes situaciones, por ejemplo, analizando
casos de uso, podremos extraer información realmente útil,
incluyendo excepciones que pueden acontecer.
Especificaciones técnicas: captura de requisitos
Es la fase en la que se capturan los requisitos que tiene que cumplir el sistema.
Para ello, existe un conjunto de técnicas y procedimientos que nos permiten conocer los elementos
necesarios para definir un proyecto de software.

Las técnicas para capturar requisitos son:

Evaluar la viabilidad (técnica) del sistema.
Definir los orígenes de requisitos, identificar los
diferentes stakeholders, no necesariamente todos ellos
serán personas (un sistema anterior puede ser un origen
de requisitos, una ley, un documento, etc.).
Definir el alcance (scope) del sistema. Identificar qué hará y
qué no hará el sistema, qué quedará dentro y qué fuera, así como las
comunicaciones con otros sistemas o entidades.
Definir las técnicas de educción a utilizar. Dependiendo del
sistema, los conocimientos de los stakeholders y diversos factores
adicionales se emplearán unas técnicas de educción u otras (prototipos,
entrevistas, casos de uso, storyboards, etc.).
Aplicar las técnicas seleccionadas a los diversos perfiles
participantes, stakeholders, etc. para extraer requisitos.
Requisitos funcionales
Condición o capacidad de un sistema, requerida por el
usuario, para resolver un problema o alcanzar un objetivo.
Para realizar bien el desarrollo de software es esencial realizar una
especificación completa de los requerimientos de los mismos.
Independientemente de lo bien diseñado o codificado que esté, un programa
pobremente especificado decepcionará al usuario y hará fracasar el
desarrollo.
Tanto el que desarrolla el software como el cliente tienen
un papel activo en la especificación de requerimientos. El
cliente intenta reformular su concepto, algo nebuloso, de la
función y comportamiento de los programas en detalles
concretos. El que desarrolla el software actúa como
interrogador, consultor y el que resuelve los problemas.
Proceso de transformación
El proceso para definir adecuadamente los requerimientos,
transformándolos en la satisfacción de necesidades del
cliente a través del software será:
1. Definir los requerimientos basándonos en la información
obtenida sobre los usuarios.

2. Revisar requerimientos de proyectos ya terminados para

identificar contenido que pueda ser reutilizable. Una vez que
se ha probado el éxito de un requerimiento respecto a un
producto, podrá ser reutilizado (siempre teniendo en cuenta los
derechos de autor).

3. Documentar los requerimientos de manera clara y

concisa. De esta forma, aseguraremos que los requisitos del
cliente han sido captados correctamente.
Para definir el alcance del
sistema es aconsejable:
◉ Elaborar un documento formal, concretando y
especificando los procesos necesarios para entregar un
producto con las características que el cliente solicita.
◉ Determinar los criterios que indican que la fase o el
proyecto ha finalizado correctamente, los llamados criterios
de aceptación.
◉ Tener conciencia de que aquello que no está en el
alcance, no está dentro del proyecto.
Arquitectura empresarial
Para capturar la visión completa del sistema empresarial en todas sus dimensiones y
complejidad surge el concepto de arquitectura empresarial. Identifica los componentes
principales de la organización y su relación para conseguir los objetivos de negocio. Actúa como
fuerza integradora entre aspectos de planificación del negocio, aspectos de operación de
negocio y aspectos tecnológicos.
La implantación de una arquitectura empresarial parte del establecimiento de un conjunto
de directrices arquitectónicas que permitan asegurar un desarrollo armónico entre los
modelos y necesidades de la empresa, con los procesos de negocio y las tecnologías de
información.
Uno de los framework de arquitectura empresarial más difundidos es TOGAF.
Herramientas
TOGAF certificadas
El Open Group Architecture Framework (TOGAF) es una arquitectura empresarial que ofrece
un marco de alto nivel para el desarrollo de software empresarial. Ayuda a organizar el
proceso de desarrollo a través de un enfoque sistemático para reducir los errores,
mantener los plazos, mantenerse dentro del presupuesto y alinear la TI con las
unidades de negocios para producir resultados de calidad.
Al igual que otros marcos de administración de TI, TOGAF ayuda a las empresas a alinear la
TI con los objetivos comerciales, a la vez que ayuda a organizar los esfuerzos de TI entre
departamentos. Ayuda a las empresas a definir y organizar los requisitos antes de que
comience un proyecto, lo que permite que el proceso avance rápidamente con pocos errores.
TOGAF está destinado a:

Asegurar que todos hablen el mismo idioma.

Evitar el bloqueo de soluciones patentadas mediante la estandarización

de métodos abiertos para la arquitectura empresarial.
Ahorrar tiempo y dinero.

Conseguir un ROI demostrable.

Beneficios comerciales.
Arquitecturas centralizadas,
2-tier, 3-tier y basadas en
web.
Arquitecturas centralizadas
En las arquitecturas centralizadas la relación entre los
componentes sigue un patrón muy característico en el
que hay una jerarquía definida de manera tal que
ciertos componentes requieren información o servicios
que otros ofrecen.
El modelo centralizado es el que ha sido ampliamente
utilizado en los sistemas de información de las grandes
organizaciones en décadas anteriores, mediante un
host que ejecutaba el 100% de la lógica del sistema,
residiendo únicamente en el terminal de usuario las
funciones de presentación. A este tipo de aplicaciones
que concentran todas las lógicas funcionales del
software (presentación, negocio y acceso a datos) en
un mismo componente se les denomina aplicaciones
monolíticas.
 N procesos
Arquitectura por niveles: 2 tier
Donde el software reparte su carga de cómputo
en dos partes independientes, pero sin reparto
claro de funciones:

01 Proveedores de los recursos

o servicios (servidores).
N máquinas N usuarios
02 Demandantes (clientes).
Sus ventajas son la escalabilidad, fácil
mantenimiento, la centralización del
control y tecnologías maduras y robustas.
Arquitectura por niveles: 3 tier
El principal objetivo de esta arquitectura es la separación por niveles de la
lógica de negocio de la de diseño.

Principales ventajas:

Simplifica la comprensión y la organización del desarrollo de sistemas complejos.

Reduce las dependencias, ya que los niveles más bajos no necesitan apoyo de las superiores.

La división de niveles da a la aplicación una mayor flexibilidad.

 Nivel de Nivel de negocio
Donde residen las
presentación funciones que se
Presenta el sistema al ejecutan.
usuario. Se reciben las peticiones
Nivel de datos
Captura y comunica la Donde residen y se
del usuario.
Información al usuario. gestionan los datos.
Se procesa la
GUI (Interfaz Gráfica del Información.
usuario). Se envía las respuestas
tras el proceso.
Arquitecturas distribuidas
Un sistema distribuido es un sistema en el que el procesamiento de información se
distribuye sobre varias computadoras en vez de estar confinado en una única máquina.
En general, el desarrollo de sistemas distribuidos intenta poner solución a los siguientes
objetivos:

Transparencia.
Fiabilidad.
Rendimiento.
Capacidad de crecimiento.
Flexibilidad.
Seguridad.
Basadas en web
Service Oriented Architecture (SOA)
Organizaciones que quieren hacer su información accesible a otros
programas pueden hacerlo definiendo y publicando una interface
de servicio web.
Un servicio web es una representación estándar para algún
recurso computacional o de información que puede ser usado
por otros sistemas.
El servicio es independiente de las aplicaciones que lo usan.
Se pueden construir aplicaciones mediante el uso de distintos
servicios.
Hay varios modelos de servicios distintos. Conceptualmente todos
operan de acuerdo al siguiente modelo.
Estándares más conocidos:

SOAP - Simple Object Access Protocol

WSDL - Web Services Description Language
UDDI - Universal Description, Discovery and Integration.
Arquitectura orientada a
web (WOA, Web Oriented
Architecture).
Web Oriented Architecture (WOA)
Una definición de WOA podría ser: “Un conjunto central de protocolos web como
HTTP y XML simple. La única diferencia real entre SOA tradicional y el concepto de
WOA es que WOA aboga por la transferencia de estado Representacional (REST),
un método cada vez más popular, poderoso y simple de aprovechar el Protocolo de
Transferencia de Hipertexto (HTTP) como un servicio web por derecho propio ”.
La pila de la WOA:

◉ Distribución (HTTP, Feeds)

◉ Composición (Hipermedia, Mashups)
◉ Seguridad (OpenID, SSL )
◉ Portabilidad de datos (XML, RDF)
◉ Representación de datos (ATOM, JSON)
◉ Métodos de transferencia (REST, HTTP, BitTorrent)
Protocolo SOAP.
Service Oriented Architecture: SOAP
Es un protocolo basado en XML que permite la interacción entre varios
dispositivos y que tiene la capacidad de transmitir información compleja.
Los datos pueden ser transmitidos a través de HTTP, SMTP, etc.
SOAP especifica el formato de los mensajes de la siguiente forma:
Envelope (envoltura): es el elemento raíz del mensaje para
describir su contenido y la forma de procesarlo.
Header (encabezado): es la información de identificación del
contenido. Un grupo de reglas de codificación para expresar las
instancias de tipos de datos definidos por la aplicación.
Body (cuerpo): es el contenido del mensaje. Una convención para
representar las llamadas y las respuestas a procedimientos remotos.
Middleware.
Middleware
Los componentes de la arquitectura pueden ser:
◉ Implementadas en diferentes lenguajes
◉ Ejecutarse en distintos tipos de procesadores
◉ Usar diferentes modelos de datos
◉ Representar de forma diferente la información
◉ Usar distintos protocolos de comunicación
Por ello, se necesita software para gestionar la
comunicación y el intercambio de datos entre
componentes. Dicho software se denomina middleware.
Normalmente, son usados middleware que son comprados
comercialmente, ya que son de propósito general.
Diseño físico de una
arquitectura.
El diseño físico de sistemas es la forma de implementar las tareas
del sistema. Incluye la manera de conjuntar sus componentes y las
funciones que realizará cada uno de estos.
El componente es la unidad de construcción elemental del diseño físico.
En el diseño físico se especifican las características de los componentes del sistema
requeridos para poner en práctica el diseño lógico. En esta fase deben delinearse las
características de cada uno de los componentes que se enumeran a continuación.
Durante el diseño físico hay que delinear las
características de cada uno de los componentes que
se enumeran a continuación:

01 Diseño de hardware.
02 Diseño de software.
03 Diseño de bases de datos.
04 Diseño de telecomunicaciones.
05 Diseño de personal.
06 Diseño de procedimientos y controles.
¡Lo conseguiste!
Has llegado al final de la unidad