Conforme el tamaño y complejidad del software se incrementa, diseñarlo va más allá de la aplicación sistemática y cuantificable de una metodología para su construcción, operación y mantenimiento. La arquitectura de software como disciplina, se centra en la idea de reducir la complejidad del software
especificando, modelando y administrando dependencias, comportamientos, y cualidades. Este taller presenta una guía para profesionales de la industria de software, bajo un enfoque técnico, práctico y ágil, respecto a:
a) ¿por qué extender el diseño de software a un nivel arquitectónico?
b) ¿cuándo es valioso abordar el diseño de un proyecto desde un enfoque arquitectónico?
c) ¿qué enfoque utilizar (model-driven, reuse-driven ó risk-driven)?
d) ¿cómo iniciar la adopción de un enfoque arquitectónico?
Concluyendo con una discusión cualitativa y cuantitativa del uso de estilos, modelos, patrones y tácticas arquitectónicas.
Objetivo: Caracterizar los fundamentos del proceso de desarrollo de software mediante su contextualización en la ingeniería de software para planificar el desarrollo de software de manera metodológica.
Objetivo: Analizar los aspectos principales para la estimación de proyectos de software alineados a metodologías usadas en la industria para desarrollar proyectos de software escalables.
Objetivo: Caracterizar los fundamentos del proceso de desarrollo de software mediante su contextualización en la ingeniería de software para planificar el desarrollo de software de manera metodológica.
Objetivo: Analizar los aspectos principales para la estimación de proyectos de software alineados a metodologías usadas en la industria para desarrollar proyectos de software escalables.
Elementos adicionales sobre diseño, permite retomar temas que fueron tratados en presentaciones anteriores y que es necesario aclarar y dejarlos con un soporte suficiente.
En esta actividad se presenta acerca de lo que son los estilos de arquitectura y los patrones de arquitectura. También se dan ejemplos de algunos de ellos como el estilo Orientado a objetos y de Filtros y tuberías, asi como los patrones MVC (Modelo Vista Controlador) y de Capas. Se mencionan diferencias entre patrón y estilo de arquitectura.
UnADM. Diego Plascencia. ES1421004131,
Creditos:
Photo Credit: <a>Canadian Pacific</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>tjwsphotographies</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Omar Omar</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Onasill ~ Bill Badzo</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>tjwsphotographies</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Ian Sane</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>PeterThoeny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Onasill ~ Bill Badzo</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>ancasta1901</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>PeterThoeny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Sworldguy</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Dakiny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Dakiny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>blavandmaster</a> Flickr via <a>Compfight</a> <a>cc</a>
UML. Un análisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
Metodologías de desarrollo ágiles: Scrum, XPejordi
Metodologías de desarrollo ágiles: Scrum y eXtreme Programming.
Treball de l'assignatura Gestió de Sistemes d'Informació (GESI) de la Universitat Politècnica de Catalunya (UPC). Professor: Jordi Esteve. Gener 2009. Vilanova i la Geltrú. Barcelona. Catalunya.
Introducción a la Arquitectura de Software.
Géneros Arquitectónicas
Estilos Arquitectónicos.
Diseño Arquitectónico.
Evaluación de los diseños alternativos para la Arquitectura.
Elementos adicionales sobre diseño, permite retomar temas que fueron tratados en presentaciones anteriores y que es necesario aclarar y dejarlos con un soporte suficiente.
En esta actividad se presenta acerca de lo que son los estilos de arquitectura y los patrones de arquitectura. También se dan ejemplos de algunos de ellos como el estilo Orientado a objetos y de Filtros y tuberías, asi como los patrones MVC (Modelo Vista Controlador) y de Capas. Se mencionan diferencias entre patrón y estilo de arquitectura.
UnADM. Diego Plascencia. ES1421004131,
Creditos:
Photo Credit: <a>Canadian Pacific</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>tjwsphotographies</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Omar Omar</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Onasill ~ Bill Badzo</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>tjwsphotographies</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Ian Sane</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>PeterThoeny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Onasill ~ Bill Badzo</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>ancasta1901</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>PeterThoeny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Sworldguy</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Dakiny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>Dakiny</a> Flickr via <a>Compfight</a> <a>cc</a>
Photo Credit: <a>blavandmaster</a> Flickr via <a>Compfight</a> <a>cc</a>
UML. Un análisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
Metodologías de desarrollo ágiles: Scrum, XPejordi
Metodologías de desarrollo ágiles: Scrum y eXtreme Programming.
Treball de l'assignatura Gestió de Sistemes d'Informació (GESI) de la Universitat Politècnica de Catalunya (UPC). Professor: Jordi Esteve. Gener 2009. Vilanova i la Geltrú. Barcelona. Catalunya.
Introducción a la Arquitectura de Software.
Géneros Arquitectónicas
Estilos Arquitectónicos.
Diseño Arquitectónico.
Evaluación de los diseños alternativos para la Arquitectura.
Discutir la importancia de las arquitecturas model-drive y reuse-drive en los procesos de creación de software para la pequeña y mediana empresa. Discutir las técnicas propuestas por el proceso unificado (RUP) y su implementación como parte del área de proceso “Solución Técnica” en el modelo CMMI en empresas pequeñas y medianas. Aplicación de patrones de arquitectura y diseño ¿para qué? ¿cómo? i ¿dónde? Como soporte a CMMI (en el área de proceso de solución técnica).
¿Quién va a desarrollar las Apps del futuro? (aviso: no serán los programador...Jordi Cabot
No hay suficientes programadores profesionales para todo el software que necesita nuestra sociedad. Aquí propongo una serie de soluciones alternativas.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
Inteligencia Artificial y Ciberseguridad.pdfEmilio Casbas
Recopilación de los puntos más interesantes de diversas presentaciones, desde los visionarios conceptos de Alan Turing, pasando por la paradoja de Hans Moravec y la descripcion de Singularidad de Max Tegmark, hasta los innovadores avances de ChatGPT, y de cómo la IA está transformando la seguridad digital y protegiendo nuestras vidas.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
2. Expectativas
¿Qué esperas aprender en este taller ?
líder de proyecto
desarrollador
ingeniero
otro
¿Cuál es tu perfil?
2 javiergs@acm.org
3. Objetivo
S Complejidad
del
so-ware
S Ingeniería:
aplicación
sistemá5ca
y
cuan5ficable
de
una
metodología
para
su
construcción,
operación
y
mantenimiento
S Arquitectura:
reducir
la
complejidad
del
so-ware
especificando,
modelando
y
administrando
dependencias,
comportamientos
y
cualidades
S Una
guía
bajo
un
enfoque
técnico,
prác5co
y
ágil
3 javiergs@acm.org
4. Objetivo
S ¿por
qué
extender
el
diseño
de
so-ware
a
un
nivel
arquitectónico?
S ¿cuándo
es
valioso
abordar
el
diseño
de
un
proyecto
desde
un
enfoque
arquitectónico?
S ¿qué
enfoque
u5lizar
(model-‐driven,
reuse-‐driven
o
risk-‐driven)?
S ¿cómo
iniciar
la
adopción
de
un
enfoque
arquitectónico?
S Concluyendo
con
una
discusión
cualita9va
y
cuan9ta9va
del
uso
de
es5los,
modelos,
patrones
y
tác5cas
arquitectónicas
4 javiergs@acm.org
6. Agenda
1. Introducción: Antecedentes, Conceptos, Contexto
2. Arquitecturas, Modelos y Patrones
3. [ Trabajo en Equipo ]
receso
1. [ Trabajo en Equipo ]
2. Enfoques
3. Aplicación en la Práctica (arquitectura + ingeniería)
4. Conclusiones y Referencias
6 javiergs@acm.org
9. Antecedentes
“Most software today is very much
like an Egyptian pyramid with
millions of bricks piled on top of each
other, with no structural integrity, but
just done by brute force and
thousands of slaves” *
Fuerza
Bruta
* ACM Queue A Conversation with Alan Kay Vol. 2, No. 9 – Dec/Jan 2004-2005
9 javiergs@acm.org
10. Antecedentes
Ensamblar
So-ware
J. Greenfield and K. Short, “Software factories: assembling applications with patterns, models, frameworks and tools,”
presented at the Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems,
languages, and applications, 2003, pp. 16–27.
10 javiergs@acm.org
11. Antecedentes
S $250 billones de dólares en desarrollo de software en USA
S Costo promedio por proyecto $430,000 a $2,300,000 dólares
S 16% de los proyectos se completan a tiempo y en presupuesto
S Aunque en promedio sólo el 42% de los requerimientos originales son
implementados
S 31% de los proyectos se cancelan por problemas de calidad
S 53% de los proyectos cuestan más de lo planeado, excediendo el
presupuesto original en promedio en 189%
J. Greenfield and K. Short, “Software factories: assembling applications with patterns, models, frameworks and tools,”
presented at the Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems,
languages, and applications, 2003, pp. 16–27.
11 javiergs@acm.org
13. Resumen
“Divide y Vencerás”
Arquitectura:
reducir la complejidad del software especificando,
modelando y administrando componentes,
dependencias, comportamientos, y cualidades
“La calidad del producto es proporcional a la calidad de
las partes que lo componen”
“El todo es más que la suma de sus partes”
13 javiergs@acm.org
17. El Arquitecto
Arquitectura de software
S NO IMPLICA DETALLES DE IMPLEMENTACIÓN
Arquitecto
S Obtener información del problema y diseñar la solución que
S satisfaga requerimientos (funcionales, no funcionales)
PERO
Arquitecto
S Apoyándose en patrones, modelos y framework Ingeniero
Obrero
ADEMÁS DE
S Participar activamente en el desarrollo, PERO no es un desarrollador
S Generar lineamientos GENERALES a considerarse en la creación de
FAMILIAS de productos
17 javiergs@acm.org
18. ¿Por qué una arquitectura?
construcción de la casa del perro construcción de una casa
S Una persona
S Estructura simple
S Proceso simple S Un equipo
S Herramientas simples S Modelado
S Procesos bien definidos
S Conocimiento teórico limitado S Herramientas poderosas
A medida que los sistemas crecen los algoritmos y las estructuras de datos dejan de ser el mayor
problema.
18 javiergs@acm.org
19. ¿Por qué una arquitectura?
Programador
=
Inmediato
Ingeniero
=
Corto
Plazo
Arquitecto
=
Largo
Plazo
19 javiergs@acm.org
21. Conceptos
S Estilo arquitectónico
Orientada a eventos
SOA
S Tipo o clase de arquitectura
Física
Lógica
Tecnológica
21 javiergs@acm.org
22. Estilos
¿Arquitectura?
Columnas: ¿maya ó azteca?
Dórico, Pirámides en ángulo
Jónico, perfecto y columnas de
piedra
y
Corintio
Egipto
mayor detalle y elaboración.
Satisfacer a los dioses y a
grandes y extravagantes, un placer a la vista.
uno mismo (simetría y
Azoteas impresionantes y detalladas
naturaleza): Roca,
madera en la estructura interna y
clásico ventanales emplomados.
Fuego, Poder y Belleza
china
Gótico
22 javiergs@acm.org
23. Tipos
Aplicación o
Física Datos
Negocio
Clase o Tipo
Estilos
arquitectónicos
Arquitectura
Componente Patrón
Reglas
23 javiergs@acm.org
28. Concepto
El área de proceso de Solución Técnica:
S Pertenece a la categoría de Ingeniería
S Es una de las 14 áreas de proceso en nivel 3
S Su propósito es diseñar, desarrollar e implementar (incluido el proceso
de pruebas) soluciones que satisfagan el conjunto de requerimientos
S Soluciones, diseños e implementaciones son parte de los productos,
componentes y procesos del área
S Productos o componentes
28 javiergs@acm.org
30. CMMi TS :: SG1
Seleccionar las Soluciones para Productos y Componentes
El diseño de la solución debe considerar la evaluación de varias alternativas
de solución: arquitectura y modularización, desarrollo interno contra
productos comerciales, etc. Estas decisiones deben fundamentarse en:
S Requerimientos
S Restricciones de diseño
S Evolución a futuro del producto
S Productos comerciales disponibles
S Cualidades del software
30 javiergs@acm.org
31. CMMi TS :: SP1.1
Desarrollar alternativas de solución y criterios de selección
S Identificar y analizar diversas soluciones alternas
S Las alternativas de solución estarán basadas en arquitecturas propuestas
que cumplan con las características críticas del producto
S Las alternativas de solución caerán dentro de márgenes aceptables de
costos, calendario y desempeño
31 javiergs@acm.org
32. CMMi TS :: SP1.2
Seleccionar las soluciones para los componentes del producto que
mejor satisfagan los criterios establecidos
S Establecer los requerimientos asociados al conjunto de soluciones, como
los requerimientos asignados a los componentes asociados con dicho
conjunto de soluciones
S Identificar las soluciones que serán reutilizadas o compradas
S Establecer y mantener la documentación de las soluciones, su evaluación
y razones de selección o rechazo
32 javiergs@acm.org
33. CMMi TS :: SG2
El diseño del producto o componentes debe incluir información para su
implementación y demás fases del ciclo de vida del producto como son
la instalación y mantenimiento. Además, la documentación del diseño
provee una referencia que soporta el entendimiento del diseño con los
agentes relevantes.
33 javiergs@acm.org
34. CMMi TS :: SP2.1
Desarrollar el diseño del producto o componentes
S Diseño preliminar o arquitectónico. Define los elementos estructurales
y de coordinación del producto o componente
S Considera cualidades deseables
S Se debe evaluar el uso de productos comerciales o el reutilizar productos
existentes para los componentes del producto
S Considera el establecimiento de un framework que de soporte a familias
de productos
S Subprácticas: RUP y aplicación de patrones
34 javiergs@acm.org
35. CMMi TS :: SP2.2
Establecer el Paquete Técnico
State
State
Diagrams
Class
Diagrams State
Use Case Use Case Diagrams State
Diagrams
Use Case
Diagrams Use Case Object
Diagrams
Sequence
Diagrams Diagrams
Use Case Diagrams
Diagrams Diagrams
Diagrams
Scenario State
Scenario State
Diagrams
Diagrams
Collaboration Component
Diagrams
Diagrams Modelos Diagrams
Diagrams
Component
Scenario Component
Diagrams
Scenario
Diagrams Deployment
Diagrams
Statechart
Diagrams Activity Diagrams
Diagrams Diagrams
35 javiergs@acm.org
36. CMMi TS :: SP2.3
Diseñar las interfaces del producto y componentes en base a los
criterios establecidos.
36 javiergs@acm.org
37. CMMi TS :: SP2.4
Evaluar, en base a criterios establecidos, si los componentes se
desarrollarán, comprarán o reutilizarán
S La decisión entre desarrollar, comprar o reutilizar comienza en los
primeros diseños y se completa a medida que los diseños se van
detallando y refinando
S Patrones y anti patrones
37 javiergs@acm.org
38. CMMi TS :: SG3
Implementación del diseño del producto
S CMMi TS :: SP3.1 Implementar (incluye pruebas)
S CMMi TS :: SP3.2 Documentar
S Hablemos de Trazabilidad
38 javiergs@acm.org
40. Idioms
S Patrón de bajo nivel
S Soluciona problemas específicos de implementación en un lenguaje de
programación
S Describe cómo implementar componentes o relaciones aplicando el
lenguaje
Ejemplos:
S Convenciones de nombres
S Formato para el código fuente
S Manejo de memoria
S Etc.
40 javiergs@acm.org
41. Patrones de Diseño
Patrones de medio nivel, organizan la funcionalidad de subsistemas de
manera independiente.
Describe esquemas comunes de comunicación entre componentes para la
solución de problemas generales en un contexto particular.
S Patrones de Creación
S Patrones Estructurales
S Patrones de Comportamiento
41 javiergs@acm.org
43. Ensamble
a) Relaciones
b) Mini-componentes incluyentes
c) Autonomía
d) Estándar
e) El “cambio” es mi amigo
f) Creatividad
g) Producto predecible
43 javiergs@acm.org
44. Hablando de Relaciones
a) Ser a) Observar
b) Usar b) Encubrir a…
c) Tener c) Decorar a…
d) Soy único
e) Yo construyo a…
f) Trabajar con …
g) Soy parte de …
44 javiergs@acm.org
54. Patrones de Arquitectura
Patrones de alto nivel, aplicables a la especificación fundamental del sistema
de software
Ejemplos:
Ÿ Distributed Ÿ Layered
Ÿ Event-driven Ÿ MVC
Ÿ Frame-based Ÿ IR-centric
Ÿ Batch Ÿ Subsumption
Ÿ Pipes and filters Ÿ Disposable
Ÿ Repository-centric Ÿ Publisher-subscriber
Ÿ Blackboard
Ÿ Interpreter
Ÿ Rule-based
54 javiergs@acm.org
55. Blackboard
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
55 javiergs@acm.org
56. Layered
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
56 javiergs@acm.org
57. Pipes and Filters
D. Garlan and M. Shaw, “An introduction to software architecture,” Advances in software engineering and knowledge
engineering, vol. 1, pp. 1–40, 1993.
57 javiergs@acm.org
58. Antipatrones
Antipatrones aplicados en desarrollo
S Lava Flow
S Spaghetti code
S Poltergeists: muchas clases
S God class: the blob
S Golden Hammer
Aplicados a la arquitectura
S Reinventando la rueda
S Stovepipeline System
S Stovepipeline Enterprise
S Vendor Lock-in
Aplicados a la gestión
S Mythical Man Month
S Death March Project
S Analysis paralysis
S Corncob
58 javiergs@acm.org
59. Trabajo en Equipo
Práctica en Equipo
Es5lo
Arquitectónico
Patrones
de
Diseño
Cualidades
¿Cómo?
59
64. Model-Driven
S Definir la funcionalidad del sistema como un modelo independiente de
la plataforma
S Propuesto y patrocinado por el Object Management Group
S Separar el diseño de la arquitectura y de las tecnologías de
construcción
S Facilitar que el diseño y la arquitectura puedan ser alterados
independientemente
S El diseño alberga los requerimientos funcionales (ej. casos de uso)
S La arquitectura proporciona la infraestructura a través de la cual se
hacen efectivos los requerimientos no funcionales como la
escalabilidad, fiabilidad y rendimiento
64 javiergs@acm.org
65. Reuse-Driven
S Enfoque orientado al negocio
S Efectividad en términos de costo y tiempo
S Generar familias de producto y líneas de producción
S Identificar un área de dominio para la compañía. El dominio se separa
en componentes y sistemas
S Utiliza Model-driven por cada componente o sistema identificado en el
dominio
S Modelar componentes NO funcionalidades
65 javiergs@acm.org
66. Risk-Driven
S Identificar la cantidad exacta de modelado requerido
S Identificar las partes de mayor riesgo en el proyecto y aplicar técnicas
arquitectónicas y de diseño para mitigar esos riesgos
S Identificar, solucionar y evaluar
G. H. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, 1st ed. Marshall & Brainerd, 2010, p.
376.
66 javiergs@acm.org
71. Ciclo de Vida
Flujos de trabajo fases
del proceso Iniciación Elaboración Construcción Transición
Modelado del
negocio
Requisitos
Análisis y diseño
Implementación
Pruebas
Despliegue
Flujos de trabajo
de soporte
Gestión del cambio
y configuraciones
Gestión del proyecto
Entorno
Iteraciones Iter Iter Iter Iter Iter Iter Iter
preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Fuente: Jacobson et al., 2000
71 javiergs@acm.org
72. Diagramas
Los diagramas expresan gráficamente partes de un modelo desde cierta perspectiva
State
State
Diagrams de
Use Case Diagramas
Diagrams
Use Case
Diagrams de Clases State
Use Case Diagramas
Diagrams State
Use Case Diagrams de
Diagramas
Diagrams de
Diagramas Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario
Diagrams de State
Diagrams de
Diagramas
Diagrams Diagramas
Diagrams
Colaboración Componentes
Modelo(s)
Scenario Component
Scenario
Diagrams de
Component
Diagrams
Diagramas de
Diagramas
Diagrams Diagrams
Estados Distribución
Diagramas de
Actividad Estáticos
Dinámicos
De Estructura
De funcionalidad
De arquitectura
De Comportamiento
72 javiergs@acm.org
73. Relación
Modelo de
Casos de Uso verificado por
especificado por
realizado por
Modelo de
distribuido por Prueba
Modelo de
Análisis
Modelo de implementado por
Diseño
Modelo de
Despliegue
Modelo de
Implementación
73 javiergs@acm.org
74. Agrupando Modelos
Mode lo de l Mode lo de l Mode lo de Mode lo de Mode lo de Mode lo de Mode lo de Mode lo Mode lo de
Ne gocio Dom inio Cas os de Anális is Dis e ño Proce s os De s plie gue Im ple m e n- Prue ba
Us o tación
Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din. Es t. Din.
Diagram a de
Cas os de Us o X X X
Diagram a de
Inte racción- X X X X X X X X
Se cue ncia
Diagram a de
Inte racción- X X X X X X X X
Colaboración
Diagram a de
Clas e s de X
Anális is
Diagram a de
Obje tos de X
Anális is
Diagram a de
Clas e s de X X
Dis e ño
Diagram a de
Obje tos de X X
Dis e ño
Diagram a de
Es tados X X X X X X
Diagram a de
Actividade s X X X X X
Diagram a de
Com pone nte s X
Diagram a de
De s plie gue X
74 javiergs@acm.org
75. Modelando
S Casos de Uso
S Clases
S Actividades
Nombre
S Estados Atributos
S Secuencias Métodos
S Objetos
S IEEE SRS
75 javiergs@acm.org
76. OOSE
UML
Cada modelo es examinado o manipulado
Construir modelos que representan al por un grupo de stakeholders
sistema
Objetos, tipos, clases
código
cambiante Sistemático modelo
informal
Problema sistema
real
OO-SE
complejo
Requerimientos – Análisis – Diseño - Implementación -- Pruebas
abstracto - iteraciones - concreto
76 javiergs@acm.org
77. OOSE
OO-SE
Comportamiento, mensajes
Características, estados
objetos encapsulamiento transición
Modelan y codifican
casos
generalización/especialización (herencia) de uso
relaciones
asociación (objetos)
dependencia (import) Generalización (herencia) de actores y casos
paquetes
código
pruebas
automáticas
77 javiergs@acm.org
82. Referencias
S Software Architecture in Practice, Len Bass, Adisson Wesley 2003.
S Software Reuse: Architecture, Process and Organization for
Business Success, Ivar Jacobson, ACM Press.
S Design Patterns, Head First, Eric Freeman & Elisabeth Freeman
S Just Enough Software Architecture, .
Marshall
&
Brainerd, George
Fairbanks
82
javiergs@acm.org