Procesos Integradores Performance

Arquitectura de Sistemas

Alejandro Spichiger

Conceptos de Arquitectura de Sistemas

• La palabra arquitectura es ampliamente usada en las más variadas disciplinas


• Hoy en día los computadores se encuentran en cualquier lugar: Datacenters, escritorios, automóviles, lavadoras, etc..

• No importa su tamaño, si son simples o complejos equipos, todos tienen 3 partes fundamentales: Hardware, Software y Datos

• Si tratamos de entender que hace cada componente, cómo trabajan en conjunto e interactúan con el mundo exterior pensamos en la arquitectura


• Definición:

“Especificación de la estructura de un sistema, entendida como la organización de componentes y relaciones entre ellos, los requerimientos que debe satisfacer y las restricciones a las que está sujeto”

Distintos escenarios y retos

• Cada escenario plantea retos, condiciones y necesidades diferentes

• Que herramientas, personas, presupuesto, conocimiento y tiempo necesitamos para cada escenario?

Caso Mansión Winchester

Caso Mansión Winchester

• Su construcción tardó 38 años (terminada en 1922)

• Mansión de estilo victoriano con 160 habitaciones

• Tres ascensores• 47 chimeneas• Sistema de alcantarillado y calefacción

La arquitectura de la mansión sorprende a todos

Qué tiene que ver esta construcción con el mundo del desarrollo de software?

• Lamentablemente llevando este caso al contexto de desarrollo de software es más común de lo que debería

• Cuando un desarrollador es asignado a mantener y evolucionar un sistema legado, cuya arquitectura tiene fallas o no está documentada, elige construir partes o crear sus propias rutas dentro del código

Arquitectura de sistemas

“Programar sin una arquitectura en mente, es como explorar una gruta, sólo con una linterna: no sabes donde estás, dónde has estado ni para donde vas”

Danny Thorpe

Ejercicio de los 3 Interruptores• Hay 3 Interruptores fuera de una

habitación con la puerta cerrada• Por desgracia no sabemos cuál de

los 3 interruptores enciende la luz al interior de la habitación

• Tenemos la posibilidad de accionar los interruptores cuantas veces queramos, pero sólo podremos abrir una sola vez la puerta

• Será posible determinar con un 100% de certeza cuál interruptor que enciende la luz?

Supuesto : No es posible mirar por las ranuras de la puerta

Accionar interruptor 1 por 5 minutos

Apagar interruptor 1

Accionar interruptor 2

Abrir la puerta

Tocar ampolleta

El interruptor 2 es el correcto

¿Está encendida la luz?

SI

NO



¿Está caliente?

SI

NO

Ejemplo: The software architect• Sally es un arquitecto de software que está pensando en

cambiar el software de administración de inventario de activos de TI de su empresa por uno mejor y que se ajuste a los cambios y necesidades del negocio

• En primera instancia no parece mayor problema, hace reuniones con unas pocas personas en la organización buscando nuevos requerimientos

• Sin embargo, diferentes ideas sobre los requerimientos surgen de los diferentes equipos de trabajo

• Por ejemplo, el equipo de logística solicita requerimientos completamente distintos a la gente de staff y la gerencia comercial también solicita los propios

• Sally está preocupada de reconciliar los conflictos de requerimientos para todas las personas que ha entrevistado

• Además está preocupada si se le olvidó alguien importante o si se le pasó por alto, un requerimiento clave

Ejercicio

• Identificar y documentar los requerimientos funcionales de un software que administre el inventario de activos de TI

Ejemplo: The software architect

• Sally en nuestro ejemplo trabaja con diferentes personas, las que tienen diferentes intereses y conceptos sobre el nuevo sistema

• Llamaremos a las personas afectadas por nuestro sistema Stakeholders

• Se necesita identificar claramente a los stakeholders, trabajar con ellos en lo que les preocupa, balancear los inevitables conflictos de prioridades y diseñar la arquitectura que direccione sus requerimientos lo más efectivo posible

Ejercicio

• Identificar a los Stakeholders de nuestro ejemplo

Ejemplo: The software architect• Sally ha logrado entender e involucrarse con las necesidades de los

stakeholders y se siente bien al comprender claramente lo que les preocupa

• Comienza el diseño estructural, crea bocetos de la estructura del sistema, identifica los principales componentes y cómo trabajarán juntos para cumplir con los requerimientos funcionales.

• Finalmente, crea un detallado modelo arquitectónico para mostrárselo a la gente

• Sin embargo, la respuesta de la gente no es la esperada tras recibir el documento. Muchos ni siquiera responden y los que responden se preocupan de detalles menores del sistema


• Al conversar con los stakeholdersresulta aún mas desmotivante.

• La gente de TI está preocupada de cómo se desplegará la aplicación en el datacenter

• Los desarrolladores están preocupados de los flujos de datos y los componentes operacionales

• Pero nadie está preocupado de las funcionalidades más importantes del modelo

Ejercicio

• Discusión: ¿en qué ha fallado Sally hasta el momento?


• Sally está en frente a un problema muy familiar para muchos arquitectos

