UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTADAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA ACADMICO PROFESIONAL DE INFORMTICA

METODOLOGIA OBJECT-ORIENTED
SOFTWARE ENGINEERING (OOSE)

CURSO:
Sistemas Orientados a Objetos

AUTORES:
Barreto Valderrama Lizbeth Estefany
Cam Urquizo Daniel
Castaeda Gallardo Carlos Eduardo
Gutierrez Romero Fabio

TRUJILLO - PER
2014
RESUMEN

En el presente trabajo se estudia la Metodologa OOSE (Object-Oriented Software

Engineering) siguiendo la siguiente estructura. Introduccin, en la cual se
desarrolla la forma en que OOSE fue creada, se habla de su crear y las
herramientas que hicieron obsoleto a este. Planteamiento, la forma en que Ivar
Jacobson plantea la metodologa sus etapas y tcnicas para desarrollar un sistema
aplicando OOSE. Etapas de OOSE, donde se revisa de manera detallada cada
etapa de la metodologa. Comparativa con otras Metodologas, se compara la
metodologa OMT, Bosch y OOSE y finalmente las Conclusiones sobre la
metodologa y el empleo de esta para realizar sistemas orientados a objetos.

ndice de Contenido
1

OOSE (Ingeniera de Software orientado a objetos)...........................................4

Object-Oriented Engineering
2

1.1 Introduccin.................................................................................................... 4
1.2 Planteamiento................................................................................................ 4
1.3 Etapas de la Metodologa............................................................................... 6
1.3.1

Primera Etapa: Anlisis de Requerimientos o Modelo de Requisitos.........7

1.3.1.1 Diagrama y Modelo de Casos de Uso.......................................................8

1.3.1.2 Descripcin de las Interfaces...................................................................9
1.3.1.3 Modelo de Objeto de Dominio..................................................................9
1.3.2

Segunda Etapa: Anlisis de Estructura o Modelo de Anlisis..................10

1.3.2.1 Objetos del Modelo Ideal........................................................................10

1.3.2.2 Subsistemas........................................................................................... 11
1.3.3

Tercera Etapa: Modelo de Plan o Modelo de Diseo..............................12

1.3.3.1 Diagrama de Bloques (Diseo de Clases)...............................................13

1.3.3.2 Diagrama de la Interaccin....................................................................13
1.3.3.3 Los Grficos de transicin de Estado......................................................14
1.3.3.4 Objetos Reales....................................................................................... 15
1.3.4

Cuarta Etapa : Implementacin o Modelo de Aplicacin........................15

1.3.5

Quinta Etapa: Modelo de Pruebas o Comprobacin................................16

1.4 Comparativa con otras Metodologas...........................................................17

2

CONCLUSIONES............................................................................................... 18

REFERENCIAS BIBLIOGRAFICAS.......................................................................19

Object-Oriented Engineering
3

1 OOSE (Ingeniera de Software orientado a objetos)

2

Introduccin

Con el surgimiento de la orientacin a objetos, se vio la necesidad de crear

metodologas eficaces para modelar estos nuevos sistemas. Cada uno tiene
su propia terminologa y como la descripcin del proceso y la notacin
utilizada.
Quien desarrollo el proceso fue Ivar Jacobson, nacido el 2 de septiembre de
1939, es un cientfico de la computacin sueco que se haba graduado de
maestra en ingeniera electrnica en el Instituto de Tecnologa de Chalmers
en Gotemburgo (1962) y doctorado en el Instituto Real de Tecnologa de
Estocolmo (1985). Jug un papel clave en el desarrollo de UML (Unified
Modelign Language), junto con James Rumbaugh (Object-modeling
technique) y Grady Booch (Mtodo Booch) llamados los tres amigos por
sus constantes plticas sobre el tema, adems de RUP (Proceso Racional
Unificado - Rational Unified Process).
Para implementar la metodologa OOSE, herramienta Objectory fue creado
por el equipo Objectory de AB para implementar el OOSE metodologa. Este
fue el primero, pero despus gran xito, otras herramientas surgieron que
apoyaron al OOSE.
El Objectory AB fusion con Rational y con esta notacin, la metodologa y
OOSE las herramientas fueron sustituidos por utilizado por Rational. Con el
desarrollo UML y la metodologa RUP, la OOSE estaba convirtiendo en
obsoleto desde el RUP tena conceptos claves integradas.
A continuacin se describe el mtodo OOSE (Ingeniera de Software
Orientada a Objetos o en ingls Object Oriented Software Engineering),
desarrollada por Ivar Jacobson en 1992, que est caracterizada
principalmente por el uso de casos de uso para describir el sistema. El
diseo de la metodologa orientada a objetos OOSE es el primero en utilizar
el concepto de casos de uso para definir los paradigmas de diseo software.

