Arquitectura Del Sistema

Una arquitectura de sistema es una representación de un sistema en la que hay una correlación de funciones
con componentes de hardware y software, una correlación de la arquitectura de software con la arquitectura
de hardware, e interacción humana con estos componentes.

Existen varios lenguajes formales que permiten describir la arquitectura de un sistema en general. Son los
llamados Lenguajes de Descripción de Arquitectura.

Entre los más importantes están: Acme (de CMU), AADL (estandarizado por SAE), C2 (desarrollado por UCI),
SBC-ADL (desarrollado por la National Sun Yat-Sen University), Darwin (desarrollado por Imperial College
London) y Wright (desarrollado por CMU).

Hay lenguajes más avanzados, para el modelado dentro de la comunidad de ingenieros, son lenguajes
especiales para un nivel corporativo. Algunos ejemplos son: ArchiMate (el actual estándar para el The Open
Group), DEMO, ABACUS (desarrollado por la University of Technology, Sydney).

"Arquitectura de sistemas: la estructura fundamental y unificadora del sistema definida en términos de

elementos del sistema, interfaces, procesos, restricciones y comportamientos". Arquitectura de sistemas: la
estructura del sistema fundamental y la unificación de los términos de comportamientos, restricciones,
procesos, interfaces y elementos del sistema.

[Definición de línea base aprobada por INCOSE Systems Architecture Working Group en INCOSE '96, en Boston
(MA), el 8 de julio de 1996]

"La arquitectura del sistema comprende las principales propiedades físicas, estilo, estructura, interacciones y
propósito de un sistema". La arquitectura del sistema comprende las principales propiedades físicas, el estilo,
la estructura, las interacciones y el objetivo del sistema.

[Proceso de arquitectura de sistemas e ingeniería de requisitos, Derek Hatley, Peter Hruschka, Imtiaz Pirbhai,
Dorset House Publishing 2000]

"Arquitectura: los conceptos y reglas que definen la estructura, el comportamiento semántico y las relaciones
entre las partes de un sistema; un plan de algo que se construirá. Incluye los elementos que comprenden la
cosa, las relaciones entre esos elementos, las restricciones que afectan esas relaciones, un enfoque en las
partes de la cosa y un enfoque en la cosa en su conjunto ". (Arquitectura: los conceptos y las reglas que
definen la estructura, el comportamiento semántico y las relaciones entre los componentes de un sistema; un
plan para construir algo. Incluye los elementos que forman ese algo, las relaciones entre dichos elementos, las
restricciones que afectan a Dichas relaciones, el foco de los componentes y el foco de todo el conjunto).

[Arquitecto con RM-ODP, Janis Putman, Prentice Hall PTR 2001, que hace referencia a ISO / IEC 10746-2:
Tecnología de la información - Proceso distribuido abierto - Modelo de referencia: Bases, igual que el origen]

"Arquitectura: la estructura de los componentes en un programa / sistema, sus interrelaciones y los principios
y directrices que rigen su diseño y evolución en el tiempo". (Arquitectura: la estructura de los componentes en
un programa / sistema, sus interrelaciones y los principios y las directrices que rigen el diseño y la evolución en
el tiempo).
[DoD 5000.59-P, "Plan maestro de simulación y modelado", octubre de 1995]

Una arquitectura es "la estructura de los componentes, sus relaciones y los principios y directrices que rigen su
diseño y evolución en el tiempo". (la estructura de los componentes, sus relaciones y los principios y las
directrices que rigen el diseño y la evolución en el tiempo).

[IEEE STD 610.12, ligeramente ampliado por el Panel de Arquitectura Integrada (IAP) del Grupo de Trabajo de
Integración de C4ISR (ITF) en DoD Architecture Framework, Versión 1.0]

Se utilizan diferentes palabras y construcciones, y no todas las definiciones cubren exactamente los mismos
aspectos, aunque hay superposiciones significativas. Estas definiciones revelan que la arquitectura de sistema
consiste en lo siguiente:

 la estructura del sistema en términos de elementos, componentes y partes

 las relaciones entre estos elementos
 las restricciones que afectan a los elementos y sus relaciones
 el comportamiento que manifiesta el sistema y las interacciones que se originan entre los elementos
para producir dicho comportamiento
 los principios, reglas y fundamentos que hacen que el sistema sea como es (y rigen su evolución)
 las características y propiedades lógicas y físicas del sistema
 el objetivo del sistema

Por lo tanto, para reflejar completamente todos estos aspectos es necesario un conjunto de información rico y
potencialmente complejo, pero hay que ser consciente de que no todos los interesados deben ver o
comprender todos los aspectos de manera simultánea. La idea de puntos de vista permite la separación de los
diferentes problemas y la presentación en una clase de interesados de únicamente lo necesario para una
participación eficaz. Desde la perspectiva de un punto de vista particular, también puede ver el sistema en
diferentes "resoluciones", desde baja resolución, que corresponde a un nivel de abstracción elevado, hasta
alta resolución, que corresponde a una especificación concreta (de partes y demás) para la implementación.

Punto de vista
Un punto de vista (en un sistema) es "una forma de abstracción lograda utilizando un conjunto seleccionado
de conceptos arquitectónicos y reglas de estructuración, para enfocarse en preocupaciones particulares
dentro de un sistema". (una forma de abstracción que se consigue mediante un conjunto seleccionado de
conceptos arquitectónicos y reglas de estructura, para centrarse en problemas particulares de un sistema).
[ISO / IEC 10746-2: Tecnología de la información - Proceso distribuido abierto - Modelo de referencia: Bases].
La tabla lista algunos de los puntos de vista para detectar varios problemas. Estos puntos de vista se alinean
con los que se encuentran en ISO / IEC 10746-1: Tecnología de la información - Proceso distribuido abierto -
Modelo de referencia: Visión general.

Punto de vista Asunto Impacto

Trabajador Se ocupa de los roles y las responsabilidades
de los trabajadores del sistema y la
organización (y las políticas que les afectan).
Información Las clases de información que maneja el
sistema y las restricciones de utilización e
interpretación de dicha información.
Actividades del trabajador, interacción
humano/sistema. Especificación del
rendimiento humano y factores
humanos.
Integridad de la información,
limitaciones de capacidad.
Accesibilidad de la información,
actualidad.
Lógico La descomposición del sistema en un conjunto
de subsistemas que interactúan en interfaces,
colaboran para proporcionar los servicios del
sistema.
Distribución/Físico La infraestructura necesaria para soportar la
distribución y la funcionalidad del sistema.
Proceso Concurrencia, escalabilidad, rendimiento,
producción, fiabilidad.
El sistema muestra el comportamiento
deseado.
El sistema es extensible, adaptable y se
puede mantener.
Los activos son reutilizables.
La adecuación de las características
físicas del sistema para alojar las
funciones y satisfacer los requisitos no
funcionales.
La adecuación de la capacidad de
respuesta, el rendimiento y la tolerancia
a errores del sistema.

