Ivar Jacobson

Ivar Hjalmar Jacobson 2 de septiembre 1939, es un

ingeniero sueco en Ciencias de la computacin.

Invent el diagrama de secuencia y desarroll los diagramas de colaboracin.

Tambin impuso el uso de diagramas de estado de transicin para describir los flujos de mensajes entre los componentes. Fue uno de los desarrolladores originales del SDL (lenguaje de especificacin), que se convirti en estndar en 1967.

 En 1967 en Ericsson, Jacobson propuso el uso de componentes de software

en la nueva generacin de software de conmutadores telefnicos controlados que Ericsson estaba desarrollando.

Al hacer esto, l invent los diagramas de secuencia y diagramas de

colaboracin desarrollada.

 En octubre de 1995 Ericsson se deshizo Objectory de Software Racional y

Jacobson comenz a trabajar con Grady Booch y James Rumbaugh, conocidos colectivamente como los Tres Amigos.

Aportaciones
Invent el diagrama de secuencia y desarroll los diagramas de colaboracin. Tambin invent casos de uso como una forma de especificar los requisitos
funcionales de software.

Impuso el uso de diagramas de estado de transicin para describir los flujos

de mensajes entre los componentes.

Desarrollador original del SDL (lenguaje de especificacin)

Diagrama de secuencia

Objetos
Se representan por rectngulos con nombre (subrayado), mensajes entre los
objetos representados por lneas continuas con una punta de flecha y el tiempo representado como una progresin vertical

 Se colocan cerca de la parte superior del diagrama de izquierda a derecha y se

acomoda de manera que simplifiquen el diagrama

La extensin que est debajo (y en forma descendiente) de cada objeto ser

una lnea discontinua conocida como lnea de vida de un objeto

 Junto con la lnea de un objeto hay un rectngulo conocido como activacin,

el cual representa una operacin que realiza el objeto longitud del rectngulo se interpreta como la duracin de la activacin

Mensajes
Puede ser simple, sncrono o asncrono. Simple: es la transferencia del control de un objeto a otro. Sncrono: aquel en el que el objeto espera la respuesta a ese mensaje antes de continuar con
su trabajo.

Asncrono: aquel en el que el objeto no espera la respuesta a ese mensaje antes de continuar

Tiempo
Se representa en direccin vertical. Se inicia en la parte superior y avanza
hacia la parte inferior.

El diagrama de secuencias tiene dos dimensiones. La dimensin horizontal es

la disposicin de los objetos, y la dimensin vertical muestra el paso del tiempo

Primera Etapa: Anlisis de Requerimientos o Modelo de Requisitos

MODELO DE CASOS DE USOS: Los actores representan quienes
interactan con el sistema. Representan todas las necesidades de cambio de informacin con el sistema. Dado que el actor representa la parte exterior del sistema no se describirn 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.

 DESCRIPCION DE LAS INTERFACES: Es importante que los

usuarios estn 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 lgica del usuario del sistema, porque el inters principal es la consistencia de esta vista lgica y la conducta real del sistema.

Segunda Etapa: Anlisis 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 anlisis o Modelo Ideal. Se define la estructura lgica del sistema independiente de la aplicacin. En este modelo se especifican todos los objetos lgicos que sern incluidos en el sistema y como estn relacionados y agrupados.

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 ms adelante los paquetes)

Objetos del Modelo Ideal

Objetos de Control
Su propsito: controlar la conducta del sistema en la primera aproximacin, ellos pueden derivarse de los casos del uso.

 Objetos de Entidad
Su propsito: recordar estado del sistema en la primera aproximacin, ellos pueden derivarse de los objetos del dominio.

 Objetos de Interface
Su propsito: presentar el sistema a fuera en la primera aproximacin, ellos pueden derivarse de las asociaciones de la interaccin.

Tercera Etapa: Modelo de Plan o Modelo Real

En este Modelo se definen Interfaces de Objetos y semntica de
funcionamientos y pueden tomarse las decisiones sobre los Sistemas de Direccin de Banco de datos y los lenguajes de programacin. Se introducen los bloques para los tipos del objeto para esconder la aplicacin real. El modelo del plan consiste en diagramas de la interaccin y grficos de transicin de estado.

LOS GRFICOS DE TRANSICIN DE ESTADO: Se usan para describir conducta del objeto por lo que se refiere a que pueden recibirse los estmulos y qu estmulos pueden causar.

 Modelar el sistema adaptndolo al ambiente de aplicacin real .(en este punto es donde entran componentes
del Sistema como DBMS, lenguaje de programacin, etc.)

El sistema debe ser tolerante a los cambios en el ambiente de aplicacin Deben establecerse interfaces de objetos para que el desarrollo extenso pueda realizarse en paralelo. Los requisitos en la arquitectura, actuacin, la memoria, la distribucin etc. Generalmente podemos decir: Se reconocen los objetos reales. Dibujar diagramas de interaccin para los guiones de casos de uso de usos particulares.

Construir los grficos de estado-transicin para describir conducta de objetos reales.

Dentro del modelo podemos distinguir los componentes de plan real

Cuarta Etapa : Implementacin o Modelo de Aplicacin

En esta etapa es cuando se procede a la ejecucin del cdigo fuente que ha
sido seleccionado. Es la codificacin del sistema tanto el desarrollo de las Bases de Datos como de los distintas aplicaciones con las que contar.

Quinta Etapa: Modelo de Pruebas o Comprobacin

En esta etapa se prueban tanto las aplicaciones y la robustez del sistema que
se diseo y programo con anterioridad.

Algunas preguntas que cabran realizar en esta etapa son:

Hay faltas en el Programa? Dnde? La aprobacin Ha sido el sistema correcto? La comprobacin Ha sido el sistema creado correctamente?

 La comprobacin de esta etapa es el Modelo de Requisitos, ya que si se

cumplen todos los requisitos all especificados, pasa la aprobacin. Aqu nuevamente la Robustez del sistema ayuda a la localizacin de faltas y la trazabilidad ayuda al movimiento dentro del Modelo del Plan (a donde la falta ser corregida).