Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
ra de
Software
Diana Patricia Quiroga
Camacho
CORTE 2
Reglas de Juego
• Proyecto Integrador (40%)
• Evaluaciones Parciales (30%)
• Trabajos en clase, estudio de casos y talleres (20%)
• Foros (10%)
ESPECIFICACION DE REQUERIMIENTOS
¿Qué son Requerimientos?
Análisis
Extracción • Se leen, conceptúan e investigan los
requisitos
• Se intercambian ideas y resaltan los
• Descubrimiento de los problemas
requisitos del sistema • Se dan alternativas y soluciones
• Se fijan reuniones
Validación Especificación
• Verificar que todos los • Documentan los requisitos
requisitos sean consistentes y • Utilización de técnicas y/o estándares
completos de documentación
ESPECIFICACION DE REQUERIMIENTOS
• Herramientas:
ESPECIFICACION DE
REQUERIMIENTOS
• REQUERIMIENTOS DE USUARIO: Son declaraciones, en lenguaje
natural y en diagramas, de los servicios que se espera que el
sistema proporcione y de las restricciones bajo las cuales debe
funcionar.
Productos de competencia
Bajos Costos
Administrador Comportamiento
Mantener a la gente apropiado
ocupada
Arquitecto
Usuario Final Seguridad
Confiabilidad
Entregas a tiempo
Cliente
Minimización de cambio
frecuentes.
INFLUENCIAS
• Que hace buena una arquitectura
https://www.youtube.com/watch?v=3Tc0rOQN-xw
ESTILOS ARQUITECTONICOS
• ORIENTADA A OBJETOS
• Ventajas
• Modelado mas natural de los problemas
• Mejor manejo de la complejidad
• Fomenta el reusó, con gran impacto en productividad y confiabilidad
• Facilita el mantenimiento y extensión
• Desventajas
• Los objetos al ser abstracto pueden no coincidir la visión de un
programador a otro.
• El concepto de un programador que realiza un objeto abstracto
podría no coincidir con la visión de otro programador.
ESTILOS ARQUITECTONICOS
• Características
• Promueve la capacidad de integración, es decir, que es posible
cambiar componentes existentes y agregar nuevos componentes
• Posible pasar datos entre clientes empleando el mecanismo del
pizarrón.
• Los componentes clientes ejecutan los procesos de manera
independiente.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS
• Ventajas
• Posibilita la integración de Agentes
• Adecuado para solución de problemas no deterministas.
• Resumen de estado de conocimiento en cada momento del proceso.
• Desventajas
• Estructura de datos común a todos los agentes
• Problemas de carga a la hora de chequear y vigilar el estado de la
pizarra.
• Alto esfuerzo en desarrollo.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS
• Arquitectura en Pizarra: Un agente examina la pizarra, realiza su tarea y escribe
sus conclusiones en la misma pizarra. De esta manera, otro agente puede
trabajar sobre los resultados generados por otro.
Solución:
Una serie de agentes de conocimiento tienen acceso a un
almacén de datos compartidos llamado Pizarra. La Pizarra
proporciona una interfaz para inspeccionar y actualizar su
contenido.
El objeto / módulo de Control activa a los agentes
siguiendo una estrategia. Tras ser activado, un agente
inspecciona la pizarra para ver si puede contribuir a
resolver el problema. Si el agente decide que puede
contribuir, el objeto de control permite a los agentes
poner la solución parcial (o final) en la pizarra.
ESTILOS ARQUITECTONICOS
• CENTRADA A DATOS
• Almacén de Datos: Un Almacén de Datos (Data Warehouse) es una colección
de datos que está formada por Variables (hechos, facts) y Dimensiones
(dimensions). Dimensiones son los elementos para ubicar datos que
participan en el análisis y Variables los valores que se desean analizar.
• Orientado a temas: Los datos en la base de datos están organizados de
manera que todos los elementos de datos relativos al mismo evento u
objeto del mundo real queden unidos entre sí.
• Variante en el tiempo: Los cambios producidos en los datos a lo largo del
tiempo quedan registrados para que los informes que se puedan generar
reflejen esas variaciones.
• No volátil: La información no se modifica ni se elimina, una vez
almacenado un dato, éste se convierte en información de sólo lectura, y
se mantiene para futuras consultas.
• Integrado: La base de datos contiene los datos de todos los sistemas
operacionales de la organización, y dichos datos deben ser consistentes.
ESTILOS
ARQUITECTONICOS
• CENTRADA A DATOS
• Almacén de Datos
ESTILOS ARQUITECTONICOS
• Flujo de Datos: Se aplica cuando los datos de entrada son transformados a
través de una serie de componentes computacionales o manipulativos en los
datos de salida.
• Características
• No se basan en un contador de programa (al menos conceptualmente) en
tanto en cuanto la posibilidad de ejecución de las instrucciones solamente
viene determinada por la disponibilidad de los argumentos de entrada de las
instrucciones
• Cada etapa de procesamiento es un filtro.
• Los datos pasan de un filtro a otro mediante canales.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Ventajas
• La ejecución fuera de orden se ha convertido en
el paradigma computacional por excelencia desde los años 90. Es una
forma de flujo de datos restringido. Este paradigma introdujo la idea de
ventana de ejecución, que sigue el orden secuencial de la arquitectura de
von Neumann; sin embargo, dentro de la ventana se permite que las
instrucciones sean completadas en el orden de las dependencias de datos.
• Desventajas
• La complejidad lógica de mantener el rastro de las dependencias de datos
de forma dinámica restringe a los procesadores basados en ejecución
fuera de orden a un reducido número de ejecuciones (de 2 a 6) y limita el
tamaño de la ventana de ejecución de 32 a 200 instrucciones, mucho
menor que las utilizadas en las máquinas puras de flujo de datos.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Tuberías y Filtros: Por los tubos fluyen dato, y son salidas de un filtro y la
entrada de otro. Cada filtro admite uno o varios tubos. Cada filtro es
independiente del resto y no conocen la identidad de los filtros antes y después
de él. No importa la secuencia (paralelismo).
• https://medium.com/@crscardellino/procesando-datos-con-spark-i-configuran
do-apache-spark-y-apache-zeppelin-b8dbda672aa4
• Soluciones :
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Tuberías y Filtros
• Diseño :
• Dividir la tarea en una secuencia de etapas de procesamiento de forma
que la salida de cada etapa sólo dependa de las salidas de sus etapas
adyacentes.
• Definir el formato de los datos que se transmitirán a través de los
canales entre etapas adyacentes (p.ej. ASCII, XML, JSON…).
• Llamadas directas entre filtros.
• Colas con productores/consumidores.
• UNIX pipes
• Middleware (colas de mensajes)
ESTILOS ARQUITECTONICOS
• FLUJO DE DATOS
• Secuencial por Lotes: Los componentes son programas independientes, cada
paso de ejecuta hasta completarse antes que se inicie el paso siguiente.
ESTILOS ARQUITECTONICOS
• Flujo de datos
• Secuencial por Lotes
• Es la estructura típica de un sistema de procesamiento de datos tradicional
por lotes (batch).
• Cada proceso se ejecuta completamente antes de comenzar la ejecución del
siguiente.
• Ventajas
• Utilizados en grandes sistemas de software.
• La descomposición en módulos disminuye la complejidad.
• Persiguen escalabilidad y modificabilidad.
• Desventajas
• Dependencia y acoplamiento entre módulos.
• La reutilización y el mantenimiento son difíciles
ESTILOS ARQUITECTONICOS
• Llamada y retorno:
• Arquitectura en Capas
• Organización jerárquica, cada capa provee
servicios a su superior y es un cliente para la
inferior.
• Las capas interiores pueden estar ocultas
(restricciones) Ej: protocolos de
comunicación
• Permiten particionar conceptualmente
problemas complejos
• Favorecen la reusabilidad
https://www.youtube.com/watch?v=Wg68_U
g2LSs
ESTILOS ARQUITECTONICOS
• Llamada y retorno:
• Arquitectura en Capas
• En una arquitectura n-layer las capas solamente
interactúan con sus capas adyacentes lo que
permite abstraer funcionalidades de las capas
superiores e inferiores.
• El numero de capas mínimo debe ser de dos.
• Hay varias capas definidas, cada una de ellas realiza
operaciones que se acercan progresivamente al
conjunto de instrucciones de la máquina.
• En la capa externa los componentes sirven a las
operaciones de interfaz del usuario.
• En la capa interna los componentes sirven como
interfaz con el sistema operativo.
• Las capas intermedias proporcionan servicios de
utilería y de SW de aplicaciones
ESTILOS ARQUITECTONICOS
• Codigo Movil: Esta familia de estilos enfatiza la portabilidad. Ejemplos de la
misma son los intérpretes, los sistemas basados en reglas y los procesadores
de lenguaje de comando.
• Arquitectura de Máquinas Virtuales: El estilo comprende básicamente dos
formas o sub-estilos, que se han llamado intérpretes y sistemas basados en
reglas.
• El enfoque de máquina virtual, por otra parte, no incluye alguna funcionalidad
adicional, sino que más bien proporciona una interfaz que es idéntica al
hardware simple que está en la base. A cada proceso se le presenta una copia
(virtual) del computador particular.
ESTILOS ARQUITECTONICOS
• PEER TO PEER:
• Consiste por lo general en procesos independientes o entidades
que se comunican a través de mensajes. Cada entidad puede
enviar mensajes a otras entidades, pero no controlarlas
directamente. Miembros de la familia son los estilos basados en
eventos, en mensajes en servicios y en recursos.
ESTILOS
ARQUITECTONICOS
• PEER TO PEER:
• Arquitectura Basada en Eventos: Una arquitectura basada en eventos consta
de productores de eventos que generan un flujo de eventos, y consumidores de
eventos que escuchan los eventos. Los eventos se entregan casi en tiempo real,
de modo que los consumidores pueden responder inmediatamente a los
eventos cuando se producen. Los productores se desconectan de los
consumidores — un productor no sabe que los consumidores están
escuchando. Los consumidores también se desconectan entre sí, y cada
consumidor ve todos los eventos.
• https://www.youtube.com/watch?v=i-VmENiPWwA
ESTILOS ARQUITECTONICOS
• PEER TO PEER:
• Arquitectura Orientada a Servicios: Sólo recientemente estas arquitecturas
que los conocedores llaman SOA han recibido tratamiento intensivo en el
campo de exploración de los estilos. Al mismo tiempo se percibe una tendencia
a promoverlas de un sub-estilo propio de las configuraciones distribuidas que
antes eran a un estilo en plenitud.
• https://www.youtube.com/watch?v=7RVzpH6UBRk
PATRONES DE ARQUITECTURA
• Un patrón de arquitectura de software es un esquema genérico probado
para solucionar un problema particular, el cual es recurrente dentro de
un cierto contexto. Este esquema se especifica describiendo los
componentes, con sus responsabilidades y relaciones.
• Objetivos:
• Proporcionar catálogos de elementos reusables en el diseño de
sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya
conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores
condensando conocimiento ya existente.
PATRONES DE
ARQUITECTURA
• Diferencias Estilos y Patrones:
PATRONES DE
ARQUITECTURA
•
Nivel de Abstracción:
PATRONES DE ARQUITECTURA
• POSA: (Pattern Oriented Software Architecture)
• Su objetivo es presentar y dar el esquema de arquitectura de software
orientada a patrones.
• Explicar cada una de las agrupaciones de patrones, los patrones y su
aplicación.
• Mostrar un lenguaje de patrones que facilitara el diseño de la arquitectura de
software a partir de los diferentes patrones.
Distribuido
Estructura Iterativos Adaptables
s
Presentación – Abstracción
Tuberías y Filtros Reflection
– Control
Pizarra
PATRONES DE ARQUITECTURA
• Estructura
• Capas: El Patrón de arquitectura por capas es una de las
técnicas más comúnes que los arquitectos de software utilizan
para dividir sistemas de software complicados.
PATRONES DE ARQUITECTURA
• Estructura
• Capas
https://www.youtube.com/watch?v=Dp0MqNFm870
PATRONES DE ARQUITECTURA
• Estructura
• Tuberías y Filtros: Consiste en ir transformando un flujo de datos en un proceso
comprendido por varias fases secuenciales, siendo la entrada de cada una la salida
de la anterior. Esta arquitectura es muy común en el desarrollo de programas para
el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con
tuberías (pipe). También es una arquitectura muy natural en el paradigma de
programación funcional, ya que equivale a la composición de funciones
matemáticas. Ejemplo Acme Estudio
PATRONES DE ARQUITECTURA
• Estructura
• Pizarra: El patrón Blackboard es un modelo arquitectónico
de software habitualmente utilizado en sistemas expertos,
multiagente y basados en el conocimiento.
https://www.youtube.com/watch?v=mpEh9cikinw
PATRONES DE ARQUITECTURA
• Distribuidos https://www.youtube.com/watch?v=chsR860gbsk
• Broker: El Broker es un patrón de arquitectura que se utiliza para
estructurar sistemas de software distribuidos con componentes
desacoplados que interactúan por invocaciones de servicios
remotos. Esto quiere decir que, si un componente necesita un
servicio de otro que está en otra ubicación que no conoce, el
broker se encarga de proporcionar la conexión.
PATRONES DE ARQUITECTURA
• Distribuidos
• Broker:
• Servidor: Implementan objetos que exponen su funcionalidad a través de
interfaces que consisten en operaciones y atributos. Se pueden clasificar
en dos tipos: Servidores que ofrecen servicios comunes a muchos
dominios de aplicación y Servidores específicos para dominios específicos.
• Cliente: Los clientes son aplicaciones que accesan los servicios de, al
menos, un servidor. La interacción entre clientes y servidores se basa en
un modelo dinámico, lo cual significa que los servidores también pueden
actuar como clientes. Los clientes no necesitan conocer la ubicación de
los servidores que accedan.
• En el primer paso, se confirma que hay suficiente información acerca de los requisitos. En esencia, se
asegura que los stakeholders han dado prioridad a los requisitos de acuerdo a los objetivos de negocio y a
la misión.
• El arquitecto, prioriza la lista de requerimientos para determinar en qué elementos del sistema se deben
concentrarse durante el diseño. Los requisitos que no han sido priorizadas deberán ser marcados y
devueltos a para su clasificación.
• Además, se debe determinar si existe suficiente información acerca de los atributos de calidad del
sistema.
Estímulo fuente
Estímulo
Artefacto
Entorno
Respuesta
Respuesta de medida
El Método Attribute Driven Design
2. Seleccionar un elemento del sistema para descomponer
Se debe elegir qué elemento del sistema será el enfoque de diseño.
• Si es la primera vez que se llega este pasó, el elemento a elegir es el propio
sistema.
• De lo contrario, el sistema ha sido divido en dos o más elementos y los
requerimientos han sido asignados a estos elementos y se debe elegir uno de
estos elementos basándose en estas 4 áreas:
Considera los siguientes posibles valores para el segundo elemento del par de importancia:
• Una de las vistas que se puede crear es la vista funcional de los elementos y
las relaciones entre ellos, que hasta el momento se tienen identificados. Otra
vista que en este punto se puede capturar es un diagrama de secuencia.
El Método Attribute Driven Design
4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.5. Describir los patrones seleccionados para iniciar la documentación de
las diferentes vistas arquitectónicas.
El Método Attribute Driven Design
• 4. Elige un concepto de diseño que satisfaga los drivers arquitecturales
4.6 Evaluar y resolver inconsistencias en el diseño conceptual
En esta parte el arquitecto puede construir modelos para describir el
comportamiento del sistema.
Las tareas iniciales de la evaluación de inconsistencias son:
a. Evaluar el diseño contra los drivers arquitectónicos. Si es necesario,
usar patrones, experimentos, simulaciones, análisis formal y métodos
de evaluación de arquitecturas.
b. Determinar si hay algún driver arquitectónico que no fue
considerado.
c. Evaluar patrones alternativos o aplicar tácticas adicionales, si el
diseño no satisface los drivers arquitectónicos.
d. Evaluar el diseño del elemento actual contra el diseño de otros
elementos en la arquitectura y resolver cualquier inconsistencia.
El Método Attribute Driven Design
5. Instanciar los elementos arquitectónicos y asignar responsabilidades
• En esta etapa se muestra como los elementos de diseño serán instanciados
para usar los drivers arquitectónicos funcionales.
• Los drivers funcionales son derivados de los requerimientos funcionales
abstractos (por ejemplo las características) o de requerimientos funcionales
concretos (casos de uso o lista de responsabilidades).
• Actividades a seguir en este paso:
• Asignar los requerimientos funcionales del elemento padre a los
elementos hijo.
• Definir responsabilidades de los elementos hijo.
• Descubrir el intercambio necesario de información entre elementos,
creando una relación productor/consumidor.
• Especificar interacciones entre elementos.
• Representar la arquitectura con vistas.
El Método Attribute Driven
Design
6. Definir interfaces para elementos instanciados.
• En este paso se definen los servicios y propiedades requeridas y otorgadas
por los elementos de software en el diseño.
• En este paso se realizan los siguientes tres subpasos:
• Utilizar los requerimientos funcionales que involucran a los elementos
instanciados en el paso 5.
• Observar cualquier operación que es producida por algún elemento y
consumida por otro. Considerar las interfaces desde la perspectiva de
diferentes vistas. Por ejemplo, una vista de componentes permitirá
analizar el flujo de información.
• Registrar lo encontrado en la documentación de interfaz para cada
elemento.
El Método Attribute Driven
Design
6. Definir interfaces para elementos instanciados.
• Una vez que se han completado los pasos del 1 al 7, se tiene una
descomposición de elementos padre en los elementos hijo. Cada elemento
hijo es una colección de responsabilidades, y tiene una descripción de
interfaz, requerimientos funcionales, requerimientos de atributos de calidad
y decisiones de diseño. Ahora se puede regresar al proceso de
descomposición en el paso 2 donde se selecciona al siguiente elemento a
descomponer.