04 documento de arquitectura

7/17/2019 04 Documento de Arquitectura

http://slidepdf.com/reader/full/04-documento-de-arquitectura 1/57

Diseño de Sistemas

Clase 4:

Documento de Arquitectura

Hugo R. Cordero S.



Objetivos

• Conocer la evaluación técnica preliminar y su importancia

para la arquitectura

• Conocer los diferentes tipos de estructuras y su presentación

mediante vistas

• Comprender los aspectos de seguridad mínimos a incorporar

dentro de la arquitectura de un sistema

• Conocer una plantilla para el documento de arquitectura

2



Describir en forma general las posibles alternativas desolución preliminares derivadas de la evaluación técnica

preliminar y seleccionar en base de los siguientes criterios:• Costo

• Performance

• Complejidad

• Crecimiento de la funcionalidad

• Limitaciones tecnológicas

• Sensibilidad a los cambios

• Riesgo

• Descontinuación del aplicativo

• Capacidades y limitaciones de los usuarios finales y operadores

Evaluación técnica preliminar

3



Alternativa 2

Lenguaje

Programación: VB

.NETMotor de Base de

datos: SQL SERVER

Servidor: .NET tiene

su propio servidor.

Herramientas

visuales,

componentes COM

y de web services.

Browser: InternetExplorer®

Alternativa 1

Lenguaje

Programación: Java

Motor de Base dedatos: MySQL

Servidor: TOMCAT

Herramientas

Frameworks Struts

Browser: Internet

Explorer®

4

Evaluación técnica preliminar



Vistas y estructuras

Una vista:

• Es una representación coherente de un conjunto de

elementos arquitectónicos y las relaciones entre ellos

• Una vista es una representación de una estructura

Una estructura:

• Es el conjunto de elementos en sí, tal como existen en el

software o hardware.

• Los arquitectos diseñan la estructura y documentan vistas de

esas estructuras

5



Tipos de Estructuras

Tipos de Estructuras (según SEI)• Basado en la representación de tres tipos de estructuras

del sistema de software

– Estructura de módulos

– Estructura de componentes y conectores

– Estructura de localización

6



Tipos de Estructuras

7



Estructuras de módulos

Nos permite responder preguntas como:• ¿Cuál es la principal responsabilidad funcional asignada a

cada módulo?

• ¿Qué otros elementos de software está permitidos de usar

por un módulo?• ¿Qué otro software es actualmente usado o dependiente?

• ¿Qué módulos están relacionados con otros módulos por

relaciones de generalización o especialización?

8



Estructura de módulos

9

Estructuras de Descomposición




10

Estructura de uso de módulos




11

Estructura de capas



Estructura de componentes y conectores

• Implica decisiones en cuanto a cómo el sistema será

estructurado como un conjunto de elementos que tienen un

comportamiento en tiempo de ejecución (componentes) y sus

interacciones (conectores)

• Los elementos son los componentes en tiempo de ejecución

