4 11 1 Arquitectura SW

Arquitectura de Software
Semana 6 - Sesin 11
Temario
Documentacin de la arquitectura
Modelo de arquitectura 4+1.
Diagramas del UML para las vistas de arquitectura.
Hagamos un recuento de lo recorrido hasta el momento y
de lo que falta recorrer
Fuente: Rational Unified Process

Relacin entre los artefactos de las
disciplinas de la ingeniera de software
Casos de Clases de Clases de Cdigo Exec

uso anlisis diseo fuente
Requerimientos y arquitectura
Diseo de la
Modelo de casos de uso
Arquitectura
Metas, mecanismos y
vistas de la
Arquitectura
Especificaciones
Suplementarias
(requerimientos
arquitectnicos)
Visin de la arquitectura
Dos rasgos en comn que tienen los proyectos

exitosos son:
La aplicacin de un ciclo de vida iterativo e incremental
bien administrado.
La existencia de una consistente visin de la arquitectura.
La visin de la arquitectura es que debe ser simple.
Pero a la vez informar a todos los diferentes participantes
del proyecto acerca de lo que les interesa saber acerca del
sistema a implementar.
Propsitos de la arquitectura
Desarrollar software que satisfaga un conjunto dado de
requisitos funcionales.
Alcanzar los requisitos no funcionales explcitos o
implcitos (atributos de calidad) para el desempeo y uso
de recursos.
Estar conforme a las limitaciones del ambiente.
Satisfacer restricciones sobre el proceso de diseo en si
mismo (tiempo, costo y disponibilidad de herramientas)
Balancear un conjunto de requisitos que

compiten entre si
1
Documentacin de la arquitectura
Para qu es til la documentacin
de la arquitectura?
Para tener informacin:
Lo suficientemente abstracta
para que nuevos miembros del
equipo de desarrollo y los
stakeholders puedan
entenderla con facilidad.
Lo suficientemente detallada, a
modo de bosquejo, para la
construccin del cdigo.
Suficiente, como base de
anlisis y entrenamiento. Fuente: Imgenes prediseadas de office.com
Para qu es til la documentacin
de la arquitectura?
Para establecer una declaracin de
la misin del sistema, til para los
desarrolladores.
Para explicar la divisin del
sistema y sus dependencias
Para establecer el punto de inicio
en la comprensin del sistema,
como instalarlo y como
recuperarlo en caso de fallas.
Para establecer el correcto plan de
desarrollo, resaltando la
funcionalidad y atributos de Fuente: Imgenes prediseadas de office.com
mayor impacto.
Documento de arquitectura
Fuente: CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

Reflexiona un momento
Antes de continuar con los contenidos propios

de la documentacin de la arquitectura,
conviene que te preguntes:
Has elegido adecuadamente los requerimientos
no funcionales y de uso general adecuados para
tu arquitectura?
Esta pregunta es importante porque a menudo nos
preocupamos por satisfacer la funcionalidad y nos
olvidamos de los otros aspectos del software.
Arquitectura y funcionalidad
Los sistemas son frecuentemente rediseados no

