SlideShare uma empresa Scribd logo
1 de 20
Baixar para ler offline
Universidad




                    INGENIERÍA DE SOFTWARE

                        Object Oriented y UML


   ELABORADO POR:
            Contreras Chávez, Estanislao       madti0112@esan.edu.pe




                                  Abril 2007
                                 Lima - Perú
Object Oriented y UML                                                                                    Estanislao Contreras Chávez




                                                                   Índice
Introducción ................................................................................................................................... 3
   1.       Object Oriented ............................................................................................................ 4
      1.1.    Paradigma Orientado a Objetos .............................................................................. 4
      1.2.    Clases y Objetos...................................................................................................... 4
      1.3.    Atributos y Métodos ................................................................................................. 5
      1.4.    Encapsulamiento ..................................................................................................... 5
      1.5.    Herencia................................................................................................................... 6
      1.6.    Polimorfismo ............................................................................................................ 7
      1.7.    Ventajas de la metodología orientada a objetos ..................................................... 8
      1.8.    Problemas derivados de la utilización de la orientación a objetos .......................... 9
      1.9.    El estado actual de la OO...................................................................................... 10
      1.10.   Predicciones del futuro cercano de la OO............................................................. 10
   2.       UML............................................................................................................................ 11
      2.1.    La importancia del Modelado................................................................................. 11
      2.2.    El Lenguaje Unificado de Modelado UML ............................................................. 11
        2.2.1      Historia de UML................................................................................................. 11
        2.2.2      Modelado Visual ................................................................................................ 12
        2.2.3      ¿Qué es UML? .................................................................................................. 13
        2.2.4      Las fases del desarrollo de sistemas que soporta UML ................................... 14
        2.2.5      Objetivos de UML .............................................................................................. 15
        2.2.6      Beneficios de UML ............................................................................................ 15
      2.3.    Diagramas de UML................................................................................................ 15
      2.4.    Proceso de Desarrollo ........................................................................................... 18
   Referencias .............................................................................................................................. 20




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                                                                           2 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez



                                        Introducción
Desde el nacimiento de los primeros lenguajes de programación orientados a objetos, en la
década de los 60, la Tecnología de Objetos (TO) se ha presentado como la solución a muchos
de los problemas del desarrollo de software, consolidándose, en la década de los 90, como el
paradigma de desarrollo para sistemas de complejidad media o alta (aplicaciones CAD/CAM,
multimedia, aplicaciones distribuidas, etc.). Además, proporciona otra serie de ventajas como
facilitar la reutilización de código o permitir obtener aplicaciones más fácilmente escalables. En
la actualidad, y especialmente desde la aparición de Java y .NET, la TO parece ser también la
que mejor se adapta a los nuevos tipos de desarrollos hipermedia y Web.

Hablar de TO lleva consigo la necesidad de hablar de objetos, de componentes, de patrones,
de lenguajes, de frameworks, de arquitecturas, de persistencia, etc. Por otra parte, la TO hoy
pasa por la integración de cada una de las técnicas y herramientas de desarrollo, tanto de
análisis y diseño, como de programación, persistencia o distribución. Cada una de estas
palabras clave, así como la problemática de la integración de las mismas, constituye un área
de interés que podría, sin duda alguna, dar lugar a un trabajo como éste. Por ello, no
pretendemos profundizar en ninguna de estas áreas sino, más bien, ofrecer una visión general
de la TO en la actualidad así como de lo que, en nuestra opinión y haciendo una arriesgada
previsión de futuro, constituyen las principales tendencias de la misma.

Tras la aceptación del paradigma orientado a objetos (OO) como el más adecuado para
producir software de calidad, a principios de los noventa emergieron un buen número de
métodos de desarrollo de software OO. En 1993, Jacobson criticó en lo que el denominaba
guerra de métodos y planteo la necesidad de llegar a una notación estándar de modelado,
para evitar la confusión reinante y favorecer el uso de los métodos de software OO. A finales de
1994 se inicio un esfuerzo unificación y es así como nace el Lenguaje Unificado de
Modelamiento (UML Unified Modeling Language). UML ha ejercido un gran impacto en la
comunidad software, tanto a nivel de desarrollo como de investigación y esas son las razones
por la cual presentamos un estudio preciso acerca de UML para exponer sus principales
características.




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             3 / 20
Object Oriented y UML                                                               Estanislao Contreras Chávez




                                                                                  Revisión: 03 de abril de 2007

ESTANISLAO CONTRERAS

                                     Object Oriented y UML1
         .

1. Object Oriented

1.1.     Paradigma Orientado a Objetos
El paradigma orientado a objetos ha derivado de los paradigmas anteriores a éste. Así como
los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de
construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de
construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para
ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en
objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción
básicos.

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

Actualmente, el Análisis y Diseño Orientado a Objetos (ADOO) va progresando como método
de análisis de requisitos por derecho propio y como complemento de otros métodos de análisis.
En lugar de examinar un problema mediante el modelo clásico de entrada-proceso-salida (flujo
de información) o mediante un modelo derivado exclusivamente de estructuras jerárquicas de
información, el ADOO introduce varios conceptos nuevos. Estos conceptos le parecen
inusuales a mucha gente, pero son bastante naturales.


1.2.     Clases y Objetos
Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida".
Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los
métodos que controlan dichos datos".

Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto
puede solamente cambiar estado, conducta, ser manipulado o estar en relación con otros
objetos de manera apropiada a este objeto.

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

1
 Este trabajo fue elaborado por el alumno Estanislao Contreras con la finalidad de mostrar los fundamentos de Object
Oriented y UML.

Universidad ESAN – Maestría en Dirección de Tecnologías de Información                                                 4 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez



Una instancia de una clase es otro término para un objeto real. Si la clase es la representación
general de un objeto, una instancia es su representación concreta. A menudo se utiliza
indistintamente la palabra objeto o instancia para referirse, precisamente, a un objeto.

1.3.    Atributos y Métodos
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 (figura 1).




                                                                     Atributos y Detalles
        Métodos e
                                                                     de la Implementación
        Interface
                                                                     Interna
        Pública




                            Figura 1: Representación de un objeto

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

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

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




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             5 / 20
Object Oriented y UML                                                      Estanislao Contreras Chávez


El encapsulamiento de variables y métodos en un componente de software ordenado es,
todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores
de software:

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

    •   Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que
        otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener
        información y métodos privados que pueden ser cambiados en cualquier tiempo sin
        afectar a los otros objetos que dependan de ello.

Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las
clases proveen el beneficio de la reutilización. Los programadores de software utilizan la misma
clase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos.

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

1.5.    Herencia
Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La
herencia es un mecanismo poderoso con el cual se puede definir una clase en términos de otra
clase; lo que significa que cuando se escribe una clase, sólo se tiene que especificar la
diferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a la
información contenida en esa otra clase.

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

Las subclases heredan todos los métodos y variables de las superclases. Es decir, en alguna
clase, si la superclase define un comportamiento que la clase hija necesita, no se tendrá que
redefinir o copiar ese código de la clase padre (figura 2).



                                                Superclase
                                              AtributoComun1
                                              AtributoComun2

                                              MetodoGeneral1()
                                              MetodoGeneral2()




                    Subclase 1                   Subclase 2            Subclase 3
                 AtributoParticularA          AtributoParticularB   AtributoParticularC

                 MetodoEspecialA()            MetodoEspecialB()     MetodoEspecialC()



                                       Figura 2: Jerarquía de Clases

Universidad ESAN – Maestría en Dirección de Tecnologías de Información                               6 / 20
Object Oriented y UML                                                                               Estanislao Contreras Chávez



