Que Es La Metodologia Orientada A Objeto

METODOLOGIA
ORIENTADA A
OBJETOS
-INTRODUCCION A
UML
Universidad Privada San Juan
Bautista
Ingenieria De Computacion y
Sistemas IV Ciclo
Docente : Ing. Jhon Romero

Integrantes :
Quintanilla Garcia, Alex Alberto
Peña Toledo, Luigui Aldair
Montes Guillermo, Erick
Nuñez Huamani, Jhossimar
2015
METODOLOGIA ORIENTADA A OBJETOS -INTRODUCCION A UML
INDICE
Dedicatoria................................................................................................................................2
Introducción.............................................................................................................................3
Capítulo I...................................................................................................................................4
Metodología Orientada Objetos...........................................................................................4
1. CONCEPTOS DE LA METODOLOGÍA ORIENTADA A OBJETOS.....................4
2. Ventajas de la metodología orientada a objetos................................................7
3. Principios de la Metodología Orientada a Objetos..............................................9
Capitulo II................................................................................................................................10
UML El lenguaje unificado de diagrama o notación.....................................................10
1. Lenguaje Unificado de Modelado..........................................................................10
2. HISTORIA.....................................................................................................................11
3. VENTAJAS DE PROGRAMAR USANDO UML:....................................................13
4. DESVENTAJAS..........................................................................................................13
5. OBJETIVOS....................................................................................................................14
6. PRINCIPIOS....................................................................................................................14
6.1. Como nació UML.....................................................................................................14
6.2. Modelado.................................................................................................................14
7. DIAGRAMAS ESTRUCTURALES..............................................................................15
Capítulo III...............................................................................................................................21
Técnicas de Metodología orientada a objetos...............................................................21
1. Metodología OMT......................................................................................................21
2. Metodología BOOCH.................................................................................................22
3. Metodología RUP.......................................................................................................24
4. OOram..........................................................................................................................26
5. Método de Fusión......................................................................................................27
Conclusiones.........................................................................................................................30
Bibliografia..............................................................................................................................31
1
Dedicatoria
Dedicamos este trabajo a nuestro

Padres que nos apoyan tanto de
manera económica como emotiva
y a los diferentes agentes que
intervienen para concretar
nuestro camino profesional.
1
1
Introducción
Una metodología Orientada a objetos es un proceso para producir

software de una manera organizada, usando convenciones y técnicas
de notació n predefinidas. Desde que la comunidad de programació n
orientada a objetos tuvo la noció n de incorporar el pensamiento de que
los objetos son entidades coherentes con identidad estado y conducta,
estos objetos pueden ser organizados por sus similitudes y sus
diferencias, puestas en uso en herencia y polimorfismo, las
metodologías orientadas a objetos incorporan estos conceptos para
definir sus reglas, normas, procedimientos, guías y notaciones para
alcanzar un producto de calidad que satisfaga las necesidades del
cliente.
UML El lenguaje unificado de diagrama o notació n (UML) sirve para

especificar, visualizar y documentar esquemas de sistemas de software
orientado a objetos. UML no es un método de desarrollo, lo que
significa que no sirve para determinar qué hacer en primer lugar o
có mo diseñ ar el sistema, sino que simplemente le ayuda a visualizar el
diseñ o y a hacerlo má s accesible para otros. UML está controlado por el
grupo de administració n de objetos y es el está ndar de descripció n de
esquemas de software.
UML está diseñ ado para su uso con software orientado a objetos, y
tiene un uso limitado en otro tipo de cuestiones de programació n.
UML se compone de muchos elementos de esquematizació n que

representan las diferentes partes de un sistema de software. Los
elementos UML se utilizan para crear diagramas, que representa
alguna parte o punto de vista del sistema.
1
Capítulo I
Metodología Orientada Objetos
1. CONCEPTOS DE LA METODOLOGÍA ORIENTADA A

OBJETOS
La metodología orientada a objetos ha derivado de las metodologías
anteriores a éste. Así como los métodos de diseño estructurado realizados guían a
los desarrolladores que tratan de construir sistemas complejos utilizando
algoritmos como sus bloques fundamentales de construcción, similarmente los
métodos de diseño orientado a objetos han evolucionado para ayudar a los
desarrolladores a explotar el poder de los lenguajes de programación basados en
objetos y orientados a objetos, utilizando las clases y objetos como bloques de
construcción básicos.
Actualmente el modelo de objetos ha sido influenciado por un número de

