DISEÑO DEL SOFTWARE.

Autores:

Gregorio A. Rojas

Jesús A. BRITO

Daymar T. Bolívar
Carlos D. Franceschi

Correo: jesusbrito751@gmail.com

Fecha: 17/06/2019

Universidad Politécnica Territorial "José Antonio Anzoátegui"

Trayecto: III Fase: I Sección: IF01

Fundamentos y Arquitectura de Diseño del Software

Resumen.

  El diseño de software es el proceso de diseño para la planificación de una solución de software, es decir, es una actividad mediante la cual se logra conceptualizar el esquema general de un software el cual será realizado a futuro. Además, una arquitectura de software, también denominada arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan un marco definido y claro para interactuar con el código fuente del software.

Overview.

  Software design is the design process for the planning of a software solution, that is, it is an activity through which it is possible to conceptualize the general scheme of a software which will be carried out in the future. In addition, a software architecture, also called logical architecture, consists of a set of coherent patterns and abstractions that provide a defined and clear framework for interacting with the source code of the software.

Diseño de software.

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" o "la actividad que sigue a la especificación de requisitos y precede a la programación, como en un proceso de ingeniería de software estilizado.

La importancia Diseño del Software.

Se trata de 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.

Persistencia del software.

Un programa software se ejecutará varias veces. Cada vez que se ponga en ejecución, se hará después de que el programa se lance a través de un comando. Dicho programa en ejecución finalizará al recibir una señal, porque llega al final de su código (quizás existe incluso una opción de finalizar que el propio usuario tiene disponible en el menú) o porque se ha realizado una llamada a una función que termina el programa.

Almacenamiento de software.

Es una arquitectura de almacenamiento que separa el software de almacenamiento de su hardware. A diferencia del almacenamiento conectado a la red (NAS) tradicional o de los sistemas de red de área de almacenamiento (SAN).

Excepciones de software.

Es una técnica de programación que permite al programador controlar los errores ocasionados durante la ejecución de un programa informático. Cuando ocurre cierto tipo de error, el sistema reacciona ejecutando un fragmento de código que resuelve la situación, por ejemplo retornando un mensaje de error o devolviendo un valor por defecto.

Métodos para la actividad de diseño.

Es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad. Para metodología de desarrollo de software consiste en:

Una filosofía de desarrollo de programas de computación con el enfoque del proceso de desarrollo de software

Herramientas, modelos y métodos para asistir al proceso de desarrollo de software.

Principios del diseño de software.

Estos principios nos proporcionan unas bases para la construcción de aplicaciones mucho más sólidas y robustas. Permiten que los cambios y la evolución del software tenga un mínimo impacto en el código ya desarrollado tratando de evitar que lo que funciona deje de funcionar y por ello que el coste del mantenimiento sea mucho menor.

Interacción entre diseño de software.

Está definido como la práctica de diseñar productos digitales interactivos, entornos, sistemas, y servicios. Mientras el lado digital de esta declaración es cierto, diseño de Interacción es también válido cuándo se ha creado un espacio físico (no-digital) como productos, cubriendo la ideología de cómo un usuario puede interactuar con él. Temas comunes que diseño de interacción es más a menudo asociado con incluir diseño, interacción de ordenador humano, y desarrollo de software.

Requerimientos  del software.

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.  Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo).

Atributo de la calidad del software.

En el desarrollo de sistemas interactivos este factor no pasa desapercibido hasta el punto que actualmente la usabilidad es considerada como un atributo de calidad en el desarrollo del software que es recogido en diversas clasificaciones de atributos de calidad. La percepción cada vez mayor de la importancia de la usabilidad se afirma que éste es uno de los atributos de calidad que se consideran más críticos en el proceso de desarrollo de software. Y dadas las ventajas que puede proporcionar debería ocupar un lugar relevante como factor de calidad estratégico.

Mantenibilidad del software.

Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:

Modularidad: Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás.

Reusabilidad.: Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos.

Analizabilidad: Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar.

Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño.

Capacidad para ser probado: Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios.

Funcionamiento.

Que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware. La interacción entre el software y el hardware hace operativo un ordenador (u otro dispositivo), es decir, el Software envía instrucciones que el Hardware ejecuta, haciendo posible su funcionamiento.

Usabilidad  del software.

