sábado, 22 de septiembre de 2007

Beneficios del Modelo de Objetos y de la Poo sobre otros Paradigmas

La programación orientada a objetos beneficia a los desarrolladores debido a que: Los programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo real.
Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios están ocultos.
Los objetos son unidades autocontenidas.
La productividad se incrementa debido a que puede reutilizar el código.
Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de negocios.
Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
Simplifica los datos complejos.
Reduce la complejidad de la transacción.
Confiabilidad.
Robustez.
Capacidad de ampliación.

Historia de los Paradigmas en el Desarrollo del Software

Paradigmas: Representan un enfoque particular o filosofía para la construcción del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas.
También hay situaciones donde un paradigma resulta más apropiado que otro.
Los más comunes son el desarrollo en cascada, el desarrollo en espira’‘, el desarrollo por prototipos, el desarrollo incremental, el desarrollo en V y el desarrollo orientado a objetos. También existen modelo híbridos, los cuales combinan elementos de diferentes modelos según las necesidades existentes.
En Ingeniería de software el desarrollo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. Un ejemplo de una metodología de desarrollo en cascada es:  Análisis de requisitos  Diseño  Programación  Prueba  Implantación  Mantenimiento De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy Para cada actividad habrá cuatro tareas. Determinar o fijar objetivos Fijar también los productos definidos a obtener: requerimientos, especificacion, manual de usuario. Fijar las restricciones. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacion inicial o previa.
Análisis del riesgo Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. Desarrollar, verificar y validar (probar) Tareas de la actividad propia y se prueba. Planificar Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la proxima actividad. Ventajas El analisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Inconvenientes Genera mucho trabajo adicional.

viernes, 21 de septiembre de 2007

Poliformismo


La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momento.

El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivación de clases o herencia.

El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto sólo se puede producir en lenguajes de programación orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior (también llamada estática), esto significa que el compilador genera una llamada a un nombre específico de función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se ha de ejecutar. En POO, el programa no puede determinar la dirección del código hasta el momento de la ejecución. Cuando se envía un mensaje a un objeto, el código que se llama no se determina hasta el momento de la ejecución. El compilador asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no conoce el código exacto a ejecutar.

Jerarquia y herencia




La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía “es-un” (is-a): generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-of): agregación).

Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la herencia define una relación entre clases, en donde una clase comparte la estructura o comportamiento definido en una o más clases (herencia simple y herencia múltiple, respectivamente).

La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de camión.

Modularidad Objetos

La Modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.
La modularización consiste en dividir un programa en módulos que se puedan compilar por separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.
La Modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación y abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización de un buen módulo como componente.
El Módulo A depende del Módulo B si cualquier cambio en el Módulo B implica que el Módulo A también tenga que ser modificado. A veces se dice que el Módulo A es un cliente del Módulo B, o que el Módulo B actúa como servidor del Módulo A. En general, es normal que un mismo módulo sea tanto cliente como servidor. Esto significa, que depende de algunos módulos, mientras que otros módulos dependen de él. Incluso es posible que un par de módulos se tengan uno al otro de cliente; sin embargo, éste es un ejemplo de dependencia circular, que debe evitarse cuando sea posible debido a que impide la reutilización.
La dependencia a veces se conoce como acoplamiento. Un sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos sistemas tienen débil acoplamiento, porque en ese caso los cambios en una parte del sistema son menos probables de propagarse a través del sistema.
Los módulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de implementar. Este tipo de módulos se dice que tienen una fuerte cohesión. El módulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente está protegido de la información irrelevante relativa a cómo el módulo hace lo que hace.

Encapsulamiento


El Encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.
La encapsulación permite la división de un programa en módulos. Estos módulos se implementan mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la práctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementación. La interfaz de una clase captura sólo su vista externa y la implementación contiene la representación de la abstracción, así como los mecanismos que realizan el comportamiento adecuado.
Encapsulación es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas más comunes para encapsular elementos. En el siguiente ejemplo, la clase BankAccount encapsula los métodos, campos y propiedades que se describen en una cuenta bancaria. Sin una encapsulación, usted necesitaría declarar procedimientos y variables por separado para almacenar y administrar información para la cuenta bancaria, y sería difícil trabajar con más de una cuenta bancaria a la vez. La encapsulación le permite utilizar los datos y procedimientos en la clase BankAccount como una unidad. Usted puede trabajar con varias cuentas bancarias al mismo tiempo sin confusión, debido a que cada cuenta está representada por una instancia única de la clase.
La encapsulación también le permite controlar la forma en que se utilizan los datos y los procedimientos. Puede utilizar modificadores de acceso, como Private o Protected, para evitar que los procedimientos externos ejecuten métodos de clase o lean y modifiquen datos en propiedades y campos.