• Cuál es el principal problema de Sally?• Tratar de describir una compleja arquitectura de un sistema a diferentes personas que necesitan entenderla

• En realidad, este problema ha estado presente para los ingenieros de software desde los primeros días de la computación


• Una de las soluciones para esto son las vistas arquitectónicas

• Una vista arquitectónica es una descripción de un aspecto de la arquitectura del sistema

• Utilizando el concepto de divide y vencerás, a través de distintas vistas se puede describir y explicar una compleja arquitectura de un sistema


• Volviendo a nuestro ejemplo, Sally decide usar un set de vistas que representan la arquitectura de su sistema

• Sus ideas son aprobadas y comienza el desarrollo del sistema en su primera versión

• Sin embargo, surgen nuevas complicaciones

Ejercicio

• Discusión: ¿Qué aspectos de la arquitectura de software no han sido considerados??

Ejemplo: The software architect• Luego de las pruebas de integración y carga al sistema, Sally

comienza a preocuparse por el performance.• Ella ve que el desempeño de las pruebas es pobre y al

mismo tiempo, el grupo de auditoría empieza a cuestionar la seguridad del sistema

• Sally se siente muy afectada, ya que nadie antes mencionó temas como performance o seguridad

• Por si fuera poco, la gerencia corporativa envió un e-‐mail solicitando que toda información se guardara a lo menos por 2 años por temas legales, además solicitó la capacidad a los sistemas de poder recuperarse ante un desastre en un site remoto, con máximo 8 horas de pérdida de servicio


• El arquitecto de nuestro ejemplo, se ha preocupado de identificar qué hace el sistema, pero no en el cómo lo hace

• La arquitectura que se escoge para el sistema dictamina qué tan rápido se ejecuta, cuan seguro es, cuan disponible está, cuan fácil es de modificar, y muchos otros factores no funcionales que colectivamente llamaremos atributos de calidad

El rol de un Arquitecto de Software

• Nos podemos encontrar con muchas definiciones en cuanto a un rol de un arquitecto ( Senior developer, experto en middelware o en diseño de base de datos)

• Pero antes de mencionar que labores realiza un arquitecto de software debemos entender exactamente cuál es su trabajo.

Definición del proceso Arquitectónico

“Es el proceso mediante el cual, las necesidades y preocupaciones de los stakeholders son capturadas, una arquitectura para satisfacer estas necesidades es diseñada, la arquitectura debe ser clara y no ambigua, la cual es representada por vistas arquitectónicas”

Arquitectura v/s Diseño• La pregunta que surge es: • ¿La definición de arquitectura es justo una parte del diseño?¿O es algo más que eso?

• Por un lado, el análisis de requerimientos, es una actividad enfocada en el espacio de problemas y se centra en lo que el sistema “es posible de realizar”

• Por otro lado el Diseño es una actividad enfocada en el espacio de soluciones y apunta principalmente a un grupo de personas – los desarrolladores

Arquitectura v/s Diseño

• La arquitectura se encarga de entender las necesidades de los stakeholders, balancear o compensar estas necesidades

Arquitectura v/s Diseño

• Por lo tanto la definición de arquitectura obedece más a una labor de descubrimiento más que sólo capturar requerimientos y funcionalidades

• La teoría siempre dice: “No trates de pensar en la solución sin antes comprender el problema”


“El arquitecto es responsable de diseñar, documentar y liderar la construcción de un sistema que reúna las necesidades de todos los stakeholders”


1. Identificar y comprometer a los stakeholders

2. Entender y capturar las necesidades de los stakeholders

3. Crear y tomar como propia la definición de la arquitectura que se ajuste a esas necesidades

4. Tomar un rol de líder en el traspaso de una arquitectura a un producto de software

Cuatro aspectos del rol de un arquitecto de software

Responsabilidades de un arquitecto de software

• Asegurarse que el alcance, contexto y restricciones estén documentadas y aceptadas

• Identificar, comprometer e involucrar a los stakeholders

• Facilitar la toma de decisiones a todo nivel, asegurándose de que son hechas con la mejor información posible y que estén alineadas con las necesidades de los stakeholders

• Capturar e interpretar los aportes técnicos de los especialistas

Responsabilidades de un arquitecto de software

• Definir y documentar la forma y estructura del sistema

• Definir y documentar estrategias, estándares y directrices para la construcción del sistema

• Asegurarse que la arquitectura reúna los atributos de calidad requeridos

• Desarrollar como propias las vistas arquitectónicas

• Proveer liderazgo técnico


Alejandro Spichiger

StakeHolders• Las personas afectadas por el sistema no se limitan sólo a quienes la usan

• También hay personas que lo diseñan, construyen, operan, reparan y por supuesto pagan por el.

• Cada grupo de personas tienen sus propios requerimientos, propios intereses y propias necesidades del sistema.

• Llamaremos colectivamente a estas personas, Stakeholders

StakeHolders

• Definición:

“En la arquitectura de software, un stakeholders es una persona, grupo o entidad con un interés o preocupación sobre la realización de la arquitectura”

Selección de los Stakeholders

