Metodologías de desarrollo

MET. RUP Y METODOLOGÍA DE DESARROLLO ORIENTADO A OBJETOS

Alejandra Barbosa
Natalia Manjarres
German Velasco
Brigieth Vasquez

Bogotá DC
Servicio Nacional de Aprendizaje – SENA
Centro de gestión de mercados logística y tecnologías de información
2056283

Metodologia Rup
Introducción

Es un conjunto de métodos, principios y reglas que permiten enfrentar de manera sistemática

el desarrollo de un programa que resuelve un problema algorítmico. Estas metodologías
generalmente se estructuran como una secuencia de pasos que parten de la definición del
problema y culminan con un programa que lo resuelve

Características principales

El RUP contiene tres características principales:

Proceso dirigido por Casos de Uso

Según Kruchten Philippe (2000), “los Casos de Uso son una técnica de captura de requisitos
que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de
funciones que sería bueno contemplar.
Se define un caso de uso como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del
sistema”.

Los casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino
que también guían su diseño, implementación y prueba. Los casos de uso constituyen un
elemento integrador y una guía del trabajo.

Los casos de uso Inician el proceso de desarrollo y proporcionan un hilo conductor,

permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes
actividades del proceso de desarrollo.

Basándose en los casos de uso, se crean los modelos de análisis y diseño, luego la
implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente
adecuadamente cada caso de uso.

Proceso centrado en la arquitectura

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo

que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios)
y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo.

En el caso de RUP, además de utilizar los casos de uso para guiar el proceso, se presta
especial atención al establecimiento temprano de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento.

Existe una interacción entre los casos de uso y la arquitectura, los casos de uso deben encajar
en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos, actualmente y en el futuro.
La arquitectura dentro de RUP se representa en varias vistas. Todas las vistas juntas forman
el llamado modelo 4+1 de la arquitectura. Según Kruchten Philippe (1998) “el cual recibe
este nombre porque lo forman las vistas lógica, de implementación, de proceso y de
despliegue, más la de casos de uso que es la que da cohesión a todas”.
Al final de la fase de elaboración se obtiene una “baseline” (base de referencia) de la
arquitectura donde fueron seleccionados una serie de casos de uso arquitectónicamente
relevantes (aquellos que ayudan a mitigar los riesgos más importantes, aquellos que son los
más importantes para el usuario y aquellos que cubran las funcionalidades significativas).

Proceso iterativo e incremental

El equilibrio correcto entre los casos de uso y la arquitectura es muy parecido al equilibrio de
la forma y la función en el desarrollo de un producto, lo cual se consigue con el tiempo. Para
esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en
donde el trabajo se divide en partes más pequeñas o mini proyectos. Cada mini proyecto se
puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los
flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.

Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando se termina.
Durante la planificación de los detalles de la siguiente iteración, el equipo también examina
cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de
la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa
con esta dinámica hasta que se haya finalizado por completo con la versión actual del
producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones (que
son una cantidad variable) según el proyecto, y en las que se hace un mayor o menor hincapié
en los distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una “baseline” (base de referencia)
de la arquitectura.

Para cada iteración se escogen algunos casos de uso, se refina su análisis y diseño, y se
procede a su implementación y pruebas. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su

entrega a la comunidad de usuarios. Como se puede observar, en cada fase participan todas
las disciplinas, pero, dependiendo de la fase, es el esfuerzo dedicado a una disciplina.

Fases

El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales. En cada
extremo de una fase se realiza una evaluación para determinar si los objetivos de la fase se
han cumplido. Una vez que la evaluación obtiene los resultados deseados, se procede a la
siguiente fase.

Planeando las fases

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva
versión del producto, cada ciclo está compuesto por fases y cada fase está compuesta por un
número de iteraciones.

1.- Concepción, Inicio o Estudio de oportunidad

Define el ámbito y objetivos del proyecto, además de la funcionalidad y capacidades del