De esta manera, se puede pensar en una jerarquía de clase como la definición de conceptos
demasiado abstractos en lo alto de la jerarquía y esas ideas se convierten en algo más
concreto conforme se desciende por la cadena de la superclase.

Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sus
superclases; pueden agregar variables y métodos además de los que ya heredan de sus clases
padres. Las clases hijas pueden, también, sobrescribir los métodos que heredan por
implementaciones especializadas para esos métodos (figura 3). De igual manera, no hay
limitación a un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que se
puede heredar varios niveles hacia abajo y mientras más niveles descienda una clase, más
especializada será su conducta.


                                                                 Superclase
                                                    AtributoComun1
                                                    AtributoComun2

                                                    MetodoGeneral1()
                                                    MetodoGeneral2()
                                                    <<virtual>> MetodoRedefinible()




                    Subclase 1                                   Subclase 2                                 Subclase 3
        AtributoParticularA                        AtributoParticularB                       AtributoParticularC

        MetodoEspecialA()                          MetodoEspecialB()                         MetodoEspecialC()
        <<override>> MetodoRedefinible()           <<override>> MetodoRedefinible()          <<override>> MetodoRedefinible()




                                        Subclase 2A                                   Subclase 2B

                              <<override>> MetodoRedefinible()           <<override>> MetodoRedefinible()




                    Figura 3: Sobrescritura de métodos en una jerarquía de clases

La herencia presenta los siguientes beneficios:

    •     Las subclases proveen conductas especializadas sobre la base de elementos comunes
          provistos por la superclase. A través del uso de herencia, los programadores pueden
          reutilizar el código de la superclase muchas veces.

    •     Los programadores pueden implementar superclases llamadas clases abstractas que
          definen conductas "genéricas". Las superclases abstractas definen, y pueden
          implementar parcialmente, la conducta pero gran parte de la clase no está definida ni
          implementada. Otros programadores concluirán esos detalles con subclases
          especializadas.

1.6.      Polimorfismo
En programación orientada a objetos se denomina polimorfismo a la capacidad que tienen
objetos de diferentes clases de responder al mismo mensaje.

Esto significa que puede haber muchos mensajes con el mismo nombre, en diferentes clases.
Cada Clase responde al mensaje con su código propio (o método). Justamente de ahí el
nombre de polimorfismo, muchas formas de responder al mismo mensaje.

También se puede aplicar a la propiedad que poseen algunas operaciones de tener un
comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican. El
polimorfismo sólo es aplicable si cualquiera de los posibles tipos de objetos que se invoquen



Universidad ESAN – Maestría en Dirección de Tecnologías de Información                                                          7 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


tienen definida la operación empleada, y los tipos de datos de entrada requeridos y los valores
devueltos, más allá de cómo se empleen o calculen, son compatibles entre sí.

El concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Así
nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas
funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta;
los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un
elemento cuyo tipo no está especificado.


1.7.    Ventajas de la metodología orientada a objetos
En síntesis, algunas ventajas que presenta son:

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

    •   Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables,
        de la misma manera que los microprocesadores y otros chips se hacen estables.

    •   El diseñador piensa en términos del comportamiento de objetos y no en detalles de
        bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean
        fáciles de utilizar. De la misma manera hace que el desarrollo del software sea mas
        intuitivo porque la gente piensa naturalmente en términos de objetos más que en
        términos de algoritmos de software.

    •   Se construyen clases cada vez más complejas. Se construyen clases a partir de otras
        clases, las cuales a su vez se integran mediante clases. Esto permite construir
        componentes de software complejos, que a su vez se convierten en bloques de
        construcción de software más complejo.

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

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

    •   Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos
        específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los
        sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al
        sistema.

    •   Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un
        método de clase a la vez. Cada clase efectúa sus funciones independientemente de las
        demás.

    •   Independencia del diseño. Las clases están diseñadas para ser independientes del
        ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con
        formato estándar. Esto les permite ser utilizadas en múltiples sistemas operativos,
        controladores de bases de datos, controladores de red, interfaces de usuario gráficas,
        etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que
        éste se especifique.

    •   Interacción. El software de varios proveedores puede funcionar como conjunto. Un
        proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e
        interactuar con ellas. El software desarrollado de manera independiente en lugares

Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             8 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


        ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante
        el usuario.

    •   Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el
        software cliente deben enviar solicitudes a las clases en el software servidor y recibir
        respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos
        clientes sólo pueden tener acceso a los datos del servidor a través de los métodos de
        la clase. Por lo tanto los datos están protegidos contra su corrupción.

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

    •   Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los
        objetos) en las bases de datos orientadas a objetos están ligadas a métodos que llevan
        a cabo acciones automáticas. Una base de datos OO tiene integrada una inteligencia,
        en forma de métodos, en tanto que una base de datos relacional básica carece de ello.

    •   Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden
        preservarse si se ajustan a un contenedor orientado a objetos, de modo que la
        comunicación con ella sea a través de mensajes estándar orientados a objetos.

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




1.8.    Problemas derivados de la utilización de la orientación a objetos
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin
embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los
beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego
comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los
programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:

    •   Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una
        forma única. Involucra la conceptualización de todos los elementos de un programa,
        desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los
        objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están
        escritos los programas orientados a objetos actualmente; al hacer la transición a un
        sistema orientado a objetos la mayoría de los programadores deben capacitarse
        nuevamente antes de poder usarlo.

    •   Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos
        objetos. En consecuencia es importante crear el conjunto de clases adecuado para un
        proyecto. Desafortunadamente la definición de las clases es más un arte que una
        ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben
        crear clases específicas para la aplicación que se este desarrollando. Luego, se da
        cuenta que las clases que se establecieron no son posibles; en ese caso será


Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             9 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


        necesario reestructurar la jerarquía de clases devastando totalmente la planificación
        original.

    •   Performance. En un sistema donde todo es un objeto y toda interacción es a través de
        mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología
        avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria
        aumentan, la situación mejorará; pero en la situación actual, un diseño de una
        aplicación orientada a objetos que no tiene en cuenta la performance no será viable
        comercialmente.


1.9.    El estado actual de la OO
En cuanto a tendencias, hay que separar claramente dos aspectos: tendencias en cuanto a
métodos para el desarrollo y gestión, que ayudan en la concepción, diseño, codificación
y pruebas así como la gestión de un sistema OO (Orientación a Objetos); y tendencias en
cuanto a la tecnología o infraestructura de desarrollo y explotación propiamente dicha.

Procesos de desarrollo y gestión

Como consecuencia del nacimiento de los primeros lenguajes de programación OO así como
de la complejidad creciente de las aplicaciones, comienzan a surgir, en la década de los 80, los
primeros métodos de análisis y diseño OO. Surgen así diversas metodologías, entre las que
podemos destacar el método de Booch (centrado en las etapas de diseño y construcción),
OOSE de Jacobson (que proporcionaba un buen soporte para los casos de uso) y OMT de
Rumbaugh (más enfocada al análisis de sistemas de información con grandes volúmenes de
datos). Estos tres autores se unieron para definir UML, Lenguaje de Modelado Unificado, un
conjunto de técnicas y un lenguaje de definición para el modelado de sistemas OO.

Sin embargo, y pese a toda la funcionalidad que parece poseer UML y de la clara aceptación
que ha tenido en el mercado, existen otras propuestas relevantes como OPEN (Henderson-
Sellers), Catalysis (D’Souza y Cameron) para el desarrollo basado en componentes y
frameworks con UML, o OHDM (Schawe y Rossi), para el desarrollo OO en Web.

Tecnología

Llamamos tecnología a la infraestructura que nos permite desarrollar sistemas OO: middleware,
Sistemas de Gestión de Bases de Datos (SGBD), Lenguajes de Programación (LP), etc.

    •   En cuanto a middleware, CORBA, DCOM y .NET Remoting son la solución para
        arquitecturas distribuidas. Además, se seguirá evolucionando y mejorando los
        rendimientos y dando soporte a aspectos tales como mejoras en la seguridad,
        tolerancia a fallos, manejo de transacciones, etc.
    •   Actualmente, los Sistemas de Gestión de Bases de Objetos (SGBO), no tienen la
        madurez suficiente para soportar aplicaciones con grandes volúmenes de datos que
        requieren rápidos tiempos de respuesta. Para este tipo de aplicaciones se utilizarán las
        nuevas versiones de los productos objeto-relacionales (p.e. Oracle, Informix).
    •   En cuanto a los lenguajes de programación, se puede pronosticar, una mayor
        utilización de Java y los lenguajes de la plataforma .NET para sistemas de todo
        propósito, así como a un retroceso del C++ que quedaría más para software de
        sistemas y menos para sistemas de gestión.


