INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS PorIvar Jacobson

INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS

porIvar Jacobson

Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial. El autor plantea el problema del diseño y construcción de software haciendo una comparación con la industria de la construcción, contemplando las siguientes fases:

Herramientas. Soportan todos los aspectos de la empresa, explícitamente las actividades de arquitectura, métodos y procesos.

Procesos. Permite el escalamiento de los métodos, de tal forma que puedan ser aplicados a proyectos de forma interactiva y en partes.

Métodos. Establece de manera explícita los procedimientos etapa por etapa que deben seguirse para aplicar la arquitectura al proyecto.

Arquitectura. Una buena estructura del sistema es fácil de entender, de cambiar y realizar pruebas y mantenimiento. Las propiedades del sistema determinan como la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la arquitectura son extremadamente importantes y forman la base del método.

El método desarrollado por Ivar Jacobson OOSE ha sido llamado “un enfoque para el manejo de casos de uso”, en este enfoque el modelo de casos de uso sirve como un modelo central del cual todos los otros modelos son derivados. Un modelo de casos de uso describe la funcionalidad completa del sistema, identificando como, todo lo que esta fuera del sistema, interactúa con él.

El modelo de casos de uso de acuerdo con Jacobson, es la base en la etapa de análisis, construcción y prueba. OOSE presenta cinco técnicas para modelar un sistema:

ETAPAS:

I. ETAPA: ANÁLISIS DE REQUERIMIENTOS O MODELO DE REQUISITOS

Un modelo de requerimientos es creado para especificar toda la funcionalidad del sistema. Esto es principalmente hecho por casos de uso. Este modelo es la base del modelo de análisis. Este modelo delimita el sistema y define su funcionalidad. Consiste en tres partes:

 Un modelo de caso de uso

 Descripción de la interfaces

 Un modelo en el dominio del problema

Modelo de casos de usos: Los actores representan quienes interactúan con el sistema. Representan todas las necesidades de cambio de información con el sistema. Dado que el actor representa la parte exterior del sistema no se describirán detalles de ellos. La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el sistema, mientras que el actor es un rol que el usuario puede jugar.

Otra característica importante del modelo de requerimientos es que podemos discutir esto con el usuario y encontrar sus requerimientos y preferencias. Este modelo es fácil de entender y formularlo desde la perspectiva del usuario y generar un buen sistema de acuerdo a sus requerimientos.

Descripción de las interfaces: Es importante que los usuarios estén envueltos en las descripciones de las interfaces detalladas. Por consiguiente estas descripciones deben hacerse en una fase temprana. La interface tiene que capturar la vista lógica del usuario del sistema, porque el interés principal es la consistencia de esta vista lógica y la conducta real del sistema. Puede tratarse que ambos usuario sean unidos con otros sistemas por la interface.

Modelo de objeto de dominio: Para desarrollar una vista lógica del sistema que puede usarse para hacer una lista que especifique los casos del uso. El modelo de caso de uso controla la formulación de otros modelos. Esto es desarrollado en cooperación con el modelo de dominio de objeto.

II. ETAPA: ANÁLISIS DE ESTRUCTURA O MODELO IDEAL

Una vez realizado el modelo de requisitos y que ha sido aceptado por los usuarios del sistema o clientes, comienza el Desarrollo del sistema real con el modelo de análisis o Modelo Ideal. Aquí se define la estructura lógica del sistema independiente de la aplicación. En este modelo se especifican todos los objetos lógicos que serán incluidos en el sistema y como están relacionados y agrupados.

Metas del Modelo

 Construcción del Sistema propiamente tal

 Obviar la aplicación y todo lo que conlleva esta

 Establecer la robustez del Sistema

Objetivos:

 Reconocer los objetos que forman parte del Sistema

 Reconocer asociaciones y estructuras de objetos

 Asignar atributos a los objetos

 Asociar un objeto a sus atributos

 Dividir el sistema en subsistemas (para preparar más adelante los paquetes)

Objetos del Modelo Ideal

Los objetos de Control

Su propósito: controlar la conducta del sistema en la primera aproximación, ellos pueden derivarse de los casos del uso.

Los objetos de la entidad

Su propósito: recordar estado del sistema en la primera aproximación, ellos pueden derivarse de los objetos del dominio

Los objetos de la interface

Su propósito: presentar el sistema a fuera en la primera aproximación, ellos pueden derivarse de las asociaciones de la interacción.

III. ETAPA: MODELO DE PLAN O MODELO REAL

En este Modelo se definen Interfaces de Objetos y semántica de funcionamientos y pueden tomarse las decisiones sobre los Sistemas de Dirección de Banco de datos y los lenguajes de programación. Se introducen los bloques para los tipos del objeto para esconder la aplicación real. El modelo del plan consiste en diagramas de la interacción y gráficos de transición de estado.

Un diagrama de la interacción: Es llevado para cada caso del uso concreto. Describe lo que el uso incluye

...