porque la funcionalidad sea deficiente, sino
porque:
Son difciles de mantener o escalar
No son portables
Son lentos
No garantizan la seguridad
Funcionalidad y atributos de calidad son dos partes
de un todo.
Arquitectura y atributos de calidad
Se determinan cules son los relevantes mediante
preguntas.
Es el desempeo crtico?
En este caso la arquitectura debe localizar las
operaciones crticas dentro de un nmero reducido de
subsistemas con poca comunicacin, para favorecer a
que los tiempos de respuesta sean cortos.
Es la seguridad crtica?
En este caso se sugiere utilizar una estructura de capas,
con los recursos mas crticos protegidos por las capas
mas internas y con alto nivel de validacin de la
seguridad aplicado a estas capas.
Es la disponibilidad crtica?
Ante esta necesidad, la arquitectura debe tener
componentes redundantes de tal forma que sea posible
reemplazar y actualizar los componentes que pueden fallar,
sin detener el sistema.
Es el mantenimiento crtico?
La arquitectura debe tener componentes de grano fino, esto
es sin muchas funcionalidades y dependencias, que puedan
cambiarse con facilidad.
Los productores de datos (componentes que crean datos)
deben estar separados de los consumidores (formularios de
consulta) y las estructuras de datos compartidas deben
evitarse.
Un modelo de capas suele ser ideal
La arquitectura es crtica para muchas cualidades de
inters del sistema.
Esas cualidades pueden ser diseadas y evaluadas a nivel de la
arquitectura, pero no resueltas
El logro de los atributos de calidad se deben considerar a
travs del diseo, implementacin y distribucin del
sistema.
A continuacin veremos una tabla en donde los atributos
de calidad son tratados de distinta manera, dependiendo si
el enfoque es arquitectnico o de diseo.
Atributo de
Enfoque Ejemplo
calidad
De diseo Hacer que la interfaz sea fcil de usar.
Usabilidad Hacer que el usuario sea capaz de cancelar
De arquitectura
operaciones o revertirlas.
Estilo de codificacin que favorezca el
De diseo
cambio.
Modificabilidad Como es dividida la funcionalidad para
De arquitectura localizar rpidamente las piezas del sistema
que deben ser cambiadas.
Seleccin de algoritmo y herramientas de
De diseo
anlisis para medir los tiempos de respuesta.
Desempeo Funcionalidad y recursos asignados a cada
De arquitectura mdulo para favorecer los tiempos de
respuesta.
No olvides que
Los atributos de calidad se documentan en la

arquitectura en un captulo denominado:
Metas y restricciones de la arquitectura
En este captulo se mencionan los
requerimientos de alto impacto y los
mecanismos que se deben usar para resolverlos.
Arquitectura y vistas
Vistas
Una vista es una representacin fsica de un conjunto de
elementos del sistema y las relaciones asociadas a ellos
Fuente: CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

Elementos de la documentacin
Tipos de vistas
Un tipo de vista define los tipos de elementos y tipos de
relaciones usadas para describir la arquitectura de
software desde una perspectiva en particular.
De acuerdo al Software Engineer Institute (SEI) de la
Universidad Carnegie Mellon existen tres tipos de
vistas:
Vistas modulares
Vistas de componentes y conectores
Vistas de despliegue
Tipos de vistas arquitectnicas
Vistas modulares
Muestra la estructura de los mdulos
lgicos de las aplicacin.
Vistas de componentes & conectores
(C&C)
Muestra la estructura de las unidades
que se estn procesando en un
sistema en ejecucin.
En otras palabras, la dinmica del
sistema.
Vistas de asignaciones Fuente: http://www.bredemeyer.com/howto.htm
Muestra las relaciones entre el

software y los entornos de desarrollo
y ejecucin.
Estilos
Son esquemas especializados pertenecientes a un tipo
de vista concreto.
Definen una serie de restricciones a los tipos de
elementos de software y sus relaciones.
La arquitectura de un sistema esta compuesta por

vistas concretas pertenecientes a mltiples estilos
de los tipos de vista.
Tipos de vistas y estilos
Tipo de vista Estilo
Descomposicin
Uso
Mdulo Generalizacin
Capas
Caera-y-Filtro (Pipes-Filters)
Tipos de Componente-y- Datos compartidos
vistas y Conector Publicar suscribir
estilos Cliente servidor
Peer-to-peer
Procesos que se comunican
..
Despliegue
Asignacin Implementacin
Asignacin de tareas
Cmo se documenta la arquitectura?
Existe un documento de la arquitectura.
Dependiendo de la complejidad del sistema el documento
deber tener un mayor detalle en la descripcin de las
vistas.
Este documento incluye:
Un descripcin textual de la filosofa de la arquitectura (las
vistas) y las claves de conduccin a travs de
requerimientos.
Concesiones hechas o alternativas consideradas.
Vistas de alto nivel de diferentes aspectos del software.
Qu ms puede ir en el documento de
arquitectura?
Tambin se puede incluir:

Escenarios de desarrollo especficos.
Patrones de arquitectura
Un patrn de arquitectura de software es un esquema genrico
probado para solucionar un problema particular recurrente que
surge en un cierto contexto.
Este esquema se especifica describiendo las componentes, con sus
responsabilidades, relaciones, y las formas en que colaboran.
El diagrama de la base de datos
Con las tablas clave y sus relaciones.
Quin desarrolla el documento?
Un pequeo e experimentado equipo de arquitectos,
conducido por un jefe que se responsabilizan por:
Definir y mantener la integridad de la arquitectura del sistema.
Aprobar los cambios sobre los paquetes de interfaces.
Evaluar los riesgos del proyecto.
Proponer el orden y contenido de cada iteracin.
En la fase de elaboracin del proyecto, los miembros del
equipo se dedican al 100% a disear la arquitectura.
En la fase de construccin los miembros se convierten en
diseadores guas para los equipos de desarrollo y
actualiza los cambios en la arquitectura a tiempo parcial.
No olvides que
Con una buena arquitectura un equipo

promedio de desarrolladores puede tener
xito.
Con una arquitectura dbil, ni el grupo mas
experto de desarrolladores puede tener
xito.
Conclusiones
Un documento de arquitectura es importante
como elemento de comunicacin entre los
diferentes participantes en un equipo de
desarrollo de software.
Una arquitectura bien documentada es til para
conducir a los equipos de desarrollo y tambin
para capacitacin.
Buenas arquitecturas propician aplicaciones
exitosas.
2
El modelo 4+1
El modelo 4+1
Fue creado por Philippe Krutchen
El modelo 4+1 describe la arquitectura del
software usando cinco vistas concurrentes como
se muestra en el siguiente diagrama.
Las Vistas 4+1 del Modelo
Vista Lgica Vista de

Desarrollo
Funcionalidad Admin. de Software,
Reuso y Portabilidad
Vista de Ingenieros
Analistas
Casos de Uso de Software
Comprensin y Uso
Vista del Proceso Vista de la

Rendimiento,
Distribucin
=VP + Escalabilidad,
Disponibilidad,
Entrega e Instalacin
Tolerancia a Fallas
Integradores y testers Ingenieros
de redes y comunicaciones
Fuente: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
En resumen
De acuerdo a Krutchen, para describir una
arquitectura se requiere de 4 vistas + 1:
Vista Descripcin
Proporciona una figura esttica de las clases principales y sus
Lgica
relaciones agrupadas en mdulo o paquetes
Muestra como el cdigo es organizado en componentes,
Desarrollo libreras y paquetes y tambin resalta el uso de software
comercial - COTS (commercial off-the-shelf).
Proceso Muestra los procesos y tareas del sistema en ejecucin.
Muestra los procesadores, dispositivos y enlaces en el ambiente
Despliegue
operativo.
Casos de Y finalmente el +1 es el escenario del modelo de casos de uso
Uso que explica como las otras vistas pueden funcionar juntas.
En importante que tomes en cuenta
Para aplicaciones Web y otras aplicaciones que no requieren
orden de compilacin, las vistas de proceso y desarrollo se
han fusionado en una vista llamada Vista de Implementacin.
Vista Descripcin
Proporciona una figura esttica de las clases principales y
Lgica
sus relaciones agrupadas en mdulo o paquetes
Muestra como el cdigo es organizado en componente,
Implementacin interfaces, libreras y el uso de software comercial - COTS
(commercial off-the-shelf) para ser instalado y ejecutado.
Muestra los procesadores, dispositivos y enlaces en el
Despliegue
ambiente operativo.
Y finalmente el +1 es el escenario del modelo de casos de
Casos de Uso uso que explica como las otras vistas pueden funcionar
juntas.

Desarrollo
Vista de Ingenieros
Analistas
Comprensin y Uso

Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista lgica
La Vista lgica (logical view) de la arquitectura
organizar los requerimientos funcionales del
sistema en modelos.
Estos es, lo que el sistema debe proporcionar en
trminos de servicios para sus usuarios.
Proporciona una figura esttica de la agrupacin
de las clases y de sus relaciones.
Se suele representar un diagrama de paquetes
que contiene clases y relaciones que representan
las abstracciones clave del sistema.
Se pueden representar en la vista lgica los
mismos estilos del tipo de vista modular
propuestos por el SEI.
Vista lgica
A los paquetes propios del desarrollo se

