• Author / Uploaded
• Johanbert Mosquera

Citation preview

La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991. OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software. Las fases que conforman a la metodología OMT son: 1.2.3.4.-

Analisis Diseño del Sistema Diseño de Objetos Implementeacion

La metodología OMT emplea tres clases de modelos para describir el sistema: 1.- Modelo de objetos. 2.- Modelo dinamico. 3.- Modelo funcional.

Introducción

Existen muchas aproximaciones de desarrollo de software que utilizan modelos orientado a objetos, pero que no tienen todos los soportes para desarrollo de aplicaciones de base de datos. Algunas aproximaciones carecen de suficientes abstracciones y tienen un bajo relacionamiento para detalles de implementación. Otros métodos de programación orientados ponen un escaso énfasis en la estructura de datos y constantes, que son muy importantes para aplicaciones de base de datos. OMT pone énfasis en la importancia del modelo y uso de modelo para lograr una abstracción , en el cual el análisis esta enfocado en el mundo real para un nivel de diseño, también pone detalles particulares para modelado de recursos de la computadora. Esta Tecnología puede ser aplicado en varios aspectos de implementación incluyendo archivos, base de datos relacionales, base de datos orientados a objetos. OMT esta construido alrededor de descripciones de estructura de datos, constantes, sistemas para procesos de transacciones. 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.

Desde el modelado de información, tuvo que ser adoptada la noción de entidades que son conectadas con entidad relación, los modelos de relación son declarativas, imperativas. OMT pone énfasis en especificaciones declarativas de la información, para capturar limpiamente 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. INTRODUCCION

El objeto que modela la técnica (OMT) comienza en la conceptualización del sistema y atraviesa el ciclo vital del desarrollo del sistema de software lógica a través de la puerta en practica de sistema. El proceso consiste en cuatro actividades de alto nivel. Cada actividad es dirigida por una descripción del flujo del trabajo e implica la creación de modelos múltiples. La técnica que modela el objeto es utilizado para mostrar la estructura estática de un sistema mostrando los objetos en el sistema, juntos con sus lazos, atributos y operaciones. OMT se puede adaptar para utilizar en diversos ordenes de sus actividades importantes para permitir que la ejecución simultanea en el trabajo sea realizada y la iteración de actividades y de sus tareas. Así ajustes de OMT agradable en un marco modelo espiral de ciclo vital del desarrollo incremental del software lógica. OMT utiliza tres modelos fundamentales para capturar el comportamiento y el diseño para el sistema. Estos modelos son: 1. Modelo del objeto, que representa la naturaleza estructural del sistema. 2. Modelo dinámico, que representa el comportamiento del sistema. 3. Modelo funcional, que describe los algoritmos requeridos para satisfacer los requisitos del proceso del sistema. Estos tres modelos son puestos en ejecución iterando concluido un conjunto de microprocesos del análisis, a partir de la fase de la conceptualización a través de la fase del diseño del objeto.

METODOLOGÍA ORIENTADAS A OBJETOS (OMT). La metodología a seguir es la OMT(Object Modeling Techique) de Rumbaugh. Surgió en los laboratorios Bell de USA. Tiene las siguientes fases: 1. Conceptualización. 2. Análisis. 3. Diseño Sistema. 4. Diseño Objeto. 5. Implementación.

•

OMT es una de las metodologías de análisis y diseño de desarrollo de software orientado a objetos más eficiente que existe en la actualidad.

•

Es uno de los precursores de UML.

•

Esta metodología se extiende del análisis, al diseño, a la implementación durante sus etapas.

Etapas de OMT 1. Análisis: es una abstracción concisa y precisa de qué debe hacer el sistema deseado, no cómo debe ser hecho. 2. Diseño del Sistema: en esta etapa se deben decidir las características del funcionamiento para optimizar el sistema, así como escoger una estrategia para atacar el problema. 3. 3. Diseño de Objetos: se agregan los detalles de implementación al modelo de diseño y las clases de objetos son reforzadas con las estructuras de datos y algoritmos escogidos. 4. 4. Implementación: las clases de objetos y las relaciones entre ellas definidas durante el diseño de objetos son trasladadas a un lenguaje de programación, a una base de datos o implementación de hardware. Modelos de OMT •

Modelo de Objetos: describe la estructura estática de los objetos de un sistema y sus relaciones. Utiliza diagramas de clases.

•

Modelo Dinámico: determina cómo los aspectos del sistema que cambian a través del tiempo. Utiliza diagramas de estado.

•

Modelo Funcional: describe las trasformaciones de los valores de los datos dentro de un sistema. Utiliza diagramas de flujo de datos.

