Que es la Metodología orientada a objetos - Introducción a UML

Integrantes : Quintanilla Garcia, AlexAlberto

Peña Toledo, LuiguiAldair

Montes Guillermo, Erick

Nuñez Huamani, Jhossimar

2015

METODOLOGIA ORIENTADA A OBJETOS -INTRODUCCION A UMLUniversidad Privada San Juan BautistaIngenieria De Computacion y Sistemas IV Ciclo

Docente : Ing. Jhon

1

METODOLOGIA ORIENTADA A OBJETOS -INTRODUCCION A UML

INDICE Dedicatoria....................................................2

Introducción...................................................3Capítulo I.....................................................4

Metodología Orientada Objetos..................................41. CONCEPTOS DE LA METODOLOGÍA ORIENTADA A OBJETOS...........4

2. Ventajas de la metodología orientada a objetos...........73. Principios de la Metodología Orientada a Objetos..........9

Capitulo II...................................................10UML El lenguaje unificado de diagrama o notación..............10

1. Lenguaje Unificado de Modelado...........................102. HISTORIA.................................................11

3. VENTAJAS DE PROGRAMAR USANDO UML:........................134. DESVENTAJAS..............................................13

5. OBJETIVOS................................................146. PRINCIPIOS...............................................14

6.1. Como nació UML........................................146.2. Modelado.............................................14

7. DIAGRAMAS ESTRUCTURALES.................................15Capítulo III..................................................21

Técnicas de Metodología orientada a objetos...................211. Metodología OMT..........................................21

2. Metodología BOOCH........................................223. Metodología RUP..........................................24

4. OOram....................................................265. Método de Fusión.........................................27

Conclusiones..................................................30Bibliografia..................................................31

1


1


Dedicatoria

Dedicamos este trabajo anuestro Padres que nosapoyan tanto de maneraeconómica como emotiva y alos diferentes agentes queintervienen para concretar

nuestro camino profesional.

1


1


Introducción

Una metodología Orientada a objetos es un procesopara producir software de una manera organizada,usando convenciones y técnicas de notaciónpredefinidas. Desde que la comunidad deprogramación orientada a objetos tuvo la noción deincorporar el pensamiento de que los objetos sonentidades coherentes con identidad estado yconducta, estos objetos pueden ser organizados porsus similitudes y sus diferencias, puestas en usoen herencia y polimorfismo, las metodologíasorientadas a objetos incorporan estos conceptospara definir sus reglas, normas, procedimientos,guías y notaciones para alcanzar un producto decalidad que satisfaga las necesidades del cliente.

UML El lenguaje unificado de diagrama o notación(UML) sirve para especificar, visualizar ydocumentar esquemas de sistemas de softwareorientado a objetos. UML no es un método dedesarrollo, lo que significa que no sirve paradeterminar qué hacer en primer lugar o cómodiseñar el sistema, sino que simplemente le ayudaa visualizar el diseño y a hacerlo más accesiblepara otros. UML está controlado por el grupo deadministración de objetos y es el estándar dedescripción de esquemas de software.

UML está diseñado para su uso con softwareorientado a objetos, y tiene un uso limitado enotro tipo de cuestiones de programación.

1


UML se compone de muchos elementos deesquematización que representan las diferentespartes de un sistema de software. Los elementosUML se utilizan para crear diagramas, querepresenta alguna parte o punto de vista delsistema.

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 lasmetodologías anteriores a éste. Así como los métodos dediseño estructurado realizados guían a los desarrolladoresque tratan de construir sistemas complejos utilizandoalgoritmos como sus bloques fundamentales de construcción,similarmente los métodos de diseño orientado a objetos hanevolucionado para ayudar a los desarrolladores a explotar elpoder de los lenguajes de programación basados en objetos yorientados a objetos, utilizando las clases y objetos comobloques de construcción básicos.

Actualmente el modelo de objetos ha sido influenciadopor un número de factores no sólo de la ProgramaciónOrientada a Objetos, POO (Object Oriented Programming, OOPpor sus siglas en inglés). Además, el modelo de objetos haprobado ser un concepto uniforme en las ciencias de lacomputación, aplicable no sólo a los lenguajes deprogramació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 aobjetos nos ayuda a hacer frente a la inherente complejidadde muchos tipos de sistemas.

Se define a un objeto como "una entidad tangible quemuestra alguna conducta bien definida". Un objeto "escualquier cosa, real o abstracta, acerca de la cualalmacenamos datos y los métodos que controlan dichos datos".

Los objetos tienen una cierta "integridad" la cual nodeberá ser violada. En particular, un objeto puede solamente

1


cambiar estado, conducta, ser manipulado o estar en relacióncon otros objetos de manera apropiada a este objeto.

Actualmente, el Análisis Orientado a Objetos (AOO) vaprogresando como método de análisis de requisitos por derechopropio y como complemento de otros métodos de análisis. Enlugar de examinar un problema mediante el modelo clásico deentrada-proceso-salida (flujo de información) o mediante unmodelo derivado exclusivamente de estructuras jerárquicas deinformación, el AOO introduce varios conceptos nuevos. Estosconceptos nuevos le parecen inusuales a mucha gente, pero sonbastante naturales.

Una clase es una plantilla para objetos múltiples concaracterísticas similares. Las clases comprenden todas esascaracterísticas de un conjunto particular de objetos. Cuandose escribe un programa en lenguaje orientado a objetos, no sedefinen objetos verdaderos sino se definen clases de objetos.

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 menudose utiliza indistintamente la palabra objeto o instancia parareferirse, 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 .

1


Para definir el comportamiento de un objeto, se creanmétodos, los cuales tienen una apariencia y un comportamientoigual al de las funciones en otros lenguajes de programación,los lenguajes estructurados, pero se definen dentro de unaclase. Los métodos no siempre afectan a un solo objeto; losobjetos también se comunican entre sí mediante el uso demétodos. Una clase u objeto puede llamar métodos en otraclase u objeto para avisar sobre los cambios en el ambiente opara solicitarle a ese objeto que cambie su estado.