adicionan los paquetes globales
Son paquetes con funciones que son usadas
por varias de las clases en desarrollo.
Son proporcionadas por el entorno de Foundation
programacin Classes
Se puede usar el estereotipo global global
Ejemplos
Clases fundamentales (Foundation clases)
Conjuntos (Sets), Listas(lists), Colas (queues), etc.
Clases de soporte a errores (Error handling

classes)
Vista lgica
Es importante tener en cuenta las dependencias
de la vista lgica.
Cada vez que se hace un cambio en algn paquete
servidor el paquete del cliente debe volverse a revisar.
El paquete del cliente no puede ser usado
independientemente porque depende del paquete del
servidor.
Paquete Paquete
Cliente Proveedor
Vista lgica
Es deseable que la jerarqua de paquetes no sea
cclica.
Esto significa que la dependencia circular debe ser
evitable
Esta se da cuando un paquete A usa el B y viceversa.
Esta dependencia implica que el paquete A y el B deben
ser tratados como un paquete nico.
Crculos mas amplios deben ser igualmente evitados.
Estas dependencias se pueden romper dividiendo
uno de los paquetes en dos mas pequeos.
Ejemplo de dependencia circular
Interfaces Reglas de
Negocio
Interfaces Reglas de
de Input Negocio
Interfaces
de Output
Vista lgica
En la vista lgica va:
Paquetes que representan
mdulos y sus relaciones
Si el desarrollo se divide en
capas
Se muestra el diagrama de
capas.
Si el sistema se ha dividido
en subsistemas
El diagrama de subsistemas. Fuente: http://www.bredemeyer.com/howto.htm
Ms las descripciones de
cada uno de estos
elementos.
Capas
Una capa (layer) proporciona una particin lgica
de un sistema o subsistema
Las capas se ordenan de arriba abajo.
Las capas de arriba estn ms cercanas al usuario final
Las capas de abajo estn ms cercanas al sistema
operativo.
El resultado es que el sistema tiene bajo
acoplamiento y por lo tanto es ms fcil su
mantenimiento.
Capas
Relaciones entre capas
La relacin es de uso permitido (Allowed to use)
Establece una jerarqua de capas.
Los mdulos de una capa no pueden utilizar
arbitrariamente los de una capa superior.
Reglas de uso: nicamente el nivel inmediatamente
inferior, o cualquier nivel inferior, etc.
Caractersticas
Reusabilidad, portabilidad y tolerancia a fallas
Ejemplo de Capas en .Net
Fuente: http://msdn.microsoft.com/en-us/library/ms954601.aspx

Desarrollo
Vista de Ingenieros
Analistas
Comprensin y Uso

Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista de desarrollo
La vista de implementacin est relacionada con la
organizacin de los componentes del software
dentro del ambiente de desarrollo.
Est conformada por:
Componentes
Interfaces
Paquetes de componentes
Relaciones de realizacin entre componentes e
interfaces
Relaciones de dependencia entre componentes.
La dependencia puede ser a travs de una interfaz o directa.
Qu es un componente?
Un componente es una unidad de cdigo fuente
que sirve como un bloque de construccin para la
estructura fsica del sistema.
Los estereotipos sirven para especificar a las
diferentes tipos de componentes.
Ejemplos: cs, exe, dll, main programs, headers,
modules, forms.
Esto vara dependiendo del ambiente de desarrollo y
del lenguaje de programacin.
Qu es un componente?
Hay que agrupar clases en componentes si tienen
una funcin cooperativa o si necesitan estar muy
prximas para que la implementacin sea
eficiente.
La notacin de un componente en el UML es:
Cmo identificar un componente?
Para modelar un componente se
especifica.
Nombre del componente.
Se utiliza un sustantivo o conjunto de
caracteres.
Puede estar formado por letras y nmeros.
Corresponde con el nombre del archivo al
que representa y que figura en el ambiente <<estereotipo>>
de desarrollo.
Componente
Debe incluir la extensin del archivo
asociado al componente modelado.
Opcionalmente puede incluir etiquetas como
versin o autor.
Estereotipo.
Indica el tipo de componente que se ha
producido.
Ejemplos de componentes
Ictutor.exe
Msdbgen.dll
Epirpe20.ini <<estereotipo>>
HostControl.h Componente
Amovie.ocx
Cliente.asp
Dialog.cpp
La extensin o estereotipo de
TextJump.java un componente depende del
lenguaje de programacin
Cmprgco.idl
49
Qu es una interfaz?
Es un tipo de estructura especial que sirve como
vehculo de comunicacin entre dos
componentes.
Muestra las operaciones del o de los componentes
que la realizan.
No ejecuta ninguna funcin sino que la deriva al
componente encargado de hacerla.
Diagrama de componentes
Un diagrama de componentes en la vista de
desarrollo, muestra la asignacin de clases y
objetos a componentes de implementacin.
Tambin muestra las dependencias de compilacin de
ser requeridas.
Se requiere un nombre para cada componente.
Este nombre tpicamente debe ser simple y corto para
poder localizarlo fcilmente en el correspondiente
archivo fsico del espacio de trabajo de desarrollo.
Tambin describen en qu orden han de conversar
o ser compilados los componentes.
Adems del diagrama debe quedar especificado el
mapeo de las clases con los componentes
implementados.
Ejemplo de Diagrama de componentes
El siguiente diagrama muestra las dependencias

