Para entendernos, tanto los usuarios como los programadores, deberíamos hablar un mismo lenguaje de manipulación de la información.
Para manipular las bases de datos usamos el
Lenguaje Estructurado de Consultas - SQL (en inglés, Structured Query Language), aunque no seamos conscientes de ello porque las sentencias están incrustadas dentro de la aplicación que interactua con las bases de datos, pero para definir la estructura de un programa o de una aplicación no hemos definido un lenguaje común con los usuarios.
Los ingenieros de software creamos la
Arquitectura de la Información mediante técnicas de modelado, diccionarios y lenguajes propios que no compartimos con los usuarios como son:
-
Diagramas de Flujo de Datos - DFD
-
Modelo de Datos Lógicos (en inglés,
Logical Data Model - LDM) mediante esquemas conceptuales de alto nivel (SAM o HDM)
-
Diccionarios de Datos - DD como conjuntos de metadatos en una
Base de Datos - BD.
Para visualizar, especificar, construir y documentar una aplicación informática nos entendemos con los programadores en el lenguaje gráfico de modelado de sistemas de software más conocido y utilizado actualmente, el
Lenguaje Unificado de Modelado - UML (en inglés, Unified Modeling Language) que se basa en 13 tipos diferentes de diagramas clasificados en 3 categorías:
-
Diagramas de Estructura: clases, componentes, objetos, compuesta, despliegue, paquetes.
-
Diagramas de Comportamiento: actividades, casos de uso, estados.
-
Diagramas de Interacción: secuencia, comunicación, colaboración, tiempos, vistas.
El problema es que UML carece de una semántica precisa, por lo que no es objetivo y puede provocar interpretaciones distintas para distintos usuarios. Otro factor es su falta de definición de componentes persistentes en aplicaciones remotas y sistemas distribuidos. Pero lo peor es la libertad para emplear cualquiera de los 13 tipos de diagramas, aún no siendo supersticiosos. Siempre se empleará el menos apropiado siguiendo el sentido común...
Para facilitar un
Diseño Interactivo es mejor decidirse por los Diagramas de Comportamiento, como los
diagramas de casos de uso y los
diagramas de estados que no dejan lugar a dudas sobre la interacción con los usuarios y se les puede mostrar para tomar decisiones conjuntas referentes al
diseño estructurado del proyecto de un Calendario Perpetuo en Excel:
Como se puede ver en este Diagrama de Casos de Uso, coexisten diversos tipos de usuarios, desde el comercial o el secretario a la gente práctica o controladora, desde los clientes de todo tipo a los trabajadores y parados. Todos quieren saber cómo van a ser sus próximos días, meses o años (algunos nostálgicos mirarán los años pasados) y algunos intentarán seguir el presente en sus diarios.
Si no es indiscrección, ¿qué tipo de usuario eres tú y en qué lenguaje te comunicas?
English translation of this post
here.
No Response to "La Estructura del Calendario Perpetuo"
Leave A Reply
Indícame las erratas que encuentres y qué es lo que te gustaría ver en los próximos artículos.