Cualquier cosa que un objeto no sabe, o no puede hacer, esexcluida del objeto. Además, como se puede observar de losdiagramas, las variables del objeto se localizan en el centroo núcleo del objeto. Los métodos rodean y esconden el núcleodel objeto de otros objetos en el programa. Alempaquetamiento de las variables de un objeto con laprotección de sus métodos se le llama encapsulamiento.Típicamente, el encapsulamiento es utilizado para esconderdetalles de la puesta en práctica no importantes de otrosobjetos. Entonces, los detalles de la puesta en prácticapueden cambiar en cualquier tiempo sin afectar otras partesdel programa.

Esta imagen conceptual de un objeto —un núcleo de variablesempaquetadas en una membrana protectora de métodos— es unarepresentación ideal de un objeto y es el ideal por el quelos diseñadores de sistemas orientados a objetos luchan. Sinembargo, no lo es todo: a menudo, por razones de eficiencia o

1


la puesta en práctica, un objeto puede querer exponer algunasde sus variables o esconder algunos de sus métodos.

El encapsulamiento de variables y métodos en un componentede software ordenado es, todavía, una simple idea poderosaque provee dos principales beneficios a los desarrolladoresde software:

• Modularidad, esto es, el código fuente de un objeto puedeser escrito, así como darle mantenimiento, independientementedel código fuente de otros objetos. Así mismo, un objetopuede ser transferido alrededor del sistema sin alterar suestado y conducta.

• Ocultamiento de la información, es decir, un objeto tieneuna "interfaz publica" que otros objetos pueden utilizar paracomunicarse con él. Pero el objeto puede mantener informacióny métodos privados que pueden ser cambiados en cualquiertiempo sin afectar a los otros objetos que dependan de ello.

Los objetos proveen el beneficio de la modularidad y elocultamiento de la información. Las clases proveen elbeneficio de la reutilización. Los programadores de softwareutilizan la misma clase, y por lo tanto el mismo código, unay otra vez para crear muchos objetos.

En las implantaciones orientadas a objetos se percibe unobjeto como un paquete de datos y procedimientos que sepueden llevar a cabo con estos datos. Esto encapsula losdatos y los procedimientos. La realidad es diferente: losatributos se relacionan al objeto o instancia y los métodos ala clase. ¿Por qué se hace así? Los atributos son variablescomunes en cada objeto de una clase y cada uno de ellos puedetener un valor asociado, para cada variable, diferente al quetienen para esa misma variable los demás objetos. Losmétodos, por su parte, pertenecen a la clase y no sealmacenan en cada objeto, puesto que sería un desperdicioalmacenar el mismo procedimiento varias veces y ello vacontra el principio de reutilización de código.

Otro concepto muy importante en la metodología orientada aobjetos es el de herencia. La herencia es un mecanismo

1


poderoso con el cual se puede definir una clase en términosde otra clase; lo que significa que cuando se escribe unaclase, sólo se tiene que especificar la diferencia de esaclase con otra, con lo cual, la herencia dará accesoautomático a la información contenida en esa otra clase.

Con la herencia, todas las clases están arregladas dentrode una jerarquía estricta. Cada clase tiene una superclase(la clase superior en la jerarquía) y puede tener una o mássubclases (las clases que se encuentran debajo de esa claseen la jerarquía). Se dice que las clases inferiores en lajerarquía, las clases hijas, heredan de las clases más altas,las clases padres.

Las subclases heredan todos los métodos y variables de lassuperclases. Es decir, en alguna clase, si la superclasedefine un comportamiento que la clase hija necesita, no setendrá que redefinir o copiar ese código de la clase padre.

De esta manera, se puede pensar en una jerarquía de clasecomo la definición de conceptos demasiado abstractos en loalto de la jerarquía y esas ideas se convierten en algo másconcreto conforme se desciende por la cadena de lasuperclase.

Sin embargo, las clases hijas no están limitadas al estado yconducta provistos por sus superclases; pueden agregarvariables y métodos además de los que ya heredan de susclases padres. Las clases hijas pueden, también,

1


sobreescribir los métodos que heredan por implementacionesespecializadas para esos métodos. De igual manera, no haylimitación a un sólo nivel de herencia por lo que se tiene unárbol de herencia en el que se puede heredar varios niveleshacia abajo y mientras más niveles descienda una clase, másespecializada será su conducta.

La herencia presenta los siguientes beneficios:

Las subclases proveen conductas especializadas sobre labase de elementos comunes provistos por la superclase. Através del uso de herencia, los programadores puedenreutilizar el código de la superclase muchas veces.

Los programadores pueden implementar superclasesllamadas clases abstractas que definen conductas"genéricas". Las superclases abstractas definen, ypueden implementar parcialmente, la conducta pero granparte de la clase no está definida ni implementada.Otros programadores concluirán esos detalles consubclases especializadas.

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 sereutilicen en muchos sistemas. Para maximizar lareutilización, las clases se construyen de manera que sepuedan adaptar a los otros sistemas. Un objetivofundamental de las técnicas orientadas a objetos eslograr la reutilización masiva al construir el software.

Estabilidad. Las clases diseñadas para una reutilizaciónrepetida se vuelven estables, de la misma manera que losmicroprocesadores y otros chips se hacen estables.

El diseñador piensa en términos del comportamiento deobjetos y no en detalles de bajo nivel. Elencapsulamiento oculta los detalles y hace que lasclases complejas sean fáciles de utilizar.

Se construyen clases cada vez más complejas. Seconstruyen clases a partir de otras clases, las cuales asu vez se integran mediante clases. Esto permite

1


construir componentes de software complejos, que a suvez se convierten en bloques de construcción de softwaremás complejo.

