2.6. La creación de bases de datos.

Con los antecedentes señalados, se inicia la creación de las bases de datos. En primer
lugar, y acorde con los diferentes niveles de arquitectura de bases de datos
reseñados, tiene lugar la construcción del modelo y del esquema conceptual de la
base de datos (REINGRUBER y GREGORY, 1994):

El esquema conceptual.

El esquema conceptual puede definirse como una descripción abstracta y general de

la parte o sector del universo real que el contenido de la base de datos va a
representar, llamada en ocasiones "universo del discurso". En este nivel de análisis se
está tratando con una descripción de la realidad, no con datos, y suele contener listas
de tipos de entidades, de las relaciones existentes entre esas entidades y de las
restricciones de integridad que se aplican sobre ellas. El esquema conceptual de la
base de datos puede utilizarse para integrar los intereses de los diferentes usuarios,
como herramienta de representación y de formación, así como para prever futuras
modificaciones del sistema. En el aspecto de la representación, lo más interesante es
utilizar algún tipo de especificación formal en sentido matemático, lo que facilita la
consistencia y los análisis lógicos de los esquemas propuestos. Del esquema
conceptual formalizado pueden derivarse diferentes subesquemas conceptuales, que
representan aquellas partes del esquema conceptual de interés para un usuario o
grupo de usuarios finales.

El esquema de la base de datos.

Una vez construido el esquema conceptual, el diseño de bases de datos obliga a

realizar varias tareas previas a la construcción del esquema lógico global del sistema,
también llamado esquema de bases de datos. Por el momento, basta saber que el
esquema de la base de datos representa la descripción de los datos de la base de
datos, mientras que el esquema conceptual representaba a la realidad. La primera de
las tareas necesarias es la identificación de los datos requeridos, para obtener como
resultado las partes del área de aplicación que deben representarse mediante datos, y
en que forma deben presentarse éstos a los usuarios. El siguiente paso es el análisis
de datos, consistente en la definición y clasificación de esos datos, su descripción, que
suele presentarse en forma de diccionario de datos, como una "metabase de datos".
Por último, debe hacerse la especificación de los paquetes de entrada y de salida,
correspondientes con los datos que deben introducir y obtener como respuesta los
usuarios, según sus necesidades. Las tres tareas habrán permitido obtener tres
documentos sobre descripción del área de aplicación, definición y clasificación de los
datos y especificación de las características de los diversos paquetes,
respectivamente. Tomando como punto de partida estos tres elementos, se construye
la especificación de esquema de la base de datos, que responderá al contenido total
de la base de datos y las características de las vías de acceso requeridas a través de
estos datos. Frente al análisis de datos, que es la definición y clasificación de los
datos, el esquema se encarga de la utilización de esos datos.
. El diccionario de recursos de información (MIGUEL y PIATTINI, 1995).

La gestión efectiva de los datos involucrados en la base de datos implica

necesariamente disponer de alguna herramienta que controle las características y
funciones de aquéllos. Esta función es cubierta mediante el diccionario de recursos de
información (DRI),que asegura la integración de toda la información contenida en el
sistema. Se habla entonces de metadatos, como datos que definen y describen los
datos existentes en el sistema. En un primer momento, este tipo de cuestiones eran
resueltas a través de los diccionarios de datos, que reunían información sobre los
datos almacenados, sus descripciones, significados, restricciones, usos, etc., y los
directorios de datos, subsistemas del sistema de gestión, encargados de describir
dónde y cómo se almacenaban los datos, Actualmente se aplica el concepto de
diccionario de recursos de información, que engloban todo lo señalado anteriormente,
dando lugar a lo que ha pasado a llamarse "metabases".

El enfoque de tratamiento de los datos.

La construcción de los modelos conceptual y lógico de las bases de datos requiere la

adopción de un determinado enfoque para la descripción y el tratamiento de los datos.
Sin embargo, es necesario insistir en que la modelización de datos se orienta al
conocimiento en profundidad de los datos que va a manejar la organización, para
lograr una implantación óptima. La unión del modelo de datos con el sistema de
gestión de base de datos dará como resultado la base de datos real. El modelo de
datos será una representación gráfica orientada a la obtención de las estructuras de
datos de forma metódica y sencilla, agrupando esos datos en entidades identificables
e individualizables, y será reflejo del sistema de información en estudio.

. Diccionario de datos.
Contiene las características lógicas de los sitios donde se almacenan los datos del
sistema, incluyendo nombre, descripción, alias, contenido y organización. Identifica los
procesos donde se emplean los datos y los sitios donde se necesita el acceso
inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia
a los analistas que participan en la determinación de los requerimientos del sistema,
su contenido también se emplea durante el diseño.

Razones para su utilización:

1. Para manejar los detalles en sistemas muy grandes, ya que tienen enormes
cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de
datos.

Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los
detalles. Por eso se registra la información, ya sea sobre hoja de papel o usando
procesadores de texto. Los analistas mas organizados usan el diccionario de
datos automatizados diseñados específicamente para el análisis y diseño de
software.

2. Para asignarle un solo significado a cada uno de los elementos y actividades del
sistema.

Los diccionarios de datos proporcionan asistencia para asegurar significados

comunes para los elementos y actividades del sistema y registrando detalles
adicionales relacionadas con el flujo de datos en el sistema, de tal manera que
todo pueda localizarse con rapidez.

3. Para documentar las características del sistema, incluyendo partes o

