Semestre 2017 – 13
| Nombre del curso: | Arquitectura de Software |
|---|---|
| Course Name: | Software Architecture |
| Créditos: | 2 |
| Profesor: | Rafael Meneses Ramírez rg.meneses81@uniandes.edu.co |
| Lina Casas lg.casas766@uniandes.edu.co |
- Descripción
- Propósito
- Objetivos
- Metodología
- Evaluación
- Generalidades
- Calendario
- Proyecto
- Recursos
- Bibliografía
Descripción
El propósito de este curso es presentar al estudiante las metodologías, estrategias y buenas prácticas de diseño de software. Así mismo, se examinan desde diferentes niveles de abstracción las tareas que enfrenta un diseñador de software, primero en la arquitectura de la solución, en la que sólo grandes elementos externamente visibles de la solución son identificados y analizados a partir de los requerimientos funcionales y los atributos de calidad requeridos. Posteriormente, se estudian las técnicas de diseño detallado de cada uno de los elementos arquitecturales. Por último, se presentan técnicas de evaluación de arquitecturas para validar el cumplimiento de los requerimientos funcionales y de los atributos de calidad requeridos.
Propósito
El propósito de este curso es presentar al estudiante las metodologías, estrategias y buenas prácticas de diseño de una arquitectura de software. Así mismo, se examinan desde diferentes niveles de abstracción las tareas que enfrenta un arquitecto de software, primero en la solución, en la que sólo grandes elementos externamente visibles de la solución son identificados y analizados a partir de los requerimientos funcionales y los atributos de calidad requeridos. Posteriormente, se estudian las técnicas de diseño detallado de cada uno de los elementos arquitecturales. Por último, se presentan técnicas de evaluación de arquitecturas para validar el cumplimiento de los requerimientos funcionales y de los atributos de calidad requeridos.
Objetivos
El curso pretende desarrollar las competencias de definir, justificar, implementar y evaluar una arquitectura de software para un problema en el mundo empresarial. Al finalizar el curso el estudiante debe estar en capacidad de:
-
Utilizar los conceptos básicos de arquitecturas de software para definir una estrategia de desarrollo. Esto significa, identificar los elementos del mundo de la solución – los componentes de software, sus propiedades visibles externamente y las relaciones entre ellos – para estructurar y organizar el proceso de desarrollo de software.
-
Utilizar adecuadamente los estilos de arquitectura para explicar el diseño de un sistema. Explicar y proponer una solución a los problemas de interacción entre los componentes. Justificar cómo una solución responde a los requerimientos y restricciones de un negocio.
-
Utilizar técnicas de evaluación de arquitecturas para justificar la selección de una arquitectura candidata como guía en el desarrollo de un sistema.
-
Entender el impacto de los atributos de calidad de una aplicación en la arquitectura, diseño e implementación de un sistema basado en componentes.
-
Realizar experimentos para validar las aproximaciones arquitectónicas propuestas.
Metodología
El curso gira alrededor de un proyecto de tamaño mediano, el cual es utilizado para introducir gradualmente los diferentes requerimientos de calidad, estrategias de documentación y tácticas de arquitectura y diseño para su solución.
El curso se basa en clases teóricas, reforzadas con hojas de trabajo y talleres para poner en práctica los conceptos vistos en clase.
El objetivo principal es presentar a los estudiantes los diferentes requerimientos de calidad presentes en un sistema de información tradicional, y cómo documentar efectivamente dichos requerimientos y seleccionar los estilos y tácticas de arquitectura más apropiados para su cumplimiento. Se espera igualmente que los estudiantes diseñen y ejecuten experimentos que validen si la aproximación seleccionada cumple o no con los objetivos propuestos a nivel de atributos de calidad.
El estudiante debe asistir y participar de manera activa en las clases teóricas y desarrollar los talleres relacionados con el tema.
Evaluación
La evaluación está compuesta por dos (2) exámenes individuales, dos (2) experimentos, dos (2) presentaciones de la arquitectura del proyecto y el documento de arquitectura (SAD). Los porcentajes están distribuidos de la siguiente forma:
-
Parcial 1 (20%)
-
Parcial 2 (20%)
-
Experimentos (30%)
-
Realimentación SAD (5%) – Documento SAD (5%)
-
Sustentación SAD (15%) – Documento SAD (5%)
Política de aproximación de notas
-
Las notas definitivas del curso varían entre 1.50 y 5.00, en intervalos de 0.5. Las notas intermedias de dichos intervalos son aproximadas por el profesor teniendo en cuenta el desempeño global del grupo. El valor a partir del cual se decide aproximar en cada intervalo, de forma ascendente o descendente, es decidida por el profesor y se aplica por igual a todos los estudiantes.
-
Las notas de parciales, experimentos, presentaciones y documentos se califican entre 0.00 y 5.00 con dos decimales y no hay aproximaciones.
-
Para aprobar el curso es necesario obtener una nota igual o superior a 3.0. No hay aproximaciones de notas inferiores a 3.0, es decir que 2.99 corresponde a 2.5.
Generalidades
-
La grabación, por cualquier medio, de este curso NO está autorizada. En caso de requerirla realice una solicitud por escrito dirigida al profesor del curso justificando las razones.
-
Se considera fundamental la asistencia a clase como garantía del rendimiento académico en el desarrollo de este curso. Durante las clases, el profesor llevará una bitácora de presencia de los estudiantes como registro de asistencia. Es responsabilidad del estudiante firmar la bitácora de presencia. La ausencia injustificada a más del 20% de las horas de clase ocasionará la reprobación del curso. Por otro lado, el estudiante que quiera justificar su ausencia, debe hacerlo ante el profesor dentro de un límite no superior a 8 (ocho) días hábiles siguientes a la fecha de su inasistencia.
-
El curso tiene como canales oficiales de comunicación el correo electrónico Uniandes, el sistema de apoyo a la docencia SICUAPLUS (http://sicuaplus.uniandes.edu.co) y la página Web del curso (https://cursos.virtual.uniandes.edu.co/csof5204).
-
Todo trabajo debe ser entregado en las fechas estipuladas. Después de la fecha designada no se aceptan trabajos sin excusa justificada.
-
Se restringe el uso de celulares, portátiles, reproductores de audio, y el consumo de alimentos en clase.
Proyecto – Sistema de Caracterización de Migrañas
IMPORTANTE: La información contenida en esta página es de carácter confidencial. Su uso está autorizado únicamente dentro de los propósitos educativos de la Universidad de los Andes y en ningún caso podrá ser utilizada en un contexto diferente al del proyecto de este curso.
Contexto
Ciertas enfermedades y condiciones clínicas se convierten en graves problemas de salud pública. Un estudio sugiere que el 10% de la población mundial ha sido diagnosticada con algún tipo de migraña, de acuerdo con este porcentaje, más de 700.000 personas podrían estar sufriendo de migraña sólo en Bogotá.
Lo anterior indica que la migraña es un padecimiento que prevalece en la población mundial, y esto causa una disminución de la calidad de vida de la mitad de las personas que lo sufren. Normalmente, los dolores de los pacientes son caracterizados usando registros clínicos así como formatos impresos en donde son registrados los episodios de dolor. El problema es que es muy común que los pacientes no tengan a mano los formatos cuando ellos los necesitan, lo cual impide que los doctores tengan información correcta y clara que podría ser la clave para un diagnóstico apropiado. De igual forma, muchos pacientes son reacios a llenar los formatos y pueden fallar en usarlos en momentos críticos.
Lo anterior muestra una clara necesidad de estrategias y terapias para pacientes crónicos. Una estrategia posible sería construir un software que remplace los formatos impresos de forma que los pacientes puedan mantener un registro de la información que tanto necesitan los doctores.
Solución
El objetivo del proyecto del curso es construir el software mencionado previamente.
La solución incluye una aplicación móvil para que el paciente colecte la información sin importar donde y cuando ocurre el episodio de migraña. La información que debe consignar el paciente incluye: fecha y hora del episodio de dolor, medicamentos que se encuentra tomando, nivel de dolor, su localización e intensidad, patrones de sueño, actividad física/alimentos/bebidas que pueden haber exacerbado los síntomas. A partir de la información consignada, el sistema central debe hacer un análisis cuyo resultado ayude al paciente a identificar y evitar hábitos que pueden desencadenar los dolores.
La solución también incluye una aplicación móvil y otra Web que permita a los doctores tener acceso a la información colectada desde los dispositivos de los pacientes, para que los primeros puedan analizarla con mayor detalle.
Aplicación del Paciente
Tener en cuenta las siguientes consideraciones:
-
Aplicación móvil con interfaz gráfica de usuario sencilla, con facilidad para grabación voz (para casos en donde el dolor es muy fuerte).
-
El análisis de los datos es crucial para animar a los pacientes a consignar los episodios. Así, al momento en que el paciente registre un episodio, el sistema puede lanzar una alarma para notificar acerca de posibles catalizadores de dolor como ciertas comidas o actividad física.
-
La aplicación móvil del paciente debe compartir parte de la información almacenada con las aplicaciones de doctores. Esto permite que los doctores hagan seguimiento a sus pacientes o pidan a un colega una segunda opinión con base en la información colectada.
Aplicaciones del Dóctor
A continuación se listan los requerimientos funcionales de estas aplicaciones:
-
Revisar los episodios de dolor del paciente a partir de su número de identificación.
-
Revisar los episodios de dolor del paciente en un período de tiempo. A partir de los registros resultantes se pueden construir gráficos mostrando la intensidad del dolor y el alivio del dolor gracias a medicamentos.
-
Revisar un episodio particular de migraña: dado el episodio, revisar todos los catalizadores asociados al dolor, síntomas y medicamentos relacionados al episodio.
Requerimientos No Funcionales
Los requerimientos no funcionales del proyecto se atacaran de forma incremental en los siguientes experimentos:
-
Experimento 1 – Desempeño
-
Experimento 2 – Seguridad y Disponibilidad
Recursos
A continuación se relacionan las plantillas de documentación a ser utilizadas en el curso y la información de experimentación base a tener en cuenta:
Bibliografía
- Rozanski Nick, Eoin woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition). Addison-Wesley Professional; 2 edition, November 4, 2011.
-
Bass, L. Clements, P., Kazman, R., “Software Architecture in Practice (SEI Series in Software Engineering)”, Addison-Wesley Professional; 3 edition (October 5, 2012).
-
Paul Clements et al, “Evaluating Software Architectures”, Addison Wesley, 2002.
-
Erl, T., “SOA Principles of Service Design”, Prentice Hall, 2008.
-
Richard Taylor, Nenad Medvidovic, Eric Dashofy. “Software Architecture Foundations, Theory and Practice, 2009.
-
Frank Buschmann, Kevin Henney, Douglas Schmidt. Pattern-Oriented Software Architecture. Volume 4.
-
John Reekie, Rohan McAdam. A Software Architecture Primer. Angophora Press. 2006.
-
Jan Bosh. Design & Use of Software Architecture. Addison-Wesley. 2000.
-
Kai Qian et Al. Software Architecture and Design Illuminated. 2010.
-
Paul Clements, et al. Documenting Software Architectures: Views and Beyond (2nd Edition), Addison-Wesley Professional; 2 edition. October 15, 2010.
-
Peter Eeles, Peter Crips. The Process of Software Architecting. Addison-Wesley Professional; 1 edition, July 24, 2009.
-
Dave Hendricksen, 12 Essential Skills for Software Architects. Addison-Wesley Professional; 1 edition. October 5, 2011.
-
Anthony Lattanze. Architecting Software Intensive Systems: A Practitioners Guide. Auerbach Publications, November 18, 2008.