Abstracción


Abstracción consiste en aislar un elemento de su contexto o del resto de los elementos que lo acompañan. En programacion, el término se refiere al énfasis en el "¿qué hace?" más que en el "¿cómo lo hace?". El común denominador en la evolución de los lenguajes de programacion, desde los clásicos o imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del que cada uno de ellos hace uso.

La abstracción encarada desde el punto de vista de la programacion orientada objetos expresa las características esenciales de un objeto, las cuales distinguen al objeto de los demás. Además de distinguir entre los objetos provee límites conceptuales. Entonces se puede decir que la encapsulación separa las características esenciales de las no esenciales dentro de un objeto. Si un objeto tiene más características de las necesarias los mismos resultarán difíciles de usar, modificar, construir y comprender.

La misma genera una ilusión de simplicidad dado a que minimiza la cantidad de características que definen a un objeto.

Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda reutilizar.

Elementos primordiales en el modelo de objetos.




La programación Orientada a Objetos trata de cumplir las necesidades de los usuarios finales, estás tareas se realizan mediante la modelización del mundo real, el sopote fundamental es el modelo objeto.

Los elementos más importantes de este modelo son:

*Abstracción

*Encapsulamiento

*Modularidad

*Jerarquia y Herencia

*Polimorfismo

Programacion Orientada Objetos Conceptos Y Caracteristicas


La Programación Orientada a Objetos (POO) es una forma de enfocar la tarea de programación. Los enfoques de la programación han cambiado drásticamente desde la invención de las computadoras, la creciente complejidad de los programas, antes se realizaban mediante una consola las instrucciones máquina en binario. Esto funcionaba porque los programas sólo tenían unos pocos cientos de instrucciones. Cuando crecierón los programas, se invento el lenguaje ensamblador para que el programador pudiera manejar programas más largos y complejos usando una representación simbólica de las instrucciones máquina.
Los lenguajes de alto nivel aparecierón para proporcionar al programador más herramientas con las cuales gestionar esa complejidad. En los años sesenta nace la programación estructurada, este es el método alentando por varios lenguajes como pascal, y C. Con los lenguajes estructurados fue posible escribir programas moderadamente complejos de una forma bastante sencilla. Sin embargo, usando incluso la programación estructurada, cuando los proyectos Alcanzan cierto tamaño, su complejidad se vuelve demasiado difícil para ser controlada por un programador.
La Programación Orientada a Objetos toma las mejores ideas de la programación estructurada la combina con nuevos y poderosos conceptos que animan o alientan una nueva visión de la tarea de la programación. La Programación Orientada a Objetos permite descomponer fácilmente un problema en subgrupos de partes relacionadas. Entonces, puede traducir estos subgrupos en unidades autocontenidas llamadas Objetos.

Diseño Orientado a Objetos


Elaborar una especificación completa y validada de la arquitectura global hardware-software, de la estructura de control y de la estructura de datos del producto, así como un esquema de los manuales de usuarios y planes de test; de las interfaces de relación, dimensionamiento y algoritmos claves de cada componente de programa.

Analisis Orientado a Objetos



Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa

miércoles, 19 de septiembre de 2007

Especificaciones de requerimiento


Facilita la comprensión que tendrá el cliente sobre el software que se le realizara tenga una mejor idea sobre como funcionara; analizando sus necesidades y tratando de dar soluciones sin ambigüedad; especificando y gestionando los requisitos para que se transformen en un sistema operacional.

Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.

El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: identificación de requisitos, Análisis de requisitos y negociación, Especificación de requisitos, Modelizado del sistema, Validación y gestión de requisitos.

IDENTFICACION DE REQUISITOS

Identifican una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.

• Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema. • Problemas de comprensión. Los clientes no están completamente seguros de lo que necesitan, tienen una pobre comprensión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del problema, etc. • Problemas de volatilidad. Los requisitos cambian con el tiempo.

ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios.