Conclusiones •

La metodología OMT (Object Modeling Technique) desarrollada por James Rumbaugh es base para el desarrollo de software orientado a objetos y se extiende del análisis, al diseño, a la implementación

La metodología OMT posee cuatro etapas: análisis, diseño del sistema, diseño de objetos e implementación definidas por tres modelos: el modelo de objetos, el modelo dinámico y el modelo funcional Rational Unified Process (RUP) La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software: 

Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.



Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.



Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.



Transmisión, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas: Disciplina de Desarrollo 

Ingeniería de Negocios: Entendiendo las necesidades del negocio.



Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.



Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.



Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.



Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado esta presente.

Disciplina de Soporte 

Configuración y administración del cambio: Guardando todas las versiones del proyecto.



Administrando el proyecto: Administrando horarios y recursos.



Ambiente: Administrando el ambiente de desarrollo.



Distribución: Hacer todo lo necesario para la salida del proyecto

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración. Los elementos del RUP son: 

Actividades, Son los procesos que se llegan a determinar en cada iteración.



Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.



Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software. Conclusión: 

La Metodología RUP es mas adaptable para proyectos de largo plazo.

METODOLOGIA ROM Consiste en el desarrollo de software utilizando objetos que hayan sido previamente desarrollados en otros proyectos

METODOLOGIA RUP

PROCESO DE DESARROLLO DE SOFTWARE: La metodología RUP es una disciplina que nos permite mantener un orden debidamente estricto el cual asigna responsabilidades en una empresa. RUP que significa Proceso Unificado racional es un programa creado por IBM el cual se desarrollo orientado para desarrollar modelos que representen en la empresa, habiendo sido debidamente investigada la empresa. Nos brinda la facilidad de utilizar UML de forma práctica, además un apoyo para realizar muchos procesos que existen para modelar o documentar el sistema de una empresa. RUP es un software moderno es complejo y novedoso. Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema. RUP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Con esto se logra reducirlos riesgos del proyecto y tener un subsistema ejecutable tempranamente.

RUP es una herramienta determinada por ciclos y fases para el proceso del Modelado

Fases de la Metodología RUP Un ciclo está conformado por 4 fases cada una las cuales son:  Fase de Inicio  Fase de Elaboración  Fase de Construcción  Fase de Transición PRINCIPALES CARACTERISTICAS Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) Pretende implementar las mejores prácticas en Ingeniería de Software Desarrollo iterativo Administración de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificación de la calidad del software Implementación del RUP para el proyecto La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios RUP Rational Unified Process

El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente. RUP se divide en 4 fases, dentro de las cuales se realizan varias iteraciones según el proyecto y en las que se hace mayor o menos esfuerzo en las distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades:  Fase de Inicio (Inspección y Concepción) Se hace un plan de fases, donde se identifican los principales casos de uso y se identifican los riesgos. Se concreta la idea, la visión del producto, como se enmarca en el negocio, el alcance del proyecto.  Fase de Elaboración: se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan los riesgos. Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura.  Fase de Construcción: se basa en la elaboración de un producto totalmente operativo y en la elaboración del manual de usuario. Construir el producto, la arquitectura y los planes, hasta que el producto está listo para ser enviado a la comunidad de usuarios.  Fase de Transición: se realiza la instalación del producto en el cliente y se procede al entrenamiento de los usuarios. Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en esta fase suelen ocurrir cambios. Con estas fases se logra ejecutar un conjunto de mejores prácticas, como lo son:

 Desarrollar Software Iterativamente  Modelar el software visualmente  Gerenciar los Requerimientos  Usar arquitecturas basadas en componentes  Verificacion continua de la calidad  Gerenciar los cambios

Metodología de Booch La Metodología de Booch es una técnica usada en ingeniería de software. Es un lenguaje de modelado de objetos y una metodología ampliamente usada en el diseño de software orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para Rational Software (hoy parte de IBM). Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado, que combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la Ingeniería de software orientada a objetos Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias metodologías y procesos, siendo la principal de ellas el Proceso Racional Unificado (RUP).

Metodología de Booch •

Surge debido a los objetivos de la ingeniería de software –

Entregar un producto Software que satisfaga las necesidades del usuario, de forma eficiente y predecible.

•

Abarca un «microproceso de desarrollo» y un «macroproceso de desarrollo».

•

Fue creado por Grady Booch en 1994, mientras estuvo en Rational Software

Modelos del Método de Booch •

Modelo de Lógica: está representado en la estructura clase-objeto.

•

Modelo Estático: es representado por el diagrama de clase, en el que se construye la arquitectura que se definirá para el sistema.