Puntos de vista comunes del sistema.

Estos puntos de vista son algunos de los más comunes para sistemas de software intensivos. Muchas
arquitecturas de sistema también requieren puntos de vista adicionales específicos del dominio. Algunos
ejemplos son los puntos de vista mecánicos y de seguridad. Los puntos de vista representan diferentes áreas
de preocupación que deben tratarse en el diseño y la arquitectura del sistema. Si hay expertos o interesados
en el sistema que tienen preocupaciones importantes para la arquitectura general, puede que sea necesario
un conjunto de productos de trabajo de puntos de vista para capturar las decisiones de diseño.
Es importante crear un equipo de arquitectura del sistema con personal competente para buscar los
diferentes puntos de vista. El equipo puede estar formado por analistas empresariales y usuarios que asumen
la responsabilidad principal del punto de vista del trabajador, los arquitectos de software que adoptan el
punto de vista lógico y los ingenieros que se encargan del punto de vista físico, así como los expertos en
puntos de vista específicos del dominio.

Niveles de abstracción
Además de los puntos de vista, una arquitectura del sistema requiere niveles de especificación. A medida que
se desarrolla la arquitectura, evoluciona desde una especificación abstracta y general a una especificación más
detallada y específica. RUP identifica cuatro niveles de arquitectura, como se muestra en la siguiente tabla.

Nivel de modelo Expresa

Contexto El sistema y sus actores.
Análisis Partición inicial del sistema para establecer la propuesta conceptual.
Diseño Realización del modelo de análisis de hardware, software y personas.
Implementación Realización del modelo de diseño en configuraciones específicas.

Niveles de arquitectura de RUP

En estos niveles, el diseño pasa de lo abstracto a lo físico. El modelo de contexto captura todas las entidades
(actores) externos que interactúan con el sistema. Estos actores pueden ser externos a la empresa que
despliega el sistema o internos. En ambos casos, los actores pueden ser trabajadores humanos u otros
sistemas. En el nivel de análisis, las particiones no reflejan las elecciones de hardware, software y personas. En
su lugar, reflejan las propuestas de diseño para dividir lo que debe hacer el sistema y cómo se debe distribuir
el esfuerzo. En el nivel de diseño, las decisiones se toman en función de las clasificaciones de componentes de
hardware y software y los roles de trabajador necesarios. En el nivel de implementación, se hacen elecciones
específicas de tecnología de software y hardware para implementar el diseño. Por ejemplo, en el nivel de
diseño, se puede especificar un servidor de datos. En el nivel de implementación, se toma la decisión de
utilizar una plataforma específica que ejecute una aplicación de bases de datos específica.
Modelos y diagramas
Un modelo es una representación de un sistema, que normalmente trata un área de preocupación en
particular. Un sistema, por lo tanto, suele representarse mediante un conjunto de modelos, ya que el
desarrollo o la utilización del sistema tienen varios asuntos que tratar. Cada modelo se puede construir con
varios niveles de abstracción, desde el más general, que oculta o encapsula detalles, al más específico, que
presenta decisiones de diseño más explícitas y detalladas.

Un punto de vista, tal como implica su nombre, es una "posición" nocional desde la que se pueden ver algunos
aspectos o asuntos del sistema, lo que supone la aplicación de un conjunto de conceptos y reglas para formar
un filtro conceptual. Normalmente, no es suficiente (para obtener conocimiento) limitarse a examinar el
sistema real; los modelos se han construido (o deberían haberse construido) para representar y describir las
preocupaciones.

Las vistas son proyecciones de modelos que muestran entidades importantes desde un punto de vista
particular. Estas proyecciones suelen ilustrarse mediante diagramas de algún tipo.
La intersección del nivel de abstracción o especificación del modelo y el punto de vista contiene (o, por lo
menos, identifica) vistas de uno o varios modelos relevantes para ese punto de vista o asunto, en ese nivel de
abstracción.

Entonces, la arquitectura del sistema se captura en un conjunto de modelos (y diagramas que los visualizan)
que expresan la arquitectura desde varios puntos de vista y niveles. Como se muestra en la tabla de
infraestructura del modelo que aparece abajo, no hay un modelo/diagrama para cada combinación de nivel y
punto de vista. En el nivel de implementación, un solo modelo captura la realización de componentes de
hardware y software para cada configuración del sistema.

Nivel de modelo Puntos de vista

Trabajador Lógico Información Distribución/Físico Proceso
Contexto Vista Organización Diagrama de Vista Datos Vista Localidad Vista
UML contexto del empresariales empresarial Proceso
sistema empresarial
Análisis Vista Trabajador Vista Vista Datos del Vista Localidad del Vista
del sistema Subsistema sistema sistema Proceso del
generalizado sistema
Diseño Vista Trabajador Vistas Clase de Esquema de Vista Nodo de Vista
del sistema subsistema datos del descriptor Proceso
Vistas sistema detallado
Componente
de software
Implementación Instrucciones y Configuraciones: diagramas de despliegue con componentes del
especificaciones sistema de hardware y software.
del rol de
trabajador

Muchas de las vistas especificadas en la tabla se derivan de modelos UML estándar. Por ejemplo, en el nivel de
análisis del punto de vista lógico, el sistema se descompone en subsistemas que colaboran para satisfacer los
requisitos del usuario. Los subsistemas se utilizan con la misma semántica que el estándar UML. Estos
subsistemas, a su vez, se descomponen en subsistemas o (en última instancia) clases. El nivel de diseño del
punto de vista lógico es la vista del modelo de clase detallado. El modelo de proceso también es un modelo de
clase UML estándar, que se centra en clases activas del sistema. Los puntos de vista específicos del dominio
también necesitan tener vistas de productos de trabajo para uno o varios niveles. El conjunto de productos de
trabajo del proyecto, en esta infraestructura, debe formar parte del guión de desarrollo del proyecto.

Modelo 4-1 más vistas

4+1 es un modelo diseñado por Philippe Kruchten para "describir la arquitectura de sistemas software,
basados en el uso de múltiples vistas concurrentes".1 Las vistas suelen describir el sistema desde el punto de
vista de diferentes interesados, tales como usuarios finales, desarrolladores o directores de proyecto. Las
cuatro vistas del modelo son: vista lógica, vista de desarrollo, vista de proceso y vista física. Además, una
selección de casos de uso o escenarios suele utilizarse para ilustrar la arquitectura sirviendo como una vista
más. Por ello el modelo contiene 4+1 vistas:

Las cuatro vistas del modelo son:

1. Vista lógica.
2. Vista de desarrollo.
3. Vista de proceso.
4. Vista física.
5. Escenario, una selección de casos de uso o que se utilizará para ilustrar la arquitectura sirviendo como
una vista más.

