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
Pea Toledo, Luigui Aldair
Montes Guillermo, Erick
Nuez Huamani, Jhossimar
2015
METODOLOGIA ORIENTADA A OBJETOS -INTRODUCCION A UML
INDICE
Dedicatoria...................................................................................................... 2
Introduccin.................................................................................................... 3
Captulo I......................................................................................................... 4
Metodologa Orientada Objetos........................................................................4
1. CONCEPTOS DE LA METODOLOGA ORIENTADA A OBJETOS.................4
2. Ventajas de la metodologa orientada a objetos.......................................7
3. Principios de la Metodologa Orientada a Objetos....................................9
Capitulo II...................................................................................................... 10
UML El lenguaje unificado de diagrama o notacin..........................................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
Captulo III..................................................................................................... 21
Tcnicas de Metodologa orientada a objetos..................................................21
1. Metodologa OMT................................................................................. 21
2. Metodologa BOOCH............................................................................ 22
3. Metodologa RUP................................................................................. 24
4. OOram................................................................................................. 26
5. Mtodo de Fusin................................................................................. 27
Conclusiones................................................................................................ 30
Bibliografia.................................................................................................... 31
1
Dedicatoria
Dedicamos este trabajo a

nuestro Padres que nos
apoyan tanto de manera
econmica como emotiva y
a los diferentes agentes
que intervienen para
concretar nuestro camino
profesional.
1
1
Introduccin
Una metodologa Orientada a objetos es un proceso para

producir software de una manera organizada, usando
convenciones y tcnicas de notacin predefinidas. Desde
que la comunidad de programacin orientada a objetos
tuvo la nocin 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 metodologas orientadas a objetos
incorporan estos conceptos para definir sus reglas, normas,
procedimientos, guas y notaciones para alcanzar un
producto de calidad que satisfaga las necesidades del
cliente.
UML El lenguaje unificado de diagrama o notacin (UML)

sirve para especificar, visualizar y documentar esquemas
de sistemas de software orientado a objetos. UML no es un
mtodo de desarrollo, lo que significa que no sirve para
determinar qu hacer en primer lugar o cmo disear el
sistema, sino que simplemente le ayuda a visualizar el
diseo y a hacerlo ms accesible para otros. UML est
controlado por el grupo de administracin de objetos y es
el estndar de descripcin de esquemas de software.
UML est diseado para su uso con software orientado a

objetos, y tiene un uso limitado en otro tipo de cuestiones
de programacin.
UML se compone de muchos elementos de esquematizacin

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
Captulo I
Metodologa Orientada Objetos
1. CONCEPTOS DE LA METODOLOGA ORIENTADA A

OBJETOS
La metodologa orientada a objetos ha derivado de las metodologas
anteriores a ste. As como los mtodos de diseo estructurado realizados guan a
los desarrolladores que tratan de construir sistemas complejos utilizando
algoritmos como sus bloques fundamentales de construccin, similarmente los
mtodos de diseo orientado a objetos han evolucionado para ayudar a los
desarrolladores a explotar el poder de los lenguajes de programacin basados en
objetos y orientados a objetos, utilizando las clases y objetos como bloques de
construccin bsicos.
Actualmente el modelo de objetos ha sido influenciado por un nmero de

factores no slo de la Programacin Orientada a Objetos, POO (Object Oriented
Programming, OOP por sus siglas en ingls). Adems, el modelo de objetos ha
probado ser un concepto uniforme en las ciencias de la computacin, aplicable no
slo a los lenguajes de programacin sino tambin al diseo de interfaces de
usuario, bases de datos y arquitectura de computadoras por completo. La razn de
ello es, simplemente, que una orientacin 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 mtodos 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 relacin con otros objetos de manera apropiada a este objeto.
Actualmente, el Anlisis Orientado a Objetos (AOO) va progresando como

mtodo de anlisis de requisitos por derecho propio y como complemento de otros
mtodos de anlisis. En lugar de examinar un problema mediante el modelo
clsico de entrada-proceso-salida (flujo de informacin) o mediante un modelo
derivado exclusivamente de estructuras jerrquicas de informacin, 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 mltiples con caractersticas

similares. Las clases comprenden todas esas caractersticas 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 trmino para un objeto real. Si la clase
es la representacin general de un objeto, una instancia es su representacin
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 mtodos (comportamiento o conducta). Los
atributos son las caractersticas 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 informacin sobre su estado.
Los mtodos 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 mtodos se encuentran en la parte externa del
objeto .
Para definir el comportamiento de un objeto, se crean mtodos, los cuales