•

Modelo Dinámico: es representado por el diagrama de objeto que muestra cómo las clases interactúan unas con otras.

El Método de Booch •

Es un ciclo de vida iterativo e incremental, en el cual se mira el desarrollo del producto como una serie de despacho (releases) de arquitectura que evolucionan hacia el sistema final.

•

El cambio se prevé en todas las fases. Se trata de una reducción del riesgo en el proceso impulsado.

Macro-Proceso • •

Engloba una actividad de planificación arquitectónica, que agrupa capas de objetos por nivel de abstracción. Identifica situaciones relevantes.

•

Crea un prototipo de diseño y valida el prototipo aplicándolo a situaciones de uso.

•

Es un proceso de alto nivel.

Micro-Proceso •

Define un conjunto de “reglas” que regulan el uso de operaciones y atributos, de reglas y políticas.

•

Desarrolla situaciones que describen la semántica de las reglas y políticas.

•

Crea un prototipo para cada política.

•

Instrumenta y refina el prototipo.

•

Es un proceso de bajo nivel

Conclusiones •

El método de Análisis y Diseño Orientado a Objetos, desarrollado por Grady Booch, se basa en dividir un solo proceso en un microproceso y un macroproceso.

•

Grady Booch para desarrollar el método de Análisis y Diseño Orientado a Objetos, unió conceptos de otras metodologías, incluyendo su trabajo anterior, Objectory, OMT, entre otros.

•

El método de Booch se basa en el desarrollo iterativo de un sistema, en el cual se mira el producto como una serie de arquitecturas que evolucionan hacia el sistema el desarrollo final.

Extreme Programming (XP) Es una de las metodologías de desarrollo de software más exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto. Características de XP, la metodología se basa en: 

Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.



Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio.



Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.

¿Qué es lo que propone XP? 

Empieza en pequeño y añade funcionalidad con retroalimentación continua



El manejo del cambio se convierte en parte sustantiva del proceso



El costo del cambio no depende de la fase o etapa



No introduce funcionalidades antes que sean necesarias



El cliente o el usuario se convierte en miembro del equipo

Derechos del Cliente 

Decidir que se implementa



Saber el estado real y el progreso del proyecto



Añadir, cambiar o quitar requerimientos en cualquier momento



Obtener lo máximo de cada semana de trabajo



Obtener un sistema funcionando cada 3 o 4 meses

Derechos del Desarrollador 

Decidir cómo se implementan los procesos



Crear el sistema con la mejor calidad posible



Pedir al cliente en cualquier momento aclaraciones de los requerimientos



Estimar el esfuerzo para implementar el sistema



Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodología es: 

La comunicación, entre los usuarios y los desarrolladores



La simplicidad, al desarrollar y codificar los módulos del sistema



La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales

Microsoft Solution Framework (MSF) Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.

Figura 3: Metodología MSF

MSF tiene las siguientes características: 

Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.



Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.



Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.



Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.

MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y finalmente el modelo de Aplicación.



Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones.



Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.



Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberación de versiones y explicando su relación con el Modelo de equipo.



Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar.



Modelo de Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores.



Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores.

Conclusión: 

La Metodología XP en cambio, se recomienda para proyectos de corto plazo.



La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.



Podemos concluir además, que lo más importante antes de elegir la metodología que usarás para la implementación de tu software, es determinar el alcance que tendrá y luego de ahí ver cual es la que más se acomoda en tu aplicación.

Metodologia Agil MSF (Microsoft Solution FrameWork) La metodologia MSF es del tipo de metodologias agiles, esta enfocada a dirigir proyectos o soluciones de innovacion, en ella no se detalla ni se hace enfasis de la organizacion ni el tamaño del equipo de desarrollo, esta mas bien centrada en la gestion y administracion del proyecto para lograr el impacto deseado. Involucra indudablemente la calidad ya que prevee liberar una solucion si esta aun tiene fallos o desperfectos para ello propone seleccionar un grupo de prueba piloto el cual es una VERSION BETA y cumplido un tiempo de prueba ya es liberada la version formal o VERSION ALFA en la cual está garantizada la calidad. Consta de 5 fases:



Vision: En esta fase se debe realizar un estudio de lo que pretendemos en el futuro que haga nuestra aplicacion o nuestro proyecto para ello debemos realizar un documento de estrategia y alcande donde debe quedar pactada la nececidad de funcionalidad y servicio que se debe contar en la solucion. Debemos crear los equipos de trabajo junto con el plan de trabajo, Para asegurar el exito del proyecto es importante tener en cuenta el analisis de riesgos y plan de contingencia.