• Desafortunadamente no hay un criterio único para definirlos

• La selección depende de un rango de factores como por ejemplo las metas del sistema, consideraciones políticas, disponibilidad de recursos, costos, etc.

• Principio: “Un buen stakeholders en la arquitectura está informado, comprometido, autorizado y es representativo”

Selección de los Stakeholders

• Criterios:– Informado: ¿Tiene la información, la experiencia y el conocimiento para tomar buenas decisiones?

– Comprometido:¿Está dispuesto por sí mismo a ser parte del proceso y preparado para tomar decisiones difíciles?

– Autorizado:¿Podemos estar seguro que las decisiones no se volverán atrás, potencialmente con altos costos?

– Representativo: Si un stakeholders es un grupo en lugar que una persona, las personas seleccionadas del grupo son representativas y reúnen los criterios de los stakeholders individualmente?

Clases de stakeholdersClase Descripción

Comprador/Cliente Supervisan la adquisición del sistema o producto

Asesores Supervisan el cumplimiento de normas y regulaciones legales

Comunicadores Explican el sistema a otros stakeholders vía documentación y materiales de entrenamiento

Desarrolladores Construyen y despliegan el sistema a partir de las especificaciones

Proveedores Construyen y/o proveen el hardware, software o infraestructura en donde correrá el sistema

Equipo de soporte Provee soporte a usuarios del producto o sistema cuando está en ejecución

Administradores de sistema Ejecutan el sistema una vez que se ha desplegado

Testers Prueban el sistema para asegurarse de queestá apto para su uso

Usuarios Definen las funcionalidades del sistema y hacen uso de ellas

Responsabilidades de los stakeholders

• Asegurarse de lo que les concierne esté claramente comunicado al arquitecto

• Los representantes de otros stakeholders deben transmitir claramente las necesidades de a quienes representan

• Tomar decisiones oportunas y con autoridad• Si un stakeholders no tiene la autoridad para tomar una decisión, debe ser capaz de escalarla a otro que si pueda tomarla

• Revisar las vistas arquitectónicas y asegurar de que el sistema satisfaga sus necesidades

Ejemplo plantilla Stakeholders


Alejandro Spichiger

Calidad del software

• “I do not worry whether something is cheap orexpensive. I only worry if it is good. If it is goodenough, the public will pay you back for it”

Walt Disney

Calidad del software

• La calidad es relativa a las personas, a su edad, a las circunstancias del trabajo, el tiempo, etc..

• Un caramelo para un niño• Un mapa gastronómico mundial• Un Ferrari del año• El tiempo varía las percepciones

Definiciones de Calidad

• Propiedad o conjunto de propiedades inherentes a una cosa, que permiten apreciarla como igual, mejor o peor que las restantes de su especie (DRAE).

• Totalidad de las características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implícitas (Norma UNE 66-‐001-‐92 traducción de ISO 8402).

Conceptos de Calidad

• No es absoluto• Está sujeto a restricciones• Trata de compromisos aceptables• Es multidimensional• Los criterios de calidad no son independientes

Calidad del software• Hay que tener en cuenta a la hora de abordar la calidad en el software un conjunto de características del mismo que lo hace un producto particular:– Se desarrolla, no se fabrica en el sentido clásico del mismo.– Se trata de un producto lógico, sin existencia física.– No se degrada con el uso.– Por la complejidad del SW y la ausencia de controles adecuados, se suele entregar el SW conscientemente con defectos (incluso públicamente declarados).

– Un gran porcentaje de la producción se hace aún a medida en vez de emplear componentes existentes y ensamblar.

– Es muy flexible. Se puede cambiar con facilidad e incluso reutilizar fragmentos.

Definición de Calidad del software

• Definición oficial (IEEE Std. 610-‐1990) Es el grado con el que un sistema, componente o proceso cumple:–Los requisitos especificados.–Las necesidades o expectativas del cliente o usuario.

Modelos de calidad

• Pressman (2002) indica que los factores que afectan la calidad del software no cambian

• Estudiaremos los modelos producidos desde los años 70 hasta ahora

• McCall (1977), FURPS (1987), ISO/IEC 9126 (1991) adaptado para la arquitectura de software propuesto por Losavio (2003)

Modelo de MacCall• El modelo de MacCall fue el primero presentado en 1977

• Se focaliza en el producto final identificando los atributos de calidad desde el punto de vista del cliente

• Estos atributos se denominan factores de calidad• Organiza los factores en 3 ejes o puntos de vista: Operación, Transición y Revisión

• Cada factor se desglosa en criterios de calidad• Las métricas desarrolladas se relacionan con los factores de calidad y la relación que se establece se mide en función del grado de cumplimiento de los criterios

Modelo de MacCall

Modelo de MacCallEje Factor Criterio

Operación del producto

Correctitud

Rastreabilidad

Completitud

Consistencia

Confiabilidad

Consistencia

Exactitud

Tolerancia a fallas

Eficiencia

Eficiencia en la ejecución

Eficiencia dealmacenamiento

IntegridadControl de acceso

Auditoría de acceso

Usabilidad

Operabilidad

