Propuesta de Modelos para Descripcion de Arquitectura PDF

Modelo propuesto, para la descripci on de una
arquitectura basada en la ISO/IEC/IEEE 42010

Juan Camilo Puerta - Jose Luis Vargas - Alvaro Andres L opez
25 de noviembre de 2013
ii
Indice general
Acknowledgements XI
Dedication XIII
1. Introduccion 1
2. Arquitectura de TI 3
2.1. Arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Arquitectura empresarial . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Tipos de arquitectos de software . . . . . . . . . . . . . . . . . . 6
2.3.1. Arquitecto tecnico . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Arquitecto funcional . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Arquitecto Empresarial . . . . . . . . . . . . . . . . . . . 7
2.4. Competencias de un arquitecto . . . . . . . . . . . . . . . . . . . 7
2.4.1. Habilidades humanas . . . . . . . . . . . . . . . . . . . . . 7
2.4.2. Habilidades tecnicas . . . . . . . . . . . . . . . . . . . . . 7
2.5. Importancia de la descripcion de arquitectura . . . . . . . . . . . 8
2.6. Dise no de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Dise no de alto nivel . . . . . . . . . . . . . . . . . . . . . 9
2.6.2. Dise no de bajo nivel . . . . . . . . . . . . . . . . . . . . . 9
2.7. Lenguajes de descripcion de arquitectura (ALDs) . . . . . . . . . 10
2.7.1. UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7.2. SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.3. ARCHIMATE . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.4. BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8. Frameworks de arquitectura . . . . . . . . . . . . . . . . . . . . . 13
2.8.1. Frameworks de proposito general - . . . . . . . . . . . . . 15
2.8.2. Frameworks de dominio especco - . . . . . . . . . . . . . 15
2.8.3. Tipicacion de frameworks . . . . . . . . . . . . . . . . . 15
3. Descripcion ISO/IEC/IEEE 42010 17
4. Situacion actual de las empresas bogotanas 19
iii
iv

INDICE GENERAL
5. Modelos para la descripcion de una arquitectura basada en la
norma ISO/IEC/IEEE-42010 31
5.1. Modelos para la descripcion de una arquitectura basada en la
norma ISO/IEC/IEEE-42010 . . . . . . . . . . . . . . . . . . . . 32
5.2. Descripcion de la norma ISO/IEC/IEEE-42010 . . . . . . . . . . 32
5.3. Modelos Propuestos . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Trabajo Por Realizar . . . . . . . . . . . . . . . . . . . . . . . . . 42
A. Traduccion de la norma ISO/IEC/IEEE 42010 43
A.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.1.1. Deniciones encontradas en la norma . . . . . . . . . . . . 43
A.1.2. Conceptos encontrados en la norma . . . . . . . . . . . . 45
A.2. Descripcion de la arquitectura . . . . . . . . . . . . . . . . . . . . 50
A.2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2.2. Identicacion e informacion general . . . . . . . . . . . . . 50
A.2.3. Vistas de arquitectura . . . . . . . . . . . . . . . . . . . . 51
A.2.4. Identicacion de Stakeholders e interes . . . . . . . . . . . 52
A.2.5. Modelos de arquitectura . . . . . . . . . . . . . . . . . . . 53
A.2.6. Reglas de relaciones . . . . . . . . . . . . . . . . . . . . . 53
A.2.7. Justicacion de la arquitectura . . . . . . . . . . . . . . . 53
A.2.8. Relacion de arquitectura . . . . . . . . . . . . . . . . . . . 53
A.2.9. Registro de decisiones . . . . . . . . . . . . . . . . . . . . 55
A.2.10. Adherencia de una AD y un AF . . . . . . . . . . . . . . 55
A.3. Frameworks de arquitectura y ADLs . . . . . . . . . . . . . . . . 56
A.3.1. Frameworks de arquitectura . . . . . . . . . . . . . . . . . 56
A.3.2. Lenguajes de descripcion de arquitectura . . . . . . . . . 56
A.4. Puntos de vista de arquitectura . . . . . . . . . . . . . . . . . . . 56
A.5. Anexo A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.5.1. Notas en terminos de conceptos . . . . . . . . . . . . . . . 57
A.5.2. Sistemas y Arquitecturas . . . . . . . . . . . . . . . . . . 57
A.5.3. Intereses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.5.4. Modelos, productos de trabajo y modelos de arquitectura 58
A.5.5. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.5.6. ISO/IEC 19793 Versus ISO/IEC 42010 . . . . . . . . . . . 59
A.5.7. Frameworks de arquitectura y ADLs . . . . . . . . . . . . 60
A.5.8. Archimate . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.6. Anexo B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.6.1. Guas para puntos de vista de arquitectura . . . . . . . . 61
A.6.2. Guas para puntos de vista de arquitectura . . . . . . . . 62
A.7. Anexo C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.7.1. ISO 12207:2008: the software arquitectural desing process
(6.4.3.3.1 y 7.1.3.3.1) . . . . . . . . . . . . . . . . . . . . . 63
Indice de cuadros
2.1. Tipo de frameworks . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Muestra una distribucion de elementos en las plataformas de tal
forma que cumplen la regla ?Regla1?. . . . . . . . . . . . . . . . 58
A.2. Muestra una distribucion de elementos en las plataformas de tal
forma que incumplen la regla ?Regla1?. . . . . . . . . . . . . . . 59
v
vi

INDICE DE CUADROS
Indice de guras
2.1. La diferencia en la interpretacion de un requerimiento. . . . . . . 3
2.2. Comparativa con la Ingeniera Civil. . . . . . . . . . . . . . . . . 4
2.3. Comparativa con la Ingeniera Civil. . . . . . . . . . . . . . . . . 5
2.4. Arquitectura empresarial la base del negocio. . . . . . . . . . . . 5
2.5. Estructura de la arquitectura empresarial. . . . . . . . . . . . . . 6
2.6. Colombianada arquitectonica. . . . . . . . . . . . . . . . . . . . . 9
2.7. Importancia AD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Togaf referenciado por archimate. . . . . . . . . . . . . . . . . . . 11
2.9. Componentes de las diferentes vistas de archimate. . . . . . . . . 12
2.10. BMPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.11. Notaciones del BPMN. . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Rol desempe nado en la empresa . . . . . . . . . . . . . . . . . . . 19
4.2. Conoce que es un Stakeholder . . . . . . . . . . . . . . . . . . . . 19
4.3. Conoce que es un interes en el sistema por parte de un Stakeholder? 20
4.4. En la descripcion de arquitectura identica Stakeholder . . . . . 20
4.5. En la descripcion de la arquitectura (AD) identica los intereses
que los diferentes Stakeholder tiene en el sistema . . . . . . . . . 20
4.6. Elementos de descripcion de arquitectura utiliza? . . . . . . . . . 21
4.7. Etapas del proceso de desarrollo de software realiza la arquitec-
tura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8. En la descripcion de arquitectura (AD) usted incluye puntos de
vista orientados a expresar el interes que los Stakeholder tienen
en el sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9. En las vistas que usted crea, utiliza mas de un punto de vista
para expresar los intereses que los Stakeholder tienen en el sistema 22
4.10. Que uso le da a la descripcion de arquitectura . . . . . . . . . . . 23
4.11. Cuales intereses utiliza en los puntos de vista . . . . . . . . . . . 23
4.12. Cuales de los siguientes elementos de descripcion de arquitectura
(AD) utiliza dentro de los puntos de vista . . . . . . . . . . . . . 24
4.13. Que convenciones usa en los puntos de vista . . . . . . . . . . . . 24
4.14. Que uso le da a las convenciones en los puntos de vista . . . . . . 25
4.15. Que tipos de modelo usa en los puntos de vista . . . . . . . . . . 25
vii
viii