Calidad. Los diseños suelen tener mayor calidad, puestoque se integran a partir de componentes probados, quehan sido verificados y pulidos varias veces.

Un diseño más rápido. Las aplicaciones se crean a partirde componentes ya existentes. Muchos de los componentesestán construidos de modo que se pueden adaptar para undiseño particular.

Integridad. Las estructuras de datos (los objetos) sólose pueden utilizar con métodos específicos. Esto tieneparticular importancia en los sistemas cliente-servidory los sistemas distribuidos, en los que usuariosdesconocidos podrían intentar el acceso al sistema.

Mantenimiento más sencillo. El programador encargado delmantenimiento cambia un método de clase a la vez. Cadaclase efectúa sus funciones independientemente de lasdemás.

Una interfaz de pantalla sugestiva para el usuario. Hayque utilizar una interfaz de usuario gráfica de modo queel usuario apunte a iconos o elementos de un menúdesplegado, relacionados con los objetos. Endeterminadas ocasiones, el usuario puede ver un objetoen la pantalla. Ver y apuntar es más fácil que recordary escribir.

Independencia del diseño. Las clases están diseñadaspara ser independientes del ambiente de plataformas,hardware y software. Utilizan solicitudes y respuestascon formato estándar. Esto les permite ser utilizadas enmúltiples sistemas operativos, controladores de bases dedatos, controladores de red, interfaces de usuariográficas, etc. El creador del software no tiene quepreocuparse por el ambiente o esperar a que éste seespecifique.

Interacción. El software de varios proveedores puedefuncionar como conjunto. Un proveedor utiliza clases deotros. Existe una forma estándar de localizar clases einteractuar con ellas. El software desarrollado de

1


manera independiente en lugares ajenos debe poderfuncionar en forma conjunta y aparecer como una solaunidad ante el usuario.

Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviarsolicitudes a las clases en el software servidor yrecibir respuestas. Una clase servidor puede serutilizada por clientes diferentes. Estos clientes sólopueden tener acceso a los datos del servidor a través delos métodos de la clase. Por lo tanto los datos estánprotegidos contra su corrupción.

Computación de distribución masiva. Las redes a nivelmundial utilizarán directorios de software de objetosaccesibles. El diseño orientado a objetos es la clavepara la computación de distribución masiva. Las clasesde una máquina interactúan con las de algún otro lugarsin saber donde residen tales clases. Ellas reciben yenvían mensajes orientados a objetos en formatoestándar.

Mayor nivel de automatización de las bases de datos. Lasestructuras de datos (los objetos) en las bases de datosorientadas a objetos están ligadas a métodos que llevana cabo acciones automáticas. Una base de datos OO tieneintegrada una inteligencia, en forma de métodos, entanto que una base de datos relacional básica carece deello.

Migración. Las aplicaciones ya existentes, seanorientadas a objetos o no, pueden preservarse si seajustan a un contenedor orientado a objetos, de modo quela comunicación con ella sea a través de mensajesestándar orientados a objetos.

Mejores herramientas CASE. Las herramientas CASE(Computer Aided Software Engineering, Ingeniería deSoftware Asistida por Computadora) utilizarán lastécnicas gráficas para el diseño de las clases y de lainteracción entre ellas, para el uso de los objetosexistentes adaptados a nuevas aplicaciones. Lasherramientas deben facilitar el modelado en términos deeventos, formas de activación, estados de objetos, etc.Las herramientas OO del CASE deben generar un código tanpronto se definan las clases y permitir al diseñador

1


utilizar y probar los métodos recién creados. Lasherramientas se deben diseñar de manera que apoyen elmáximo de creatividad y una continua afinación deldiseño durante la construcción.

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

Existen cuatro principios básicos, estosprincipios son fruto de la experiencia en todaslas ramas de la ingeniería.

a) La elección de qué modelos se creen influyedirectamente sobre cómo se acomete el problema.Hay que seleccionar el modelo adecuado para cadamomento y dependiendo de qué modelo se elija seobtendrán diferentes beneficios y diferentescostes. En la industria software se ha comprobadoque un modelado orientado a objetos proporcionaunas arquitecturas más flexibles y readaptablesque otros por ejemplo orientados a lafuncionalidad o a los datos.

b) Todo modelo puede ser expresado a diferentesniveles de precisión. Esto es, es necesario poderseleccionar el nivel de detalle que se desea yaque en diferentes partes de un proyecto y endiferentes etapas se tendrán unas determinadasnecesidades.

c) Los mejores modelos están ligados a larealidad. Lo principal es tener modelos que nospermitan representar la realidad lo másclaramente posible, pero no sólo esto, tenemosque saber, exactamente cuándo se apartan de larealidad para no caer en la ocultación de ningúndetalle importante

d) Un único modelo no es suficiente. Cualquiersistema que no sea trivial se afronta mejor desde

1


pequeños modelos casi independientes, que lospodamos construir y estudiar independientemente yque nos representen las partes más diferenciadasdel sistema y sus interrelaciones.

Capitulo II

UML El lenguaje unificado de diagrama onotación.

1.Lenguaje Unificado de Modelado

(UML, por sus siglas en inglés, Unified ModelingLanguage) es el lenguaje de modelado de sistemas desoftware 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ándarpara describir un "plano" del sistema (modelo), incluyendoaspectos conceptuales tales como procesos de negocio,funciones del sistema, y aspectos concretos comoexpresiones de lenguajes de programación, esquemas debases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje demodelado" para especificar o para describir métodos oprocesos. Se utiliza para definir un sistema, paradetallar los artefactos en el sistema y para documentar yconstruir. En otras palabras, es el lenguaje en el queestá descrito el modelo.

https://es.wikipedia.org/wiki/Object_Management_Group

https://es.wikipedia.org/wiki/Software

https://es.wikipedia.org/wiki/Modelado

