4.2 Clases

"Hay un método para identificar clases de dominio en potencia que es el análisis de un texto en busca de los sustantivos. Esta técnica puede ser útil cuando no tiene idea de lo que está haciendo y quiere algunas ideas iniciales. Sin embargo, es mala porque en muchos lugares se enseña como una forma "tosca" de extraer información." (Cardozzo, 2016).

De vez en cuando puede escuchar a alguien con la vieja idea de crear un intérprete mágico, un tipo de inteligencia artificial, capaz de generar un sistema basado en un texto que describe las necesidades del usuario. Devaneos a un lado, lo mejor es centrarse en lo que es real a día de hoy.

De hecho, es común el uso de la palabra "Extraer" o "Coger" de forma incorrecta. Cuando creamos un sistema, no extraemos o cogemos los requisitos y las clases necesarias como si ellas existieran allí, ocultas en alguna manera.

En cuanto a los requisitos, el término "deducir" es más apropiado, con el sentido de descubrir y describir. En cuanto a las clases, simplemente decidimos cuál de ellas el sistema debe contener para poder satisfacer las necesidades. Si nos encontramos con que no cumplen con los requisitos, vamos a modificarlas para que los cumplan. Todo esto es un proceso creativo y no un proceso de extracción como se hace con la materia prima. Por "creativo" no piense en arte posmoderno, sino un proceso creativo metódico e incluso científico.

Nuestra recomendación es identificar, a través de los requisitos, los datos que se necesitan para hacer funcionar el sistema, así como la relación entre los mismos. Ya lo dicen los administradores de bases de datos: los datos son el corazón del sistema. Así obtenemos las clases que representan las entidades necesarias. Luego, basándose en las funcionalidades que el sistema debe tener, puede definir clases que son responsables de la manipulación de estas características.

La ingeniería de Software todavía tiene muchos retos por delante para realmente ser una ingeniería en el pleno sentido de la palabra. Hoy en día muchos se consideran más artesanos tecnológicos que ingenieros propiamente dichos. Esto es bueno en un sentido pero también abre muchas lagunas para las "artes abstractas".

Comentarios

Publicar un comentario

Entradas populares de este blog

4.5 Modelo de dominio

Imagen
"Un  Modelo de Dominio  es un artefacto de la  disciplina de análisis , construido con las reglas de  UML  durante la  fase de concepción , en la tarea  construcción del modelo de dominio , presentado como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de software sino de la propia realidad física." (del Águila Cano, 2019) Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo. Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el análista como un medio para comprender el sector industrial o de negocios al cual el sistema va a servir. El siguiente diagrama es un pequeño ejemplo de Modelo de Dominio, en este caso, referido al Metro o sistema de transporte subterraneo de una ciudad cualquiera. Fig. 1 –  Ejemplo de Modelo de Dom...
Leer más

4.3 Modelo de requisitos

"El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo." (Somerville, 2005). El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología  Objectory  (Jacobson et al. 1992), basada principalmente en el modelo de  casos de uso . Actualmente esta metodología es parte del  Proceso Unificado de Rational  (...
Leer más

4.4 Modelo de casos de uso

Imagen
"Un "caso de uso", describe un servicio que el usuario requiere del sistema. Incluye la secuencia completa de interacciones entre el usuario y el sistema de una actividad del sistema que proporciona un servicio específico al usuario. Por ejemplo, son "casos de uso" en un Sistema Retributivo de Nómina: dar de alta, de baja, actualizar los datos de un empleado, obtener mensualmente su nómina, el pago de su cuota patronal y obrera a la Seguridad Social, etc." (Alonso, Martínez y Segovia, 2005). Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuaro un resultado de interés, como dar de alta en nómina a un empleado. Los casos de uso representan los requisitos funcionales y son utilizados con carácter general para la captura de requisitos del sistema. El conjunto de los casos de uso constituye, en el PU, el modelo de casos de uso que describe toda la funcionalidad del sistema. Los casos de uso guían el proceso de desarrollo del...
Leer más