INDICE DE FIGURAS
4.16. Que Lenguaje Descripcion de Arquitectura (ADL) utiliza para
describir la arquitectura del sistema . . . . . . . . . . . . . . . . 26
4.17. Que importancia le da a expresar los intereses de los Stakeholder
por medio del ADL? . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.18. Que tipos de modelo expresa con el Lenguaje de Descripcion de
Arquitectura (ADL) utilizado? . . . . . . . . . . . . . . . . . . . 27
4.19. El ADL que utiliza le permite expresar las relaciones y reglas de
relacion entre los elementos de un modelo regido por unos puntos
de vista? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.20. Que Framework de Arquitectura (Marco de Referencia de Arqui-
tectura) utiliza? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.21. El Framework de arquitectura que utiliza le permite identicar
los intereses que los diferentes Stakeholder tienen en el sistema? . 28
4.22. Que relaciones puede identicar con el Framework de arquitectura
que utiliza en los puntos de vista descritos? . . . . . . . . . . . . 29
4.23. El Framework de arquitectura que utiliza le permite declarar re-
glas de correspondencia entre los elementos de los puntos de vista? 29
4.24. Con que propositos usa o ha usado los Framework de Arquitectura? 30
5.1. Proceso para identicacion de Stakeholders . . . . . . . . . . . . 34
5.2. Modelo Organizacional, general a compa nas de TI . . . . . . . . 36
5.3. Funciones de los roles . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4. Cooperacion entre roles para la descripcion de Arquitectura . . . 38
5.5. Cooperacion entre roles para la descripcion de Arquitectura . . . 38
5.6. Proceso descripcion de arquitectura, identicacion Framework,
vista, ADLs, puntos de vista . . . . . . . . . . . . . . . . . . . . . 39
5.7. Identicacion de aplicaciones a construir y a proponer en modelos
de arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Identicacion de ADL de descripcion de arquitectura . . . . . . . 40
5.9. Modelo Archimate Norma ISO/IEEE/IEC 42010 . . . . . . . . . 41
5.10. Modelo Archimate Norma ISO/IEEE/IEC 42010 . . . . . . . . . 42
List of Others
ix
x LIST OF OTHERS
Acknowledgements
Agradecemos por su participacion y colaboracion en la investigacion a:
Participacion directa:
Ing. Alexandra Abuchar (Director)
Ing. Paulo Cesar Coronado (Asesor)
Ing. Sandro Bola nos (Asesor)
Participacion indirecta:
Ing. Agustn Valle Daz
xi
xii ACKNOWLEDGEMENTS
Dedication
Dedicamos este trabajo a Dios y a nuestras familias que con su apoyo in-
condicional nos dieron la fuerza necesaria para mantener las esperanzas a lo
largo de nuestros estudios, llevando la culminacion de esta investigacion y de
este libro.
xiii
xiv DEDICATION
Captulo 1
Introducci on
Con la constante automatizaci on de procesos a traves de herramientas IT,
los sistemas han dado un gran paso hacia el futuro, dado esto, se promueven
nuevas oportunidades para la industria como para la Ingeniera de Software, per-
mitiendo adoptar una norma que permita tener un estandar y/o organizacion,
la cual se adopta a partir del 2001.
La norma ISO/IEC/IEEE 42010 nace el 2 de agosto 2001, cuando ANSI
adopta la norma IEEE 1471 convirtiendola en la ANSI/IEEE 1471 como Practi-
cas recomendadas para descripcion de arquitectura, convertida en norma para
aplicaciones de software. Inicialmente nace como una propuesta para describir
arquitectura, a traves de las necesidades de los Stakeholder, vistas, puntos de
vista y justicacion de la arquitectura [6].
Adoptar mejores practicas para aplicar en la industria se han convertido en
un factor vital, puesto que se incrementa la eciencia y ecacia para el desarrollo
de software, ahora bien, com unmente nos encontramos con diferentes requeri-
mientos, tanto funcionales como no funcionales (atributos de calidad), diferen-
tes Stakeholder, y diferentes tecnologas a utilizar para resolver un problema
especco, esto genera muchas inquietudes de como abordar un proyecto de
arquitectura y aunque tenemos muchos Frameworks arquitectonicos, tampoco
tenemos certeza de cual se debe usar, causando muchas inquietudes a la hora
de abordar un requerimiento; todo este tipo de factores aunque son importan-
tes a la hora de la toma de decisiones no deben convertirse en un problema,
debe abordarse de una manera intuitiva y sencilla, permitiendo que se logre dar
solucion a la verdadera problematica.
La norma aborta la arquitectura de forma holstica, esto quiere decir que no
diferencia entre la descripcion de una arquitectura para una empresa o para un
proyecto. Para los autores esto quiere decir que la norma se aplica tanto para
hacer descripcion de arquitectura de software como empresarial.
1
2 CAP
ITULO 1. INTRODUCCI
ON
Captulo 2
Arquitectura de TI
2.1. Arquitectura de software
La arquitectura de software es importante dado que, esta dene la estruc-
tura del software, as como tambien describe aspectos relevantes de la misma,
entre ellas cualidades sistemicas, y elementos de relevancia, estos pueden ser
llamados Requerimientos no funcionales. Normalmente en la industria encon-
tramos Arquitecturas bien denidas, con todos los elementos necesarios, y dan
bastante claridad acerca de la forma como se debe C onstruir.
o
mplementar una
aplicacion software. En el proceso de desarrollo de software, se le ha dado una
fase donde se debe indicar la forma como se construira la aplicacion, esto pre-
vio a desarrollarla: para comunicar a todos aquellos interesados (Stakeholder)
se requiere que la arquitectura del sistema, sea clara y permita ser entendida
entre todos aquellos involucrados. Es importante la comunicacion entre roles,
normalmente cuando esta comunicacion falla, el sistema, realmente no cumple
las expectativas que se requieren. [12]
Figura 2.1: La diferencia en la interpretacion de un requerimiento Fuente:
http://img.desmotivaciones.es/201011/proyectoinformatico.jpg
3
4 CAP
ITULO 2. ARQUITECTURA DE TI
El problema anterior llevado a un campo de accion mas especco como, lo es
la arquitectura de software, conlleva a problemas estructurales, si la estructura
de un software falla, es posible que todo lo que ella tiene inmerso tambien falle,
ahora bien si requerimos que esa estructura nos soporte una aplicacion con
mas caractersticas, escalabilidad, desempe no, seguridad, entre otras debemos
contemplar que esta a futuro pueda tenerlas, sin que afecte la estructura inicial
para lo cual fue pensada.
Previamente Previamente a la denicion de arquitectura, se requiere identi-
car cuales son las necesidades de los Stakeholder, y de que manera se empieza
a interactuar con el sistema, all nacen los blueprintde arquitectura, donde
se empiezan a dise nar los planos del sistema. El arquitecto de software una vez
identica que es lo que se quiere realizar, empieza a jugar con las piezas del siste-
ma, con el n de unirlas de la manera esperada, siendo este un juego tecnologico,
donde ubicar cada pieza en el lugar correcto corresponde a cierto grado de ex-
pertiz para identicar la forma como debe ponerla, teniendo en cuenta todos
aquellos requerimientos o indicaciones que deben tenerse en cuenta.
Figura 2.2: Comparativa con la Ingeniera Civil Fuente:
http://roble.pntic.mec.es/jdic0020/imagenes/construccion.jpg
Existen elementos que nos ayudan a describir la arquitectura de un sistema,
entre estos elementos se encuentran todos aquellos, que permiten visualizar el
sistema, estos son llamados puntos de vista, y deben estar acordes a quien quiere
visualizar el sistema desde esa misma perspectiva.
Si no se presenta una arquitectura de manera adecuada posiblemente se
encuentren problemas de ambig uedad en el sistema, y se requiere que este eli-
mine todo tipo de ellas, permitiendo a los diferentes Stakeholder que haya un
entendimiento correcto de la aplicacion.
2.2. ARQUITECTURA EMPRESARIAL 5
Figura 2.3: Comparativa con la Ingeniera Civil Fuente: http://www.cnsc8.com/
2.2. Arquitectura empresarial
Es la disciplina de arquitectura aplicada a las empresas, la arquitectura
empresarial busca alinear los objetivos de las empresas con las TIC (tecnologias
de informacion y comunicaciones). [10]
Figura 2.4: Arquitectura empresarial la base del negocio Fuente:
http://www.amazing.com.co/images/arquitectura-de-procesos-de-negocio-big.jpg
La razon de ser del de la arquitectura empresarial es la de aumentar el
valor del negocio por medio de la inversion en TI(Tecnologa de Informacion);
ofreciendo una vision a largo plazo de los procesos, sistemas y tecnologa se
puedan ejecutar y no solo cubrir las necesidades actuales.
6 CAP
Figura 2.5: Estructura de la arquitectura empresarial Fuente:
http://2.bp.blogspot.com
Existen marcos de referencia y metodologas para hacer arquitectura empre-
sarial las cuales ya tienen un nivel alto de madurez y ofrecen conanza en el
mundo empresarial; algunos ejemplos de esto son Togaf, Zachman, FEA, Gar-
ner. En la seccion de framework de arquitectura se estudiara a mas detalle los
frameworks de proposito general y especco.
2.3. Tipos de arquitectos de software
Para denir que es un arquitecto de software, nos basamos en la vision
holstica y ontologica de la nomra ISO/IEC/IEEE 42010. Dicho de otra forma,
un arquitecto de software esta en la capacidad de hacer arquitectura para un
proyecto o para una empresa. Lo anterior depende de la organizacion, de su
negocio, de sus objetivos, de la inuencia del area de sistemas, de la importan-
cia de el/los proyecto/s y del tama no de los mismos. Teniendo en cuenta este
contexto, podemos proponer una serie de niveles en los que un arquitecto de
software se puede desempe nar: [12]
2.3.1. Arquitecto tecnico
Se trata de profesionales con amplios conocimientos tecnicos, conocedor del
negocio de los proyectos y que, probablemente, este asignado a uno o varios
proyectos al mismo tiempo. Algunas de sus responsabilidades suelen ser: denir
los lineamientos de dise no, su arquitectura y demas cuestiones tecnicas de los
proyectos.
2.4. COMPETENCIAS DE UN ARQUITECTO 7
2.3.2. Arquitecto funcional
Tienden a ocupar el rol de team leader y, a su vez, de lder tecnico. Mane-
jan el cronograma y planican las iteraciones junto al project manager (PM).
Suele representar un canal de comunicacion uida entre el PM y los equipos de
desarrollo. Validan dise nos; guan a los desarrolladores, para que cumplan con
las expectativas de calidad tomando metricas, organizando y promoviendo la
documentacion y las buenas practicas; aseguran que el proyecto no se desve de
la arquitectura previamente denida.
2.3.3. Arquitecto Empresarial
Unica los dos casos mencionados anteriormente; pero con algunos agre-
gados. El arquitecto empresarial esta llamado a conocer mas el negocio de la
empresa que un ingeniero de negocio, y debe tener un alto conocimiento en
estrategias de negocio.
2.4. Competencias de un arquitecto
2.4.1. Habilidades humanas
Capacidad de abstraccion creatividad
Liderazgo
Comunicacion oral y escrita
Negociacion
Disciplina
Autodidacta
[4]
2.4.2. Habilidades tecnicas
Manejar por lo menos un ADL (lenguaje de descripcion de arquitectura)
y el uso de por lo menos una herramienta de modelado.
Analisis, Dise no y Programacion Orientada a Objetos.
Estar actualizado en los paradigmas programacion que esten con fuerza
en el mercado.
Ventajas, desventajas y particularidades entre los principales lenguajes y
tecnologas disponibles: Java, C++, .Net, J2EE, etc.
Bases de datos.
8 CAP
Desarrollo basado en componentes.
Patrones de dise no.
Patrones de arquitectura.
Estilos de arquitectura.
Frameworks (De arquitectura y desarrollo).
Nuevas tecnologas y plataformas, incluyendo open source.
Conocimientos del hardware y sus capacidades.
Metodos de desarrollo de software tales como el Proceso Unicado, Scrum
y Xp por nombrar algunos
[4]
2.5. Importancia de la descripcion de arquitec-
tura
Es insolito darnos cuenta como podemos obtener dise nos de un hotel que
lleva construido por lo menos unos 50 a nos, pero no tenemos la arquitectura
del software hecho hace 6 meses; la falta de documentacion en los proyectos de
software no es algo nuevo ni que impresione, pero s que nos debera preocupar,
aqu se encuentra la base para la mantenibilidad y el exito de estos proyectos
en el tiempo. [1]
Todos los proyectos de Tecnologas de la informacion que conlleven software
tienen arquitectura. En los tiempos modernos la arquitectura se viene prac-
ticando como un arte a base de dibujos compuestos de cajas y echas, pero
como todo en este mundo de la tecnologa tiene un ritmo frenetico a la hora de
evolucionar, ya no basta con pintar y plasmar en papeles como va a funcionar
nuestra estructura. En proyectos grandes y con diferentes necesidades, necesi-
tamos contemplar diferentes puntos de vista para diferentes grupos de personas
(Stakeholder) de forma que todos entiendan lo que se quiere hacer, lo que se
esta haciendo y muy importante lo que se hizo. [7]
Lo que busca la descripcion de la arquitectura es tener una documentacion de
la estructura que sea duradera, rigurosa, completa y util. Con el n de mejorar
la comunicacion y el entendimiento entre los diferentes Stakeholder, ayudar a
corregir el problema de la desorganizacion de los proyectos, la dicultad de
la mantenibilidad, tener evidencia de las decisiones tomadas y de paso validar
buenas practicas a la hora de realizar una arquitectura. [9]
2.6. DISE
NO DE ARQUITECTURA 9
Figura 2.6: Colombianada arquitectonica Fuente:
http://i1185.photobucket.com/albums/z352/thereivaj/colom
2.6. Dise no de arquitectura
El nivel de detalle que se puede dar para una arquitectura es proporcionado
seg un para quien sea esta destinado, esto con el n de brindar a dicha persona
o grupo de personas la forma mas propicia para entender la arquitectura del
sistema, catalogando as de esta manera la arquitectura como dos tipos (dise no
de alto nivel y dise no de bajo nivel) las cuales ayudaran a entender un poco mas
la forma como debe construirse el sistema.
2.6.1. Dise no de alto nivel
Un dise no de alto nivel corresponde a la forma como se aborda el sistema des-
de un punto de vista mas abstracto, sin dar detalles concretos o muy puntuales
sobre la construccion del sistema.
2.6.2. Dise no de bajo nivel
Para un dise no de bajo nivel se debe llegar a una aproximacion de la imple-
mentacion del sistema, incluyendo todos aquellos aspectos detallados del siste-
ma, siendo este dise no el q tenga mayor claridad y acercamiento a la construccion
del sistema. Este tipo de dise nos son necesarios en cuanto a que pueden ser utiles
para un grupo de desarrollo, evitando as ambig uedades que puedan presentarse
sobre el sistema. [9]
10 CAP
Figura 2.7: Importancia de la descripcion de la arquitectura Fuente:
http://blog.construmatica.com/wp-content/uploads/2011/03/AGI-4.jpg
2.7. Lenguajes de descripcion de arquitectura
(ALDs)
2.7.1. UML
El lenguaje UML comenzo a gestarse en octubre de 1994 [1], cuando Rum-
baugh se unio a la compa na Rational fundada por Booch (dos reputados in-
vestigadores en el area de metodologa del software). El objetivo de ambos era
unicar dos metodos que haban desarrollado: el metodo Booch y el OMT (Ob-
ject Modelling Tool). El primer borrador aparecio en octubre de 1995. En esa
misma epoca otro reputado investigador, Jacobson, se unio a Rational y se in-
cluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos.
Ademas, este lenguaje se abrio a la colaboracion de otras empresas para que
aportaran sus ideas. Todas estas colaboraciones condujeron a la denicion de la
primera version de UML [2]. UML se encuentra avalado por la OMG 1, permi-
tiendo que este sea convertido en un estandar a nivel internacional.
Con la necesidad de crear un estandar para la comunicacion entre dise nadores
de software, surge UML, el cual se encarga de estandarizar los dise nos para
que estos puedan ser entendibles para cualquier dise nador, permitiendo una
mejor comunicacion entre ellos. La fase mas importante donde se hace uso de
estos modelos realizados en UML es en la de dise no, esto es necesario para que
los grupos de desarrollo puedan entender las caractersticas del sistema entre
muchos otros detalles que se deben tener en cuenta.
UML como cualquier lenguaje dene un vocabulario y unas reglas para per-
mitir la comunicacion, siendo dicho vocabulario, los elementos de comunicacion,
y las reglas, la sintaxis de dicho lenguaje, esto con el n de que este no pueda
presentar ambig uedades, de la forma como debe ser representado para que sea
entendible para todos los que quieran comunicarse mediante este ADL.
2.7. LENGUAJES DE DESCRIPCI
ON DE ARQUITECTURA (ALDS) 11
Para que un modelo UML se encuentre con una buen nivel de completitud
este debe contemplar
Elementos, los cuales corresponden a aquellas abstracciones de un elemen-
to de la vida real.
Relaciones, la relacion que puede existir entre los elementos anteriores.
Diagramas, Esto es una agrupacion de todos aquellos elementos son todas
las posibles interrelaciones.
[3]
2.7.2. SysML
SysML es un lenguaje, para modelado de sistemas, nace en el 19 de septiem-
bre de 2007 como una propuesta para el OMG, permitiendo modelar Analisis,
y dise no. [11]
2.7.3. ARCHIMATE
Archimate es un lenguaje libre e independiente para modelar arquitectura
empresarial. su objetivo es describir de una forma clara los dominios del nego-
cio. archimate es una tecnologia estandar del open group y esta basada en la
conceptos del estandar ISO 1471. archimate tambien es una marca registrada
por Open Group.
El lenguaje de modelacion de archimate se diferencia de otros como UML y
BPMN por tener un meta-modelo bien denido y por ofrecer un amplio margen
para el modelaje de la empresa.Archimate soporta framework como TOGAF,
DYA y la FAI, archimate es un est andar abierto mantenido por el Open Group.
[4]
Figura 2.8: Togaf referenciado por archimate Fuente: http://blog.itil.org
En la mayora de las empresas los grupos tecnicos y los grupos de negocio
hablan diferentes idiomas, dise nan sus propios modelos y tienen sus propias
tecnicas y herramientas por lo que se torna difcil la comunicacion y el entendi-
miento entre estas partes, afectando el desarrollo del negocio.
12 CAP
Archimate ofrece un lenguaje com un para describir la construccion y ope-
racion de procesos de negocio, estructuras organizativas, ujos de informacion,
sistemas informaticos e infraestructura tecnica. De esta forma se facilita la in-
teraccion, el dise no, informar el impacto de las decisiones y cambio dentro de
los diferentes grupos del negocio.
ArchiMate evita la confusion, ofreciendo un lenguaje sencillo y uniforme
para describir la arquitectura de la empresa. ArchiMate entrega tres capas de
modelaje:
La capa de negocio: procesos de negocio, organizacion, funciones de negocios,
productos y servicios de ocina.
La capa de aplicacion: aplicaciones, servicios de aplicacion, las funciones de
aplicacion, interfaces de aplicaciones.
La capa de la tecnologa: nodos, redes, servicios de infraestructura, software.
Figura 2.9: Componentes de las diferentes vistas de archimate Fuen-
te: https://lh4.ggpht.com/i5lh67xNYlZqKNb6eJD7yyK9UHkglyg7iP4Ogw4j3ZngVYkhslz0LBOi-
BjssMJJxoJKtA=s139
2.7.4. BPMN
BPMN es un lenguaje de descripcion de arquitectura orientado a describir
detalladamente los diferentes procesos de negocio de una empresa.
La rapida evolucion La rapida evolucion y de los negocios necesita el uso de
estandares para asegurar el entendimiento entre diferentes area y departamentos
dentro de una empresa y tambien con empresas diferentes. BPMN ofrece un
amplio conjunto de anotaciones que aseguran el cubrimiento de los diversos
procesos que ocurren dentro de una institucion.
2.8. FRAMEWORKS DE ARQUITECTURA 13
Figura 2.10: BMPN Fuente: https://lh6.ggpht.com
El objetivo del BPMN es asegurar la eciencia y el desarrollo de los proce-
sos en el tiempo a traves de la gestion de los procesos de negocio, que se deben
modelar, organizar, documentar y optimizar de forma continua
Figura 2.11: Notaciones del BPMN
[2]
2.8. Frameworks de arquitectura
Un Frameworks de arquitectura es una estructura de soporte en la cual la
descripcion de arquitectura, bien sea de un proyecto de desarrollo (Arquitectura
de software) o de una empresa (Arquitectura empresarial), puede ser organiza-
da y encarada con mayor simplicidad. Un Frameworks establece convenciones,
principios y practicas comunes, con un dominio de aplicacion y/o comunidad de
Stakeholder.
Los usos de un Frameworks de arquitectura incluyen pero no se limitan a:
La creacion y/o analisis de la descripcion de arquitectura, entendiendo
14 CAP
esta como un producto tangible y entregarse resultado de un trabajo o
proceso (workProduct), siendo este uno de los usos mas populares que se
encuentra en la industria del software colombiana.
Desarrollo de herramientas de modelado de arquitectura.
Metodos de arquitectura.
Establecer procesos para facilitar la comunicacion.
Un Frameworks de arquitectura debe incluir :
Informacion identicando el Frameworks de arquitectura
La identicacion de uno o mas intereses
La identicacion de uno o mas Stakeholder que tienen esos interes
Uno o mas puntos de vistas que muestran esos interes
Cualquier regla de correspondencia
Un Frameworks de arquitectura debera incluir condiciones de aplicabilidad.
Ejemplos:
Una descripcion de arquitectura (AD) usando un Frameworks de arqui-
tectura (AF) necesita identicar Stakeholder determinados que operan en
una jurisdiccion especca.
Una descripcion de arquitectura (AD) usando un Frameworks de arquitec-
tura (AF) puede omitir un punto de vista especicado cuando un interes
en particular no esta identicado
Usando un Frameworks de arquitectura (AF), un tipo de modelo, MK por
sus siglas en ingles puede ser omitido en un punto de vista determinado
para un Stakeholder especico
Algunos ejemplos de Frameworks de arquitectura son:
Zacman
MODAF (UK ministery defensy)
TOGAF
Kruchten (4+1)
Siemens 4
RM-ODP (ISO/IEC 10746)
GERAM (ISO 15704)
2.8. FRAMEWORKS DE ARQUITECTURA 15
2.8.1. Frameworks de proposito general -
Lo que diferencia a este tipo de Frameworks con respecto a otros, es que
tratan de resolver el problema general que las empresas estan teniendo. Estos
marcos son agnosticos a cualquier aplicacion especca. Ellos no tienen factores
especcos de negocio (empresa especca), sino mas bien son basados capacidad.
Estos marcos son generalmente impulsados por consorcios industriales como
Open Group. Como caracterastica principal, estos brindan un mayor nivel de
personalizacion con respecto a los de dominio especco
Entrega deniciones abiertas a traves de taxonomas y ontologas
Indiferente a la estructura de la organizacion
Indiferente a los procesos de bajo nivel (SDLC, PMO, Service Manage-
ment, etc )
Muy congurable a la empresa
2.8.2. Frameworks de dominio especco -
Estos Frameworks que se derivan de un esfuerzo de arquitectura empresarial
para un dominio especco. Estos marcos se obtuvieron a partir de un conjunto
predenido de intereses de un negocio especco en mente, ya que proceden de
una ocina de arquitectura empresarial o del esfuerzo de mejora de procesos de
un gobierno o de una empresa. En gran parte de estos marcos son impulsados por
las agencias gubernamentales como el gobierno de los EE.UU. u otras geografas.
Como caracterstica principal, estos brindan una mayor especicacion en guas
predenidas a seguir con respecto a los de proposito general
Guas prescriptivas para (estructura de la organizacion, procesos y arte-
factos)
Por lo general, ofrecen muchas plantillas
Muchos ejemplos del mundo real
Referencias [12] [8][5]
2.8.3. Tipicaci on de frameworks
Cuadro 2.1: Tipo de frameworks
Frameworks de proposito general Frameworks de dominio especco
TOGAF FEAF
Agile EA DODAF
Zachman MODAF
(TEAF)
16 CAP
Captulo 3
Descripcion ISO/IEC/IEEE
42010
La conformidad de la norma se dene bajo los siguientes aspectos:
Descripcion de arquitectura.
Artefacto, usado para describir una arquitectura.
Framework de arquitectura.
Convenciones, principios y practicas para descripcion de una arquitectura,
establecidos con un dominio de aplicacion y/o comunidad de Stakeholders.
Lenguajes de descripcion de arquitectura. Un ADL debe especicar :
La identicacion de 1 o mas interes a ser expresadas por ADL
La identicacion de 1 o mas Stakeholders que tiene esos interes
Tipos de modelos implementados por el ADL, los cuales muestran
los interes
Cualquier punto de vista
Un ADL no necesita proveer ning un punto de vista, este puede denir 1 o
mas tipos de modelo para usar en cualquier punto de vista que se dena.
Un ADL necesita proveer reglas de relacion relativos a los tipos de modelos
Puntos de vista de arquitectura.
Artefacto que establece las convenciones para la construccion, interpreta-
cion, y uso de vistas para presentar un interes especco del sistema.
[6]
17
18 CAP
ITULO 3. DESCRIPCI
ON ISO/IEC/IEEE 42010
Captulo 4
Situaci on actual de las
empresas bogotanas
La encuesta tuvo un total de 21 encuestados:
Figura 4.1: Rol desempe nado en la empresa
Se evidencia que la poblacion en su mayora son desarrolladores, pero lo mas
importante es que se tiene una poblacion diversa de Stakeholder.
Figura 4.2: Conoce que es un Stakeholder
19
20CAP
ITULO 4. SITUACI
ON ACTUAL DE LAS EMPRESAS BOGOTANAS