Esto se mide a través del estudio de la relación que se produce entre las herramientas (entendidas en un Sitio Web el conjunto integrado por el sistema de navegación, las funcionalidades y los contenidos ofrecidos) y quienes las utilizan, para determinar la eficiencia en el uso de los diferentes elementos ofrecidos en las pantallas y la efectividad en el cumplimiento de las tareas que se pueden llevar a cabo a través de ellas.

Seguridad del software.

El software de seguridad está diseñado para proteger los ordenadores de los programas maliciosos, como virus y malware. Es importante contar con un software de seguridad instalado en su equipo para protegerlo. Dicho esto, cuando no está configurado correctamente, el software de seguridad puede causar problemas de interacción con sus juegos WildTangent.

Tolerancia  del software.

es la propiedad que le permite a un sistema seguir funcionando correctamente en caso de fallo de uno o varios de sus componentes. Si disminuye su calidad de funcionamiento, la disminución es proporcional a la gravedad de la avería, en comparación con un sistema diseñado ingenuamente de forma que hasta un pequeño fallo puede causar el colapso total del sistema. Tolerancia a fallos es particularmente buscado en sistemas de alta disponibilidad.

Arquitectura de software:

se consideraba un arte y se desarrollaba como tal debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado arquitectura de software, porque, a semejanza de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los algoritmos y estructuras de datos de la computación; el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema.

Patrones de diseño software.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Reuso de software.

 reuso en software nos ayuda a mejorar la producción y calidad del software al “no reiventar la rueda.

Estrategias de diseño de software.

El Diseño estructurado es la conceptualización de un problema en varios elementos organizados de solución. Está básicamente centrado en el diseño de soluciones. El beneficio del diseño estructurado es que da un mejor entendimiento sobre cómo se resuelve el problema. El diseño estructurado también simplifica el proceso al diseñador, por tanto este último puede concentrarse en el problema de forma más acurada.

El Diseño estructurado se basa en 'dividir y conquistar', estrategia donde el problema se rompe en otros pequeños problemas y cada uno es tratado por separado para finalmente resolver la totalidad del problema.

Diseño orientado a la función.

En Diseño orientado a la función, el sistema es comprimido en varios pequeños sub sistemas concidos como funciones. Estas funciones son capaces de llevar a cabo tareas significativas en el sistema. El sistema es considerado como la vista superior de todas las funciones.

Diseño orientado al objeto.

El diseño orientado al objeto funciona alrededor de entidades y sus características en vez de involucrando funciones en el sistema de software. Esta estrategia de diseño se centra en entidades y sus características. Todo el concepto de solución de software se centra en las entidades implicadas.

Proceso de diseño.

El proceso de diseño de Software se puede definir en una serie de pasos bien definidos. Aunque cambie según el tipo de aproximación (orientado a la función o al objeto), Debe seguir los siguientes pasos:

Una solución de diseño se crea partiendo de un requisito o un sistema usado con anterioridad y/o el diagrama de secuenia de un sistema.

Los objetos se identifian y agrupan en clases según su similaridad con las características del atributo.

La jerarquía de clase y su relación entre ellos está definida.

El borrador de la aplicación está definido.

Arquitectura flujo de datos(filtros y tuberías).

 Se basa en un patrón tuberías y filtros. Este consta de un conjunto de componentes denominados filtros, conectados entre sí 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 el.

 Cada paso del proceso se encapsula en un filtro.  Los datos se pasan a través de tubos entre filtros adyacentes.  Los filtros se pueden usar en varios sistemas.

Tuberia.

Una tubería, es una arquitectura que conecta componentes (filtros), a través de los conectores y las comunicaciones se ejecutan como un flujo

Filtros.

 Los filtros, no necesariamente realizan únicamente tareas de filtrado, sino que ejecutan formas variables de transformación

Sistemas basados en Llamado y Retorno (Capas).

Están organizados jerárquicamente; cada capa le presta servicios a la capa superior y es cliente de la capa inferior. El sistema se constituye de un programa principal que tiene el control del sistema y varios subprogramas que se comunican con éste mediante el uso de llamadas

La programación por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos.

Sistemas de Componentes Independientes.

Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos).

Todos los procesos del sistema son colocados en componentes separados de tal manera que todos los datos y funciones dentro de cada componente están semánticamente relacionados. Debido a este principio, con frecuencia se dice que los componentes son modulares y cohesivos.