tienen una apariencia y un comportamiento igual al de las funciones en otros
lenguajes de programacin, los lenguajes estructurados, pero se definen dentro de
una clase. Los mtodos no siempre afectan a un solo objeto; los objetos tambin
se comunican entre s mediante el uso de mtodos. Una clase u objeto puede
llamar mtodos 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. Adems, como se puede observar de los diagramas, las variables del
objeto se localizan en el centro o ncleo del objeto. Los mtodos rodean y
esconden el ncleo del objeto de otros objetos en el programa. Al
empaquetamiento de las variables de un objeto con la proteccin de sus mtodos
se le llama encapsulamiento. Tpicamente, el encapsulamiento es utilizado para
esconder detalles de la puesta en prctica no importantes de otros objetos.
1
Entonces, los detalles de la puesta en prctica pueden cambiar en cualquier

tiempo sin afectar otras partes del programa.
Esta imagen conceptual de un objeto un ncleo de variables empaquetadas

en una membrana protectora de mtodos es una representacin ideal de un
objeto y es el ideal por el que los diseadores de sistemas orientados a objetos
luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la
puesta en prctica, un objeto puede querer exponer algunas de sus variables o
esconder algunos de sus mtodos.
El encapsulamiento de variables y mtodos en un componente de software

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

que otros objetos pueden utilizar para comunicarse con l. Pero el objeto puede
mantener informacin y mtodos 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

informacin. Las clases proveen el beneficio de la reutilizacin. Los programadores
de software utilizan la misma clase, y por lo tanto el mismo cdigo, 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 mtodos 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 dems objetos. Los mtodos, por su parte,
pertenecen a la clase y no se almacenan en cada objeto, puesto que sera un
desperdicio almacenar el mismo procedimiento varias veces y ello va contra el
principio de reutilizacin de cdigo.
Otro concepto muy importante en la metodologa orientada a objetos es el de

herencia. La herencia es un mecanismo poderoso con el cual se puede definir una
clase en trminos de otra clase; lo que significa que cuando se escribe una clase,
slo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la
herencia dar acceso automtico a la informacin contenida en esa otra clase.
Con la herencia, todas las clases estn arregladas dentro de una jerarqua
estricta. Cada clase tiene una superclase (la clase superior en la jerarqua) y
puede tener una o ms subclases (las clases que se encuentran debajo de esa
1
clase en la jerarqua). Se dice que las clases inferiores en la jerarqua, las clases
hijas, heredan de las clases ms altas, las clases padres.
Las subclases heredan todos los mtodos 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 cdigo de la clase padre.
De esta manera, se puede pensar en una jerarqua de clase como la definicin de

conceptos demasiado abstractos en lo alto de la jerarqua y esas ideas se
convierten en algo ms concreto conforme se desciende por la cadena de la
superclase.
Sin embargo, las clases hijas no estn limitadas al estado y conducta provistos por
sus superclases; pueden agregar variables y mtodos adems de los que ya
heredan de sus clases padres. Las clases hijas pueden, tambin, sobreescribir los
mtodos que heredan por implementaciones especializadas para esos mtodos.
De igual manera, no hay limitacin a un slo nivel de herencia por lo que se tiene
un rbol de herencia en el que se puede heredar varios niveles hacia abajo y
mientras ms niveles descienda una clase, ms 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 travs del uso de
herencia, los programadores pueden reutilizar el cdigo de la superclase
muchas veces.
Los programadores pueden implementar superclases llamadas clases

abstractas que definen conductas "genricas". Las superclases abstractas
definen, y pueden implementar parcialmente, la conducta pero gran parte
de la clase no est definida ni implementada. Otros programadores
concluirn esos detalles con subclases especializadas.
1
2. Ventajas de la metodologa orientada a objetos.
En sntesis, algunas ventajas que presenta son:
Reutilizacin. Las clases estn diseadas para que se reutilicen en

muchos sistemas. Para maximizar la reutilizacin, las clases se construyen
de manera que se puedan adaptar a los otros sistemas. Un objetivo
fundamental de las tcnicas orientadas a objetos es lograr la reutilizacin
masiva al construir el software.
Estabilidad. Las clases diseadas para una reutilizacin repetida se

vuelven estables, de la misma manera que los microprocesadores y otros
chips se hacen estables.
El diseador piensa en trminos del comportamiento de objetos y no en

detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las
clases complejas sean fciles de utilizar.
Se construyen clases cada vez ms 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 construccin de software ms complejo.
Calidad. Los diseos suelen tener mayor calidad, puesto que se integran a
partir de componentes probados, que han sido verificados y pulidos varias
veces.
Un diseo ms rpido. Las aplicaciones se crean a partir de componentes