Se evidencia que en su mayora los encuestados reconocen a que se hace re-
ferencia cuando se habla de Stakeholder, lo cual facilita el entendimiento de la
norma.
Figura 4.3: Conoce que es un interes en el sistema por parte de un Stakeholder
Es claro para la mayora de los encuestados cuando se habla de interes de un
Stakeholder, lo que demuestra que se puede hablar correctamente de intereses
en el ambito de descripcion de arqauitectura de software.
Figura 4.4: En la descripcion de arquitectura identica Stakeholder
Se evidencia que un alto porcentaje de los encuestados en la descripcion de la
arquitectura identica los Stakeholder, lo cual nos demuestra que estan acordes
a las sugerencia de la norma.
En la descripcion de la arquitectura (AD) identica los intereses
que los diferentes Stakeholder tiene en el sistema.
Figura 4.5: En la descripcion de la arquitectura (AD) identica los intereses
que los diferentes Stakeholder tiene en el sistema
21
Los encuestados en su mayora logran identicar los diferentes Stakeholder
que tiene el sistema en la descripci on de la arquitectura, mostrando que se tiene
concordancia con las sugerencias de la norma.
Figura 4.6: Elementos de descripcion de arquitectura utiliza
Se evidencia que los elementos de descripcion mas utilizados por los encues-
tados son los Stakeholder, vistas, modelos de arquitectura y puntos de vista,
mostrando gran anidad con las sugerencias de la norma.
En que etapas del proceso de desarrollo de software realiza la
arquitectura de software?
Figura 4.7: Etapas del proceso de desarrollo de software realiza la arquitectura
de software
Se evidencia que para los encuestados la etapa de desarrollo de software en
la que se realiza la arquitectura de software es la de dise no con un 41 % y la
siguiente poblacion importante con un 33 % es la de que la arquitectura se realice
en todas las etapas, demostrando que no se tiene una certeza ambsoluta sobre
22CAP
ITULO 4. SITUACI