componentes así como los aspectos que los distinguen. Tambien es necesario
saber bajo que circunstancias se lleva a cabo cada proceso y con que
frecuencia ocurren. Produciendo una comprensión mas completa. Una vez que
las características están articuladas y registradas, todos los participantes en el
proyecto tendrán una fuente común de información con respecto al sistema.

4. Para facilitar el análisis de los detalles con la finalidad de evaluar las

características y determinar donde efectuar cambios en el sistema.

Determina si son necesarias nuevas características o si están en orden los

cambios de cualquier tipo.

Se abordan las características:

* Naturaleza de las transacciones: las actividades de la empresa que se llevan a

cabo mientras se emplea el sistema.

* Preguntas: solicitudes para la recuperación o procesamiento de información

para generar una respuesta especifica.

* Archivos y bases de datos: detalles de las transacciones y registros maestros

que son de interés para la organización.

* Capacidad del sistema: Habilidad del sistema para aceptar, procesar y

almacenar transacciones y datos
5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan
en un informe. Aun en los manuales, se revelan errores.

Contenido de un registro del diccionario

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son
los elementos datos y estructura de datos.

Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si
mismos no le dan un significado suficiente al usuario. Se agrupan para formar una
estructura de datos.

Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que

describen los datos utilizados o producidos por el sistema.

Cada uno esta identificado con:

Un nombre: para distinguir un dato de otro.

Descripción: indica lo que representa en el sistema.

Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este
dato.

Longitud: porque es de importancia de saber la cantidad de espacio necesario para

cada dato.

Valores de los datos: porque en algunos procesos solo son permitidos valores muy
específicos para los datos. Si los valores de los datos están restringidos a un intervalo
especifico, esto debe estar en la entrada del diccionario.

Estructura de datos: es un grupo de datos que están relacionados con otros y que en
conjunto describen un componente del sistema.

Descripción:

Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las

siguientes combinaciones ya sea individualmente o en conjunción con alguna otra.

Relación secuencial: define los componentes que siempre se incluyen en una

estructura de datos.

Relación de selección: (uno u otro), define las alternativas para datos o estructuras de
datos incluidos en una estructura de datos.

Relación de iteración: (repetitiva), define la repetición de un componente.

Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna
iteración.

Notación

Los analistas usan símbolos especiales con la finalidad de no usar demasiada cantidad
de texto para la descripción de las relaciones entre datos y mostrar con claridad las
relaciones estructurales. En algunos casos se emplean términos diferentes para
describir la misma entidad (alias) estos se representan con un signo igual (=) que
vincula los datos.

8. Diagrama de estructura de datos

Es una descripción de la relación entre entidades (personas, lugares, eventos y

objetos) de un sistema y el conjunto de información relacionado con la entidad.

Finalidades:

1. Verificar los requerimientos de información.

2. Describir los datos asociados con las entidades.
3. Mostrar la relación entre entidades.
4. Comunicar los requerimientos de datos a un diseñador de archivos o
administrador de la base de datos.

Notación

Una común se usa al preparar los diagramas de estructura de datos. Las entidades se
representan mediante rectángulos, con el nombre de la entidad en la parte de arriba y
una lista de atributos que describan la entidad. Cada entidad se puede identificar
mediante un atributo llave.

Uso en el diseño de archivo.

El uso de los diagramas de estructura de datos requiere que el analista haga

preguntas importantes acerca de la entidad a describir. La llave de registro, identifica
de una forma única a la cuenta. Los demás detalles son los atributos.

Además de los componentes básicos existen dos elementos adicionales esenciales:

* Apuntadores atributos: enlazan dos entidades mediante la información común,

usualmente un atributo llave en uno y un atributo (no llave) en el otro.

* Apuntadores lógicos: identifican las relaciones entre las entidades, sirven para
obtener acceso inmediato a la información en una entidad, definiendo un atributo
llave en otra entidad.

Usualmente se indican en la parte inferior del diagrama, son los enlaces con las
demás entidades incluidas en el diagrama.

Compartir datos entre las aplicaciones.

Cada sistema se puede desarrollar por separado, guardando los datos de los estados
de cuenta aparte de los datos del inventario. Al desarrollar mas sistemas y crecer su
utilidad, muy seguido existe la necesidad de integrar los sistemas para permitir que la
información sea compartida por mas de un sistema.

Redundancia e integridad:

Si cada sistema se desarrolla en forma independiente, la información puede ser

almacenada al menos una vez en cada sistema, éste además de requerir espacio de
almacenamiento extra, esta duplicación es llamada redundancia, para reducir la
integridad de la información; cuando se duplica información es muy probable de que
los detalles no coincidan o que no todos sean actualizados. Resultando la perdida de
integridad en los datos, pudiendo ser corregido mejorando los procedimientos.

Se puede evitar del todo disminuyendo la redundancia de datos en los archivos.

9. Gráfica de estructura

Muestra con símbolos la relación entre los módulos de procesamiento y el software de

la computadora. Describen la jerarquía de los módulos componentes y los datos que
serán transmitidos entre ellos. Incluye el análisis de las transformaciones entrada-
salida y el análisis de transacción.
Las flechas con una circunferencia indican datos, mientras que las que tienen un
circulo representa información de control de programa, tales como notas o
condiciones de error.

Diagrama de contexto

Se pueden usar diagramas de flujos de datos para representar el sistema a cualquier