(que son las principales unidades de cómputo y podrían ser

servicios, clientes, servidores, filtros, etc.) y conectores (que

son los vehículos de comunicación entre los componentes.

12



13

Módulos

• Unidades de diseño

• Encierran funcionalidad

o responsabilidad que seaccede a través de una

interfaz

• No se replica

• No interesa la ejecución

Componentes

• Unidad de ejecución

• Tiene una interfaz

definida y accesibledurante la ejecución

• Puede instalarse en

forma independiente

• Puede replicarse

Módulos y componentes



Nos permite responder preguntas como:

• ¿Cuáles son los principales componentes de ejecución y

cómo interactúan en tiempo de ejecución?

• ¿Cuáles son los principales almacenes de datos compartidos?• ¿Qué partes del sistema son replicados?

• ¿De qué manera se procesan los datos a través del sistema?

• ¿Qué partes del sistema pueden ejecutarse en paralelo?

14





15

Estructura de servicios, componentes y conectores




16

Sincronización

Paralelismo

Estructura de concurrencia



Estructura de localización

• Incorporar las decisiones en cuanto a cómo el sistema serelaciona con las estructuras no software en su entorno (por

ejemplo, CPU, sistemas de archivos, redes, equipos de

desarrollo, etc).

• Estas estructuras muestran la relación entre los elementosde software y elementos en uno o más entornos externos en

el cual el software es creado y ejecutado

17




Nos permite responder preguntas como:• ¿Qué procesador tiene cada elemento de software durante su

ejecución?

• ¿En qué directorios o archivos está cada elemento

almacenado durante el desarrollo, las pruebas y laconstrucción del sistema?

• ¿Cómo se asignarán los elementos de software entre los

equipos de desarrollo?

18




19

Estructura de Despliegue (1)




20

Estructura de Despliegue (2)



Notaciones para representar la

arquitectura

21

Genéricos

• UML, Unified Modeling Language

• ADL, Architecture Description Language

Propietarios

• De alguna organización

• Versión particular



Modelos para representar la Arquitectura

• Diferentes modelos que agrupan vistas para representar tota

la arquitectura de un sistema

• Cada vista representa el detalle de alguna parte del sistema

• Principales modelos:

– Modelo 4+1

– Modelo de Siemens

– Modelo propuesto por SEI

22



Modelo de Siemens (o de Nord)

Vista Conceptual• Se describe el sistema en términos de sus elementos

principales de diseño y las relaciones entre éstos, dentro de un

dominio determinado

• Esta vista es independiente de las decisiones deimplementación y enfatiza en los protocolos de interacción

entre los elementos de diseño

Vista de Módulos

• Se captura la descomposición funcional y las capas del sistema

• El sistema es descompuesto lógicamente en subsistemas, y

módulos

23



Modelo de Siemens (o de Nord)

Vista de Ejecución• Se describe la estructura dinámica del sistema en términos de

sus elementos en tiempo de ejecución

• Algunos de los aspectos que se consideran en esta vista son, el

desempeño y el entorno de ejecución

Vista de Código

• Se organiza el código fuente en directorios, archivos y

bibliotecas

• Algunos de los aspectos que se incluyen son, los lenguajes de

programación a utilizar, herramientas de desarrollo, la

administración de la configuración y la estructura del proyecto

24



Modelo de vistas propuesto por SEI

• Esta nueva tendencia está respaldada por el Instituto de

Ingeniería del Software (SEI) con su propuesta "Vistas y

más allá de éstas, enfoque para la documentación de

arquitecturas de software“

• En su propuesta define tres categorías denominadas “tipos

de vista” en las que prácticamente cualquier vista,

dependiendo del tipo de información que contenga puede

pertenecer a una de estas categorías.

25



Vista de módulo

• Describe cómo el sistema es estructurado en un conjunto

de unidades funcionales. Por ejemplo capas:

26




Vista de conectores y componentes

• Describe cómo el sistema es estructurado en un conjunto

de elementos que están en tiempo de ejecución así como

la interacción entre éstos.

27




Vista de localización

• Se describe la relación entre las unidades de software y

los elementos del entorno tales como, hardware o la

organización de los equipos de desarrollo de software

28




• Una vista puede llegar a contener gran cantidad de

elementos, ocasionando en el personal involucrado

dificultad en su interpretación

• La solución a esto es utilizar paquetes de vista, los cuales

contienen un número reducido de elementos, logrando

así una mejor comprensión ya que solo se muestra un

fragmento particular del sistema.

29




• El SEI recomienda que se cuente con una guía de estilos

que contenga entre otros aspectos, la descripción

relevante del estilo, elementos, relaciones, propiedades,

situaciones en las que no es recomendable aplicarlo,

circunstancias en las que se recomienda usar el estilo, y

posibles enfoques analíticos que el arquitecto puede

utilizar.

30




Documentando la arquitectura

• Los arquitectos deben documentar las vistas que sean de

mayor utilidad y no ajustarse a un número fijo de vistas,

como es el caso en las propuestas de Kruchten y Nord.

• Documentar la arquitectura tomando en cuenta losintereses y necesidades de las personas involucradas en el

proyecto, estos intereses se traducen como las cualidades

que el sistema resultante debe poseer.

31



Documentando la arquitectura

UML• Es un lenguaje para especificar, construir, visualizar y

documentar los artefactos de un sistema de software

orientado a objetos. Un artefacto es una información que

es utilizada o producida mediante un proceso dedesarrollo de software

• No define un proceso concreto que determine las fases

de desarrollo de un sistema

• No pretende definir un modelo estándar

de desarrollo

32



Vistas

Estructurales (usando UML)

• Vista de clases

• Vista de paquetes

• Vista de componentes• Vista de despliegue

33



Vista de clases

34



Vista de paquetes

35

Sistema de Venta de Libros OnLine

pe

com

sisvenlib

catalogo

compras

administracion

utilitarios



Vista de componentes

36



Vista de despliegue

37



Vistas

De Comportamiento (usando UML)• Vistas de casos de uso

• Vistas de actividades

• Vistas de comunicación

38



Vista de casos de uso

39



Vistas de actividades

40



Vista de comunicación

41



Vistas del modelo 4+1 vs. UML

42



Otras vistas

• Vistas de código

43



Otras vistas

• Vista de Integración

44



Otras vistas

• Vista de ejecución

45



Seguridad e integridad de los procesos Describir los controles de secuencia de los procesos Batch (procesos

transaccionales que corren nocturnamente). Ej: Cuadro de totales

procesados, validaciones y controles de para transmisiones y/o

procedimientos automáticos.

Proceso : Bat008.4gi

Parámetros: S 1 1 1

----------------------------------------------------

Hora inicio: 21:00:31

Cantidad de registros leídos: 23006

Cantidad de registros procesados : 23006

Cantidad de registros con error: 0

Hora fin: 21:30:58

Definición de la Seguridad

46



Administración de Perfiles de AccesoDefinir y describir los módulos vs. Perfiles de acceso

• Descripción del módulo de seguridad

• Descripción de perfiles.

Aplicativo

Funciónes por Módulo Perfil 1 Perfil 2 ... Perfil NMódulo AConsulta de información deempresas

x x X x

Consulta de operadoresautorizados

x x X x

Consulta de cuentas afiliadas x x X x

Consulta de combinacionesautorizadas

x x X x

Modificación de datos básicos de

empresas

x x X x

Modificación de datos extendidos

de la empresa

x x x

Modificación de operadoresautorizados

Módulo B

x x X x

Modificación de cuentas afiliadas x x X x

Modificación de combinacionesautorizadas

x x X x


47



Administración de Perfiles de Acceso

A continuación podemos observar el tiempo de búsqueda de una clave de

acuerdo a su longitud y tipo de caracteres utilizados. La velocidad de búsqueda

se supone en 100.000 passwords por segundo, aunque este número suele ser

mucho mayor dependiendo del programa utilizado.


48



Administración de Perfiles de Acceso : • Longitud mínima de password

• Número de intentos de acceso fallidos antes de bloquear el acceso

• Número de veces que se puede repetir un password

• Otras políticas de password implementadas

• Confirmación de password al crear cuentas y resetear

• Existencia de opción deshabilitar cuenta y/o eliminar• Métodos de encripción en passwords


49



Controles de Acceso:• Definir y describir los Usuarios genéricos (no aplicativo), como

usuarios del dominio, BD, mail’s, componentes MTS, directorios

compartidos, etc.

• Identificación de usuarios especiales y su necesidad: Ej. DBO, System

Administrador, etc.

• Identificación de programas que manejan elementos confidenciales.Ej. Rutinas de encriptación, etc.

• Identificación de conexiones a redes externas: firewall, puertos y

protocolos.

50




Backups, replicación, procedimientos de recuperación

Respecto a respaldos de información (Backups) La mayoría de aplicaciones

cuenta con respaldos de información generalmente centrada alrededor de

bases de datos. Se está reforzando la necesidad de diseñar e implementar

procesos de respaldo debido a que se ha encontrado que muchas

aplicaciones no están almacenando toda la información crítica para su

funcionamiento.

51

Tareas operativas básicas




•Descripción general – Propósito del sistema

– Objetivo y alcance del diseño

– Definiciones y convenciones

• Requerimientos

– Funcionales

– No funcionales

•Arquitectura del sistema – Contexto del sistema

– Arquitectura general

– Tecnologías seleccionadas

52




• Vistas del sistema

– Vista de módulos

– Vista de casos de uso

– Vista de procesos

– Vista de componentes

– Vista de datos

– Vista de despliegue

– Vista de integración – Vista de concurrencia

53




• Detalles de Implementación

– Plataforma y herramientas

– Organización del proyecto

– Requerimientos de Hardware

– Requerimientos de Software

– Definiciones de Seguridad

– Diseño de archivos y base de datos

– Tareas operativas básicas• Anexos

– Glosario de términos

54



Resumen

• La evaluación técnica preliminar sienta las bases del sistema

a implementar

• Existen tres grupos de estructuras: módulos, de

componentes y conectores, y de localización

• Los modelos 4+1, de Siemens y del SEI son formas de

representar un sistema a través de un conjunto de vistas

• Las vistas estructurales son: de clases, de paquetes, de

componentes y de despliegue

• Las vistas de comportamiento son: de casos de uso, de

actividades y de comunicación

• Administración de los perfiles de acceso y los controles de

acceso son definiciones de seguridad importantes.

55



¿Preguntas?

• ¿Por qué es importante la evaluación técnica

preliminar?

56



Bibliografía

• Ingeniería del Software, 9na. Edición, Ian Sommerville

– Capítulo 6: Diseño arquitectónico

• Ingeniería de Software: Un enfoque práctico, 7ma. edición,

Roger S. Pressman

– Capítulo 8: Conceptos de diseño

– Capítulo 9: Diseño de la arquitectura

• Ingeniería de Software. Un enfoque desde la guía SWEBOK

1ra. edición, S.Sánchez - M.Sicilia - D.Rodriguez

– Capítulo 5: Diseño

• Ingeniería de Software, 1ra. edición, Guillermo Pantaleo y

Ludmila Rinaudo

– Capítulo 13, Arquitectura de software

– Capítulo 14, Diseño de software

04 documento de arquitectura

Documents