de compilacin de varios componentes.
Cul ser l o los primeros componentes en
compilarse?
Cul ser el ltimo?
Paquetes en la vista de desarrollo
En la vista de desarrollo un paquete es una
coleccin de componentes, donde algunos son
visibles u ocultos a otros.
Un paquete agrupa componentes que estn
lgicamente relacionados.
Correspondencia con la vista lgica
En general, un paquete o capa de la vista lgica
corresponde directamente con un paquete o
componente de la vista de desarrollo.
No obstante las estructuras lgica y fsica pueden
variar de acuerdo a las siguientes razones:
Los paquetes de la vista lgica se fusionan para
conservar a los objetos con una comunicacin estrecha
para la implementacin, inspirados en la funcionalidad
que tienen en comn.
Los paquetes o componentes de la vista de desarrollo
son adicionados para implementar funcionalidad de
bajo nivel (como una librera de funciones adquirida
para estadsticas).
Ejemplo de correspondencia entre las
capas lgicas y de desarrollo
Vista Lgica: Vista de Desarrollo:

Diagrama Capas Diagrama de Componentes

Desarrollo
Vista de Ingenieros
Analistas
Comprensin y Uso

Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista del proceso
La vista del proceso se concentra en la
descomposicin de los diferentes procesos del
sistema en tiempo de ejecucin.
El diagrama de componentes se actualiza para
mostrar la asignacin de componentes a procesos.
La vista de procesos implica el cumplimiento de
ciertos atributos de calidad como: disponibilidad,
fiabilidad, rendimiento, administracin y
sincronizacin del sistema.
Qu es un proceso?
Un proceso es la ejecucin de un hilo de control
en un programa OO o sistema.
La mayor parte de los sistemas que usamos, ejecutan
un proceso a la vez.
Hay otros sistemas que pueden descomponerse en
mltiples procesos o hilos de control.
Ejemplo de un sistema de este tipo son las centrales
telefnicas que atienden ms de un proceso o llamada a la vez.
Componentes del proceso
Los ejecutables y sus libreras asociadas con representadas como

componentes.
Package specification (DLL)
Task specification (EXE)
En algunas implementaciones del UML como el Rational Rose
pueden adoptar diferentes formas como las que se muestran a
continuacin.
Package specification (DLL)

Task Specification (EXE)
Ejemplos de procesos que se ejecutan en
paralelo
Matricula.exe Conta.exe
Proceso para el registro Proceso para la generacin

semestral de la matrculas de cuotas y conceptos de
de los alumnos pago y que registra los pagos
efectuados por el alumno.
orientado al proceso
Matricula.exe
Conta.exe Sistema
Contabilidad
Usuarios
Cursos
Agentes.dll
Cursos.dll Alumnos Profesores
Curso Oferta de
Cursos
Vista de los componentes ejecutables


Desarrollo
Vista de Ingenieros
Analistas
Comprensin y Uso

Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista de implementacin
La vista de implementacin tambin usa un diagrama de