Planteamiento

El autor plantea el problema del diseo y construccin de software haciendo

una comparacin con la industria de la construccin, contemplando las
siguientes fases:

Object-Oriented Engineering
4

Ilustracin 1. Diseo y Construccin de Software (Vista desde la Industria de Construccin).

Herramientas: Soportan todos los aspectos de la empresa, como

actividades de arquitectura, mtodos y procesos.
Procesos: Permite el escalamiento de los mtodos, de tal forma que
puedan ser aplicados a proyectos de forma interactiva y en partes.
Mtodos: Establece de manera explcita los procedimientos etapa
por etapa que deben seguirse para aplicar la arquitectura al proyecto.
Arquitectura: Una buena estructura del sistema es fcil de
entender, de cambiar y realizar pruebas y mantenimiento debido a
que son extremadamente importantes y forman la base del mtodo.
Jacobson Propone una metodologa de desarrollo de aplicaciones orientada
a objetos. Propone el desarrollo de sistemas basados en el uso de distintos
modelos. Proporciona un soporte para el diseo creativo de productos de
software. Las actividades consisten en la transformacin de un conjunto de
requisitos en un plan estructurado de construccin y plan de accin.
El modelo de casos de uso de acuerdo con Jacobson, es la base en la etapa
de anlisis, construccin y prueba. OOSE presenta cinco tcnicas para
modelar un sistema:

Object-Oriented Engineering
5

Ilustracin 2. Tcnicas para modelar un Sistema.

Modelo de requerimientos: define la limitacin del sistema y

especifica su comportamiento. Se compone de un modelo de casos
de uso, descripciones de la interfaz, y un modelo de dominio del
problema.
El modelo de anlisis: El objetivo de este modelo es producir
estructura ideal, robusta y modificable de un objeto.
El modelo de diseo: Refina los objetos manteniendo el ambiente
de implementacin en mente. Consiste de diagramas de interaccin y
diagramas de transicin de estados.
El modelo de implementacin: Consiste en el cdigo fuente de los
objetos especificados en el modelo de diseo.
El modelo de prueba: El objetivo del modelo de examen es
comprobar y verificar la funcionalidad del sistema.
La idea bsica de estos modelos es capturar el concepto inicial de todos los
requerimientos funcionales y usar sus perspectivas. Es por eso que la
relacin entre ellos es importante. Para ser posible el mantenimiento del
sistema es tambin necesario que los modelos sean tangibles.

Object-Oriented Engineering
6

Ilustracin 3. Diagramas Caso de Uso.

Etapas de la Metodologa

Anlisis: Se centra en la comprensin del sistema y la creacin de un

modelo conceptual. Consiste en dos sub-fases, iterativos no
secuenciales.
o Anlisis de Requerimientos: Con miras a obtener y el modelado
de los requisitos del sistema. A Requisitos Modelo se produce.
o Anlisis de robustez, destinado a modelar la estructura del
sistema. Modelo de anlisis se produce.
Construccin: se centra en la creacin de un modelo del software y de
la produccin de la produccin del cdigo de cdigo C.
o Diseo: Destinado a modelar la estructura de tiempo de
ejecucin del sistema, y tambin el inter-objeto y el
comportamiento intra-objeto. Es un modelo de diseo producido.
o Ejecucin: Con el objetivo de construir el software. Un modelo de
implementacin (incluyendo el cdigo) se produce.
Pruebas: Centrado en verificar y validar la implementacin del sistema.

