Gabriel J. Azócar
Sandy J. Mieres
Paulo F. Ramos
Fecha: 11/06/2019
Universidad Politecnica Territorial "Jose Antonio Anzoategui"
Trayecto: III Fase: I Sección: IF01
Fundamentos y Arquitectura de Diseño del Software
Introducción
El diseño de software es una actividad mediante la cual se logra conceptualizar el esquema general de un software el cual será realizado a futuro. Permite planear como se comportara un sistema además de permitir crear una estructura de calidad para que estos posean una mayor aceptación por los usuarios. Aunado a esto se encuentra la arquitectura de diseño, la cual consiste en originar una representación técnica del software que se va a desarrollar permitiendo delimitar los elementos más importantes.
Summary
Software design is an activity through which conceptualization of the general scheme of a software is achieved, which will be carried out in the future. It allows to plan how a system behaves, in addition to allowing to create a quality structure so that they have a greater acceptance by the users. Added to this is the design architecture, which is to originate a technical representation of the software that will be developed allowing delimiting the most important elements.
Diseño de software
Es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física.
A través de la historia de la ingeniería del software ha evolucionado un conjunto de conceptos fundamentales de diseño de software, aunque el grado de interés en cada concepto ha variado con los años, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados. Se refiere al proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir unos objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones. El diseño de software se puede referir a toda la actividad implicada en conceptualizar, enmarcar, implementar, poner en funcionamiento y, finalmente, modificar sistemas complejos, es decir, el diseño de software consiste en la la definición de la estructura o arquitectura general del un software.
El diseño es la primera fase del desarrollo de un sistema, en la cual, se aplica distintas técnicas y herramientas para describir, organizar y estructurar los componentes del software, o lo que quiere decir, la afirmación de requisitos del usuario y la realización de estos en forma de código ejecutable.
Importancia del diseño de software
En la actualidad, el software es un común denominador entre la gente, ya sea en un nivel educativo, profesional, laboral o personal. La informática se ha vuelto indispensable en el vivir diario de la gente, esta importancia ha hecho que sea todavía más importante el desarrollo de software, esto debido a que cada día la gente demanda más calidad en los servicios informáticos, de tal manera que siempre se necesita estar actualizado en el software, para esto es indispensable estar en un continuo desarrollo de todo tipo de software existente.
El diseño de software es una etapa fundamental y en muchas ocasiones la más importante en el desarrollo de Software. Es el momento en que los profesionales tienen que aportar sus conocimientos, experiencia y creatividad para llegar a una solución que cumpla con los requerimientos funcionales y no funcionales establecidos en la fase de la toma de requisitos.
El diseño del Software tiene un impacto directo sobre la capacidad del sistema para cumplir o no el total de requerimientos establecidos. Un error de diseño en esta fase puede acarrear problemas en todo el proyecto y provocar que este caiga en una espiral de continuos cambios y de rehacer constantemente el trabajo.
Si tuviéramos que resumir en una sola palabra la importancia del diseño del Software esta sería “Calidad”.
En resumen, sin la consideración del diseño, el sistema será construido de manera inestable, y al momento de ser sometidas a cambios mostrará cantidad de fallas, trayendo como consecuencia invertir mucho dinero y tiempo para la calidad del mismo.
Persistencia es el "arte" de almacenar y recuperar el estado de un objeto. No todo campo de un objeto requiere persistir, puede ser calculado, en tal caso a ese campo se le llama trasciente. Por ejemplo si tengo una clase que representa un triángulo rectángulo entonces el estado a almacenarse corresponderá a las dimensión de los lados, mientras que la hipotenusa es un campo trasciente ya que resulta de aplicar la eterna ecuación pitagórica.
Los almacenes de datos internos y externos dentro de un sistema proporcionan puntos limpios de separación entre subsistemas con interfaces bien definidas. En general, todo almacén de datos puede combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos de almacenamiento secundario. Los distintos tipos de almacenes de datos proporcionan diversas compensaciones entre costo, tiempo de acceso, capacidad y fiabilidad.
La mayor parte de las aplicaciones actuales requieren algún tipo de esquema de persistencia, es decir, algún medio a través del cual almacenar la información una vez finalizada su ejecución y recuperarla cuando sea preciso.
La elección de un mecanismo de persistencia adecuado a los propósitos del sistema que se pretende desarrollar supone la toma de un conjunto de decisiones:
- El tipo de sistema de base de datos a utilizar.
- La forma en que la aplicación se comunicará con el mismo.
- El grado de automatización para los accesos
- Los requerimientos de performance
- La distribución de la lógica; que parte resolverá la aplicación y que otra se delegará a mecanismos propios del sistema elegido
Notaciones en diseño de software
y documentación.
Existen numerosas notaciones para representar artefactos de diseño. Algunas se usan durante el diseño arquitectónico, otras durante el detallado y otras en ambas. Se han caracterizado las notaciones en términos de caja negra versos caja blanca:
- Notación caja negra: se preocupa con las propiedades externas de los elementos del modelo de diseño
- Notación caja blanca: se preocupa mayormente con describir algunos aspectos de la realización detalladas de un elemento de diseño Otra forma es diferenciarlas entre notaciones para describir propiedades estructurales (estáticas) y las que describen propiedades conductuales (dinámicas)
Algunas descripciones estructurales (vista
estática)
- Diagramas de clase y objeto: se usan para representar un conjunto de clase (y objetos) y sus relaciones. Una notación antigua relacionada son los diagramas entidad-relación usados para representar modelos conceptuales de datos almacenados en sistemas de información. UML tiene esta notación.
- Diagramas
de componentes: se usan para modelar la vista de implementación estáticas de un sistema, es
decir, cosas físicas (y sus relaciones) como
ejecutables, librerías, tablas, archivos y documentos. A pesar que si uso principal es durante la
construcción, estos diagramas pueden ser usados
durante diseño, por ejemplo, para documentar la estructura de un módulo. UML tiene esta notación.
- Diagramas de deployment: se usan para modelar la vista de deployment estático de un sistema, es decir, la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que viven en ellos. Típicamente estos diagramas pueden ser usados para representar aspectos de distribución, por ejemplo un modelo empotrado, cliente/servidor o sistemas distribuidos. UML tiene esta notación.
- Cartas
de estructuras o Diagrama de Estructura: se usan para
describir la estructura de llamado de un programa, es decir, cuál
módulo es invocado por otro módulo. Estos diagramas son inherentes de la
aproximación de diseño orientado a la función.
Algunas descripciones conductuales (vista dinámica)
- Diagramas
de actividad: se usan para mostrar el flujo de control
de actividad (ejecución continua no-atómica dentro de una máquina de
estado) a otra actividad. UML tiene esta notación.
- Diagramas
de interacción: se usan para mostrar las interacciones
entre un grupo de objetos. Estos diagramas vienen en dos tipos:
diagramas de secuencia ponen el énfasis en el ordenamiento temporal
de los mensajes, mientras que los diagramas de colaboración ponen
el énfasis en los objetos, sus enlaces y los mensajes que
intercambian en estos enlaces. UML tiene esta notación.
- Diagramas
de flujo de datos: se usan para mostrar el flujo
de datos entre un conjunto de procesos.
- Diagramas
de transición de estados y diagramas de statecharts (utilizados en UML):
se usan para mostrar el flujo de control de estado a estado en una
máquina de estados.
Pseudocódigo y lenguajes de diseño de
programas: son lenguajes estructurados
similares a programación que se usan para describir en la etapa de diseño
detallado la conducta de un procedimiento o método.
Documentación de diseño.
Dada la variedad de notaciones disponibles, se presenta la
dificultad de cómo combinarlas para confeccionar un documento de diseño
coherente. No hay respuesta definitoria. Depende de muchos aspectos: tipo de
software a desarrollar, las personas involucradas, etc. La selección de un
conjunto apropiado de vistas depende las personas involucradas: administradores
del proyecto, desarrolladores, testeadores e integradores, clientes, usuarios
finales, etc. Satisfacer las diferentes necesidades se puede describir en
términos de la importancia relativa de las varias visitas desde cada tipo de
visitas: módulos, componente, conector y asignación.
Principios del Diseño, Interacción entre diseño y requerimientos
Son las razones por las que el rango completo de elecciones abiertas a un diseñador seria restringidas. Estas pueden ser:
Contractuales: Cuando los componentes requieren que se sigan ciertos procedimientos o métodos a ser utilizados.
Técnicos: El hardware y software existente limitan la libertad del diseñador desde el principio.
Expectativas del cliente: La participación del cliente influye en la estrategia del diseño adoptada.
Tipo de sistema: El sistema que se desarrolla es el que permite la elección de los métodos de diseño y herramientas.
Tipo de aplicación: Las implicaciones de diseñar un sistema de garantía o seguridad crítica son diferentes del diseño de un prototipo.
Ambiente del proyecto: Esto está referido, al ambiente en el que trabajamos desde el punto de vista físico y en cuanto al ambiente del diseño en general; requisitos que ya tenemos planteados en el diseño.
Vista completa del ciclo de vida: Es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implementar un sistema de información.
Requerimientos no funcionales: Esto está referido a los materiales y equipos que no son función del sistema; pero que necesito para llevarlo a cabo.
Diseño de atributos de calidad (mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia...)
El diseño del software es un proceso iterativo mediante el
cual los requerimientos se traducen en un “plano” para construir el software.
Para lograr que un diseño sea presentable se deben seguir ciertas
pautas. Existen ciertos criterios que son los que evalúan el diseño del
software, estos criterios son:
- Un
diseño debe mostrar una organización jerárquica.
- En
diseño debe ser modular.
- Un
diseño debe contener representaciones distintas y separadas de los
datos y procedimientos.
- Debe
llevar a módulos.
- Debe
llevar interfaces que reduzcan la complejidad.
- Debe
obtenerse el diseño mediante un modulo reproducible.
Características para la evaluación
- Implementar
todos los requisitos explícitos contenido en el modelo de análisis y
ajustarse a todos lo requisitos del cliente
- Debe
ser una guía legible y comprensible para quienes generan códigos y quienes
realizan pruebas, es decir, dan soporte al software
- Debe
proporcionar una imagen completa del software desde una perspectiva de
implantación
¿Cómo alcanzar las metas del proceso?
Un diseño debe presentar una estructura arquitectónica que
se halla creado mediante patrones de diseño reconocibles, la integren
componentes que exhiban buenas características de diseño
y que pueda implementarse de manera evolutiva para que de estar forma
facilite la implementación y las pruebas.
- Un
diseño debe ser modular.
- Un
diseño debe contener distintas representaciones de los datos, la
arquitectura, las interfaces y los componentes.
- Un
diseño debe conducir a estructuras
de datos que sean apropiadas para las clases que habrán de implementarse y
que procedan de patrones de datos reconocibles.
- Un
diseño debe conducir a componentes que representan características
funcionales independientes.
- Un
diseño debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los componentes y el ambiente externo.
- Un
diseño debe obtenerse por medio de un método repetible que se base en la
información obtenida durante el análisis de requisitos del software.
- Un
diseño debe representarse por medio de una notación que comunique de
manera eficaz su significado
Características
- La
funcionalidad.
- La
facilidad.
- La
confiabilidad.
- El
desempeño.
- La
soportabilidad, la adaptabilidad y la servicialidad
Atributos de calidad
En la literatura que da una definición de calidad de
producto software en base a atributos es ISO 9126 (ISO/IEC, 2001). Dicha norma
establece que la medición de la calidad de un producto software debe hacerse en
base a sus atributos, siendo éstos internos, propiedades características de
cómo se estructura el software, o externos, cualidades observables aún sin
conocer cómo está construido. De hecho no se habla de calidad, en general,
sino de calidad interna y calidad externa, afirmándose que la calidad interna
de un producto software influye directamente en su calidad externa. De algún
modo se está diciendo que mejorando la calidad interna se mejora directamente
la calidad observada en atributos de uso del producto software. Tanto la
calidad interna como la externa se definen, en ISO 9126, como un conjunto de 6
características:
- Funcionalidad: La
capacidad del software de proveer las funciones que cumplen con las
necesidades implícitas y explícitas cuando el mismo es utilizado bajo
ciertas condiciones.
- Fiabilidad: La
capacidad del software de mantener un nivel específico de rendimiento bajo
determinadas condiciones de uso.
- Usabilidad: La
capacidad del producto software de ser entendido, aprendido, usado y
atractivo al usuario, cuando se usa bajo ciertas condiciones.
- Eficiencia: La
capacidad del software de ofrecer el rendimiento apropiado con
respecto a la cantidad de recursos utilizados, bajo condiciones
prefijadas.
- Mantenibilidad: La
capacidad del producto de ser modificado. Dichas modificaciones pueden
incluir correcciones, mejoras o adaptaciones a cambios en el entorno y en
los requisitos y especificaciones funcionales.
- Portabilidad: La
capacidad del software de ser trasladado de un entorno (informático) a
otro.
Estas características son generales para cualquier tipo de
programa informático o software independientemente.
Arquitecturas, patrones de diseño y reuso.
La arquitectura es el resultado de influencias técnicas, de
negocios y sociales. Tener una arquitectura real apoya el retorno de inversión
con respecto a calidad, calendario y costo
Arquitectura.
Influenciada por:
- Gente
con interés en el sistema
- Factores
técnicos y organizacionales
- Experiencia
A su vez, afecta:
- La
estructura de la organización que desarrolla
- Las
metas de la organización que desarrolla
- Los
requerimientos del cliente para el siguiente sistema
- La
experiencia del arquitecto
- La
cultura de ingeniería de software y el ambiente técnico en que se opera
Recomendaciones – Proceso
La arquitectura debe:
- Ser
producto de un arquitecto o de un grupo reducido.
- Basarse
en requerimientos técnicos y propiedades que el sistema debe
satisfacer.
- Estar
bien documentada en una notación común.
- Ser
analizada cuantitativamente y revisada para determinar sus propiedades
cualitativas.
- Guiar
el desarrollo basándose en el esqueleto.
- Resultar
en áreas de contención específicas
Recomendaciones de estructura
La arquitectura debe:
- Producir
módulos bien definidos cuya funcionalidad está desarrollada alrededor
de privacidad de información y separación.
- Producir
módulos que puedan ser desarrollados por diferentes equipos.
- Encapsular
la información de manera tal que prevenga los cambios
tecnológicos y de plataforma.
- Nunca
depender de una versión de un producto.
- Separar
módulos que produzcan datos de aquellos que consuman datos
- Incluir patrones de interacción
Estilo:
- Conjunto
de tipos de componentes.
- Mapa
(layout) topológico de los componentes indicando interrelaciones en
ejecución.
- Conjunto
de condiciones semánticas.
- Conjunto
de conectores que hacen la comunicación, coordinación o cooperación
entre componentes.
- Modelo
de referencia es una división de funcionalidad y su flujo de datos.
Arquitectura de referencia es el modelo de referencia
mapeado a componentes de software y el flujo de datos entre éstos.
Estilos (Patrones de Sistema)
Centradas en datos
- Objetivo:
integrabilidad de los datos.
- Ventaja:
clientes y datos independientes por tanto, fácilmente escalables.
De flujo de datos
- Objetivo:
reuso y modularidad (ve el sistema como una serie
de transformaciones en los datos).
- Ventaja:
simplicidad (no interacciones complejas).
- Desventaja:
no apta para aplicaciones interactivas, rendimiento pobre.
Maquinas virtuales
- Objetivo:
portabilidad (simulan funcionalidad no nativa)
- Ventaja:
flexibilidad para interrumpir y modificar en ejecución
- Desventaja:
rendimiento pobre
Call-and-return
- Objetivo:
modificabilidad y escalabilidad (estilo dominante los últimos 30 años)
Componentes independientes
- Por
eventos: control parte del sistema
- Procesos
comunicándose
¿Por Qué Reusar Software?
- Responder
a la demanda elevada
- Reducir
esfuerzos de mantenimiento
- Reducir
costos
- Mejorar
la práctica de software
- Incrementar
la productividad
- Mejorar
la calidad
La Clave: Productividad.
Cambios en la estrategia de producción
- Uso
de prototipos rápidos
- Uso
de desarrollo incremental
- Compra
de software hecho
Reuso ayuda en todos estos aspectos
Componentes Reusables
No sólo código. Incluye requerimientos,
diseño, métricas.
Diseñado para ser reutilizado
Descripción de especificación y adaptabilidad
Granularidad: tamaño del componente
- Probabilidad
de reuso inversamente proporcional
- Utilidad
de reuso directamente proporcional.
Se han propuesto variados principios generales y estrategias
para guiar y mejorar la calidad del software resultante. En contraste a las
estrategias, los métodos son más específicos, ya que sugieren un conjunto
particular de notaciones junto con una descripción de un proceso a ser seguido,
así como heurísticas para adaptar el proceso a un contexto particular.
Diseño orientado a la función (estructurado)
Es uno de los primeros paradigmas de diseño, que se centra en identificar las funciones principales de un sistema, y luego refinarlas en una manera top-down. El diseño estructurado se realiza después del análisis estructurado. Este análisis produce DFDs con descripciones de procesos y también se pueden usar diagramas E-R.
Se han propuesto dos estrategias para derivar una arquitectura de software a partir de un DFD:
- Análisis de transacción: una transacción se caracteriza por algún evento en el medio ambiente que genera un estímulo al sistema, quien a su vez gatilla alguna actividad que produce una respuesta teniendo un efecto hacia el medio ambiente. El análisis de transacciones consiste en identificar los tipos de transacciones claves de un sistema y usarlos como unidades de diseño, esto es, diseñándose paradamente el procesamiento de cada tipo de transacción.
- Análisis de transformación: el paso clave para derivar un diagrama de estructura de un DFD (para una transacción dada) es identificar la transacción central, esto es, la porción de un DFD que contiene las funciones esenciales del sistema y es independiente de la implementación de la entrada y salida. Una carta de estructura borrador se puede obtener “elevando” las burbujas asociadas a la transformación central.
Los conceptos claves del diseño estructurado son acoplamiento y cohesión. Un buen diseño debe restringir el acoplamiento a tipos normales de acoplamiento (datos, estampado, y control) siendo el de datos el preferido, donde la comunicación entre módulos es a través de parámetros, donde cada parámetro es un pedazo de datos elemental, evitando así las formas patológicas de acoplamientos, como la común y de contenido.
Un buen diseño debe dar preferencia a módulos de alta cohesión, es decir, módulos que exhiban cohesión funcional, que es cuando el módulo contiene todos los elementos que contribuyen a la ejecución de una y sólo una tarea relacionada al problema.
Existen otras formas de cohesión más débiles se han identificado: secuencial, comunicacional, procedural, temporal, lógica y coincidental.
Otras heurísticas se han sugerido para ayudar a mejor calidad del diseño resultante:
Fan-in/ Fan-out: un alto fan-in (número de módulo que llaman a u módulo M) es considerado bueno, ya que indica el reuso de M. por su parte un bajo o moderado (número de módulo que M invoca)
Particionamiento de decisiones: se debe evitar la división de decisiones, que ocurren cuando el reconocimiento de una condición y la ejecución de la acción asociado se mantienen dentro del mismo módulo
Sistema balanceado: se prefiere un sistema balanceado, es decir, cuando los módulos de alto nivel tratan con lógica y datos abstractos.
Diseño orientado a objeto
La noción de objeto está íntimamente relacionada con las nociones de abstracción de datos, encapsulamiento y tipo abstracto de datos. A través de los años, se han propuesto numerosos métodos de diseño, UML no es un método de diseño, es sólo un conjunto de notaciones neutral con respecto a cualquier método de diseño específico.
También se conoce como programación estructurada de Jackson. El énfasis se basa en los datos que manipula el programa en vez de las funciones que realiza. El énfasis se basa en que los datos son más estables (menos sujetos a cambios) que las funciones que debe desarrollar.
El diseñador describe los datos de entrada y salida, usando los diagramas de estructura de Jackson, y desarrolla entonces la estructura de control del programa estableciendo una correspondencia apropiada entre los diagramas de estructura de entrada y salida.
Abstracción
Cuando se considera una solución modular para cualquier problema, pueden formularse muchos niveles de abstracción. En el nivel superior de abstracción, se establece una solución en términos amplios, usando el lenguaje del entorno del problema. En los niveles inferiores de abstracción se toma una orientación más procedimental. La terminología orientada al problema se acompaña con una terminología orientada a la implementación, en un esfuerzo para establecer una solución. Por último, en el nivel más bajo de abstracción, se establece la solución, de forma que pueda implementarse directamente.
Modularidad
Refinamiento
El refinamiento sucesivo es una primera
estrategia de diseño descendente propuesta por Niklaus Wirth. La
arquitectura de un programa se desarrolla en niveles sucesivos de refinamiento
de los detalles procedimentales. Se desarrolla una jerarquía descomponiendo una
declaración macroscópica de una función de una forma sucesiva, hasta que llega
a las sentencias del lenguaje de programación.
El refinamiento es realmente un proceso de elaboración.
Comenzamos una declaración de la función definida a un nivel superior de
abstracción. Es decir, la declaración describe la función o la información
conceptualmente, pero no proporciona información sobre el funcionamiento
interno de la función. El refinamiento hace que el diseñador amplíe la
declaración original, dando cada vez más detalles conforme se produzca los
sucesivos refinamientos.
El software se divide en componentes con nombres y ubicaciones determinados, que sedenominan módulos y que se integran para satisfacer los requisitos del problema. Se ha dicho que la “modularidad es el atributo individual del software que permite a un programa ser intelectualmente manejable”.
Arquitectura del software
Se refiere a dos características importantes del software: la estructura jerárquica de los componentes procedimentales y la estructura de datos. La arquitectura se obtiene mediante un proceso de partición, que relaciona los elementos de una solución de una solución de software con partes de un problema del mundo real definido implícitamente durante el análisis de los requisitos.
Se refiere a dos características importantes del software: la estructura jerárquica de los componentes procedimentales y la estructura de datos. La arquitectura se obtiene mediante un proceso de partición, que relaciona los elementos de una solución de una solución de software con partes de un problema del mundo real definido implícitamente durante el análisis de los requisitos.
Jerarquía de control
La jerarquía de control, también denominada estructura del programa, representa la organización (frecuentemente jerárquica) de los componentes del programa (módulos) e implica una jerarquía de control. No representa aspectos procedimentales del software, tales como la secuencia de procesos, la ocurrencia u orden de decisiones o la repetición de operaciones.
La jerarquía de control, también denominada estructura del programa, representa la organización (frecuentemente jerárquica) de los componentes del programa (módulos) e implica una jerarquía de control. No representa aspectos procedimentales del software, tales como la secuencia de procesos, la ocurrencia u orden de decisiones o la repetición de operaciones.
Para representar la jerarquía de control se utiliza un diagrama en forma de árbol. La profundidad, y la anchura son una indicación del número de niveles de control y de la amplitud global del control, respectivamente.El grado de salida es una medida del número de módulos que están directamente controlados por otros módulos.El grado de entrada indica cuántos módulos controlan directamente a un módulo dado.
La jerarquía de control también representa dos características, sutilmente diferentes, de la arquitectura del software: la visibilidad y la conectividad. La visibilidad indica el conjunto de componentes del programa que pueden ser invocados o utilizados sus datos por un componente dado, incluso cuando se haga indirectamente. La conectividad indica el conjunto de componentes a los que directamente se invoca o se utilizan sus datos en un determinado módulo.
Estructuras de datos
Es una representación de la
relación lógica existente entre los elementos individuales de datos. La
estructura de datos dicta la organización, los métodos de acceso, el grado de
asociatividad y las alternativas de procesamiento para la información.
La organización y la complejidad de una estructura de datos
tan sólo están limitadas por el ingenio del diseñador. Sin embargo, hay un
número reducido de estructuras de datos clásicas, que constituyen los bloques
con los que se construyen estructuras de datos más sofisticadas.
Procedimientos del software
Se centra en los
detalles de procesamiento de cada módulo individual.
Proporciona una especificación precisa del procesamiento, incluyendo la
secuencia de sucesos, los puntos concretos de decisiones, la repetición de
operaciones e incluso la organización y estructura de los datos.
Cohesión y acoplamiento
Como regla general, acoplamiento ente componentes debe ser débil, mientras que la cohesión (interna) de un componente debe ser alta.
Como regla general, acoplamiento ente componentes debe ser débil, mientras que la cohesión (interna) de un componente debe ser alta.
La información oculta se define donde cada módulo se caracteriza por el conocimiento de la decisión de diseño que la oculta de los otros. Un principio clave es la separación de la interfaz y la implementación donde se especifica una interfaz pública conocida por los clientes, que separa los detalles de cómo lo realiza el componente.
Encapsulamiento es el agrupamiento de las ideas en una unidad las que pueden ser referencia después por un solo nombre. Encapsulamiento combina elementos para crear una nueva unidad, cuyos detalles internos son ocultados. Suficiencia, completitud y premitividad: estas nociones indican que un componente debe capturar todas las características importantes de una abstracción para interactuar con ellas y ninguna más.
Suficiencia, completitud y primitividad
Estas nociones
indican que un componente debe capturar todas lascaracterísticas importantes de
una abstracción para interactuar con ella y ninguna más.
Arquitectura de diseño
La arquitectura de diseño es un proceso de ingeniería del software, que consiste en originar una representación técnica del software que se va a desarrollar, nos permite delimitar los elementos más importantes así como sus relaciones.
El diseño arquitectónico inicia con el diseño de datos, que son los componentes de datos del sistema y posteriormente se procede a la bifurcación de una o más representaciones de la estructura arquitectónica del sistema, que son la representación de la estructura de los componentes del software, sus propiedades e interacciones.
Es importante la arquitectura de diseño ya que proporcionan la comunicación entre todas las partes interesadas en el desarrollo de un sistema y permite representar un modelo pequeño y comprensible de cómo está estructurado el sistema y de cómo trabajan sus componentes.
Sistemas de Flujos de Datos (tuberías y filtros), Sistemas basados en Llamado y Retorno (capas), Sistemas de Componentes Independientes, Sistemas Basados en transacciones, basados en eventos, P2P, cliente servidor.
Se basa en un patrón tuberías y filtros. este consta de un conjunto de componentes denominados “filtros” conectados entre si por “tuberías” que transmiten los datos desde un componente al siguiente. cada filtro trabaja de manera independiente de los componentes que se encuentren situados antes o después de ella. se diseñan de tal modo que esperan que un conjunto de datos en un determinado formato. y obtiene como resultado datos de salida en un formato especifico.
Sistemas basados en llamado y retorno (capas)
Este estilo arquitectónico permite al diseñador del software (arquitecto del sistema) construir una estructura de programa relativamente fácil de modificar y ajustar a escala.
Existen dos subestilos dentro de esta categoría:
- Arquitecturas de programa principal.
- Arquitecturas de llamada de procedimiento remoto.
Sistemas de componentes independientes
Es un estilo de diseño para aplicaciones compuestas de componentes individuales. pone énfasis en la descomposición del sistema en componentes lógicos o funcionales que tienen interfaces bien definidas. define una aproximación de diseño que usa componentes discretos, los que se comunican a través de interfaces que contienen métodos, eventos y propiedades.
Sistemas basados en transacciones
Este estilo permite compartir los detalles entre cliente servidor, este estilo se prefiere cuando se conoce de antemano la transacción y no cambian con frecuencia
Sistemas basados en eventos
La arquitectura dirigida por eventos, event-driven architecture o eda, es un patrón de arquitectura software que promueve la producción, detección, consumo de, y reacción a eventos. cada subsistema puede responder a eventos generados externamente por los otros subsistemas o el entorno del sistema.
difusión (broadcast): cuando ocurre un evento el control se transfiere al subsistema que puede tratarlo. cada subsistema decide sobre los eventos que le interesan.
guiado por interrupciones cada interrupción tiene un manejador.
Sistemas peer-to-peer (p2p)
Sistemas cliente servidor
La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.
Aspectos de Hardware en arquitectura del software.
Toda arquitectura de software debe describir diversos aspectos del Hardware. Generalmente, cada uno de estos aspectos se describe de una manera más comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripción parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es así porque todas las vistas deben ser coherentes entre sí, evidente dado que describen la misma cosa.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:
- La visión estática: describe qué componentes tiene la arquitectura.
- La visión funcional: describe qué hace cada componente.
- La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí.
Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El más obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados únicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje único para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de información (o expresarlas de manera incomprensible).
Trazabilidad de los requerimientos en el diseño
Una especificación de un requerimiento de software es trazable si el origen de cada requerimiento está claro y si se facilita la referencia de cada requerimiento en el desarrollo futuro o en la documentación. La trazabilidad es la capacidad de describir y de seguir la vida de un requisito, tanto en dirección hacia adelante y hacia atrás, es decir, desde sus orígenes, a través de su desarrollo y especificación, a su despliegue y uso subsecuentes, y a través de períodos de refinamiento y de la iteración en curso en cualquiera de estas fases.
Esto implica que un requerimiento debe de ser rastreable desde que se define y durante todo el desarrollo del software, lo cual garantiza una adecuada administración del cambio con el fin de evaluar el impacto en el resto del sistema. En el caso que se esté en la etapa de desarrollo de los requerimientos, se podrá evaluar como afectaría un cambio de un requisito en otro. Por otro lado, estando en etapa de implementación y en caso de que haya un cambio en los requerimientos, la trazabilidad permitirá hacer una evaluación en el diseño y en la implementación. Si el cambio se da cuando el sistema está implementado, la trazabilidad permitirá hacer una evaluación de cómo serán afectados los involucrados. Las razones de porqué utilizar trazabilidad es porque se dispone de información en la evaluación de los cambios de requerimientos y son la base para el control de costos y calidad
Existen muchas notaciones y lenguajes para representar los artefactos del diseño software. Unas son para representar la estructura y otras el comportamiento, unas sirven principalmente durante el diseño arquitectural, otras durante el diseño detallado, y algunas durante ambos, algunas se emplean principalmente en el contexto de métodos específicos.
- Lenguajes de Descripción de Arquitecturas (ADLs): Lenguajes textuales formales ideados para describir una arquitectura software en términos de componentes y conectores.
- Diagramas de Clases y Objetos: Para representar un conjunto de clases (y objetos) y sus interrelaciones.
- Diagramas de Componentes: Para representar un conjunto de componentes (partes físicas y reemplazables de un sistema que son conformes a y proveen un conjunto de interfaces) y sus interrelaciones.
- Tarjetas CRC (Clase Responsabilidad Colaborador):Para denotar los nombres de los componentes (clases), sus responsabilidades, y los nombres de los componentes con los que colaboran.
- Diagramas de Despliegue: Para representar un conjunto de nodos físicos y sus interrelaciones, modelando los aspectos físicos de un sistema.
- Diagramas Entidad-Interrelación: Para representar modelos conceptuales de los datos almacenados en sistemas de información.
- Lenguajes de Descripción de Interfaces (IDLs): Similares a los lenguajes de programación normales, sirven para definir las interfaces (nombres y tipos de las operaciones exportadas) de los componentes software.
- Diagramas de Estructura de Jackson: Para describir las estructuras de datos en términos de secuencia, selección e iteración.
- Grafo de Estructura: Para describir la estructura de llamadas de los programas (qué módulos llaman y son llamados por qué módulos).
- Diagramas de Actividad: Para mostrar el flujo de control entre actividades (ejecuciones no atómicas dentro de una máquina de estados).
- Diagramas de Colaboración : Para mostrar las interacciones entre un grupo de objetos, haciendo énfasis en los objetos, sus conexiones y los mensajes que intercambian en dichas conexiones.
- Diagramas de Flujo de Datos (DFDs): Para representar el flujo de datos entre un conjunto de procesos.
- Tablas y Diagramas de Decisión: Para representar combinaciones complejas de condiciones y acciones.
- Diagramas de Flujo [Estructurados]: Para representar el flujo de control y las acciones asociadas que deben ser realizadas.
- Diagramas de Secuencia: Para mostrar las interacciones entre un grupo de objetos, con énfasis en la ordenación temporal de los mensajes.
- Diagramas de Transición de Estados y Grafos de Máquinas de Estados: Para mostrar el flujo de control entre estados de una máquina de estados.
- Lenguajes de Especificación Formal: Lenguajes textuales que usan nociones básicas matemáticas (lógica, conjuntos, secuencia) para definir de forma rigurosa y abstracta las interfaces y el comportamiento de los componentes (habitualmente en términos de pre y post-condiciones).
- Pseudocódigo y Lenguajes de Diseño de Programas Lenguajes, al estilo de los tradicionales de programación estructurada, usados para describir, normalmente en la etapa de diseño detallado.
Evaluación del diseño
El primer paso para la evaluación de una arquitectura es conocer qué es lo que se quiere evaluar. De esta forma, es posible establecer la base para la evaluación, puesto que la intención es saber qué se puede evaluar y qué no. Resulta interesante el estudio de la evaluación de una arquitectura: si las decisiones que se toman sobre la misma determinan los atributos de calidad del sistema, es entonces posible evaluar las decisiones de tipo arquitectónico con respecto al impacto sobre estos atributos.
La arquitectura de software posee un gran impacto sobre la calidad de un sistema, por lo que es muy importante estar en capacidad de tomar decisiones acertadas sobre ella, en diversos tipos de situaciones, entre las cuales destacan:
- Comparación de alternativas similares.
- Comparación de la arquitectura original y la modificada.
- Comparación de la arquitectura de software con respecto a los requerimientos del sistema.
- Comparación de una arquitectura de software con una propuesta teórica.
- Valoración de una arquitectura en base a escalas específicas.
Conclusión
Es claro que el diseño así como la arquitectura de software son elementos de la ingeniería del software que pueden ser altamente resaltados ya que gracias a estas se pueden establecer estándares de calidad bastante elevados que permitirán la satisfacción de los clientes finales.
Esta investigación deja por sentado la importancia que tienen el diseño de software ademas de manifestar diversas estrategias de diseño que se han creado con el paso del tiempo como lo son la orientada a funciones, o estructurada, orientada a objetos y orientado a estructuras de datos. También se expusieron métodos para la actividad de diseño.
Aunado a los conceptos ya expuestos se hablo también sobre la arquitectura de diseño, es decir modelar todo el funcionamiento de un sistema permitiendo mostrar cada uno de los items de mayor relevancia para el sistema y esquematizando la manera en que este actuara y se comportara.
Rafael Gómez Blanes(2017). El Libro negro del Programador. 2da Edición
[Documento en Línea]. Disponible en:
https://www.amazon.com/Libro-Negro-del-Programador-desarrollando-ebook/dp/B00J5RHHNW
[Consulta 2019; Junio 11]
Kendall y Kendall. (2009). Análisis y Diseño de Sistemas. 8va Edición
[Documento en Línea]. Disponible en: https://www.academia.edu/7102592/Analisis_y.Diseno_de_Sistemas_8ed_Kendall_PDF
[Consulta 2019; Junio 11]
Roger S. Pressman. (2010). Ingeniera del Software. Un enfoque Práctico. 7ma Edición
[Documento en Línea]. Disponible en: https://tesuva.edu.co/.../Ingenieria_del_Software._Un_Enfoque_Practico.pdf
[Consulta 2019; Junio 11]
George Scott. (1992). Principios de Sistemas de Información. 1era Edición
[Documento en Línea]. Disponible en:
www.aliat.org.mx/.../sistemas/Analisis_de_sistemas_de_informacion.pdf
[Consulta 2019; Junio 11]
Autores:
Gabriel J. Azócar. Correo: Gaboazocar13@gmail.com
Sandy J. Mieres. Correo: Smmieresj@gmail.com
Paulo F. Ramos.
[Documento en Línea]. Disponible en: https://tesuva.edu.co/.../Ingenieria_del_Software._Un_Enfoque_Practico.pdf
[Consulta 2019; Junio 11]
George Scott. (1992). Principios de Sistemas de Información. 1era Edición
[Documento en Línea]. Disponible en:
www.aliat.org.mx/.../sistemas/Analisis_de_sistemas_de_informacion.pdf
[Consulta 2019; Junio 11]
Autores:
Gabriel J. Azócar. Correo: Gaboazocar13@gmail.com
Sandy J. Mieres. Correo: Smmieresj@gmail.com
Paulo F. Ramos.
Carrera: Informática. Trayecto: 03. Fase: 01 Sección: IF01
Docente: Ing. Marilen Campos
Docente: Ing. Marilen Campos
Universidad: Universidad Politecnica Territorial "Jose Antonio Anzoategui"