nivel de abstracción. El diagrama de flujo de dato de nivel 0 se llama diagrama de
contexto y en él el sistema esta representado por un solo proceso, que identifica cual
es la función principal del sistema, mostrando además, los flujos de información que lo
relacionan con otros sistemas: las entidades externas. El diagrama de contexto tiene
una gran importancia puesto que resume el requisito principal del sistema de recibir
ciertas entradas, procesarlas de acuerdo con determinada función y generar ciertas
salidas. A partir del diagrama de contexto se puede ir construyendo nuevos diagramas
que vayan definiendo con mayor nivel de detalle lo flujos de datos y procesos de
transformación que ocurren en el sistema, de forma que al final obtenemos una
jerarquía de diagramas.

Método del desarrollo por prototipos

Los sistemas pueden desarrollarse con métodos y lenguajes de programación

convencionales, aunque no tengan todas las características y toques finales de un
sistema terminado. Quizás los informes no tengan encabezados, logos, etc., falten
controles de entradas y procesamiento. Lo importante es el ensayo, y hallar los
requerimientos.
Los generadores de aplicaciones, son programas que sirven para hacer otros
programas, son un apoyo en la construcción de prototipos, permitiendo definir la
estructura visual de las pantallas, los registros de entrada y el formato de los
informes.En algunos casos donde el sistema no será utilizado frecuentemente, puede
convertirse el prototipo en el sistema terminado, o bien, cuando no son muchos los
beneficios que se obtienen.

Razones para desarrollar prototipos de sistemas

Los requerimientos de información no siempre están bien definidos, pueden ser

demasiados vagos aún al formular el diseño. En otros casos, es probable que una
investigación de sistemas bien llevada, de como resultado un conjunto muy amplio de
requerimientos de sistemas, pero construir un sistema que satisfaga a todos ellos
quizás necesite del desarrollo de nueva tecnología.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de
diseñar e implantar sistemas no tienen información ni experiencia, o también donde
existen situaciones de riesgo y costos elevados, y aquellas donde el diseño propuesto
es novedoso y aún no ha sido probada.
La información obtenida con su uso se aplica en un nuevo diseño que se emplea, otra
vez, como prototipo y que revela más información valiosa sobre diseño. El proceso se
repite las veces que sea necesario para revelar los requerimientos esenciales del
diseño.

Maquetas
Cuando se comienza el desarrollo, tiene por objetivo presentar a los usuarios y/o
clientes la apariencia del sistema final. Los usuarios pueden manifestar su
opinión.Ambos métodos son muy útiles para establecer la viabilidad del proyecto y
definir acuerdos sobre los objetivos y resultados esperados.

10. Etapas del método de prototipos

1- Identificación de requerimientos conocido.

La determinación de los requerimientos de una aplicación es tan importante para el

método de desarrollo de prototipo como lo es para los métodos del ciclo clásico de
desarrollo de sistemas o análisis estructurado (aunque las tácticas son diferentes). Por
consiguiente, antes de crear el prototipo, los analistas y usuarios deben trabajar
juntos para identificar los requerimientos conocidos que tiene que satisfacerse. Para
hacerlo determinan los fines para lo que servirá el sistema y el alcance de sus
capacidades.

2- Desarrollo de un modelo de trabajo

Es útil comenzar el proceso de construcción del prototipo con el desarrollo de un plan

general que permita a las personas conocer lo que se espera de ellas y del proceso de
desarrollo. Es difícil, y en ocasiones imposibles, fijar una fecha tentativa de
terminación. La experiencia con el sistema es la que determina eventualmente cuando
en sistema esta terminado.

Para comenzar la primera iteración, usuarios y analistas identifican de manera

conjunta los datos que son necesarios para el sistema y especifican la salida que debe
producir la aplicación.

Las decisiones de diseño necesarias para desarrollar la salida del sistema cambian
muy poco en relación con las tomadas en otros métodos de desarrollo. Sin embargo,
con un prototipo, se espera que las especificaciones iniciales estén incompletas.

En el desarrollo de un prototipo se preparan los siguientes componentes:

*El lenguaje para el diálogo o conversación entre el usuario y el sistema

*Pantallas y formato para la entrada de datos

*módulos esenciales de procesamiento

*Salida del sistema

Al construir el prototipo se deben seguir los estándares para datos que emplea la
organización.

En esta etapa es más importante la rapidez con que se construye el prototipo que la
eficiencia de operación. Es por esto que el analista no intenta optimizar la velocidad
de operación del sistema
Durante la evaluación los analistas de sistemas desean capturar 3)El prototipo y el
usuario

Es responsabilidad del usuario trabajar con prototipo y evaluar su característica y

operación. La experiencia con el sistema bajo condiciones permite obtener la
familiaridad indispensable para determinar los cambios o mejoras que sean necesarios
así como la eliminación de características inadecuadas o innecesarias.

4)Revisión del prototipo

información sobre los que les gusta y los que les desagrada a los usuarios. La
información obtenida tendrá influencia sobre las características de la siguiente versión
de la aplicación.

Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo. El
analista es el responsable de realizar las modificaciones.

5) Repetición del proceso las veces que sea necesario.

El proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema
ha evolucionado lo suficiente como para incluir todas las características necesarias o
cuando ya es evidente que no se obtendrá mayor beneficio.

6) El abandono o dejarlo como esta:

Cuando se verifica de que no es posible desarrollar el sistema para satisfacer los

objetivos deseados, ya sea por la tecnología existente o por el factor economico.

11. Coordinación y Gestión del proyecto.

La gestión del proyecto presupone establecer condiciones para el desarrollo del

mismo. Involucra actividades de: planificación, estimación de recursos, seguimiento y
control y evaluación del proyecto.

• La planificación de proyectos se define como la predicción de la duración de las

