saber mas sobre el tema

1. ”
INSTITUTO TEGNOLOGICO “SAN GABRIEL
TEMA: METODOLOGIA ORIENTADA A OBJETOS
AUTOR: YOLANDA CANDO
RIOBAMBA – ECUADOR

2. METODOLOGÍA ORIENTADA A OBJETOS
Una metodología de ingeniería del software 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
Que consta de los siguientes elementos:
Un ciclo de vida que permita adaptarse a las reglas de negocio y
factibilidades tecnológicas
Conjunto completo de modelos y conceptos internamente consistentes
Colección de reglas y guías de desarrollo
Notación
Técnicas para pruebas
Métricas apropiadas
Estándares y estrategias de pruebas
Identificación de reglas organizacionales, de reglas de negocios y
programación
Guía de manejo de proyectos y control de calidad.
Metodología OMT
Object Modeling Technique (OMT):

3. 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.

4. 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 las relaciones 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 que 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
Object Oriented Design - Grady Booch

5. 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 iterándose hasta llegar al
estado de refinamiento deseado. El método Booch proporciona un
conjunto de herramientas gráficas y notaciones 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.
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:

6. 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.
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.
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,

7. 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 desuna forma planificada. El RUP se sostiene en los tres puntos
básicos anteriores. Para hacer que funcionen, se necesitan un proceso
polifacético, que tenga en cuenta ciclos, fases, flujos de trabajo, gestión del
riesgo, control de calidad, gestión del proyecto y control de la
configuración. El RUP ha establecido un Framework que integra todas
esas diferentes facetas.
PROCESO UNIFICADO

8. 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

9. 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

10. 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

11. Fusion 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.1
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

12. 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 Fusion 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 Fusion, 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.