componentes, llamado diagrama de implementacin.
Usa todos los elementos de un diagrama de componentes.
Esta orientado a la ejecucin y comunicacin entre componentes.
El diagrama de implementacin debe responder a la pregunta:
Si maana debo instalar el sistema en un cliente, qu componentes
debo llevar?
Qu pruebas debo hacer para validar la interaccin de los
componentes?
Cada elemento del diagrama debe estar descrito de manera que
se entienda su relacin con la vista lgica.
En la vista de implementacin se pueden representar los estilos
del tipo de vista componente-conector propuestos por el SEI.
Ejemplo de un diagrama de
implementacin

Desarrollo
Vista de Ingenieros
Analistas
Comprensin y Uso

Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista de la distribucin o despliegue
La vista del despliegue vincula componentes a nodos
de procesamiento (mquinas).
Los atributos de calidad como rendimiento y
tolerancia a las fallas son tomados en cuenta.
Los diagramas de despliegue son creados para mostrar
los diferentes nodos (procesadores y dispositivos) en
el sistema.
Tambin muestra la asignacin de componentes a dichos
nodos
Tambin muestra los tipos de enlace fsicos y protocolos de
comunicacin usados.
La vista de despliegue se inspira en el estilo despliegue
del tipo de vista de asignacin propuesto por el SEI.
El diagrama de despliegue
El Diagrama de Despliegue tambin puede
mostrar:
Los distintos componentes de una arquitectura de tres
capas fsicas (Three Tier)
Servidor de datos
Servidor de aplicaciones
Cliente
Diferentes configuraciones fsicas de nodos para la

ejecucin.
Elementos de la vista del despliegue
Nodos
Representa un recurso computacional o dispositivo.
Es un elemento fsico que existe en tiempo de ejecucin.
Constituye un lugar fsico donde se ejecutan los componentes
diseados o rehusados.
Se representa con un cubo con un nombre representativo
Nombre
del nodo
Tipos de nodo.
Procesador (Processor).
Procesador
Nodo con capacidad de
procesamiento por lo que puede
ejecutar un componente.
En el UML 1.X se representaba
con un cubo sombreado.
Dispositivo (Device).
Nodo sin capacidad de
procesamiento. Por lo general Dispositivo
representa una mquina
necesaria para la
implementacin del sistema.
Ejemplo: impresora, modem, etc.
Conexin
Una conexin indica comunicacin.
Usualmente significa enlaces de hardware entre nodos y
dispositivos.
Se denota por una lnea etiquetada con el tipo de conexin
Tipo de conexin
Ejemplo de diagrama de despliegue
Fuente: http://www.robertz.com/Papers/AspMarch1998/Developing%20Applications%20with%20Java,%20IIS,%20and%20ASP.html
Despliegue de los componentes
Los procesos y componentes son asignados a procesadores

La asignacin puede ser dinmica
Los procesos deben ejecutarse en mquinas.
Se representan asociados al nodo en texto o grfico
Nombre
del
Procesador
proceso 1, proceso 2, ... proceso n

Diagramas de despliegue y de implementacin
Fuente: http://yed.yworks.com/support/qa/1572/can-yed-draw-uml-deployment-diagram
Diagrama de despliegue no UML
Fuente: http://www.tutorialspoint.com/uml/uml_deployment_diagram.htm
Consideraciones especiales en el despliegue
Al vincular paquetes de desarrollo con procesos
ejecutables hay que tomar en cuenta que:
Este proceso involucra la comprensin de la topologa
del sistema y sus prioridades:
La arquitectura del procesador, su velocidad y capacidad.
Conservar las asociaciones de clases juntas para minimizar la
comunicacin interprocesos (IPC)
Estrategia IPC -- cliente/servidor u otra?
Tcnicas de distribucin de procesos.
Se debe resolver puntos relacionados con mltiples
procesadores o sistemas distribuidos durante el diseo.
Consideraciones especiales en el despliegue
Al vincular procesos ejecutables al hardware
Los procesos deben ser asignados a dispositivos de
hardware para su ejecucin.
Hay que tomar en cuenta aspectos como:
Tiempo de respuesta y de puesta en marcha del sistema.
Ancho de banda de comunicacin y sus capacidad.
Medio ambiente del hardware requerido.
Necesidades de procesamiento distribuido.
Sobrecarga o balance del procesador en un sistema
distribuido.
Tolerancia a fallas.
...