ya existentes. Muchos de los componentes estn construidos de modo que
se pueden adaptar para un diseo particular.
Integridad. Las estructuras de datos (los objetos) slo se pueden utilizar

con mtodos especficos. Esto tiene particular importancia en los sistemas
cliente-servidor y los sistemas distribuidos, en los que usuarios
desconocidos podran intentar el acceso al sistema.
Mantenimiento ms sencillo. El programador encargado del

mantenimiento cambia un mtodo de clase a la vez. Cada clase efecta
sus funciones independientemente de las dems.
Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una
interfaz de usuario grfica 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 ms fcil que recordar y escribir.
Independencia del diseo. Las clases estn diseadas para ser

independientes del ambiente de plataformas, hardware y software. Utilizan
solicitudes y respuestas con formato estndar. Esto les permite ser
utilizadas en mltiples sistemas operativos, controladores de bases de
datos, controladores de red, interfaces de usuario grficas, etc. El creador
1
del software no tiene que preocuparse por el ambiente o esperar a que ste
se especifique.
Interaccin. El software de varios proveedores puede funcionar como

conjunto. Un proveedor utiliza clases de otros. Existe una forma estndar
de localizar clases e interactuar con ellas. El software desarrollado de
manera independiente en lugares ajenos debe poder funcionar en forma
conjunta y aparecer como una sola unidad ante el usuario.
Computacin 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 slo pueden tener acceso a
los datos del servidor a travs de los mtodos de la clase. Por lo tanto los
datos estn protegidos contra su corrupcin.
Computacin de distribucin masiva. Las redes a nivel mundial utilizarn

directorios de software de objetos accesibles. El diseo orientado a objetos
es la clave para la computacin de distribucin masiva. Las clases de una
mquina interactan con las de algn otro lugar sin saber donde residen
tales clases. Ellas reciben y envan mensajes orientados a objetos en
formato estndar.
Mayor nivel de automatizacin de las bases de datos. Las estructuras

de datos (los objetos) en las bases de datos orientadas a objetos estn
ligadas a mtodos que llevan a cabo acciones automticas. Una base de
datos OO tiene integrada una inteligencia, en forma de mtodos, en tanto
que una base de datos relacional bsica carece de ello.
Migracin. 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 comunicacin con ella sea a travs de mensajes estndar
orientados a objetos.
Mejores herramientas CASE. Las herramientas CASE (Computer Aided

Software Engineering, Ingeniera de Software Asistida por Computadora)
utilizarn las tcnicas grficas para el diseo de las clases y de la
interaccin entre ellas, para el uso de los objetos existentes adaptados a
nuevas aplicaciones. Las herramientas deben facilitar el modelado en
trminos de eventos, formas de activacin, estados de objetos, etc. Las
herramientas OO del CASE deben generar un cdigo tan pronto se definan
las clases y permitir al diseador utilizar y probar los mtodos recin
creados. Las herramientas se deben disear de manera que apoyen el
mximo de creatividad y una continua afinacin del diseo durante la
construccin.
3. Principios de la Metodologa Orientada a Objetos.
Existen cuatro principios bsicos, estos principios son fruto de la

experiencia en todas las ramas de la ingeniera.
1
a) La eleccin de qu modelos se creen influye directamente

sobre cmo se acomete el problema. Hay que seleccionar el
modelo adecuado para cada momento y dependiendo de qu
modelo se elija se obtendrn diferentes beneficios y diferentes
costes. En la industria software se ha comprobado que un
modelado orientado a objetos proporciona unas arquitecturas ms
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

precisin. 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 tendrn unas determinadas necesidades.
c) Los mejores modelos estn ligados a la realidad. Lo

principal es tener modelos que nos permitan representar la
realidad lo ms claramente posible, pero no slo esto, tenemos
que saber, exactamente cundo se apartan de la realidad para no
caer en la ocultacin de ningn detalle importante
d) Un nico modelo no es suficiente. Cualquier sistema que no

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