Entrenamiento

Comunicación


Revisión del producto

MantenibilidadSimplicidad

Corrección

Capacidad de Prueba

Simplicidad

Instrumentación

Auto-‐Descriptividad

Modularidad

Flexibilidad


Capacidad de expansión

Generalidad

Modularidad


Transición del producto

Portabilidad


Independencia del S.O.

Independencia del HW

Reusabilidad


Generalidad

Modularidad

Independencia del S.O.

Independencia del HW

Interoperablidad

Simplicitud de comunicación

Simplicitud de datos

Modularidad

Modelo de FURPS (1987)• Modelo desarrollado por Hewlett Packard (HP) en1987, empleando un conjunto de factores decalidad de software y sus respectivos atributos.

• Funcionalidad (Functionality), usabilidad(Usability), confiabilidad (Reliability), desempeño(Performance) y capacidad de soporte(Supportability).

• Basado en el modelo de MCCALL.• Se utilizan para establecer métricas de la calidadpara todas las actividades del proceso dedesarrollo de un software

Modelo de FURPS (1987)Factor Criterio

Funcionalidad

Características y capacidades del programa

Generalidad de las funciones

Seguridad del sistema

Facilidad de Uso

Factores humanos (Interacción)

Factores estéticos

Consistencia de la interfaz

Documentación

Confiabilidad

Frecuencia y severidad de las fallas

Exactitud de las salidas

Tiempo medio de fallos

Capacidad de recuperación ante fallas

Capacidad de predicción

Modelo de FURPS (1987)Factor Criterio

Rendimiento

Velocidad del procesamiento

Tiempo de respuesta

Consumo de recursos

Rendimiento efectivo local

Eficacia

Capacidad de soporte

Extensibilidad

Adaptabilidad

Capacidad de pruebas

Capacidad de configuración

Compatibilidad

Requisitos de instalación

Modelo ISO/IEC 9126

• Éste estándar es una simplificación del modelo de MacCall e identifica seis características básicas de calidad que pueden estar presentes en cualquier producto de software

Modelo ISO/IEC 9126Característica Subcaracterística

Funcionalidad

Idoneidad

Precisión

Interoperabilidad

Seguridad

Fiabilidad

Madurez

Tolerancia a Fallos

Capacidad de recuperación

Usabilidad

Inteligibilidad

Facilidad de aprendizaje

Operabilidad

Atractividad

Modelo ISO/IEC 9126Característica Subcaracterística

EficienciaComportamiento en el tiempo

Utilización de recursos

Mantenibilidad

Capacidad para ser analizable

Cambiabilidad

Estabilidad

Pruebabilidad

Portabilidad

Adaptabilidad

Facilidad de instalación

Coexistencia

Intercambiabilidad

Ejemplos de métricas

• Completitud de implementación funcional– Fórmula: X= 1 –A/B• Donde

– A= Número faltante de funciones– B= Número de funciones descritas en especificación de requisitos

• 0 <= X <= 1 (Entre más cercano a 1, más completa)• Fuente de medición= Documentación del sistema

Algunos atributos de Calidad

• Funcionalidad• Fiabilidad• Usabilidad• Eficiencia• Mantenibilidad• Portabilidad

Funcionalidad

• Habilidad del software de realizar las funciones para las que fue creado

Atributos de la Funcionalidad• Idoneidad: Capacidad del producto de software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuarios especificados

• Precisión: Capacidad del producto software para proporcionar los resultados o efectos correctos o acordados, con el grado necesario de precisión

• Interoperabilidad: Capacidad del producto de software para interactuar con uno o más sistemas especificados

• Seguridad: Capacidad del producto de software para proteger la información y datos de manera que las personas o sistemas no autorizados no puedan leerlos o modificarlos

Fiabilidad

• Habilidad del software para mantenerse operativo (funcionando) dentro de condiciones normales

Atributos de la fiabilidad• Madurez: Capacidad del producto de software para evitar fallar como resultado de fallos en el software

• Tolerancia a fallos: Capacidad del software de mantener un nivel especificado de prestaciones en caso de fallos de software o de infringir sus interfaces especificados

• Capacidad de recuperación: Capacidad del producto de software para restablecer y recuperar los datos directamente afectados en caso de fallo

Usabilidad

• Habilidad del software para que el usuario invierta el mínimo esfuerzo

Atributos de la usabilidad• Inteligibilidad: Capacidad del producto de software que permite al usuario entender si el software es adecuado y cómo puede ser usado para unas tareas o condiciones particulares

• Facilidad de aprendizaje: Capacidad del producto de software que permite al usuario aprender sobre su aplicación

• Operabilidad: Capacidad del producto de software que permite al usuario operarlo y controlarlo

• Atractividad: Capacidad del producto de software para ser atractivo al usuario

Eficiencia

• Habilidad del software para responder a una petición del usuario a una velocidad apropiada

Atributos de Eficiencia

• Comportamiento en el tiempo: Capacidad del producto de software para proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados, bajo condiciones determinadas

• Utilización de recursos: Capacidad del producto de software para usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas

Mantenibilidad