Desarrollo
Vista de
Analistas Ingenieros
Comprensin
y Uso
Rendimiento,
Distribucin
Disponibilidad,
Tolerancia a Fallas
Vista de casos de uso
Los casos de uso son los conductores del diseo
de la arquitectura.
Son las abstracciones de largos y complejos
requerimientos.
Permiten identificar interfaces crticas.
Fuerzan a los diseadores a concentrarse en puntos
concretos.
Permiten la planificacin de las iteraciones.
Conclusiones
La arquitectura 4+1 es un esquema que cubre
aspectos de documentacin del software a
travs de;
4 vistas especficas orientadas a distintos interesados
y stakeholders
+ 1 una vista que conduce todo el proceso, que es la
vista de la funcionalidad o casos de uso.
La arquitectura 4+1 es compatible con los tipos
de vista recomendadas por el Instituto de
Ingeniera de Software de la universidad
Carnegie Mellon.
3
Diagramas del UML para la

arquitectura
La vista 4+1 y diagramas del UML
Vista Lgica Vista de Desarrollo

Diagrama de Paquetes
Diagrama de Subsistemas Diagrama de Componentes
Diagrama de Capas
Vista de
Casos de Uso
Diagramas de
Casos de Uso
Vista de Procesos Vista de Despliegue
Diagrama de Componentes Diagrama de Despliegue

Los elementos de documentacin ms
empleados son:
Interfaz
Una interfaz es un lmite a travs del cual dos
elementos pueden comunicarse e interactuar.
Mdulo:
Es una unidad de implementacin no de
tiempo de ejecucin.
Los elementos de un mdulo estn altamente
cohesionados.
Componente: Fuente: http://www.bredemeyer.com/
Es una unidad de cdigo de tiempo de
ejecucin.
UML y la vista lgica
En la vista lgica podemos tener:
Un diagramas de mdulos de clases
Un diagrama de capas
Un diagrama de subsistemas
Diagrama de mdulos
Se utiliza cuando las

clases se han agrupado de
acuerdo a mdulos
lgicos.
Se muestra la
descomposicin de
mdulos en sub mdulos.
Se utilizan los paquetes
del UML para representar
tanto a los mdulos
contenedores como a los
sub mdulos.
Diagrama de capas
Para representar las

capas tambin se utilizan
paquetes.
Se colocar el estereotipo
de <<layer>> para
representar que se trata
de una capa.
Se representa la relacin
<<allowed tu use>> con
una dependencia.
Diagrama de capas con subcapas
Diagrama de subsistemas
Para representar un
subsistema, UML 2.x tiene
un estereotipo especial.
Otro elemento es la interfaz,
que es el lmite que permite
la comunicacin entre
subsistemas.
Cuando un subsistema
requiere de una interfaz
para publicar sus servicios
utiliza la relacin de
realizacin <<realizatin>>.
Cuando un subsistema
requiere los servicios de
otro subsistema utiliza una
relacin de dependencia
con el estereotipo <<use>>
para comunicarse con la
interfaz de dicho
subsistema.
Diagrama de subsistemas
Relacin de
dependencia entre
Interfaz subsistemas.
Relacin de
realizacin entre un
Subsistema subsistema y su
interfaz
UML y las vistas de desarrollo, de procesos y
de implementacin
Para todas las vistas que tienen que ver con el desarrollo de cdigo se
utiliza el diagrama de componentes (component diagram) del UML.
Los elementos bsicos de un diagrama de componentes son:
Componentes
Interfaces
Relacin de realizacin entre un componente y su interfaz
Una interfaz realizada expone los servicios de un componente.
Relacin de dependencia entre un componente y la interfaz de otro
componente.
Cuando un componente necesita los servicios de otro componente lo hace a travs de su
interfaz.
Relacin de dependencia entre componentes.
Cuando un componente necesita de otro componente servidor y este no expone una
interfaz, la dependencia es directa.
Componente
Dependencia
directa
Relacin de uso
(dependencia)
Interfaz
Relacin de
realizacin
Diagrama de implementacin
UML y la vista de despliegue
Para la vista de despliegue se utiliza el diagrama de despliegue
(deployment diagram) del UML
EL Diagrama de Despliegue tiene los siguientes elementos:
Nodos
Asociaciones
Puertos
Conectores
Los nodos se vinculan a travs de asociaciones que reflejan la
comunicacin que existe entre ellos.
Las asociaciones se pueden documentar con el tipo de enlace y el protocolo
Los puertos se vinculan entre si a travs de conectores que denotan un
enlace fsico.
Adems, muestra la asociacin de los componentes de la vista de
implementacin a los nodos de procesamiento.
Diagrama de Despliegue
Nodo
Procesador
Asociacin con
Puerto
protocolo
Conector
Nodo
Dispositivo
Diagrama de despliegue con asociacin de
componentes
Componentes
asociados
Ejemplo diagrama de despliegue
No olvides que
En la vista lgica se puede usar ms de un
diagrama del UML, dependiendo de cmo se ha
organizado la agrupacin de la funcionalidad.
En las vistas relacionadas con el desarrollo se usa
el diagrama de componentes que establece los
componentes de desarrollo y la dependencia
entre ellos.
En la vista de despliegue se usa el diagrama de
despliegue que muestra los elementos de
hardware de la arquitectura que ejecutarn los
componentes del software.
96
Conclusiones
El UML proporciona los artefactos y diagramas
necesarios para documentar las vistas de la
arquitectura
Bibliografa
CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