que la descripcion de arquitectura se da en todas las etapas del desarrollo de
softwre.
En la descripcion de arquitectura (AD) usted incluye puntos de
vista orientados a expresar el interes que los Stakeholder tienen en el
sistema?
Figura 4.8: En la descripcion de arquitectura (AD) usted incluye puntos de
vista orientados a expresar el interes que los Stakeholder tienen en el sistema
La mayora de los encuestados incluyen puntos de vista para la descripcion de
arquitectura, estando acorte con las sugerencias de la norma, pero se evidencia
que hay una poblacion considerable que no los incluye la cual necesita caer en
cuenta de la importancia de esto.
En las vistas que usted crea, utiliza mas de un punto de vista
para expresar los intereses que los Stakeholder tienen en el sistema?
Figura 4.9: En las vistas que usted crea, utiliza mas de un punto de vista para
expresar los intereses que los Stakeholder tienen en el sistema
La graca reeja una mayora con el 40 % que si usa mas de un punto de
vista en las vistas que usa, pero tambien encontramos una poblacion grande
que no usan esta posibilidad y un menor porcentaje que no sabe de que se esta
hablando, raticando la necesidad de plantear maneras mas faciles de expli-
car el funcionamiento de las vistas y puntos de vistas en la descripcion de la
arquitectura.
23
Que uso le da a la descripcion de arquitectura?
Figura 4.10: Que uso le da a la descripcion de arquitectura
Se encuentra que la descripcion de arquitectura se usa en mayor parte para las
actividades de desarrollo y el analisis, demostrando que se necesita conciencia
sobre otros usos como la documentacion o como entrada para la simulacion con
nuevas herramientas.
Cuales intereses utiliza en los puntos de vista?
Figura 4.11: Cuales intereses utiliza en los puntos de vista
En su mayora los intereses mas usados por los encuestados son la funcionali-
dad, la compactibilidad, la usabilidad, las caractersticas del sistema, la seguri-
dad y la modularidad, demostrando gran anidad con los atributos de calidad
denidos por la norma ISO IEC 25010.
24CAP
ITULO 4. SITUACI

Cuales de los siguientes elementos de descripcion de arquitectura
(AD) utiliza dentro de los puntos de vista?
Figura 4.12: Cuales de los siguientes elementos de descripcion de arquitectura
(AD) utiliza dentro de los puntos de vista
Se encuentra que el elemento mas usado por los encuestados para la descrip-
cion de arquitectura en los puntos de vista son los Stakeholder, dejando de lado
la importancia que tienen los intereses de estos mismos por los puntos de vista.
Que convenciones usa en los puntos de vista?
Figura 4.13: Que convenciones usa en los puntos de vista
Las convenciones m as usadas para los puntos de vista son los patrones y las
notaciones, demostrando que se dejan de lado convenciones dadas por los len-
guajes y la semantica los cuales tienen un importante consideracion por parte
de los autores.
25
Que uso le da a las convenciones en los puntos de vista?
Figura 4.14: Que uso le da a las convenciones en los puntos de vista
Seg un los encuestados el uso mas importante de las convenciones en los puntos
de vista es el uso de modelos concretos de un tipo de modelo.
Que tipos de modelo usa en los puntos de vista?
Figura 4.15: Que tipos de modelo usa en los puntos de vista
Los tipos de modelo mas usado por los encuestados en los puntos de vista
son el diagrama de clases y el diagrama de secuencia con un 24 % cada uno,
demostrando que los tipos de modelos mas populares son los que nos ofrece el
lenjuade de descripcion de arquitectura UML, dejando de la do los ofrecidos por
BPM y en menor porcentaje por archimate.
Que Lenguaje Descripcion de Arquitectura (ADL) utiliza para
describir la arquitectura del sistema?
26CAP
ITULO 4. SITUACI

Figura 4.16: Que Lenguaje Descripcion de Arquitectura (ADL) utiliza para
describir la arquitectura del sistema?
La mayora de los encuestados utiliza el lenguaje de descripcion de arqui-
tectura UML para describir la arquitectura de un sistema con un 38 %, dejando
de la do lenguajes como archimate o el mismo BPM.
Que importancia le da a expresar los intereses de los Stakeholder
por medio del ADL?
Figura 4.17: Que importancia le da a expresar los intereses de los Stakeholder
por medio del ADL?
Se evidencia que los encuestados no estan completamente seguros de la im-
portancia de describir los intereses de los Stakeholder.
Que tipos de modelo expresa con el Lenguaje de Descripcion de
Arquitectura (ADL) utilizado?
27
Figura 4.18: Que tipos de modelo expresa con el Lenguaje de Descripcion de
Arquitectura (ADL) utilizado?
Se encuentra que el 50 % de los encuestados expresa mayormente los tipos
de modelo sugeridos por UML, demostrando que en la industria estabolcada
por una preferencia apartando la posibilidad de utilizar nuevos tipos de modelo
como el archimate.
El ADL que utiliza le permite expresar las relaciones y reglas de
relacion entre los elementos de un modelo regido por unos puntos de
vista?
Figura 4.19: El ADL que utiliza le permite expresar las relaciones y reglas de
relacion entre los elementos de un modelo regido por unos puntos de vista?
Se evidencia que los encuestados no tienen claro que reglas de relacion dado
que en la pregunta anterior se encuentra que el ADL mas usado es UML y este
no tiene reglas de relacion denidas.
Que Framework de Arquitectura (Marco de Referencia de Arqui-
tectura) utiliza?
28CAP
ITULO 4. SITUACI

Figura 4.20: Que Framework de Arquitectura (Marco de Referencia de Arqui-
tectura) utiliza?
La mayora de los encuestados usa TOGAF para describir la arquitectura,
demostrando que se la mayoria de los frameworks usados son de tigo general.
El Framework de arquitectura que utiliza le permite identicar
los intereses que los diferentes Stakeholder tienen en el sistema?
Figura 4.21: El Framework de arquitectura que utiliza le permite identicar los
intereses que los diferentes Stakeholder tienen en el sistema?
Se evidencia que la mayora de los encuestados pueden identicar los Sta-
keholder por medio del Frameworks que utiliza con un 53 %, dejando un un
porcentaje grande insatisfecho con la forma en la que el framewors les permite
identicar los intereses de los Stakeholder.
Que relaciones puede identicar con el Framework de arquitec-
tura que utiliza en los puntos de vista descritos?
29
Figura 4.22: Que relaciones puede identicar con el Framework de arquitectura
que utiliza en los puntos de vista descritos?
Las relaciones mas utilizadas en los Frameworks que utilizan los encuestados
son la composicion y dependencia.
El Framework de arquitectura que utiliza le permite declarar re-
glas de correspondencia entre los elementos de los puntos de vista?
Figura 4.23: El Framework de arquitectura que utiliza le permite declarar reglas
de correspondencia entre los elementos de los puntos de vista?
Se encuentra que la mayora de los encuestados no puede declarar reglas de
correspondencia con los Frameworks que se utilizan o no se sabe lo que son las
reglas de correspondencia, demostrando la necesidad de facilitar el entendimien-
to de la descripcion de arquitectura.
Con que propositos usa o ha usado los Framework de Arquitec-
tura?
30CAP
ITULO 4. SITUACI

