Introducción al estándar mundial para el análisis de sistemas orientado a objetos

Introducción al estándar mundial para el análisis de sistemas orientado a objetos

Universidad de Congreso

Mendoza - República Argentina

http://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 sistemas

2 - El Lenguaje de Modelación Unificado

3 - Procesos de modelación

4 - Conclusión

5 - Bibliografía


1 - El análisis de sistemas antes del UML

1.1 - Las metodologías tradicionales

1.2 - Fundamentos filosóficos del enfoque orientado a objetos

1.3 - Los métodos orientados a objetos


Metodología

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

• Es un enfoque particular, fundado en ciertos principios generales, de orden filosófico; es un modo de comprender la realidad.

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


Método

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

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


Clasificación de las metodologías

Metodología

Met. orientadaa procesos

Met. orientadaa objetos

Met. orientadaa datos

Método1 1..*


Los métodos de análisis orientado 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 orientado a 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.)


El error de Kant: no comprender la realidad 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 los métodos tradicionales

“Categorías” tradicionales:datos o procesos

Realidad caótica (al inicio del relevamiento)

Abstracción


La realidad según los métodos orientados a objetos

Abstracción

Realidad caótica (al inicio del relevamiento)

Se trata de captar la realidadtal cual es


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

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

• Aristóteles indica que “no se pueden separar, a los objetos en movimiento, por ejemplo,” puesto que "hay una multitud de accidentes que son esenciales a las cosas, en tanto que cada uno de ellos 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 del entendimiento con las cosas" (Suma Teológica. I, c.16, a.3.)


Una suma sinérgica

¡Objetos! = características + comportamiento

¿Datos?edadrazacolor

¿Procesos?ladrarcomerdormir

¡Soy orientado

a objetos!


Ventajas del empleo de un enfoque adecuado

• Facilita el logro del éxito del análisis al permitir interpretar la realidad tal cual ella es

• Permite reducir la complejidad del sistema a evaluar

• Mejora la comunicación con los usuarios y con el equipo de análisis

• Permite representar las relaciones existentes entre los elementos constitutivos del sistema

• Permite modelar con el mismo énfasis los datos y los procesos


Respaldo de los autores tradicionales

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

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

”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

¨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."¿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.

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


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

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

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

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

• Comienza a gestarse el UML (1994)


2 - El Lenguaje de Modelación Unificado

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 de unificar criterios

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

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

• James Rumbaugh se une a Booch en octubre de 1994


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 a aportes de muchas otras personas (versiones 0.91 y 1.0)

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

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


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

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

• Establecer bases formales

• Integrar las mejores prácticas

• Imponer un estándar mundial


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 el metamodelo

• Object Constraint Language

• Lenguaje natural


Object Constraint Language• Elaborado por Jos Warmer dentro del grupo de trabajo de IBM y ObjectTime que colaboró con Rational• Proviene del método Syntropy, lenguaje de modelación de negocios de la IBM Insurance Division, desarrollado por Steve Cook y John Daniels• Objetivos: especificación de invariantes, descripción de pre y post condiciones, descripción de guardias, definición de reglas de 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 la especificació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


Estructura del metamodelo

Elementos de comportamiento

Administración del 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..


Diagrama de Casos de Uso• Introducido formalmente por Ivar Jacobson

• Aceptado por la comunidad usuaria de TOO y por muchos metodologistas

• De empleo en la etapa de relevamiento para captar los requerimientos de los usuarios

• De fácil comprensión por parte de los usuarios de los sistemas

• Herramienta que precisa otras complementarias para ser utilizada en procesos de modelación OO


Diagrama de Casos de Uso

incorporarlibros

realizarpréstamo

Alumno

Bibliotecario

Subsistema de biblioteca

actor

caso de uso


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 una situación excepcional o de error, que no corresponde al camino normal del caso de uso básico

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

• Los casos de uso abstractos son ejecutados por actores abstractos obtenidos de una estructura de generalización entre actores


Diagrama de Clases• Proviene de los diagramas de entidad-relación de Chen (‘70s)

• Fueron extendidos con conceptos de AOO, como generalización y agregación (‘80s)

• Incorporados por los autores orientados a las características de los objetos

• 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 aspecto de 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


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


Diagrama de Clases: conceptos avanzados

• 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 for Objectory Process for Software Engineering” y “UML Extension for Business Modeling”

«empleado»

AdministradorAdministrador



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

• estos conceptos fueron introducidos inicialmente por Odell

AlumnoPersona

Profesor

Hombre

Mujer

sexo rol



• 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

Motor

1

Conductor

Automóvil

Motor 1



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

Ventana Windows

VentanaVentana

Mac

Editor de textos

«interfaz»

Ventana Windows

Editor de textos

Ventana



• Asociación cualificada: consiste en indicar la necesidad de una estructura de datos, 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



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

Clase1

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

P


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

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

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

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

• También permite reducir los ciclos de dependencias


Diagrama de paquetes

Paquete 5 Paquete 6

Paquete 2Paquete 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 el UML