1


Se puede aplicar en el desarrollo de software granvariedad de formas para dar soporte a una metodología dedesarrollo de software (tal como el Proceso UnificadoRacional o RUP), pero no especifica en sí mismo quémetodología o proceso usar.

UML no puede compararse con la programaciónestructurada, pues UML significa Lenguaje Unificado deModelado, no es programación, solo se diagrama la realidadde una utilización en un requerimiento. Mientras que,programación estructurada, es una forma de programar comolo es la orientación a objetos, la programación orientadaa objetos viene siendo un complemento perfecto de UML,pero no por eso se toma UML sólo para lenguajes orientadosa objetos.UML cuenta con varios tipos de diagramas, los cualesmuestran diferentes aspectos de las entidadesrepresentadas.

2.HISTORIA

Antes de UML 1.x

Después de que la Rational Software Corporationcontratara a James Rumbaugh de General Electric en1994, la compañía se convirtió en la fuente de los dosesquemas de modelado orientado a objetos más popularesde la época: el OMT (Object-modeling technique) deRumbaugh, que era mejor para análisis orientado aobjetos, y el Método Booch de Grady Booch, que eramejor para el diseño orientado a objetos. Poco despuésse les unió Ivar Jacobson, el creador del método deingeniería de software orientado a objetos. Jacobson seunió a Rational en 1995 después de que su compañía,Objectory AB, fuera comprada por Rational. Los tresmetodologistas eran conocidos como los Tres Amigos,porque se sabía de sus constantes discusiones sobre lasprácticas metodológicas.

https://es.wikipedia.org/wiki/Ivar_Jacobson

https://es.wikipedia.org/wiki/Programaci%C3%B3n_estructurada

https://es.wikipedia.org/wiki/Programaci%C3%B3n_estructurada

https://es.wikipedia.org/wiki/RUP

1


En 1996 Rational concluyó que la abundancia delenguajes de modelado estaba alentando la adopción dela tecnología de objetos, y para orientarse hacia unmétodo unificado, encargaron a los Tres Amigos quedesarrollaran un Lenguaje Unificado de Modeladoabierto. Se consultó con representantes de compañíascompetidoras en el área de la tecnología de objetosdurante la OOPSLA '96; eligieron cajas para representarclases en lugar de la notación de Booch que utilizabasímbolos de nubes.

Bajo la dirección técnica de los Tres Amigos (Rumbaugh,Jacobson y Booch) fue organizado un consorciointernacional llamado UML Partners en 1996 paracompletar las especificaciones del Lenguaje Unificadode Modelado (UML), y para proponerlo como una respuestaal OMG RFP. El borrador de la especificación UML 1.0 deUML Partners fue propuesto a la OMG en enero de 1997.Durante el mismo mes la UML Partners formó una Fuerzade Tarea Semántica, encabezada por Cris Kobryn yadministrada por Ed Eykholt, para finalizar lassemánticas de la especificación y para integrarla conotros esfuerzos de estandarización. El resultado deeste trabajo, el UML 1.1, fue presentado ante la OMG enagosto de 1997 y adoptado por la OMG en noviembre de1997.

UML 1.x

Como notación de modelado, la influencia de la OMTdomina UML (por ejemplo el uso de rectángulos paraclases y objetos). Aunque se quitó la notación de"nubes" de Booch, si se adoptó la capacidad de Boochpara especificar detalles de diseño en los nivelesinferiores. La notación de Casos de Uso del Objectory yla notación de componentes de Booch fueron integradosal resto de la notación, pero la integración semántica

1


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 integradossuperficialmente en UML con el propósito de hacerlocompatible con todos los métodos OO. Además el grupotomó en cuenta muchos otros métodos de la época, con elobjetivo de asegurar amplia cobertura en el dominio delos 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ólousuario a sistemas concurrentes y distribuidos.

El Lenguaje de Modelado Unificado es un estándarinternacional:

ISO / IEC 19501:2005 Tecnología de la información -Procesamiento distribuido abierto - Lenguaje deModelado Unificado (UML) Versión 1.4.2

UML 2.x

UML ha madurado considerablemente desde UML 1.1. Variasrevisiones menores (UML 1.3, 1.4 y 1.5) han corregidodefectos y errores de la primera versión de UML. Aestas le ha seguido la revisión mayor UML 2.0 que fueadoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como unaespecificación formal, las versiones 2.1.1 y 2.1.2,aparecieron en 2007, seguidas por UML 2.2 en febrero de2009. 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 formalmenteliberada.

1


UML es la herramienta grafica que Se utiliza paraespecificar métodos o procesos realizados por elsistema, por medio de una serie de diagramas.

Nos proporciona una serie de herramientas que permitenmostrar el programa en sus diferentes etapas oprocesos, delimitarlos y organizarlos de tal forma quesean entendibles por la persona que va a desarrollar elsistema.

Cabe destacar que UML no es un lenguaje deprogramación, sino el sistema que permite modelar laestructura del programa.

Aquellas personas que nunca han programado usando umlsiempre lo ven como una pérdida de tiempo, perodeberían dedicarle por lo menos una semana a esto, enverdad 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

1


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.

5. OBJETIVOS

- El método debía ser capaz de modelar no sólo sistemas desoftware sino otro tipo de sistemas reales de la empresa,siempre utilizando los conceptos de la orientación aobjetos (OO).

- Crear un lenguaje para modelado utilizable a la vez pormáquinas y por personas.

- Establecer un acoplamiento explícito de los conceptos ylos artefactos ejecutables.

- Manejar los problemas típicos de los sistemas complejosde misión crítica.

Lo que se intenta es lograr con esto que los lenguajes quese aplican siguiendo los métodos más utilizados siganevolucionando en conjunto y no por separado. Y además,unificar las perspectivas entre diferentes tipos desistemas (no sólo software, sino también en el ámbito delos negocios), al aclarar las fases de desarrollo, losrequerimientos de análisis, el diseño, la implementación ylos conceptos internos de la OO.