1.10. Predicciones del futuro cercano de la OO

    •   Ampliación del estándar de UML para el modelado de nuevas aplicaciones (web, wap,
        etc.) así como para el desarrollo basado en componentes y servicios.
    •   Desaparición casi total de C++ para sistemas de gestión a favor de una mayor
        utilización de Java y los lenguajes .NET.


Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             10 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


    •   Las BD reducirán sus funcionalidades, ocupándose casi exclusivamente de la
        persistencia de objetos y de un modo totalmente transparente.
    •   Serán más habituales los entornos de desarrollo basados en componentes que
        permitirán construir sistemas «prefabricados».
    •   Cibertiendas de aplicaciones “hágalo usted mismo”, donde el usuario, por menor costo,
        se lleva a casa un sistema desmontado que el mismo tendrá que componer.
    •   Conexión de objetos físicos a la red, que permitirán, por ejemplo, poner a calentar la
        comida antes de salir del trabajo, o leer el contador de la luz desde un teléfono móvil.
        La evolución de los dispositivos electrónicos tiende a que cada uno de ellos lleve un
        pequeño ordenador que se pueda conectar a una red de datos, publicando sus
        servicios. En esta situación será posible que cada dispositivo electrónico (doméstico o
        industrial) se presente como un objeto distribuido, en una aplicación central que
        permitiría que interactuaran entre sí.


2. UML

2.1.    La importancia del Modelado
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que
describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de
desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los
diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos
requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad.
Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales
describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño
tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y
más complejo es el sistema, más importante es el papel de que juega el modelado por una
simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos
en su totalidad".

Un modelo proporciona “los planos” de un sistema y puede ser más o menos detallado, en
función de los elementos que sean relevantes en cada momento.

Todo sistema puede describirse desde distintos punto de vista:
   • Modelos estructurales (organización del sistema)
   • Modelos de comportamiento (dinámica del sistema)

El modelo es esencial en la construcción de software para:
    • Comunica la estructura de un sistema complejo
    • Especificar el comportamiento deseado del sistema
    • Comprender mejor lo que estamos construyendo
    • Descubrir oportunidades de simplificación y reutilización

2.2.    El Lenguaje Unificado de Modelado UML

2.2.1 Historia de UML
Desde los inicios de la informática se han estado utilizando distintas formas de representar los
modelos de una forma más bien personal o con algún diseño gráfico. La falta de
estandarización en la manera de representar gráficamente un modelo impedía que los diseños
gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores.

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores
sino también para servir de apoyo en los procesos de análisis de un problema. Con este
objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML


Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             11 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


se ha convertido en ese estándar tan ansiado para representar y modelar la información con la
que se trabaja en las fases de análisis y, especialmente, de diseño.

UML es una técnica para la especificación sistemas en todas sus fases. El lenguaje UML
comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational
fundada por Booch (dos reputados investiga-dores en el área de metodología del software). El
ob-jetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el
OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma
época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas.
Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la
colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones
condujeron a la definición de la primera versión de UML.




                                  Figura 4: Evolución del UML

La versión actual de UML (principios de 2007) es la versión 2.1.1. UML 2.1.1 consiste en dos
porciones, infraestructuras y superestructuras; se asocian a éstos las especificaciones del
lenguaje de restricciones de objetos (Object Constraint Language OCL) y del diagrama de
intercambios.

2.2.2 Modelado Visual
Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación
de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del
sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación
gráfica. Esto se conoce como modelado visual.

El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la
misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir
un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos
que el ser humano pueda entender.

UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los
sistemas software como para la arquitectura hardware donde se ejecuten.

Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             12 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez




Otro objetivo de este modelado visual es que sea independiente del lenguaje de
implementación, de tal forma que los diseños realizados usando UML se pueda implementar en
cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a
objetos).

UML es además un método formal de modelado. Esto aporta las siguientes ventajas:
  • Mayor rigor en la especificación.
  • Permite realizar una verificación y validación del modelo realizado.
  • Se pueden automatizar determinados procesos y permite generar código a partir de los
       modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite
       que el modelo y el código estén actualizados, con lo que siempre se puede mantener la
       visión en el diseño, de más alto nivel, de la estructura de un proyecto.

El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o
menor medida todas las fases de un proyecto informático: desde el análisis con los casos de
uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y
configuración con los diagramas de despliegue.

2.2.3 ¿Qué es UML?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y
diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un
método es una manera explícita de estructurar el pensamiento y las acciones de cada
individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por
qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos
contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados
del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de
vistas, diagramas, elementos de modelo  los símbolos utilizados en los modelos  y un
conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas
son sintácticas, semánticas y pragmáticas (figura 5).




                              Figura 5: Lenguaje de modelo UML

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una
gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos
diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el
lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes
vistas que UML tiene son:

    •   Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben
        los actores externos.

    •   Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos
        de la estructura estática y la conducta dinámica del sistema.


Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             13 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


    •    Vista de Componentes: Muestra la organización de los componentes de código.

    •    Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas
         con la comunicación y sincronización que están presentes en un sistema concurrente.

    •    Vista de Distribución: muestra la distribución del sistema en la arquitectura física con
         computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene
nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de
un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de
colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los
elementos de modelo que representan conceptos comunes orientados a objetos, tales como
clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación,
dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas
diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica
acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o
extender UML a un método o proceso específico, organización o usuario.

2.2.4 Las fases del desarrollo de sistemas que soporta UML
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis,
Diseño, Programación y Pruebas.

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del
modelado de casos de uso, los actores externos que tienen interés en el sistema son
modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores
y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son
divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case.
Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella)
espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de
requerimientos puede ser realizado también para procesos de negocios, no solamente para
sistemas de software.

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que
están presentes en el dominio del problema. Las clases que se modelan son identificadas, con
sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para
ejecutar los casos de uso también se consideran en esta fase a través de los modelos
dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio
del problema (conceptos del mundo real) y todavía no se consideran clases que definen
detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario,
bases de datos, comunicaciones, concurrencia, etc.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan
nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de
bases de datos para almacenar objetos en una base de datos, comunicaciones con otros
sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El
diseño resulta en especificaciones detalladas para la fase de programación.



Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             14 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación
orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más
aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas
de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases
individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las
pruebas de integración integran componentes y clases en orden para verificar que se ejecutan
como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan
que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de
aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son
similares a las pruebas de sistema.

2.2.5 Objetivos de UML
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

    •   Visualizar: UML permite expresar de una for-ma gráfica un sistema de forma que otro lo
        puede entender.
    •   Especificar: UML permite especificar cuáles son las características de un sistema antes
        de su construcción.
    •   Construir: A partir de los modelos especifica-dos se pueden construir los sistemas
        diseñados.
    •   Documentar: Los propios elementos gráficos sirven como documentación del sistema
        des-arrollado que pueden servir para su futura re-visión.


2.2.6 Beneficios de 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.


2.3.    Diagramas de UML
Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En
concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar
correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el
sistema desde varias perspectivas. UML incluye los siguientes diagramas:

    •   Diagrama de casos de uso.
    •   Diagrama de clases.
    •   Diagrama de objetos.
    •   Diagrama de secuencia.
    •   Diagrama de colaboración.
    •   Diagrama de estados.
    •   Diagrama de actividades.
    •   Diagrama de componentes.
    •   Diagrama de despliegue.


Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             15 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez


Los diagramas más interesantes (y los más usados) son los de casos de uso, clases y
secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejemplos de un sistema
de venta de entradas de cine por Internet.

El diagrama de casos de usos representa gráficamente los casos de uso que tiene un
sistema. Se define un caso de uso como cada interacción supuesta con el sistema a
desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que
tiene que hacer un sistema y cómo. En la figura 6 se muestra un ejemplo de casos de uso,
donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y las
operaciones que pueden realizar (sus roles).




                             Figura 6: Diagrama de Casos de Uso

El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el
diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En
la figura 7 se muestran las clases globales, sus atributos y las relaciones de una posible
solución al problema de la venta de entradas.




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             16 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez




                                 Figura 7: Diagrama de Clases

En el diagrama de secuencia se muestra la interacción de los objetos que componen un
sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 8 muestra la
interacción de crear una nueva sala para un espectáculo.




                               Figura 8: Diagrama de Secuencia



Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             17 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez



El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el
comportamiento dinámico del sistema están los de interacción, colaboración, estados y
actividades. Los diagramas de componentes y despliegue están enfocados a la
implementación del sistema.

2.4.    Proceso de Desarrollo
Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga, los mismos
creadores de UML han propuesto su propia metodología de desarrollo, denominada el Proceso
Unificado de Desarrollo.

El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software
en construcción está formado por componentes software interconectados a través de interfaces
bien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos
los esquemas de un sistema software. Pero, realmente, los aspectos que definen este Proceso
Unificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado en la
arquitectura.

Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores crean una
serie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos se
vali-dan para que sean conformes a los casos de uso. Finalmente, los casos de uso también
sir-ven para realizar las pruebas sobre los componentes desarrollados.

Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir un
edificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas,
fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notación
correspondiente. Siguiendo este ejemplo, el concepto de arquitectura software incluye los
aspectos estáticos y dinámicos más significativos del sistema.

Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo que
puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto
en varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan varios
recorridos por todas las fases. Cada recorrido por las fases se denomina iteración en el
proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cada
iteración parte de la anterior incrementado o revisando la funcionalidad implementada. Se suele
denominar proceso. (Ver figura 9).




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             18 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez




                           Figura 9: Proceso Iterativo e Incremental




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             19 / 20
Object Oriented y UML                                                    Estanislao Contreras Chávez




Referencias

    •   G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado", Addison
        Wesley, 1999
    •   Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo", Addision
        Wesley, 2000
    •   Martin Fowler: “UML Distilled”, Addison Wesley, 2004.
    •   Pagina oficial de UML. www.uml.org
    •   Wikipedia. www.wikipedia.org




Universidad ESAN – Maestría en Dirección de Tecnologías de Información                             20 / 20

Mais conteúdo relacionado

Mais procurados (18)

IntroduccióN Uml
IntroduccióN UmlIntroduccióN Uml
IntroduccióN Uml
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Curso
CursoCurso
Curso
 
investigacion uml
investigacion umlinvestigacion uml
investigacion uml
 
Uml java
Uml javaUml java
Uml java
 
Historia uml
Historia umlHistoria uml
Historia uml
 
Nesii
NesiiNesii
Nesii
 
Introduccion uml
Introduccion umlIntroduccion uml
Introduccion uml
 
Introducción a UML
Introducción a UMLIntroducción a UML
Introducción a UML
 
Lenguaje de modelo de objetos
Lenguaje de modelo de objetosLenguaje de modelo de objetos
Lenguaje de modelo de objetos
 
Uml
UmlUml
Uml
 
Perfiles UML - Jénifer Quintero
Perfiles UML - Jénifer QuinteroPerfiles UML - Jénifer Quintero
Perfiles UML - Jénifer Quintero
 
Diagrama uml ing software i promecys
Diagrama uml ing software i promecysDiagrama uml ing software i promecys
Diagrama uml ing software i promecys
 
Uml (lenguaje unificado de modelado)
Uml (lenguaje unificado de modelado)Uml (lenguaje unificado de modelado)
Uml (lenguaje unificado de modelado)
 
Objeto de Aprendizaje : Introducción a UML
Objeto de Aprendizaje : Introducción a UMLObjeto de Aprendizaje : Introducción a UML
Objeto de Aprendizaje : Introducción a UML
 
Patrones de diseño
Patrones de diseñoPatrones de diseño
Patrones de diseño
 
Presentacion uml dian1_2003
Presentacion uml dian1_2003Presentacion uml dian1_2003
Presentacion uml dian1_2003
 
Introduccion a UML
Introduccion a UMLIntroduccion a UML
Introduccion a UML
 

Destaque

Estudio Real Decreto Ley 3/ 2012
Estudio Real Decreto Ley 3/ 2012Estudio Real Decreto Ley 3/ 2012
Estudio Real Decreto Ley 3/ 2012mujerpcenavarra
 
ACIDOS NUCLEICOS
ACIDOS NUCLEICOSACIDOS NUCLEICOS
ACIDOS NUCLEICOSdianiizzta
 
4 geomorfologia
4 geomorfologia4 geomorfologia
4 geomorfologianuevvo
 
Material dispensação de produtos controlados- versão 2
Material dispensação de produtos controlados- versão 2Material dispensação de produtos controlados- versão 2
Material dispensação de produtos controlados- versão 2marinezesper
 
Lazaro Cardenas Mich Aduanas
Lazaro Cardenas Mich Aduanas Lazaro Cardenas Mich Aduanas
Lazaro Cardenas Mich Aduanas Saaúl Meriino
 
Trabajo de investigación i
Trabajo de investigación iTrabajo de investigación i
Trabajo de investigación iSangynary Xtrem
 
The Role of Biotechnology in our Food Supply (French)
The Role of Biotechnology in our Food Supply (French)The Role of Biotechnology in our Food Supply (French)
The Role of Biotechnology in our Food Supply (French)Food Insight
 
21010100901 taller cross docking
21010100901 taller cross docking21010100901 taller cross docking
21010100901 taller cross dockingleidy95c
 
Cuestionario Casa de Bernarda Alba ilustrado
Cuestionario Casa de Bernarda Alba ilustradoCuestionario Casa de Bernarda Alba ilustrado
Cuestionario Casa de Bernarda Alba ilustradoLITESUN
 
Derecho valides de acto juridivco tarea
Derecho valides de acto juridivco tareaDerecho valides de acto juridivco tarea
Derecho valides de acto juridivco tareaDavidd Reos
 
Formulaire de beton_arme
Formulaire de beton_armeFormulaire de beton_arme
Formulaire de beton_armeZahir Hadji
 
Unidad 2 Circulacion Estructuras
Unidad 2 Circulacion EstructurasUnidad 2 Circulacion Estructuras
Unidad 2 Circulacion EstructurasLeonardo Hernandez
 
Fisica rec
Fisica recFisica rec
Fisica recJulio
 
Formulacion de proyectos
Formulacion de proyectosFormulacion de proyectos
Formulacion de proyectosformulacion
 
Prueba de hipótesis
Prueba de hipótesisPrueba de hipótesis
Prueba de hipótesisvaro99
 

Destaque (20)

Estudio Real Decreto Ley 3/ 2012
Estudio Real Decreto Ley 3/ 2012Estudio Real Decreto Ley 3/ 2012
Estudio Real Decreto Ley 3/ 2012
 
ACIDOS NUCLEICOS
ACIDOS NUCLEICOSACIDOS NUCLEICOS
ACIDOS NUCLEICOS
 
Gènero Musical (Rap)
Gènero Musical (Rap)Gènero Musical (Rap)
Gènero Musical (Rap)
 
Sensores analogicos
Sensores analogicosSensores analogicos
Sensores analogicos
 
4 geomorfologia
4 geomorfologia4 geomorfologia
4 geomorfologia
 
Material dispensação de produtos controlados- versão 2
Material dispensação de produtos controlados- versão 2Material dispensação de produtos controlados- versão 2
Material dispensação de produtos controlados- versão 2
 
Lazaro Cardenas Mich Aduanas
Lazaro Cardenas Mich Aduanas Lazaro Cardenas Mich Aduanas
Lazaro Cardenas Mich Aduanas
 
Trabajo de investigación i
Trabajo de investigación iTrabajo de investigación i
Trabajo de investigación i
 
The Role of Biotechnology in our Food Supply (French)
The Role of Biotechnology in our Food Supply (French)The Role of Biotechnology in our Food Supply (French)
The Role of Biotechnology in our Food Supply (French)
 
21010100901 taller cross docking
21010100901 taller cross docking21010100901 taller cross docking
21010100901 taller cross docking
 
Cuestionario Casa de Bernarda Alba ilustrado
Cuestionario Casa de Bernarda Alba ilustradoCuestionario Casa de Bernarda Alba ilustrado
Cuestionario Casa de Bernarda Alba ilustrado
 
Derecho valides de acto juridivco tarea
Derecho valides de acto juridivco tareaDerecho valides de acto juridivco tarea
Derecho valides de acto juridivco tarea
 
Formulaire de beton_arme
Formulaire de beton_armeFormulaire de beton_arme
Formulaire de beton_arme
 