• Habilidad del software para que el usuario invierta el mínimo esfuerzo para mantenerlo o mejorarlo

Atributos de la mantenibilidad• Capacidad para ser analizable: Es la capacidad del producto de software para serle diagnosticadas deficiencias o causas de los fallos en el software o para identificar las partes que han de ser modificadas

• Cambiabilidad: Capacidad del producto de software que permite una determinada modificación sea implementada

• Estabilidad: Capacidad del producto de software para evitar efectos inesperados debidos a modificaciones de software

• Pruebabilidad: Capacidad del producto de software que permite que el software modificado sea validado

Portabilidad

• Habilidad del software para ser transferido de un ambiente a otro y funcionar en este

Atributos de la portabilidad• Adaptabilidad: Capacidad del producto de software para

ser adaptado a diferentes entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos proporcionados para este propósito por el propio software considerado

• Facilidad de instalación: Capacidad del producto de software para ser instalado en un entorno especificado

• Coexistencia: Capacidad del producto de software para coexistir con otro software independiente, en un entorno común, compartiendo recursos comunes

• Intercambiabilidad: Capacidad del producto de software para ser usado en lugar de otro producto software, para el mismo propósito, en el mismo entorno

Ejercicio: Identifique los atributos de calidad presentes en la siguiente vista

Cliente 1

Cliente 2

Cliente 3

INTERNET

Servidor de servicios 1

Servidor de servicios 2

Servidor Base de datos 1

Servidor Base de datos 2

Transacción

Transacción

Réplica

Mensajes SOAP

Mensajes SOAP

Respuestas XML Respuestas XML


• Inteligibilidad : Qué porción de las funciones del sistema son evidentes para el usuario– Fórmula: X= A/B• Donde

– A= Número de funciones evidentes al usuario– B= Total de funciones

• 0 <= X <= 1 (Entre más cercano a 1, mejor)• Fuente de medición= Documentación del sistema


• Eficiencia : Tiempo estimado en completar una tarea– Fórmula: X (tiempo calculado o estimado)• Donde

– X = Tiempo en seg

• Fuente de medición: Sistema operativo, herramientas de testing


• Cambiabilidad : Registro adecuado de cambios a la especificación

• Fórmula: X = A/B• Donde

– A = Número de cambios a funciones o módulos que tienen registros de cambios

– B = Total de funciones o módulos modificados– 0 <= X <= 1 (Entre más cercano a 1, mejor)– 0 indica un control de cambios deficiente

• Fuente de medición: Bitácora de versiones

Trabajo N°1

• Tomar como ejemplo algún software desarrollado por Ud. o presente en su empresa y aplicar métricas de calidad de alguno de los modelos de calidad revisado en clases.

• Entrega de informe escrito más presentación


Alejandro Spichiger

Vistas y Puntos de Vistas

• ¿Cuáles son los elementos funcionales principales de tu arquitectura?

• ¿Cómo esos elementos interactúan con otros y con el mundo exterior?

• ¿Qué información será almacenada, procesada y presentada?

• ¿Qué hardware y software soportarán las funcionalidades y la información?

• ¿Con qué ambientes contamos para desarrollar, probar y capacitar?


• Puede resultar tentador responder todas estas preguntas en un único modelo

• ¿Recuerdan lo que le pasó a Sally en el ejemplo de la primera clase?

• Un solo modelo es el peor de los mundos• Los autores hacen hincapié en que no es posible describir una arquitectura utilizando un único modelo


• Principio:“No es posible capturar las características funcionales y atributos de calidad de un complejo sistema en un único modelo que sea comprensible y entregue valor a todoslos stakeholders”

• Estrategia:“Un complejo sistema se representa de forma mucho más efectiva, usando un set de vistas relacionadas, que colectivamente ilustran las características funcionales y atributos de calidad necesarios para cumplir las metas y objetivos del sistema”

Vistas Arquitectónicas• Una vista arquitectónica es la manera de retratar aspectos o elementos estructurales que son relevantes del sistema para un grupo de stakeholders

• En 1995 Phillipe Kruchten publicó un escrito ampliamente aceptado para describir los puntos de vista: “Architectural Blueprints – The 4+1 View Modelof Software Architecture”

• La publicación sugiere cuatro diferentes vistas de un sistema y un set de escenarios (casos de uso)

• Más recientemente el estándar IEEE 1471 formaliza estos conceptos y estandariza la terminología

Puntos de Vista

• En el modelo 4+1 Kruchten define cuatro vistas estándar llamadas: Lógica, despliegue, de procesos y física

• El estándar IEEE hace de esta idea genérica y no especifica un set de vistas u otro, proponiendo el concepto de punto de vista

• Un punto de vista es un conjunto de patrones, plantillas y convenciones para la construcción de una vista

Puntos de Vista

• La arquitectura de software trata de abstracciones, de descomposición y composición, de estilos y estética

• También tiene relación con el diseño y la implementación de la estructura a alto nivel del software

• Los elementos arquitectónicos escogidos deben satisfacer los requerimientos funcionales y no funcionales como el performance, confiabilidad, escalabilidad, etc..