Object-Oriented Engineering
7

Ilustracin 4. Etapas o Fases de OOSE.

4.1.1 Primera

Etapa:

Anlisis

de

Requerimientos

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 anlisis.
Este modelo delimita el sistema y define su funcionalidad.
Consiste en tres partes:
o

o
o

Un modelo de caso de uso.

Descripcin de las interfaces.
Un modelo en el dominio del problema.

4.1.1.1 Diagrama y Modelo de Casos de Uso

Documentan el comportamiento de un sistema desde el
punto de vista del usuario. Por lo tanto los casos de uso
determinan los requisitos funcionales del sistema, es
decir, representan las funciones que un sistema puede
ejecutar.

Object-Oriented Engineering
8

Actor:
Es una idealizacin de una persona externa (rol),
organizacin u otro sistema que interacta con un
sistema, subsistema o clase.
Caso de uso:
Es una unidad o tarea de funcionalidad visible
externamente coherente proporcionada por una unidad
de sistema y expresada por secuencias de mensajes
intercambiados por la unidad del sistema y uno o ms
agentes de la unidad del sistema
Tambin hay otro elementos como Asociaciones (une
actor y caso de uso) y un escenario (representa la
secuencia de mensajes y que tambin es lo ms general)
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.

Ilustracin 5. Modelo de Caso de Uso

Otra
caracterstica
importante
del
modelo
de
requerimientos es que podemos discutir esto con el
usuario y encontrar sus requerimientos y preferencias.
Este modelo es fcil de entender y formular desde la
perspectiva del usuario y generar un buen sistema de
acuerdo a sus requerimientos.

Object-Oriented Engineering
9

Ilustracin 6. Diagrama de Casos de Uso de Jacobson.

4.1.1.2 Descripcin 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. Puede tratarse que ambos usuario sean
unidos con otros sistemas por la interface.
Prototipos de interfaz facilitan la comunicacin con los
usuarios.
Muestran lo que los usuarios
corriendo el caso de uso.

ven

cuando

estn

Reduce la posibilidad de un desacuerdo entre lo que

quiere y lo que los proyectos de los analistas

4.1.1.3 Modelo de Objeto de Dominio

Para desarrollar una vista lgica del sistema que puede
usarse para hacer una lista que especifique los casos del
uso. El modelo de caso de uso controla la formulacin de
otros modelos. Esto es desarrollado en cooperacin con
el modelo de dominio de objeto. Se define los conceptos
con los que el sistema debe trabajar, muestra las
instancias de objetos, clases y relacin de asociaciones.

Object-Oriented Engineering
10

Ilustracin 7. Modelado de Objeto de Dominio.

4.1.2 Segunda Etapa: Anlisis de Estructura o Modelo de

Anlisis
En esta etapa comienza el Desarrollo del sistema real con el
modelo de anlisis o Modelo Ideal. Aqu 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.
Metas del Modelo
o
o
o

Construccin del Sistema propiamente tal.

Obviar la aplicacin y todo lo que conlleva esta.
Establecer la robustez del Sistema.

Objetivos
o
o
o
o
o

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).

4.1.2.1 Objetos del Modelo Ideal

o

Los objetos de Control: Su propsito: controlar la

conducta del sistema en la primera aproximacin, ellos
pueden derivarse de los casos del uso.
Los objetos de la entidad: Su propsito: recordar
estado del sistema en la primera aproximacin, ellos
pueden derivarse de los objetos del dominio.
Los objetos de la interface: Su propsito: presentar
el sistema a fuera en la primera aproximacin, ellos
pueden derivarse de las asociaciones de la interaccin.

Object-Oriented Engineering
11

Ilustracin 8. Elementos del Diagrama de Modelo

de Anlisis

Ilustracin 9. Ejemplo del Diagrama de Modelo

de Anlisis-

4.1.2.2 Subsistemas
o
o
o
o

Agrupan los objetos en uno o ms niveles

Para obtener una clara visin y comprensin del modelo
Reduccin de la complejidad disponiendo el desarrollo y
mantenimiento de la estructura
La divisin en subsistemas debera basarse en la
funcionalidad del sistema y fuerte acoplamiento entre
objetos