notacin.
1. Lenguaje Unificado de Modelado
(UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de

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

documentar un sistema. UML ofrece un estndar para describir un "plano" del
1
sistema (modelo), incluyendo aspectos conceptuales tales como procesos de

negocio, funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programacin, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para

especificar o para describir mtodos 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 metodologa de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o
proceso usar.
UML no puede compararse con la programacin estructurada, pues

UML significa Lenguaje Unificado de Modelado, no es programacin, solo se
diagrama la realidad de una utilizacin en un requerimiento. Mientras que,
programacin estructurada, es una forma de programar como lo es la
orientacin a objetos, la programacin orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML slo 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

Despus de que la Rational Software Corporation contratara a
James Rumbaugh de General Electric en 1994, la compaa se
convirti en la fuente de los dos esquemas de modelado
orientado a objetos ms populares de la poca: el OMT (Object-
modeling technique) de Rumbaugh, que era mejor para anlisis
orientado a objetos, y el Mtodo Booch de Grady Booch, que era
mejor para el diseo orientado a objetos. Poco despus se les
uni Ivar Jacobson, el creador del mtodo de ingeniera de
software orientado a objetos. Jacobson se uni a Rational en
1995 despus de que su compaa, Objectory AB, fuera
comprada por Rational. Los tres metodologistas eran conocidos
como los Tres Amigos, porque se saba de sus constantes
discusiones sobre las prcticas metodolgicas.
En 1996 Rational concluy que la abundancia de lenguajes de

modelado estaba alentando la adopcin de la tecnologa de
objetos, y para orientarse hacia un mtodo unificado, encargaron
a los Tres Amigos que desarrollaran un Lenguaje Unificado de
1
Modelado abierto. Se consult con representantes de compaas

competidoras en el rea de la tecnologa de objetos durante la
OOPSLA '96; eligieron cajas para representar clases en lugar de
la notacin de Booch que utilizaba smbolos de nubes.
Bajo la direccin tcnica 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 especificacin 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 Semntica, encabezada por Cris Kobryn y administrada por
Ed Eykholt, para finalizar las semnticas de la especificacin y
para integrarla con otros esfuerzos de estandarizacin. 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 notacin de modelado, la influencia de la OMT domina UML
(por ejemplo el uso de rectngulos para clases y objetos).
Aunque se quit la notacin de "nubes" de Booch, si se adopt la
capacidad de Booch para especificar detalles de diseo en los
niveles inferiores. La notacin de Casos de Uso del Objectory y la
notacin de componentes de Booch fueron integrados al resto de
la notacin, pero la integracin semntica era relativamente
dbil en UML 1.1, y no se arregl realmente hasta la revisin
mayor de UML 2.0.
Conceptos de muchos otros mtodos OO fueron integrados

superficialmente en UML con el propsito de hacerlo compatible
con todos los mtodos OO. Adems el grupo tom en cuenta
muchos otros mtodos 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 ingeniera, desde procesos sencillos y aplicaciones de un slo
usuario a sistemas concurrentes y distribuidos.
El Lenguaje de Modelado Unificado es un estndar internacional:
1
ISO / IEC 19501:2005 Tecnologa de la informacin -

Procesamiento distribuido abierto - Lenguaje de Modelado
Unificado (UML) Versin 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 versin de UML. A estas le ha seguido la
revisin mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificacin

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 versin "En proceso" y todava tiene que ser
formalmente liberada.
UML es la herramienta grafica que Se utiliza para especificar

mtodos 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 programacin, sino

el sistema que permite modelar la estructura del programa.
Aquellas personas que nunca han programado usando uml

siempre lo ven como una prdida de tiempo, pero deberan
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 ms).
Modelar sistemas (y no slo de software) utilizando conceptos orientados

a objetos.
Establecer conceptos y artefactos ejecutables.
1
Encaminar el desarrollo del escalamiento en sistemas complejos de

misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por

mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.
Fcil actualizacin o modificado del software a programar
4. DESVENTAJAS
UML no es un mtodo de desarrollo.
UML al no ser un mtodo de desarrollo es independiente del ciclo de

desarrollo
UML no se presta con facilidad al diseo de sistemas distribuidos.
5. OBJETIVOS
- El mtodo deba ser capaz de modelar no slo sistemas de software sino otro
tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la
orientacin a objetos (OO).
- Crear un lenguaje para modelado utilizable a la vez por mquinas y por

personas.
- Establecer un acoplamiento explcito de los conceptos y los artefactos

ejecutables.
- Manejar los problemas tpicos de los sistemas complejos de misin crtica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican
siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no
por separado. Y adems, unificar las perspectivas entre diferentes tipos de
sistemas (no slo software, sino tambin en el mbito de los negocios), al
aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo, la
implementacin y los conceptos internos de la OO.
1
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 anlisis y diseo de sistemas orientados a objetos.
Los tres llegaron por separado a obtener bastante
reconocimiento.Booch haba escrito "Object-Oriented Analysis and
Design with Applications " un libro de referencia en el anlisis y diseo
orientado a objetos desarrollando su propia notacin.Por su parte
James Rumbaugh haba desarrollado su propia notacin de diseo
orientado a objetos llamada OMT (Object Modeling Technique) en su
libro "Object-Oriented Modeling and Design ".Por otro lado Jacobson se
haba revelado como un visionario del anlisis (padre de los casos de
uso) y sobre todo del diseo 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 ao despus Jacobson se
una a ellos en Rational.En 1997 sali a la luz la versin 1.0 de UML.
6.2. Modelado.
El Lenguaje de Modelado Unificado UML."El Lenguaje de Modelado