factores no sólo de la Programación Orientada a Objetos, POO (Object Oriented
Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha
probado ser un concepto uniforme en las ciencias de la computación, aplicable no
sólo a los lenguajes de programación sino también al diseño de interfaces de
usuario, bases de datos y arquitectura de computadoras por completo. La razón de
ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la
inherente complejidad de muchos tipos de sistemas.
Se define a un objeto como "una entidad tangible que muestra alguna

conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de
la cual almacenamos datos y los métodos que controlan dichos datos".
Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En
particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o
estar en relación con otros objetos de manera apropiada a este objeto.
Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como

método de análisis de requisitos por derecho propio y como complemento de otros
métodos de análisis. En lugar de examinar un problema mediante el modelo
clásico de entrada-proceso-salida (flujo de información) o mediante un modelo
derivado exclusivamente de estructuras jerárquicas de información, el AOO
introduce varios conceptos nuevos. Estos conceptos nuevos le parecen inusuales
a mucha gente, pero son bastante naturales.
Una clase es una plantilla para objetos múltiples con características

similares. Las clases comprenden todas esas características de un conjunto
particular de objetos. Cuando se escribe un programa en lenguaje orientado a
objetos, no se definen objetos verdaderos sino se definen clases de objetos.
1
Una instancia de una clase es otro término para un objeto real. Si la clase
es la representación general de un objeto, una instancia es su representación
concreta. A menudo se utiliza indistintamente la palabra objeto o instancia para
referirse, precisamente, a un objeto.
En los lenguajes orientados a objetos, cada clase está compuesta de dos

cualidades: atributos (estado) y métodos (comportamiento o conducta). Los
atributos son las características individuales que diferencian a un objeto de otro
(ambos de la misma clase) y determinan la apariencia, estado u otras cualidades
de ese objeto. Los atributos de un objeto incluyen información sobre su estado.
Los métodos de una clase determinan el comportamiento o conducta que

requiere esa clase para que sus instancias puedan cambiar su estado interno o
cuando dichas instancias son llamadas para realizar algo por otra clase o
instancia. El comportamiento es la única manera en que las instancias pueden
hacerse algo a sí mismas o tener que hacerles algo. Los atributos se encuentran
en la parte interna mientras que los métodos se encuentran en la parte externa del
objeto .
Para definir el comportamiento de un objeto, se crean métodos, los cuales

tienen una apariencia y un comportamiento igual al de las funciones en otros
lenguajes de programación, los lenguajes estructurados, pero se definen dentro de
una clase. Los métodos no siempre afectan a un solo objeto; los objetos también
se comunican entre sí mediante el uso de métodos. Una clase u objeto puede
llamar métodos en otra clase u objeto para avisar sobre los cambios en el
ambiente o para solicitarle a ese objeto que cambie su estado.
Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del

objeto. Además, como se puede observar de los diagramas, las variables del
objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y
esconden el núcleo del objeto de otros objetos en el programa. Al
empaquetamiento de las variables de un objeto con la protección de sus métodos
se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para
esconder detalles de la puesta en práctica no importantes de otros objetos.
1
Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier

tiempo sin afectar otras partes del programa.
Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas

en una membrana protectora de métodos— es una representación ideal de un
objeto y es el ideal por el que los diseñadores de sistemas orientados a objetos
luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la
puesta en práctica, un objeto puede querer exponer algunas de sus variables o
esconder algunos de sus métodos.
El encapsulamiento de variables y métodos en un componente de software

ordenado es, todavía, una simple idea poderosa que provee dos principales
beneficios a los desarrolladores de software:
• Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como
darle mantenimiento, independientemente del código fuente de otros objetos. Así
mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado
y conducta.
• Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica"

que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede
mantener información y métodos privados que pueden ser cambiados en cualquier
tiempo sin afectar a los otros objetos que dependan de ello.
Los objetos proveen el beneficio de la modularidad y el ocultamiento de la

información. Las clases proveen el beneficio de la reutilización. Los programadores
de software utilizan la misma clase, y por lo tanto el mismo código, una y otra vez
para crear muchos objetos.
En las implantaciones orientadas a objetos se percibe un objeto como un

paquete de datos y procedimientos que se pueden llevar a cabo con estos datos.
Esto encapsula los datos y los procedimientos. La realidad es diferente: los
atributos se relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se
hace así? Los atributos son variables comunes en cada objeto de una clase y cada
uno de ellos puede tener un valor asociado, para cada variable, diferente al que
tienen para esa misma variable los demás objetos. Los métodos, por su parte,
pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un
desperdicio almacenar el mismo procedimiento varias veces y ello va contra el
principio de reutilización de código.
Otro concepto muy importante en la metodología orientada a objetos es el de

herencia. La herencia es un mecanismo poderoso con el cual se puede definir una
clase en términos de otra clase; lo que significa que cuando se escribe una clase,
sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la
herencia dará acceso automático a la información contenida en esa otra clase.
Con la herencia, todas las clases están arregladas dentro de una jerarquía
estricta. Cada clase tiene una superclase (la clase superior en la jerarquía) y
puede tener una o más subclases (las clases que se encuentran debajo de esa
1
clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases
hijas, heredan de las clases más altas, las clases padres.
Las subclases heredan todos los métodos y variables de las superclases. Es decir,
en alguna clase, si la superclase define un comportamiento que la clase hija
necesita, no se tendrá que redefinir o copiar ese código de la clase padre.
De esta manera, se puede pensar en una jerarquía de clase como la definición de

conceptos demasiado abstractos en lo alto de la jerarquía y esas ideas se
convierten en algo más concreto conforme se desciende por la cadena de la
superclase.
Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por
sus superclases; pueden agregar variables y métodos además de los que ya
heredan de sus clases padres. Las clases hijas pueden, también, sobreescribir los
métodos que heredan por implementaciones especializadas para esos métodos.
De igual manera, no hay limitación a un sólo nivel de herencia por lo que se tiene
un árbol de herencia en el que se puede heredar varios niveles hacia abajo y
mientras más niveles descienda una clase, más especializada será su conducta.
La herencia presenta los siguientes beneficios:
 Las subclases proveen conductas especializadas sobre la base de

elementos comunes provistos por la superclase. A través del uso de
herencia, los programadores pueden reutilizar el código de la superclase
muchas veces.
 Los programadores pueden implementar superclases llamadas clases
abstractas que definen conductas "genéricas". Las superclases abstractas
definen, y pueden implementar parcialmente, la conducta pero gran parte
de la clase no está definida ni implementada. Otros programadores
concluirán esos detalles con subclases especializadas.
2. Ventajas de la metodología orientada a objetos.
En síntesis, algunas ventajas que presenta son:
1
 Reutilización. Las clases están diseñadas para que se reutilicen en

muchos sistemas. Para maximizar la reutilización, las clases se construyen
de manera que se puedan adaptar a los otros sistemas. Un objetivo
fundamental de las técnicas orientadas a objetos es lograr la reutilización
masiva al construir el software.
 Estabilidad. Las clases diseñadas para una reutilización repetida se

vuelven estables, de la misma manera que los microprocesadores y otros
chips se hacen estables.
 El diseñador piensa en términos del comportamiento de objetos y no en

detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las
clases complejas sean fáciles de utilizar.
 Se construyen clases cada vez más complejas. Se construyen clases a

partir de otras clases, las cuales a su vez se integran mediante clases. Esto
permite construir componentes de software complejos, que a su vez se
convierten en bloques de construcción de software más complejo.
 Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a
partir de componentes probados, que han sido verificados y pulidos varias
veces.
 Un diseño más rápido. Las aplicaciones se crean a partir de componentes

ya existentes. Muchos de los componentes están construidos de modo que
se pueden adaptar para un diseño particular.
 Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar

con métodos específicos. Esto tiene particular importancia en los sistemas
cliente-servidor y los sistemas distribuidos, en los que usuarios
desconocidos podrían intentar el acceso al sistema.
 Mantenimiento más sencillo. El programador encargado del

mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus
funciones independientemente de las demás.
 Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una
interfaz de usuario gráfica de modo que el usuario apunte a iconos o
elementos de un menú desplegado, relacionados con los objetos. En
determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver
y apuntar es más fácil que recordar y escribir.
 Independencia del diseño. Las clases están diseñadas para ser

independientes del ambiente de plataformas, hardware y software. Utilizan
solicitudes y respuestas con formato estándar. Esto les permite ser
utilizadas en múltiples sistemas operativos, controladores de bases de
datos, controladores de red, interfaces de usuario gráficas, etc. El creador
del software no tiene que preocuparse por el ambiente o esperar a que éste
se especifique.
 Interacción. El software de varios proveedores puede funcionar como

conjunto. Un proveedor utiliza clases de otros. Existe una forma estándar
de localizar clases e interactuar con ellas. El software desarrollado de
1
manera independiente en lugares ajenos debe poder funcionar en forma

conjunta y aparecer como una sola unidad ante el usuario.
 Computación Cliente-Servidor. En los sistemas cliente-servidor, las

clases en el software cliente deben enviar solicitudes a las clases en el
software servidor y recibir respuestas. Una clase servidor puede ser
utilizada por clientes diferentes. Estos clientes sólo pueden tener acceso a
los datos del servidor a través de los métodos de la clase. Por lo tanto los
datos están protegidos contra su corrupción.
 Computación de distribución masiva. Las redes a nivel mundial utilizarán

directorios de software de objetos accesibles. El diseño orientado a objetos
es la clave para la computación de distribución masiva. Las clases de una
máquina interactúan con las de algún otro lugar sin saber donde residen
tales clases. Ellas reciben y envían mensajes orientados a objetos en
formato estándar.
 Mayor nivel de automatización de las bases de datos. Las estructuras

de datos (los objetos) en las bases de datos orientadas a objetos están
ligadas a métodos que llevan a cabo acciones automáticas. Una base de
datos OO tiene integrada una inteligencia, en forma de métodos, en tanto
que una base de datos relacional básica carece de ello.
 Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no,

pueden preservarse si se ajustan a un contenedor orientado a objetos, de
modo que la comunicación con ella sea a través de mensajes estándar
orientados a objetos.
 Mejores herramientas CASE. Las herramientas CASE (Computer Aided

Software Engineering, Ingeniería de Software Asistida por Computadora)
utilizarán las técnicas gráficas para el diseño de las clases y de la
interacción entre ellas, para el uso de los objetos existentes adaptados a
nuevas aplicaciones. Las herramientas deben facilitar el modelado en
términos de eventos, formas de activación, estados de objetos, etc. Las
herramientas OO del CASE deben generar un código tan pronto se definan
las clases y permitir al diseñador utilizar y probar los métodos recién
creados. Las herramientas se deben diseñar de manera que apoyen el
máximo de creatividad y una continua afinación del diseño durante la
construcción.
3. Principios de la Metodología Orientada a Objetos.
Existen cuatro principios básicos, estos principios son fruto de la

experiencia en todas las ramas de la ingeniería.
a) La elección de qué modelos se creen influye directamente

sobre cómo se acomete el problema. Hay que seleccionar el
modelo adecuado para cada momento y dependiendo de qué
modelo se elija se obtendrán diferentes beneficios y diferentes
costes. En la industria software se ha comprobado que un
1
modelado orientado a objetos proporciona unas arquitecturas más

flexibles y readaptables que otros por ejemplo orientados a la
funcionalidad o a los datos.
b) Todo modelo puede ser expresado a diferentes niveles de