producto.

2.- Elaboración

Tanto la funcionalidad como el dominio del problema se estudian a profundidad. Se define

una arquitectura básica y se planifica el proyecto considerando recursos disponibles.
3.- Construcción

El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de

análisis, diseño e implementación Las fases de concepción y elaboración sólo dieron una
arquitectura básica que es refinada aquí de manera incremental conforme se construye (se
permiten cambios en la estructura). Gran parte del trabajo es programación y pruebas, se
documenta tanto el sistema construido como el manejo del mismo En esta fase se hace una
documentación junto con el producto.

4.- Transición

Se libera el producto y se entrega al usuario para un uso real. Se incluyen tareas de

mercadotecnia, empaquetado atractivo, instalación, configuración, entrenamiento, soporte,
mantenimiento, etc.

Los manuales de usuario se completan y refinan con la información anterior.

Ninguna fase es idéntica en términos de tiempo y esfuerzo. Aunque esto varía

significativamente dependiendo del proyecto, un ciclo de desarrollo inicial típico para un
proyecto de tamaño mediano debe anticipar la distribución siguiente del esfuerzo y horario:

Conforme un proyecto avanza y se intenta mejorar, llega un momento en que el ciclo (las
cuatro fases) debe repetirse. Estos ciclos subsecuentes se llaman los ciclos de la evolución.
Mientras que el producto pasa durante varios ciclos, se producen las nuevas generaciones.

Esfuerzo respecto de los flujos de trabajo (o disciplinas)

En la imagen posterior del documento se muestra el porcentaje el esfuerzo que se tiene que
realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se
muestran de forma horizontal son para todo el proyecto.

Se puede observar que para la obtención de requisitos en la fase de concepción se empiezan a

conseguir, en la fase de elaboración tiene su auge, y va declinando en la fase de construcción.
Con las demás sucede algo similar en distintas iteraciones.

Esfuerzo respecto de las fases

Disciplinas

Las disciplinas son los flujos del trabajo, los cuales son una secuencia de pasos para la
culminación de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las
de apoyo. Las primarias son las necesarias para la realización de un proyecto de software,
aunque para proyectos no muy grandes se pueden omitir algunas; entre ellas se tienen:
modelado del negocio, requerimientos, análisis y diseño, implementación, pruebas y
despliegue. Las de apoyo son las que complementan y brindan mejoras a las primarias y
especifican otras características en la realización de un proyecto de software; entre estas se
tienen: entorno, gestión del proyecto, gestión de configuración y cambios.

Modelado del negocio

Tiene como objetivos comprender la estructura y la dinámica de la organización, comprender

problemas actuales e identificar posibles mejoras, comprender los procesos del negocio.

Requerimientos

Sus objetivos son: establecer lo que el sistema debe hacer, se definen los límites del sistema,
y una interfaz de usuario. También realiza una estimación del costo y tiempo de desarrollo.

Análisis y diseño
Define la arquitectura del sistema y tiene como objetivos trasladar requisitos en
especificaciones de implementación, al decir análisis se refiere a transformar CU (casos de
uso) en clases, y al decir diseño se refiere a refinar el análisis para poder implementar los
diagramas de clases de análisis de cada CU, los diagramas de colaboración de cada CU, el de
clases de diseño de cada CU, el de secuencia de diseño de CU, el de estados de las clases, etc.

Implementación

Tiene como objetivos implementar las clases de diseño como componentes, asignar los
componentes a los nodos, probar los componentes individualmente (pruebas unitarias) e
integrar los componentes en un sistema ejecutable.

Pruebas

Verificar la integración de los componentes (prueba de integración), verificar que todos los
requisitos han sido implementados (pruebas del sistema), asegurar que los defectos
detectados han sido resueltos antes de la distribución.

Despliegue