Unidad 2 Circulacion Estructuras
Unidad 2 Circulacion EstructurasUnidad 2 Circulacion Estructuras
Unidad 2 Circulacion Estructuras
 
ONTSI 2011
ONTSI 2011ONTSI 2011
ONTSI 2011
 
Accounting concept
Accounting conceptAccounting concept
Accounting concept
 
Fisica rec
Fisica recFisica rec
Fisica rec
 
Gestión del tiempo
Gestión del tiempoGestión del tiempo
Gestión del tiempo
 
Formulacion de proyectos
Formulacion de proyectosFormulacion de proyectos
Formulacion de proyectos
 
Prueba de hipótesis
Prueba de hipótesisPrueba de hipótesis
Prueba de hipótesis
 

Semelhante a Estanislao contreras object-oriented_y_uml

Semelhante a Estanislao contreras object-oriented_y_uml (20)

Modelado Unificado (UML)
Modelado Unificado (UML)Modelado Unificado (UML)
Modelado Unificado (UML)
 
Diseño+de..
Diseño+de..Diseño+de..
Diseño+de..
 
Guia Yahveh
Guia YahvehGuia Yahveh
Guia Yahveh
 
UML - Lenguaje de Modelamiento Unificado
UML - Lenguaje de Modelamiento UnificadoUML - Lenguaje de Modelamiento Unificado
UML - Lenguaje de Modelamiento Unificado
 
Presentacion de-uml-formato-2-1227891304393749-8
Presentacion de-uml-formato-2-1227891304393749-8Presentacion de-uml-formato-2-1227891304393749-8
Presentacion de-uml-formato-2-1227891304393749-8
 
Presentación2
Presentación2Presentación2
Presentación2
 
Presentación2
Presentación2Presentación2
Presentación2
 
Trabajo analisis y diseño de sistemas
Trabajo analisis y diseño de sistemasTrabajo analisis y diseño de sistemas
Trabajo analisis y diseño de sistemas
 
Analisis Y DiseñO Orientado Objetos
Analisis Y DiseñO Orientado ObjetosAnalisis Y DiseñO Orientado Objetos
Analisis Y DiseñO Orientado Objetos
 
Presentación poo
Presentación pooPresentación poo
Presentación poo
 
Uml
UmlUml
Uml
 
Tema 2.UML parte 1.ppt
Tema 2.UML parte 1.pptTema 2.UML parte 1.ppt
Tema 2.UML parte 1.ppt
 
Deber analisis
Deber analisisDeber analisis
Deber analisis
 
UML Java
UML JavaUML Java
UML Java
 
Uml java
Uml javaUml java
Uml java
 
Diagramas de clases y aplicaciones JAVA en NetBeans 6.9.1
Diagramas de clases y aplicaciones  JAVA en NetBeans 6.9.1Diagramas de clases y aplicaciones  JAVA en NetBeans 6.9.1
Diagramas de clases y aplicaciones JAVA en NetBeans 6.9.1
 
Lenguaje unificado
Lenguaje unificadoLenguaje unificado
Lenguaje unificado
 
Uml
UmlUml
Uml
 
Uml
UmlUml
Uml
 
Metodologias para el desarrollo de aplicacones web
Metodologias para el desarrollo de aplicacones webMetodologias para el desarrollo de aplicacones web
Metodologias para el desarrollo de aplicacones web
 

Mais de pierre R.

Gestión de calidad
Gestión de calidadGestión de calidad
Gestión de calidadpierre R.
 
Creatividad y liderazgo
Creatividad y liderazgoCreatividad y liderazgo
Creatividad y liderazgopierre R.
 
Manual de generacion de documento de diagnóstico y mejora de procesos
Manual de generacion de documento de diagnóstico y mejora de procesosManual de generacion de documento de diagnóstico y mejora de procesos
Manual de generacion de documento de diagnóstico y mejora de procesospierre R.
 
Formato de caracterización del proceso
Formato de caracterización del procesoFormato de caracterización del proceso
Formato de caracterización del procesopierre R.
 
Constitución del proyecto
Constitución del proyectoConstitución del proyecto
Constitución del proyectopierre R.
 
Alcance del proyecto
Alcance del proyectoAlcance del proyecto
Alcance del proyectopierre R.
 
Plan de gestion de proyecto
Plan de gestion de proyectoPlan de gestion de proyecto
Plan de gestion de proyectopierre R.
 
guía de proyecto
guía de proyectoguía de proyecto
guía de proyectopierre R.
 
Arquitectura del sistema
Arquitectura del sistemaArquitectura del sistema
Arquitectura del sistemapierre R.
 
Reglas del negocio
Reglas del negocioReglas del negocio
Reglas del negociopierre R.
 
Manual técnico
Manual técnicoManual técnico
Manual técnicopierre R.
 
Manual de usuario
Manual de usuarioManual de usuario
Manual de usuariopierre R.
 
L5 -caso_bsc
L5  -caso_bscL5  -caso_bsc
L5 -caso_bscpierre R.
 
Trabajo final
Trabajo finalTrabajo final
Trabajo finalpierre R.
 
Aprendiendo java
Aprendiendo javaAprendiendo java
Aprendiendo javapierre R.
 
Administración 2
Administración 2Administración 2
Administración 2pierre R.
 
Manual de control de inventario
Manual de control de inventarioManual de control de inventario
Manual de control de inventariopierre R.
 
Reingenieria
ReingenieriaReingenieria
Reingenieriapierre R.
 

Mais de pierre R. (20)

Gestión de calidad
Gestión de calidadGestión de calidad
Gestión de calidad
 
Motivacion
MotivacionMotivacion
Motivacion
 
Creatividad y liderazgo
Creatividad y liderazgoCreatividad y liderazgo
Creatividad y liderazgo
 
Manual de generacion de documento de diagnóstico y mejora de procesos
Manual de generacion de documento de diagnóstico y mejora de procesosManual de generacion de documento de diagnóstico y mejora de procesos
Manual de generacion de documento de diagnóstico y mejora de procesos
 
Formato de caracterización del proceso
Formato de caracterización del procesoFormato de caracterización del proceso
Formato de caracterización del proceso
 
Constitución del proyecto
Constitución del proyectoConstitución del proyecto
Constitución del proyecto
 
Alcance del proyecto
Alcance del proyectoAlcance del proyecto
Alcance del proyecto
 
Plan de gestion de proyecto
Plan de gestion de proyectoPlan de gestion de proyecto
Plan de gestion de proyecto
 
guía de proyecto
guía de proyectoguía de proyecto
guía de proyecto
 
Arquitectura del sistema
Arquitectura del sistemaArquitectura del sistema
Arquitectura del sistema
 
glosario
glosarioglosario
glosario
 
Reglas del negocio
Reglas del negocioReglas del negocio
Reglas del negocio
 
Manual técnico
Manual técnicoManual técnico
Manual técnico
 
Manual de usuario
Manual de usuarioManual de usuario
Manual de usuario
 
L5 -caso_bsc
L5  -caso_bscL5  -caso_bsc
L5 -caso_bsc
 
Trabajo final
Trabajo finalTrabajo final
Trabajo final
 
Aprendiendo java
Aprendiendo javaAprendiendo java
Aprendiendo java
 
Administración 2
Administración 2Administración 2
Administración 2
 
Manual de control de inventario
Manual de control de inventarioManual de control de inventario
Manual de control de inventario
 
Reingenieria
ReingenieriaReingenieria
Reingenieria
 