Planificacion: En esta fase basicamente debemos concreatar claramente como va a estar estructurada nuestra solucion para ello debemos crear un documento de planificacion y diseño de la arquitectura, diseñar las pruebas de concepto donde se plantean los diferentes escenarios para probar la validez de los criterios utilizados para el diseño, debemos establecer metricas.



Desarrollo: En la etapa de desarrollo debemos codificar las aplicaciones y realizar las configuraciones necesarias para que la solucion funcione, es importante hacer pruebas continuamente asi se verifica la calidad del producto continuamente a lo largo del desarrollo y no unicamente al final de el proceso.



Estabilizacion: Esta fase debemos seleccionar el entorno de prueba piloto y lo que pretendemos con esto es identifiar las deficiencias con un grupo reducido de usuarios para corregirlas y asi en el futuro no tener problemas cuando se use la solucion por todos, ocacionalmente a esta etapa se le llama BETA, debemos crear un plan de gestion de incidencias, realizar una revision de documentacion final de la arquitectura y Elaboracion de plan de despliegue o implementacion.



Despliegue o Implementacion: En esta etapa final ya se ha comprobado la calidad de la solucion por lo cual esta lista para ser publicada, en este

sentido debemos liberar la solucion y crear un registro de mejoras y sugerencias, revisar las guias y manuales y entrega de proyecto final. Este ciclo se puede llevar a cabo de forma iterativa, de manera que cuando liberamos una solucion podemos iniciar nuevamente la metodologia para darle mas funcionalidad.

Metodología Kendall & Kendall

“El ciclo de vida de vida del desarrollo de sistemas (SºDLC, Systems Development life cycle) es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall & Kendall) Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse.

FASE I: Identificación de problemas, oportunidades y objetivos FASE II: Determinación de los requerimientos de información FASE III: Análisis de las necesidades del sistema FASE IV: Diseño del sistema recomendado FASE V: Desarrollo y documentación del software FASE VI: Prueba y mantenimiento del sistema

FASE VII: Implementación y evaluación

Metodología UML: La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST (Modeling and Analysis Suite for Real-Time Applications), que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT. Lenguaje Unificado de Modelado (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 y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Es importante resaltar 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 entregando 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, sin embargo, 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.

Lenguaje Unificado de Modelado (LUM o 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, sin embargo, 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.

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos. Leer más: http://www.monografias.com/trabajos5/insof/insof.shtml#ixzz2M7DJzVqc

¿UML es una metodología de desarrollo de software? No, UML no es una metodología de desarrollo y te voy a comentar un poco que es y su origen. En la década de los ochentas y parte de los noventas existieron muchas propuestas de diagramas para realizar analisis y diseño de los mismos. Entonces, es por ahí de 1994 cuando la empresa Rational decide contratar a 3 personas para que con sus propuestas crearan un solo lenguaje para hacer análisis y diseño de sistemas. Algo así como existe una notación especial en la rama de la química con sus fórmulas, o de la música con sus notas, de tal forma que un músico o químico del otro lado del mundo puede interpretar una partitura o una fórmula química de alguien que la escribe aquí en México. Algo así se intentó crear con UML, un lenguaje que pudiera entender cualquier ingeniero de software aquí o en china. Pues bien, quisieron crear un Lenguaje Unificado para el área de análisis y diseño de sistemas de información. Lo cual dio origen a un conjunto de varios diagramas posibles a usar: Diagramas Estructurales • Diagrama de Clases • Diagrama de Objetos • Diagrama de Componentes • Diagrama de Estructura Compuesta • Diagrama de Despliegue • Diagrama de Paquetes • Diagrama de Comportamiento • Diagrama de Interacción • Diagrama de Secuencia • Diagrama de Comunicaciones • Diagrama de Descripción de la Interacción • Diagrama de Tiempos • Diagrama de Actividades • Diagrama de Casos de Uso • Diagrama de Máquina de Estados ¿Es necesario usar todos? No, realmente tu usas los que necesites para representar tu arquitectura del sistema. Entonces que es UML? Es un lenguaje (o conjunto de diagramas) que te sirven para analizar, diseñar e interpretar la arquitectura de un sistema computacional. - Una respuesta más breve, directa que la que te dieron es difícil. Como te lo han dicho: NO. Una metodología busca definir el que y como, estructurar las actividades para conducir el proyecto. En cambio UML es una de las tantas herramientas que uno puede o no utilizarlas. A algunos les resultará tedioso, aburrido, y

hasta innecesario; pero a otros les sirve de mucha ayuda para aclarase las dudas y hacer un mejor análisis y una mejor propuesta.