ESPECIFICACION DE REQUERIMIENTOS

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

A menudo los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos del dominio.

Requerimientos funcionales

Son declaraciones de los servicios que proveerá el sistema, de la manera
en que éste reaccionará a entradas particulares. En algunos casos, los
requerimientos funcionales de los sistemas también declaran explícitamente
lo que el sistema no debe hacer.

lunes, 17 de septiembre de 2007

Conceptos del Ciclo de Vida del Software



Un modelo de viad del software se define el estado de las fases atravez de las cuales se mueve el desarrollo de algún tipo de programa.
Mas que nada el modelo de vida de software es mas que nada una lista de actividades a realizar y que van ocurriendo en en el desarrollo del software.

Las funciones principales de un modelo de ciclo de vida del software son:
  • describe las funciones principales del software
  • ayuda a administrar el progreso del desarrollo
  • provee un buen espacio de trabajo

Los diversos tipos de modelos suministran una especie de guia para los ingenieros con el fin de ordenar diferentes actividades tecnicas, suministran un marco para la administracion del desarrollo y mantenimiento esto quiere decir que permite estimar recursos ala vez definir puntos de control intermedio, etc.

DIFERENTES TIPOS DE CICLOS DE VIDA DEL SOFTWARE

Modelo de Cascada

Este es el primer modelo que se desarrollo y asta ahora el mas comodo a utilizar por su simplicidad en los pasos siendo el mas basico. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase.

Principios basicos del modelo de cascada

  • Planear un proyecto
  • Definir el comportamiento exteno del sistema
  • Archivar los resultados de cada actividad
  • diseñar un sistema

miércoles, 5 de septiembre de 2007

CONCEPTOS BASICOS DEL MODELO ORIENTASO A OBJETOS


1.1 RECONOCIMIENTOS DE OBJETOS Y CLASES EN EL MUNDO REAL Y LA INTERACCIÓN ENTRE ELLOS.


Cualquier sistema de software es una serie de cambios dentro de un conjunto de objetos, esto quiere decir que todo lo que integra al sistema tiene un significado, un nombre como un objeto de la vida real.

La mayoría de los objetos de la vida real tiene atributos como un niño, que tiene una edad, sexo, nacionalidad etc.


COMPORTAMIENTO

Son las acciones que puede realizar un objeto.

ejemplo:

una persona: pude comer, jugar, bailar, hablar, etc.
esto quiere decir que los ojetos saben que tienen que hacer, es decir tienen funciones.

Los objetos tienen atributos y ellos a su vez comportamientos, como una persona que tiene inteligencia y puede estudiar.


Las características que un objeto tiene o sabe son sus atributos.

Las acciones que un objeto puede realizar son su comportamiento.



1.2 LA ABSTRACCIÓN Y EL ENCAPSULAMIENTO COMO UN PROCESO NATURAL.


Las técnicas que utilizan los programadores para controlar la complejidad , es la abstracción.



Como un GPS que proyecta mapas virtuales de una region determinada, los cuales solo tienen la información necesaria para que el usuario pueda llagar a su destino, son una abstracción de los caminos o carreteras originales.

Entender el proceso de abstracción es psicologicamente necesario y natural para comprender nuestro entorno de una manera mas facil.


L a tecnica mas fácil para entender la complejidad fue aumentar la abstracción, es decir la abstracción significa encapsular y aislar la información del diseño y ejecución.


1.3 LA PPO Y LA COMPLEJIDAD DEL SOFTWARE.




Booch dice que la complejidad del software se deriva de 4 elementos:


  • la complejidad del dominio del problema.
  • la dificultad de gestionar el proceso de desarrollo.
  • la posible flexibilidad a través del software
  • los problemas de caracterización del comportamiento de sistemas discretos.


LA COMPLEJIDAD DEL DOMINIO DEL PROBLEMA

Esta complejidad se produce por las difíciles interacciones entrelos usuarios de un sistema y sus desarrolladores-. Los usuarios encuentran generalmente muy difícil dar precisión sobre sus necesidades de forma que los desarrolladores puedan comprender. En casos extremos, los usuarios pueden tener solo ideas vagas de lo que se desea en un sistema software.











martes, 4 de septiembre de 2007

APUNTES DE PROGRAMACION ORIENTADA A OBJETOS



PROGRAMACIÓN ORIENTADA A OBJETOS