Unificado UML es un lenguaje estndar 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 mtodo porque no tiene nocin de proceso el cual es una parte
importante de un mtodo. Ahora bien si UML no es mtodo; entonces
Cules son las etapas a seguir en el desarrollo de sistemas con UML?,
varios especialistas en desarrollo de sistemas de informacin 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 informacin
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 especficas, cada una
de ellas a su vez contienen otras subactividades las cuales sirven como
una gua de cmo 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.
1
7. DIAGRAMAS ESTRUCTURALES.
Diagrama de clases.- un diagrama de clases en Lenguaje
Unificado de Modelado (UML) es un tipo de diagrama de estructura
esttica que describe la estructura de un sistema mostrando las clases
del sistema, sus atributos, operaciones (o mtodos), y las relaciones
entre los objetos.
Diagrama de componentes.- Un diagrama de componentes

representa cmo un sistema de software es dividido en componentes y
muestra las dependencias entre estos componentes. Los componentes
fsicos incluyen archivos, cabeceras, bibliotecas
compartidas, mdulos, 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 ms parecidos a los diagramas de casos de usos, stos son
utilizados para modelar la vista esttica y dinmica de un sistema.
Muestra la organizacin 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 interactan con cada una de las otras o mediante las
cuales, instancias de la clase interactan 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 ejecucin para lograr algn propsito. Cada elemento tiene
algn rol definido en la colaboracin.
1
Diagrama de paquetes.- Muestra cmo un sistema est

dividido en agrupaciones lgicas mostrando las dependencias entre
esas agrupaciones .Dado que normalmente un paquete est pensado
como un directorio, los diagramas de paquetes suministran una
descomposicin de la jerarqua lgica de un sistema. Los Paquetes
estn normalmente organizados para maximizar la coherencia interna
dentro de cada paquete y minimizar el acoplamiento externo entre los
paquetes. Con estas lneas maestras sobre la mesa, los paquetes son
buenos elementos de gestin. Cada paquete puede asignarse a un
individuo o a un equipo, y las dependencias entre ellos pueden indicar el
orden de desarrollo requerido.
1
Diagrama de despliegue.- Diagrama de Despliegue es un tipo

de diagrama del Lenguaje Unificado de Modelado que muestran las
relaciones fsicas 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 implementacin del
sistema. Describen la topologa 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
nodos son conectados por asociaciones de comunicacin tales como
enlaces de red, conexiones TCP/IP.
1
Diagrama de objetos.- diagrama que muestra una vista completa o

parcial de los objetos de un sistema en un instante de ejecucin especfico.
Un diagrama de objetos es un grfico 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 estn ligados a los diagramas de
clase y comparten virtualmente los mismos smbolos para la notacin. Los
diagramas de objetos pertenecen a la categora de diagramas estructurales
en UML.
1
1
Captulo III
Tcnicas de Metodologa orientada a objetos

1. Metodologa OMT
Object Modeling Technique (OMT):
Es importante el modelo y uso del mismo para lograr una abstraccin, en el cual
el anlisis est enfocado en el mundo real para un nivel de diseo, tambin pone
detalles particulares para modelado de recursos de la computadora. Esta
metodologa puede ser aplicada en varios aspectos de implementacin 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 informacin, para capturar los requerimientos, especificaciones
imperativas para poder descender prematuramente en el diseo, declaraciones
que permiten optimizar los estados, adems provee un soporte declarativo para
una directa implementacin deDBMS
Data Base Manager System
Los puntos ms importantes para esta metodologa son los siguientes:

Poner nfasis en el anlisis y no en el desarrollo.
Poner nfasis en los datos ms que en las funciones, lo que proporciona
estabilidad al proceso de desarrollo.
Utilizar una notacin comn en todas las fases a travs de tres modelos que
capturan los aspectos estticos, dinmicos y funcionales que combinados proveen
una descripcin completa del software. La Metodologa OMT divide el proceso de
desarrollo en tres partes aisladas: anlisis, diseo e implantacin.
Anlisis:
Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se
expresa en trminos de objetos y de relaciones entre ellos, flujo dinmico de
control y las transformaciones funcionales.
Diseo:
Es la estrategia de alto nivel para resolver el problema y cmo construir una
solucin. Se define la arquitectura del sistema y se toman las decisiones
estratgicas.
Implementacin:
En esta fase se convierte finalmente el diseo de objetos en cdigo. A su vez,
cada una de estas fases se divide en su tareas, como son: modelos de objetos,
dinmico y funcional; anlisis y del sistema, y objetos del sistema.
Modelo de Objetos:
En esta primera parte del anlisis se forma una primera imagen del modelo de
clases del sistema con sus atributos y lasrelaciones entre ellas, usando para ello
un diagrama entidad relacin modificada en el que adems de las clases y sus
relaciones se pueden representar tambin los mtodos.
1
Modelo Dinmico:
El modelo dinmico usa un grafo para representar el comportamiento dinmico 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 modificacin 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 mtodos que se pueden
incorporar en los dos modelos anteriores. Por eso se dice que el mtodo OMT es
iterativo.
Diseo del Sistema:

Se centra en la parte fsica del sistema como la descomposicin de ste en
subsistemas, el tipo de entorno en el que se va a ejecutar, el manejo de recursos y
el almacenamiento de datos.
Diseo de los objetos:

Determina que operaciones van a realizar los mtodos y profundiza incluso los
algoritmos que va a usar. Se escogen los distintos tipos de representacin de
datos y se subdivide en mdulos que pasarn a formar parte de la
implementacin.
2. Metodologa BOOCH
La metodologa Booch (OOD), es una metodologa de propsito 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 continuacin se
construye el modelo de interfaz y se examinan las relaciones entre las clases lo
que, a su vez, genera la adicin de nuevos interfaces que generarn nuevas
relaciones iterndose hasta llegar al estado de refinamiento deseado. El
mtodo Booch proporciona un conjunto de herramientas grficas y notaciones
que ayudan representar visualmente los modelos definidos en las fases de
anlisis y diseo.
Algunas de ellas son:
1
Diagramas de clase:
Es una variacin de los diagramas de entidad relacin en los que se

aaden nuevos tipos de relaciones como la herencia, instanciacin y
uso. Adems permite agrupar las clases y relaciones en categoras para
diagramas demasiado complejos.
El grfico correspondiente a una clase en la notacin 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 mtodos
(comportamiento). Cada clase lleva asociado un nombre que en general
debe ser nico. No se especifican todos los mtodos y atributos
siempre, sino solamente aquellos que son relevantes para la parte del
diseo que tratamos de describir.
Diagramas de objetos:
En este tipo de grfico de muestran los objetos y sus relaciones de

forma dinmica 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 creacin y destruccin de objetos.

Suelen ir acompaados de pseudocdigo en el que se explica el flujo de
mensajes de control entre los objetos del sistema.
Diagramas de transicin 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 Transicin de Estado (tambin conocido como DTE)

enfatiza el comportamiento dependiente del tiempo del sistema. Este
tipo de modelo slo importaba para una categora de sistemas conocido
como sistemas de tiempo-real; como ejemplo de estos sistemas se
tienen el control de procesos, sistemas de conmutacin telefnica,
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: Descripcin del estado de un evento sobre una entidad
Definicin de DTE.
1
Un diagrama de transicin 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 mdulo y proceso:
En Booch, en la fase de implementacin, es posible representar

mediante estos grficos la parte fsica del sistema, es decir, podemos
mostrar cmo se van a almacenar internamente las clases y objetos,
relaciones entre mdulos en tiempo de compilacin, procesos,
dispositivos y las comunicaciones entre ellos.
El diagrama de mdulos muestra la asignacin de clases y objetos o
mdulos en el diseo fsico de un sistema. Un solo diagrama de
mdulos representa una vista de la estructura de mdulos de un
sistema. Los dos elementos esenciales de un diagrama de mdulos son
los mdulos y sus dependencias.
Programa principal: Identifica al archivo que contiene la raz del

programa.
Especificacin y cuerpo: Identifican los archivos que contienen la
declaracin y la definicin de los objetos o bien procedimientos o
funciones necesarias para el correcto funcionamiento de la aplicacin.
3. Metodologa RUP
Rational Unified Process (RUP)
1
Proceso Unificado de Desarrollo es el resultado de tres dcadas de desarrollo y