Figura 4.24: Con que propositos usa o ha usado los Framework de Arquitectura?
Se encuentra que la mayora de los encuestados con un 41 % usa los Frame-
works de arquitectura para la descripcion de arquitectura de software, lo cual es
dato positivo para el uso de la norma que se apoya en el uso de los Frameworks.
Captulo 5
Modelos para la descripcion
de una arquitectura basada
en la norma
ISO/IEC/IEEE-42010
La arquitectura tanto de software como empresarial, deben describirse co-
rrectamente, esta es la motivacion por la cual se estudia la norma ISO/IEEE/IEC
42010, como estandar internacional para la descripcion de arquitectura; lo men-
cionado anteriormente permite a los diferentes stakeholders de la ingenieria de
software, apoyarse en elementos que aseguran que dicha descripcion se realice
apoyada en el estandar permitiendo que esta sea entendible por todos aquellos
involucrados en el ambito de la arquitectura. Con el n de darle una explicacion
mas clara a dicha norma, se proponen modelos que contemplan los elementos
que se consideraron necesarios para que de una manera u otra el arquitecto,
entienda los diferentes elementos a tener en cuenta para una correcta descrip-
cion de arquitectura, y asi poder establecer una buena comunicacion con los
diferentes stakeholder que interactuan en un proyecto de arquitectura.Para ase-
gurar que la investigacion de campo suple los elementos necesarios para una
correcta descripcion de arquitectura, se realizo una investigacion de campo en
la cual se identicaron dichos elementos que no son conocidos por los diferentes
stakeholders en proyectos de ingenieria de software.
31
32CAP
ITULO5. MODELOS PARALADESCRIPCI
ONDE UNAARQUITECTURABASADAENLANORMAISO/IEC/IEEE-42010
5.1. Modelos para la descripcion de una arqui-
tectura basada en la norma ISO/IEC/IEEE-
42010
Con la constante automatizacion de procesos a traves de herramientas de las
Tecnologias de informacion (IT), los sistemas han dado un gran paso hacia el
futuro, dado esto, se promueven nuevas oportunidades para la industria como
para la Ingeniera de Software, permitiendo adoptar una norma que permita
tener un estandar y/u organizacion, la cual se adopta a partir del 2001.
La norma ISO/IEC/IEEE 42010 nace el 2 de agosto 2001, cuando ANSI
adopta la norma IEEE 1471 convirtiendola en la ANSI/IEEE 1471 como practi-
cas recomendadas para descripcion de arquitectura, convertida en norma para
sistemas software.Inicialmente nace como una propuesta para describir arqui-
tectura, a traves de las necesidades de los stakeholder, vistas, puntos de vista y
justicacion de la arquitectura.
Adoptar mejores practicas para aplicar en la industria se han convertido en
un factor vital, puesto que se incrementa la eciencia y ecacia para el desarrollo
de software, ahora bien, com unmente se encuentra con diferentes requerimien-
tos, tanto funcionales como no funcionales (atributos de calidad), diferentes Sta-
keholder, y diferentes tecnologas a utilizar para resolver un problema especco,
esto genera muchas inquietudes de como abordar un proyecto de arquitectura
y aunque se tienen muchos frameworks arquitectonicos, tampoco hay certeza
de cual se debe usar, causando muchas inquietudes a la hora de abordar un
requerimiento; todo este tipo de factores aunque son importantes a la hora de la
toma de decisiones no deben convertirse en un problema, debe abordarse de una
manera intuitiva y sencilla, permitiendo que se logre dar solucion a la verdadera
problematica.
Entrando en la norma ISO/IEC/42010, esta apoya la toma de decisiones en
la arquitectura, la norma presenta una postura holistica a la hora de hablar
de la arquitectura, permitiendo identicar cuales serian aquellos factores que
permiten denir la forma como se abordara la arquitectura, en este tipo de
proyectos. El lenguaje que se debe hablar debe ser com un entre los diferentes
stakeholder del proyecto, permitiendo una mejor comunicacion en los proyectos.
Para entender mejor la norma ISO/IEC/IEEE 42010, el artculo presenta la
decripcion, conclusiones y trabajos futuros, que permiten entender un poco mas
acerca de este tema y la aplicabilidad que tiene en el campo de la arquitectura
de software.
5.2. Descripcion de la norma ISO/IEC/IEEE-
42010
La arquitectura de software, se apoya en elementos fundamentales con el n
de que esta pueda ser descrita, esto comunmente es llamado descripcion de
arquitectura, para tener un estandar internacional, ISO denio una norma
5.2. DESCRIPCI
ON DE LA NORMA ISO/IEC/IEEE-42010 33
correspondiente a identicar todos aquellos aspectos que deben ser tenidos en
cuenta, a la hora de elaborar una descripcion de arquitectura.
Dentro de los elementos que deben tenerse en cuenta para la descripcion
de arquitectura se encuentran estilos arquitectonicos, frameworks, patrones ar-
quitectura, diagramas, notaciones, elementos, restricciones de dise no las cuales
son fundamentales para describir o elaborar la estructura de un sistema; la ar-
quitectura debe ser representada o escrita en los terminos en los que desea ser
explicada, aquello que es parte de ella y la forma como se relaciona con otras
arquitecturas, este estandar internacional permite denir la forma como se des-
cribe la arquitectura, indicando 4 puntos de conformidad dentro de ella, estos
son: descripcion de arquitectura, puntos de vista, framework de arquitectura y
lenguaje de descripcion de arquitectura, estos puntos son necesarios a la hora
de abordar un proyecto de software y denir la arquitectura.
Constantemente los arquitectos se encuentran con decisiones de dise no que
impactaran el sistema, no obstante se debe tomar la decision correcta para
describir la arquitectura, y esto es importante dado que no se puede cambiar
constantemente la arquitectura.
Cada requerimiento, necesita un analisis respectivo, esto es: Identinticar
los intereses que tienen los stakeholder sobre el sistema, vericar si existe un
framework de arquitectura, en cuantas vistas deberia describirse el sistema las
cuales son gobernadas por los puntos de vista, adicionalmente las reglas de
correspondencia o restricciones que se deben tener en cuenta para la elaboracion.
Al hacerse un uso indebido de la descripcion de arquitectura, implica que
se represente incorrectamente el sistema, haciendo que este sea poco entendible
para los diferentes stakeholder, adicional a ello se convierte en un factor para la
mala comunicacion entre los diferentes involucrados (Analistas, Desarrolladores,
Arquitectos, Tester) causando problemas mas grandes con respecto al proceso
de desarrollo de Software.
Para brindar mecanismos de comunicacion correctos en los proyectos de soft-
ware, se hace necesario utilizar un lenguaje, este es determinante para establecer
la comunicacion entre los diferentes stakeholder; para ello se debe identicar cual
lenguaje contiene todos los elementos necesarios para una correcta descripcion
de la arquitectura, entre ellos existen UML, Archimate, Rapide, SysMl, BPMN,
entre otros, los lenguajes anteriores permiten una correcta comunicacion entre
los diferentes stakeholder. La iconograa y la relacion que pueden existir entre
ellos permite representar un sistema, dandole estructura, y caracterizacion de la
forma como debe construirse, esto corresponde a la descripcion de arquitectura
que a su vez cubre las necesidades de un grupo de Stakeholders.
Com unmente se encuentra en algunos dise nos o interpretaciones que aunque
se vean atractivos y agradables, no signica que estos describan correctamente
una arquitectura, dado que no se usa un lenguaje de descripcion de arquitectura
(ADL), para que este sea considerado un modelo se hace necesario que cumpla
con unas especicaciones y restricciones establecidas en un tipo de modelo,
el cual debe pertenecer a un ADL especico, cuando sucede lo mencionado
34CAP
anterirormente, corresponde a un ADL especicado por la persona que creo el
modelo.Para que un tipo de modelo sea considerado como tal se deben tener en
cuenta los siguientes elementos: Entidades,Atributos, Relaciones, Restricciones.
Para que un ADL sea considerado como tal se deben tener en cuenta los
siguientes elementos: especicar la identicacion de los intereses en el siste-
ma,Tipos de modelo, Puntos de Vista
En la descripcion de arquitectura se deben contemplar vistas, las cuales
permiten denir un contexto de interpretacion que normalmente tiene cabida
dentro de uno de los intereses de los stakeholder, por ejemplo: cuando se requiere
que funcionalmente se entienda su estructura, se debe contemplar una vista que
represente las funciones del sistema, y para ello se debe tomar una vista que
represente dicho interes.
5.3. Modelos Propuestos
Con la nalidad de darle una interpretacion, a la norma ISO/IEC/IEEE-
42010 y ver la aplicabilidad de la arquitectura, se proponen los siguientes mode-
los que permiten entender mejor la forma como debe describirse la arquitectura,
as como entender el proposito y nalidad que esta representa.
Basados en la norma ISO/IEC/IEEE-42010, para el proceso de descripcion
de arquitectura se hace necesario identicar los Stakeholders, un ejemplo de estos
son: Usuario Final, Arquitectos, Gerentes de Proyecto, Gerente Operacional,
Desarrolladores entre otros multiples roles que pueden intervenir en desiciones
de arquitectura. Se debe tener en cuenta que para cada proyecto de arquitectura,
se deben identicar aquellos involucrados al igual que sus puntos de vista sobre
el sistema, esto dado que es requerido identicar aquellas necesidades relevantes
del proyecto.
Figura 5.1: Proceso para identicacion de Stakeholders
A traves del anterior diagrama de procesos se le brinda al arquitecto la forma
en la cual puede identicar los stakeholder y todo lo que esta inmerso en ellos,
5.3. MODELOS PROPUESTOS 35
con el n de poder aplicar de una forma correcta la arquitectura, seg un la norma
ISO/IEC/IEEE 42010.
Architect: Arquitecto Empresarial/Software, que se encuentra implicado
en el proyecto, y requiere describir la arquitectura seg un corresponda su
rol, o funciones especicas.
Identify Project: Ubicacion espacial, nombre de proyecto, objetivos del
mismo.
Ask for information the organizational viewpointpoint: Identicar
todos los elementos para construir un diagrama organizacional, que per-
mita ubicar casos de escalamiento, al igual que responsables por cada uno
de los temas a realizar dentro del proyecto.
Identify Expectations: Identicar, las expectativas de los involucrados
del proyecto, identicar que requieren ellos realizar para as identicar cual
sera la mejor forma de representarlo.
Prioritize the Importance of Stakeholder: Permite darle la impor-
tancia a cada uno de los Stakeholder, esto con el n de saber si su criterio
se hace importante para la descripcion de arquitectura, estos pueden ser
de dos niveles:
Stakeholder First Level: Son aquellos que tienen relevancia, a la
construccion de la arquitectura.
Stakeholder Second Level: Son aquellos Stakeholder que se hacen
importantes para la descripcion de la arquitectura, sin embargo debe vali-
darse si con los Stakeholder de primer nivel se hace necesario la inclusion
de este Stakeholder como importante, al igual que su criterio.
En el diagrama anterior se identica una actividad como Organizational
Viewpoint, esta actividad corresponde a realizar un diagrama de la organiza-
cion para la cual se realiza la descripcion de arquitectura, esto normalmente
corresponde a un grupo de Stakeholder, con sus respectivos cargos dentro de
la organizacion. Las estructuras de las empresas de TI, normalmente encajan
dentro del siguiente modelo Organizacional:
Project Manager: Corresponde a todos aquellos responsables del pro-
yecto, la direccion del proyecto se encuentra dentro de este Stakeholder.
Las organizaciones contienen dos grandes areas, las cuales corresponden a
la Tecnica y a la Funcional:
Technical: Corresponde a la parte encargada de orientar a la organizacion
con todos los elementos tecnologicos para apoyar los procesos organizacio-
nales, automatizacion y apoyo a la gestion de la informacion a traves de
Software.
36CAP
Functional: Corresponde a la parte encargada de orientar correctamente
el funcionamiento de los procesos organizacionales, al igual que conocer
correctamente el negocio e identicar todos aquellos elementos que apoyan
a la misma para ir de la mano con los objetivos estrategicos de la compa na.
Architecture: Este corresponde a un arquitecto de negocio, que se en-
carga de apoyar los procesos y mejoras de los mismos en el area funcional,
tambien puede ser un arquitecto empresarial.
Developer: Corresponde a una persona o grupo de personas que se encar-
gan de realizar la Construccion del Software Requerido por la Compa na.
Analist: Corresponde a aquellos Stakeholder que conocen las funciones
del negocio al igual que la forma como debe ser representado.
Quality Analist: Son los Stakeholder encargados de asegurar la ca-
lidad del producto.
Requirements: Son aquellos Stakeholder que realizan y apoyan el
entendimiento de los requerimientos de negocio, a nivel funcional.
Figura 5.2: Modelo Organizacional, general a compa nas de TI
Para entender un poco mas cual es la forma como dichos se debe representar
los intereses de los anteriores Stakeholder sobre el sistema se identica a detalle
los roles de los mismos permitiendo entender como operan en la descripcion de
arquitectura (AD).
Figura 5.3: Funciones de los roles
La forma como se relacionan los diferentes Stakeholder con el n de describir
correctamente la arquitectura se identica de la siguiente manera:
38CAP
Figura 5.4: Cooperacion entre roles para la descripcion de Arquitectura
El area funcional, coopera con el area tecnica, realizando levantamiento
de requerimientos, esto se transmite en casos de uso de las funcionalidades,
o procesos de negocio, apoyando al rol de arquitectura, para identicacion de
algunos intereses de los stakeholder.
Para identicar todos aquellos intereses de los Stakeholder que se identica-
ron en el proceso anterior (graca.2) se debe realizar el proceso de identicacion
de intereses de estos sobre el sistema, para ello se proporciona el siguiente pro-
ceso:
Figura 5.5: Cooperacion entre roles para la descripcion de Arquitectura
Funcionalidad: Capacidad del producto software para proporcionar fun-
ciones que satisfagan las necesidades especicadas e implcitas.
Fiabilidad: capacidad del producto software para mantener un nivel espe-
cicado de rendimiento.
Usabilidad: la capacidad del producto software de ser entendido, aprendido,
utilizado y atractivo al usuario.
Eciencia: la capacidad del producto software para proporcionar el rendi-
miento apropiado, relativo a la cantidad de recursos utilizados.
Mantenibilidad: la capacidad del producto software para ser modicado.
Las modicaciones pueden incluir correcciones, mejoras o adaptacion del softwa-
re a cambios en el entorno, en los requisitos o en las especicaciones funcionales.
Portabilidad: la capacidad del producto software de ser transferido de un
entorno a otro.
Para describir correctamente la norma ISO/IEC/IEEE42010, proponemos el
siguiente diagrama de procesos, de la vista de negocio de archimate. Donde el
arquitecto debe realizar los siguientes pasos:
Figura 5.6: Proceso descripcion de arquitectura, identicacion Framework, vista,
ADLs, puntos de vista
Identicar Framework: Esto corresponde, a la tarea de vericar cual co-
rresponde al framework que mas se acomoda a las necesidades de los stakeholder
identicadas en el proceso 1.1, este debe cumplir especcamente la forma como
debe describirse la arquitectura.
40CAP
Figura 5.7: Identicacion de aplicaciones a construir y a proponer en modelos
de arquitectura
Proponer vistas: Esto corresponde, a la tarea de proponer o identicar las
vistas necesarias que suplen la descripcion de arquitectura, esto corresponde a
proponer cuales utilizar de un framework. Identicar ADLs: Esto corresponde,
a identicar el lenguaje para la descripcion de arquitectura.
Figura 5.8: Identicacion de ADL de descripcion de arquitectura
Identicar Puntos de Vista: Es necesario identicar los puntos de vista, estos
estan limitados al lenguaje, permitiendo hacer uso de uno o muchos puntos de
vista para describir la arquitectura.
El arquitecto debe apoyarse en diferentes elementos que le permiten en la
descripcion de arquitectura ser identicadas, con el n de usarlas o integrarlas
con el sistema a describir.
Figura 5.9: Modelo Archimate Norma ISO/IEEE/IEC 42010
En la descripcion de arquitectura, es necesario identicar todos aquellos ele-
mentos que se deben describir concretamente en la arquitectura, este correspon-
de a arquitectura de software o arquitectura empresarial, en los cuales se debe
describir la aplicacion como debe construirse, esto es representado con puntos
de vista especcos de un ADL.
Todo lo mencionado anteriormente se deduce en el modelo propuesto en la
gura 10:
42CAP
Figura 5.10: Modelo Archimate Norma ISO/IEEE/IEC 42010
5.4. Trabajo Por Realizar
Realizacion de un gu
Aa para la elaboracion de arquitectura.