1. Vista lógica
Está enfocada en describir la estructura y funcionalidad del sistema, y para éste sistema se utilizó un diagrama
de Clases para representar esta Vista. El cual está separado en 2 package:

1. Package AppAnalizarTesis:
 Clases 1: Index
 Clase 2: ProcesarTesisPdf
1. Package WS-AnalizarPDF (Servicio Web):
 Clase 1: AnalizarPdf
 Clase 2: Parser
2. Vista de desarrollo
Ilustra el sistema de la perspectiva del programador y está enfocado en la administración de los artefactos de
software. El Diagrama Componentes UML se utiliza para describir los componentes del sistema. El cual
contiene dos componentes

1. Componente 1: App Analizar Tesis

2. Componente 2: Servicio Web Analizar PDF

Ambos conectados mediante el protocolo HTTP.

3. Vista de proceso
Explica los procesos de sistema y cómo se comunican. se enfoca en el comportamiento del sistema en tiempo
de ejecución

Esta vista se representará con un diagrama de Actividad.

En él se detallan tres actores:

1. Usuario
2. App
3. Servidor Web
4.

4. Vista física
Describe el sistema desde el punto de vista de un ingeniero de sistemas. Está relacionada con la topología de
componentes de software en la capa física (hardware), así como las conexiones físicas entre estos
componentes.

En el se muestra dos nodos, como capa física y dentro de ellos sus artefactos o componentes de software:

Nodo 1: Workstation
 Componente Web Browser.

Nodo 2: Web Server App

 Componente App Analizar Tesis.

Nodo 3: Web Server Web Service

 Componente Servicio web Analizar PDF
 Componente Parser (Librería PHP que permite leer un archivo PDF)

5. Escenarios
Los escenarios describen secuencias de interacciones entre objetos, y entre procesos. Se utilizan para
identificar y validar el diseño de arquitectura. También sirven como punto de partida para pruebas de un
prototipo de arquitectura. La descripción de la arquitectura se ilustra utilizando un conjunto de casos de uso.
En él, se modelan tres casos de uso y un actor del sistema.
Sistema:
 Repositorio para Trabajos de Tesis

Actor:
 Profesor Guía

Casos de uso:
 Mostrar formulario upload tesis.
 Subir Archivo PDF.
 Mostrar resultado análisis tesis pdf.
Diseñando la arquitectura del sistema
Diseño del Sistema
El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste
incluye decisiones acerca de la organizacióndel sistema en subsistemas, la asignación de subsistemas a
componentes hardware y software, y decisiones fundamentales conceptuales y de políticaque son las que
constituyen un marco de trabajo para el diseño detallado.

La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número
de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones.
Una forma de caracterizar una aplicación es por la importancia relativa de sus modelos de objetos, dinámico y
funcional. Las distintas arquitecturas ponen distintos grados de énfasis en los tres modelos.

El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver
el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del
sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura
proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. AL
tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en
subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que
trabajarán independientemente en distintos subsistemas. El diseñador de sistemas debe tomar las siguientes
decisiones:

- Organizar el sistema en subsistemas

- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades

Definición de subsistema
En todas las aplicaciones, salvo en las más pequeñas, el primer paso para diseñar un sistema consiste en
dividir el sistema en un pequeño número de componentes. Cada uno de los componentes principales de un
sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que comparten
alguna propiedad común.

Un subsistema no es ni una función ni un objeto, sino un paquete de clases, asociaciones, operaciones,

sucesos y restricciones interrelacionados, y que tienen una interfaz razonablemente bien definida y pequeña
con los demás subsistemas. Normalmente, un subsistema se identifica por los servicios que proporciona.
Un servicio es un grupo de funciones relacionadas que comparten algún propósito común, tal como el
procesamiento de entrada-salida, dibujar imágenes o efectuar cálculos aritméticos. Un subsistema define una
forma coherente de examinar un aspecto del problema.

Cada subsistema posee una interfaz bien definida con el resto del sistema. Ésta especifica la forma de todas las
interacciones y el flujo de informaciónentre los límites de subsistemas, pero no especifica cómo está
implementado internamente el subsistema. Cada subsistema se puede diseñar, entonces,
independientemente, sin afectar a los demás.

Los subsistemas deberían definirse de tal manera que la mayoría de las interacciones se produzcan dentro de
y no entre los límites de distintos subsistemas, con objeto de reducir las dependencias existentes entre ellos.
Todo sistema debería dividirse en un pequeño número de subsistemas. Cada subsistema, a su vez, debe
descomponerse en subsistemas propios aún más pequeños. Los subsistemas de más bajo nivel se denominan
módulos.

La relación entre dos subsistemas puede ser cliente-proveedor o punto a punto. En las primeras, el cliente
debe conocer la interfaz del proveedor, pero éste no necesita conocer las interfaces de aquellos porque todas
las interacciones son iniciadas por los clientes, empleando la interfaz del proveedor. En una relación entre
pares, cada subsistema puede llamar a los demás. Una comunicación desde un subsistema hacia otro no va
necesariamente seguida por una respuesta inmediata. Las interacciones entre pares son más complejas
porque los subsistemas deben conocer las interfaces del otro. Hay ciclos de comunicaciones que son difíciles
de entender y proclives a sutiles errores de diseño. Hay que buscar descomposiciones cliente-proveedor
siempre que sea posible, porque una interacción monodireccional es mucho más fácil de construir,
comprender y modificar que una interacción bidireccional.

Identificación de la concurrencia
EN el modelo de análisis, al igual que en el mundo real y en el hardware, todos los objetos son concurrentes.
En una implementación, sin embargo, no todos los objetos del software son concurrentes, porque
un procesador puede dar soporte a muchos objetos. En la práctica, se pueden implementar muchos objetos
en un único procesador si los objetos no pueden estar activados a la vez. Un objetivo importante del diseño
del sistema es identificar los objetos que deben estar activados concurrentemente, y los objetos que tienen
actividad que sea mutuamente exclusiva. Estos últimos objetos se pueden plegar y juntar en un único hilo de
control o tarea.

Asignación
Cada subsistema concurrente debe ser asociado a una unidad de hardware, bien a un procesador de propósito
general o a una unidad funcional especializada. El diseñador del sistema deberá:
- Estimar las necesidades de rendimiento y los recursos necesarios para satisfacerlas
- Seleccionar las implementaciones de hardware o de software para los subsistemas
- Asignar los subsistemas de software a los procesadores para satisfacer las necesidades de rendimiento y para
minimizar la comunicación entre procesadores
- Determinar las conexiones de las unidades físicas que implementan los subsistemas.