precisión. Esto es, es necesario poder seleccionar el nivel de
detalle que se desea ya que en diferentes partes de un proyecto y
en diferentes etapas se tendrán unas determinadas necesidades.
c) Los mejores modelos están ligados a la realidad. Lo

principal es tener modelos que nos permitan representar la
realidad lo más claramente posible, pero no sólo esto, tenemos
que saber, exactamente cuándo se apartan de la realidad para no
caer en la ocultación de ningún detalle importante
d) Un único modelo no es suficiente. Cualquier sistema que no

sea trivial se afronta mejor desde pequeños modelos casi
independientes, que los podamos construir y estudiar
independientemente y que nos representen las partes más
diferenciadas del sistema y sus interrelaciones.
Capitulo II
UML El lenguaje unificado de diagrama o

notación.
1. Lenguaje Unificado de Modelado
(UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de

modelado de sistemas de software más conocido y utilizado en la actualidad;
está respaldado por el OMG (Object Management Group).
Es un lenguaje gráfico para visualizar, especificar, construir y

documentar un sistema. UML ofrece un estándar para describir un "plano" del
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de
negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
1
Es importante remarcar que UML es un "lenguaje de modelado" para

especificar o para describir métodos o procesos. Se utiliza para definir un
sistema, para detallar los artefactos en el sistema y para documentar y
construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o
proceso usar.
UML no puede compararse con la programación estructurada, pues

UML significa Lenguaje Unificado de Modelado, no es programación, solo se
diagrama la realidad de una utilización en un requerimiento. Mientras que,
programación estructurada, es una forma de programar como lo es la
orientación a objetos, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML sólo para
lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas.
2. HISTORIA
Antes de UML 1.x
Después de que la Rational Software Corporation contratara a James Rumbaugh

de General Electric en 1994, la compañía se convirtió en la fuente de los dos
esquemas de modelado orientado a objetos más populares de la época: el OMT
(Object-modeling technique) de Rumbaugh, que era mejor para análisis
orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el
diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador
del método de ingeniería de software orientado a objetos. Jacobson se unió a
Rational en 1995 después de que su compañía, Objectory AB, fuera comprada
por Rational. Los tres metodologistas eran conocidos como los Tres Amigos,
porque se sabía de sus constantes discusiones sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba

alentando la adopción de la tecnología de objetos, y para orientarse hacia un
método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje
Unificado de Modelado abierto. Se consultó con representantes de compañías
competidoras en el área de la tecnología de objetos durante la OOPSLA '96;
eligieron cajas para representar clases en lugar de la notación de Booch que
utilizaba símbolos de nubes.
1
Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue
organizado un consorcio internacional llamado UML Partners en 1996 para
completar las especificaciones del Lenguaje Unificado de Modelado (UML), y
para proponerlo como una respuesta al OMG RFP. El borrador de la
especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de
1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea
Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para
finalizar las semánticas de la especificación y para integrarla con otros esfuerzos
de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante
la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.
UML 1.x
Como notación de modelado, la influencia de la OMT domina UML (por ejemplo

el uso de rectángulos para clases y objetos). Aunque se quitó la notación de
"nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles
de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y
la notación de componentes de Booch fueron integrados al resto de la notación,
pero la integración semántica era relativamente débil en UML 1.1, y no se arregló
realmente hasta la revisión mayor de UML 2.0.
Conceptos de muchos otros métodos OO fueron integrados superficialmente en

UML con el propósito de hacerlo compatible con todos los métodos OO. Además
el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de
asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como
resultado, UML es útil en una gran variedad de problemas de ingeniería, desde
procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y
distribuidos.
El Lenguaje de Modelado Unificado es un estándar internacional:
ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido

abierto - Lenguaje de Modelado Unificado (UML) Versión 1.4.2
UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores

(UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de
UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el
OMG en 2005.
1
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las
versiones 2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de
2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado
oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como
una versión "En proceso" y todavía tiene que ser formalmente liberada.
UML es la herramienta grafica que Se utiliza para especificar métodos o procesos

realizados por el sistema, por medio de una serie de diagramas.
Nos proporciona una serie de herramientas que permiten mostrar el programa

en sus diferentes etapas o procesos, delimitarlos y organizarlos de tal forma que
sean entendibles por la persona que va a desarrollar el sistema.
Cabe destacar que UML no es un lenguaje de programación, sino el sistema que

permite modelar la estructura del programa.
Aquellas personas que nunca han programado usando uml siempre lo ven como
una pérdida de tiempo, pero deberían dedicarle por lo menos una semana a
esto, en verdad lo vale.
3. VENTAJAS DE PROGRAMAR USANDO UML:
 Mejores tiempos totales de desarrollo (de 50 % o más).

 Modelar sistemas (y no sólo de software) utilizando conceptos orientados
a objetos.
 Establecer conceptos y artefactos ejecutables.
 Encaminar el desarrollo del escalamiento en sistemas complejos de
misión crítica.
 Crear un lenguaje de modelado utilizado tanto por humanos como por
máquinas.
 Mejor soporte a la planeación y al control de proyectos.
 Alta reutilización y minimización de costos.
 Fácil actualización o modificado del software a programar
4. DESVENTAJAS
 UML no es un método de desarrollo.

 UML al no ser un método de desarrollo es independiente del ciclo de
desarrollo
 UML no se presta con facilidad al diseño de sistemas distribuidos.
1
5. OBJETIVOS
- El método debía ser capaz de modelar no sólo sistemas de software sino otro
tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la
orientación a objetos (OO).
- Crear un lenguaje para modelado utilizable a la vez por máquinas y por

personas.
- Establecer un acoplamiento explícito de los conceptos y los artefactos

ejecutables.
- Manejar los problemas típicos de los sistemas complejos de misión crítica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican
siguiendo los métodos más utilizados sigan evolucionando en conjunto y no
por separado. Y además, unificar las perspectivas entre diferentes tipos de
sistemas (no sólo software, sino también en el ámbito de los negocios), al
aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la
implementación y los conceptos internos de la OO.
6. PRINCIPIOS
6.1. Como nació UML.
Durante los ochenta y principios de los noventa Grady Booch, James
Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de
notaciones para el análisis y diseño de sistemas orientados a objetos.
Los tres llegaron por separado a obtener bastante
reconocimiento.Booch había escrito "Object-Oriented Analysis and
Design with Applications " un libro de referencia en el análisis y diseño
orientado a objetos desarrollando su propia notación.Por su parte
James Rumbaugh había desarrollado su propia notación de diseño
orientado a objetos llamada OMT (Object Modeling Technique) en su
libro "Object-Oriented Modeling and Design ".Por otro lado Jacobson se
había revelado como un visionario del análisis (padre de los casos de
uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo
el mundo en "Object-Oriented Software Engineering: A Use Case Driven
Approach ".A mediados de los noventa empezaron a intercambiar
documentos y trabajar en conjunto produciendo grandes avances en el
modelado de sistemas orientados a objetos.En 1994 Rational contrató a
Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se
unía a ellos en Rational.En 1997 salió a la luz la versión 1.0 de UML.
6.2. Modelado.
El Lenguaje de Modelado Unificado UML."El Lenguaje de Modelado
1
Unificado UML es un lenguaje estándar para escribir planos de

software. UML puede utilizarse para visualizar, especificar, construir y
documentar los artefactos de un sistema que involucra gran cantidad de
software"El UML es el Lenguaje de Modelado Unificado Orientado a
Objetos, UML no es un método porque no tiene noción de proceso el
cual es una parte importante de un método. Ahora bien si UML no es
método; entonces ¿Cuáles son las etapas a seguir en el desarrollo de
sistemas con UML?, varios especialistas en desarrollo de sistemas de
información arguyen de que existe la necesidad de adoptar un Proceso
de Desarrollo de sistemas para enmarcar las fases importantes que
sigue el UML, por ello los desarrolladores de proyectos de sistemas de
información emplean el Procesos Unificado para dar soluciones
adecuadas a las necesidades de los clientes.El desarrollo de sistemas
con UML siguiendo el proceso unificado incluye actividades específicas,
cada una de ellas a su vez contienen otras subactividades las cuales
sirven como una guía de cómo deben ser las actividades desarrolladas
y secuenciadas con el fin de obtener sistemas exitosos;
consecuentemente el desarrollo de los sistemas puede variar de
desarrollador en desarrollador, de proyecto en proyecto, de empresa en
empresa adoptando siempre un Proceso de Desarrollo.
7. DIAGRAMAS ESTRUCTURALES.
 Diagrama de clases.- un diagrama de clases en Lenguaje
Unificado de Modelado (UML) es un tipo de diagrama de estructura
estática que describe la estructura de un sistema mostrando las clases
del sistema, sus atributos, operaciones (o métodos), y las relaciones
entre los objetos.
1
 Diagrama de componentes.- Un diagrama de componentes

representa cómo un sistema de software es dividido en componentes y
muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas
compartidas, módulos, ejecutables, o paquetes. Los diagramas de
Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier
arquitectura de sistema.Debido a que los diagramas de componentes
son más parecidos a los diagramas de casos de usos, éstos son
utilizados para modelar la vista estática y dinámica de un sistema.
Muestra la organización y las dependencias entre un conjunto de
componentes. No es necesario que un diagrama incluya todos los
componentes del sistema, normalmente se realizan por partes. Cada
diagrama describe un apartado del sistema.
1
 Diagrama de estructura compuesta.- es un tipo de

diagrama en el Lenguaje de Modelado Unificado (UML), que muestra la
estructura interna de unaclase y las colaboraciones que esta estructura
hace posibles. Esto puede incluir partes internas, puertas mediante las
cuales, las partes interactúan con cada una de las otras o mediante las
cuales, instancias de la clase interactúan con las partes y con el mundo
exterior, yconectores entre partes o puertas. Una estructura
compuesta es un conjunto de elementos interconectados que colaboran
en tiempo de ejecución para lograr algún propósito. Cada elemento tiene
algún rol definido en la colaboración.
 Diagrama de paquetes.- Muestra cómo un sistema está

dividido en agrupaciones lógicas mostrando las dependencias entre
esas agrupaciones .Dado que normalmente un paquete está pensado
como un directorio, los diagramas de paquetes suministran una
1
descomposición de la jerarquía lógica de un sistema. Los Paquetes

están normalmente organizados para maximizar la coherencia interna
dentro de cada paquete y minimizar el acoplamiento externo entre los
paquetes. Con estas líneas maestras sobre la mesa, los paquetes son
buenos elementos de gestión. Cada paquete puede asignarse a un
individuo o a un equipo, y las dependencias entre ellos pueden indicar el
orden de desarrollo requerido.
 Diagrama de despliegue.- Diagrama de Despliegue es un tipo

de diagrama del Lenguaje Unificado de Modelado que muestran las
relaciones físicas de los distintos nodos que componen un sistema y el
reparto de los componentes sobre dichos nodos.
Los diagramas de despliegue son los complementos de los diagramas
de componentes que, unidos, proveen la vista de implementación del
sistema. Describen la topología del sistema la estructura de los
elementos de hardware y el software que ejecuta cada uno de ellos.Los
diagramas de despliegue representan a los nodos y sus relaciones. Los
1
nodos son conectados por asociaciones de comunicación tales como

enlaces de red, conexiones TCP/IP.
Diagrama de objetos.- diagrama que muestra una vista completa o

parcial de los objetos de un sistema en un instante de ejecución específico.
Un diagrama de objetos es un gráfico de instancias, incluyendo objetos y
datos. Un diagrama de objetos es una instancia de un diagrama de clases;
muestra una 'foto' del estado de un sistema en un punto de tiempo
determinado Los diagramas de objeto están ligados a los diagramas de
clase y comparten virtualmente los mismos símbolos para la notación. Los
diagramas de objetos pertenecen a la categoría de diagramas estructurales
en UML.
1
1
Capítulo III
Técnicas de Metodología orientada a objetos

1. Metodología OMT
Object Modeling Technique (OMT):
Es importante el modelo y uso del mismo para lograr una abstracción, en el cual
el análisis está enfocado en el mundo real para un nivel de diseño, también pone
detalles particulares para modelado de recursos de la computadora. Esta
metodología puede ser aplicada en varios aspectos de implementación incluyendo
archivos, base de datos relacionales, base de datos orientados a objetos. OMT
está construido alrededor de descripciones de estructura de datos, constantes,
sistemas para procesos de transacciones.OMT pone énfasis en especificaciones
declarativas de la información, para capturar los requerimientos, especificaciones
imperativas para poder descender prematuramente en el diseño, declaraciones
que permiten optimizar los estados, además provee un soporte declarativo para
una directa implementación deDBMS
Data Base Manager System
Los puntos más importantes para esta metodología son los siguientes:
Poner énfasis en el análisis y no en el desarrollo.
Poner énfasis en los datos más que en las funciones, lo que proporciona
estabilidad al proceso de desarrollo.
Utilizar una notación común en todas las fases a través de tres modelos que
capturan los aspectos estáticos, dinámicos y funcionales que combinados proveen
una descripción completa del software. La Metodología OMT divide el proceso de
desarrollo en tres partes aisladas: análisis, diseño e implantación.
Análisis:
Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se
expresa en términos de objetos y de relaciones entre ellos, flujo dinámico de
control y las transformaciones funcionales.

Diseño:
Es la estrategia de alto nivel para resolver el problema y cómo construir una
solución. Se define la arquitectura del sistema y se toman las decisiones
estratégicas.

Implementación:
En esta fase se convierte finalmente el diseño de objetos en código. A su vez,
cada una de estas fases se divide en su tareas, como son: modelos de objetos,
dinámico y funcional; análisis y del sistema, y objetos del sistema.

Modelo de Objetos:
En esta primera parte del análisis se forma una primera imagen del modelo de
clases del sistema con sus atributos y lasrelaciones entre ellas, usando para ello
un diagrama entidad relación modificada en el que además de las clases y sus
relaciones se pueden representar también los métodos.

1
Modelo Dinámico:
El modelo dinámico usa un grafo para representar el comportamiento dinámico de
cada clase, es decir, el comportamiento de estas ante cada evento que se
produce en el sistema. Un evento desencadenará en un cambio de estado en la
clase que se traducirá en una modificación de los atributos o relaciones de ésta.

Modelo Funcional:
Muestra que es lo que el sistema ha de hacer mediante un diagrama de flujo de
datos, sin entrar en la secuencia temporal en la que los procesos se ejecutan. El
modelo funcional puede revelar nuevos objetos y métodos que se pueden
incorporar en los dos modelos anteriores. Por eso se dice que el método OMT es
iterativo.

Diseño del Sistema:
Se centra en la parte física del sistema como la descomposición de éste en
subsistemas, el tipo de entorno en el que se va a ejecutar, el manejo de recursos
y el almacenamiento de datos.

Diseño de los objetos:
Determina que operaciones van a realizar los métodos y profundiza incluso los
algoritmos que va a usar. Se escogen los distintos tipos de representación de
datos y se subdivide en módulos que pasarán a formar parte de la
implementación.
2. Metodología BOOCH
La metodología Booch (OOD), es una metodología de propósito general en la

que se parte de que cada etapa no es un proceso aislado si no que ha de
Interactuar con sus siguientes y precedentes en una especie de bucle del que
se sale cuando se esté satisfecho con el modelo conseguido. En un principio se
tienen una serie de objetos y clases que forman el sistema, a continuación se
construye el modelo de interfaz y se examinan las relaciones entre las clases lo
que, a su vez, genera la adición de nuevos interfaces que generarán nuevas
relaciones iterándose hasta llegar al estado de refinamiento deseado. El
método Booch proporciona un conjunto de herramientas gráficas y notaciones
que ayudan representar visualmente los modelos definidos en las fases de
análisis y diseño.
Algunas de ellas son:
1
Diagramas de clase:
Es una variación de los diagramas de entidad relación en los que se

añaden nuevos tipos de relaciones como la herencia, instanciación y
uso. Además permite agrupar las clases y relaciones en categorías para
diagramas demasiado complejos.
El gráfico correspondiente a una clase en la notación de Booch es una
especie de nube a trazos en cuyo interior se escribe el nombre de la
misma, separado por una linea de sus atributos (estado) y métodos
(comportamiento). Cada clase lleva asociado un nombre que en general
debe ser único. No se especifican todos los métodos y atributos
siempre, sino solamente aquellos que son relevantes para la parte del
diseño que tratamos de describir.
Diagramas de objetos:
En este tipo de gráfico de muestran los objetos y sus relaciones de

forma dinámica mostrando la forma en la que los objetos se pasan
mensajes entre ellos. Así mismo, en esto diagramas es posible
representarla visibilidad de los objetos siendo ésta la que determina que
objetos se pueden comunicar con otros.
Diagramas temporales:
Muestran la secuencia temporal de creación y destrucción de objetos.

Suelen ir acompañados de pseudocódigo en el que se explica el flujo de
mensajes de control entre los objetos del sistema.
Diagramas de transición de estados:
Permiten definir como las instancias de las clases pasan de un estado a

otro a causa de ciertos eventos y que acciones se desencadenan de
esos cambios de estado.
El Diagrama de Transición de Estado (también conocido como DTE)

enfatiza el comportamiento dependiente del tiempo del sistema. Este
tipo de modelo sólo importaba para una categoría de sistemas conocido
como sistemas de tiempo-real; como ejemplo de estos sistemas se
tienen el control de procesos, sistemas de conmutación telefónica,
sistemas de captura de datos de alta velocidad y sistemas de control y
mando militares.
Elementos
Entidades: Las entidades pasan por varios estados. En cada uno de
ellos pueden suceder determinados eventos que provoquen efectos o
acciones sobre la entidad.
Eventos: Algo que sucede en el mundo real y como consecuencia se

ejecuta un proceso.
Acciones: Descripción del estado de un evento sobre una entidad
Definición de DTE.
1
Un diagrama de transición de estados describe un conjunto de

transiciones que pueden suceder sobre una entidad. El estado en que
se encuentra una entidad es el resultado de todas las transiciones
sucedidas durante su vida.
Diagramas de módulo y proceso:
En Booch, en la fase de implementación, es posible representar

mediante estos gráficos la parte física del sistema, es decir, podemos
mostrar cómo se van a almacenar internamente las clases y objetos,
relaciones entre módulos en tiempo de compilación, procesos,
dispositivos y las comunicaciones entre ellos.
El diagrama de módulos muestra la asignación de clases y objetos o
módulos en el diseño físico de un sistema. Un solo diagrama de
módulos representa una vista de la estructura de módulos de un
sistema. Los dos elementos esenciales de un diagrama de módulos son
los módulos y sus dependencias.
Programa principal: Identifica al archivo que contiene la raíz del

programa.
Especificación y cuerpo: Identifican los archivos que contienen la
declaración y la definición de los objetos o bien procedimientos o
funciones necesarias para el correcto funcionamiento de la aplicación.
3. Metodología RUP
Rational Unified Process (RUP)
1
Proceso Unificado de Desarrollo es el resultado de tres décadas de desarrollo y

uso práctico. Es un conjunto de actividades necesarias para transformar los
requisitos de un usuario en un sistema de software. Más que un simple proceso
de trabajo, es un marco de trabajo genérico que puede especializarse para una
gran variedad de dominios. Rational Unified Process (RUP), es la metodología
estándar de la industria para la construcción completa del ciclo de ingeniería de
software, tanto para sistemas tradicionales como para sistemas web. Esta
metodología permite mayor productividad en equipo y la realización de mejores
prácticas de software a través de plantillas y herramientas que guían en todas
las actividades de desarrollo crítico del software. RUP unifica las disciplinas en
lo que a desarrollo de software se refiere, incluyendo modelado de negocio,
El manejo de requerimientos, componentes de desarrollo, ingeniería de datos,
manejo y configuración de cambios, y pruebas, cubriendo todo el ciclo de vida
de los proyectos basado en la construcción de componentes y maximizando el
uso del UML (Unified Modeling Language). El software en construcción está
formado por componentes interconectados a través de interfaces. Los puntos
principales en los que se basa RUP son los siguientes:
Casos de Uso:
Los casos de uso representan los requisitos funcionales de la aplicación a ser
desarrollada; en otras palabras, qué es lo que debe hacer el sistema.
Arquitectura del producto:

El concepto de arquitectura de software incluye los aspectos estáticos y
dinámicos más significativos del sistema. Hay que tomar en cuenta que tanto la
arquitectura como los casos de uso deben ser generados en paralelo, pues los
casos de uso deben encajar en la arquitectura, así como la arquitectura debe
permitir que los casos de uso se lleven a cabo.
Ciclo de vida Iterativo Incremental:

El ciclo de vida Iterativo Incremental, consiste en dividir el trabajo en partes
más pequeñas o mini proyectos. Cada mini proyecto es una iteración que
resulta en un incremento. Las iteraciones hacen referencias a pasos en el flujo
de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad
máxima,
Las iteraciones deben estar controladas; esto es, deben seleccionarse y
ejecutarse desuna forma planificada. El RUP se sostiene en los tres puntos
básicos anteriores. Para hacer que funcionen, se necesitan un proceso
polifacético, que tenga en cuenta ciclos, fases, flujos de trabajo, gestión del
riesgo, control de calidad, gestión del proyecto y control de la configuración. El
RUP ha establecido un Framework que integra todas esas diferentes facetas.
1
PROCESO UNIFICADO
Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es

un marco de desarrollo de software que se caracteriza por estar dirigido por
casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El
refinamiento más conocido y documentado del Proceso Unificado es el Proceso
Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo

extensible que puede ser adaptado a organizaciones o proyectos específicos.
De la misma forma, el Proceso Unificado de Rational, también es un marco de
trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del Proceso Unificado o del
RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que

incluye aquellos elementos que son comunes a la mayoría de los refinamientos
existentes.
4. OOram
1
OOram (Object-Oriented Role Analysis and Modeling) Es un método de

análisis y diseño basado en la metáfora de la orientación a objetos pero que
introduce El concepto de modelo de roles como principal mecanismo de
abstracción que utilizará el modelador. El modelado con roles fue ideado para
modelar grandes sistemas y con el propósito de favorecer una implementación
en lenguajes de programación orientada a objetos. Para ello el sistema se
descompone en un conjunto de subsistemas o áreas de interés que
representan actividades desempeñadas por una estructura de objetos que
colaboran entre sí. Cada una de estas estructuras es descrita Mediante un
modelo de roles.Un modelo de roles describe los objetos que participan en una
actividad y las interacciones entre ellos; contiene un conjunto de roles, de modo
que todos los objetos que ocupan una misma posición en la estructura son
representados por un rol. un rol describe el comportamiento de un objeto en el
contexto de una actividad. la figura 1 muestra el modelo de roles compras
proyecto que describe la actividad asociada a una solicitud de compra por un
miembro de un proyecto desarrollado en una organización. El modelo se
representa mediante una vista colaboración y una vista escenario, que son las
más utilizadas del conjunto de vistas que ofrece Ooram.Modelo de roles de la
vista escenario se deduce fácilmente la secuencia de acciones que incluye la
actividad. Si dos roles están conectados mediante una línea, significa que
existe una interacción entre ellos. si en el extremo de una línea aparece un
puerto, significa que un objeto que juegue el rol asociado enviará mensajes a
un objeto que juegue el rol del otro extremo de la línea. el envío de un mensaje
provoca la ejecución de una operación o método sobre el objeto del rol que lo
recibe. un puerto representado con un doble círculo denota que la interacción
puede ser con un conjunto de objetos. Ooram también incluye la vista
diagrama de estados, que describe los estados de un rol y las transiciones
entre ellos; la vista proceso (basada en el estándar idef0 muestra
explícitamente las acciones que realizan los roles y los flujos de información
que intercambian, y la vista semántica, isomorfa a la vista colaboración del
mismo modelo, pero que en vez de puertos y caminos de interacción entre
roles, muestra relaciones de asociación. el concepto de rol unifica los
conceptos clase y objeto: los roles tienen tanto una naturaleza estática como
dinámica, pues permiten describir las propiedades de los objetos que
representan, y también pueden usarse para mostrar cómo los objetos
colaboran entre sí. al igual que un objeto, un rol tiene identidad: puede enviar y
recibir mensajes. La extensión de un rol es el conjunto de objetos que pueden
representar ese papel; de forma paralela, la extensión de un modelo de roles
es el conjunto de estructuras de objetos obtenido una vez que hacemos jugar
sus roles a los objetos del sistema; durante una instanciación, un rol puede ser
jugado por un objeto como máximo. Una clase describe un objeto
independientemente del contexto en que dicho objeto interacciona con otros;
un rol describe un objeto en el contexto de una actividad. Los roles son
independientes de las clases, permiten un modelado que pospone la elección
de las clases que implementan los objetos y de las relaciones entre ellas. un rol
puede ser implementado por una o más clases y una clase puede implementar
uno o más roles.
5. Método de Fusión
Fusión proporciona un método de desarrollo de software orientado al objeto,
que abarca desde la definición de requisitos a la implementación en un
lenguaje de programación.
1
Es considerada como una metodología de segunda generación, porque

proviene de:
OMT: modelo de objetos,

CRC: interacción de objetos,
BOOCH: visibilidad,
Los métodos Formales: pre- y post- condiciones.
Proporciona un proceso de desarrollo, que se divide en:
Análisis, Diseño e Implementación.
Ofrece notaciones para los modelos, que describen varios aspectos del
software.
Actualmente ha abandonado su notación.
Proporciona herramientas de gestión.
Análisis
El análisis se basa más en describir lo que hace un sistema en lugar de cómo
lo hace. Para esto, hay que ver el sistema desde la perspectiva del usuario en
lugar de desde la de la máquina. El análisis casa con el dominio del problema y
se preocupa por el comportamiento visible externamente.
La meta de la fase de análisis es capturar tantos requisitos del sistema como
sea posible. Se producen los siguientes modelos del sistema:
 Modelo de objetos
 Modelo de la interfaz
 Modelo del funcionamiento,
 Modelo del ciclo de vida.
Estos modelos describen:

 Clases de objetos que existen en el sistema.
 Relaciones entre esas clases.
 Operaciones que pueden realizarse en el sistema.
 Secuencias permitidas de estas operaciones.
 La entrada para la fase de análisis es un documento de definición de
requisitos en lenguaje natural.
1
Modelo de objetos
La finalidad del modelo de objetos en Fusión es: capturar los conceptos que
existen en el dominio del problema y las relaciones entre ellos, mostrar clases y
sus relaciones, (no mostrar objetos)
El modelo de objetos representa: la estructura estática de la información en el
sistema, las clases y relaciones entre ellas
Especifica el orden en el que deben hacerse las cosas dentro de cada fase.
También proporciona criterios de cuándo pasar a la siguiente fase.
En la fase del análisis de Fusión, sólo los atributos de una clase son
considerados. Los métodos son considerados en la fase de diseño. Por
consiguiente, en la fase del análisis, los objetos son similares a las entidades
en el tradicional modelo entidad relación. Atributos de clases, agregación,
especialización/generalización.
1
Conclusiones
La metodología orientada a objetos permite la optimización de los elementos

generados gracias a que mediante técnicas de herencia, atributos estáticos entre otros
permiten, que los elementos sean genéricos de manera que sea reutilizable.
Las metodologías orientado a objetos es algo totalmente distinto a la programación

estructurada y se tiene que romper cualquier esquema y enseñanza previa si
deseamos incursionar en lenguajes y documentación orientada a objetos
Gracias a UML se puede estudiar las distintas partes que conforman al sistema y
cómo interactúan estas. Reflejando las interfaces, protocolos e intercambio de
señales. Para tal fin nos podemos apoyar de los diagramas de clases, estructura
compuesta y comunicación.
El lenguaje de Modelado UML cumple con varios requerimientos para elaborar un

sistema orientado a objetos, ya que cuenta con una notación estándar y notaciones
semánticas que son esenciales para elaborar este tipo de software.
1
Bibliografía
 http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html
 http://profesores.fi-b.unam.mx/carlos/aydoo/toc.html
 http://login.osirislms.com/offline/uml/
 http://es.slideshare.net/Waleskita/metodologia-uml-presentation
 -ERIKSSON, Hans-Erik and PENKER, Magnus
 -"UML Toolkit"
 -Wiley Computer Publishing
o Analisis Orientado a Objetos
o Ing Soft –UML
 3-Tipos diagramas uml.pdf
 3a- Inroduccion a UML
o Diagramas uml.ppt
 5-UML
 6-Basicos-uml
 7-Analisis-Diseño SI
 www.wikipedia.com
 www.deslishare.com/uml.html
 www.buenastareas.com
 www.monografias.com
 http://es.slideshare.net/yolandacando1/metodologa-orientadas-a-objetos
 http://metodologia-de-booch.blogspot.pe/

Que Es La Metodologia Orientada A Objeto

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Que Es La Metodologia Orientada A Objeto

Cargado por

Copyright:

Formatos disponibles

METODOLOGIA

Docente : Ing. Jhon Romero

Peña Toledo, Luigui Aldair

Montes Guillermo, Erick

Nuñez Huamani, Jhossimar

Dedicamos este trabajo a nuestro

Una metodología Orientada a objetos es un proceso para producir

UML El lenguaje unificado de diagrama o notació n (UML) sirve para

UML se compone de muchos elementos de esquematizació n que

Metodología Orientada Objetos

1. CONCEPTOS DE LA METODOLOGÍA ORIENTADA A

Actualmente el modelo de objetos ha sido influenciado por un número de

Se define a un objeto como "una entidad tangible que muestra alguna

Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como

Una clase es una plantilla para objetos múltiples con características

En los lenguajes orientados a objetos, cada clase está compuesta de dos

Los métodos de una clase determinan el comportamiento o conducta que

Para definir el comportamiento de un objeto, se crean métodos, los cuales

Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del

Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier

Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas

El encapsulamiento de variables y métodos en un componente de software

• Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica"

Los objetos proveen el beneficio de la modularidad y el ocultamiento de la

En las implantaciones orientadas a objetos se percibe un objeto como un

Otro concepto muy importante en la metodología orientada a objetos es el de

De esta manera, se puede pensar en una jerarquía de clase como la definición de

La herencia presenta los siguientes beneficios:

 Las subclases proveen conductas especializadas sobre la base de

2. Ventajas de la metodología orientada a objetos.

En síntesis, algunas ventajas que presenta son:

 Reutilización. Las clases están diseñadas para que se reutilicen en

 Estabilidad. Las clases diseñadas para una reutilización repetida se

 El diseñador piensa en términos del comportamiento de objetos y no en

 Se construyen clases cada vez más complejas. Se construyen clases a

 Un diseño más rápido. Las aplicaciones se crean a partir de componentes

 Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar

 Mantenimiento más sencillo. El programador encargado del

 Independencia del diseño. Las clases están diseñadas para ser

 Interacción. El software de varios proveedores puede funcionar como

manera independiente en lugares ajenos debe poder funcionar en forma

 Computación Cliente-Servidor. En los sistemas cliente-servidor, las

 Computación de distribución masiva. Las redes a nivel mundial utilizarán

 Mayor nivel de automatización de las bases de datos. Las estructuras

 Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no,

 Mejores herramientas CASE. Las herramientas CASE (Computer Aided

3. Principios de la Metodología Orientada a Objetos.

Existen cuatro principios básicos, estos principios son fruto de la

a) La elección de qué modelos se creen influye directamente

modelado orientado a objetos proporciona unas arquitecturas más

b) Todo modelo puede ser expresado a diferentes niveles de

c) Los mejores modelos están ligados a la realidad. Lo

d) Un único modelo no es suficiente. Cualquier sistema que no

UML El lenguaje unificado de diagrama o

(UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de

Es un lenguaje gráfico para visualizar, especificar, construir y

Es importante remarcar que UML es un "lenguaje de modelado" para

UML no puede compararse con la programación estructurada, pues

Antes de UML 1.x

Después de que la Rational Software Corporation contratara a James Rumbaugh

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo

Conceptos de muchos otros métodos OO fueron integrados superficialmente en