El modelo 4+1 Kruchten

Vista Lógica Vista de Desarrollo

Vista de Procesos

Vista física

Escenarios

Usuarios finalesFuncionalidad

ProgramadoresAdministradores de software

IntegradoresPerformanceEscalabilidad

Ingenieros de SistemaTopología

Comunicacuones

Vista Lógica

• Se apoya principalmente en los requerimientos funcionales

• Se aplican los principios de abstracción, encapsulamiento y herencia

• Sirve además para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema

• Diagramas : Clases, Comunicación, Secuencia

Diagrama de Clases

Diagrama de comunicación (Colaboración)

Diagrama de Secuencia

Vista de Procesos

• Toma en cuenta atributos de calidad como por ejemplo performance y la fiabilidad (disponibilidad)

• Se enfoca en asuntos como integridad del sistema y tolerancia a fallas

• Muestra cómo se comunican los procesos• Se representa desde la perspectiva de un Integrador de Sistemas

• Diagrama de Actividad

Diagrama de Actividad

Vista de Desarrollo

• Se centra en la organización real de los módulos de software

• El software se empaqueta en partes pequeñas que pueden ser desarrolladas por uno o un grupo de desarrolladores

• Tiene como base analizar reutilización, portabilidad y seguridad

• Diagrama de Componentes

Diagrama de componentes

Vista Física

• Toma en cuenta atributos de calidad como disponibilidad, tolerancia a fallos, performance y escalabilidad

• Esta vista se muestra desde el punto de vista del Ingeniero de Sistemas

• Se muestran todos los componentes físicos del sistema tales como conexiones, servicios, nodos, etc.

• Diagrama de Despliegue

Diagrama de despliegue

Vista de Escenarios

• Los escenarios son de alguna manera una abstracción de los requisitos más importantes del sistema

• Tiene la función de unir y relacionar las otras 4 vistas

• Los elementos de cada vista trabajan conjuntamente mediante el uso de pequeños escenarios relevantes

• Diagrama de casos de uso

Diagrama de Casos de Uso


Alejandro Spichiger

Diagrama de Flujo de Datos DFD

• Objetivo: Construir un modelo lógico del sistema que facilite la comprensión de alto nivel

• Establece “Qué” funciones se deben desarrollar sin implicar el “Cómo”

• Proporciona una representación del sistema a nivel Lógico y Conceptual

Diagrama de Flujo de Datos DFD

• El resultado de este análisis deberá ser:– Gráfico– Lógico, nunca referido a entornos físicos– Preciso y breve– Comprensible– Debidamente Particionado– Bien documentado– Nunca redundante– No ambiguo

DFD – Elementos básicos

• Proceso: Muestra una parte del sistema que transforma entradas en salidas, suelen ser procedimientos, se representa gráficamente por un círculo

Gestión de Venta

Proceso


• Flujo de datos: Se representan gráficamente por una flecha que entra o sale de un proceso, se usa para describir el movimiento de bloques de información de una parte del sistema a otra, pueden ser flujos direccionales, bidireccionales o convergentes

Flujo de datos


• Almacén de datos: Se utiliza para modelar una colección de datos en reposo, se representa por dos líneas paralelas, normalmente las bases de datos o sistemas de archivos son representados por este componente

Almacén de datos

Archivo Clientes


• Entidad: Es un terminador, representado gráficamente por un rectángulo, indica fuentes (origen) o destinos externos de datos que pueden ser: personas, programas, organizaciones u otras entidades que interactúan con el sistema pero se encuentran fuera de la frontera

Entidad Externa o Terminador

Cliente

Reglas para la construcción de DFDs

• Elegir nombres representativos para los procesos, flujos de datos, almacenamiento y entidades externas– Función: Verbo(Ej: validar, registrar, etc) + Objeto– Evitar palabras de uso exclusivo por parte del usuario– Evitar terminología informática (Rutina, procedimiento, etc..)

• Numerar los procesos para identificarlos de forma rápida y unívoca (los números no indican secuencia)

Reglas para la construcción de DFDs

• Evitar DFDs excesivamente complejos y recargados• Consolidar flujos para ganar legibilidad• Redibujar el DFD tantas veces como sea necesario• Asegurarse que el DFD es consistente– Evitar procesos que tienen entradas pero no salidas– Evitar procesos de generación espontánea, es decir, con salidas pero sin entradas

– Etiquetar todos los componentes, un componente no etiquetado puede ocultar errores importantes

– Cuidado con los almacenes de sólo lectura o sólo escritura– Las entidades externas NO pueden acceder directamente a ningún almacenamiento sin pasar por un proceso de intermediario

Niveles de un DFD

• Se recomienda utilizar hasta 4 niveles de descomposición de diagramas

• Nivel 0: Diagrama de contexto• Nivel 1: Subsistemas• Nivel 2: Funciones de cada subsistema• Nivel 3: Subfunciones asociadas• Nivel 4: Procesos necesarios para el tratamiento de cada subfunción

Diagrama de contexto

• Tiene como objetivo una declaración formal del dominio del sistema