actividades y tareas a nivel individual.
• La estimación se define como la predicción de personal, esfuerzo y costo que se
requerirá para terminar todas las actividades y productos conocidos asociados
con el proyecto. El tamaño del producto a desarrollar es una de las primeras
tareas en la gestión del proyecto. El tamaño se define como la cantidad de
código fuente, especificaciones, casos de prueba, documentación del usuario y
otros productos tangibles que son salida del proyecto, éste se basa
principalmente en la experiencia de proyecto anteriores.
• El seguimiento de proyectos es la recolección de datos y su acumulación sobre
recursos consumidos, costos generados asociados con un proyecto. La medición
en los proyectos de desarrollo de software es una actividad fundamental para la
mejora de la productividad, el costo y la calidad del producto final.

Proceso de Iniciación del Proyecto.

Abarca aquellas actividades de creación de la estructura del proyecto. Durante este
ciclo se define el ciclo de vida del software para este proyecto y se establecen en los
planes para su gestión. Se estiman y asignan los recursos necesarios a fin de ejecutar
las distintas tareas que demanda el proyecto. Se identifican y seleccionan estándares,
metodologías y herramientas para la gestión y ejecución del mismo y, por último, se
prepara y establece un plan para su implementación adecuada y oportuna. El plan de
Gestión del Proyecto Software que conducirá el desarrollo se produce como
culminación de este proceso.

12. Mediciones y estimaciones

El software al ser intangible, no tener peso, ni volumen, ni superficie, etc. se mide a

través de diversos aspectos clave en el desarrollo. La medición determina cuales son
los aspectos y proporcionan métodos para medirlos.

La medición y estimación atacan los tres problemas claves de la ingeniería del

software:

1. Estimar costos y recursos en un proyecto software

2. Garantizar la calidad del producto final
3. Mejorar la productividad del ingeniero de software durante el desarrollo.

Teniendo en cuenta estos objetivos, las métricas se centran en cuatro aspectos:

Para estimar los recursos es necesario tener en cuenta una serie de factores de riesgo
que influyen sustancialmente en la precisión de las estimaciones de los recursos
humanos necesarios para la realización del proyecto. Los mas importantes son:

*Complejidad de la tarea.

*Modificaciones permitidas a lo largo del desarrollo

*Experiencia previa de los desarrolladores

*Duración fijada del proyecto.

*Estructuración del problema y de las tareas.

*Disponibilidad de datos e información suministrada por el usuario.

*Disponibilidad y facilidad de comunicación con el usuario.

Además de las fases estándar del desarrollo, hay que tener en cuenta la coordinación
y seguimiento del proyecto que suponen una importante carga de trabajo y que son
olvidadas durante la planificación o no se le dedica mucho.

El costo global se compone de las partidas de viajes, hardware (nuevo o

actualización), software (en caso de comprar algún paquete para el desarrollo), gastos
comunes, y personal que es el mas influyente, ya que el costo de un proyecto es
directamente proporcional a los recursos humanos.

El proceso engloba todas las actividades y fases que se llevan a cabo durante la
realización del proyecto. Se persigue determinar si en cada fase los resultados
producidos se corresponden con los esperados y en establecer un control sobre los
recursos estimados para cada una de las fases.

El producto incluye cualquier documento o software desarrollado que se genere

durante el proceso completo. En las medidas de productos software existen medidas
directas (costo del proyecto, esfuerzo empleado, líneas de código implementadas,
etc.) y medidas indirectas f( funcionalidad, fiabilidad, eficiencia, facilidad de
mantenimiento, etc.).

Herramientas para el desarrollo de sistemas

Las herramientas son cualquier dispositivo que, empleándose adecuadamente, mejora

el desempeño del desarrollo de sistemas de información.

Se agrupan en las tres siguientes herramientas automatizadas:

Herramientas de tipo Front-end

Automatizan las primeras actividades del proceso de desarrollo de sistemas.

Esta herramienta proporciona soporte para el desarrollo de modelos gráficos de

sistemas y procesos

Los diagramas de flujo son representativos de este tipo de herramientas.

Herramientas para análisis

Éstas herramientas ayudan a los especialistas en sistemas a documentar un sistema

existente, ya sea manual o automatizado. También sirve para determinar los
requerimientos de una nueva aplicación. Incluye:

- Herramientas para recolección de datos: capturan detalles que describen sistemas y

procedimientos en uso. Documentan procesos y actividades de decisión, se utilizan
para apoyar la tarea de identificar requerimientos.

- Herramientas para diagramación: crean representaciones gráficas de sistemas y

actividades. Apoyan el dibujo y revisión de diagramas de flujos de datos e iconos
asociados con el análisis estructurado. Incluyen programas para representación en
diagramas de flujo.

- Herramientas para el diccionario: registran y mantienen descripciones de los

elementos del sistema, como grupo de datos, procesos, alimentos de datos, etc.
Frecuentemente proporcionan la capacidad de examinar las descripciones del sistema,
para decidir si son incompletas o inconsistentes.

Herramientas para diseño

Apoyan el proceso de formular las características que el sistema debe tener para
satisfacer los requerimientos deseados durante las actividades de análisis. Incluye:

- Herramienta de especificación: apoyan el proceso de formular las características,

como por ejemplo deben tener una aplicación como entradas, salidas, procesamientos
específicos de control.

- Herramienta para presentación: se utilizan para describir la posición de datos,

mensajes, y encabezados sobre las pantallas de las terminales, informes y otros
medios de entradas y salidas.

Los analistas utilizan las herramientas para el diseño de sistemas desde el inicio de la
era de las computadoras. Ahora a las herramientas se le están dando un nuevo
significado en el diseño de software.