BREDEMEYER CONSULTING, Software Architecting. Disponible en:
http://www.bredemeyer.com/howto.htm
KRUCHTEN, Philippe. Planos Arquitectnicos: El Modelo de 4+1 Vistas de la
Arquitectura del Software.pdf
Unified Modeling Language (UML). Disponible en: www.uml.org
Preguntas
Si, luego del estudio de este
material, tienes dudas sobre
alguno de los temas, ingresa al
Aula Virtual y participa en el foro
de dudas acadmicas de la unidad.
Contina con las actividades
propuestas en la sesin.
Material producido para el curso de Arquitectura de Software

Autor: Mara del Pilar Stronguil Leturia
Diseo y produccin: TICE
ARQUITECTURA DE SOFTWARE- EPE

COPYRIGHT UPC 2014

4 11 1 Arquitectura SW

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

4 11 1 Arquitectura SW

Diunggah oleh

Hak Cipta:

Format Tersedia

Arquitectura de Software

Fuente: Rational Unified Process

Casos de Clases de Clases de Cdigo Exec

Dos rasgos en comn que tienen los proyectos

Balancear un conjunto de requisitos que

Fuente: CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

Antes de continuar con los contenidos propios

Los sistemas son frecuentemente rediseados no

Los atributos de calidad se documentan en la

Fuente: CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

Muestra las relaciones entre el

La arquitectura de un sistema esta compuesta por

Tambin se puede incluir:

Con una buena arquitectura un equipo

Vista Lgica Vista de

Vista del Proceso Vista de la

Vista Lgica Vista de

Vista del Proceso Vista de la

A los paquetes propios del desarrollo se

Clases de soporte a errores (Error handling

Vista Lgica Vista de

Vista del Proceso Vista de la

El siguiente diagrama muestra las dependencias

Vista Lgica: Vista de Desarrollo:

Vista Lgica Vista de

Vista del Proceso Vista de la

Los ejecutables y sus libreras asociadas con representadas como

Package specification (DLL)

Proceso para el registro Proceso para la generacin

Cursos.dll Alumnos Profesores

Vista de los componentes ejecutables

Vista Lgica Vista de

Vista del Proceso Vista de la

La vista de implementacin tambin usa un diagrama de

Vista Lgica Vista de

Vista del Proceso Vista de la

Diferentes configuraciones fsicas de nodos para la

Los procesos y componentes son asignados a procesadores

proceso 1, proceso 2, ... proceso n

Vista Lgica Vista de

Diagramas del UML para la

Vista Lgica Vista de Desarrollo

Diagrama de Componentes Diagrama de Despliegue

Se utiliza cuando las

Para representar las

CLEMENTS, Paul. Documenting Software Architectures: Views and Beyond

Material producido para el curso de Arquitectura de Software

ARQUITECTURA DE SOFTWARE- EPE

Anda mungkin juga menyukai