uso prctico. Es un conjunto de actividades necesarias para transformar los
requisitos de un usuario en un sistema de software. Ms que un simple proceso
de trabajo, es un marco de trabajo genrico que puede especializarse para una
gran variedad de dominios. Rational Unified Process (RUP), es la metodologa
estndar de la industria para la construccin completa del ciclo de ingeniera de
software, tanto para sistemas tradicionales como para sistemas web. Esta
metodologa permite mayor productividad en equipo y la realizacin de mejores
prcticas de software a travs de plantillas y herramientas que guan en todas
las actividades de desarrollo crtico 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, ingeniera de datos,
manejo y configuracin de cambios, y pruebas, cubriendo todo el ciclo de vida
de los proyectos basado en la construccin de componentes y maximizando el
uso del UML (Unified Modeling Language). El software en construccin est
formado por componentes interconectados a travs 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 aplicacin 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 estticos y
dinmicos ms 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
ms pequeas o mini proyectos. Cada mini proyecto es una iteracin 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
mxima,
Las iteraciones deben estar controladas; esto es, deben seleccionarse y
ejecutarse desuna forma planificada. El RUP se sostiene en los tres puntos
bsicos anteriores. Para hacer que funcionen, se necesitan un proceso
polifactico, que tenga en cuenta ciclos, fases, flujos de trabajo, gestin del
riesgo, control de calidad, gestin del proyecto y control de la configuracin. 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 ms 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 especficos.
De la misma forma, el Proceso Unificado de Rational, tambin 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 genrico que

incluye aquellos elementos que son comunes a la mayora de los refinamientos
existentes.
1
4. OOram
OOram (Object-Oriented Role Analysis and Modeling) Es un mtodo de

