texto argumentativo, ejemplos y ejercicios prácticos
Metodologia ROM
1. Universidad Nororiental Privada Gran Mariscal de Ayacucho
Facultad Ingeniería
Escuela: Ingeniería en sistemas
VIII Semestre Sección n° 5s2231
Asignatura: Sistema de Información
Profesor:
Integrantes:
Molina José
Adams Karleydis CI:20.557.778
Álvarez Gabriela CI:20.886.548
González Dorvis CI:20.494.823
Genatio Juan CI:21.068.405
Ciudad Bolívar, Abril 2012
2. Este trabajo describe las bases de una metodología (ROM) y
de un repositorio (Tesauro de Software) para el tratamiento y
gestión integral de componentes de software, considerados
como documentos multimedia, con aplicación directa a la
recuperación de cualquier componente del proyecto de
software.
Álvarez Gabriela 2
3. Utilización de las
Paradigmas de técnicas de
funcionamiento Orientación a
Objetos
Los conceptos
Los atributos son
permiten modelar
propiedades
funcionalidad y
permanentes
datos
Las acciones Modelado de
modelan la procesos mediante
funcionalidad eventos
Aplicación
Desarrollo de
generalizada de las
Software
clases
Álvarez Gabriela 3
4. El modelado conceptual constituye la fase de análisis del sistema,
y pretende determinar exactamente los conceptos y procesos
fundamentales de un problema para su posterior representación
[RUMB91], [ROBI94], [BOOC91].
Modelado Modelado
Estático Dinámico
Álvarez Gabriela 4
5. • El Interfaz • Las clases • Las clases • Las clases
gráfico de gráficas, por gráficas se gráficas
usuario (GUI) su propia programan aplican los
se compone estructura, mediante la principios de
de objetos son ocurrencia de la Orientación
gráficos. encapsuladas. eventos. a Objetos.
Álvarez Gabriela 5
7. Para poder aplicar todas las posibilidades que proporciona la
utilización de los Tesauros de Descriptores al análisis, diseño y
desarrollo de un proyecto de software, resulta necesario diseñar
una estructura más compleja que la ya definida para los Tesauros
clásicos.
Objetivo
• Es traducir las especificaciones de alto nivel
que definen un problema informático a
consultas contra dicha estructura de
información
González Dorvis 7
9. Los atributos
que lo
caracterizan
Las
restricciones
que posee Atributos y
Variables
Las
Conceptos interrelaciones
que le afectan Los atributos
caracterizan a las
entidades
Las acciones
que posibilita
El
comportamiento
que modela González Dorvis 9
10. Jerarquías Todo
/ Parte
(agregación)
Jerarquías de
Interrelación de
Generalización /
Jerarquía
Especialización
Jerarquías
Enumerativas
Interrelaciones
entre Conceptos Asociaciones
Permanentes
Interrelación de
Asociación
Asociaciones
Circunstanciales
Interrelación de
equivalencia
González Dorvis 10
11. Estados de una entidad
o de un objeto Acciones
Eventos
• Eventos Externos Procesos
• Eventos Internos
González Dorvis 11
12. Clases gráficas: Objetos
gráficos
Ventanas
Visualizadores
Activadores
Fuentes de Datos
González Dorvis 12
13. Los eventos y acciones
que determinan el
funcionamiento de cada
clase gráfica son
encapsulados en la misma,
y representan la
funcionalidad propia del
objeto gráfico, no la
funcionalidad de una
determinada aplicación.
Adams Karleydis 13
14. Modelado Modelado
Estático Dinámico
Modelado El sistema permite En los entornos actuales de
programación se trabaja
Conceptual localizar, seleccionar y
configurar un modelo de fundamentalmente en dos
datos completo con procedimiento:
conceptos, atributos e Top-Down y Bottom-Up
interrelaciones
Aproximación In-Out
Adams Karleydis 14
15. Diseño
En el diseño las tareas que considera ROM son:
Diseño del nivel conceptual de la base de
datos
Modelado Gráfico
Diseño del Data-GUI (DGUI)
Diseño del Processes-GUI (PGUI)
Adams Karleydis 16
16. P
R
O
T
O
T
I
P
A
D
O
Los conceptos que representan en el Tesauro Los conceptos no gráficos del esquema se
de Software información grafica se traducen en clases no graficas (Funtional
implementan en ROM mediante clases Class), que incorporar toda la funcionalidad
graficas (Windows Class) seleccionada en el esquema de alto nivel
Si una clase posee atributos, se derivara hacia
una de tipo Data Source
Adams Karleydis 17
17. Reutilización
Un componente se
considera reutilizado cuando se
introduce en el nuevo esquema
junto con toda la información que
posee, bien por sí mismo, bien
por el esquema en el que se
encuentra.
Genatio Juan 18
18. Recuperación
Un componente se
considera recuperado, pero no
reutilizado, cuando se introduce en
el nuevo esquema después de haber
sido localizado en el Tesauro de
Software por alguno de los criterios
de búsqueda que se proporcionan.
Genatio Juan 19
19. Creación
Un componente se
considera creado cuando es la
primera vez que se utiliza como tal
en un esquema.
Genatio Juan 20