Herramientas de tipo back-end

Su finalidad es ayudar al analista a formular la lógica del programa, los algoritmos de

procesamiento y la descripción física de datos.

Tambien ayudan a la intersección con los dispositivos (para entrada y salida). Estas
actividades convierten los diseños lógicos del software en un código de programación;
este es que da existencia a la aplicación.

Herramientas para el desarrollo

Ayudan al analista a trasladar los diseños en aplicaciones funcionales. Incluye:

- Herramientas para ingeniería Software: apoyan el proceso de formular diseños de

software, incluyendo procesamientos y controles.

- Generadores de códigos: producen el código fuente y las aplicaciones a partir de

especificaciones funcionales bien articuladas

- Herramientas para pruebas: apoyan la fase evaluación de un sistema. Incluyen

facilidades para examinar la correcta operación del sistema.

Herramientas integrales

Proporcionan un ambiente que automatiza tareas claves a lo largo del proceso de

desarrollo. Estas herramientas facilitan el diseño, administración y mantenimiento del
código. Brinda un ambiente eficiente para crear, almacenar, manipular y documentar
sistemas.
13. Reingeniería e ingeniería inversa

Los conceptos de reingeniería e ingeniería inversa están ligados al desarrollo de

software a gran escala, donde una mejora en proceso de este desarrollo supone un
aumento en la competitividad de la empresa.

Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo
(normalmente de uno a dos años) ambas actividades, están orientadas a automatizar
el mantenimiento de aplicaciones. Esta es una tarea que consume gran cantidad de
recursos, por lo que cualquier reducción en el tiempo y recursos empleados en ella
supone una importante mejora en la productividad del proceso. Este es el principal
objetivo de la reingeniería. Se trata, de analizar el código o el diseño actual y
modificarlo con la ayuda de herramientas automáticas para traducirlos a códigos mas
estructurados, y más eficientes.

Dentro de la reingeniería, el proceso de pasar del código a una descripción de mas

alto nivel es lo que se denomina:

Ingeniería inversa.

La reingeniería e ingeniería inversa prolongan la vida del software.

Dado que es una labor estratégica, es conveniente conocer cuando conviene realizar
la tarea de reingeniería para una aplicación y cuándo es más rentable sustituirla e
implementar una nueva. Las aplicaciones para el primer paso, son aquellas en la que
se produce las siguientes situaciones:

• Fallos frecuentes, que son difíciles de localizar

• Son poco eficientes, pero realizan la función esperada
• Dificultades en la integración con otros sistemas
• Calidad pobre del software final
• Resistencia a introducir cambios
• Pocas personas capacitadas para realizar modificaciones
• Dificultades para realizar pruebas
• El mantenimiento consume muchos recursos
• Es necesario incluir nuevos requisitos, pero los básicos se mantienen.
Desarrollo de software con y para reuso

El desarrollo de software con reúso consiste en desarrollar una aplicación usando

software ya existente. Cualquier profesional lo utiliza

El desarrollo de software para reuso consiste en la construcción de un sistema con la

intención de reutilizar partes de él en futuros desarrollos. Con software a gran escala,
un buen profesional con experiencia puede desarrollarlo.

Estudios realizados determinan que la práctica de reutilización del software en un

proyecto aumenta la productividad durante el desarrollo de dicho proyecto.

Sin embargo, la reutilización del software no cubre solo el reuso de códigos, abarca
todo un amplio de posibilidades en los diferentes niveles, metodología, ciclos de vida,
planes del proyecto, especificaciones de requisitos, diseños, arquitectura software,
planes de validación, juegos de prueba y documentación.

Diccionario de datos

Los diccionarios de datos son el segundo componente del análisis del

flujo de datos. En sí mismos los diagramas de flujo de datos no describen por
completo el objeto de la investigación. El diccionario de datos proporciona
información adicional sobre el sistema. Esta sección analiza que es un
diccionario de datos, por qué se necesita en el análisis de flujo de datos y como
desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir
los diccionarios de datos.

Un diccionario de datos es una lista de todos los elementos incluido en el

conjunto de los diagramas de flujo de datos que describen un sistema. Los
elementos principales en un sistema, estudiados en las secciones anteriores,
son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario
de datos almacena detalles y descripciones de estos elementos.

Si los analistas desean conocer cuántos caracteres hay en un dato, con

qué otros nombres se le conocen en el sistema, o en donde se utilizan dentro
del sistema deben ser capaces de encontrar la respuesta en un diccionario de
datos desarrollado apropiadamente.

El diccionario de dato se desarrolla durante el análisis de flujo de datos y

ayuda el analista involucrado en la determinación de los requerimientos de
sistemas. Sin embargo, como se verá más adelante, también el contenido del
diccionario de datos se utiliza durante el diseño del sistema.

En informática, base de datos acerca de la terminología que se utilizará

en un sistema de información. Para comprender mejor el significado de un
diccionario de datos, puede considerarse su contenido como "datos acerca de
los datos"; es decir, descripciones de todos los demás objetos (archivos,
programas, informes, sinónimos...) existentes en el sistema. Un diccionario de
datos almacena la totalidad de los diversos esquemas y especificaciones de
archivos, así como sus ubicaciones. Si es completo incluye también
información acerca de qué programas utilizan qué datos, y qué usuarios están
interesados en unos u otros informes. Por lo general, el diccionario de datos
está integrado en el sistema de información que describe.

Descripción de los Datos en el Diccionario

Cada entrada en el diccionario de dato consiste en un conjunto de