Sus objetivos son asegurar que el producto está preparado para el cliente, para proceder a su
entrega y recepción por el cliente. En esta disciplina se realizan las actividades de probar el
software en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, así como la
tarea de enseñar al usuario.

Gestión y configuración de cambios

Éste es esencial para controlar el número de artefactos producidos por la cantidad de personal
que trabajan en un proyecto conjuntamente. Los controles sobre los cambios son de mucha
ayuda ya que evitan confusiones costosas, como la compostura de algo que ya se había
arreglado.

Entorno
Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que
engloba el desarrollo de un proyecto y describe las actividades requeridas para el desarrollo
de las pautas que apoyan un proyecto.
Su propósito es proveer a la organización que desarrollará el software, un ambiente en el cual
basarse, el cual provee procesos y herramientas para poder desarrollar el software.

Organización y elementos del RUP

Ya conociendo varias partes del RUP nos concentramos ahora en los elementos que lo
componen, entre estos se tienen: flujos de trabajo, detalle de los flujos de trabajo, actores,
actividades (o acciones) y artefactos.

Actores o roles

Son los personajes encargados de la realización de las actividades definidas dentro de los
flujos de trabajo de cada una de las disciplinas del RUP

Analistas

- Analista del Proceso del Negocio.

- Diseñador del Negocio.
- Revisor del Modelo del Negocio.
- Revisor de Requerimientos.
- Analista del Sistema.
- Especificador de Casos de Uso.
- Diseñador de Interfaz del Usuario.

Desarrolladores

- Arquitecto.
- Revisor de la Arquitectura.
- Diseñador de Cápsulas.
- Revisor del Código y Revisor del Diseño.
- Diseñador de la Base de Datos.
- Diseñador.
- Implementador y un Integrador.

Probadores Profesionales

- Diseñador de Pruebas.
- Probador.

Encargados

- Encargado de Control del Cambio.

- Encargado de la Configuración.
- Encargado del Despliegue.
- Ingeniero de Procesos.
- Encargado de Proyecto.
- Revisor de Proyecto.

Otros

- Cualquier trabajador.
- Artista Gráfico.
- Stakeholder.
- Administrador del Sistema.
- Escritor técnico.
- Especialista de Herramientas.

Artefactos

Los artefactos son el resultado parcial o final que es producido y usado por los actores
durante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores,
los cuales utilizan y van produciendo estos artefactos para tener guías. Un artefacto puede ser
un documento, un modelo o un elemento de modelo.
Conjunto de artefactos:

1.- Modelado del negocio

Capturan y presentan el contexto del negocio del sistema. Los artefactos del modelado del
negocio sirven como entrada y como referencia para los requisitos del sistema.

2.- Requerimientos

Capturan y presentan la información usada en definir las capacidades requeridas del sistema.

3.- Análisis y diseño del sistema

Capturan y presenta la información relacionada con la solución a los problemas que se

presentaron en los requisitos fijados.

4.- Implementación

Capturan y presentan la realización de la solución presentada en el análisis y diseño del

sistema.

5.- Pruebas
Los artefactos desarrollados como productos de las actividades de prueba y de la evaluación
son agrupadas por el actor responsable, con el cual se lleva un conjunto de documentos de
información sobre las pruebas realizadas y las metodologías de pruebas aplicadas.

6.- Despliegue

Capturan y presentan la información relacionada con la transitividad del sistema, presentada

en la implementación en el ambiente de la producción.

7.- Administración del proyecto

Capturan los artefactos asociados con el proyecto, el planeamiento y a la ejecución del
proceso.

8.- Administración de cambios y configuración

Capturan y presentan la información relacionada con la disciplina de configuración y

administración del cambio.
9.- Entorno o ambiente

Presenta los artefactos que se utilizan como dirección a través del desarrollo del sistema para
asegurar la consistencia de todos los artefactos producidos.

Grado de finalización de artefactos