Almacenamiento de datos
Los almacenes de datos internos y externos dentro de un sistema proporcionan puntos limpios de separación
entre subsistemas con interfaces bien definidas. En general, todo almacén de datos puede
combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos
de almacenamiento secundario. Los distintos tipos de almacenes de datos proporcionan diversas
compensaciones entre costo, tiempo de acceso, capacidad y fiabilidad.

Los archivos son una forma de almacenamiento de datos barata, sencilla y permanente. Sin embargo, las
operaciones de archivos son de bajo nivel y las aplicaciones deben incluir un código adicional para
proporcionar un nivel de abstracción adecuado. Las implementaciones de los archivos son distintas según los
diferentes sistemas de computadoras, así que las aplicaciones transportables deben de aislar cuidadosamente
las dependencias con sistemas de archivos. Las implementaciones para archivos secuenciales son las más
comunes, pero las ordenes y los formatos de almacenamiento para ficheros de acceso aleatorio e indexados
varían mucho.

Las bases de datos, que son administradas mediante sistemas de gestión de bases de datos, son otro tipo de
almacenamiento. Existen varios tipos de sistemas de gestión disponibles comercialmente: jerárquicos, en red,
relacionales, orientados a objetos y lógicos. Estos sistemas intentan reservar los datos de acceso frecuente en
memoria, con objeto de alcanzar la mejor combinación posible de costo y rendimiento desde y hacia la
memoria y el almacenamiento en disco. Las bases de datos son potentes y hacen que las aplicaciones sean
más fáciles de transportar a sistemas operativos y a distintas plataformas, por cuanto el vendedor transporta
el código del sistema de gestión. Una desventaja es que tienen una interfaz compleja.

Las siguientes líneas generales caracterizan el tipo de datos que pertenece a una base de datos formal:

- Datos que requieran un acceso a niveles finos de detalle por parte de múltiples usuarios
- Datos que puedan ser administrados eficientemente mediante ordenes de un sistema gestor de base de
datos
- Datos que deban transportarse a través de múltiples sistemas operativos y muchas plataformas hardware
- Datos a los que deba acceder más de un programa de aplicación
Las siguientes líneas caracterizan las clases de datos que pertenecen a un archivo y no a una base de datos
relacional:
- Datos que sean voluminosos respecto a cantidad pero difíciles de estructurar en los confines de un sistema
de datos.
- Datos que sean voluminosos en cantidad y con una baja densidad de formación
- Datos crudos que estén resumidos en la base de datos
- Datos volátiles que se mantengan durante un corto periodo de tiempo y se descarten después.

Administración de los recursos

El diseñador de sistemas debe identificar los recursos globales y tiene que determinar mecanismos para
controlar el acceso a ellos. Entre los recursos globales se cuentan: unidades físicas, tales como procesadores,
unidades de cinta y satélites de comunicación; espacio, tal como el espacio en disco, una pantalla de una
estación de trabajo, y los botones de un ratón; nombres lógicos, tales como la identificación de los objetos,
nombres de archivos y nombres de clases; y el acceso a datos compartidos, tales como bases de datos.

Si el recurso es un objeto físico se puede controlar a sí mismo estableciendo un protocolo para obtener el
acceso dentro de un sistema concurrente. SI el recurso es una entidad lógica, tal como la identidad de un
objeto, o una base de datos, existe el peligro de que el acceso produzca conflictos en un entorno compartido.
Podría ser, por ejemplo, que varias tareas independientes utilizasen simultáneamente la misma identidad de
un objeto. Todo recurso global debe ser poseído por un objeto guardián que controle el acceso a éste. Un
objeto guardián puede controlar varios recursos. Todo el acceso al recurso debe pasar a través del objeto
guardián. Por ejemplo, la mayoría de los administradores de bases de datos son tareas libres a las cuales
invocan otras tareas para obtener datos de la base de datos. La asignación de cada recurso global compartido
a un único objeto es un reconocimiento de que ese recurso tiene una identidad.

Un recurso lógico también se puede descomponer lógicamente, de forma que los subconjuntos se asignan a
distintos objetos guardianes para ser controlados de modo independiente.

En una aplicación en la cual el tiempo sea crítico, el costo de pasar todo el acceso a un recurso a través de un
objeto guardián resulta a veces excesivo, por lo que los clientes deben acceder directamente al recurso. En
este caso, se pueden situar bloqueos en subconjuntos del recurso. Un bloqueo es un objeto lógico asociado
con algún subconjunto definido de algún recurso que proporciona a quien posea el bloqueo el derecho de
acceder directamente a ese recurso. Sigue siendo necesario que exista un objeto guardián para asignar los
bloqueos, pero tras una interacción con el guardián para obtener un bloqueo, el usuario del recurso puede
acceder directamente al recurso. Esta aproximación es más peligrosa porque hay que confiar en que todos los
usuarios de recursos se comporten correctamente en su acceso al mismo. El uso de accesos directos a
recursos compartidos no debe de propugnarse en un diseño orientado a objetos a no ser que resulte
absolutamente necesario.

Software de control
Durante el análisis, todas las interacciones se muestran como sucesos entre objetos. El control del hardware
se parece mucho al modelo de análisis, aunque el diseñador de sistemas de be escoger entre varias maneras
de implementar el control en software. Aún cuando no existe una necesidad lógica de que todos los
subsistemas utilicen la misma implementación, lo normal es que el diseñador seleccione un único estilo de
control. Existen dos clases de flujos de control en un sistema de software: el control externo y el interno.
El control externo es el flujo de los sucesos externamente visibles entre los objetos del sistema. Existen tres
clases de control para sucesos externos: secuencial, controlado por procedimientos, secuencial controlado por
sucesos, y concurrente. El estilo de control que se adopte dependerá de los recursos disponibles y de la trama
de interacciones existentes en la aplicación.

El control interno es el flujo de control dentro de un proceso. Solo existe en la implementación y, por tanto, no
es inherentemente concurrente ni secuencial. El diseñador puede decidir descomponer un proceso en varias
tareas por claridad lógica o por rendimiento. A diferencia de los sucesos externos, las transferencias internas
de control, tales como las llamadas a procedimientos o las llamadas entre tareas, están dirigidas por el
programa y se pueden estructurar de la forma que más convenga. Son frecuentes tres clases de control de
flujo: llamadas a procedimientos, llamadas entre tareas que son casi concurrentes y llamadas entre tareas
concurrentes. Las llamadas entre tareas casi concurrentes, tales como las corrutinas o procesosligeros, son
conveniencias de programación en las cuales existen múltiples espacios de direcciones o pilas de llamada,
pero en las que solamente puede estar activo un hilo de control en cada momento.

Diseño De Los Objetos

La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina
el plan de ataque. La fase de diseño de objetos determina las definiciones completas de las clases y
asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de
los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos
internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es
análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.

