Modelado de aplicaciones y patrones de diseño
El modelado de aplicaciones y patrones de diseño hace parte del desarrollo de aplicaciones y ejecutables desde su proceso de diseño.
facultad de informática · software
jue. 29 de jul. 2021
0

El desarrollo y diseño de software hace parte de una de las áreas informáticas más importantes en la actualidad. Este campo se dedica a la programación y estructura funcional de datos en diversos ámbitos. Por ello se hace necesario que exista una buena parte de profesionales dedicados a este campo, de manera tal que los mismos desempeñen una óptima labor. El modelado de aplicaciones y patrones de diseño brinda parámetros a estos profesionales, sobre como usar estas herramientas.

Modelo avanzado de requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad, que ofrecerá desde la perspectiva del usuario. Este modelo puede trabajar como un contrato entre el desarrollador y el cliente, o usuario del sistema, por lo que deberá proyectar lo que el cliente desea, según la percepción del desarrollador. Por ello, es esencial que los clientes lo comprendan.

El modelo de requisitos es el primero en desarrollarse, y es la base para formar todos los demás modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias a este nivel que posteriormente. El propósito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones.

Los demás modelos, análisis, diseño, implementación y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aquí, desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así resolver ambigüedades e inconsistencias.

También debe separar los requisitos verdaderos de las decisiones relacionadas con el diseño e implementación. Se deben indicar cuáles aspectos son obligatorios y cuáles opcionales para evitar que se limite la flexibilidad de la implementación. Durante el diseño, se debe extender el modelo de requisitos con las especificaciones de rendimiento y los protocolos de interacción para los sistemas externos, al igual que las provisiones sobre modularidad y futuras extensiones. Incluso, en ciertas ocasiones, se pueden incluir aspectos de diseño, como el uso de lenguajes de programación particulares.

Modelado de requisitos

En la Metodología Objetiva (Jacobson et al. 1992), el modelo de requisitos consta de tres modelos principales que se representan visualmente mediante un diagrama tridimensional. Los tres ejes del modelado de requisitos son:

  • El modelo de comportamiento, basado directamente en el modelo de caso de uso, especifica la funcionalidad que proporciona el sistema desde la perspectiva del usuario. Este modelo utiliza dos conceptos clave: actores para representar los diferentes roles que los usuarios pueden jugar con el sistema y casos de uso para representar lo que los actores pueden hacer con respecto al sistema.
  • El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el usuario, especifica cómo se verán visualmente las interfaces gráficas y qué funcionalidad ofrecerá cada una de ellas.
  • El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema. Este modelo conceptualiza el sistema en términos de objetos que representan las entidades básicas de la aplicación. Si bien muchos métodos le permiten especificar la funcionalidad completa del sistema utilizando el modelo de dominio del problema, incluidas las operaciones formales en objetos que se ajustan a un modelo de requisitos sin casos de uso, el modelo de dominio del problema será mucho más útil como soporte para el modelo de casos de uso en lugar de como una entidad completamente independiente.

Es importante destacar que esta separación en tres ejes independientes del modelo es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

Modelado estático avanzado

Este modela conceptos del dominio de la aplicación, sus propiedades internas y sus relaciones y se denomina estático porque no modela el comportamiento del sistema dependiente del tiempo.

  • Componentes principales
    • Clases: describen conceptos del dominio de la aplicación o de la solución.
    • Relaciones
    • Asociación
    • Generalización
    • Dependencia: realización y uso

Diagramas de clases

Las características de las clases individuales, así como las relaciones de dependencia y generalización se definen en el diagrama de clases. Aquí, se ampliará el conocimiento del diseño orientado a objetos, se definirán clases y se implementarán las relaciones de herencia y agregación que ya son típicas. Este diagrama permite visualizar las relaciones entre las clases en las que está involucrado el sistema.

Estos pueden ser asociativos, heredables, utilizables y de contenido. Se utiliza cuando se necesita realizar un análisis de dominio: el analista interroga al cliente con el objetivo de conocer las entidades más importantes en el dominio del cliente. Se deben tomar notas durante la conversación entre el cliente y el analista. A partir de estas notas, se buscan nombres de clases de objetos modelo (por ejemplo, proveedor, pedido, factura, etc.) y se convierten en clases.

Los métodos de estas clases también se buscan mediante la búsqueda de verbos (por ejemplo, calcular, imprimir, agregar, etc.). Esto muestra una vista de la aplicación en un momento específico, cuando el sistema está en suspensión o detenido.

Elementos

Un diagrama de clases se compone de los siguientes elementos:

  • Clase: atributos, métodos y visibilidad
  • Relaciones: herencia, asociación, montaje y uso

Pasos para crear el diagrama de clases

  • Identificar las clases, nombrarlas y definirlas.
  • Mostrar atributos y operaciones.
  • Identificar, nombrar y definir asociaciones entre pares de clases.
  • Etiquetar asociaciones y, si es necesario, roles
  • Indicar multiplicidad
  • Dibujar flechas de dirección
  • Evaluar cada asociación para determinar si debe ser una agregación y cada agregación para ver si debe ser una composición.
  • Evaluar las clases para encontrar una posible generalización (herencia).

Diagramas de objetos

En UML, los diagramas de clases se utilizan para visualizar los aspectos estáticos de los componentes básicos del sistema. Los diagramas de interacción se utilizan para visualizar la dinámica del sistema y consisten en instancias de estos bloques y mensajes enviados entre ellos. Un diagrama de objeto contiene un conjunto de instancias de los elementos que se encuentran en un diagrama de clases.

Por tanto, un diagrama de objetos expresa la parte estática de una interacción, formada por los objetos que colaboran, pero sin ninguno de los mensajes enviados entre ellos, es decir, son como instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos. Un diagrama de objetos es simplemente un diagrama que representa un conjunto de objetos y sus relaciones en un momento determinado. Un diagrama de objetos contiene objetos y enlaces.

Como otros diagramas, puede contener notas y restricciones. Los diagramas de objetos también pueden contener paquetes o subsistemas, que se utilizan para agrupar elementos de un modelo en partes más grandes. A veces, las clases se insertan en diagramas de objetos, especialmente cuando desea mostrar qué clase está detrás de cada instancia. Un objeto se representa de la misma forma que una clase.

El nombre del objeto aparece en el compartimento superior junto con el nombre de la clase subrayado, según la siguiente sintaxis: Nombre del objeto: Nombre de la Clase Puede representarse un objeto sin un nombre específico, entonces solo aparecerá el nombre de la clase subrayado.

El especialista en la programación

Para el profesional de la informática, es importante conocer tanto como le sea posible acerca de las últimas tecnologías. Por ello, se hace necesaria la capacitación constante debido a la gran velocidad a la que avanza esta área. En TECH Universidad Tecnológica se desarrollan algunos de los mejores programas educativos del mundo.

Tal es el caso de su Facultad de Informática, donde se pueden hallar especializaciones tales como el Máster en Tecnología Específica de Telecomunicación y el Máster en Visual Analytics & Big Data. Sin embargo, para aquellos profesionales que buscan dominar el área de la programación aplicada, no cabe duda que su mejor elección será el Máster en Ingeniería de Software y Sistemas de Información.

Artículos relacionados

1 /

Compartir