detalles que describen los datos utilizados o producidos en el sistema. Cada
artículo se identifica por un nombre de dato, descripción, sinónimo y longitud
de campo y tiene valores específicos que se permiten para éste en el sistema
estudiado.

Qué es la Arquitectura del Software y que relación tiene con la

usabilidad. Tener en cuenta la usabilidad en el momento del diseño de
la arquitectura de un sistema interactivo nos puede ahorrar muchos
quebraderos de cabeza.

El Iceberg de la usabilidad

Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en

cuenta:

• la presentación de la información
• la funcionalidad de la aplicación
• la Arquitectura del Software

Hasta hace poco, se asumía que la usabilidad era una propiedad

exclusiva de la presentación de la información. Se creía que, encapsulando la
capa de presentación y separándola del resto, se podía desarrollar la aplicación
y, de forma iterativa, pasar los tests de usabilidad. Tras cada test, tan sólo
sería necesario resolver los problemas modificando la presentación y, gracias a
esta separación, la funcionalidad no quedaría afectada.

Dick Berry, en su analogía del Iceberg de la usabilidad, explica que los

aspectos relacionados con la presentación, es decir, lo que normalmente
entendemos como look & feel, sólo afectan en un 40% a la usabilidad. El 60%
restante está influenciado por lo que él llama “modelo del usuario”, que está
constituido por los objetivos que el usuario quiere alcanzar con sus tareas.
 Berry relaciona el modelo del usuario con el modelo de objetos propio de
la interfaz de usuario, en el sentido estricto de la OOP (programación orientada
a objetos), que incluye, entre otras cosas, los objetos y las metáforas de la
interfaz.

Este modelo de objetos, siempre según Berry, es el que permite al

usuario relacionar sus objetivos con la funcionalidad del sistema.

Por lo tanto, y para conseguir una buena usabilidad, no basta con tener en
cuenta la capa de presentación, sino que es preciso que la usabilidad se
contemple también en el momento de la definición de la funcionalidad de la
aplicación.

Usabilidad y Arquitectura del Software

Sin embargo, a menudo hay que ir más lejos y no basta con tener en
cuenta la presentación y la funcionalidad. Sobre todo en sistemas complejos,
como pueden ser los entornos distribuidos, los transaccionales, los multicanal y
aquéllos en los que puede haber miles de usuarios conectados
simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del
diseño del sistema, es decir, desde lo que se denomina momento de
Arquitectura del Software.

Es bien sabido por los ingenieros del software que cuanto más tarde se
detectan los problemas, más cuesta arreglarlos. ¿Cuántas veces nos ha pasado
que, al diseñar una interfaz, desearíamos crear interacciones y diálogos que el
entorno tecnológico no nos permite? Y siempre acabamos exclamando: ¡Pero si
esto mismo lo hice en tal otro sitio! La respuesta de los técnicos no se hace
esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos
dicen que en su plataforma esto no es posible.

Si analizamos estos escenarios de interacción, veremos que la causa de

que no se puedan implementar es que no se tuvo en cuenta al usuario al inicio
del diseño del sistema, es decir, en la Arquitectura del Software.

¿Qué es la Arquitectura del Software?

 En un sentido amplio podríamos estar de acuerdo en que la Arquitectura
del Software es el diseño de más alto nivel de la estructura de un sistema,
programa o aplicación y tiene la responsabilidad de:

• Definir los módulos principales

• Definir las responsabilidades que tendrá cada uno de estos módulos
• Definir la interacción que existirá entre dichos módulos:
• Control y flujo de datos
• Secuenciación de la información
• Protocolos de interacción y comunicación
• Ubicación en el hardware

La Arquitectura del Software aporta una visión abstracta de alto nivel,

posponiendo el detalle de cada uno de los módulos definidos a pasos
posteriores del diseño.

La definición oficial de Arquitectura del Software es la IEEE Std 1471-

2000 que reza así: “La Arquitectura del Software es la organización
fundamental de un sistema formada por sus componentes, las relaciones entre
ellos y el contexto en el que se implantarán, y los principios que orientan su
diseño y evolución”.

Los productos resultantes de la Arquitectura del Software

El objetivo principal de la Arquitectura del Software es aportar elementos

que ayuden a la toma de decisiones y, al mismo tiempo, proporcionar
conceptos y un lenguaje común que permitan la comunicación entre los
equipos que participen en un proyecto. Para conseguirlo, la Arquitectura del
Software construye abstracciones, materializándolas en forma de diagramas
(blueprints) comentados.

No hay estándares en cuanto a la forma y lenguaje a utilizar en estos

blueprints. De todas formas, existe consenso en cuanto a la necesidad de
organizar dichas abstracciones en vistas, tal y como se hace al diseñar un
edificio. La cantidad y tipos de vistas difiere en función de cada tendencia
arquitectónica.

Quizá uno de los modelos más conocidos es el “4+1” de Philippe

Kruchten, vinculado al Rational Unified Process (RUP), que define cuatro vistas
diferentes:

• Vista lógica: describe el modelo de objetos.

• Vista de proceso: muestra la concurrencia y sincronía de los procesos.
• Vista física: muestra la ubicación del software en el hardware.
• Vista de desarrollo: describe la organización del entorno de desarrollo.
• Existe una quinta vista que consiste en una selección de casos de uso o
de escenarios que los arquitectos pueden elaborar a partir de las cuatro
vistas anteriores.
 Ejemplos de Arquitectura del Software: J2EE y MVC

Para ilustrar un poco lo que se ha explicado hasta ahora, a continuación