Realizacion de auditoria a la industria Colombiana del Software con el
n de tomar medidas al respecto de la forma como se esta haciendo la
descripcion de la arquitectura.
Creacion de un libro interactivo con la descripcion de la norma.
Apendice A
Traduccion de la norma
ISO/IEC/IEEE 42010
A.1. Introduccion
La norma especca la manera en que la descripcion de arquitectura organiza
y expresa los sistemas.
Especca puntos de vista, frameworks de Arquitectura, y ADL para usar
en la descripcion de arquitectura.
Provee motivacion para terminos y conceptos de uso; presenta guas para la
especicacion de puntos de vista.
muestra el uso de este estandar en compa nia de otros estandares.
Cubre cuatro aspectos para conformidad de la descripcion de arquitectura
(AD):
Descricion de arquitectura (AD)
Puntos de vista
Framework de arquitectura
Lenguajes de descripcion de arquitectura (ADL)
A.1.1. Deniciones encontradas en la norma
Realizar Arquitectura
Proceso de concebir, denir, expresar, documentar, comunicar, certicar la
propia implementacion, mantener y mejorar una arquitectura durante el ciclo
de vida de un sistema. Se puede hacer arquitectura de dos formas:
En una organizacion (persona o grupo con responsabilidades, autoridad y
relaciones)
43
44 AP
ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

A un proyecto (desarrollo con inicio, n y el compromiso de cumplir con
unos requerimientos).
Arquitectura
Conceptos fundamentales o propiedades, relaciones, principios de dise no y
evolucion de un sistema en un entorno determinado.
Descripcion de arquitectura
Artefacto, usado para describir una arquitectura.
Framework de arquitectura
Convenciones, principios y practicas para descripcion de una arquitectura,
establecidos con un dominio de aplicacion y/o comunidad de Stakeholders.
GERAM (ISO 15704)
RM-ODP (ISO 10746)
Vista de arquitectura
Artefacto que expresa la arquitectura de un sistema desde la perspectiva de
un interes especco.
Punto de vista de arquitectura
Artefacto que establece las convenciones para la construccion, interpretacion,
y uso de vistas para presentar un interes especco del sistema.
Interes
Interes relevante en un sistema de parte de uno o mas de los Stakeholders.
Un interes corresponde a cualquier inuencia de un sistema en el entorno, inclu-
yendo, desarrollo, tecnologico, de negocio, operacional, organizacional, polotico,
economico, legal, regulatorio, ecologico y social.
Entorno
Contexto que determina la conguracion y las circunstancias de toda inuen-
cia sobre el sistema. el entorno de un sistema incluye inuencias de tipo desa-
rrollo, tecnologico, de negocio, operacional, organizacional, polotico, economico,
legal, regulatorio, ecologico y social.
Tipo de modelo
Convenciones para un tipo de modelo. Ej de tipo de modelo son: diagramas
de ujo, diagramas de clase, redes de petri, balances, organigramas y modelos
de estado de transicion.
A.1. INTRODUCCI
ON 45
Stakeholders
Individuo, equipo y/u organizaciones o clases de estos que tengan un interes
en el sistema.
A.1.2. Conceptos encontrados en la norma
Sistema
Sera entendido como es descrito en la norma ISO/IEC 15288.
Sistemas que son construidos por hombres y que pueden ser
congurados con uno o mas de los siguientes: hardware, software,
datos, humanos, procesos, (ej. proveer servicios al usuario),
procedimientos (ej. instrucciones del operador), facilidades,
materiales y entidades que ocurren naturalmente.
Productos de software y servicios
Como se describen en ISO 12207
Aplicaciones de software
Como se describe en ISO 1471:2000
C ualquier sistema donde el software constituya inuencia esencial
en el dise no, construccion, despliegue y evolucion del sistema de
manera holstica (como un todo); para abarcar aplicaciones
individuales, sistemas en el sentido tradicional, subsistemas,
sistemas de sistemas, lneas de producto, familias de productos,
toda empresa, y otras agregaciones de interes
Como se indica en la ISO 15288:2008. Un sistema es una combinacion de
interacciones entre elementos organizados para lograr un proposito.
Un sistema esta situado en un entorno. El entorno determina la totalidad de
l inuencia sobre el sistema durante el ciclo de vida, incluyendo las interacciones
con el entorno. El entorno de un sistema puede contener otros sistemas.
Para propositos de la norma el entorno es limitado por y entendido a traves
de la identicacion de los Stakeholders y sus intereses.
la arquitectura de un sistema indica que es esencial con respecto al sistema
considerado en relacion a un entorno. La caracterizacion de un sistema puede
pertenecer a:
elementos del sistema
como estan organizados e interrelacionados estos elementos
principios de la organizacion y/o dise no del sistema
principios de gobernabilidad e la evolucion en el ciclo de vida del sistema
46 AP

la AD es usada para expresar la Arquitectura de un sistema
Un sistema puede ser descrito por muchas arquitecturas diferentes (ej. Cuan-
do se considera en diferentes entornos), as como una arquitectura puede ser
expresada utilizando muchas AD diferentes (Ej. cuando diferentes frameworks
de Arq son utilizados), por otro lado, la misma arquitectura puede caracterizar
mas de un sistema (Ej. una familia de sistemas compartiendo la misma Arq.)
Arquitectura y AD
AD son artefactos de arquitectura SW y arquitectura de sistemas. En la
norma no se describe el proceso a ser usado para producir una AD. No se asume
o prescribe metodos, notaciones, o tecnicas usadas para product AD.
modelo de arquitectura
Es una instancia de un tipo de modelo
Una vista de arquitectura es compuesta por uno mas modelos de arquitec-
tura.un modelo usa convenciones de modelado apropiadas para el interes abar-
cado, estas convenciones son especcas para el tipo de modelo que gobierna ese
modelo.
En una descripcion de arquitectura un modelo de arquitectura puede ser
parte de mas de una vista.
Stakeholders e intereses
los Stakeholders tienen interes respecto al sistema considerado en el entorno.
un interes puede ser contemplado por uno o mas Stakeholders. los intereses
surgen durante todo el ciclo de vida de las necesidades y requerimientos del
sistema, elecciones de dise no, implementacion y consideraciones de operacion
Vistas y puntos de vista
una AD incluye uno o mas vistas de arquitectura. Vista aborda uno o mas
interes de los Stakeholder del sistema
una vista expresa la arquitectura del sistema en relacion con un punto de
vista.
Dos aspectos de puntos de vistas son los intereses son mostrados a los Sta-
keholders y los convenciones son establecidas en las vistas.
Un punto de vista muestra uno o mas intereses
un interes puede ser mostrado por mas de un punto de vista
una vista es gobernada por puntos de vista: el punto de vista establece con-
venciones para la construccion interpretacion y analisis de visitas, contemplando
intereses mostrados por ese punto de vista punto convenciones de punto de vista
pueden incluir lenguajes notaciones tipos de modelo reglas de dise no y metodos
de modelado tecnicas de analisis y otras operaciones en vista. la norma no usa
frases como arquitectura de negocio arquitectura fsica o arquitectura tecnica
A.1. INTRODUCCI
ON 47
en terminos de esta norma la arquitectura de un sistema es holostica. en vez de
eso se usan frases como vista de negocio vista fsica vista tecnica.
Descripcion de arquitectura elementos y correspondencia
Son las mnimas unidades de actividades en el estandar y son cualquier
construido en una excepcion de arquitectura.
Todo eStakeholder, intereses, puntos de vista, vista, tipo de modelo, modelo,
decision y justicacion de arquitecturas son consideradas elementos de arquitec-
tura.
cuando dos puntos de vista y tipos de modelo son denidos y esto son
llenados es decir completados, los elementos de descripcion de arquitectura
son introducidos.
una correspondencia dene la relacion entre elemento denicion de arqui-
tectura. una correspondencia es usada para expresar relaciones de arqui-
tectura de los intereses en una exposicion de arquitectura oltre descrip-
ciones de arquitecturas.
las correspondencias puede ser gobernada por reglas de correspondencia
ejemplos de composicion consecuencia trazabilidad dependencia restric-
cion y obligatoriedad.
decisiones de arquitectura justicacion
Justicacion de las necesidades tomadas pueden incluir la base para la
decision alternativas y consecuencias consideradas si t? has anyone de
fuentes join formacion adicional.
decisiones penitentes a los intereses.
una decision puede afectar la arquitectura en diferentes aspectos se pueden
reejar en descripcion de arquitectura como:
requiriendo las existencias de elementos que es pura.
combinando las propiedades del mp version de arquitectura.
disparadores de analisis de negocio en relacion algunos elementos de
arquitectura coma incluyendo otras decisiones e intereses son revisados
levantamiento de nuevos intereses.
arquitectura en el ciclo de vida
La arquitectura contribuye al desarrollo y operacion y mantenimiento desde
la concepcion inicial hasta la puesta en uso. arquitectura toma lugar en el con-
texto y el proyecto u organizacion. arquitectura ejercida sobre todo y no solo en
una etapa del ciclo de vida . denicion de arquitectura el producto resultado de
48 AP

varias actividades en un producto. alternativamente puede ser la agregacion de
otros productos de trabajo del ciclo de vida.
La norma no depende asume o pre establece un ciclo de vida en particular.
Distintos procesos del ciclo de vida para el dise no de arquitectura.
Usos de la excepcion de arquitectura.
USO de la descripcion de arquitectura
Los usos incluyen pero no estan limitados a :
bases para dise no del sistema de actividades de desarrollo.
bases para analizar y evaluar implementaciones alternativas de una arqui-
tectura.
desarrollar y mantener una documentacion.
documentacion de aspectos esenciales del sistema como:
Entorno y uso previsto.
Principios supuestos y restricciones para guiar futuros cambios.
Puntos de exibilidad limitaciones del sistema con respecto a cambios
futuros.
Decisiones de arquitectura sus decisiones e impactos.
como entradas para herramientas de simulacion de sistemas de generacion
y analisis.
especicar un grupo de sistemas que comparten caractersticas comunes
entre parentesis con estilos de arquitectura de referencia arquitecturas de
lneas de produccion.
comunicacion entre las partes involucradas en los desarrollos produccion
despliegue operacion y mantenimiento del sistema.
bases para la preparacion de adquisicion de documentos (solicitudes para
propuestas y sentencias de trabajo).
comunicacion entre clientes y adquirentes proveedores y desarrolladores
que hacen parte del control de negociacion.
documentacion de caractersticas propiedades y dise no de un sistema para
clientes potenciales adquisidores, propietarios operadores integradores.
planeacion para la transicion de una arquitectura legado a una nueva ar-
quitectura.
como quiera para la operacion y soporte de infraestructura y administra-
cion de conguracion.
A.1. INTRODUCCI
ON 49
como soporte a la planeacion del sistema la programacion y presupuesta-
cion.
establecer criterios de aceptacion para la especicacion de implementacion
de una arquitectura.
como mecanismos de adaptacion para externos y proyectos o polticas
internas de la organizacion ejemplo legislacion principios generales de ar-
quitectura.
bases para la revisin analisis y evaluacion de sistemas entre su ciclo de
vida.
bases para el analisis y evaluacion de arquitecturas alternativas.
compartir lecciones aprendidas y revisar conocimientos de arquitectura
como puntos de vista patrones y estilos.
entrenamiento y educacion de Stakeholders y otras partes sobre mejores
practicas en arquitectura y evaluacion del sistema.
Frameworks de arquitectura y ADLs
Son mecanismos muy usados en arquitectura un framework de arquitectura
establece practicas comunes para la creacion e interpretacion analisis y uso de
have con un dominio particular de aplicacion o comunidad estoy soltera
Los usos de framework de arquitectura incluyen pero no se limitan creacion
de la descripcion de la arquitectura.
Desarrollo de herramientas de modelado de arquitectura y metodos de ar-
quitectura y establecer procesos para facilitar la comunicacion compromisos de
interpretacion a traves de m ultiples proyectos y/o organizacion ejemplos:
Zacman
MODAF (UK ministery defensy)
TOGAF
Kruchten (4+1)
Siemens 4
RM-ODP
ISO/IEC 10746
ISO 15704
50 AP