6. PRINCIPIOS6.1. Como nació UML.

Durante los ochenta y principios de los noventa GradyBooch, James Rumbaugh, e Ivar Jacobson trabajaban porseparado en desarrollo de notaciones para el análisisy diseño de sistemas orientados a objetos. Los tresllegaron por separado a obtener bastante

1


reconocimiento.Booch había escrito "Object-OrientedAnalysis and Design with Applications " un libro dereferencia en el análisis y diseño orientado aobjetos desarrollando su propia notación.Por su parteJames Rumbaugh había desarrollado su propia notaciónde diseño orientado a objetos llamada OMT (ObjectModeling Technique) en su libro "Object-OrientedModeling and Design ".Por otro lado Jacobson se habíarevelado como un visionario del análisis (padre delos casos de uso) y sobre todo del diseño orientado aobjetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case DrivenApproach ".A mediados de los noventa empezaron aintercambiar documentos y trabajar en conjuntoproduciendo grandes avances en el modelado desistemas orientados a objetos.En 1994 Rationalcontrató a Rumbaugh en donde ya trabajaba Booch, unaño después Jacobson se unía a ellos en Rational.En1997 salió a la luz la versión 1.0 de UML.

6.2. Modelado.

El Lenguaje de Modelado Unificado UML."El Lenguaje deModelado Unificado UML es un lenguaje estándar paraescribir planos de software. UML puede utilizarsepara visualizar, especificar, construir y documentarlos artefactos de un sistema que involucra grancantidad de software"El UML es el Lenguaje deModelado Unificado Orientado a Objetos, UML no es unmétodo porque no tiene noción de proceso el cual esuna parte importante de un método. Ahora bien si UMLno es método; entonces ¿Cuáles son las etapas aseguir en el desarrollo de sistemas con UML?, variosespecialistas en desarrollo de sistemas deinformación arguyen de que existe la necesidad deadoptar un Proceso de Desarrollo de sistemas paraenmarcar las fases importantes que sigue el UML, porello los desarrolladores de proyectos de sistemas deinformación emplean el Procesos Unificado para dar

1


soluciones adecuadas a las necesidades de losclientes.El desarrollo de sistemas con UML siguiendoel proceso unificado incluye actividades específicas,cada una de ellas a su vez contienen otrassubactividades las cuales sirven como una guía decómo deben ser las actividades desarrolladas ysecuenciadas con el fin de obtener sistemas exitosos;consecuentemente el desarrollo de los sistemas puedevariar de desarrollador en desarrollador, de proyectoen proyecto, de empresa en empresa adoptando siempreun Proceso de Desarrollo.

7. DIAGRAMAS ESTRUCTURALES. Diagrama de clases.- un diagrama de

clases en Lenguaje Unificado de Modelado (UML) es untipo de diagrama de estructura estática que describela estructura de un sistema mostrando las clases delsistema, sus atributos, operaciones (o métodos), y lasrelaciones entre los objetos.

https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado

1


Diagrama de componentes.- Un diagrama decomponentes representa cómo un sistema de software esdividido en componentes y muestralas dependencias entre estos componentes. Loscomponentes físicos incluyen archivos,cabeceras, bibliotecascompartidas, módulos, ejecutables, o paquetes. Losdiagramas de Componentes prevalecen en el campo dela arquitectura de software pero pueden ser usadospara modelar y documentar cualquier arquitectura desistema.Debido a que los diagramas de componentes sonmás parecidos a los diagramas de casos de usos, éstosson utilizados para modelar la vista estática ydinámica de un sistema. Muestra la organización y lasdependencias entre un conjunto de componentes. No es

necesario que un diagrama incluya todos loscomponentes del sistema, normalmente se realizan porpartes. Cada diagrama describe un apartado delsistema.

https://es.wikipedia.org/wiki/Arquitectura_de_software

https://es.wikipedia.org/wiki/Paquete_de_software

https://es.wikipedia.org/wiki/Ejecutable

https://es.wikipedia.org/wiki/M%C3%B3dulo_(programaci%C3%B3n)

https://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

https://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

https://es.wikipedia.org/wiki/Archivo_(computaci%C3%B3n)

https://es.wikipedia.org/w/index.php?title=Dependencia_(UML)&action=edit&redlink=1

https://es.wikipedia.org/wiki/Componente_de_software

https://es.wikipedia.org/wiki/Software

1


Diagrama de estructura compuesta.- es untipo de diagrama en el Lenguaje de ModeladoUnificado (UML), que muestra la estructura interna deunaclase y las colaboraciones que esta estructura haceposibles. Esto puedeincluir partes internas, puertas mediante las cuales,las partes interactúan con cada una de las otras omediante las cuales, instancias de la claseinteractúan con las partes y con el mundo exterior,yconectores entre partes o puertas. Una estructuracompuesta es un conjunto de elementos interconectadosque colaboran en tiempo de ejecución para lograr algúnpropósito. Cada elemento tiene algún rol definido en lacolaboración.

https://es.wikipedia.org/wiki/Clase_(inform%C3%A1tica)

https://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

https://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

1


1


Diagrama de paquetes.- Muestra cómo unsistema está dividido en agrupaciones lógicasmostrando las dependencias entre esasagrupaciones .Dado que normalmente un paquete estápensado como un directorio, los diagramas de paquetessuministran una descomposición de la jerarquía lógicade un sistema. Los Paquetes están normalmenteorganizados para maximizar la coherencia internadentro de cada paquete y minimizar el acoplamiento

externo entre los paquetes. Con estas líneas maestrassobre la mesa, los paquetes son buenos elementos degestión. Cada paquete puede asignarse a un individuo oa un equipo, y las dependencias entre ellos puedenindicar el orden de desarrollo requerido.