Con grado de finalización nos referimos a cuántos de esos lineamientos del artefacto hemos
completado o llenado, esto en cada una de las disciplinas, de acorde a la fase en que se. En la
fase de concepción, en la disciplina de implementación del sistema los artefactos tienen una
poca finalización y van aumentando progresivamente en cada fase hasta llegar a su
culminación en la fase de transición.

Con esto se puede mostrar el aumento progresivo de los artefactos en cada disciplina en la
fase dada, teniendo una idea un poco más amplia sobre el desenvolvimiento del proyecto
hablando en términos de sus artefactos.

Desventajas de la metodología:

No capturar un caso de uso a tiempo puede causar una reconstrucción parcial de la

arquitectura.

La falta de especificaciones en los requisitos por parte del usuario puede causar ciertas
discrepancias.
Se requiere mucho personal (dependiendo del proyecto).

Ventajas de la metodología:
Es el proceso de desarrollo más general de los existentes actualmente.
Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo
(quién hace qué, cuándo y cómo).
Reutilización

El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel

Confiabilidad, Integridad y Estabilidad.

Mantenimiento más sencillo. Modificaciones locales.

Conclusión

La planeación de un proyecto de programación que pretende dar un beneficio en algún

servicio ya existente o en uno nuevo requiere definitivamente de una buena organización.
RUP es eficaz para atacar los asuntos de organización y de ejecución de un sistema de
desarrollo de software. Ayuda a percibir el problema desde distintos puntos de vista y ahorra
el tiempo de demora para un proyecto que tenga alguna continuidad y necesite
modificaciones o adiciones.

METODOLOGÍA DE DESARROLLO ORIENTADO A OBJETOS

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

UML El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar
y documentar esquemas de sistemas de software orientado a objetos. UML no es un método
de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo
diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más
accesible para otros. UML está controlado por el grupo de administración de objetos y es el
estándar de descripción de esquemas de software.

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

UML se compone de muchos elementos de esquematización que representan las diferentes

partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que
representa alguna parte o punto de vista del sistema.

CONCEPTOS DE LA METODOLOGÍA ORIENTADA A OBJETOS

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

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

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

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

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

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

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

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

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

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

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

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

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

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.
● Se construyen clases cada vez más complejas. Se construyen clases a partir de
otras clases, las cuales a su vez se integran mediante clases. Esto permite construir
componentes de software complejos, que a su vez se convierten en bloques de
construcción de software más complejo.

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

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

existentes. Muchos de los componentes están construidos de modo que se pueden
adaptar para un diseño particular.

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

● Mantenimiento más sencillo. El programador encargado del mantenimiento

cambia un método de clase a la vez. Cada clase efectúa sus funciones
independientemente de las demás.

● Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una
interfaz de usuario gráfica de modo que el usuario apunte a iconos o elementos de
un menú desplegado, relacionados con los objetos. En determinadas ocasiones, el
usuario puede ver un objeto en la pantalla. Ver y apuntar es más fácil que recordar
y escribir.

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

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

Un proveedor utiliza clases de otros. Existe una forma estándar de localizar clases
 e interactuar con ellas. El software desarrollado de manera independiente en
lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola
unidad ante el usuario.

● Computación Cliente-Servidor. En los sistemas cliente-servidor, las clases en el

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

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

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

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

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

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

preservarse si se ajustan a un contenedor orientado a objetos, de modo que la
comunicación con ella sea a través de mensajes estándar orientados a objetos.

● Mejores herramientas CASE. Las herramientas CASE (Computer Aided

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

Principios de la Metodología Orientada a Objetos.

Existen cuatro principios básicos, estos principios son fruto de la experiencia en todas las
ramas de la ingeniería.

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

acomete el problema. Hay que seleccionar el modelo adecuado para cada
momento y dependiendo de qué modelo se elija se obtendrán diferentes
beneficios y diferentes costes. En la industria software se ha comprobado que
un modelado orientado a objetos proporciona unas arquitecturas más flexibles
y adaptables que otros por ejemplo orientados a la funcionalidad o a los datos.

b) Todo modelo puede ser expresado a diferentes niveles de precisión. Esto

