DISEÑO DE LA ARQUITECTURA ARQUIT ECTURA DEL DEL SOFTWARE UNIDAD 2 TEMA 2.4.
Ing. Rosa Imelda García Chi
Diseño de software:
El diseño se ha descrito como un proceso multifase en el que se sintetizan representaciones representaciones de la estructura de los datos, la estructura del programa, las características de la interfaz y los detalles procedimentales desde los requisitos de la información.
Según Freeman, el diseño es…
...una actividad en la que se toman decisiones importantes, frecuentemente de naturaleza estructural. Comparte con la programación un interés por la abstracción de la representación de la información y de las secuencias de procesamiento, pero el nivel de detalle es muy diferente en ambos casos.
Según Freeman …
El diseño construye representaciones coherentes y bien planificadas de los programas, concentrándose en las interrelaciones de los componentes de mayor nivel y en las operaciones lógicas implicadas en los niveles inferiores.. .
Se considera que …
El diseño está dirigido por la información.
Los métodos de diseño del software se obtienen del estudio de cada uno de los tres dominios del modelo de análisis:
• El dominio de los datos, • el funcional y comportamiento o • el de comportamient sirven de directriz para la creación del diseño.
¿Qué es el diseño arquitectónico?
El diseño arquitectónico representa la estructura de los datos y los componentes del programa que se requieren para construir un sistema de computadora.
Constituye el estilo arquitectónico que tendrá el sistema, las estructuras de datos y las propiedades de los componentes y la interrelación que tiene con otros componentes com ponentes arquitectónicos del sistema.
¿Quién lo hace?
Lo puede llevar a cabo el ingeniero de software… Aunque se recomienda que… El diseño de la base de datos la lleve a cabo el diseñador de base de datos o almacén de datos y Que el arquitecto del sistema seleccione el estilo de arquitectura a utilizar, según los requisitos recolectados en el análisis. (esto tiene que ver con el modelo de desarrollo de software mas conveniente a utilizar)
¿Por qué es importante?
Proporciona los detalles completos de todo el software que se va a construir.
Se aprecia cada uno de los detalles con conformarán la software.
Asegura que la construcción sea correcta y completa.
¿Cuáles son los pasos?
El diseño arquitectónico comienza con el diseño de datos y después procede a la derivación de una o mas representaciones representaciones de la estructura arquitectónica del sistema.
Arquitectura de Software
Para poder entender el diseño, es necesario comprender que es la arquitectura de software.
Arquitectura de software
La arquitectura de software de un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes componente s del software software,, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos.
La arquitectura no es el software operacional. Más bien, es la representación que capacita al ingeniero del software para: (1) analizar la efectividad del diseño para la consecución de los requisitos fijados, (2) considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil, y (3) reducir los riesgos asociados a la construcción del software.
En el contexto del diseño arquitectónico,
un componente del software puede ser tan simple como un módulo de programa, pero también puede ser algo tan complicado como incluir bases de datos y software intermedio «middleware») «middleware») que permiten la configuración de una red de clientes y servidores.
Propiedades de los componentes
Las propiedades de los componentes son aquellas características necesarias para entender cómo los componentes interactúan con otros componentes.
A nivel arquitectónico, no se especifican las propiedades internas (por ejemplo, detalles de un algoritmo).
Relaciones entre los componentes
Las relaciones entre los componentes pueden ser tan sencillas como una llamada de procedimiento de un módulo a otro, o tan complicadas como el protocolo de acceso a bases de datos.
El diseño de la arquitectura de software tiene en cuenta dos niveles de la pirámide del diseño
Diseño de datos y Diseño arquitectónico arquitectónico
Diseño de datos y Diseño Arquitectónico
En este sentido, el diseño de datos nos facilita la representación de los componentes componentes de datos de la arquitectura.
El diseño arquitectónico se centra en la representación de la estructura de los componentes componentes del software, soft ware, sus propiedades e interacciones.
¿Por qué es importante la arquitectura?
Las representaciones de la arquitectura de software facilitan la comunicación entre todas las partes (partícipes) interesadas en el desarrollo de un sistema basado en computadora; computadora;
La arquitectura …
la arquitectura destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software que sigue, y es tan importante en el éxito final del sistema como una entidad operacional;
la arquitectura «constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes».
La arquitectura…
El modelo de diseño arquitectónico y los patrones arquitectónicos contenidos dentro son transferibles.
Esto es, los estilos y patrones de arquitectura pueden ser aplicados en el diseño de otros sistemas y representados a través de un conjunto de abstracciones que facilitan a los ingenieros del software la descripción de la arquitectura de un modo predecible.
DISEÑO DE DATOS
El diseño de datos (a veces llamado arquitectura de datos) crea un modelo de datos y/o información que se representa con un alto nivel de Abstracción (la visión de datos del cliente/usuario).
Modelo de datos
Este modelo de datos, es entonces refinado en progresivas representaciones especificas de la implementación, que pueden ser procesadas por un sistema basado en computadora.
En muchas aplicaciones de software, la arquitectura de datos tendrá una gran influencia sobre la arquitectura del software que debe procesarlo
Estructura de datos
La estructura de datos ha sido siempre una parte importante del diseño de software. Al nivel de los componentes del programa, el diseño de las estructuras de datos y de los algoritmos asociados requeridos para su manipulación, manipulación, son la parte esencial en la creación de aplicaciones de alta calidad
Modelo de datos
A nivel de aplicación, la traducción de un modelo de datos (derivado como parte de la ingeniería de requisitos) en una base de datos es el punto clave para alcanzar los objetivos de negocio del sistema.
Modelo de datos
A nivel de negocios, el conjunto de información almacenada en las diferentes bases de datos y reorganizada en el almacén de datos facilita la minería de datos o el descubrimiento de conocimiento que puede influir en el propio éxito del negocio. negoc io.
De cualquier modo, el diseño de datos juega un papel muy importante.
Modelado de datos, estructuras de datos, bases de datos y almacén de datos
Los objetos de datos definidos durante el análisis de Requisitos del software son modelados utilizando diagramas de entidad-relación y el diccionario de datos
Del diseño de datos a estructuras de componentes
La actividad de diseño de datos traduce esos elementos del modelo de requisitos en estructuras de datos a nivel de los componentes componentes del software software y, cuando es necesario, a arquitectura de base de datos a nivel de aplicación.
La arquitectura de datos
Durante muchos años, la arquitectura de datos estuvo limitada, generalmente, a las estructuras de datos a nivel del programa y a las bases de datos a nivel de aplicación.
Pero hoy, las empresas grandes y pequeñas están inundadas de datos.
Las empresas y las bases de datos
No es inusual, incluso para una mediana empresa, tener docenas de bases de datos sirviendo diferentes aplicaciones de cientos de gigabytes de datos.
El desafío de las empresas ha sido extraer información útil de su entorno de datos, particularmente cuando la información deseada está funcionalmente interrelacionada (por ejemplo, información que sólo puede obtenerse si los datos de marketing específicos se cruzan con los datos de la ingeniería del producto).
Desafío de TI
Para resolver este desafío, la comunidad de empresas de TI ha desarrollado las técnicas de minería de datos, también llamadas “descubrimiento “descubrimien to de conocimiento en bases de datos” (DCBC), que navegan a través de las bases de datos en un intento por extraer el nivel de información de negocio apropiado.
Múltiples Bases de Datos
Sin embargo, la existencia de múltiples bases de datos, sus diferentes estructuras, el grado de detalle contenido en las bases de datos, y muchos otros factores hacen difícil la minería de datos dentro de un entorno con bases de datos existentes.
Una solución alternativa, llamada almacén de datos, datos, añade una capa adicional a la arquitectura de datos.
Almacén de datos
Un almacén de datos es un entorno de datos separado, que no está directamente integrado con las aplicaciones del día a día, pero que abarca todos los datos utilizados por una empresa
Almacén de datos
En cierto sentido, un almacén de datos es una gran base de datos independiente, independiente, que contiene algunos, pero no todos los datos almacenados en las bases de datos que sirven al conjunto de aplicaciones requeridas en un negocio.
Sin embargo, hay muchas características diferenciales entre un almacén de datos y una base de datos típica
Orientación por materia.
Integración.
Restricciones de tiempo.
No volatilidad.
Orientación por materia. Un almacén de datos está organizado por las materias importantes del negocio, más que por los procesos o funciones del negocio. Esto nos lleva a una exclusión de datos que podrían ser necesarios para una función particular del negocio, pero que generalmente generalmente no son necesarios para la minería de datos.
Integración.
Sin tener en cuenta la fuente de datos, da consistencia nombrar convenciones, unidades y medidas, estructuras de codificación y atributos físicos incluso cuando la inconsistencia existe a través de las diferentes bases de datos orientadas a aplicaciones.
Restricciones de tiempo.
Para un entorno de aplicación orientado a transacción, los datos son precisos en el momento del acceso y por un periodo de tiempo relativamente pequeño (normalmente de 60 a 90 días) antes del acceso. Sin embargo, en un almacén de datos, se accede a los datos en un momento específico del tiempo (por ejemplo, los clientes con los que se ha contactado c ontactado el mismo día que el nuevo producto ha sido anunciado en la prensa comercial). El horizonte típico de tiempo de un almacén de datos es de 5 a 10 años.
No volatilidad.
A diferencia de las típicas bases de datos de aplicaciones de negocios que atraviesan una continua corriente de cambios (insertar, borrar, actualizar), en el almacén de datos los datos se cargan, pero después de la primera transferencia, los datos no cambian.
Diseño de datos a nivel de componentes
El diseño de datos a nivel de componentes componentes se centra en la representación de estructuras de datos a las que se accede directamente a través de uno o más componentes del software.
Análisis de requisitos y diseño
Recordando que el análisis de requisitos y el diseño a menudo se solapan, consideramos el siguiente conjunto de principios para la especificación de datos:
Principios para especificacione especificaciones s 1. Los principios del análisis sistemático aplicados a la función y al comportamiento deberían aplicarse también a los datos. Invertimos mucho tiempo y esfuerzo en obtener, revisar y especificar los requisitos funcionales y el diseño preliminar.
Principios para especificacione especificaciones s
Las representaciones de flujo de datos y contenido deberían desarrollarse y revisarse, las de objetos de datos deberían identificarse, se deberían estudiar las organizaciones alternativas de datos y debería evaluarse el impacto del modelado de datos sobre el diseño del software.
Principios 2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas. El diseño de una estructura de datos eficaz debe tener en cuenta las operaciones que se van a llevar a cabo sobre dicha estructura de datos La especificación de los tipos de datos abstractos puede simplificar considerablemente el diseño del software.
Principios 3. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa. Un diccionario de datos representa explícitamente las relaciones entre los objetos de datos y las restricciones de los elementos de una estructura de datos. Los algoritmos que deben aprovecharse de estas relaciones específicas pueden definirse más fácilmente si existe una especificación de datos tipo diccionario.
Principios 4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño. Se puede usar un proceso de refinamiento paso a paso para el diseño de datos. Es decir, la organización general de datos puede definirse durante el análisis de requisitos; refinarse durante los trabajos de diseño de datos y especificarse en detalle durante el diseño a nivel de componentes.
Principios 4…
El enfoque descendente del diseño de data proporciona ventajas análogas al enfoque descendente del diseño de software: se diseñan y evalúan primeramente los atributos estructurales principales de manera que se pueda establecer la arquitectura de los datos.
Principios 5. La representación de las estructuras de datos deberían conocerla sólo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
Principios 6. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les pueden aplicar. Las estructuras de datos y las operaciones deberían considerarse como recursos para el diseño del software. Las estructuras de datos pueden diseñarse para que se puedan reutilizar. Una biblioteca de plantillas de estructuras de datos (tipos abstractos de datos) puede reducir el esfuerzo del diseño y de la especificación de datos.
Principios 7. Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos. La implementación de una estructura de datos sofisticada puede hacerse excesivamente difícil si no existen los medios de especificación directa de la estructura en el lenguaje de programación escogido para dicha implementación.
Principios Los principios descritos anteriormente forman una base para un enfoque de diseño de datos a nivel de componentes que puede integrarse en las fases de análisis y diseño.
Estilos arquitectónicos
El software construido para sistemas basados en computadoras también cuenta con diversos estilos arquitectónicos:
Estilos arquitectónicos o patrones Cada estilo describe una categoría del sistema que contiene: (1) un conjunto de componentes (por ejemplo, una base de datos, módulos computacionales) que realizan una función requerida por el sistema; (2) un conjunto de conectores que posibilitan la «comunicación, la coordinación y la cooperación» entre los componentes; (3) restricciones que definen cómo se pueden integrar los componentes que forman el sistema; y (4) Modelos semánticos que permiten al diseñador entender las propiedades globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes.
Una breve taxonomía de estilos y patrones
Cientos de miles de sistemas basados en computadora, la gran mayoría pueden ser clasificados dentro de uno de los estilos arquitectónicos siguientes:
Estilos Arquitectónicos:
Arquitecturas centradas de datos.
Arquitecturas de flujo de datos.
Arquitecturas de llamada y retorno.
Arquitecturas orientadas a objetos.
Arquitecturas estratificadas.
Arquitecturas centradas de datos
En el centro de esta arquitectura se encuentra un almacén de datos (por ejemplo, un documento o una base de datos) al que otros componentes componentes acceden con frecuencia para actualizar, añadir, borrar o bien modificar los datos del almacén.
Arquitecturas de flujo de datos.
Esta arquitectura se aplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales computacionales o manipulativos manipulativos en los datos de salida.
Arquitecturas de llamada y retorno.
Este estilo arquitectónico permite al diseñador del software (arquitecto del sistema) construir una estructura de programa relativamente relativamente fácil de modificar y ajustar a escala.
Existen dos subestilos dentro de esta categoría:
Arquitecturas de llamadas de retorno:
arquitecturas de programa principal.
arquitecturas de llamada de procedimiento remoto.
Arquitecturas orientadas a objetos.
Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos.
La comunicación y la coordinación entre componentes componentes se consigue a través del paso de mensajes.
Arquitecturas estratificadas.
La estructura básica de una arquitectura estratificada se representa en la Figura14.3. Se crean diferentes capas y cada una realiza operaciones que progresivamente se aproximan más al cuadro de instrucciones de la máquina. En la capa externa, los componentes sirven a las operaciones de interfaz de usuario. En la capa interna, los componentes realizan operaciones de interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y funciones del software de aplicaciones.
Estilos Arquitectónicos
Los estilos arquitectónicos citados anteriormente son sólo una pequeña parte de los que dispone el diseñador de software . Una vez que la ingeniería de requisitos r equisitos define las características y las restricciones del sistema que ha de ser construido, se escoge el patrón arquitectónico (estilo) o la combinación de patrones (estilos) que mejor encajan con las características y restricciones. En muchos casos, puede ser apropiado más de un patrón y se podrían diseñar y evaluar estilos arquitectónicos alternativos.
El Instituto de Ingeniería de Software (SEI) ha desarrollado un Método de análisis de compromiso para la arquitectura (MACA) que establece un proceso de evaluación iterativo para las arquitecturas de software. Las actividades de análisis de diseño mencionadas abajo se realizan iterativamente:
MACA 1. Recopilación de escenarios. 2. Elicitación de requisitos. 3. Describir los patroneslestilos patroneslestilos arquitectónicos escogidos para derivar los escenarios y requisitos. 4. Evaluar los atributos de calidad c alidad considerando considerando cada atributo de forma aislada. 5.Identificar la sensibilidad de los atributos de calidad con los diferentes atributos arquitectónicos en un estilo arquitectónico específico. 6. Análisis de las arquitecturas candidatas (desarrolladas en el paso 3) utilizando el análisis de sensibilidad del paso 5.
CONCLUSIONES
La arquitectura del software nos proporciona una visión global del sistema a construir.
CONCLUSIONES
Describe la estructura y la organización de los componentes del software, sus propiedades y las conexiones entre ellos.
Los componentes del software incluyen módulos de programas y varias representaciones representaciones de datos que son manipulados por el programa.
CONCLUSIONES Además, el diseño de datos es una parte integral para la derivación de la arquitectura del software. La arquitectura marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas.
CONCLUSIONES
El diseño de datos traduce los objetos de datos definidos en el modelo de análisis, en estructuras de datos que residen dentro del software. Los atributos que describe el objeto, las relaciones entre los objetos de datos y su uso dentro del programa influyen en la elección de la estructura de datos. A mayor nivel de abstracción, el diseño de datos conducirá a lo que se define como una arquitectura para una base de datos o un almacén de datos.
CONCLUSIONES
El ingeniero del software cuenta con diferentes estilos y patrones arquitectónicos. Cada estilo describe una categoría de sistema que abarca un conjunto de componentes que realizan una función requerida por el sistema, un conjunto de conectores que posibilitan la comunicación, la coordinación y cooperación entre los componentes, las restricciones que definen cómo se integran los componentes para conformar el sistema, y los modelos semánticos que facilitan al diseñador el entendimiento de todas las partes del sistema.
CONCLUSIONES
El diseño arquitectónico agrupa un grupo inicial de actividades de diseño que conducen a un modelo completo del diseño del software.
Gracias … ¿dudas?
