4.1 Objetos

Hay varios métodos de modelado orientado a objetos que hasta el advenimiento de UML causaron una guerra entre la comunidad de desarrolladores orientado a objetos. El UML terminó esta guerra al traer las mejores ideas de cada uno de estos métodos, y mostrando cómo debería ser la migración de cada uno para UML. (Gracia Burgués, 2016).

Se mostrara las principales metodologías que se hicieron populares en los años 90:

- Booch: El método de Grady Booch para el desarrollo orientado a objetos está disponible en muchas versiones. Booch define la noción de que un sistema se analiza a partir de un número de puntos de vista, donde cada vista describe mediante una serie de modelos y diagramas. El Método de Booch trajo una simbología compleja para ser dibujada a mano, también contenía el proceso por el cual los sistemas se analizan para macro y macro vistas.

 - OMT: Técnica de Modelado de Objetos (Object Modelling Technique) es un método desarrollado por GE (General Electric), donde James Rumbaugh trabajaba. El método está especialmente dirigido para la prueba de modelos, basado en las especificaciones del análisis de requisitos del sistema. El modelo total del sistema basado en el método OMT está compuesto por la unión de los modelos de objetos, funcional y de casos de uso.

 - OOSE / Objectory: Los métodos Objectory y OOSE se desarrollaron basándose en el mismo punto de vista creado por Ivar Jacobson. El Método OOSE es la visión de Jacobson de un método orientado a objetos, ya que el Objectory se utiliza para la construcción de sistemas tan diversos como puedan ser. Ambos métodos se basan en la utilización de casos de uso, que definen los requisitos iniciales del sistema, vistos por un actor externo. El método Objectory también fue adaptado para la ingeniería de negocios, donde se utiliza para modelar y mejorar los procesos involucrados en el funcionamiento de las empresas.

 Cada uno de estos métodos tiene su propia notación (sus propios símbolos para representar los modelos orientados a objetos), procesos (que actividades se desarrollan en las diferentes partes del desarrollo) y herramientas (herramientas CASE que soportan cada una de estas notaciones y procesos.)

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