Un ADL es cualquier forma de expresion para uso en descripcion de arquitectura.
Un ADL provee uno o mas tipos de modelos que sirva para mostrar los
intereses a una audiencia de este. se puede ser estrechamente enfocado con unico
tipo de modelo extensamente enfocado para viendo muchos tipos de modelo
opcionalmente organizado en puntos de vista ademas un ADL soportado por
herramientas para el apoyo de la creacion y uso y analisis de estos modelos
ejemplos:
Rapide
Wright
SysML
Archimade
ISO 10746 (View point of RM-ODP)
A.2. Descripcion de la arquitectura
A.2.1. Introduccion
Identicacion de arquitecto descripcion de la arquitectura e informacion ge-
neral l identicacion de los Stakeholders del sistema y sus intereses una denicion
para cada punto de vista de la arquitectura usado en la descripcion de arquitec-
tura una vista de arquitectura y modelos de arquitectura para cada punto de
vista usado.
Reglas de relaciones aplicadas en la edicion de arquitectura relaciones en
la sesion del tura y registros de inconsistencias conocidas en el contenido obli-
gatorio de la descripcion de arquitectura Justicacion para las decisiones de
arquitectura
A.2.2. Identicaci on e informacion general
Se debe identicar el sistema y brindar informacion general que el proyecto
y organizacion requieran. Ejemplos:
Fecha de pendiente siete y estados
Autores
Revisores
Autoridad de aprobacion
Historial de cambios
resumen
alcance
A.2. DESCRIPCI
ON DE LA ARQUITECTURA 51
contexto
glosario
informacion de control de versiones
administracion de la conguracion
referencias
Los resultados de cualquier evaluacion de arquitectura o descripcion de ar-
quitectura deben ser incluidos
la norma no describe:
La granuladad de intereses
como los intereses se interrelacionan con otros interees
Relacionar un interesa otras declaraciones del sistema como : las nece-
sidades de los Stakeholders, los objetivos del sistema, los objetivos del
sistema o requerimientos del sistema. Esto es tema de los frameworks de
arquitectura, metodos de arquitectura y otras practicas y otras practicas
Puntos de vista de arquitectura
Una AD debe incluir cada punto de vista usado.
Cada interes identicado se debe mostrar por lo menos en un punto de vista
A.2.3. Vistas de arquitectura
Una AD debe incluir exactamente una vista por cada punto de vista usado
Cada vista se debe adherir a las convenciones que la gobiernan por el punto de
vista Cada vista debe incluir:
identicar y entregar informacion especca para el proyecto y/o organi-
zacion
Identicar el punto de vista que la gobierna
Modelos de arquietctura que direccionan todos los interesas mostrados por
le punto de vista que la gobirna y cubirr el sistemaamcaldo de ese punto
de vista
Registrar todos los pendientes de una vista con respecto al punto de vista
que la gobierna
52 AP

A.2.4. Identicacion de Stakeholders e interes
Los interes de los Stakeholders estan sobre el sistema o sobre la arqitectura.
Ejemplos de Stakeholders son:
Usuarios
Operadores
Adquirientes
Propietarios
Proveedores
desarrolladores
Constructores
mantenedores
Algunos ejemplos de los interes son:
El efecto del sistema
La idoneidad de la arquitectura para conseguir el proposito del sistema
la factibilidad de construccion y desarrollo del sistema
lo riesgos potenciales e impactos del sistema para estos Stakeholders du-
rante el ciclo de vida
mantenibilidad del sistema
se debe identicar cada interes con cada Stakeholders con el que tenga interes.
En general esta asociacion es de muchos a muchos
Es importante determinar la ubicacion de un interes en la AD, Para esto es
fundamental mostrar completamente el sistema un interes en un de vista desde
el punto de vista que los gobierna. En una vista 1 o mas modelos de arquitectura
pueden ser usados para presentar selectivamente porciones del sistema acorde a
los puntos de interes sin violentar los requerimientos.
Pendientes conocidos incluyen:
Pendientes para resolver (Pueden llevar a toma de decisiones)
Excepciones
Desviaciones de las convenciones (Pueden ser documentos como desiciones
tomadas y su justicacion)
Una AD puede contener informacion que no hace parte de ninguna vista. Ejem-
plos de esto son:
descripcion general
Ejemplo Modelos de relaciones
Justicacion de la arquitectura
A.2. DESCRIPCI
A.2.5. Modelos de arquitectura
Una vista debe estar compuesta por 1 o mas modelos de arquitectura. Cada
modelo debe contener identicaci on de version como los especica el proyecto
y/o organizacion. Cada modelo debe identicar el tipo de modelo que lo gobierna
y adherirse a las convenciones de ese tipo de modelo. Un modelo puede ser parte
de mas de una vista
Compartir: modelos de arquitectura entre vistas permite a una AD mostrar
diferentes pero relacionados intereses sin redundar o repetir la misma informa-
cion en m ultiples vistas y reducir las posibilidades de inconsistencias. COm-
partiendo modelos de arquitectura tambien permitimos un estilo orientado a
aspectos de AD.
Modelos de arquitectura compartidas a traves de las vistas pueden ser usado
para representar perspectivas/texturas de arquitectura Modelos de arquitectura
usarse como contenedorespara aplicar patrones de arquitectura o estilos para
expresar esquemas de arquitectura o estilos para expresar esquemas fundamen-
tales (capas, niveles p2p,) en las vistas
A.2.6. Reglas de relaciones
Una AD debe incluir cada regla de correspondencia que aplique a esta. Una
regla de correspondencia puede ser originada en la AD, Framework, punto de
vista o ADL. En caso de una regla de correspondencia identicada violada se
debe registrar, es decir, se deben registrar todas y cada una de las violaciones o
todas y cada una de las reglas de AD identicadas EN la norma las relaciones
son compatibles con las vistas de relacion de las normas ISO/IEC 10746 y 19793
A.2.7. Justicacion de la arquitectura
Registro de la Justicacion
Una AD debe tener una Justicacion para cada punto de vista en terminos
de Stakeholders, intereses, tipos de modelos, notacion y metodos. Una AD debe
tener una Justicacion para cada decision de una arquitectura clave. Una AD
debe tener evidencia de consideracion alternativas para las decisiones tomadas
A.2.8. Relacion de arquitectura
Consistencia en una AD
Una AD debe registrar toda inconsistencia conocida entre los modelos de
arquitectura y sus vistas iestras una AD consistente es preferida, esta muchas
veces es inviable o impractica para resolver todas las inconsistencias por razones
de tiempo, esfuerzo o informacion insucientes. Estas situaciones las inconsis-
tencias conocidas son registradas.
Una Ad podria incluir un analisis de consistencia de los modelos y sus vistas
Relaciones y reglas de correspondencia pueden ser usadas para expresar, regis-
54 AP

trar, reforzar y analizar coherencias entre modelos, vistas y otros elementos de
AD en una AD
Relacion
Cada relacion debe ser identicada e identicar sus elementos AD. Cada
relacion de be identicar la regla de correspondencia que la gobierna. Se puede
relacionar un elemento de AD con el mismo. Para registrar una decision de debe
considerar lo siguiente:
La decision tiene un identicador unico
La decision es estetica
La decision esta relacionada a interes del sistema y sus pertenencias
El propietario de la decision es identicado
La decision es relacionada a los elementos de AD afectados por la decision
Relacionada con la justiacion
SOn identicados las restricciones y supuestos que inuyen en la decision
ALternativas que fueron consideradas y sustanciales consecuencias
Consecuencias de la decision (relacionas a otra desiciones) son registradas
Marcas de tiempo cuando la decision fue echa, aprobada, y cambiada
citaciones de fuentes de informacion adicional
Esto puede ser usado para el registro de alternativas rechazaDAS Y LA
Justicacion de estos rechazos. tambien puede ser usado en caso de que esas de-
cisiones tengan que ser consideradas Puede ser usado para relacionar decisiones
de arquitectura. Ejemplo:
Restricciones
Inuencias
disponibles
disparadores
renamiento
conictos con...
compatibles con...
A.2. DESCRIPCI
A.2.9. Registro de decisiones
Una AD debe llevar un registro de las decisiones claves tomadas. No es
practico registrar todas la decisiones tomadas. Se deben establecer criterios para
registrar decision claves. Criterios a considerar son:
Decisiones sobre requerimientos arquitectonicamente importantes
Decisiones que necesiten una mayor inversion de tiempo para ejecutarse,
implementarse o hacer cumplir
Decisiones que afecten Stakeholder claves o un n umero de estos
decision que son altamente sensitivas a cambios
decision que pueden costar para ser cambiadas
decision que son base para la planeacion de proyecto y administracion de
proyecto. Ejemplo:
Estructura de descomposicion de trabajo
Seguimiento de calidad
decision que resultan en gasto de capital o costos indirectos
Un AF debe establecer consistencia con el modelo conceptual. El requeri-
miento puede ser conocido a traves de un metamodelo, un mapeo de un AF
construyendo el modelo, una narrativa de texto o de alguna otra manera.
A.2.10. Adherencia de una AD y un AF
Una AD se adhiere a un AF cuando:
Cada Stakeholder que aplique, identicado en el AF ha sido considerado
e identicado en el AD
Cada interes aplicable, identicado en el AF ha sifo considerado en la AD
Cada punto de vista especicado por el AF es incluido en la AD
Cada regla de correspondencia especicada por el AF es incluida en la AD
la AD cumple con los requerimientos de especicados en esta norma
Un AF puede aplicar reglas adicionales para la adherencia
Una AD puede estar adherida a mas de un AF, pero tiene que haber
reconciliacion entre cada AF respecto a los elementos de AD
56 AP