Con respecto a la coordinación a lo largo del sistema, los componentes se comunican uno con el otro por medio de interfaces. Cuando un componente ofrece servicios al resto del sistema, éste adopta una interface proporcionada que especifica los servicios que otros componentes pueden utilizar, y cómo pueden hacerlo. Esta interface puede ser vista como una firma del componente – el cliente no necesita saber sobre los funcionamientos internos del componente (su implementación) para hacer uso de ella. Este principio resulta en componentes referidos como encapsulados.

Sin embargo, cuando un componente necesita usar otro componente para poder funcionar, adopta una interface usada que especifica los servicios que necesita. En las ilustraciones de UML en este artículo, las interfaces usadas son representadas por un símbolo de zócalo abierto unido al borde externo del componente.

Permite la reutilización de software como proceso de crear sistemas de software a partir de software existente, en lugar de desarrollarlo desde el comienzo.

Sistemas Basados en transacciones.

Un sistema de procesamiento de transacciones es un tipo de sistema de información que recolecta, almacena, modifica y recupera toda la información generada por las transacciones producidas en una organización. Una transacción es un evento que genera o modifica los datos que se encuentran eventualmente almacenados en un sistema de información.

Desde un punto de vista técnico, un TPS monitoriza los programas transaccionales (un tipo especial de programas). La base de un programa transaccional está en que gestiona los datos de forma que estos deben ser siempre consistentes (por ejemplo, si se realiza un pago con una tarjeta electrónica, la cantidad de dinero de la cuenta sobre la que realiza el cargo debe disminuir en la misma cantidad que la cuenta que recibe el pago, de no ser así, ninguna de las dos cuentas se modificará), si durante el transcurso de una transacción ocurriese algún error, el TPS debe poder deshacer las operaciones realizadas hasta ese instante.

Sistemas Basados en eventos.

Una arquitectura basada en eventos responde a las acciones o acontecimientos generados por un directorio y sus usuarios. Los eventos del directorio conectado actúan como un disparador para iniciar la replicación o sincronización de los datos de ese directorio. El cambio del repositorio genera un evento resultante, y dicho evento acciona los cambios en los demás directorios conectados. Como consecuencia de los eventos y de los cambios correspondientes, se sincronizan los datos de identidad de todos los directorios conectados

Por ejemplo, cuando un consumidor compra un coche, el estado del coche pasa de “se vende” a “vendido”. La arquitectura del sistema del vendedor de coches debe tratar este cambio de estado como un evento, cuyo suceso puede ser conocido en otras aplicaciones en la arquitectura. Desde una perspectiva formal, lo que es producido, publicado, propagado, detectado o consumido es un mensaje (típicamente asíncrono) llamado notificación del evento, y no el evento en sí mismo, el cuál es el cambio de estado que disparó la emisión del evento. Los eventos no viajan, solamente ocurren. Por otro lado, el término evento es frecuentemente usado para denotar el mensaje de notificación en sí mismo, lo cual puede llevar a algún tipo de confusión.

PEER TO PEER O P2P.

Los programas P2P, son programas que convierten a los usuarios de una red en nodos, que automáticamente vuelven a los ordenadores en clientes y servidores a la vez, lo que permite realizar transferencias de archivos de manera rápida y sencilla entre usuarios de una misma red

El estilo arquitectónico Peer to Peer o P2P, son algunos de los programas más utilizados por los usuarios de todo el mundo para compartir archivos a través de Internet. En la actualidad, existe una gran cantidad de programas de este tipo que son utilizados para mantener una enorme base de datos de programas y archivos, que pueden ser intercambiados por miembros de una misma red, siendo muy utilizados para la descarga de archivos.

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, quien 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.

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.

NOTACIÓN PARA REPRESENTAR LAS ARQUITECTURAS DEL SOFTWARE.

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.

1. Notaciones de aspectos estructurales (estática), es decir, los componentes y sus interconexiones.

• 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).

2.    Las siguientes notaciones y lenguajes sirvan para describir el comportamiento (dinámica) de un  software y sus componentes.

• 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.

Referencias.

Ingeneria del software (2019). Documento en línea. Disponible en

http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/fuentes_k_jf/capitulo2.pdf

[consulta 2019; junio 17]

Diseño de la arquitectura (2019). Documento en linea. Disponible en 

https://sg.com.mx/revista/29/diseno-la-arquitectura [consulta 2019; junio 17]

Ingeneria del software (2017). Documento en linea. Disponible en

https://pnfioem1.wordpress.com/category/unidad-iii/ [consulta 2019; junio 17]