Análisis de sistemas orientado a objetos: estado del …ucongreso.edu.ar/grado/carreras/lsi/Introduccion_al_UML1.pdfde datos relacionales (Coad & Yourdon, Martin & Odell, Rumbaugh,

1

Análisis de sistemas orientadoa objetos: estado del arte

Universidad de CongresoMendoza - República Argentinahttp://www.ucongreso.edu.ar

Prof. Fernando Pinciroli

Universidad de Congreso - Mendoza - Argentina - http://www.ucongreso.edu.ar

Temario

1 - Evolución del análisis de sistemas2 - El Lenguaje de Modelación Unificado3 - Procesos de modelación4 - Conclusión5 - Bibliografía

2


1 - El análisis de sistemas antes delUML

1.1 - Las metodologías tradicionales

1.2 - Fundamentos filosóficos del enfoqueorientado a objetos

1.3 - Los métodos orientados a objetos


Metodología

• Conjunto de métodos que se siguen en una investigacióncientífica o en una exposición doctrinal

• Es un enfoque particular, fundado en ciertos principiosgenerales, de orden filosófico; es un modo de comprender larealidad.

• Se puede decir que es un enfoque, una manera de interpretar larealidad o la disciplina en cuestión

3


Método

• Procedimiento que se sigue en las ciencias para hallar laverdad y enseñarla. Puede ser analítico o sintético

• Es un conjunto de técnicas, herramientas y tareas que, deacuerdo a un enfoque metodológico, se aplican para laresolución de un problema.


Clasificación de las metodologías

Metodología

Met. orientadaa procesos

Met. orientadaa objetos

Met. orientadaa datos

Método1 1..*

4


Los métodos de análisisorientado a procesos• Empleo del lenguaje natural (‘50s. y ss.)

• Descomposición funcional (Constantine, ‘60s. y ss.)

• Análisis estructurado (De Marco, Gane & Sarson, ‘70s.,‘80s.)

• Análisis esencial (McMenamin & Palmer, ‘84)

• Análisis estructurado moderno (Yourdon, ‘86)


Los métodos de análisis orientadoa datos

• Aparición de la Teoría Relacional (Codd, ‘70s.)

• Modelo Entidad/Relación (Chen, ‘70s.)

• Modelación de la Información (´70s., ´80s.)

• Desarrollo de Sistemas de Jackson (‘80s.)

5


El error de Kant: no comprender larealidad tal como ella es

Espacio y tiempo 12 categorías(color, medida, etc.)

Realidad caótica

...¡o la mente inventa la realidad!

O la realidad posee un orden...

Abstracción


El error kantiano se observa en losmétodos tradicionales

“Categorías” tradicionales:datos o procesos

Realidad caótica (al inicio del relevamiento)

Abstracción

6


La realidad según los métodosorientados a objetos

Abstracción

Realidad caótica (al inicio del relevamiento)

Se trata de captar la realidadtal cual es


La OO posee un enfoquearistotélico-tomista• En la realidad no existen datos o procesos independientes

• Santo Tomás de Aquino sostiene que el número, consideradoabstractamente, no existe fuera de nuestra mente

• Aristóteles indica que “no se pueden separar, a los objetos enmovimiento, por ejemplo,” puesto que "hay una multitud deaccidentes que son esenciales a las cosas, en tanto que cada uno deellos reside esencialmente en ellas” (Metafísica. 7ª ed. Madrid,Espasa-Calpe, 1972, p.284.)

• Para Santo Tomás, "la verdad consiste en la adecuación delentendimiento con las cosas" (Suma Teológica. I, c.16, a.3.)

7


Una suma sinérgica

¡Objetos! = características + comportamiento

¿Datos?edadrazacolor

¿Procesos?ladrarcomerdormir

¡Soy orientado a objetos!


Ventajas del empleo de un enfoqueadecuado

• Facilita el logro del éxito del análisis al permitir interpretar larealidad tal cual ella es• Permite reducir la complejidad del sistema a evaluar• Mejora la comunicación con los usuarios y con el equipo deanálisis• Permite representar las relaciones existentes entre loselementos constitutivos del sistema• Permite modelar con el mismo énfasis los datos y los procesos

8


Respaldo de los autorestradicionales

• Gane & Sarson incorporan la teoría relacional• McMenamin & Palmer no dudan en remarcar la importanciade modelar datos además de procesos• Page-Jones destaca la importancia que cobró la modelaciónde los datos además de los procesos• Yourdon combina herramientas de modelación de datos yprocesos• Jackson agrega modelación de procesos a su método demodelación de datos




”La normalización se hará probablemente más y más importanteen los próximos años, a medida que las bases de datos se vuelvan más complejas y la simplicidad se haga más vital”GANE, Chris y Sarson, Trish. Análisis Estructurado deSistemas. Buenos Aires, El Ateneo, 1988, p.118.

9




¨Los analistas deben por consiguiente usar un tema diferente,uno denominado particionado en objetos”McMENAMIN, Stephen y Palmer, John. Essential SystemsAnalysis. Englewood Cliffs, Prentice-Hall, 1984, p.57.




¨Los analistas deben por consiguiente usar un tema diferente,uno denominado particionado en objetos”McMENAMIN, Stephen y Palmer, John. Essential SystemsAnalysis. Englewood Cliffs, Prentice-Hall, 1984, p.57.

10




”Ocho años han pasado desde que escribí la primera ediciónde este libro. Durante este tiempo ha sucedido mucho en elcampo del desarrollo del software. Por ejemplo, hemos vistoel advenimiento de la edad de la modelación de la información”PAGE-JONES, Meilir. The Practical Guide to StructuredSystems Design. 2ª ed. Englewood Cliffs, Prentice-Hall,1988, p.XV




”El diseño y la programación estructurados les permitíana algunos equipos de encargados de proyectos llegar a undesastre más rápidamente que antes, al construir unabrillante solución al problema equivocado”YOURDON, Edward. Análisis Estructurado Moderno. México, Prentice-Hall Iberoamericana, 1989, p.138.

11



• Gane & Sarson incorporan la teoría relacional• McMenamin & Palmer no dudan en remarcar la importanciade modelar datos además de procesos• Page-Jones destaca la importancia que cobró la modelaciónde los datos además de los procesos• Yourdon combina herramientas de modelación de datos yprocesos• Jackson agrega modelación de procesos a su método demodelación de datos"¿Qué tal si el propósito del sistema no es hacer algo, sinomeramente ser el recipiente de una gran cantidad deinformación interesante?"YOURDON, Edward. Análisis Estructurado Moderno. México, Prentice-Hall Iberoamericana, 1989, p.261.


Evolución del análisis orientado aobjetos• En principio encontramos recomendaciones de diseño (Booch, 1986)

• Se impone la modelación orientada a las características de losobjetos (Shlaer & Mellor, 88)

• Surgen muchos métodos más, de autores provenientes de las basesde datos relacionales (Coad & Yourdon, Martin & Odell, Rumbaugh,Embley, etc., 1990 y ss.)

• Se imponen los métodos orientados al comportamiento de losobjetos (Wirfs-Brock, Jacobson, Rubin & Goldberg, 1994)

• Comienza a gestarse el UML (1994)

12


2 - El Lenguaje de ModelaciónUnificado

2.1 - El camino hacia la unificación

2.2 - Objetivos del UML

2.3 - Características del UML

2.4 - Descripción de las herramientas


El camino hacia la unificación• Grady Booch observa la necesidad deunificar criterios

• Ese mismo año, Ivar Jacobson completa el tríode “amigos”

• Ambos elaboran la versión 0.8 del Unified Method en 1995

• James Rumbaugh se une a Booch enoctubre de 1994

13


El camino hacia la unificación• Se elabora la versión 0.9 del Unified Modeling Language

• Durante 1996 se realizan sucesivas modificaciones en base aaportes de muchas otras personas (versiones 0.91 y 1.0)

• Se realiza la versión 1.1 en conjunto con otras importantesempresas, que es presentada al OMG

• El OMG adopta al UML versión 1.1 como estándar a fines de1997


Objetivos del UML• Establecer un lenguaje visual de modelación, expresivo ysencillo en su uso

• Mantener una independencia de los procesos de modelación yde los lenguajes de programación

• Establecer bases formales

• Integrar las mejores prácticas

• Imponer un estándar mundial

14


Elementos constitutivos

Herramientade modelación

Semántica

Metalenguaje

Extensión

Notación

Elemento demodelación

1..*

1..*

1..*1..*

1

1..*

0..*


Metalenguajes

• Porción de la notación (diagramas de clases) empleada en elmetamodelo

• Object Constraint Language

• Lenguaje natural

15


Object Constraint Language• Elaborado por Jos Warmer dentro del grupo de trabajo deIBM y ObjectTime que colaboró con Rational• Proviene del método Syntropy, lenguaje de modelación denegocios de la IBM Insurance Division, desarrollado por SteveCook y John Daniels• Objetivos: especificación de invariantes, descripción de pre ypost condiciones, descripción de guardias, definición de reglasde formación y de restricciones en operaciones

• Ejemplo:ExpresiónOCL ´esta oración escrita en Courier es una expresión OCL´


Arquitectura del UMLArquitectura de cuatro capas, definida a fin de cumplir con laespecificación Meta Object Facility del OMG:

• Meta-metamodelo: define el lenguaje para especificar metamodelos

• Metamodelo: define el lenguaje para especificar modelos

• Modelo: define el lenguaje para describir un dominio de información

• Objetos de usuario: define un dominio de información específico

16


Estructura del metamodelo

Elementos decomportamiento

Administracióndel Modelo

Fundación

Fundación:

Comportamiento comúnColaboracionesCasos de usoMáquinas de estado

Elementos de comportamiento:

Elementos centralesElementos auxiliaresMecanismos de extensiónTipos de datos


Metamodelo de “Clase”

Generalización

OperaciónAtributo

Clase

MétodoAsociación

Rol de la Asociación

Elemento del modeloInterfaz

**

*

* *

*

*

*

*

*

12..

17


Diagrama de Casos de Uso• Introducido formalmente por Ivar Jacobson• Aceptado por la comunidad usuaria de TOO y por muchosmetodologistas• De empleo en la etapa de relevamiento para captar losrequerimientos de los usuarios• De fácil comprensión por parte de los usuarios de los sistemas• Herramienta que precisa otras complementarias para serutilizada en procesos de modelación OO


Diagrama de Casos de Uso

incorporarlibros

realizarpréstamo

Alumno

Bibliotecario

Subsistema de biblioteca

actor

caso de uso

18


Diagrama de Casos de Usoincorporar

libros

realizarpréstamoAlumno

Bibliotecarioconsultar

libro

«usa»

«usa»

crear nuevocódigo

«extiende»


Diagrama de Casos de Uso• «extiende» (extends) se emplea para establecer unasituación excepcional o de error, que no corresponde alcamino normal del caso de uso básico

• «usa» (uses) se utiliza para extraer las parte comunes de loscasos de uso; son casos de uso abstractos

• Los casos de uso abstractos son ejecutados por actoresabstractos obtenidos de una estructura de generalización entreactores

19


Diagrama de Clases• Proviene de los diagramas de entidad-relación de Chen (‘70s)• Fueron extendidos con conceptos de AOO, como generalización yagregación (‘80s)• Incorporados por los autores orientados a las características de losobjetos• Permiten modelar la estructura estática de los sistemas• Utilizados en el UML para la construcción de los metamodelos• Aunque también fueron empleados por Booch, conservan el aspectode la notación propuesta por Rumbaugh en OMT


Diagrama de Clases

atributos

operaciones

nota

Alumno Libro

Préstamo

0..* 0..*

PersonaAutor

1..*1

rol

generalización

clase

multiplicidad

asociación

clase asociación

navegabilidad

discriminador

solicita

20


Diagrama de Clases: conceptos• Atributos:

visibilidad nombre:tipo=valor inicial

atributos derivados: /nombre

• Operaciones:

visibilidad nombre(parámetros):tipo de resultado

• Visibilidad:

existe definición a nivel público, privado o protegido

atributos

operaciones

Alumno


Diagrama de Clases: conceptos

triángulo:Polígono triángulo:Polígono

• Objetos:

• Diagrama de objetos: instancia de un diagrama de clases

21


Diagrama de Clases: conceptosavanzados

• Estereotipos: extienden la semántica de los elementos del UML

• la idea proviene de Rebecca Wirfs-Brock, que incorporó el objeto«coordinador»• Ivar Jacobson mejoró sustancialmente la idea con sus objetos de interfaz,entidad y control• Como ejemplo se pueden consultar los documentos “UML Extension forObjectory Process for Software Engineering” y “UML Extension forBusiness Modeling”

«empleado»

AdministradorAdministrador



• Clasificación múltiple: permite que un mismo objeto pertenezca a más deuna clase• Clasificación dinámica: brinda la posibilidad de que un objeto cambie declase

• estos conceptos fueron introducidos inicialmente por Odell

AlumnoPersona

Profesor

Hombre

Mujer

sexo rol

22



• Agregación: relación todo-parte

• Composición: agregación en la que las partes nacen y mueren con el todo

• todavía no existe un acuerdo definitivo con respecto a estos conceptos,pero ésta es la postura con más aceptación

Automóvil

Motor1

Conductor

Automóvil

Motor 1



• Interfaz: clase con declaración de operaciones, sin implementación y sinatributos

VentanaWindows

Ventana VentanaMac

Editor detextos

«interfaz»

VentanaWindows

Editor detextos

Ventana

23



• Asociación cualificada: consiste en indicar la necesidad de una estructura dedatos, estilo “diccionario”, en un extremo de una asociación

• En algunos casos permite reducir la multiplicidad

Nombre_archivoDirectorio Archivo



• Clase asociación: es una asociación que se modela como clase o viceversa

• Importante: por cada asociación entre los objetos de las clases ordinarias,sólo puede existir un solo objeto de la clase asociación

Factura Artículo* 1..*

Ítem_facturado

24



• Clase parametrizada: es la descripción de una clase con uno o másparámetros

Clase1

operación1(P)operación2(P)

P


Diagrama de paquetes• Permite administrar la complejidad del sistema al subdividirloen porciones de menor tamaño

• Corresponde a las categorías del método de Booch

• Se pueden aplicar a diferentes elementos de modelación, nosólo a clases

• Permite establecer las dependencias entre paquetes (que noson de carácter transitivo) a fin de reducirlas

• También permite reducir los ciclos de dependencias

25


Diagrama de paquetes

Paquete 5 Paquete 6

Paquete 2 Paquete 3 {abstracto}

Paquete 4

Paquete 7

Paquete 8

Paquete 1 {global}


Diagrama de Secuencia• Es uno de los dos diagramas de interacción que propone elUML• Describe la forma en la que colaboran entre sí los objetos parallevar a cabo sus respectivas responsabilidades• Cada diagrama representa la funcionalidad de un único caso deuso• Permite ver cómo se suceden cronológicamente los mensajesentre los objetos•Proviene de los diagramas POSA de Buschmann• Fueron utilizados por los tres autores del UML en susrespectivos métodos previos

26


Diagrama de Secuencia

objeto 1 objeto 2 objeto 3

inicio de un métodoauto-delegación

destrucción de un objeto

retornoactivación


Diagrama de Colaboración

• Es otro de los diagramas de interacción que se incluye en elUML

• No permite observar gráficamente la cronología de losmensajes

• Facilita la organización de los objetos en paquetes

• Destaca la conexión estática entre los objetos

27


Diagrama de Colaboración

:objeto 3

:objeto 2:objeto 1

1:mensaje1( )

1.1:mensaje2( )

1.2:auto-delegación1( ) 1.3:auto-delegación2( )


Diagrama de Estados• Describe los estados posibles en la vida de los objetos

• Permite observar cómo cambian de estado los objetos a medidaque ocurren los eventos

• Cada diagrama se utiliza para representar el ciclo de vida de losobjetos de una única clase

• Provienen de las cartas de estado de David Harel

• Los emplearon Rumbaugh en OMT, Booch en su libro de 1994y Jacobson con la incorporación de una vasta notación

28


Diagrama de Estados

entrada/acciónhacer/actividadsalida/acción

Estado 1 Estado 2

Estado 3Estado 5

Estado 6

Estado 4

evento/acción [guardia]


Diagrama de Actividad• No posee antecedentes claros entre las herramientas de losautores del UML en sus propios métodos• Proviene de varias técnicas, como diagramas de eventos deOdell y redes de Petri• Permite destacar y sincronizar las operaciones concurrentes yestablecer caminos alternativos• Muestra el comportamiento combinado de varias clases,aunque éstas no se identifican si no se lo hace explícitamente• Al igual que los diagramas de estado, se emplea para describircomportamientos complejos

29


Diagrama de ActividadBuscar

transporte

Entra a sutrabajo

Camb ia demarcha

Mira por elespejo

Toma untaxi

Se va ensu auto

[eligió un taxi][eligió su auto]


Diagrama de Componentes• Este diagrama, junto al de despliegue, corresponde al grupo deherramientas de implementación del UML

• Representa módulos físicos de código

• Es importante que cada componente sea equivalente a unpaquete

• De esta manera, las dependencias entre componentes con lasmismas que las existentes entre los paquetes

• La notación gráfica corresponde a los gradygramas

30


Diagrama de Componentes

Nombre 1

Nombre 2


Diagrama de Despliegue• Es la segunda herramienta de implementación del UML

• Muestra las relaciones entre los componentes de hardware ysoftware del sistema

• Permite observar dónde se encuentran físicamente los paquetesen el sistema

• La notación gráfica también proviene de Booch

31


Diagrama de Despliegue

PC

1

PC*

servidor

1

Impresora

*


Rational Rose• Herramienta de Rational Software Corporation que soportael UML

• Provee generación de código en múltiples lenguajes

• Posee ingeniería reversa y reingeniería

• Permite emplear la notación tradicional de OMT y el métodode Booch

• Es posible obtener una copia demo en el sitio web deRational, http://www.rational.com

32


Rational Rose


3 - Procesos de modelación

3.1 - Proceso orientado a las características de los objetos

3.2 - Proceso orientado al comportamiento

3.3 - Tarjetas CRC

3.4 - Rational Unified Process

33


Modelación basada en lascaracterísticas de los objetos

comportamiento de los objetos

característicasde los objetos

Modelo OO

Realidad

Diagrama declases

Diagrama deestados

Diagrama desecuencia


Modelación orientada alcomportamiento de los objetos

comportamiento de los objetos

característicasde los objetos

Modelo OO

Realidad

Diagrama decasos de uso

Diagrama declases

Diagrama deinteracción

34


Empleo de scripts en los Casos deUso

incorporarlibros

realizarpréstamo

Alumno

Bibliotecario


Descripción de los Casos de Uso

Casos de uso:

incorporar libros: el bibliotecario recibe el libro, consultasus datos, le coloca su código, actualiza su existencia y loubica en la estantería.

realizar préstamo: el alumno solicita un libro, elbibliotecario consulta el pedido, actualiza los datos delpréstamo y entrega el libro al alumno.

35


Scripts• Los scripts son oraciones estructuradas que describen elcomportamiento en base a cuatro elementos:

• el actor o iniciador• la acción que ejecuta el iniciador• el participante que responde a la acción del iniciador• la respuesta a esa acción

• Fueron creados por Kenneth Rubin para su método OBA/D acomienzos de los ‘90• Los propongo como herramienta complementaria del UML


Estructuración de los casos de usomediante scriptsUso de scripts:

el alumno solicita un libro; el bibliotecario atiende pedido

el bibliotecario realiza consulta; el fichero entrega datos

el bibliotecario conforma préstamo; el fichero acepta datos

el bibliotecario entrega el libro; el alumno recibe el libro

(actor acción; participante respuesta)

36


Tarjetas CRC

(Figura tomada del paper original: http://c2.com/doc/oopsla89/paper.html)

clase

colaboraciones

responsabilidades


Tarjetas CRC

comportamientode los objetos

características de los objetos

Modelo OO

Realidad

TarjetasCRC

Diagrama declases

Diagrama deinteracción

37


Rational Objectory Process:origen

• Proveniente de Object Factory for Software Development, fue creado en1985 por Ivar Jacobson, para el desarrollo de sistemas en Ericsson, Suecia

• Se completó en 1986, se presentó en OOPSLA’87 y se incorporó unaherramienta automatizada en 1989

• Fue adoptado por numerosas empresas, principalmente de telefonía

• Parte del método fue publicada en OOSE, la primera obra de Jacobson

• Cuando Jacobson se incorporó a Rational, Objectory fue complementado conlas ideas de Booch

• Además se integraron la herramientas que soportan a Objectory con otras deRational o adquiridas por esta última empresa


Rational Objectory Process:características generales

• Es un proceso de ingeniería de software para la producción de software dealta calidad que satisfaga las necesidades del usuario

• Es un proceso iterativo en el que el producto final se obtiene por sucesivosrefinamientos con crecimiento incremental

• Se basa en la producción y mantenimiento de modelos con un enfoqueorientado a objetos y empleo del UML

• Utiliza como herramienta principal a los casos de uso

• Soporta desarrollo basado en componentes y es aplicable a diferentes tiposde proyectos y de distinta envergadura

• Alcanza el nivel CMM de madurez 3 del Software Engineering Institute

38


Rational Objectory Process:etapas• En cada iteración, el proceso pasa por cuatro fases:• Incepción: se establecen las características del proyecto, los casos de uso, seevalúan los riesgos, se estiman los recursos y se decide la factibilidad delproyecto• Elaboración: se analiza el problema, se combaten los mayores riesgos, sedescriben los casos de uso y se establece la arquitectura del sistema• Construcción: se desarrolla iterativa e incrementalmente un producto através de las etapas de análisis, diseño, implementación y prueba, para serentregado al usuario• Transición: consiste en poner en marcha el producto final, corrigiendoerrores, realizando ajustes y se verifica el cumplimiento del plan de proyecto


Rational Objectory Process:iteraciones

Elaboration Construction TransitionInceptionPhases

Require ments Capture

Analys is & Desi gn

Impl ementat ionTest

Manag ementEnviron mentDeployment

Process Components

Supporting Components

Iterations

pre lim inar yi teration(s)

i ter.#1

iter.#2

iter.#n

iter.#n+1

i ter.#n+2

iter.#m

iter.#m+1

Organizationalong con tent

Organization along t ime

(Dibujo tomado de “Rational Objectory Process 4.1 - Your UML Process”, pág.3, http://www.rational.com)

39


Rational Objectory Process:componentes

OKOKFail

Rea lized ByImp lem en ted

ByVerif ied By

Imp lementatio nModel

Test Mode lDesig n Model

Use-C aseM od el

Mode ls

Proc es sCompon ents TestImple me n-

tat ionAna lys is &

DesignR equir ements

C apture

(Dibujo tomado de “Rational Objectory Process 4.1 - Your UML Process”, pág.5, http://www.rational.com)


Rational Unified Process(RUP)

• Proceso de modelación que permite optimizar el uso delUML, anunciado el 15 de junio de 1998

• Reúne las mejores prácticas de diversas disciplinas• administración de requerimientos• modelación de negocios• desarrollo basado en componentes• ingeniería de datos• prueba y calidad

• Rational Objectory Process pasó a ser un subconjunto deRUP

40


Consideraciones finales• En estos momentos está disponible la versión 1.3 del UML

• El OMG espera la versión 2.0 del UML conteniendo todas lasmejoras

• Existen otras alternativas que continúan desarrollándose conéxito (ej.: OML)

• También existen varios métodos que siguen evolucionando


Conclusión• El análisis de sistemas debe fundarse en tres aspectosprimordiales: un enfoque adecuado, un buen conjunto deherramientas y un método dirigido por la realidad

• El UML es un excelente medio para esta visión del análisis desistemas, además de que es estándar

• Numerosas empresas están desarrollando herramientasautomatizadas para aplicar el UML

• Las Universidades deberían realizar un esfuerzo para orientar suenseñanza en este sentido y ser impulsoras del cambio en lasociedad

41


Bibliografía sobre UML• FOWLER, Martin con Scott,Kendall. UML Distilled.Applying the StandardObject Modeling Language.Addison Wesley Longman,1997.• http://www.rational.com/uml

• Más la trilogía de libros de losautores del UML, Booch,Rumbaugh y Jacobson


Bibliografía complementaria alUML

• BOOCH, Grady. Análisis y Diseño Orientado a Objetoscon Aplicaciones. 2ª ed. Wilmington, Addison-WesleyIberoamericana, 1996

• JACOBSON, Ivar y otros. Object-Oriented SoftwareEngineering. A Use Case Driven Approach. 4ª reimpresiónrevisada. Estados Unidos de América, Addison-Wesley/ACMpress, 1994

• RUMBAUGH, James y otros. Object-Oriented Modelingand Design. Englewood Cliffs, Prentice-Hall, 1991. (Vertambién OMT-2 en http://www.rational.com)

42


Bibliografía adicional sobre OOBERARD, Edward. Be Careful With "Use Cases". The Object Agency, Inc.BOOCH, Grady. Object Solutions: Managing the Object-Oriented Project. Addison-Wesley, 1996.BOOCH, Grady y otros. The Unified Modeling Language User Guide. Addison-Wesley, 1999.COAD, Peter y Yourdon, Edward. Object-Oriented Analysis. 2ª ed. Englewood Cliffs, Prentice-Hall, 1991.EMBLEY, David y otros. Object-Oriented Systems Analysis. A Model-Driven Approach. Englewood Cliffs, Prentice-Hall, 1992.ERIKSSON, Hans-Erik y Penker, Magnus. UML Toolkit Wiley Computer Publishing, 1998.FOWLER, Martin y Scott, Kendall. UML Distilled. A brief Guide to the Standard Object Modeling Language. 2da.ed. Addison-Wesley, 1999.GAMMA, Erich y otros. Design Patterns. Reading, Addison-Wesley, 1995.GOLDBERG, Adele y Rubin, Kenneth. Succeeding with Objects: Decision Frameworks for Project Management. Addison-Wesley, 1995.GRAHAM, Ian. Métodos Orientados a Objetos. 2ª ed. Wilmington, Addison-Wesley Iberoamericana, 1996.GRAHAM, Ian. Migrating to Object Technology. Addison-Wesley, 1995.JACOBSON, Ivar. Use Case Engineering. En: A Rational Technical Class Software Development West 1996. California, Rational Software

Corporation, 27/3/1996.JACOBSON, Ivar y otros. The Object Advantage - Business Process Reengineering with Object Technology. Addison-Wesley, 1996.MARTIN, James. Principles of Object-Oriented Analysis and Design. Englewood Cliffs, Prentice-Hall, 1993.MARTIN, James y Odell, James. Análisis y Diseño Orientado a Objetos. México, Prentice-Hall, 1994.MELLOR, Stephen y Lang, Neil. Developing Shlaer-Mellor Models Using UML. California, Project Technology Inc., 1997, .MEYER, Bertrand. Object-Oriented Software Construction. Hertfordshire, Prentice-Hall, 1988.MULLER, Pierre Alain. Modelado de Objetos con UML. Barcelona, Gestión 2000, 1997.PAGE-JONES, Meilir. The Practical Guide to Structured Systems Design. 2ª ed. Englewood Cliffs, Prentice-Hall, 1988.ParcPlace. MethodWorks User's Guide. Sunnyvale, ParcPlace Systems, Inc., 1995.QUATRINI, Terry. Visual Modeling With Rational Rose and UML. Addison-Wesley, 1998.ROSENBERG, Doug y Scott, Kendall. Use Case Driven Modeling with UML. A Practical Approach. Addison-Wesley, 1999.RUBIN, Kenneth. Object Behavior Analysis and Design. Sunnyvale, ParcPlace Systems, Inc., 1994.RUMBAUGH, James. Trends in Object-Oriented Methodology. Unifying Methods. Short Talk. Santa Clara, Rational Software Corporation,

1996.SHLAER, Sally y Lang, Neil. Shlaer-Mellor Method: The OOA96 Report Version 1.0. Berkeley, Project Technology, Inc., 1996,

http://www.projtech.comSHLAER, Sally y Mellor, Stephen. Migration from Structured to OO Methodologies. Berkeley, Project Technology, Inc., 1996,

http://www.projtech.comSHLAER, Sally y Mellor, Stephen. Object Lifecycles. Modeling the World in States. Englewood Cliffs, Prentice-Hall, 1992.SHLAER, Sally y Mellor, Stephen. Object-Oriented Analysis. Modeling the World in Data. Englewood Cliffs, Prentice-Hall, 1988.TAKAHASHI, Tadao. Introduçao a Programaçao Orientada a Objetos. Curitiba, III EBAI, 1988.WIRFS-BROCK, Rebecca y otros. Designing Object-Oriented Software. Englewood Cliffs, Prentice-Hall, 1990.YOURDON, Edward. Análisis Estructurado Moderno. México, Prentice-Hall Iberoamericana, 1989.


Otra bibliografía consultada paraesta presentaciónAQUINO, Santo Tomás de. Suma Teológica.An Interview with Ivar Jacobson. Parte I. En: Object Currents. Vol. I Nº 3. New York, SIGS Publications,

Inc., marzo de 1996.An Interview with Steve Mellor. En: Object Currents. Vol.I Nº 6. New York, SIGS Publications, Inc., 1996.ARISTÓTELES. Metafísica. 7ª ed. Madrid, Espasa-Calpe, 1972.BERTALANFFY, Ludwig von. Teoría General de los Sistemas. Buenos Aires, Fondo de Cultura Económica,

1990.GAMBRA, Rafael. Historia Sencilla de la Filosofía. 12 ed. Madrid, Rialp, 1981.GANE, Chris y Sarson, Trish. Análisis Estructurado de Sistemas. Buenos Aires, El Ateneo, 1988.HAREL, David. State Charts: A Visual Formalism for Complex Systems. Science of Computer

Programming, vol 8, 1987.HATHAWAY, Bob. James Rumbaugh Interview. En: Object Currents. Vol. I, Nº 2. New York, SIGS

Publications, Inc., 1995.HEUSER, Carlos. Modelagem Conceitual de Sistemas. Buenos Aires, Kapelusz, I EBAI, 1988.MARTIN, James. Sistemas de Información. Buenos Aires, El Ateneo, 1989.McMENAMIN, Stephen y Palmer, John. Essential Systems Analysis. Englewood Cliffs, Prentice-Hall, 1984.MURDICK, Robert y Munson, John. Sistemas de Información Administrativa. México, Prentice-Hall

Hispanoamericana, 1988.PRESSMAN, Roger. Ingeniería del Software. Un enfoque práctico. 3ª ed. Madrid, McGraw-

Hill/Interamericana de España, 1993.URDANOZ, Teófilo O.P. Historia de la Filosofía. Tomo IV. Siglo XIX: Kant, idealismo y espiritualismo.

Madrid, La Editorial Católica, 1975.

43


Cómo contactarnoshttp://www.ucongreso.edu.are-mail: [email protected] [email protected]./Fax: (0261) 4230193 / 630 / 771 / 960 / 980Domicilios: Av. Mitre 617

o Colón 90(5500) Mendoza

Documents

Análisis de sistemas orientado a objetos: estado del …ucongreso.edu.ar/grado/carreras/lsi/Introduccion_al_UML1.pdfde datos relacionales (Coad & Yourdon, Martin & Odell, Rumbaugh,