es, es necesario poder seleccionar el nivel de detalle que se desea ya que en
diferentes partes de un proyecto y en diferentes etapas se tendrán unas
determinadas necesidades.

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

modelos que nos permitan representar la realidad lo más claramente posible,
pero no sólo esto, tenemos que saber, exactamente cuándo se apartan de la
realidad para no caer en la ocultación de ningún detalle importante

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

afronta mejor desde pequeños modelos casi independientes, que los podamos
construir y estudiar independientemente y que nos representen las partes más
diferenciadas del sistema y sus interrelaciones.

UML El lenguaje unificado de diagrama o notación.

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

modelado de sistemas de software más conocido y utilizado en la actualidad; está
respaldado por el OMG (Object Management Group).
 Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.

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

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

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

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

HISTORIA

Antes de UML 1.x

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

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

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

alentando la adopción de la tecnología de objetos, y para orientarse hacia un método
unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de
Modelado abierto. Se consultó con representantes de compañías competidoras en el
área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para
representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue
organizado un consorcio internacional llamado UML Partners en 1996 para completar
las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo
como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML
Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML
Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y
administrada por Ed Reykholt, para finalizar las semánticas de la especificación y para
integrar con otros esfuerzos de estandarización. El resultado de este trabajo, el UML
1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en
noviembre de 1997.

UML 1.x

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

uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de
Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los
niveles inferiores. La notación de Casos de Uso del Objectory y la notación de
componentes de Booch fueron integrados al resto de la notación, pero la integración
semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la
revisión mayor de UML 2.0.
Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML
con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo
tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia
cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en
una gran variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones
de un sólo usuario a sistemas concurrentes y distribuidos.

El Lenguaje de Modelado Unificado es un estándar internacional:

ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido

abierto - Lenguaje de Modelado Unificado (UML) Versión 1.4.2

UML 2.x

UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores

(UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A
estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones
2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3
fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en
agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En
proceso" y todavía tiene que ser formalmente liberada.

UML es la herramienta grafica que Se utiliza para especificar métodos o procesos

realizados por el sistema, por medio de una serie de diagramas.

Nos proporciona una serie de herramientas que permiten mostrar el programa en sus
diferentes etapas o procesos, delimitarlos y organizarlos de tal forma que sean
entendibles por la persona que va a desarrollar el sistema.

Cabe destacar que UML no es un lenguaje de programación, sino el sistema que

permite modelar la estructura del programa.
 Aquellas personas que nunca han programado usando uml siempre lo ven como una
pérdida de tiempo, pero deberían dedicarle  por lo menos una semana a esto, en verdad
lo vale.

VENTAJAS DE PROGRAMAR USANDO UML:

● Mejores tiempos totales de desarrollo (de 50 % o más).

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

1. DESVENTAJAS

● UML no es un método de desarrollo. 

● UML al no ser un método de desarrollo es independiente del ciclo de desarrollo
● UML no se presta con facilidad al diseño de sistemas distribuidos.

OBJETIVOS

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

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

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

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

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

Técnicas de Metodología orientada a objetos

Metodología OMT

Object Modeling Technique (OMT):

Es importante el modelo y uso del mismo para lograr una abstracción, en el cual el
análisis está enfocado en el mundo real para un nivel de diseño, también pone detalles
particulares para modelado de recursos de la computadora. Esta metodología puede ser
aplicada en varios aspectos de implementación incluyendo archivos, base de datos
relacionales, base de datos orientados a objetos. OMT está construido alrededor de
descripciones de estructura de datos, constantes, sistemas para procesos de
transacciones.OMT pone énfasis en especificaciones declarativas de la información, para
capturar los requerimientos, especificaciones imperativas para poder descender
prematuramente en el diseño, declaraciones que permiten optimizar los estados, además
provee un soporte declarativo para una directa implementación de
DBMS
Data Base Manager System

Los puntos más importantes para esta metodología son los siguientes:
Poner énfasis en el análisis y no en el desarrollo.
Poner énfasis en los datos más que en las funciones, lo que proporciona estabilidad al
proceso de desarrollo.
Utilizar una notación común en todas las fases a través de tres modelos que capturan los
aspectos estáticos, dinámicos y funcionales que combinados proveen una descripción
completa del software. La Metodología OMT divide el proceso de desarrollo en tres
partes aisladas: análisis, diseño e implantación.
 Análisis: 
Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se
expresa en términos de objetos y de relaciones entre ellos, flujo dinámico de control y las
transformaciones funcionales.
 
Diseño: 
Es la estrategia de alto nivel para resolver el problema y cómo construir una solución. Se
define la arquitectura del sistema y se toman las decisiones estratégicas.
 
Implementación:
En esta fase se convierte finalmente el diseño de objetos en código. A su vez, cada una
de estas fases se divide en su tareas, como son: modelos de objetos, dinámico y
funcional; análisis y del sistema, y objetos del sistema.
 
Modelo de Objetos:
En esta primera parte del análisis se forma una primera imagen del modelo de clases del
sistema con sus atributos y lasrelaciones entre ellas, usando para ello un diagrama
entidad relación modificada en el que además de las clases y sus relaciones se pueden
representar también los métodos.
 
Modelo Dinámico:
El modelo dinámico usa un grafo para representar el comportamiento dinámico de cada
clase, es decir, el comportamiento de estas ante cada evento que se produce en el sistema.
Un evento desencadenará en un cambio de estado en la clase que se traducirá en una
modificación de los atributos o relaciones de ésta.
 
Modelo Funcional: 
Muestra que es lo que el sistema ha de hacer mediante un diagrama de flujo de datos, sin
entrar en la secuencia temporal en la que los procesos se ejecutan. El modelo funcional
puede revelar nuevos objetos y métodos que se pueden incorporar en los dos modelos
anteriores. Por eso se dice que el método OMT es iterativo.
 
Diseño del Sistema: 
Se centra en la parte física del sistema como la descomposición de éste en subsistemas, el
tipo de entorno en el que se va a ejecutar, el manejo de recursos y el almacenamiento de
datos.
 
Diseño de los objetos: 
Determina qué operaciones van a realizar los métodos y profundiza incluso los
algoritmos que va a usar. Se escogen los distintos tipos de representación de datos y se
subdivide en módulos que pasarán a formar parte de la implementación.

Metodología BOOCH

La metodología Booch (OOD), es una metodología de propósito general en la que se

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

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

Diagramas de objetos: 

En este tipo de gráfico de muestran los objetos y sus relaciones de forma

dinámica mostrando la forma en la que los objetos se pasan mensajes entre
ellos. Así mismo, en esto diagramas es posible representarla visibilidad de los
objetos siendo ésta la que determina que objetos se pueden comunicar con
otros.

Diagramas temporales: 

Muestran la secuencia temporal de creación y destrucción de objetos. Suelen ir

acompañados de pseudocódigo en el que se explica el flujo de mensajes de
control entre los objetos del sistema.

Diagramas de transición de estados: 

Permiten definir como las instancias de las clases pasan de un estado a otro a
causa de ciertos eventos y que acciones se desencadenan de esos cambios de
estado.

El Diagrama de Transición de Estado (también conocido como DTE) enfatiza

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

Eventos: Algo que sucede en el mundo real y como consecuencia se ejecuta un

proceso.
Acciones: Descripción del estado de un evento sobre una entidad

Definición de DTE.

Un diagrama de transición de estados describe un conjunto de transiciones que

pueden suceder sobre una entidad. El estado en que se encuentra una entidad
es el resultado de todas las transiciones sucedidas durante su vida.

Diagramas de módulo y proceso:

En Booch, en la fase de implementación, es posible representar mediante estos

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

Programa principal: Identifica al archivo que contiene la raíz del programa.

Especificación y cuerpo: Identifican los archivos que contienen la declaración
y la definición de los objetos o bien procedimientos o funciones necesarias
para el correcto funcionamiento de la aplicación.
Metodología RUP
Rational Unified Process (RUP)

Proceso Unificado de Desarrollo es el resultado de tres décadas de desarrollo y uso

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

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

Arquitectura del producto:

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

Ciclo de vida Iterativo Incremental:

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

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

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo

extensible que puede ser adaptado a organizaciones o proyectos específicos.

De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo

extensible, por lo que muchas veces resulta imposible decir si un refinamiento
particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho
motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

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

OOram (Object-Oriented Role Analysis and Modeling) Es un método de análisis y

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

Método de Fusión
Fusión proporciona un método de desarrollo de software orientado al objeto, que
abarca desde la definición de requisitos a la implementación en un lenguaje de
programación.
Es considerada como una metodología de segunda generación, porque proviene de:

OMT: modelo de objetos,

CRC: interacción de objetos,
BOOCH: visibilidad,
Los métodos Formales: pre- y post- condiciones.
Proporciona un proceso de desarrollo, que se divide en:
Análisis, Diseño e Implementación.
Ofrece notaciones para los modelos, que describen varios aspectos del software.
Actualmente ha abandonado su notación.
Proporciona herramientas de gestión.

Análisis
El análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace.
Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la
de la máquina. El análisis casa con el dominio del problema y se preocupa por el
comportamiento visible externamente.
La meta de la fase de análisis es capturar tantos requisitos del sistema como sea
posible. Se producen los siguientes modelos del sistema:
● Modelo de objetos
● Modelo de la interfaz
● Modelo del funcionamiento,
 ● Modelo del ciclo de vida.

Estos modelos describen:

✔ Clases de objetos que existen en el sistema.
✔ Relaciones entre esas clases.
✔ Operaciones que pueden realizarse en el sistema.
✔ Secuencias permitidas de estas operaciones.
✔ La entrada para la fase de análisis es un documento de definición de requisitos
en lenguaje natural.

Modelo de objetos

La finalidad del modelo de objetos en Fusión es: capturar los conceptos que existen en
el dominio del problema y las relaciones entre ellos, mostrar clases y sus relaciones,
(no mostrar objetos)
El modelo de objetos representa: la estructura estática de la información en el sistema,
las clases y relaciones entre ellas
Especifica el orden en el que deben hacerse las cosas dentro de cada fase. También
proporciona criterios de cuándo pasar a la siguiente fase.
En la fase del análisis de Fusión, sólo los atributos de una clase son considerados. Los
métodos son considerados en la fase de diseño. Por consiguiente, en la fase del
análisis, los objetos son similares a las entidades en el tradicional modelo entidad
relación. Atributos de clases, agregación, especialización/generalización.

Conclusiones

La metodología orientada a objetos permite la optimización de los elementos generados

gracias a que mediante técnicas de herencia, atributos estáticos entre otros permiten, que los
elementos sean genéricos de manera que sea reutilizable.
Las metodologías orientado a objetos es algo totalmente distinto a la programación
estructurada y se tiene que romper cualquier esquema y enseñanza previa si deseamos
incursionar en lenguajes y documentación orientada a objetos

Gracias a UML se puede estudiar las distintas partes que conforman al sistema y cómo
interactúan estas. Reflejando las interfaces, protocolos e intercambio de señales. Para tal fin
nos podemos apoyar de los diagramas de clases, estructura compuesta y comunicación.

El lenguaje de Modelado UML cumple con varios requerimientos para elaborar un sistema
orientado a objetos, ya que cuenta con una notación estándar y anotaciones semánticas que
son esenciales para elaborar este tipo de software.