• Un solo proceso representará el área que se está estudiando

• El contexto está definido por los flujos de entrada y salida y las entidades externas

DFD – Ejemplo – Gestión Biblioteca• Petición de Libros: Un usuario puede realizar una petición de uno o más libros a la biblioteca. Presenta el carnet de usuario de la biblioteca y una ficha en la que se detallan los libros pedidos.

• Tipos de préstamo:– SALA El día de la petición.– AYUDANTE Una semana– PROYECTO FIN CARRERA Quince días.– DOCTORADO Un mes.

• Una vez entregados el carné y la ficha, el sistema comprobará y aceptará la petición de los libros solicitados siempre que pueda satisfacer la petición, es decir, cuando haya ejemplares disponibles. Si se acepta la petición, se actualiza el número de unidades de los libros de la biblioteca y se guarda la ficha de préstamo.

DFD – Ejemplo – Gestión Biblioteca• Devolución de libros: Un usuario no puede realizar más

peticiones hasta que no haya efectuado todas las devoluciones de la petición anterior. El usuario, para hacer la petición, necesita el carnet, que no se le entrega hasta que no haya devuelto todos los libros. Sí puede hacer una devolución parcial de los libros. Cuando un usuario realice una devolución, el sistema actualizará el stock de libros y comprobará la fecha de devolución de cada ejemplar para estudiar, en el caso de que la devolución se haga fuera de tiempo, la imposición de una sanción que tiene un coste de $ X por cada ejemplar y días de retraso en la devolución. En este caso, la sanción se emite cuando el usuario entrega el último ejemplar.

• El bibliotecario se encarga de las altas y bajas de los libros de la biblioteca.

DFD – Ejemplo – Gestión Biblioteca




Alejandro Spichiger

Orientación a objetos

• La orientación a objetos es un paradigma que trata conceptos como– Abstracción– Herencia– Polimorfismo– Encapsulamiento– Envío de mensajes– Asociaciones– Agregaciones

UML – Diagrama de Clases

• Clase: Es la unidad básica que encapsula toda la información de un objeto

• En UML una clase es representada por un rectángulo con tres divisiones

<Nombre Clase>

<Atributos>

<Operaciones o métodos>

LavadoraMarcaModeloCapacidadAgregar ropa()Sacar ropa()Agregar detergente()


• Herencia: Indica que una subclase hereda métodos y atributos de la clase padre, además de poseer sus propios atributos y métodos

VehículoMarcaModeloNum de ruedasEncender()Subir()Bajar()

AutomóvilDescapotable

CamionetaTara

Cargar (kilos)Activar Tracción()Modo Deportivo()

Velocidad Crucero()


• Asociación: Es una relación entre clases que colaboran entre sí

Jugador EquipoParticipa en

Jugador EquipoParticipa en

Emplea

Puede ser vice-‐versa

UML – Diagrama de Clases• Cardinalidad: Es la cantidad de objetos de una clase que se relacionan con objetos de la clase asociada.

• Ejemplo:– uno a muchos 1..*(1..n)– Cero a uno 0..1– Muchos a muchos *..*(n..n)

Profesor EstudiantesEnseña1 *

Cajero ClienteAtiende1 1..*

Casa ChimeneaTiene1 0,1


• Agregación: En ocasiones una clase consta de otra clase, el objeto base utiliza al incluido para su funcionamiento

• Composición: Es un tipo representativo de una agregación, se representa por un rombo con relleno, y cada componente puede ser sólo parte de un todo.

Comida

Ensalada Plato de Fondo

Postre

Mesa

Superficie Pata

Agregación Composición


• Clases abstractas: La clase no puede ser instanciada pues posee sólo métodos abstractos, el nombre de la clase está en cursiva

JugadorNombreAlturaPesoCorrer()Pasar()

Defensa

Correr()Despejar()QuitarBalon()

Delantero

Rematar()Correr()

Mediocampista

Paseconventaja()TitoLibre()


• Ejercicio: Realice un diagrama de clases para un equipo de futbol

UML – Diagrama de Secuencias

• Muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo

• Consta de objetos que se representan en modo de rectángulos con nombre (Subrayado)

• Los mensajes se representan con líneas continuas con punta de flecha

• El tiempo es representado como progresión vertical


:Nombre

OBJETO MENSAJE

Asíncrono

Síncrono

Tiempo

:Nombre 1 :Nombre 2


• Ejercicio: Realizar un diagrama de secuencia para la venta de una bebida gaseosa en una máquina dispensadora

UML -‐ Diagrama de comunicación (Colaboración)

• Muestran la forma en que los objetos colaboran entre si

• Es semánticamente equivalente al diagrama de secuencias

• El diagrama de colaboración destaca el contexto y organización general de los objetos que interactúan

• Los mensajes se representan por una flecha que apunta al objeto receptor

• Por lo general, el mensaje indicará al objeto receptor que ejecute una de sus operaciones


• El mensaje finalizará con un par de paréntesis en donde se colocarán los parámetros de la operación (si los hubiera)

• Para representar la información de secuencia se agregará una cifra a la etiqueta del mensaje separada por dos puntos (:)


