· Orientados
a Datos Jerárquicos
Orientados
a Datos No Jerárquicos
1. Orientados a
Datos Jerárquicos: La
estructura de control del programa debe ser jerárquica y debe derivarse de la
estructura de datos. El proceso de diseño consiste en definir primero las estructuras
de entrada y salida, para posteriormente combinarlas con el fin de obtener la
estructura del programa. Finalmente se ordena la lógica procedimental para que
se ajuste a esta estructura. El diseño lógico debe preceder y estar separado
del diseño físico Métodos:
·
JSP (Jackson Structured Programming) y JSD (Jackson
Structured Design) de Jackson (1975)
·
LCP (Logical Construction Program) de Warnier
(1974)
·
LCS (Logical Construction Systems) de Warnier y Orr
(1981)
2. Orientados a
Datos No Jerárquicos: Los
datos son la parte esencial del sistema porque son más estables que los
procesos que actúan sobre ellos. Son una representación de un modelo de datos
de la organización formado por un conjunto de entidades de datos básicas y las
relaciones entre ellas. Los procesos derivan de una definición inicial de los
datos.Métodos:
·
Metodología
Ingeniería de la Información (InformationEngineering - IE) de J. Martin y C.
Finkelstein [Martin,1986.
– Planificación: Se construye una
arquitectura de la información y una estrategia que soporte los objetivos de la
organización – Análisis: Se comprenden las áreas de negocio y se determinan los
requisitos del sistema – Diseño: Se establece el comportamiento del sistema
deseado por el usuario y que sea alcanzable por la tecnología
– Construcción: Se construye el
sistema que cumpla los tres niveles anteriores
·
Orientados
a Datos Jerárquicos
·
Orientados
a Datos No Jerárquicos
1. Orientados a
Datos Jerárquicos: La
estructura de control del programa debe ser jerárquica y debe derivarse de la
estructura de datos. El proceso de diseño consiste en definir primero las estructuras
de entrada y salida, para posteriormente combinarlas con el fin de obtener la
estructura del programa. Finalmente se ordena la lógica procedimental para que
se ajuste a esta estructura. El diseño lógico debe preceder y estar separado
del diseño físico Métodos:
·
JSP (Jackson Structured Programming) y JSD (Jackson
Structured Design) de Jackson (1975)
·
LCP (Logical Construction Program) de Warnier
(1974)
·
LCS (Logical Construction Systems) de Warnier y Orr
(1981)
2. Orientados a
Datos No Jerárquicos: Los
datos son la parte esencial del sistema porque son más estables que los
procesos que actúan sobre ellos. Son una representación de un modelo de datos
de la organización formado por un conjunto de entidades de datos básicas y las
relaciones entre ellas. Los procesos derivan de una definición inicial de los
datos.Métodos:
·
Metodología
Ingeniería de la Información (InformationEngineering - IE) de J. Martin y C.
Finkelstein [Martin,1986.
– Planificación: Se construye una
arquitectura de la información y una estrategia que soporte los objetivos de la
organización – Análisis: Se comprenden las áreas de negocio y se determinan los
requisitos del sistema – Diseño: Se establece el comportamiento del sistema
deseado por el usuario y que sea alcanzable por la tecnología
– Construcción: Se construye el
sistema que cumpla los tres niveles anteriores
PRINCIPALES METODOLOGÍAS DE DESARROLLO.
4.1.- Metodología MERISE.
Esta metodología surge en Francia en 1977 a propuesta del Ministerio de Industria, como un intento de unificar criterios en torno a la metodología de desarrollo para los sistemas informáticos de la Administración Pública Francesa.
Sus principios generales son:
- Desglose en etapas: estudio preliminar, estudio detallado, realización y puesta en marcha.
- División en el estudio de los tratamientos por un lado y el estudio de los datos por otro.
- Uso del modelo Entidad/Relación y sus formalismos para representar los datos.
- Uso de los Diagramas de Encadenamiento de Procedimientos para representar los tratamientos.
- Completo reparto de tareas y responsabilidades entre los desarrolladores durante la fase inicial, y entre los ususarios y ordenador en la explotación. (Esquema director)
| NIVEL | TRATAMIENTOS | DATOS | OPCIÓN |
| CONCEPTUAL | Modelo Conceptual | Modelo Conceptual | De gestión |
| ORGANIZACIONAL | Modelo Organizacional | Modelo Lógico | De organización |
| OPERACIONAL | Modelo Operacional | Modelo Físico | Técnica |
4.2.- Metodología SSADM. (Método Estructurado de Análisis y Diseño de Sistemas).
Aparece en Gran Bretaña por los mismos motivos que MERISE y se establece como obligatoria para la Administración Pública a partir de 1983.
Los aspectos claves de esta metodología son:
- Énfasis en los usuarios: sus requisitos y participación.
- Definición del proceso de producción.
- Tres puntos de vista: datos, eventos y procesos.
- Máxima flexibilidad en herramientas y técnicas de implementación.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero no cubre aspectos como la planificación estratégica ni entra en la construcción del código.
METODOLOGIA METRICA
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):
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 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
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:
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,
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
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
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
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.
No hay comentarios.:
Publicar un comentario