anlisis y diseo basado en la metfora de la orientacin a objetos pero que
introduce El concepto de modelo de roles como principal mecanismo de
abstraccin que utilizar el modelador. El modelado con roles fue ideado para
modelar grandes sistemas y con el propsito de favorecer una implementacin
en lenguajes de programacin orientada a objetos. Para ello el sistema se
descompone en un conjunto de subsistemas o reas de inters que
representan actividades desempeadas 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 posicin 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 organizacin. El modelo se
representa mediante una vista colaboracin y una vista escenario, que son las
ms utilizadas del conjunto de vistas que ofrece Ooram.Modelo de roles de la
vista escenario se deduce fcilmente la secuencia de acciones que incluye la
actividad. Si dos roles estn conectados mediante una lnea, significa que
existe una interaccin entre ellos. si en el extremo de una lnea 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 lnea. el envo de un mensaje
provoca la ejecucin de una operacin o mtodo sobre el objeto del rol que lo
recibe. un puerto representado con un doble crculo denota que la interaccin
puede ser con un conjunto de objetos. Ooram tambin incluye la vista
diagrama de estados, que describe los estados de un rol y las transiciones
entre ellos; la vista proceso (basada en el estndar idef0 muestra
explcitamente las acciones que realizan los roles y los flujos de informacin
que intercambian, y la vista semntica, isomorfa a la vista colaboracin del
mismo modelo, pero que en vez de puertos y caminos de interaccin entre
roles, muestra relaciones de asociacin. el concepto de rol unifica los
conceptos clase y objeto: los roles tienen tanto una naturaleza esttica como
dinmica, pues permiten describir las propiedades de los objetos que
representan, y tambin pueden usarse para mostrar cmo los objetos
colaboran entre s. al igual que un objeto, un rol tiene identidad: puede enviar y
recibir mensajes. La extensin de un rol es el conjunto de objetos que pueden
1
representar ese papel; de forma paralela, la extensin 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 instanciacin, un rol puede ser
jugado por un objeto como mximo. 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 eleccin
de las clases que implementan los objetos y de las relaciones entre ellas. un rol
puede ser implementado por una o ms clases y una clase puede implementar
uno o ms roles.
5. Mtodo de Fusin
Fusin proporciona un mtodo de desarrollo de software orientado al objeto,
que abarca desde la definicin de requisitos a la implementacin en un
lenguaje de programacin.
Es considerada como una metodologa de segunda generacin, porque

proviene de:
OMT: modelo de objetos,

CRC: interaccin de objetos,
BOOCH: visibilidad,
Los mtodos Formales: pre- y post- condiciones.
Proporciona un proceso de desarrollo, que se divide en:
Anlisis, Diseo e Implementacin.
Ofrece notaciones para los modelos, que describen varios aspectos del
software.
Actualmente ha abandonado su notacin.
Proporciona herramientas de gestin.
Anlisis
El anlisis se basa ms en describir lo que hace un sistema en lugar de cmo
lo hace. Para esto, hay que ver el sistema desde la perspectiva del usuario en
lugar de desde la de la mquina. El anlisis casa con el dominio del problema y
se preocupa por el comportamiento visible externamente.
1
La meta de la fase de anlisis 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 anlisis es un documento de definicin de
requisitos en lenguaje natural.
Modelo de objetos
La finalidad del modelo de objetos en Fusin 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 esttica de la informacin en el
sistema, las clases y relaciones entre ellas
Especifica el orden en el que deben hacerse las cosas dentro de cada fase.
Tambin proporciona criterios de cundo pasar a la siguiente fase.
En la fase del anlisis de Fusin, slo los atributos de una clase son
considerados. Los mtodos son considerados en la fase de diseo. Por
consiguiente, en la fase del anlisis, los objetos son similares a las entidades
en el tradicional modelo entidad relacin. Atributos de clases, agregacin,
especializacin/generalizacin.
1
Conclusiones
La metodologa orientada a objetos permite la optimizacin de los elementos

generados gracias a que mediante tcnicas de herencia, atributos estticos entre otros
permiten, que los elementos sean genricos de manera que sea reutilizable.
Las metodologas orientado a objetos es algo totalmente distinto a la programacin

estructurada y se tiene que romper cualquier esquema y enseanza previa si
deseamos incursionar en lenguajes y documentacin orientada a objetos
Gracias a UML se puede estudiar las distintas partes que conforman al sistema y cmo
interactan estas. Reflejando las interfaces, protocolos e intercambio de seales. Para
tal fin nos podemos apoyar de los diagramas de clases, estructura compuesta y
comunicacin.
El lenguaje de Modelado UML cumple con varios requerimientos para elaborar un

sistema orientado a objetos, ya que cuenta con una notacin estndar y notaciones
semnticas que son esenciales para elaborar este tipo de software.
1
Bibliografa
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-Diseo 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

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Que Es La Metodologia Orientada A Objeto

Hochgeladen von

Copyright:

Verfügbare Formate

METODOLOGIA

Docente : Ing. Jhon Romero

Pea Toledo, Luigui Aldair

Montes Guillermo, Erick

Nuez Huamani, Jhossimar

Dedicamos este trabajo a

Una metodologa Orientada a objetos es un proceso para

UML El lenguaje unificado de diagrama o notacin (UML)

UML est diseado para su uso con software orientado a

UML se compone de muchos elementos de esquematizacin

Metodologa Orientada Objetos

1. CONCEPTOS DE LA METODOLOGA ORIENTADA A

Actualmente el modelo de objetos ha sido influenciado por un nmero de

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

Actualmente, el Anlisis Orientado a Objetos (AOO) va progresando como

Una clase es una plantilla para objetos mltiples con caractersticas

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

Los mtodos de una clase determinan el comportamiento o conducta que

Para definir el comportamiento de un objeto, se crean mtodos, los cuales

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

Entonces, los detalles de la puesta en prctica pueden cambiar en cualquier

Esta imagen conceptual de un objeto un ncleo de variables empaquetadas

El encapsulamiento de variables y mtodos en un componente de software

Ocultamiento de la informacin, 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 metodologa orientada a objetos es el de

De esta manera, se puede pensar en una jerarqua de clase como la definicin de

La herencia presenta los siguientes beneficios:

Las subclases proveen conductas especializadas sobre la base de

Los programadores pueden implementar superclases llamadas clases

2. Ventajas de la metodologa orientada a objetos.

En sntesis, algunas ventajas que presenta son:

Reutilizacin. Las clases estn diseadas para que se reutilicen en

Estabilidad. Las clases diseadas para una reutilizacin repetida se

El diseador piensa en trminos del comportamiento de objetos y no en

Se construyen clases cada vez ms complejas. Se construyen clases a

Un diseo ms rpido. Las aplicaciones se crean a partir de componentes

Integridad. Las estructuras de datos (los objetos) slo se pueden utilizar

Mantenimiento ms sencillo. El programador encargado del

Independencia del diseo. Las clases estn diseadas para ser

Interaccin. El software de varios proveedores puede funcionar como

Computacin Cliente-Servidor. En los sistemas cliente-servidor, las

Computacin de distribucin masiva. Las redes a nivel mundial utilizarn

Mayor nivel de automatizacin de las bases de datos. Las estructuras

Migracin. Las aplicaciones ya existentes, sean orientadas a objetos o no,

Mejores herramientas CASE. Las herramientas CASE (Computer Aided

3. Principios de la Metodologa Orientada a Objetos.

Existen cuatro principios bsicos, estos principios son fruto de la

a) La eleccin de qu modelos se creen influye directamente

b) Todo modelo puede ser expresado a diferentes niveles de

c) Los mejores modelos estn 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 ingls, Unified Modeling Language) es el lenguaje de

Es un lenguaje grfico para visualizar, especificar, construir y

sistema (modelo), incluyendo aspectos conceptuales tales como procesos de

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

UML no puede compararse con la programacin estructurada, pues

Antes de UML 1.x

En 1996 Rational concluy que la abundancia de lenguajes de

Modelado abierto. Se consult con representantes de compaas

Bajo la direccin tcnica de los Tres Amigos (Rumbaugh, Jacobson