• Ejemplo al presionar una tecla en un procesador de texto1. La GUI notifica al sistema operativo que se

presionó una tecla2. El sistema operativo notifica a la CPU3. La CPU notifica a la tarjeta de video4. La tarjeta de video envía un mensaje al monitor5. El monitor presenta el carácter alfanumérico en

la pantalla


Tecleo

:GUI

:Sistema Operativo

1: Notificar(Tecleo)

:CPU

2: Actualizar(Tecleo)

:Tarjeta de Video 3: Notificar(Tecleo)

:Monitor

4: Mostrar(Tecleo)

5: Respuesta()


• Ejercicio: Realizar el diagrama de colaboración para el ejemplo de la máquina dispensadora de bebidas gaseosas

UML – Diagrama de Actividad• Muestra lo que ocurre durante la operación de un proceso• Cada actividad es representada por un rectángulo con las

esquinas redondeadas• El procesamiento de cada actividad se lleva a cabo y luego se

prosigue con la siguiente actividad• El inicio del diagrama es representado por un círculo con relleno

y el final con un círculo con otro circulo con relleno en su interior

Actividad 1

Actividad 2

UML – Diagrama de Actividad

• Las decisiones son representadas por un rombo e indicarán la ruta o el flujo a seguir de la operación

Despertar

Desayunar Volver a dormir

¿Con hambre?

SI NO

UML – Diagrama de Actividad• Concurrencia: Son rutas que se ejecutan al mismo tiempo que luego se reúnen

• Se representa por una línea gruesa perpendicular a la transición y

• Para representar la reincorporación, ambas rutas apuntarán a otra línea gruesa

Fin de la Jornada

Baño Descanso

UML – Diagrama de Actividad

• Ejercicio: Realizar un diagrama de actividad que represente la creación de un documento

UML – Diagrama de componentes• Representan la estructura física de nuestro sistema

• Un componente puede ser la representación de más de una clase

• Un componente físico es algo que podemos ver en el disco duro

• Generalmente son archivos, tablas, ejecutables, documentos y cosas por el estilo

• Es un mapa de todos los archivos y tablas que va a manejar la aplicación

UML – Diagrama de componentes

• Un diagrama de componente contiene obviamente componentes, interfaces y relaciones

• Un componente se representa por un rectángulo que tiene otros dos sobrepuestos al lado izquierdo

• Las interfaces es el lazo de unión entre los componentes y se representan con un círculo con el nombre de la interfaz

UML – Diagrama de componentes

ProcesadordeTexto.exe

Un componente provee una interfaz

ProcesadordeTexto.exe

Un componente usa una interfaz

UML – Diagrama de Despliegue

• Se concentra en el hardware del sistema• El Nodo es representado por un cubo con un nombre, y en su interior puede contener componentes que se relacionan con otros nodos


ISP

Internet

Router

Servidor

WinServ 2008

IIS Service

Base de datos SQL Server

Firewall


• Ejercicio: Realizar un diagrama de despliegue que represente un sistema de control de acceso centralizado a instalaciones de una empresa en 3 sucursales.

UML – Diagramas de Casos de Uso

• Representan la forma en como un cliente (actor) opera con el sistema

• Y como los elementos interactúan• Actor, caso de uso, relaciones de uso


• Actor: Es un rol de un usuario con respecto al sistema, por ejemplo Vendedor, Jefe de local, Digitador, etc..

• Caso de uso: Es una operación o tarea específica que se realiza tras la orden de un agente externo (des un actor o desde otro caso de uso

Actor Caso de uso

Relación


• Relaciones:– Asociación: Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

– Dependencia o Instanciación: Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.


• Generalización : Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia(<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

UML – Diagramas de Casos de Uso• Ejemplo Máquina Recicladora: El sistema controla una máquina de

reciclaje de botellas, papeles y plásticos, el sistema debe realizar lo siguiente:– Registrar el número de ítemes ingresados. – Imprimir un recibo cuando el usuario lo solicita:

• Describe lo depositado • El valor de cada item• Total

– El usuario/cliente presiona el botón de comienzo – Existe un operador que desea saber lo siguiente:

• Cuantos ítemes han sido retornados en el día. • Al final de cada día el operador solicita un resumen de todo lo depositado en el

día. – El operador debe además poder cambiar:

• Información asociada a ítemes. • Dar una alarma en el caso de que:

– Item se atora. – No hay más papel.


Depositar item

Generar Reporte

Cambiar Item

Sistema máquina de reciclaje

ClienteOperador


Depositar botella

Depositar papel

Depositar plástico

Un Item puede ser una botella, papel o plástico

Depositar item

<<extends>><<extends>>

<<extends>>


Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Depositar item

Generar Reporte

Imprimir

<<uses>> <<uses>>


Entonces, el diseño completo del diagrama Use Case es:

Depositar botella

Depositar papel

Depositar plástico

Depositar item

<<extends>>

<<extends>>

<<extends>>

Imprimir

Generar Reporte

<<uses>><<uses>>

Cambiar Item

Generar alarma

Procesos Integradores Performance

Documents