1


Diagrama de despliegue.- Diagrama deDespliegue es un tipo de diagrama del LenguajeUnificado de Modelado que muestran las relacionesfísicas de los distintos nodos que componen un sistemay el reparto de los componentes sobre dichos nodos.Los diagramas de despliegue son los complementos delos diagramas de componentes que, unidos, proveen lavista de implementación del sistema. Describen latopología del sistema la estructura de los elementosde hardware y el software que ejecuta cada uno deellos.Los diagramas de despliegue representan a losnodos y sus relaciones. Los nodos son conectados porasociaciones de comunicación tales como enlaces dered, conexiones TCP/IP.

1


Diagrama de objetos.- diagrama que muestra unavista completa o parcial de los objetos de un sistema enun instante de ejecución específico. Un diagrama deobjetos es un gráfico de instancias, incluyendo objetosy datos. Un diagrama de objetos es una instancia de undiagrama de clases; muestra una 'foto' del estado de unsistema en un punto de tiempo determinado Los diagramasde objeto están ligados a los diagramas de clase ycomparten virtualmente los mismos símbolos para lanotación. Los diagramas de objetos pertenecen a lacategorí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 unaabstracción, en el cual el análisis está enfocado en el mundoreal para un nivel de diseño, también pone detallesparticulares para modelado de recursos de la computadora.Esta metodología puede ser aplicada en varios aspectos deimplementación incluyendo archivos, base de datosrelacionales, 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, especificacionesimperativas para poder descender prematuramente en el diseño,declaraciones que permiten optimizar los estados, ademásprovee un soporte declarativo para una directa implementacióndeDBMSData Base Manager System

Los puntos más importantes para esta metodología son lossiguientes:Poner énfasis en el análisis y no en el desarrollo.Poner énfasis en los datos más que en las funciones, lo queproporciona estabilidad al proceso de desarrollo.Utilizar una notación común en todas las fases a través detres modelos que capturan los aspectos estáticos, dinámicos yfuncionales que combinados proveen una descripción completadel software. La Metodología OMT divide el proceso dedesarrollo en tres partes aisladas: análisis, diseño eimplantación.

Análisis: Su objetivo es desarrollar un modelo de lo que va a hacer elsistema. El modelo se expresa en términos de objetos y de

1


relaciones entre ellos, flujo dinámico de control y lastransformaciones funcionales. Diseño: Es la estrategia de alto nivel para resolver el problema ycómo construir una solución. Se define la arquitectura delsistema y se toman las decisiones estratégicas. Implementación:En esta fase se convierte finalmente el diseño de objetos encódigo. A su vez, cada una de estas fases se divide en sutareas, 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 primeraimagen del modelo de clases del sistema con sus atributos ylasrelaciones entre ellas, usando para ello un diagramaentidad relación modificada en el que además de las clases ysus relaciones se pueden representar también los métodos. Modelo Dinámico:El modelo dinámico usa un grafo para representar elcomportamiento dinámico de cada clase, es decir, elcomportamiento de estas ante cada evento que se produce en elsistema. Un evento desencadenará en un cambio de estado en laclase que se traducirá en una modificación de los atributos orelaciones de ésta. Modelo Funcional: Muestra que es lo que el sistema ha de hacer mediante undiagrama de flujo de datos, sin entrar en la secuenciatemporal en la que los procesos se ejecutan. El modelofuncional puede revelar nuevos objetos y métodos que sepueden incorporar en los dos modelos anteriores. Por eso sedice que el método OMT es iterativo. Diseño del Sistema: Se centra en la parte física del sistema como ladescomposición de éste en subsistemas, el tipo de entorno enel que se va a ejecutar, el manejo de recursos y elalmacenamiento de datos. Diseño de los objetos: Determina que operaciones van a realizar los métodos yprofundiza incluso los algoritmos que va a usar. Se escogen

1


los distintos tipos de representación de datos y se subdivideen 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ósitogeneral en la que se parte de que cada etapa no es unproceso aislado si no que ha de Interactuar con sussiguientes y precedentes en una especie de bucle del que sesale cuando se esté satisfecho con el modelo conseguido. Enun principio se tienen una serie de objetos y clases queforman el sistema, a continuación se construye el modelo deinterfaz y se examinan las relaciones entre las clases loque, a su vez, genera la adición de nuevos interfaces quegenerarán nuevas relaciones iterándose hasta llegar alestado de refinamiento deseado. El método Booch proporcionaun conjunto de herramientas gráficas y notaciones queayudan representar visualmente los modelos definidos en lasfases de análisis y diseño. Algunas de ellas son:

Diagramas de clase:

Es una variación de los diagramas de entidad relaciónen los que se añaden nuevos tipos de relaciones comola herencia, instanciación y uso. Además permiteagrupar las clases y relaciones en categorías paradiagramas demasiado complejos.El gráfico correspondiente a una clase en la notaciónde Booch es una especie de nube a trazos en cuyointerior se escribe el nombre de la misma, separadopor una linea de sus atributos (estado) y métodos

1


(comportamiento). Cada clase lleva asociado un nombreque en general debe ser único. No se especificantodos los métodos y atributos siempre, sino solamenteaquellos que son relevantes para la parte del diseñoque tratamos de describir.

Diagramas de objetos:

En este tipo de gráfico de muestran los objetos y susrelaciones de forma dinámica mostrando la forma en laque los objetos se pasan mensajes entre ellos. Asímismo, en esto diagramas es posible representarlavisibilidad de los objetos siendo ésta la quedetermina que objetos se pueden comunicar con otros.

Diagramas temporales:

Muestran la secuencia temporal de creación ydestrucción de objetos. Suelen ir acompañados depseudocódigo en el que se explica el flujo demensajes de control entre los objetos del sistema.

Diagramas de transición de estados:

Permiten definir como las instancias de las clasespasan de un estado a otro a causa de ciertos eventosy que acciones se desencadenan de esos cambios deestado.

El Diagrama de Transición de Estado (también conocidocomo DTE) enfatiza el comportamiento dependiente deltiempo del sistema. Este tipo de modelo sóloimportaba para una categoría de sistemas conocidocomo sistemas de tiempo-real; como ejemplo de estossistemas se tienen el control de procesos, sistemasde conmutación telefónica, sistemas de captura dedatos de alta velocidad y sistemas de control y mandomilitares.ElementosEntidades: Las entidades pasan por varios estados. Encada uno de ellos pueden suceder determinados eventosque provoquen efectos o acciones sobre la entidad.

Eventos: Algo que sucede en el mundo real y comoconsecuencia se ejecuta un proceso.

1


Acciones: Descripción del estado de un evento sobreuna entidad

Definición de DTE.

Un diagrama de transición de estados describe unconjunto de transiciones que pueden suceder sobre unaentidad. El estado en que se encuentra una entidad esel resultado de todas las transiciones sucedidasdurante su vida.

Diagramas de módulo y proceso:

En Booch, en la fase de implementación, es posiblerepresentar mediante estos gráficos la parte físicadel sistema, es decir, podemos mostrar cómo se van aalmacenar internamente las clases y objetos,relaciones entre módulos en tiempo de compilación,procesos, dispositivos y las comunicaciones entreellos.El diagrama de módulos muestra la asignación declases y objetos o módulos en el diseño físico de unsistema. Un solo diagrama de módulos representa unavista de la estructura de módulos de un sistema. Losdos elementos esenciales de un diagrama de módulosson los módulos y sus dependencias.

Programa principal: Identifica al archivo quecontiene la raíz del programa.Especificación y cuerpo: Identifican los archivos quecontienen la declaración y la definición de losobjetos o bien procedimientos o funciones necesariaspara el correcto funcionamiento de la aplicación.

3.Metodología RUP Rational Unified Process (RUP)

1


Proceso Unificado de Desarrollo es el resultado de tresdécadas de desarrollo y uso práctico. Es un conjunto deactividades necesarias para transformar los requisitos deun usuario en un sistema de software. Más que un simpleproceso de trabajo, es un marco de trabajo genérico quepuede especializarse para una gran variedad de dominios.Rational Unified Process (RUP), es la metodología estándarde la industria para la construcción completa del ciclo deingeniería de software, tanto para sistemas tradicionalescomo para sistemas web. Esta metodología permite mayorproductividad en equipo y la realización de mejoresprácticas de software a través de plantillas y herramientasque guían en todas las actividades de desarrollo críticodel software. RUP unifica las disciplinas en lo que adesarrollo de software se refiere, incluyendo modelado denegocio,El manejo de requerimientos, componentes de desarrollo,ingeniería de datos, manejo y configuración de cambios, ypruebas, cubriendo todo el ciclo de vida de los proyectosbasado en la construcción de componentes y maximizando eluso del UML (Unified Modeling Language). El software enconstrucción está formado por componentes interconectados através de interfaces. Los puntos principales en los que sebasa RUP son los siguientes:

1


Casos de Uso:Los casos de uso representan los requisitos funcionales dela aplicación a ser desarrollada; en otras palabras, qué eslo que debe hacer el sistema.

Arquitectura del producto:El concepto de arquitectura de software incluye losaspectos estáticos y dinámicos más significativos delsistema. Hay que tomar en cuenta que tanto la arquitecturacomo los casos de uso deben ser generados en paralelo, pueslos casos de uso deben encajar en la arquitectura, así comola arquitectura debe permitir que los casos de uso selleven a cabo.

Ciclo de vida Iterativo Incremental:El ciclo de vida Iterativo Incremental, consiste en dividirel trabajo en partes más pequeñas o mini proyectos. Cadamini proyecto es una iteración que resulta en unincremento. Las iteraciones hacen referencias a pasos en elflujo de trabajo, y los incrementos, al crecimiento delproducto. Para una efectividad máxima,Las iteraciones deben estar controladas; esto es, debenseleccionarse y ejecutarse desuna forma planificada. El RUPse sostiene en los tres puntos básicos anteriores. Parahacer 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 delproyecto y control de la configuración. El RUP haestablecido un Framework que integra todas esas diferentesfacetas.

1


PROCESO UNIFICADO

Proceso Unificado de Desarrollo Software o simplementeProceso Unificado es un marco de desarrollo de software quese caracteriza por estar dirigido por casos de uso,centrado en la arquitectura y por ser iterativo eincremental. El refinamiento más conocido y documentado delProceso Unificado es el Proceso Unificado de Rational osimplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino unmarco de trabajo extensible que puede ser adaptado aorganizaciones o proyectos específicos. De la misma forma,el Proceso Unificado de Rational, también es un marco de trabajoextensible, por lo que muchas veces resulta imposible decirsi un refinamiento particular del proceso ha sido derivadodel Proceso Unificado o del RUP. Por dicho motivo, los dosnombres suelen utilizarse para referirse a un mismoconcepto.

El nombre Proceso Unificado se usa para describir el procesogenérico que incluye aquellos elementos que son comunes ala mayoría de los refinamientos existentes.

http://es.wikipedia.org/wiki/RUP

http://es.wikipedia.org/wiki/RUP

http://es.wikipedia.org/wiki/Desarrollo_en_espiral

http://es.wikipedia.org/wiki/Desarrollo_en_espiral

http://es.wikipedia.org/wiki/Casos_de_uso

http://es.wikipedia.org/wiki/Ciclo_de_desarrollo

1


4.OOram