Aspectos generales del diseño de objetos

Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan
los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación
a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del
diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el
tiempo de ejecución, la memoria y el costo. En particular, las operaciones identificadas durante el análisis
deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones
internas más sencillas. Las clases, atributos y asociaciones del análisis deben de implementarse en forma de
estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados
intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos. La optimización del
diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la
extensibilidad son también objetivos importantes.

Algoritmos
Cada operación especificada en el modelo funcional debe ser formulada como un algoritmo. El análisis de
especificaciones dice lo que hace la operación desde el punto de vista de sus clientes y los algoritmos
muestran cómo se hace. Un algoritmo se puede subdividir en llamadas a operaciones más sencillas y así
sucesivamente, hasta que las operaciones del nivel más bajo sean suficientemente sencillas para
implementarlas directamente sin más refinamiento.

El diseñador de algoritmos debe:

- Seleccionar algoritmos que minimicen el costo de implementar las operaciones

- Seleccionar estructuras de datos adecuadas para los algoritmos
- Definir nuevas clases y operaciones internas según sea necesario
- Asignar la responsabilidad de las operaciones a las clases adecuadas

Controles
El diseñador debe refinar la estrategia para implementar los modelos de estados y sucesos presentes en el
modelo dinámico. Como parte del diseño del sistema, se habrá seleccionado una estrategia básica para
construir el modelo dinámico. Durante el diseño de objetos, es necesario desarrollar esta estrategia.

Para implementar el modelo dinámico hay tres aproximaciones básicas:

- Utilizar la posición dentro del programa para almacenar el estado (sistema controlado por procedimientos
- Implementación directa de un mecanismo de máquina de estados (sistema controlado por sucesos)
- Utilización de tareas concurrentes

Asociaciones
Las asociaciones son el pegamento de nuestro modelo de objetos, y proporcionan vías de acceso entre objetos
siendo entidades conceptuales útiles para el modelado y el análisis. Durante la fase de diseño de objetos hay
que formularse una estrategia para implementar las asociaciones habidas en el modelo de objetos. Se puede
seleccionar una estrategia global para implementar todas las asociaciones uniformemente o bien seleccionar
una técnica particular para cada asociación, teniendo en cuenta la forma en que será utilizada en la aplicación.
Para tomar decisiones inteligentes acerca de las asociaciones se necesita analizar primero la forma en que
serán utilizadas.

ejemplo
Para ejemplificar la aplicación del método ADD, a continuación mostraremos el resultado de algunos de los
pasos del proceso para una iteración del diseño de arquitectura usando como base el ejemplo introducido en
la columna anterior. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la
comercialización de productos de diversos fabricantes”.

Para este ejemplo, supondremos que ya se tiene suficiente información sobre los drivers (paso 1), que es la
primera iteración, que el elemento a descomponer es el sistema entero (paso 2) y que se ha identificado el
siguiente sub-conjunto de drivers para la iteración:

 Caso de uso primario: Realizar consultas del catálogo de productos.

 Atributos de calidad: Escenario de modificabilidad relativo a la facilidad para agregar nuevos sistemas
externos de fabricantes de productos.
 Restricción: Uso de librerías y herramientas Open Source.

El siguiente paso (4) indica que debemos elegir conceptos de diseño para satisfacer los drivers. Dado que se
tienen escenarios de modificabilidad y que se está en una iteración inicial del diseño, en la cuál se busca crear
la estructuración de alto nivel del sistema, se elige como concepto de diseño el patrón de “capas”, que
permite agrupar responsabilidades generales del sistema. Por otro lado, se elige el concepto de diseño de
“módulos” para agrupar funcionalidades a nivel de las distintas capas y soportar el caso de uso elegido.
Finalmente, se opta por aplicar el patrón Inversión de Control para conectar los componentes que estarán
contenidos en los módulos y facilitar la integración de nuevos módulos. Este patrón se aplica mediante la
introducción del framework “Spring”, que es open source.

Posteriormente, en el paso 5 aplicamos los conceptos de diseño y asignamos responsabilidades a los

elementos resultantes. La figura 1 muestra un posible resultado inicial de descomposición de la arquitectura.
Durante este paso del diseño, además de aplicar los conceptos de diseño, se asignan responsabilidades a los
elementos identificados. Ejemplos de asignaciones de responsabilidades serían:

 La capa de integración contendrá el conjunto de elementos que permitirá a la aplicación comunicarse

con los diferentes sistemas externos a través de diferentes canales.
 El módulo de InterfazCatálogos contiene los componentes que permiten desplegar las pantallas
asociadas al caso de uso de consulta de catálogo de productos.

El siguiente paso (6) consiste en definir interfaces para los elementos resultantes. En iteraciones iniciales, las
interfaces entre los elementos no se detallan de forma extensa, sin embargo en iteraciones subsecuentes,
dichas interfaces deben documentarse de forma más detallada.

Ahora verificamos la satisfacfción de los drivers seleccionados en el paso 3. El primer nivel de descomposición
de la arquitectura cubre los requerimientos de la siguiente forma: la solución incluye módulos que permitirán
al usuario realizar las consultas al catálogo de productos, adicionalmente la división en capas favorece la
modificabilidad. La selección tecnológica también favorece la modificabilidad y se apega a las restricciones..
 Construyendo Iteraciones

La iteración incluye las actividades de desarrollo que dan lugar al release de un producto; es decir, una versión
estable y ejecutable del producto, junto con los demás elementos periféricos necesarios para utilizar este
release. Una iteración de desarrollo es, de algún modo, un recorrido completo por todas las disciplinas:
requisitos, análisis y diseño, implementación y realización de pruebas, como mínimo. Es como un pequeño
proyecto de cascada en sí mismo. Hay que tener en cuenta que se establecen criterios de evaluación cada vez
que se planifica una iteración. El release tendrá una posibilidad planeada que es demostrable. La duración de
una iteración varía en función del tamaño y de la naturaleza del producto, pero lo más probable es que se
construyan múltiples compilaciones en cada iteración, según se especifica en el plan de creación de
integración de la iteración.

Esto es una consecuencia del continuo enfoque de integración recomendado en Rational Unified Process
(RUP): a medida que van habiendo componentes probados en unidad disponibles, éstos se integran y, a
continuación, se crea una compilación y se le realizan pruebas de integración. De este modo, la posibilidad del
software integrado crece a medida que la iteración avanza, hacia los objetivos que se han establecido al
planificar la iteración. Se podría argumentar que cada compilación representa en sí misma una mini-iteración,
la diferencia reside en la planificación necesaria y en el nivel de formalidad de la valoración efectuada. En
algunos proyectos, puede ser adecuado y conveniente construir compilaciones cada día, pero éstas no
representarían iteraciones tal como las define RUP, excepto, quizás, en el caso de un proyecto muy pequeño
de una sola persona. Incluso en pequeños proyectos de varias personas (por ejemplo, uno que implique a
cinco personas compilando 10.000 líneas de código), sería muy difícil alcanzar una duración de iteración
inferior a una semana. Para obtener una descripción de los motivos que lo explican, consulte el
apartado Directriz: Plan de desarrollo de software.

¿Por qué la iteración?

Tradicionalmente, los proyectos se han organizado para pasar por cada disciplina de forma secuencial, una y
sólo una vez. Este enfoque da lugar al ciclo vital en cascada:

A menudo, el resultado es un "amontonamiento" de integración en un momento avanzado de la

implementación, cuando, por primera vez, se compila el producto y empiezan a realizarse pruebas. Problemas
que han permanecido ocultos durante las fases de análisis, diseño e implementación, salen a la superficie con
fuerza y el proyecto se queda estancado porque empieza un lento ciclo de resolución de defectos.
Una forma más flexible (y menos arriesgada) de proceder es pasar varias veces por las distintas disciplinas de
desarrollo, consiguiendo una comprensión mayor de los requisitos, construyendo una arquitectura sólida,
mejorando la organización de desarrollo y, finalmente, proporcionando una serie de implementaciones que
son cada vez más completas. Esto es un ciclo vital iterativo. Cada recorrido por la secuencia de disciplinas de
proceso se denomina iteración.
Por lo tanto, desde un punto de vista de desarrollo, el ciclo vital del software es una sucesión de iteraciones a
través de las cuales el software se desarrolla de forma incremental. Cada iteración finaliza con el release de un
producto ejecutable. Este producto puede ser un subconjunto de la visión completa, pero es útil desde
algunas perspectivas de ingeniería o de usuario. Cada release va acompañado de productos de trabajo de
soporte: descripción del release, documentación del usuario, planes, etc, así como de modelos actualizados
del sistema.

La consecuencia principal de este enfoque iterativo es que los productos de trabajo, descritos antes, crecen y
maduran con el tiempo, como se muestra en el siguiente diagrama.

Evolución del conjunto de información a través de las fases de desarrollo.

Objetivo menor
Cada iteración se finaliza con un objetivo menor, donde el resultado de la iteración se valora en relación con
los criterios de éxito objetivos de dicha iteración en particular.
 Especificación de arquitectura
¿Por que la importancia de la Arquitectura?
La complejidad en el desarrollo de sistemas empresariales donde hay requerimientos de alta disponibilidad,
de integración, componentes distribuidos y seguridad ha ocasionado que sea necesario contar con un
desarrollador de software experimentado en la combinación de las tecnologías adecuadas para lograr que un
sistema con estas características sea exitoso y cumpla así los objetivos del sistema.

¿Qué es Arquitectura?

Es la especificación de la estructura de un sistema para soportar correctamente su operación.

Metas de la arquitectura

 Reducir los riesgos tecnológicos del proyecto asociados a sistemas de gran escala

 Diseñar los componentes de software que soporten la operación del sistema y cumplan con los
requerimientos no funcionales

 Facilitar el diseño, implementación y despliegue de la aplicación.

¿Qué es un Arquitecto de Software?

Una persona como cualquiera de nosotros que cuenta con suficiente experiencia para poder proponer
soluciones. Contrario a lo que podríamos pensar, un Arquitecto no es un gurú del desarrollo, no se centra en
detalles de codificación y no tiene porque conocer los detalles codificación de todos los frameworks
conocidos. El Arquitecto debe conocer cómo funcionan las diferentes opciones tecnológicas, sus ventajas y
desventajas para poder proponer una o varias alternativas de solución que normalmente deben sujetarse a
restricciones de presupuesto, tiempo y recursos. La elección debe ser cuidadosa ya que uno de sus objetivos
es tratar de eliminar los riesgos del desarrollo sistema y garantizar la operación del sistema una vez liberado.
Los proyectos siempre tienen variantes o requieren de ciertos frameworks que nunca habíamos utilizado, por
ello también el Arquitecto debe saber investigar y entender rápidamente cómo funciona la tecnología.

Actividades del Arquitecto

El insumo de un Analista Funcional de Sistemas son los requerimientos de Negocio y Funcionales para
encontrar ¿Qué funcionalidad debe proporcionar el sistema?. El insumo de un Arquitecto son los
Requerimientos No Funcionales y las Restricciones Iniciales para determinar ¿Cómo debe ser construido el
sistema para soportar tal funcionalidad?.
El Arquitecto al igual que el Analista de Sistemas debe realizar actividades de Análisis, Diseño y Construcción
con la diferencia que su objetivo son los Requerimientos No Funcionales del Sistema, todo aquello que
determina como debe funcionar el sistema.

¿Cómo proponer una solución?

El Arquitecto obtiene los requerimientos iniciales, las restricciones, los supuestos, identifica riesgos, analiza la
información y formula una o varias propuestas de solución tomando en cuenta todo lo anterior. Dentro de la
solución no elige un framework porque es el favorito del Arquitecto, no elige el lenguaje de desarrollo porque
quiere aprenderlo o porque es el de moda, los elementos que conforman la solución deben elegidos de forma
adecuada para que en conjunto cumplan con los requerimientos no funcionales y las restricciones de tiempo,
costo y recursos.

¿Cuál es el resultado de las actividades de análisis de un Arquitecto?

El resultado es un entregable al que llamo en este artículo: Documento de Arquitectura, este documento
puede tener diferentes nombres dependiendo de la metodología y de la empresa: Documento de Arquitectura
(Vision Consulting), Service Level Agreement (SLA), TCH100 (GNP) etc.
Las siguientes son algunas de las actividades que debe realizar el Arquitecto para poder proponer una solución
de Arquitectura.

Obtención y Análisis de Requerimientos

Requerimientos de Negocio
Al igual que el Analista Funcional, el arquitecto debe identificar y conocer cuáles son los objetivos de negocio
que motivan el desarrollo del sistema. Esto permitirá proponer la solución más adecuada en función de estos
objetivos y evitar cualquier desviación.

Requerimientos No Funcionales
Los Requerimientos No Funcionales (NFRs) son los niveles de servicio y restricciones que el sistema debe
cumplir, cuando un cliente es experimentado puede definirlas por el mismo, en otras ocasiones es el
arquitecto quien debe ayudar a identificarlas.
En el Documento de Arquitectura el listado de Requerimientos No funcionales puede ir en una tabla como la
siguiente escritas con palabras propias del cliente.

Clave Descripción

NFR01 Descripción del Requerimiento No Funcional

NFR 02

Estás características dictan Como?, Que tan bien? o Que tan rápido? se debe realizar la funcionalidad del
sistema. Estas características técnicas están clasificadas y bien definidas, Sun Microsystems en su Metodología
de Arquitectura, Sun Tone Methodology las llama Cualidades Sistémicas o Quality of Service (QoS)
Cualidades Sistémicas
Las cualidades sistémicas están definidas por Sun Microsystems de la siguiente manera:

Manifiestas u obvias para el usuario

 Desempeño (Performance) – Que tan rápido el sistema debe cumplir la petición.

 Confiabilidad (Reliability) – El sistema debe ser exacto.

 Disponibilidad (Availability) – Cantidad de tiempo en línea en el que el sistema puede procesar

solicitudes. (De hecho el tema es más complejo)

 Usabilidad (Usability) – Que tan fácil es usar el sistema.

Cualidades operacionales que están ligadas al sistema en ejecución

 Rendimiento de trabajo (Throughput) – Cantidad de trabajo hecho por el sistema medido en

operaciones por unidad de tiempo.

 Posibilidad de ser Administrado (Manageability).

 Seguridad (Security) – Prevención de uso no autorizado del sistema y su información.

 Serviceabilidad (Serviceability) – Esfuerso necesario para actualizar o reparar el sistema.

 Facilidad de hacer pruebas (Testeability) – Esfuerzo requerido para identificar y aislar una falla en el
sistema.

Cualidades Evolucionarias relacionadas de cómo se comporta el sistema cuando es modificado o

actualizado.

 Escalabilidad (Scalability) – Capacidad de crecer y mantener buenos niveles de operación ante un

incremento en el número de usuarios o peticiones.

 Mantenibilidad (Maintainability) – Que tan susceptible es de ser corregido o reparado.

 Extensibilidad (Extensibility) – Posibilidad de agregar funcionalidad nueva.

 Flexibilidad (Flexibility) – Costo de implementar una corrección o una funcionalidad nueva.

 Reusabilidad (Reusability) – Esfuerzo ahorrado apoyándose en componentes existentes

 Portabilidad (Portability) – Esfuerzo ahorrado cuando se migra a una infraestructura diferente.

Cualidades de Desarrollo que afectan como se está construyendo

 Realizabilidad (Realizabilidad) – Probabilidad o confianza en que el sistema puede desarrollarse, se ve

reflejado en la facilidad de estimación, planeación y construcción.

 Planeabilidad (Serviceability) – Confianza en que el sistema puede ser planeado en costo y esfuerzo.

Algunas cualidades sistémicas son excluyentes entre sí, por ejemplo Desempeño Vs Seguridad, el
cumplimiento de una minimiza a otra por lo que es necesaria una priorización en las cualidades sistémicas
para poder decidir de entre varias opciones de solución cual es la más adecuada y que no comprometa el
cumplimiento de una o varias cualidades.
Las cualidades sistémicas identificadas se listan y priorizan en un listado como el siguiente:

QoS Prioridad Descripción del Requerimiento Propuesta para cubrir el requerimiento

Disponibilidad Alta El sistema no debe quedar fuera Opción 1: Se propone escalar el sistema con
de línea en las horas pico o dentro XX Memoria RAM y mover las aplicaciones
de la ventana de servicio. existentes a otro servidor con menos
recursos

Opción 2: Se propone el uso de 2 servidores

YYY y 1 balanceador de carga.
Seguridad Alta
Tiempos de Alto Ver tabla anexa
Respuesta

Características operacionales

Característica Operaciones del Sistema Descripción

Detectadas
Transaccional *Asignación del folio Se desarrollarán los componentes de negocio con EJBs

*Calculo de número de Los demás componentes de negocio se desarrollarán con POJOs

referencia para poder llegar a los tiempos de respuesta solicitados.
Concurrencia * Registro de un
solicitante

* Consulta de reportes

* Configuración de
procesos de registro
Restricciones
Todo proyecto tiene restricciones, las más comunes son tiempo, recursos, presupuesto y tecnología a utilizar.
El arquitecto debe proponer alternativas de solución que se muevan dentro de estas restricciones. En algunos
casos será necesario sacrificar una buena opción porque no cumple alguna de estas.
Es muy importante documentar las restricciones iniciales del proyecto y a lo largo del desarrollo documentar
los cambios sobre estas restricciones. Al final del proyecto es común que alguien sin contexto cuestione: ¿Por
qué se hizo de esta manera? La respuesta puede estar en las restricciones iniciales y los cambios a lo largo del
proyecto.

Suposiciones
Al inicio del proyecto no siempre tenemos toda la información necesaria para poder plantar una propuesta,
incluso el cliente puede no tenerla. Esta incertidumbre puede hacer que dudemos en proponer una solución
porque no sabemos qué implicaciones puede tener ese faltante de información, pero por otro lado no
podemos quedarnos inmóviles a esperar a que se defina ese faltante, esto puede resultar en la pérdida de un
posible cliente. Ante estos casos se deben hacer supuestos y actuar en base a estos. Cuando por ejemplo se
hace una propuesta estos supuestos se deben notificar a todos los involucrados y denotar que cierta solución
es válida bajo ciertas consideraciones.

Riesgos
El manejo de riesgos es un tema importante en la administración de proyectos y de igual forma para la
Actividad de Arquitectura. Unos de los objetivos de la arquitectura es precisamente disminuir los riesgos
tecnológicos.
La idea es identificar todos aquellas situaciones que pueden poner en riesgo el éxito del proyecto dentro de
las restricciones de tiempo y presupuesto, crear un plan de mitigación y de contingencia en caso de que se de
el problema.

Riesgo Descripción Probabilidad Impacto Plan de mitigación

Ejemplo: El ambiente de desarrollo es ALTA ALTO / * Desarrollar en
Windows y el de Producción /MEDIA / MEDIO maquinas virtuales
Diferente es UNIX puede haber BAJA /BAJO * Realizar deploys y
comportamiento problemas de ambientación revisiones periódicas
entre el ambiente de del sistema en el
desarrollo y de ambiente AIX
producción
Ejemplo: La especificación dice que el BAJA ALTO RESUELTO
servidor de aplicaciones que
El cliente propone el adquirirá el cliente cumple Se realizaron pruebas
uso de un framework con le especificación XXX y el de operaciones
web open source que framework necesita de esa complejas con el
no ha sido probado en especificación para poder framework usando la
el servidor final funcionar. Hay una misma versión y
probabilidad de que el sistema operativo del
framework no funcione servidor de
 correctamente aplicaciones.
Ejemplo: Se está solicitando el tener MEDIO ALTO Se deben hacer
tiempos de respuesta de pruebas de
Tiempos de respuesta máximo 5 segundos para desempeño en el
arriba del valor operaciones de consulta en servidor de pruebas
requerido horario pico Es un criterio usando los mismos
de elementos de
Dada la configuración de aceptación hardware e identificar
topología red donde se tiene para la posibles cuellos de
…… liberación botella fuera de la
aplicación

Esta tabla es un ejemplo y nos ayuda a identificar y prepararnos para saber que debe hacerse en caso de que
se presente un problema previamente identificado.
Esta lista de riesgos debe actualizarse y mantenerse durante todo el desarrollo del proyecto

Sizing y Planeación de la Capacidad

Dentro de este rubro se puede mencionar la medición del crecimiento de espacio en disco por elementos
propios de la aplicación, información tales como archivos o datos de la base de datos o número de peticiones
de clientes considerando cifras iniciales y a futuro.
Esta recolección de cifras ayudará a determinar qué tipo y cantidad de hardware es necesaria para soportar la
operación del sistema en un horizonte de tiempo dado.

Numero de Accesos

Accesos Accesos
concurrentes concurrentes
Accesos concurrentes Accesos concurrentes
Operaciones más Iníciales, Horario Pico Iníciales, Horario Futuros, Horario Pico Futuros, Horario
demandantes No Pico No Pico
(Operaciones / min) (Operaciones / min)
(Operaciones / (Operaciones /
min) min)

Registro de X 750 200 825 220

Consulta de
300 50 330 55
reportes

Configuración de 330 55
- -
catalogos
 A 1 año A 1 año

Crecimiento de espacio en Disco Duro

Descripción del Tipo de Cantidad inicial (6 Tamaño al final del Porcentaje

archivo Archivo meses) MB año (MB) semestral Periodicidad

EARs, Wars de la
aplicación Aplicación

Archivos Archivos

Base de
Base de datos Datos

Archivo de
Log texto

Esquema de Base
de Datos Esquema

Total

Crecimiento de la base de datos

Tamaño inicial en
Incremento
registros (primeros 6
semestral (% o núm)
Tabla meses) Operación

Consulta Actualización

%o %o
Nombre Oper Frec núm. Oper Frec núm.

CSI_AREA 13 0% S DIA 525 ----- ----- 0

CSI_COLONIA 91500 0% S DIA 525 ----- ----- 0

CSI_DEPENDENCIA 30 0% S DIA 525 ----- ----- 0

CSI_ESTADO 32 0% S DIA 525 ----- ----- 0

Propuesta de Solución (Diseño)

Tipo de Sistema

Se debe especificar qué tipo de sistema se desarrollará.

 Cliente / Servidor

 Multicapa

 Multicapa web

Diagrama de Capas y Filas

Este diagrama es un artefacto de la metodología Sun Tone Methodology, muestra la tecnología a utilizar en
cada una de las capas del sistema y por cada capa define niveles de productos que participan en la solución.
Cada una de las tecnologías elegidas da solución a los requerimientos detectados en la fase de Análisis.
Ejemplo: Este es un diagrama de ejemplo, Algunas de las celdas pueden haber sido dadas de inicio por las
restricciones tecnológicas del cliente y las otras se llenan con la propuesta tecnológica del Arquitecto

Capa Capa Cliente Capa de Capa de Capa Integración o Capa de Recursos

Presentación Negocio Acceso a Datos
Nivel
API, *HTML ver. 4.01 Presentación: *POJOs *Hibernate 3.0 BD:
Framework con JSE *Tablas
*CSS 2.1 *Web Components 6.0 *JSE 6.0
JSP1.2, Servlet 2.5, *No Habra triggers,
*DOM 2 *Webservices con ni stored procedures
*Struts 1.3 JAX-WS
*Javascript
*JSE 6.0 *Correo con
*Plugins: apache-mail
Reportes:
*Adobe Reader *Java IO para
PDF *Jasper Reports lectura de
archivos
*Ajax Prototipe *JFree Chart
*WebServices con
Utilerias: AXIS2.0

*apache-commons
Producto Explorer >=6.0, *JBoss 4.3.2GA con soporte para JEE5.0 *SQL Server 2005
Mozilla>=2.0 para la BD del
 *Workflow: jBPM 3.3.2 sistema (En server 1)
Sistema Cualquiera *Linux Ubuntu Server 8.04 *Windows 2003
Operativo Server en server 1.

Hardware Cualquiera *Servidor 2: Opteron AMD dual core serie 800 *Servidor 1: intel
xeon 3.2 MHZ

Capa de Cliente: Es la capa donde se ejecuta una aplicación de consola, dispositivo móvil, pc desktop o con
navegador web.

Capa de Presentación: Aquí residen los componentes dinámicos de vista y control que generan una salida
HTML, XML y los Reportes que se envían al cliente, por ejemplo JSP, Servlets.

Capa de Negocio: Aquí residen los procesos de negocio, workflow, timers.

Capa de Integración: Aquí residen los componentes que permiten la comunicación al exterior tal como
componentes de acceso a base de datos, web services, correo, colas de mensajes, clientes de web service,
conectores.

Capa de Recursos: Aquí se encuentran todas las fuentes de información externas, tales como Bases de Datos,
sistemas de Archivos, Content Managers, Mainframes.

Diagrama de Componentes

El diagrama de componentes inicial es una propuesta de que componentes de software intervendrán en la

solución.

Diagrama de Despliegue

El Diagrama de Despliegue inicial nos ayuda a saber con qué otros sistemas interactuarán y convivirá el
nuestro dentro.

Prototipo

Provee una demostración o implementación de principio a fin de los componentes tecnológicos primarios,
demuestra la viabilidad de la solución y sirve como guía para el desarrollo del sistema.
Estos prototipos pueden ser implementaciones base o presentaciones ppt dependiendo del nivel de cliente
para el cual se desea hacer una prueba

Usabilidad
La usabilidad toma en cuenta el tipo de personas que serán usuarios del sistema para proporcionarles una
interfaz de usuario que permita hacer productivo su trabajo y por ninguna circunstancia dañe su información.
En este sentido es necesario al inicio del proyecto hacer pruebas de usabilidad ya sea con un demo o una
presentación que muestre la forma en la que se interactuará con el sistema.
Principios de Diseño a seguir:

 Visibilidad – Claridad en la información a presentar.

 Retroalimentación – Enviar información en respuesta a una acción del usuario.

 Facilidad - Uso de elementos obvios y sencillos para el usuario.

 Simplicidad – Mantener una interfaz simple.

 Estructura – L a interfaz de usuario está dispuesta en una forma lógica y con sentido.

 Consistencia – Uniformidad y la navegación hacen fácil el uso

 Tolerancia – La aplicación debe tolerar los errores de usuario, (uso de confirmaciones, mensajes de
error)

El realizar esta exploración de los elementos de interfaz de usuario requeridos ayudará a elegir la tecnología
de la capa de presentación que debe usarse desde el inicio del proyecto. No es lo mismo utilizar simples JSPs
que utilizar AJAX, esta diferencia implica requerimientos del servidor de aplicaciones, de recursos humanos y
de costos.