A.3. Frameworks de arquitectura y ADLs
A.3.1. Frameworks de arquitectura
Un framework de arquitectura debe incluir :
informacion identicando el framework de arquitectura
La identicacion de 1 o mas intereses
La identicacion de 1 mas Stakeholders que tiene esos interes
Uno o mas puntos de vistas que muestran esos interes
Cualquier regla de relacion
Un framework de arquitectura debera incluir condiciones de aplicabilidad. Ejem-
plos:
Un AD usando un AF necesita identicar Stakeholders determinados que
operan en una jurisdiccion especca
Un AD usa un AF puede omitir un punto de vista especicado cuando un
interes en particular no esta identicado
Usando un AF, un tipo de modelo, MK por sus siglas en ingles puede ser
omitido en un punto de vista V2 para un determinado Stakeholder
A.3.2. Lenguajes de descripci on de arquitectura
Un ADL debe especicar :
La identicacion de 1o mas interes a ser expresadas por ADL
La identicacion de 1 o mas Stakeholders que tiene esos interes
Tipos de modelos implementados por el ADL, los cuales muestran los
interes
Cualquier punto de vista
Un ADL no necesita proveer ning un punto de vista, este puede denir 1 o
mas tipos de modelo para usar en cualquier punto de vista que se dena. Un
ADL necesita proveer reglas de relacion relativos a los tipos de modelos
A.4. Puntos de vista de arquitectura
Un punto de vista debe especicar:
Uno o mas intereses mostrados por este punto de vista
Stakeholder tpicos que tiene esos intereses
A.5. ANEXO A 57
Uno o mas tipos de modelo usado en los puntos de vista
Para cada uno de esos tipos del modelo tener loslenguajes . metodos de
analisis, y otras operaciones para ser usados sobre los tipos de modelos
Referencias de fuentes. Ejemplo. Autor, fecha, URLs.
Un punto de vista debe incluir informacion en tecnicas de arquitectura usada,
para crear, interpretar o analizar una vista gobernada por ese punto de vista.
Ejemplo:
Reglas de correspondencia
Criterios
metodos para vericar consistencia
Complementos
metodos, heursticas, metricas, reglas de dise no y lneas gua, mejores
practicas para la creacion de vistas y fuentes.
Un punto de vista puede ser denido como parte de una AD, de un AF, o
individualmente de tal forma que se pueda usar en diferentes AD.
A.5. Anexo A
A.5.1. Notas en terminos de conceptos
Principios de dise no, conceptos y terminos en los que se basa la norma. La
norna dene los requerimientos minimos de una AD
A.5.2. Sistemas y Arquitecturas
Permite estudiar la forma desde dos losofas diferentes: Arquitectura como
concepto y Arquitectura como propiedad. Se han identicado cuatro met?foras
de arquitectura:
Arquitectura como modelo
Arquitectura como literatura
Arquitectura como lenguaje
Arquitectura como Decision
La arquitectura es inevitablemente basada sobre multiples Stakeholders con
multiples intereses en el sistema
58 AP

A.5.3. Intereses
Separacion de intereses de la fuente software y sistemas de ingenieria.
es
crito
por Edsger W Dijktra en 1974. Vistas y Vistas de Arquitectura Las vistas son
agrupaciones de tipos de modelo que tiene el proposito de mostrar intereses de
aspectos parecidos o manejan una relacion con cierta conicidencia entre ellos.
Los puntos de vista son convensiones para expresar una arquitectura con un
set de interes El uso de multiples vistas es la premisa fundamental de la norma
ISO/IEC 107746-2:2009
Cada vista necesita representa todo el sistema desde la perspectiva del
interes mostrado por el punto de vista que gobierna esta vista. Ejemplo:
En una vista de rendimientode un sistema de redes corporativas se
debe considerar ambos redes tiempos de deley (en un modelo) y tiempo
de procesamiento (en otro modelo) para producir una vista holistica de el
rendimiento del sistema completa
Dos enfoques para la cosntruccion de vista
Enfoque sintetico
Enfoque proyectivo ? Mary Shaw
A.5.4. Modelos, productos de trabajo y modelos de arqui-
tectura
Todo modelo tiene un sujeto Ejempplo:identicacion de Stakeholders) Un
modelo puede ser:
Concepto (Como un modelo mental). Ejemplo:Arquitectura
Un producto de trabajo. Ejemplo: Descripcion de Arquitectura
A.5.5. Relaciones
Determinan relaciones entre elementos de AD.
Regla1:Un elemento debe ser ejecutado en una o mas plataformas. Ele-
mentos ejecutados en plataformas
Ejemplo 1 Se cumple la regla
Cuadro A.1: Muestra una distribucion de elementos en las plata-
formas de tal forma que cumplen la regla ?Regla1?.
R1: Elementos R1: Plataformas
e1 p1,p4
e2 p2,p3
e3 p2
e4 p4
A.5. ANEXO A 59
Cuadro A.1 continued from previous page
Ejemplo 2 Se incumple la regla
En el ejemplo 2 se viola la regla porque hay elementos sin plataformas asig-
nadas
Cuadro A.2: Muestra una distribucion de elementos en las plata-
formas de tal forma que incumplen la regla ?Regla1?.
e1 p1
e2 p2
e3 -
e4 -
Ejemplo 3 Regla: Cada instancia del tipo de modelotareasnecesita tener
un renamiento a una instancia de tipo de modelo nteraccion
Ejemplo 4 Regla: El identicador de version de cada vista necesita ser su-
perior a 1.5 para su publicacion
Ejemplo 5 Una notacion matematica para representar el ejemplo 1
A.5.6. ISO/IEC 19793 Versus ISO/IEC 42010
Homogeneidad Vs hetereogenea
19793: Cada vista es homogenea:Un solo lenguaje de punto de vista es
usado para la especicacion
42010: Cada vista es hetereogenea: Cada vista es compuesta por uno o
mas puntos de vista de vista de arquitectura en los cuales cada modelo
(gobernado por un tipo de modelo) puede utilizar un diferente lenguaje
de modelado. Esto permite que ISO/IEC 42010 establezca relaciones entre
los modelos tambien, y no solo entre las vistas
Relaciones en vistas Vs Relaciones en modelo
19793: Relaciones son binarias (Relaciones entre vistas)
42010: Relaciones son n-arias (Relaciones entre modelos)
60 AP

Relaciones entre elemtnos de punto de vista Vs relaciones entre ele-
mentos de descripcion de arquitectura
19793: Relaciones son denidas entre los elementos de un punto dde vista
especicado (Relaciones entre vistas)
42010: Relaciones no estan limitadas a los elemntos de los modelos, sino
que pueden incluirse relaciones entre los elementos de descripcion de ar-
quitectura (Relaciones entre modelos)
42010 relaciones y reglas de correspondencia pueden ser usadas entre
descripciones descripciones de arquitectura
A.5.7. Frameworks de arquitectura y ADLs
Framework de arquietctura (AF) ? 1970 Lenguaje de sdescirpcion de arqui-
tectura (ADL) ? 1990
A.5.8. Archimate
Cubre tres capas:
Negocio
Aplicacion
Tecnologia
Cubre 15 puntos de vista basicos:
Organizacion
Actor y cooperacion
Funciones de negocio
Procesos
Cooperacion de procesos
Producto
Cooperacion de aplicaciones
Estructura de aplicacion
Uso de Aplicaci on
Infraestructura
Implementacion y despliegue
Estructura de informacion
A.6. ANEXO B 61
Realizacion de servicios
Capas
Mapa de aplicacion
A.6. Anexo B
A.6.1. Guas para puntos de vista de arquitectura
Tipos de modelo: Diferentes maneras de documentarla
Especicando el metamodelo
Entregando un templete para ser llenado
Lenguaje decnion o referneciando un lenguaje de modelado
Combinacion de los metodos anteriores
Tipos de modelos:Metamodelos
Los metamodelos pueden presentar:
Entidades
Atributos
Relaciones
Restricciones
Operaciones en vistas
Metodos de creacion: la manera de hacer vistas
Process guidance
WorkProduct guidance(templete de vistas de este tipo)
Heuristicas
Styles
Otros idiomas
Metodos de interpretacion: La manera de entender la vista
Metodos de analisis: Vericar, razon de ser, transformar, predecir, aplicar
y evaluar resultados de Ar para estas vistas
Metodos de dise no e implementacion: Son usados para realizar o construir
sistemas usando la informacion de estas vistas
62 AP

A.6.2. Guas para puntos de vista de arquitectura
Referencia -Deniendo ejecucion de punto de vista para un largo y com-
plejo sistema de softwre-.
4 puntos de vista
Referencia -Documenting software Arquitecture: Views and beyonce-
3 categoras de puntos de vista
Referencia -Process of software Arquitecture-
Un catalogo de puntos de vista
ISO/IEC 42010: View point repository
Repositorio suministrado por la comunidad
The 4+1 view model architecture
Logica, desarrollo, proceso e infraestructura
Referencia -Software system Arquitecture work with Stakeholders using
viewpoint and perpectives-
Catalogo de puntos de vista
ISO/IEC 12288: 2008 Dise no Arquitectural
Requerimientos en una Descripcion de arquitectura
Descripcion arquitectonica
descomposicion y ubicacion de puntos de vuista
ISO/IEC 10746-(2,3) (RM-ODP): AF for distributed processing sys-
tem
5 Puntos de vista
Enterpice
Information
Computacional
Engeniering
Technology
A.7. Anexo C
Relacion entre los estandares
A.7. ANEXO C 63
A.7.1. ISO 12207:2008: the software arquitectural desing
process (6.4.3.3.1 y 7.1.3.3.1)
Dise no de arquitectura de sistemas
Dise no de arquitectura de software
the software arquitectural desing process
Descomposicion y ubicacion de puntos de vista
identicacion de requerimientos del sistema
descomposicion del sistema en items
Ubicacion de los requerimientos en los tems
vericacion de que todos los requerimientos son ubicados en items
64 AP

Bibliografa
[1] David Ricardo Fernandez Aramayo. Arquitectura de Software. ITESM,
2004.
[2] Object Management Group. Business process model and notation. http:
//www.bpmn.org/.
[3] Objet Managmen Group. Unied modeling lenguages. http://www.uml.
org/.
[4] The Open Group. Archimate
A R 2.0 the book. http://theopengroup.

org/archimate.
[5] The Open Group. Other architectures and frameworks. http://pubs.
opengroup.org/architecture/togaf8-doc/arch/chap37.html.
[6] IEEE ISO, IEC. Systems and software engineering Architecture description
ISO/IEC/IEEE 42010. ISO, 2011.
[7] Philippe Kruchten. Architectural BlueprintsThe 4+1 View Model of Soft-
ware Architecture. IEEE, 1995.
[8] Rick Lapenna. Applying ea framework. http://ricklapenna.com/
about-ea-frameworks/.
[9] J.D. Meiers. Reference models, reference architectures, and reference im-
plementations. http://ricklapenna.com/about-ea-frameworks.
[10] Microsoft. Architecture standards. http://blogs.msdn.com/blogfiles/
mikewalker/WindowsLiveWriter/ArchitectureStandards_DEEC.
[11] SysML Partners. Systems modeling language. http://www.sysml.org/.
[12] Roger Sessions. A comparison of the top four enterprise-architecture metho-
dologies. http://msdn.microsoft.com/en-us/library/bb466232.aspx.
65

Propuesta de Modelos para Descripcion de Arquitectura PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Propuesta de Modelos para Descripcion de Arquitectura PDF

Caricato da

Copyright:

Formati disponibili

Modelo propuesto, para la descripci on de una

arquitectura basada en la ISO/IEC/IEEE 42010

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ON ACTUAL DE LAS EMPRESAS BOGOTANAS

ITULO5. MODELOS PARALADESCRIPCI

ITULO5. MODELOS PARALADESCRIPCI

ITULO5. MODELOS PARALADESCRIPCI

ITULO5. MODELOS PARALADESCRIPCI

ITULO5. MODELOS PARALADESCRIPCI

ITULO5. MODELOS PARALADESCRIPCI

Aa para la elaboracion de arquitectura.

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

ENDICE A. TRADUCCION DE LA NORMA ISO/IEC/IEEE 42010

A R 2.0 the book. http://theopengroup.

Potrebbero piacerti anche