Object-Oriented Engineering
12

Ilustracin 10. Diagrama de un Subsistema.

4.1.3 Tercera Etapa: Modelo de Plan o Modelo de Diseo

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.
Caractersticas:
o
o

Describe las caractersticas del entorno de ejecucin

Describe los detalles de las clases de diseo (denominados
describe los detalles de las clases de diseo (en adelante,
bloques) necesarios para implementar el sistema
Describe la forma de ejecucin se describe la forma en los
objetos en tiempo de ejecucin debe comportarse.

Sub Fases:
o

Determinacin de las caractersticas del entorno de

ejecucin (DBMS, las caractersticas del lenguaje de
programacin, distribucin consideraciones)

Definicin de los bloques (clases de diseo) y su estructura:

Cada objeto en el modelo de anlisis se asigna a una
Cada objeto en el modelo de anlisis se asigna a un
bloque.
Se aaden los bloques especficos de la
implementacin y la coleccin se revisa.
Interfaces y semntica de las operaciones son
definidas.

Object-Oriented Engineering
13

Especificacin de las secuencias de las interacciones entre

los objetos y el comportamiento dinmico de cada bloque:
Un diagrama de interaccin se realiza para cada uno
de los casos de uso.
Un diagrama estado de transicin se utiliza para
describir el comportamiento de cada bloque.

4.1.3.1 Diagrama de Bloques (Diseo de Clases)

Un bloque es un objeto de diseo. Los diferentes tipos de
bloques se pueden usar inicialmente, cada objeto de
anlisis simplemente se transforma en un bloque.
Un diagrama de clases sirve para visualizar las
relaciones entre las clases que involucran el sistema, las
cuales pueden ser asociativas, de herencia, de uso y de
consentimiento.
Un diagrama de clases est compuesto por los
siguientes elementos: Clases, atributos, mtodos y sus
relaciones.

Ilustracin 11. Diagrama de Bloques

4.1.3.2 Diagrama de la Interaccin

Es llevado para cada caso del uso concreto. Describe lo
que el uso incluye por lo que se refiere a comunicar los
objetos. Esta comunicacin se planea como bloques que
envan los estmulos a nosotros. La interaccin hace el
diagrama de los casos de uso de apoyo con las
extensiones. En este caso, se agregan las posiciones de
las sondas a un diagrama de interaccin. Una posicin
de sonda indica una posicin en el caso del uso que se
ser extendido y a menudo una condicin se requiere
para cuando la extensin se permite tener lugar. Las
interacciones de muestras entre varios objetos en la
sucesin de tiempo (y posiblemente en la balanza de
tiempo, si es necesario). El diagrama de la interaccin es
una manera apropiada de expresar los guiones
conductuales. El diagrama de interaccin hace que OOSE
pueda involucrar alternativas o iteraciones, ya que ellos

Object-Oriented Engineering
14

son basados en la descripcin de un caso del uso en el

idioma estructurado. Puede describir cmo cada caso de
uso es manejado por la interaccin de los objetos,
adems la interaccin recibe y enva un estmulo de un
bloque a otro, as como tambin diferentes objetos
colaboran para resolver un caso de uso.

Ilustracin 12. Diagrama de Interaccin (Secuencia).

4.1.3.3 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. OOSE usa una extensin de la
anotacin de SDL (la Especificacin e Idioma de la
Descripcin que son un CCITT normal). (LSTG) describe
la conducta de un objeto en un idioma de manera
independiente. Qu mensajes despliega (o estmulos) se
recibe de otros objetos y que se enva por el objeto hacia

Object-Oriented Engineering
15

fuera. LSTG tambin incluye los estados del ciclo de vida

computacional del objeto.

4.1.3.4 Objetos Reales

El mapa transparentemente a un objeto ideal (pero la
cartografa no necesita ser uno a uno). El objeto real
encapsula varias clases que trazan transparentemente al
ambiente de aplicacin. Algunas clases son pblicas
(ellos comunican con las clases en otros objetos reales),
algunos pueden ser privados (oculto y as protegi del
mundo externo).
Este Modelo es un refinamiento y formalizacin del
anterior. Sus metas:
o

o
o
o
o
o
o
o
o

4.1.4 Cuarta

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.

Etapa

Implementacin

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.
Aqu los paquetes, antes mencionados, pasan a ser clases.
Metas del Modelo:

Object-Oriented Engineering
16

o
o
o

Disear clases que sean robustas y favorablemente

reusables.
Los objetos reales llevando a cabo en un idioma de la
programacin.
La traceabilidad (que es la caracterstica que permite a las
clases poder comunicarse y relacionarse con otras clases).

4.1.5 Quinta Etapa: Modelo de Pruebas o Comprobacin

En esta etapa se procede a probar tanto las aplicaciones como
el funcionamiento de las clases y la robustez del sistema, si
esta ltima es buena no debera fallar el sistema ante
situaciones defectuosas. Se recomienda comenzar por los
niveles ms bajos del sistema, es decir:
o
o

Mdulos de Objetos y Blocks. Casos de Uso

El Desarrollo de la Aplicacin

Los modelos de testeo son resultados de las pruebas

documentadas. Todos los informes de las pruebas: parte estn
probando, el tipo de prueba que se realiza, utiliza datos de
resultados y evaluacin (defectuoso o bien) obtenidos, adems
es iimportante cuando el sistema est siendo desarrollado
como un equipo. El modelo a desarrollar es el modelo de
prueba, que consiste principalmente en:
o
o
o

Plan de pruebas
Especificaciones de prueba Especificaciones de prueba
Resultados de la prueba.

Y las faces son:

o

Comprobacin de unidad: Examina por partes menores

como operaciones de clases o clases y la base para estas
dos pruebas es el modelo de diseo, en particular, el
modelo de interfaz de bloque.
Comprobacin de integracin: Reune todas las clases
envueltas en un determinado caso de uso, o comunicacin y
colaborando para la resolucin de caso de uso.
Comprobacin de sistema: Los casos de uso son
probados en conjunto, verifica que los casos relacionados
estn de acuerdo.

Object-Oriented Engineering
17

Ilustracin 13. Rol de Casos de Uso

Comparativa con otras Metodologas

Comparativa con las metodologas contemporneas a

Jacobson
METODOLOGI
AS
DESARROLLA
DOR

Ingeniera de
software orientado a
objetos OOSE
Desarrollada por Ivar
Jacobson.

Tcnica de
modelado de
objetos OMT
Desarrollada por
James Rumbaugh.

El modelo de caso de
uso sirve como modelo
central.

Describe el anlisis y
diseo orientado a
objetos, que
incorporan tanto
comportamiento
como estructuras de
datos.
La esencia del
desarrollo es la
identificacin y
organizacin de
conceptos en el
dominio del
problema.

La parte ms
importante en el
anlisis y diseo
orientado a objetos
es
la identificacin de
clases y objetos.

El sistema es descrito
a partir de tres
modelos
diferentes: un modelo
de objetos, un modelo
dinmico, y un

Propone cuatro
modelos de
desarrollo orientado
a objetos:
estructura fsica y
lgica y su

FUNCIONALID
AD

ENFOQUE

MODELOS

El modelo de caso de
uso es la base en la
etapa de anlisis,
construccin y prueba.

Presenta cinco tcnicas

para modelar un
sistema:
Modelo de
requerimientos,
anlisis, diseo,

Object-Oriented Engineering
18

Metodologa
Booch
Desarrollada por
Grady Booch.
La realizacin de
modelos es muy
importante para la
construccin de
sistemas
complejos.

implementacin y
prueba.

modelo funcional.

semntica esttica
y dinmica.

Estos modelos
capturan el concepto
inicial de todos los
requerimientos
funcionales y usar sus
perspectivas

Cada modelo describe

un aspecto del
sistema pero contiene
referencias a los
dems
Modelos, por eso no
son totalmente
independientes.

Los aspectos
metodolgicos
fueron incorporados
en varias
metodologas y
procesos, siendo la
principal el Proceso
Racional Unificado
(RUP).

FUERZA

Mtodo fuerte para

producir requisitos
orientados al usuario y
orientada a objetos
modelo de anlisis.

Mtodo fuerte para la

produccin de modelo
de objetos de
estructura esttica
del sistema.

Mtodo fuerte para

la produccin
orientada a objetos
detallados
modelos de diseo.

DEBILIDAD

No trate la
programacin
orientada a objetos al
mismo nivel que otros
mtodos.

No se puede expresar
plenamente los
requisitos.

Centrarse
exclusivamente en
el
diseo y no en
anlisis.

FUNCIONALID
AD
MODELOS

6 CONCLUSIONES
Este es el mtodo ms completo, de los que se presentan aqu, que abarca todas
las etapas del proceso de desarrollo, pero su objetivo principal es los requisitos de
la fase de anlisis. Tiene caractersticas favorables para los sistemas que
requieren la participacin de los usuarios y los expertos en el dominio en el que
detalla los requisitos debidos al uso de casos de uso, los actores y los diagramas
de interaccin.
Los casos de uso conducen a lo largo del desarrollo del sistema, lo que permite la
coherencia entre los modelos generados en las distintas fases, porque todo el
mundo se centrar en el perfeccionamiento de los casos de uso.
Otros mtodos no tienen este enfoque, trate de identificar todos los objetos y sus
relaciones, a continuacin, hacer algn tipo de modularizacin. El mtodo
presenta los objetos del modelo de anlisis de dominio adicional (objetos de
control y los objetos de la interfaz). El uso de este tipo de objetos es defendida por
los autores como una forma de facilitar las actualizaciones y el mantenimiento
futuro del sistema, ya que seran ms localizada, que afecta slo a los objetos con
mayor riesgo de cambios (interfaz y control) La notacin que el mtodo utiliza es
bastante diferente de todos los dems mtodos presentados aqu, que tienen

Object-Oriented Engineering
19

algunas caractersticas comunes entre ellos. Por ejemplo, la representacin de la

externa atribuye la representacin del objeto, lo que hace difcil comprender los
diagramas para los principiantes. El mtodo se puede utilizar en el desarrollo de
grandes sistemas reales. Est indicado para el uso de los equipos de desarrollo y
no por un solo desarrollador; siendo que esquipes deben tener formacin en
anlisis, diseo y programacin.
Centrndose en los casos de uso en todas las etapas tiende a asegurar un sistema
es consistente y coherente
Esta metodologa favorece el desarrollo del equipo, ya que permite que las fases
se producen en paralelo.

7 REFERENCIAS BIBLIOGRAFICAS
Ingeniera de Software. Consultado el 18 de Enero del 2015. Disponible en
http://adimen.si.ehu.es/~rigau/teaching/EHU/ISO/Curs20112012/Apunts/IS.7.pdf
Instituto Tecnolgico de la Laguna. Anlisis y Diseo Orientado a Objetos
(Resumen). Consultado el 18 de Enero del 2015. Disponible en
http://www.itlalaguna.edu.mx/Academico/Carreras/sistemas/Analisis%20y
%20dise%C3%B1o%20orientado%20a%20objetos/Resumen3.pdf
Wikipedia (2014) Ivar Jacobson. En Wikipedia. Consultado el 18 de Enero del
2015. Disponible en http://es.wikipedia.org/wiki/Ivar_Jacobson
Finkelstein, A. (1999) Unit5: Object-Oriented Software Engineering.
Consultado el 18 de Enero del 2015. Disponible en
http://www0.cs.ucl.ac.uk/staff/A.Finkelstein/crsenotes/1B1499REQTS.pdf

Object-Oriented Engineering
20

 Ramsin, R. Software Development Methodologies. Consultado el 18 de

Enero del 2015. Disponible en
http://sharif.edu/~ramsin/index_files/sdmlecture4.pdf
Volkweis, M. (2010). Objectory. En Scribd. Consultado el 18 de Enero del
2015. Disponible en http://es.scribd.com/doc/31791340/Objectory#scribd

Object-Oriented Engineering
21