se muestran dos diagramas de arquitectura en un entorno J2EE. Ambos
diagramas están disponibles en Designing Enterprise Applications with the J2EE
Platform, Second Edtion.

El primer diagrama consiste en una vista lógica que muestra los

componentes y servicios típicos de un entorno J2EE.

El segundo diagrama es una vista de proceso que muestra las relaciones entre
las capas model, view y controller de la arquitectura MVC bajo J2EE.

Escenarios de usabilidad sensibles a la Arquitectura del Software

El trabajo de Bass y de este equipo se basa en inventariar una serie de

escenarios de usabilidad sensibles a la Arquitectura del Software. Esto significa
determinar una serie de momentos de interacción o tareas del usuario que,
para que el sistema los pueda soportar, tienen que estar definidos en la
Arquitectura del Software.
 Hasta el momento, este inventario está compuesto de 26 escenarios que
se pueden consultar en el documento CMU/SEI-2001-TR-005 de Bass y otros.

La lista completa es demasiado extensa para el objetivo del presente

artículo pero, a modo de ejemplo, se enumeran a continuación los cinco
primeros escenarios:

1. Agregación de datos: Poder aplicar simultáneamente una acción a un

conjunto de datos u objetos.
2. Agregación de comandos: Agrupar acciones que se puedan ejecutar de
una sola vez.
3. Comandos de cancelación
4. Uso de aplicaciones de forma concurrente
5. Validación automática de la entrada de datos

Patrones arquitecturales

Bass continúa con una propuesta de patrón arquitectural para cada

escenario (sobre el tema de patrones, consultad el artículo de Luis Villa,
Patrones para el diseño de interfaz, publicado en Grancomo).

El objetivo es doble:

• Facilitar a los expertos en usabilidad una checklist con escenarios que

muestre aspectos de usabilidad importantes a tener en cuenta en tiempo
de requerimientos.
• Facilitar a los arquitectos patrones que los guíen en el momento de dar
soporte a los escenarios.

Conclusión

Siempre que se tenga la oportunidad, sería necesario que la usabilidad se

tuviera presente desde el inicio del diseño de un sistema, es decir, desde el
momento de la Arquitectura del Software. Pero, para que esta participación sea
realmente efectiva, arquitectos y expertos en usabilidad deberían tener un
lenguaje común. Es en este sentido en el que los escenarios de usabilidad y los
patrones arquitectónicos pueden ser de gran ayuda.
 DISEÑO Y MODELACIÓN DE UN PROYECTO DE SOFTWARE.
UTILIZANDO EL LENGUAJE UML

1. Introducción
2. Descripción
3. Objetivos
4. Alcance
5. Justificación
6. Metodología
7. Bibliografía

INTRODUCCION

Desde los inicios de la informática se han estado utilizando distintas

formas de representar los diseños de una manera más bien personal o con
algún modelo gráfico, La falta de estandarización en la representación gráfica
de un modelo impedía que los diseños gráficos realizados se pudieran
compartir fácilmente entre distintos diseñadores, con este objetivo se creo el
Lenguaje Unificado de Modelado (UML: Unified Modeling Language).
UML es el lenguaje de modelado de sistemas de software más conocido
en la actualidad; es el estándar internacional aprobado por la OMG (Object
Managment Group), consorcio creado en 1989 responsable de la creación,
desarrollo y revisión de especificaciones para la industrial del software.

UML son un grupo de especificaciones de notación orientadas a Objeto,

las cuales están compuesta por distintos diagramas, que representan las
diferentes etapas del desarrollo de un proyecto de software. Este trabajo se
centra en un Sistema de Control de Citas Médicas. Se han usados varios de los
diagramas de UML, de modo que se muestre el uso de los mismos, enfocado
desde una perspectiva práctica.

DESCRIPCION

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando

Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados
investigadores en el área de metodología del software). El objetivo de amb os
era unificar dos métodos que habían desarrollado: el método Booch y el OMT
(Object Modelling Tool). El primer borrador apareció en octubre de 1995. En
esa misma época otro reputado investigador, Jacobson, se unió a Rational y se
incluyeron ideas suyas. Estas tres personas son conocidas como los "tres
amigos". Además, este lenguaje se abrió a la colaboración de otras empresas
para que aportaran sus ideas. Todas estas colaboraciones condujeron a la
definición de la primera versión de UML.

1. Modelado: es el diseño de un software

antes de su codificación, es la visualización de lo que se quiere construir.

Esta primera versión se ofreció a un grupo de trabajo para convertirlo en