1. Objetos

Entender que es un objeto es la clave para entender cualquier lenguaje orientado a objetos.

Existen muchas definiciones que se le ha dado al Objeto. Primero empecemos entendiendo que es un objeto del mundo real. Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor. Digamos que para leer este artículo lo hacemos a través del monitor y una computadora, ambos son objetos, al igual que nuestro teléfono celular, un árbol o un automóvil.

Analicemos un poco más a un objeto del mundo real, como la computadora. No necesitamos ser expertos en hardware para saber que una computadora está compuesta internamente por varios componentes: la tarjeta madre, el chip del procesador, un disco duro, una tarjeta de video, y otras partes más. El trabajo en conjunto de todos estos componentes hace operar a una computadora.

Internamente, cada uno de estos componentes puede ser sumamente complicado y puede ser fabricado por diversas compañías con diversos métodos de diseño. Pero nosotros no necesitamos saber cómo trabajan cada uno de estos componentes, como saber que hace cada uno de los chips de la tarjeta madre, o cómo funciona internamente el procesador. Cada componente es una unidad autónoma, y todo lo que necesitamos saber de adentro es cómo interactúan entre sí los componentes, saber por ejemplo si el procesador y las memorias son compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de video. Cuando conocemos como interaccionan los componentes entre sí, podremos armar fácilmente una computadora.

¿Que tiene que ver esto con la programación? La programación orientada a objetos trabaja de esta manera. Todo el programa está construido en base a diferentes componentes (Objetos), cada uno tiene un rol específico en el programa y todos los componentes pueden comunicarse entre ellos de formas predefinidas.

Todo objeto del mundo real tiene 2 componentes: características y comportamiento.

Por ejemplo, los automóviles tienen características (marca, modelo, color, velocidad máxima, etc.) y comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar llantas, etc.).

Los Objetos de Software, al igual que los objetos del mundo real, también tienen características y comportamientos. Un objeto de software mantiene sus características en una o más "variables", e implementa su comportamiento con "métodos". Un método es una función o subrutina asociada a un objeto.


Características asociadas al POO

La abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento. Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué características podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué características semejantes tienen todos los automóviles? Todos tendrán una marca, un modelo, número de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su comportamiento todos los automóviles podrán acelerar, frenar, retroceder, etc.

En los lenguajes de programación orientada a objetos, el concepto de Clase es la representación y el mecanismo por el cual se gestionan las abstracciones.

Encapsulamiento

El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento que veremos a continuación.

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

Ocultamiento

Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer sólo los detalles que sean necesarios para el resto del sistema.

El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habrá cierto comportamiento privado de la Clase que no podrá ser accedido por otras Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dónde se validarán que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y métodos.


Lenguajes de Programación Orientado a Objetos

En 1985, E. Stroustrup extendió el lenguaje de programación C a C++, es decir C con conceptos de clases y objetos, también por esas fechas se creo desde sus bases el lenguaje EIFFEL.

En 1995 apareció el más reciente lenguaje OO, Java desarrollado por SUN, que hereda conceptos de C++.

El lenguaje de desarrollo más extendido para aplicaciones Web, el PHP 5, trae todas las características necesarias para desarrollar software orientado a objetos.

Además de otros lenguajes que fueron evolucionando, como el Pascal a Delphi.

Finalmente también otros lenguajes script como el ActionScript que si bien no es totalmente orientado a objetos pero sí posee las características.



Análisis y diseño Orientado a Objetos


Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos. También se necesitará realizar un análisis y diseño orientado a objetos.

El modelamiento visual es la clave para realizar el análisis OO. Desde los inicios del desarrollo de software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías.

Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier tipo de sistemas (no solamente de software) usando los conceptos de la orientación a objetos. Y además, este lenguaje debe ser entendible para los humanos y máquinas.

Actualmente en la industria del desarrollo de software tenemos al UML como un estándar para el modelamiento de sistemas OO. Fue la empresa Racional que creó estas definiciones y especificaciones del estándar UML, y lo abrió al mercado. La misma empresa creó uno de los programas más conocidos hoy en día para este fin; el Racional Rose, pero también existen otros programas como el Poseidon que trae licencias del tipo community edition que permiten su uso libremente.

El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se construyen en forma correcta, son fáciles de comunicar, cambiar, expandir, validar y verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes plenamente reutilizables.