• Describe la forma en la que colaboran entre sí los objetos para llevar a cabo sus respectivas responsabilidades

• Cada diagrama representa la funcionalidad de un único caso de uso

• Permite ver cómo se suceden cronológicamente los mensajes entre los objetos

•Proviene de los diagramas POSA de Buschmann

• Fueron utilizados por los tres autores del UML en sus respectivos métodos previos


Diagrama de Secuencia

objeto 1 objeto 2 objeto 3

inicio de un método

auto-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 el UML

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

• Facilita la organización de los objetos en paquetes

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


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 medida que ocurren los eventos

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

• Provienen de las cartas de estado de David Harel

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


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 los autores del UML en sus propios métodos

• Proviene de varias técnicas, como diagramas de eventos de Odell y redes de Petri

• Permite destacar y sincronizar las operaciones concurrentes y establecer 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 describir comportamientos complejos


Diagrama de ActividadBuscar

transporte

Entra a sutrabajo

Cambia 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 de herramientas de implementación del UML

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

• Es importante que cada componente sea equivalente a un paquete

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

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


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 y software del sistema

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

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


Diagrama de Despliegue

PC

1

PC

*

servidor

1

Impresora

*


Rational Rose• Herramienta de Rational Software Corporation que soporta el 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étodo de Booch

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


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


Modelación basada en las características de los objetos

comportamiento de los objetos

característicasde los objetos

Modelo OO

Realidad

Diagrama declases

Diagrama deestados

Diagrama desecuencia


Modelación orientada al comportamiento de los objetos

comportamiento de los objetos

característicasde los objetos

Modelo OO

Realidad

Diagrama decasos de uso

Diagrama declases

Diagrama deinteracción


Empleo de scripts en los Casos de Uso

incorporarlibros

realizarpréstamo

Alumno

Bibliotecario


Descripción de los Casos de Uso

Casos de uso:

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

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


Scripts

• Los scripts son oraciones estructuradas que describen el comportamiento 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 a comienzos de los ‘90• Los propongo como herramienta complementaria del UML


Estructuración de los casos de uso mediante 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)


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


Rational Objectory Process:origen

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

• Se completó en 1986, se presentó en OOPSLA’87 y se incorporó una herramienta 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 con las ideas de Booch

• Además se integraron la herramientas que soportan a Objectory con otras de Rational 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 de alta calidad que satisfaga las necesidades del usuario

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

• Se basa en la producción y mantenimiento de modelos con un enfoque orientado 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 tipos de proyectos y de distinta envergadura

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


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, se evalúan los riesgos, se estiman los recursos y se decide la factibilidad del proyecto

• Elaboración: se analiza el problema, se combaten los mayores riesgos, se describen los casos de uso y se establece la arquitectura del sistema

• Construcción: se desarrolla iterativa e incrementalmente un producto a través de las etapas de análisis, diseño, implementación y prueba, para ser entregado al usuario

• Transición: consiste en poner en marcha el producto final, corrigiendo errores, realizando ajustes y se verifica el cumplimiento del plan de proyecto


Rational Objectory Process:iteraciones

Elaboration Construction TransitionInception

Phases

Requirements Capture

Analysis & Design

ImplementationTest

ManagementEnvironmentDeployment

Process Components

Supporting Components

Iterations

preliminaryiteration(s)

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Organizationalong content

Organization along time

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


Rational Objectory Process:componentes

OK

OK

Fail

Realized By

ImplementedBy

Verified By

ImplementationModel

Test ModelDesign Model

Use-CaseModel

Models

ProcessComponents Test

Implemen-tation

Analysis &Design

RequirementsCapture

(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 del UML, 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 de RUP


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 las mejoras

• 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 aspectos primordiales: un enfoque adecuado, un buen conjunto de herramientas y un método dirigido por la realidad

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

• Numerosas empresas están desarrollando herramientas automatizadas para aplicar el UML

• Las Universidades deberían realizar un esfuerzo para orientar su enseñanza en este sentido y ser impulsoras del cambio en la sociedad


Bibliografía sobre UML• FOWLER, Martin con Scott, Kendall. UML Distilled. Applying the Standard Object Modeling Language.Addison Wesley Longman, 1997.

• http://www.rational.com/uml

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


Bibliografía complementaria al UML

• BOOCH, Grady. Análisis y Diseño Orientado a Objetos con Aplicaciones. 2ª ed. Wilmington, Addison-Wesley Iberoamericana, 1996

• JACOBSON, Ivar y otros. Object-Oriented Software Engineering. A Use Case Driven Approach. 4ª reimpresión revisada. Estados Unidos de América, Addison-Wesley/ACM press, 1994

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


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 para esta 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.


Cómo contactarnos

http://www.ucongreso.edu.ar

e-mail: [email protected]

[email protected]

Tel./Fax: (0261) 4230193 / 630 / 771 / 960 / 980

Domicilios: Av. Mitre 617

o Colón 90

(5500) Mendoza


¡Muchas gracias!

¡Gracias San Juan!

¡Hasta la próxima!

Documents

Introducción al estándar mundial para el análisis de sistemas orientado a objetos