OOram (Object-Oriented Role Analysis and Modeling) Es unmétodo de análisis y diseño basado en la metáfora de laorientación a objetos pero que introduce El concepto demodelo de roles como principal mecanismo de abstracción queutilizará el modelador. El modelado con roles fue ideadopara modelar grandes sistemas y con el propósito defavorecer una implementación en lenguajes de programaciónorientada a objetos. Para ello el sistema se descompone enun conjunto de subsistemas o áreas de interés querepresentan actividades desempeñadas por una estructura deobjetos que colaboran entre sí. Cada una de estasestructuras es descrita Mediante un modelo de roles.Unmodelo de roles describe los objetos que participan en unaactividad y las interacciones entre ellos; contiene unconjunto de roles, de modo que todos los objetos que ocupanuna misma posición en la estructura son representados porun rol. un rol describe el comportamiento de un objeto enel contexto de una actividad. la figura 1 muestra el modelode roles compras proyecto que describe la actividadasociada a una solicitud de compra por un miembro de unproyecto desarrollado en una organización. El modelo serepresenta mediante una vista colaboración y una vistaescenario, que son las más utilizadas del conjunto devistas que ofrece Ooram.Modelo de roles de la vistaescenario se deduce fácilmente la secuencia de acciones queincluye la actividad. Si dos roles están conectadosmediante una línea, significa que existe una interacciónentre ellos. si en el extremo de una línea aparece unpuerto, significa que un objeto que juegue el rol asociadoenviará mensajes a un objeto que juegue el rol del otroextremo de la línea. el envío de un mensaje provoca la

1


ejecución de una operación o método sobre el objeto del rolque lo recibe. un puerto representado con un doble círculodenota que la interacción puede ser con un conjunto deobjetos. Ooram también incluye la vista diagrama deestados, que describe los estados de un rol y lastransiciones entre ellos; la vista proceso (basada en elestándar idef0 muestra explícitamente las acciones querealizan los roles y los flujos de información queintercambian, y la vista semántica, isomorfa a la vistacolaboración del mismo modelo, pero que en vez de puertos ycaminos de interacción entre roles, muestra relaciones deasociación. el concepto de rol unifica los conceptos clasey objeto: los roles tienen tanto una naturaleza estáticacomo dinámica, pues permiten describir las propiedades delos objetos que representan, y también pueden usarse paramostrar cómo los objetos colaboran entre sí. al igual queun objeto, un rol tiene identidad: puede enviar y recibirmensajes. La extensión de un rol es el conjunto de objetosque pueden representar ese papel; de forma paralela, laextensión de un modelo de roles es el conjunto deestructuras de objetos obtenido una vez que hacemos jugarsus roles a los objetos del sistema; durante unainstanciación, un rol puede ser jugado por un objeto comomáximo. Una clase describe un objeto independientemente delcontexto en que dicho objeto interacciona con otros; un roldescribe un objeto en el contexto de una actividad. Losroles son independientes de las clases, permiten unmodelado que pospone la elección de las clases queimplementan los objetos y de las relaciones entre ellas. unrol puede ser implementado por una o más clases y una clasepuede implementar uno o más roles.

5.Método de Fusión

Fusión proporciona un método de desarrollo de softwareorientado al objeto, que abarca desde la definición derequisitos a la implementación en un lenguaje deprogramació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 variosaspectos del software.Actualmente ha abandonado su notación.Proporciona herramientas de gestión.

AnálisisEl análisis se basa más en describir lo que hace un sistemaen lugar de cómo lo hace. Para esto, hay que ver el sistemadesde la perspectiva del usuario en lugar de desde la de lamáquina. El análisis casa con el dominio del problema y sepreocupa por el comportamiento visible externamente.La meta de la fase de análisis es capturar tantosrequisitos del sistema como sea posible. Se producen lossiguientes 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.

1


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.

Modelo de objetos

La finalidad del modelo de objetos en Fusión es: capturarlos conceptos que existen en el dominio del problema y lasrelaciones entre ellos, mostrar clases y sus relaciones,(no mostrar objetos)El modelo de objetos representa: la estructura estática dela información en el sistema, las clases y relaciones entreellasEspecifica el orden en el que deben hacerse las cosasdentro de cada fase. También proporciona criterios decuándo pasar a la siguiente fase.En la fase del análisis de Fusión, sólo los atributos deuna clase son considerados. Los métodos son considerados enla fase de diseño. Por consiguiente, en la fase delanálisis, los objetos son similares a las entidades en eltradicional 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 delos elementos generados gracias a que mediante técnicas deherencia, atributos estáticos entre otros permiten, que loselementos sean genéricos de manera que sea reutilizable.

Las metodologías orientado a objetos es algo totalmentedistinto a la programación estructurada y se tiene que rompercualquier esquema y enseñanza previa si deseamos incursionar enlenguajes y documentación orientada a objetos

Gracias a UML se puede estudiar las distintas partes queconforman al sistema y cómo interactúan estas. Reflejando lasinterfaces, protocolos e intercambio de señales. Para tal finnos podemos apoyar de los diagramas de clases, estructuracompuesta y comunicación.

El lenguaje de Modelado UML cumple con varios requerimientospara elaborar un sistema orientado a objetos, ya que cuenta conuna notación estándar y notaciones semánticas que son esencialespara 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 Objetoso 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/

http://metodologia-de-booch.blogspot.pe/

http://es.slideshare.net/yolandacando1/metodologa-orientadas-a-objetos

http://es.slideshare.net/yolandacando1/metodologa-orientadas-a-objetos

http://www.monografias.com/

http://www.buenastareas.com/

http://www.deslishare.com/uml.html

http://www.wikipedia.com/

http://es.slideshare.net/Waleskita/metodologia-uml-presentation

http://es.slideshare.net/Waleskita/metodologia-uml-presentation

http://login.osirislms.com/offline/uml/

http://profesores.fi-b.unam.mx/carlos/aydoo/toc.html

http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html

http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html

Que es la Metodología orientada a objetos - Introducción a UML

Documents

Transcript of Que es la Metodología orientada a objetos - Introducción a UML