Estanislao contreras object-oriented_y_uml

  • 1. Universidad INGENIERÍA DE SOFTWARE Object Oriented y UML ELABORADO POR: Contreras Chávez, Estanislao madti0112@esan.edu.pe Abril 2007 Lima - Perú
  • 2. Object Oriented y UML Estanislao Contreras Chávez Índice Introducción ................................................................................................................................... 3 1. Object Oriented ............................................................................................................ 4 1.1. Paradigma Orientado a Objetos .............................................................................. 4 1.2. Clases y Objetos...................................................................................................... 4 1.3. Atributos y Métodos ................................................................................................. 5 1.4. Encapsulamiento ..................................................................................................... 5 1.5. Herencia................................................................................................................... 6 1.6. Polimorfismo ............................................................................................................ 7 1.7. Ventajas de la metodología orientada a objetos ..................................................... 8 1.8. Problemas derivados de la utilización de la orientación a objetos .......................... 9 1.9. El estado actual de la OO...................................................................................... 10 1.10. Predicciones del futuro cercano de la OO............................................................. 10 2. UML............................................................................................................................ 11 2.1. La importancia del Modelado................................................................................. 11 2.2. El Lenguaje Unificado de Modelado UML ............................................................. 11 2.2.1 Historia de UML................................................................................................. 11 2.2.2 Modelado Visual ................................................................................................ 12 2.2.3 ¿Qué es UML? .................................................................................................. 13 2.2.4 Las fases del desarrollo de sistemas que soporta UML ................................... 14 2.2.5 Objetivos de UML .............................................................................................. 15 2.2.6 Beneficios de UML ............................................................................................ 15 2.3. Diagramas de UML................................................................................................ 15 2.4. Proceso de Desarrollo ........................................................................................... 18 Referencias .............................................................................................................................. 20 Universidad ESAN – Maestría en Dirección de Tecnologías de Información 2 / 20
  • 3. Object Oriented y UML Estanislao Contreras Chávez Introducción Desde el nacimiento de los primeros lenguajes de programación orientados a objetos, en la década de los 60, la Tecnología de Objetos (TO) se ha presentado como la solución a muchos de los problemas del desarrollo de software, consolidándose, en la década de los 90, como el paradigma de desarrollo para sistemas de complejidad media o alta (aplicaciones CAD/CAM, multimedia, aplicaciones distribuidas, etc.). Además, proporciona otra serie de ventajas como facilitar la reutilización de código o permitir obtener aplicaciones más fácilmente escalables. En la actualidad, y especialmente desde la aparición de Java y .NET, la TO parece ser también la que mejor se adapta a los nuevos tipos de desarrollos hipermedia y Web. Hablar de TO lleva consigo la necesidad de hablar de objetos, de componentes, de patrones, de lenguajes, de frameworks, de arquitecturas, de persistencia, etc. Por otra parte, la TO hoy pasa por la integración de cada una de las técnicas y herramientas de desarrollo, tanto de análisis y diseño, como de programación, persistencia o distribución. Cada una de estas palabras clave, así como la problemática de la integración de las mismas, constituye un área de interés que podría, sin duda alguna, dar lugar a un trabajo como éste. Por ello, no pretendemos profundizar en ninguna de estas áreas sino, más bien, ofrecer una visión general de la TO en la actualidad así como de lo que, en nuestra opinión y haciendo una arriesgada previsión de futuro, constituyen las principales tendencias de la misma. Tras la aceptación del paradigma orientado a objetos (OO) como el más adecuado para producir software de calidad, a principios de los noventa emergieron un buen número de métodos de desarrollo de software OO. En 1993, Jacobson criticó en lo que el denominaba guerra de métodos y planteo la necesidad de llegar a una notación estándar de modelado, para evitar la confusión reinante y favorecer el uso de los métodos de software OO. A finales de 1994 se inicio un esfuerzo unificación y es así como nace el Lenguaje Unificado de Modelamiento (UML Unified Modeling Language). UML ha ejercido un gran impacto en la comunidad software, tanto a nivel de desarrollo como de investigación y esas son las razones por la cual presentamos un estudio preciso acerca de UML para exponer sus principales características. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 3 / 20
  • 4. Object Oriented y UML Estanislao Contreras Chávez Revisión: 03 de abril de 2007 ESTANISLAO CONTRERAS Object Oriented y UML1 . 1. Object Oriented 1.1. Paradigma Orientado a Objetos El paradigma orientado a objetos ha derivado de los paradigmas anteriores a éste. Así como los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos. El modelo de objetos ha sido influenciado por un número de factores no sólo de la Programación Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglas en inglés). Además, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los lenguajes de programación sino también al diseño de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razón de ello es, simplemente, que una orientación a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas. Actualmente, el Análisis y Diseño Orientado a Objetos (ADOO) va progresando como método de análisis de requisitos por derecho propio y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante el modelo clásico de entrada-proceso-salida (flujo de información) o mediante un modelo derivado exclusivamente de estructuras jerárquicas de información, el ADOO introduce varios conceptos nuevos. Estos conceptos le parecen inusuales a mucha gente, pero son bastante naturales. 1.2. Clases y Objetos Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos". Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar en relación con otros objetos de manera apropiada a este objeto. Una clase es una plantilla para objetos múltiples con características similares. Las clases comprenden todas esas características de un conjunto particular de objetos. Cuando se escribe un programa en lenguaje orientado a objetos, no se definen objetos verdaderos sino se definen clases de objetos. 1 Este trabajo fue elaborado por el alumno Estanislao Contreras con la finalidad de mostrar los fundamentos de Object Oriented y UML. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 4 / 20
  • 5. Object Oriented y UML Estanislao Contreras Chávez Una instancia de una clase es otro término para un objeto real. Si la clase es la representación general de un objeto, una instancia es su representación concreta. A menudo se utiliza indistintamente la palabra objeto o instancia para referirse, precisamente, a un objeto. 1.3. Atributos y Métodos 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 (figura 1). Atributos y Detalles Métodos e de la Implementación Interface Interna Pública Figura 1: Representación de un objeto Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen una apariencia y un comportamiento igual al de las funciones en otros lenguajes de programación, los lenguajes estructurados, pero se definen dentro de una clase. Los métodos no siempre afectan a un solo objeto; los objetos también se comunican entre sí mediante el uso de métodos. Una clase u objeto puede llamar métodos en otra clase u objeto para avisar sobre los cambios en el ambiente o para solicitarle a ese objeto que cambie su estado. 1.4. Encapsulamiento Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Además, como se puede observar en la figura 1, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en una membrana protectora de métodos— es una representación ideal de un objeto y es el ideal por el que los diseñadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en práctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus métodos. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 5 / 20
  • 6. Object Oriented y UML Estanislao Contreras Chávez El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: • Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. • Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello. Los objetos proveen el beneficio de la modularidad y el ocultamiento de la información. Las clases proveen el beneficio de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo código, una y otra vez para crear muchos objetos. En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos que se pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es diferente: los atributos se relacionan al objeto o instancia y los métodos a la clase. ¿Por qué se hace así? Los atributos son variables comunes en cada objeto de una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al que tienen para esa misma variable los demás objetos. Los métodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilización de código. 1.5. Herencia Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La herencia es un mecanismo poderoso con el cual se puede definir una clase en términos de otra clase; lo que significa que cuando se escribe una clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a la información contenida en esa otra clase. Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clase tiene una superclase (la clase superior en la jerarquía) y puede tener una o más subclases (las clases que se encuentran debajo de esa clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases hijas, heredan de las clases más altas, las clases padres. Las subclases heredan todos los métodos y variables de las superclases. Es decir, en alguna clase, si la superclase define un comportamiento que la clase hija necesita, no se tendrá que redefinir o copiar ese código de la clase padre (figura 2). Superclase AtributoComun1 AtributoComun2 MetodoGeneral1() MetodoGeneral2() Subclase 1 Subclase 2 Subclase 3 AtributoParticularA AtributoParticularB AtributoParticularC MetodoEspecialA() MetodoEspecialB() MetodoEspecialC() Figura 2: Jerarquía de Clases Universidad ESAN – Maestría en Dirección de Tecnologías de Información 6 / 20
  • 7. Object Oriented y UML Estanislao Contreras Chávez De esta manera, se puede pensar en una jerarquía de clase como la definición de conceptos demasiado abstractos en lo alto de la jerarquía y esas ideas se convierten en algo más concreto conforme se desciende por la cadena de la superclase. Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sus superclases; pueden agregar variables y métodos además de los que ya heredan de sus clases padres. Las clases hijas pueden, también, sobrescribir los métodos que heredan por implementaciones especializadas para esos métodos (figura 3). De igual manera, no hay limitación a un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que se puede heredar varios niveles hacia abajo y mientras más niveles descienda una clase, más especializada será su conducta. Superclase AtributoComun1 AtributoComun2 MetodoGeneral1() MetodoGeneral2() <<virtual>> MetodoRedefinible() Subclase 1 Subclase 2 Subclase 3 AtributoParticularA AtributoParticularB AtributoParticularC MetodoEspecialA() MetodoEspecialB() MetodoEspecialC() <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() Subclase 2A Subclase 2B <<override>> MetodoRedefinible() <<override>> MetodoRedefinible() Figura 3: Sobrescritura de métodos en una jerarquía de clases La herencia presenta los siguientes beneficios: • Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A través del uso de herencia, los programadores pueden reutilizar el código de la superclase muchas veces. • Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genéricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no está definida ni implementada. Otros programadores concluirán esos detalles con subclases especializadas. 1.6. Polimorfismo En programación orientada a objetos se denomina polimorfismo a la capacidad que tienen objetos de diferentes clases de responder al mismo mensaje. Esto significa que puede haber muchos mensajes con el mismo nombre, en diferentes clases. Cada Clase responde al mensaje con su código propio (o método). Justamente de ahí el nombre de polimorfismo, muchas formas de responder al mismo mensaje. También se puede aplicar a la propiedad que poseen algunas operaciones de tener un comportamiento diferente dependiendo del objeto (o tipo de dato) sobre el que se aplican. El polimorfismo sólo es aplicable si cualquiera de los posibles tipos de objetos que se invoquen Universidad ESAN – Maestría en Dirección de Tecnologías de Información 7 / 20
  • 8. Object Oriented y UML Estanislao Contreras Chávez tienen definida la operación empleada, y los tipos de datos de entrada requeridos y los valores devueltos, más allá de cómo se empleen o calculen, son compatibles entre sí. El concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado. 1.7. Ventajas de la metodología orientada a objetos En síntesis, algunas ventajas que presenta son: • Reutilización. Las clases están diseñadas para que se reutilicen en muchos sistemas. Para maximizar la reutilización, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las técnicas orientadas a objetos es lograr la reutilización masiva al construir el software. • Estabilidad. Las clases diseñadas para una reutilización repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. • El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fáciles de utilizar. De la misma manera hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software. • Se construyen clases cada vez más complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construcción de software más complejo. • Calidad. Los diseños suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces. • Un diseño más rápido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes están construidos de modo que se pueden adaptar para un diseño particular. • Integridad. Las estructuras de datos (los objetos) sólo se pueden utilizar con métodos específicos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podrían intentar el acceso al sistema. • Mantenimiento más sencillo. El programador encargado del mantenimiento cambia un método de clase a la vez. Cada clase efectúa sus funciones independientemente de las demás. • Independencia del diseño. Las clases están diseñadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estándar. Esto les permite ser utilizadas en múltiples sistemas operativos, controladores de bases de datos, controladores de red, interfaces de usuario gráficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que éste se especifique. • Interacción. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estándar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente en lugares Universidad ESAN – Maestría en Dirección de Tecnologías de Información 8 / 20
  • 9. Object Oriented y UML Estanislao Contreras Chávez ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario. • Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos clientes sólo pueden tener acceso a los datos del servidor a través de los métodos de la clase. Por lo tanto los datos están protegidos contra su corrupción. • Computación de distribución masiva. Las redes a nivel mundial utilizarán directorios de software de objetos accesibles. El diseño orientado a objetos es la clave para la computación de distribución masiva. Las clases de una máquina interactúan con las de algún otro lugar sin saber donde residen tales clases. Ellas reciben y envían mensajes orientados a objetos en formato estándar. • Mayor nivel de automatización de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos están ligadas a métodos que llevan a cabo acciones automáticas. Una base de datos OO tiene integrada una inteligencia, en forma de métodos, en tanto que una base de datos relacional básica carece de ello. • Migración. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se ajustan a un contenedor orientado a objetos, de modo que la comunicación con ella sea a través de mensajes estándar orientados a objetos. • Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) utilizarán las técnicas gráficas para el diseño de las clases y de la interacción entre ellas, para el uso de los objetos existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado en términos de eventos, formas de activación, estados de objetos, etc. Las herramientas OO del CASE deben generar un código tan pronto se definan las clases y permitir al diseñador utilizar y probar los métodos recién creados. Las herramientas se deben diseñar de manera que apoyen el máximo de creatividad y una continua afinación del diseño durante la construcción. 1.8. Problemas derivados de la utilización de la orientación a objetos Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente: • Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo. • Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, se da cuenta que las clases que se establecieron no son posibles; en ese caso será Universidad ESAN – Maestría en Dirección de Tecnologías de Información 9 / 20
  • 10. Object Oriented y UML Estanislao Contreras Chávez necesario reestructurar la jerarquía de clases devastando totalmente la planificación original. • Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente. 1.9. El estado actual de la OO En cuanto a tendencias, hay que separar claramente dos aspectos: tendencias en cuanto a métodos para el desarrollo y gestión, que ayudan en la concepción, diseño, codificación y pruebas así como la gestión de un sistema OO (Orientación a Objetos); y tendencias en cuanto a la tecnología o infraestructura de desarrollo y explotación propiamente dicha. Procesos de desarrollo y gestión Como consecuencia del nacimiento de los primeros lenguajes de programación OO así como de la complejidad creciente de las aplicaciones, comienzan a surgir, en la década de los 80, los primeros métodos de análisis y diseño OO. Surgen así diversas metodologías, entre las que podemos destacar el método de Booch (centrado en las etapas de diseño y construcción), OOSE de Jacobson (que proporcionaba un buen soporte para los casos de uso) y OMT de Rumbaugh (más enfocada al análisis de sistemas de información con grandes volúmenes de datos). Estos tres autores se unieron para definir UML, Lenguaje de Modelado Unificado, un conjunto de técnicas y un lenguaje de definición para el modelado de sistemas OO. Sin embargo, y pese a toda la funcionalidad que parece poseer UML y de la clara aceptación que ha tenido en el mercado, existen otras propuestas relevantes como OPEN (Henderson- Sellers), Catalysis (D’Souza y Cameron) para el desarrollo basado en componentes y frameworks con UML, o OHDM (Schawe y Rossi), para el desarrollo OO en Web. Tecnología Llamamos tecnología a la infraestructura que nos permite desarrollar sistemas OO: middleware, Sistemas de Gestión de Bases de Datos (SGBD), Lenguajes de Programación (LP), etc. • En cuanto a middleware, CORBA, DCOM y .NET Remoting son la solución para arquitecturas distribuidas. Además, se seguirá evolucionando y mejorando los rendimientos y dando soporte a aspectos tales como mejoras en la seguridad, tolerancia a fallos, manejo de transacciones, etc. • Actualmente, los Sistemas de Gestión de Bases de Objetos (SGBO), no tienen la madurez suficiente para soportar aplicaciones con grandes volúmenes de datos que requieren rápidos tiempos de respuesta. Para este tipo de aplicaciones se utilizarán las nuevas versiones de los productos objeto-relacionales (p.e. Oracle, Informix). • En cuanto a los lenguajes de programación, se puede pronosticar, una mayor utilización de Java y los lenguajes de la plataforma .NET para sistemas de todo propósito, así como a un retroceso del C++ que quedaría más para software de sistemas y menos para sistemas de gestión. 1.10. Predicciones del futuro cercano de la OO • Ampliación del estándar de UML para el modelado de nuevas aplicaciones (web, wap, etc.) así como para el desarrollo basado en componentes y servicios. • Desaparición casi total de C++ para sistemas de gestión a favor de una mayor utilización de Java y los lenguajes .NET. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 10 / 20
  • 11. Object Oriented y UML Estanislao Contreras Chávez • Las BD reducirán sus funcionalidades, ocupándose casi exclusivamente de la persistencia de objetos y de un modo totalmente transparente. • Serán más habituales los entornos de desarrollo basados en componentes que permitirán construir sistemas «prefabricados». • Cibertiendas de aplicaciones “hágalo usted mismo”, donde el usuario, por menor costo, se lleva a casa un sistema desmontado que el mismo tendrá que componer. • Conexión de objetos físicos a la red, que permitirán, por ejemplo, poner a calentar la comida antes de salir del trabajo, o leer el contador de la luz desde un teléfono móvil. La evolución de los dispositivos electrónicos tiende a que cada uno de ellos lleve un pequeño ordenador que se pueda conectar a una red de datos, publicando sus servicios. En esta situación será posible que cada dispositivo electrónico (doméstico o industrial) se presente como un objeto distribuido, en una aplicación central que permitiría que interactuaran entre sí. 2. UML 2.1. La importancia del Modelado En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción. El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad". Un modelo proporciona “los planos” de un sistema y puede ser más o menos detallado, en función de los elementos que sean relevantes en cada momento. Todo sistema puede describirse desde distintos punto de vista: • Modelos estructurales (organización del sistema) • Modelos de comportamiento (dinámica del sistema) El modelo es esencial en la construcción de software para: • Comunica la estructura de un sistema complejo • Especificar el comportamiento deseado del sistema • Comprender mejor lo que estamos construyendo • Descubrir oportunidades de simplificación y reutilización 2.2. El Lenguaje Unificado de Modelado UML 2.2.1 Historia de UML Desde los inicios de la informática se han estado utilizando distintas formas de representar los modelos de una forma más bien personal o con algún diseño gráfico. La falta de estandarización en la manera de representar gráficamente un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores. Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML Universidad ESAN – Maestría en Dirección de Tecnologías de Información 11 / 20
  • 12. Object Oriented y UML Estanislao Contreras Chávez se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño. UML es una técnica para la especificación sistemas en todas sus fases. El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investiga-dores en el área de metodología del software). El ob-jetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML. Figura 4: Evolución del UML La versión actual de UML (principios de 2007) es la versión 2.1.1. UML 2.1.1 consiste en dos porciones, infraestructuras y superestructuras; se asocian a éstos las especificaciones del lenguaje de restricciones de objetos (Object Constraint Language OCL) y del diagrama de intercambios. 2.2.2 Modelado Visual Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una simplificación de la realidad. El objetivo del modelado de un sistema es capturar las partes esenciales del sistema. Para facilitar este modelado, se realiza una abstracción y se plasma en una notación gráfica. Esto se conoce como modelado visual. El modelado visual permite manejar la complejidad de los sistemas a analizar o diseñar. De la misma forma que para construir una choza no hace falta un modelo, cuando se intenta construir un sistema complejo como un rascacielos, es necesario abstraer la complejidad en modelos que el ser humano pueda entender. UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas software como para la arquitectura hardware donde se ejecuten. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 12 / 20
  • 13. Object Oriented y UML Estanislao Contreras Chávez Otro objetivo de este modelado visual es que sea independiente del lenguaje de implementación, de tal forma que los diseños realizados usando UML se pueda implementar en cualquier lenguaje que soporte las posibilidades de UML (principalmente lenguajes orientados a objetos). UML es además un método formal de modelado. Esto aporta las siguientes ventajas: • Mayor rigor en la especificación. • Permite realizar una verificación y validación del modelo realizado. • Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y a la inversa (a partir del código fuente generar los modelos). Esto permite que el modelo y el código estén actualizados, con lo que siempre se puede mantener la visión en el diseño, de más alto nivel, de la estructura de un proyecto. El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue. 2.2.3 ¿Qué es UML? UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo  los símbolos utilizados en los modelos  y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 5). Figura 5: Lenguaje de modelo UML Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son: • Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. • Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 13 / 20
  • 14. Object Oriented y UML Estanislao Contreras Chávez • Vista de Componentes: Muestra la organización de los componentes de código. • Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente. • Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos. Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología. Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario. 2.2.4 Las fases del desarrollo de sistemas que soporta UML Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas. Análisis de Requerimientos UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software. Análisis La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. Diseño En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 14 / 20
  • 15. Object Oriented y UML Estanislao Contreras Chávez Programación En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código. Pruebas Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema. 2.2.5 Objetivos de UML Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones: • Visualizar: UML permite expresar de una for-ma gráfica un sistema de forma que otro lo puede entender. • Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. • Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados. • Documentar: Los propios elementos gráficos sirven como documentación del sistema des-arrollado que pueden servir para su futura re-visión. 2.2.6 Beneficios de 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. 2.3. Diagramas de UML Un diagrama es la representación gráfica de un conjunto de elementos con sus relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para poder representar correctamente un sistema, UML ofrece una amplia variedad de diagramas para visualizar el sistema desde varias perspectivas. UML incluye los siguientes diagramas: • Diagrama de casos de uso. • Diagrama de clases. • Diagrama de objetos. • Diagrama de secuencia. • Diagrama de colaboración. • Diagrama de estados. • Diagrama de actividades. • Diagrama de componentes. • Diagrama de despliegue. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 15 / 20
  • 16. Object Oriented y UML Estanislao Contreras Chávez Los diagramas más interesantes (y los más usados) son los de casos de uso, clases y secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará ejemplos de un sistema de venta de entradas de cine por Internet. El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. En la figura 6 se muestra un ejemplo de casos de uso, donde se muestran tres actores (los clientes, los taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus roles). Figura 6: Diagrama de Casos de Uso El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones. Éste es el diagrama más común a la hora de describir el diseño de los sistemas orientados a objetos. En la figura 7 se muestran las clases globales, sus atributos y las relaciones de una posible solución al problema de la venta de entradas. Universidad ESAN – Maestría en Dirección de Tecnologías de Información 16 / 20
  • 17. Object Oriented y UML Estanislao Contreras Chávez Figura 7: Diagrama de Clases En el diagrama de secuencia se muestra la interacción de los objetos que componen un sistema de forma temporal. Siguiendo el ejemplo de venta de entradas, la figura 8 muestra la interacción de crear una nueva sala para un espectáculo. Figura 8: Diagrama de Secuencia Universidad ESAN – Maestría en Dirección de Tecnologías de Información 17 / 20
  • 18. Object Oriented y UML Estanislao Contreras Chávez El resto de diagramas muestran distintos aspectos del sistema a modelar. Para modelar el comportamiento dinámico del sistema están los de interacción, colaboración, estados y actividades. Los diagramas de componentes y despliegue están enfocados a la implementación del sistema. 2.4. Proceso de Desarrollo Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga, los mismos creadores de UML han propuesto su propia metodología de desarrollo, denominada el Proceso Unificado de Desarrollo. El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidos. Además, el Proceso Unificado utiliza el UML para expresar gráficamente todos los esquemas de un sistema software. Pero, realmente, los aspectos que definen este Proceso Unificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado en la arquitectura. Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que los llevan a cabo. Además, estos modelos se vali-dan para que sean conformes a los casos de uso. Finalmente, los casos de uso también sir-ven para realizar las pruebas sobre los componentes desarrollados. Centrado en la arquitectura: En la arquitectura de la construcción, antes de construir un edificio éste se contempla desde varios puntos de vista: estructura, conducciones eléctricas, fontanería, etc. Cada uno de estos aspectos está representado por un gráfico con su notación correspondiente. Siguiendo este ejemplo, el concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. Iterativo e incremental: Todo sistema informático complejo supone un gran esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo más práctico es dividir un proyecto en varias fases. Actualmente se suele hablar de ciclos de vida en los que se realizan varios recorridos por todas las fases. Cada recorrido por las fases se denomina iteración en el proyecto en la que se realizan varios tipos de trabajo (denominados flujos). Además, cada iteración parte de la anterior incrementado o revisando la funcionalidad implementada. Se suele denominar proceso. (Ver figura 9). Universidad ESAN – Maestría en Dirección de Tecnologías de Información 18 / 20
  • 19. Object Oriented y UML Estanislao Contreras Chávez Figura 9: Proceso Iterativo e Incremental Universidad ESAN – Maestría en Dirección de Tecnologías de Información 19 / 20
  • 20. Object Oriented y UML Estanislao Contreras Chávez Referencias • G. Booch, J. Rumbaugh y I. Jacobson, "El Lenguaje Unificado de Modelado", Addison Wesley, 1999 • Jacobson, G. Booch, J. Rumbaugh , "El Proceso Unificado de Desarrollo", Addision Wesley, 2000 • Martin Fowler: “UML Distilled”, Addison Wesley, 2004. • Pagina oficial de UML. www.uml.org • Wikipedia. www.wikipedia.org Universidad ESAN – Maestría en Dirección de Tecnologías de Información 20 / 20