1997 en un estándar del OMG. Este grupo gestiona estándares relacionados
con la tecnología orientada a objetos (metodologías, bases de datos objetuales,
CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML
(la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997.
Desde aquella versión han habido varias revisiones que gestiona la OMG
Revision Task Force. La última versión aprobada es la UML 2.0 superstructure.
En estos momentos se está desarrollando actualizaciones a esta versión en la
que se incluirán cambios importantes (principalmente añadir nuevos
diagramas).

OBJETIVOS GENERALES
 • Desarrollar el diseño y modelación de un Sistema de Control de Citas
Médicas utilizando el lenguaje UML.
• Impulsar el acercamiento hacia una nueva manera de entender el diseño
de software basado en UML.

OBJETIVOS ESPECIFICOS
• Estudiar el lenguaje de Modelado UML.
• Desarrollar por completo el diseño de un proyecto de software con el fin
de comprender todo el proceso.
• Identificar en el diseño del proyecto los distintos tipos de diagramas que
existen como son los:
• Diagramas de clases
• Casos de usos
• Paquetes
• Diagramas de interacción y secuencia, y los diagramas de transición de
estados
• Aplicar patrones de diseño modernos para la construcción de una
aplicación de software utilizando para ello la herramienta Rational Rose.
• Mostrar como UML crea un protocolo de comunicación estándar entre los
desarrolladores.

ALCANCE

El trabajo presentado a continuación es un estudio sobre el Lenguaje de

Modelado que abarca desde la definición de sus conceptos hasta su aplicación
en un ejemplo práctico, en el mismo veremos como UML nos permite
experimentar y visualizar un sistema que aun no ha sido codificado.

Este trabajo contiene la siguiente documentación:

• Diseño de Sistema utilizando UML

• Historia del UML
• Que es UML
• Bloques de Construcción UML
• Elementos Estructurales
• Elementos de comportamiento
• Elementos de agrupación
• Elementos de anotación
• Relaciones
• Diagramas
• Caso Practico de un Diseño de Software utilizando UML (Sistema de
Control de Citas Medicas)
• Definición de los requerimientos del sistema.
• Los diagramas de casos y subcasos de uso.
• La descripción de los casos de uso.
• Diagrama Conceptual.
• Diagrama de Estructura Estática (de Clases).
• Diagrama de Interacción.
• Diagrama de Estados.
 • Diagrama de Actividades.

Este trabajo no incluye la codificación del Software, el mismo esta

enfocado desde el punto de vista del diseño.

JUSTIFICACION

Standish Group, CHAOS Report nos muestra en su estudio del 2002 que
el 26% de los proyectos de software son exitosos, lo que quiere decir que el
74% fallan. La razón básica por la que fallan los proyectos se determina en la
etapa de análisis y diseño del sistema.

Entendiendo lo anterior, podemos decir que es necesario y obligatorio el

mejorar la calidad del desarrollo de software y para esto debemos adoptar
procedimientos, metodologías y herramientas que permitan una
estandarización en la ingeniería de software, esto es precisamente lo que
ofrecen los lenguajes de modelado de software, un lenguaje común que
permite el crear una disciplina con estándares como existe en la ingeniería
civil, ingeniería eléctrica, etc.
Siendo UML el estándar internacional para el modelado hemos decidido
el desarrollar este tema para este proyecto, veamos algunos de los beneficios
que ofrece UML:

• Contaremos con un mejor entendimiento del riesgo del proyecto antes de

construir el sistema
• Mejores tiempos totales de desarrollo (de 50% o mas)
• Podremos especificar la estructura y el comportamiento del sistema y
comunicarlo a todos los integrantes del proyecto
• Se documentarán las decisiones de la arquitectura del proyecto
• Se obtendrá el "plano" del sistema
• Mejor soporte a la planeación y al control del proyecto
• Un aumento en la calidad del desarrollo
• Reducción en los costos económicos

Estas son algunas de las razones por la cual es necesario adoptar UML
como lenguaje de modelado, otra razón importante es el hecho de que muchas
compañías a la hora de contratar servicios de desarrollo exigen que el lenguaje
de modelado utilizado sea UML.

METODOLOGÍA

Tarea 1. Documentación: En esta etapa se realizarán consultas

bibliográficas relacionadas con el análisis y diseño de sistemas de información
con UML, a los fines de elaborar un manual de UML con sus diagramas,
definición y ejemplos.

Tarea 2. Análisis de requerimientos: En esta etapa se busca la necesidad

del usuario y la forma en que se va a presentar la solución.

Actividades:
• Identificar Casos de Uso del sistema
• Dar detalle a los casos de uso descritos
• Definir una interfaz inicial del sistema
• Desarrollar el modelo del mundo
• Validar los modelos

Tarea 3. Diseño del sistema: en esta etapa se define una subdivisión del
sistema por funciones y la forma de comunicación para su interacción.

Actividades:

• Identificar la arquitectura del sistema

• Definir los componentes del sistema
• Refinar los casos de uso (textualmente y en diagrama)

Tarea 4. Diseño detallado: en esta etapa se adecuará el análisis a las

características específicas del software.

Actividades:

• Agregar detalles de implementación al modelo del mundo

• Desarrollar el modelo de interfaz
• Desarrollar los modelos de control, persistencia y comunicación
• Medios y Materiales a utilizar:
• Hardware
• Computador Pentium bajo Windows XP.
• Software
• Rational Rose(Software para el modelado)

BIBLIOGRAFÍA.
http://www.monografias.com/trabajos16/lenguaje-modelado-unificado/lenguaje-
modelado-unificado.shtml#PRINCIP
www.omg.org
http://www.monografias.com/trabajos5/insof/insof.shtml
http://64.233.161.104/search?
q=cache:3aHY_Njdo4YJ:www.solocursos.net/analisis_y_dise
%C3%B1o_orientado_a_objetos_de_un_framework_para_el_modelado_estadistic
o_con_mlg-slccurso697391.htm+tesis+de+uml+objetivo&hl=es
http://64.233.161.104/search?
q=cache:kVXLEJTjyiUJ:delta.cs.cinvestav.mx/~pmejia/investiga.ppt+OBJETIVOS
+ESPECIFICOS+tesis+uml&hl=es
www.delta.cs.cinvestav.mx/~pmejia/investiga.ppt
http://www.clikear.com/manuales/uml/
http://www.xpdian.com/UML2.0.html
Diseño Orientado a Objeto usando UML. Raúl Alarcón
Interfaces Graficas
Tablas de la Base de Datos en AMIC

Relaciones de las tablas