Base de Datos 1.1.

Evolucin de los Sistemas de Informacin

Con frecuencia se implantan en forma inicial los Sistemas Transaccionales y, posteriormente, se introducen los Sistemas de Apoyo a las Decisiones. Por ltimo, se desarrollan los Sistemas Estratgicos que dan forma a la estructura competitiva de la empresa. En la dcada de los setenta, Richard Nolan, un conocido autor y profesor de la Escuela de Negocios de Harvard, desarroll una teora que impact el proceso de planeacin de los recursos y las actividades de la informtica. Segn Nolan, la funcin de la Informtica en las organizaciones evoluciona a travs de ciertas etapas de crecimiento, las cuales se explican a continuacin: Comienza con la adquisicin de la primera computadora y normalmente se justifica por el ahorro de mano de obra y el exceso de papeles. Las aplicaciones tpicas que se implantan son los Sistemas Transaccionales tales como nminas o contabilidad. El pequeo Departamento de Sistemas depende en la mayora de los casos del rea de contabilidad. El tipo de administracin empleada es escaso y la funcin de los sistemas suele ser manejada por un administrador que no posee una preparacin formal en el rea de computacin. El personal que labora en este pequeo departamento consta a lo sumo de un operador y/o un programador. Este ltimo podr estar bajo el rgimen de honorarios, o bien, puede recibirse el soporte de algn fabricante local de programas de aplicacin. En esta etapa es importante estar consciente de la resistencia al cambio del personal y usuario (ciberfobia) que estn involucrados en los primeros sistemas que se desarrollan, ya que estos sistemas son importantes en el ahorro de mano de obra. Esta etapa termina con la implantacin exitosa del primer Sistema de Informacin. Cabe recalcar que algunas organizaciones pueden vivir varias etapas de inicio en las que la resistencia al cambio por parte de los primeros usuarios involucrados aborta el intento de introducir la computadora a la empresa.

Etapa de contagio o expansin

Implantacin exitosa del primer Sistema de Informacin en la organizacin.

Etapa de control o formalizacin

Esta etapa de evolucin de la Informtica dentro de las empresas se inicia con la necesidad de controlar el uso de los recursos computacionales a travs de las tcnicas de presupuestacin base cero (partiendo de que no se tienen nada) y la implantacin de sistemas de cargos a usuarios (por el servicio que se presta)

Base de Datos
Se inicia el desarrollo de interfases automticas entre los diferentes sistemas.

Etapa de integracin
La integracin de los datos y de los sistemas surge como un resultado directo de la centralizacin del departamento de sistemas bajo una sola estructura administrativa. Las nuevas tecnologas relacionadas con base de datos, sistemas administradores de bases de datos y lenguajes de cuarta generacin, hicieron posible la integracin. En esta etapa surge la primera hoja electrnica de clculo comercial y los usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayud mucho a que los usuarios hicieran su propio trabajo y no tuvieran que esperar a que sus propuestas de sistemas fueran cumplidas. El costo del equipo y del software disminuy por lo cual estuvo al alcance de ms usuarios.

Etapa de administracin de datos

El departamento de Sistemas de Informacin reconoce que la informacin es un recurso muy valioso que debe estar accesible para todos los usuarios. Para poder cumplir con lo anterior resulta necesario administrar los datos en forma apropiada, es decir, almacenarlos y mantenerlos en forma adecuada para que los usuarios puedan utilizar y compartir este recurso.

Etapa de madurez
La Informtica dentro de la organizacin se encuentra definida como una funcin bsica y se ubica en los primeros niveles del organigrama (direccin). Los sistemas que se desarrollan son Sistemas de Manufactura Integrados por Computadora, Sistemas Basados en el Conocimiento y Sistemas Expertos, Sistemas de Soporte a las Decisiones, Sistemas Estratgicos y, en general, aplicaciones que proporcionan informacin para las decisiones de alta administracin y aplicaciones de carcter estratgico. En esta etapa se tienen las aplicaciones desarrolladas en la tecnologa de base de datos y se logra la integracin de redes de comunicaciones con terminales en lugares remotos, a travs del uso de recursos computacionales.

Base de Datos 1.2. Componentes de las Bases de Datos

Hardware: constituido por dispositivo de almacenamiento como discos, tambores, cintas, etc. Software: que es el DBMS o Sistema Administrador de Base de Datos. Datos: los cuales estn almacenados de acuerdo a la estructura externa y van a ser procesados para convertirse en informacin.

Ilustracin 1. Componentes de una Base de Datos

La estructura fundamental de una Base de Datos es una ``tabla'', la cual organiza la informacin en filas y columnas relacionndose entre s para que su acceso sea ms fcil. Las filas dentro de una tabla son conocidas como ``registros'', los cuales son unidades de almacenamiento dentro de una tabla. Las columnas son llamadas ``campos'', que es cualquier elemento indivisible contenido en un registro. Existe la posibilidad de que la informacin de los registros se repita, por lo que es necesario asignar o adicionar una clave conocida como campo clave, dicha clave identificar a cada registro como nico.

Para ilustrar de alguna forma cmo se representa una tabla incluyendo el campo clave se puede ver en la figura:

Base de Datos

Ilustracin 2. Componentes de una tabla

Documentos, constituyen la entidad fsico/cognitiva compleja que alberga la estructura formal, basada en los datos fsicos necesarios para su identificacin (ttulo, autor, lugar de publicacin, fecha, edicin,...) y la estructura lgico-cognitiva, centrada en el contenido y en las propiedades semnticas. Representacin de documentos, tanto de sus propiedades fsicas como semnticas se hace mediante palabras clave, frases, etc. que servirn de puntos de acceso cuando interroguemos al sistema. Necesidades de informacin de los usuarios, manifestadas en la solicitud de informacin. Representacin de las necesidades de informacin, expresadas tambin con palabras clave o frases. Comparacin de la representacin de informacin con la representacin de los documentos. Las bases de datos, basadas en la funcin semejanza compara, a travs de un ndice, ambas representaciones para seleccionar los documentos relevantes.

Base de Datos 1.3. Lenguajes de Bases de Datos

Los lenguajes de consulta (query language) son especificaciones formales para representar consultas. An cuando son llamados de "consulta" en realidad pueden hacer mucho ms que consultas.

Structured Query Language/Lenguaje de consultas estructurado (SQL)

El lenguaje de consulta estructurado (SQL) es un lenguaje de programacin de base de datos normalizado, utilizado por los diferentes motores de bases de datos para realizar determinadas operaciones sobre los datos o sobre la estructura de los mismos. Pero como sucede con cualquier sistema de normalizacin hay excepciones para casi todo; de hecho, cada motor de bases de datos tiene sus peculiaridades y lo hace diferente de otro motor, por lo tanto, el lenguaje SQL normalizado (ANSI) no nos servir para resolver todos los problemas, aunque si se puede asegurar que cualquier sentencia escrita en ANSI ser interpretable por cualquier motor de datos.

Creado por IBM alrededor de los aos 70s Combinacin de lgebra relacional y clculo relacional En 1986 ANSI e ISO lo estandarizan en SQL-86 Otras versiones: SQL-92, SQL-99

Los principales gestores de bases de datos (SGBD) usan SQL y son: DB2 Firebird Informix Interbase MySQL Oracle PostgreSQL Pervasive SQLite SQL Server Sybase ASE

Base de Datos
El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos. Existen dos tipos de comandos SQL: DLL que permiten crear y definir nuevas bases de datos, campos e ndices. DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Query Language (QUEL)

Basado en el clculo relacional de tuplas. A) Consultas La estructura general de una consulta es la siguiente: ==== RANGE OF t1 IS r1 RANGE OF t2 IS r2 ................................... .................................. RANGE OF tm IS rm RETRIEVE (ti1.Aj1, ti2.Aj2, ........, tim.Ajm) WHERE P ==== donde t1,.....,tm son las tuplas que usamos para la consulta, r1,...,rm son las relaciones correspondientes a t1,...,tm. La clusula RETRIEVE es equivalente a la clusula SELECT de SQL, y P es el predicado de seleccin. Lenguaje Comercial Desarrollado por M. Stonebraker en 1976 Lenguaje original de "ingres" Basado en el clculo relacional de tuplas

Base de Datos
Query by example (QBE)
Es un lenguaje comercial desarrollado por IBM y basado en el clculo relacional de dominios. En l las consultas se hacen por medio de ejemplos, para ello se usan unas tablas que son "esqueletos" de relaciones. El sistema generaliza los ejemplos. Desarrollo de ibm en los 70s Ejemplo de programacin visual Sintxis bidimensional Genera consultas a partir de ejemplos Relacin directa con clculo relacional de tuplas

Por que utiliza una base de datos distribuida? como SQL SERVER, MYSQL, O ORACLE.
La utilidad es que siempre tendrs la informacin guardada de manera estructura y lista para su consulta y manejo. En todos los sistemas la razn de ser de los mismos es el manejo de la informacin y cuando utilizas una base de datos lo que tienes es una manera estndar de manejar y guardar tu informacin, cuando la base de datos es distribuida tiene mayor alcance ya que puede ser accesada desde muchos equipos.

Base de Datos
El sistema SQL es muy accesible para instalarse sobre cualquier tipo de hardware, puede contenerse desde laptops hasta las pequenas poket pc. Haciendo esto una capacidad optima de movibilidad. Como las bases de datos distribuidas se encuentran en diferentes pc, ya sea unidas por algun tipo de red, es muy sencillo usar el software de microsoft ( sqlserver) que es sumamente sencillo y facil de aprender.

1.4 Arquitectura de 3 niveles de esquema

La definicin de un sistema de informacin es la descripcin detallada de la arquitectura del sistema. Las arquitecturas de bases de datos han evolucionado mucho desde sus comienzos, aunque la considerada estndar hoy en da es la descrita por el comit ANSI/X3/SPARC ( Standard Planning and Requirements Committee of the American National Standards Institute on Computers and Information Processing), que data de finales de los aos setenta. Este comit propuso una arquitectura general para DBMSs basada en tres niveles o esquemas: el nivel fsico, o de mquina, el nivel externo, o de usuario, y el nivel conceptual. As mismo describi las interacciones entre estos tres niveles y todos los elementos que conforman cada uno de ellos.

Arquitectura ANSI
La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado por la ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) en

Base de Datos
1975 como ayuda para conseguir la separacin entre los programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los usuarios y el uso de un catlogo para almacenar el esquema de la base de datos. Nivel interno: Tiene un esquema interno que describe la estructura fsica de almacenamiento de base de datos. Emplea un modelo fsico de datos y los nicos datos que existen estn realmente en este nivel. Nivel conceptual: tiene esquema conceptual. Describe la estructura de toda la base de datos para una comunidad de usuarios. Oculta los detalles fsicos de almacenamiento y trabaja con elementos lgicos como entidades, atributos y relaciones. Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada esquema describe la visin que tiene de la base de datos a un grupo de usuarios, ocultando el resto.

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicacin de la base de datos fsica. Hay que destacar que los tres esquemas no son ms que descripciones de los mismos datos pero con distintos niveles de abstraccin. Los nicos datos que existen realmente estn a nivel fsico, almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar cualquier peticin expresada en trminos de un esquema externo a una peticin expresada en trminos del esquema conceptual, y luego, a una peticin en el esquema interno, que se procesar sobre la base de datos almacenada. Si la peticin es de una obtencin (consulta) de datos, ser preciso modificar el formato de la informacin extrada de la base de datos almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o transformacin. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas. La arquitectura de tres niveles es til para explicar el concepto de independencia de datos que podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior. Se pueden definir dos tipos de independencia de datos: La independencia lgica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicacin. Se puede modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran a ella no debern verse afectados. La independencia fsica es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros fsicos con el fin de mejorar el rendimiento de las operaciones

Base de Datos
de consulta o de actualizacin de datos. Dado que la independencia fsica se refiere slo a la separacin entre las aplicaciones y las estructuras fsicas de almacenamiento, es ms fcil de conseguir que la independencia lgica. En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catlogo o diccionario, de modo que incluya informacin sobre cmo establecer la correspondencia entre las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar estas correspondencias haciendo referencia a la informacin de correspondencia que se encuentra en el catlogo. La independencia de datos se consigue porque al modificarse el esquema en algn nivel, el esquema del nivel inmediato superior permanece sin cambios, slo se modifica la correspondencia entre los dos niveles. No es preciso modificar los programas de aplicacin que hacen referencia al esquema del nivel superior. Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecucin de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta arquitectura completa.

10

El nivel clave en esta arquitectura, como se puede adivinar, es el conceptual. ste contiene la descripcin de las entidades, relaciones y propiedades de inters para la empresa (UoD), y constituye una plataforma estable desde la que proyectar los distintos esquemas externos, que describen los datos segn los programadores, sobre el esquema interno, que describe los datos segn el sistema fsico. Las posibles proyecciones de datos quedan resumidas en la grafica.

Base de Datos

Ilustracin 3. Arquitectura ANSI

El nivel clave en esta arquitectura, como se puede adivinar, es el conceptual. ste contiene la descripcin de las entidades, relaciones y propiedades de inters para la empresa (UoD), y constituye una plataforma estable desde la que proyectar los distintos esquemas externos, que describen los datos segn los programadores, sobre el esquema interno, que describe los datos segn el sistema fsico. Las posibles proyecciones de datos quedan resumidas en la grafica.

11

Base de Datos
1.5 Independencia de los datos
Se refiere a la proteccin contra los programas de aplicacin que puedan originar modificaciones cuando se altera la organizacin fsica o lgica de la base de datos. Existen 2 niveles de independencia de datos. Independencia fsica de datos Es la capacidad de modificar el esquema fsico sin provocar que se vuelvan a escribir los programas de aplicacin. Independencia lgica de datos Capacidad de modificar el esquema conceptual sin provocar que se vuelvan a escribir los programas de aplicacin. Las aplicaciones actuales con frecuencia dependen de los datos. Dicho de otro modo, los requerimientos de la aplicacin en cuestin determinan la forma de organizar los datos en almacenamiento secundario y la tcnica para acceder a ellos. Se dice que una aplicacin es dependiente de los datos porque es imposible alterar la estructura de almacenamiento (la organizacin fsica de los datos) o la tcnica de acceso sin afectar a la aplicacin. En un sistema de BD no es recomendable tener aplicaciones dependientes de los datos, al menos por 2 razones: 1. Cada aplicacin requiere una vista diferente de los mismos datos (ejemplo, 2 archivos que trabajen con un saldo en decimal y el otro en binario, el DBMS debe estar preparado y ser capaz de realizar las conversiones). Son las diferencias que pueden existir entre la forma como ve los datos una aplicacin dada y la forma como se almacenan fsicamente. 2. El DBA debe tener libertad para modificar la estructura de almacenamiento o la tcnica de accesos (o las 2 cosas) para adaptarlas a cambios en los requerimientos, sin tener que modificar las aplicaciones ya existentes. Si las aplicaciones dependen de los datos, tales cambios requerirn con toda seguridad modificaciones correspondientes en los programas, lo cual ocupara un tiempo que los programadores podran dedicar a la creacin de nuevas aplicaciones. Esta independencia puede definirse como la inmunidad de las aplicaciones ante los cambios en la estructura de almacenamiento y en la tcnica de acceso. Definiremos 3 trminos:

12

Un campo almacenado es la unidad ms pequea de informacin almacenada que recibe un nombre. La base de datos incluir, en la mayor parte de los casos, muchas ocurrencias (o casos) de cada uno de los diversos tipos de campo almacenado. Un registro almacenado es un conjunto de campos almacenados relacionados entre s, que cuenta con su propio nombre. Una vez ms se hace la distincin entre tipo y ocurrencia. Una ocurrencia de un registro almacenado est formada por un grupo de

Base de Datos
ocurrencias de campos almacenados entre s (una ocurrencia para cada tipo distinto de parte). Un archivo almacenado es el conjunto (con nombre) de todas las ocurrencias de un tipo de registro almacenado.

En los sistemas sin BD cadi siempre un registro lgico de una aplicacin es idntico a un registro almacenado correspondiente. Esto no tiene por qu ser as en un sistema de BD, pues el DBA podra requerir la capacidad de modificar la estructura de almacenamiento sin que cambien las estructuras lgicas correspondientes.

1.6. Administrador de base de datos

El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye lo siguiente: Recuperabilidad - Crear y probar Respaldos Integridad - Verificar o ayudar a la verificacin en la integridad de datos Seguridad - Definir o implementar controles de acceso a los datos Disponibilidad - Asegurarse del mayor tiempo de encendido Desempeo - Asegurarse del mximo desempeo incluso con las limitaciones Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.

El diseo lgico y fsico de las bases de datos a pesar de no ser obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general estn asignadas a los analistas de bases de datos o a los diseadores de bases de datos. Deberes Debido a la importancia de los datos que estn a su cargo, el administrador de bases de datos debe ser experto en TI (tecnologa de la informacin), teniendo particular conocimiento de DBMS (sistemas de administracin de bases de datos) y el lenguaje de consulta SQL. Tambin debe tener conocimiento de varios tipos de lenguaje de programacin para poder automatizar ciertas tareas. Una de sus tareas es la de asegurar la integridad del sistema de informacin de la compaa. Adems, es necesario que posea un buen entendimiento de DBMS para optimizar las consultas, ajustar la configuracin de DBMS o para sincronizar en forma precisa las herramientas de control del acceso a las bases de datos. Es posible que el administrador de bases de datos tenga que brindar asistencia tcnica a usuarios de las aplicaciones cliente o equipos de desarrollo para solucionar problemas, dar consejos o ayudar a resolver consultas complicadas.

13

Base de Datos
Al trabajar con el jefe de seguridad, el administrador de bases de datos debe crear copias de seguridad, planes y procedimientos de restauracin para preservar los datos de los cuales es responsable. Adems de estas habilidades tcnicas, el administrador de bases de datos debe poseer un buen entendimiento de las aplicaciones de la compaa y estar dispuesto a atender las necesidades de los usuarios cuando desarrolla o edita una base de datos. En el mejor de los casos, debe tener experiencia en diseo de sistemas de informacin y modelos UML (Lenguaje unificado de modelos).

1.7 Diccionario de Datos

El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD). Es el segundo componente del anlisis estructurado. Tambin se conoce como "Data Repository". Incluye el contenido de los data flow (flujos de datos), los "data store", las entidades externas y los procesos. Data elements (elementos de datos) Es la parte ms pequea de los datos que tiene significado en el sistema de informacin. Se combinan varios elementos de datos para hacer los records o "data structures". Ejemplo: nombre, direccin, seguro social. Data Structure (Estructura de datos) Tambin se conocen como record. Es la combinacin de elementos de datos relacionados que se incluye en un flujo de datos o se retiene en un "data store". Un diccionario de datos contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema que estamos programando, incluyendo nombre, descripcin, alias, contenido y organizacin. Estos diccionarios se desarrollan durante el anlisis de flujo de datos y ayuda a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo del proyecto. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo.

14

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripcin de todos estos elementos.

Base de Datos
Contiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo. Razones para su utilizacin: Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas ms chicos hay gran cantidad de datos. Los sistemas al sufrir cambios continuos, es muy difcil manejar todos los detalles. Por eso se registra la informacin, ya sea sobre hoja de papel o usando procesadores de texto. Los analistas mas organizados usan el diccionario de datos automatizados diseados especficamente para el anlisis y diseo de software. 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. Para documentar las caractersticas del sistema, incluyendo partes o componentes as como los aspectos que los distinguen. Tambin es necesario saber bajo qu circunstancias se lleva a cabo cada proceso y con qu frecuencia ocurren. Produciendo una comprensin ms completa. Una vez que las caractersticas estn articuladas y registradas, todos los participantes en el proyecto tendrn una fuente comn de informacin con respecto al sistema. Para facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema. Determina si son necesarias nuevas caractersticas o si estn en orden los cambios de cualquier tipo. Se abordan las caractersticas:

Naturaleza de las transacciones: las actividades de la empresa que se llevan a cabo mientras se emplea el sistema. Preguntas: solicitudes para la recuperacin o procesamiento de informacin para generar una respuesta especfica. Archivos y bases de datos: detalles de las transacciones y registros maestros que son de inters para la organizacin.

15

Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar transacciones y datos Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un informe. Aun en los manuales, se revelan errores.

Base de Datos
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 bsicos para todos los dems datos del sistema, por si mismos no le dan un significado suficiente al usuario. Se agrupan para formar una estructura de datos. Descripcin: 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. Descripcin: 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 especficos para los datos. Si los valores de los datos estn restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario. Estructura de datos: es un grupo de datos que estn relacionados con otros y que en conjunto describen un componente del sistema. Descripcin: Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes combinaciones ya sea individualmente o en conjuncin con alguna otra. Relacin secuencial: define los componentes que siempre se incluyen en una estructura de datos. Relacin de seleccin: (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. Relacin de iteracin: (repetitiva), define la repeticin de un componente. Relacin opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteracin.

Notacin Los analistas usan smbolos especiales con la finalidad de no usar demasiada cantidad de texto para la descripcin de las relaciones entre datos y mostrar con claridad las relaciones estructurales. En algunos casos se emplean trminos diferentes para describir la misma entidad (alias) estos se representan con un signo igual (=) que vincula los datos. Documentacin: Data elements - Las caractersticas que se describen en el diccionario de datos son: 1. Name - Es el nombre del elemento de datos; debe ser significativo. 2. Alias - Cualquier otro nombre que se pueda usar para referirse al elemento de datos. Por ejemplo, el nombre de un elemento de datos puede ser Balance actual, y el alias puede ser Deuda. Solo se incluye el alias si realmente es necesario utilizarlo. 3. Type y Size - Type o tipo se refiere a si el elemento de datos contiene valor numrico, caracteres o alfabtico. Size o tamao se refiere al mximo de caracteres o de dgitos que puede tener el elemento de datos.

16

Base de Datos
4. Output format or edit mask - Indica cmo se presenta el dato al mostrarse en pantalla o al imprimirse en un reporte. Por ejemplo, el nmero de telfono del cliente se puede guardar en el disco usando solo nmeros 7878889999, pero presentarse editado en la pantalla o en el reporte (787) 888-9999. 5. Default value - Es el valor que el elemento de datos tiene si no se cambia entrando otro valor. 6. Prompt, column header or field caption - Es el nombre que se presenta en la pantalla o el ttulo del dato en el reporte. 7. Source - De dnde se origina el valor del elemento de datos. Puede ser una forma, un departamento, otro sistema, etc. 8. Security - Identifica los individuos o departamentos que pueden modificar el elemento de datos. Por ejemplo, la lnea de crdito puede ser cambiada por el gerente de crdito. 9. Responsible user(s) - Identifica el (los) usuarios responsables de entrar o cambiar los valores del elemento de datos. 10. Acceptable Data and Data validation - Se especifica el dominio o valores permitidos. Pueden ser valores especficos, una lista de valores, los valores que se encuentren en otro archivo, etc. El valor puede tener reglas de validacin; por ejemplo, el salario debe estar entre lo permitido para la posicin que el empleado ocupa. 11. Derivation formula - Si el valor es el resultado de un clculo, se muestra la frmula que se utiliza. 12. Description or comments - Para proveer informacin adicional, notas o descripciones. Data flows (Flujo de datos) Las caractersticas que se describen en el flujo de datos son: Name El nombre del flujo de datos tal y como aparece en el DFD. Alias Otro nombre con que se conozca el flujo de datos. Abbreviation or ID Cdigo que provee acceso rpido al flujo de datos en un diccionario de datos automatizado. Description Describe el flujo de datos y su propsito. Origin De donde sale (la fuente) el flujo de datos. Puede ser un proceso, un data store o una entidad. Destination El punto final del flujo de datos en el DFD. Puede ser un proceso, un data store o una entidad. Record Cada flujo de datos representa un grupo de elementos de datos relacionados, o un record. Los records y los flujos de datos se definen por separado para que ms de un flujo de datos o data store pueda hacer referencia al mismo record.

17

Base de Datos
Volume and frequency Describe el nmero esperado de ocurrencias para el flujo de datos por unidad de tiempo.

Data store Las caractersticas que se describen en el data store son: Name El nombre del data store segn aparece en el DFD. Alias Otro nombre con el que se pueda llamar al data store. Abbreviation or ID Cdigo que provee un acceso rpido al data store en un diccionario de datos automatizado. Description Describe el data store y su propsito. Input data flows Los nombres de los flujos de datos que entran al data store. Output data flows Los nombres de los flujos de datos que salen del data store. Record El nombre del record en el diccionario de datos para el data store. Volume and Frequency El nmero estimado de records guardados en el data store, al igual que el aumento o cambio esperado.

Proceso Se documenta cada funcin primitiva. Se incluye: Process name or label El nombre del proceso como aparece en el DFD. Purpose or description Un resumen del propsito general del proceso. Los detalles se documentan en el Process Description. Process number Nmero de referencia que identifica el proceso y su relacin con los niveles del sistema. Input data flows Los nombres de los flujos de datos que entran al proceso. Output data flows Los nombres de los flujos de datos que salen del proceso. Process Description Se explican los detalles del proceso.

Entidades Externas Las caractersticas que se describen son: Name Alias Description Describe a la entidad y su propsito. Input data flow Output data flow

18

Record Se describe lo siguiente: Record name Alias Description

Base de Datos
Record content or composition Una lista de todos los elementos de datos incluidos en el record. Se identifica cualquier key primario, o sea un elemento de datos en el record que identifica en forma nica al record.

1.8 Modelo de Datos

Un modelo de datos para las bases de datos es una coleccin de conceptos que se emplean para describir la estructura de una base de datos. Esa coleccin de conceptos incluye entidades, atributos y relaciones. La mayora de los modelos de datos poseen un conjunto de operaciones bsicas para especificar consultas y actualizaciones de la base de datos.

Los modelos de datos pueden clasificarse en: * Modelos de datos de alto nivel o conceptuales: disponen de conceptos cercanos a la forma en que los usuarios finales perciben una base de datos. * Modelos de datos de bajo nivel o fsicos: disponen de conceptos que describen detalles sobre el almacenamiento de los datos en la computadora. * Modelos de datos de representacin (o de implementacin): disponen de conceptos que pueden entender los usuarios finales, pero que no estn alejados de la forma en que se almacenan los datos en la computadora. Clasificacin de los modelos de datos Los modelos de datos sirven para clasificar los distintos tipos de SGBD. Existen diferentes modelos de datos para bases de datos como ser: Modelo relacional *** Modelo orientado a objetos Modelo relacional-objeto **** Modelo jerrquico *** Modelo de red

19

Caractersticas

Es el proceso de analizar los aspectos de inters para una organizacin y la relacin que tienen unos con otros. Resulta en el descubrimiento y documentacin de los recursos de datos del negocio. El modelado hace la pregunta " Qu ? " en lugar de " Cmo ? ", sta ltima orientada al procesamiento de los datos.

Base de Datos

Es una tarea difcil, bastante difcil, pero es una actividad necesaria cuya habilidad solo se adquiere con la experiencia.

Metas y beneficios

Registrar los requerimientos de datos de un proceso de negocio. Dicho proceso puede ser demasiado complejo y se tendr que crear un "enterprise data model", el cual deber estar constitudo de lneas individuales. Permite observar: o Patrones de datos o Usos potenciales de los datos

Modelado de Datos Conceptual Conceptos bsicos Algunos aspectos a considerar al momento de realizar el modelado/anlisis No pensar fsicamente, pensar conceptualmente No pensar en procesos, pensar en estructura No pensar en navegacin, pensar en trminos de relaciones Modelos conceptuales Existen distintos tipos de modelos conceptuales:

Basados en registros

Basados en objetos

Jerrquico: datos en registros, relacionados con apuntadores y organizados como colecciones de rboles Redes: datos en registros relacionados por apuntadores y organizados en grficas arbitrarias Relacional: datos en tablas relacionados por el contenido de ciertas columnas

Orientado a objetos: datos como instancias de objetos (incluyendo sus mtodos) Entidad-relacin: datos organizados en conjuntos interrelacionados de objetos (entidades) con atributos asociados

Modelo Entidad-Relacin

20

Definicin Generalmente todo modelo tiene una representacin grfica, para el caso de datos el modelo ms popular es el modelo entidad-relacin o digrama E/R. Se denomina as debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos). El modelo debe estar compuesto por:

Base de Datos

Entidades Atributos Relaciones Cardinalidad Llaves

Conjuntos de entidades y atributos

Entidades: todo lo que existe y es capaz de ser descrito (sustantivo). Atributos: es una caracterstica (adjetivo) de una entidad que puede hacer 1 de tres cosas: o Identificar o Relacionar o Describir

En el diseo se pueden considerar 3 categoras de atributos Simples o compuestos: ya sea que el atributo sea un todo o bien este compuesto o Color es simple, toma valores rojo, azul, etc o Nombre es compuesto, contiene nombre de pila, apellido materno, apellido materno Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores. o Telefono o Telfonos Derivados: que se pueden calcular en base a otros atributos o El promedio de prstamos se puede derivar si tenemos los valores de cada prstamo realizado a un persona NOTA: en la prctica es mejor considerar "siempre" a todos los atributos como simples y con valores simples

Conjuntos de relaciones

Relaciones: la conexin que existe entre 2 entidades (verbo).

21

Base de Datos

Diagrama E-R

22

Base de Datos
Diagramas E-R de relaciones entre entidades

Categoras de atributos

23

NOTA: como se mencion anteriormente NO es lo mejor el emplear estos atributos Entidades dbiles

Una entidad dbil es aquella que no posee una llave primaria Para existir dependen de una relacin con una entidad fuerte

Base de Datos

Pueden contener algun atributo "discriminante" que podra considerarse como aquel que lo distingue pero no de manera nica, de ah que no se considere como llave

Cardinalidades En base al nmero de instancias involucradas en cada relacin, stas presentan un cardinalidad, que puede ser:

24

Base de Datos

Especializacin y generalizacin Es el principio de "herencia" Las entidades de bajo nivel heredan todos los atributos de las entidades de mayor nivel

Si se considera de arriba hacia abajo se considera como especializacin Si se considera de abajo hacia arriba se considera como generalizacin

25

Base de Datos

26

Base de Datos
1.9 El proceso de diseo de la base de Datos
Si usa un proceso de diseo de base de datos establecido, puede crear de forma rpida y efectiva una base de datos bien diseada que le proporciona acceso conveniente a la informacin que desea. Con un diseo slido tardar menos tiempo en construir la base de datos y obtendr resultados ms rpidos y precisos. La clave para obtener un diseo de base de datos eficaz radica en comprender exactamente qu informacin se desea almacenar y la forma en que un sistema de administracin de bases de datos relacionales, como Visual FoxPro, almacena los datos. Para ofrecer informacin de forma eficiente y precisa, Visual FoxPro debe tener almacenados los datos sobre distintos temas en tablas separadas. Por ejemplo, puede haber una tabla donde slo se almacenen datos sobre empleados y otra tabla que slo contenga datos de ventas. Al organizar los datos de forma apropiada, proporciona flexibilidad a la base de datos y tiene la posibilidad de combinar y presentar informacin de muchas formas diferentes. Al disear una base de datos, en primer lugar debe dividir la informacin que desea almacenar como temas distintos y despus indicar a Visual FoxPro cmo se relacionan estos temas para que pueda recuperar la informacin correcta cuando sea necesario. Si mantiene la informacin en tablas separadas facilitar la organizacin y el mantenimiento de los datos y conseguir aplicaciones de alto rendimiento. A continuacin se indican los pasos que hay que seguir en el proceso de diseo de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta seccin. Determinar el propsito de la base de datos Este paso le ayudar a decidir los datos que desea que se almacenen. Determinar las tablas necesarias Cuando ya conozca claramente el propsito de la base de datos, puede dividir la informacin en temas distintos, como "Employees" u "Orders". Cada tema ser una tabla de la base de datos. Determinar los campos necesarios. Tiene que decidir la informacin que desea incluir en cada tabla. Cada categora de informacin de una tabla se denomina campo y se muestra en forma de columna al examinar la tabla. Por ejemplo, un campo de la tabla Employee podra ser Last_name y otro podra ser Hire_date. Determinar las relaciones. Observe cada tabla y decida cmo se relacionan sus datos con los de las tablas restantes. Agregue campos a las tablas o cree tablas nuevas para clarificar las relaciones, si es necesario. Perfeccionar el diseo. Busque errores en el diseo. Cree las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desea de sus tablas. Haga los ajustes necesarios al diseo.

27

No se preocupe si se equivoca o si olvida algunos aspectos en el diseo inicial. Piense en l como en un borrador que podr mejorar posteriormente. Pruebe con datos de ejemplo y con prototipos de los formularios e informes. Resulta sencillo modificar el diseo de la base de datos durante su

Base de Datos
creacin. Sin embargo, es mucho ms difcil modificar las tablas cuando ya estn llenas de datos y se han generado formularios e informes. Por este motivo, debe asegurarse de tener un diseo slido antes de llegar demasiado lejos en la programacin de una aplicacin. Cualidades de un buen diseo de base de datos Reflejar la estructura del problema en el mundo real. Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo. Evitar el almacenamiento de informacin redundante. Proporcinar un acceso eficaz a los datos. Mantener la integridad de los datos a lo largo del tiempo. Ser claro, coherente y de fcil comprensin. Nota: A veces, estos objetivos pueden ser contradictorios. Se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementacin. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulacin de los diferentes grupos de usuarios. Si parte de la informacin necesaria para crear algn elemento establecido ya se encuentra implementado en otro sistema de almacenamiento hay que documentar que relacin existir entre uno y otro y detallar los sistemas que eviten la duplicidad o incoherencia de los datos. El diseo consta, como se vio anteriormente, de tres fases: el diseo global o conceptual, el diseo lgico y el modelo fsico. Esta etapa consta de tres fases: diseo conceptual, diseo lgico, diseo fsico de la Base de Datos. La primera fase consiste en la produccin de un esquema conceptual que es independiente de todas las consideraciones fsicas. Este modelo se refina despus en un esquema lgico eliminando las construcciones que no se puede representar en el modelo de Base de Datos escogido (relacional, orientado a objeto, etc.). En la tercera fase el esquema lgico que traduce un esquema fsico para el sistema gestor de Base de Datos escogido. La fase de diseo fsico considera las estructuras de almacenamiento y los mtodos de acceso necesarios para proporcionar un acceso eficiente a la Base de Datos en memoria secundaria. Seleccin del SGBD / DBMS: Si no se dispone de un Sistema Gestor de Base de Datos o que se encuentre obsoleto se debe escoger un SGBD que sea adecuado para el sistema de informacin esta eleccin se debe hacer en cualquier momento antes del diseo lgico.

28

Base de Datos
1.10 El Desarrollo de un sistema de BD
Para el desarrollo de Sistemas sobre Base de Datos contamos con una metodologa probada, y con un conjunto de herramientas orientadas a aumentar la productividad y la calidad del producto final (libreras, protocolos, generadores, etc.). Desarrollamos potencializando la metodologa RUP, donde los componentes se desarrollan pensando en arquitectura de tres capas y el proceso de ingeniera de software tiene la caracteristica principal de ser incremental e iterativo. Nuestra metodologia considera entre sus principales actividades, la comunicacin con el cliente a lo largo de todo el proceso de desarrollo, planificacin, anlisis de riesgo, ingeniera, construcccin, adaptacin y finalmente evaluacin del cliente. El proceso de ingeniera considera levantar requerimientos basados en casos de uso, diseo de interfaces, diseos fsicos de la solucin. El desarrollo y mantenimiento de software es un servicio especializado, orientado a la construccion de sistemas de informacion para dar apoyo a los distintos requerimientos de desarrollo de sistemas o mantenimiento de los existentes, de acuerdo a las directrices estrategicas de la compaia. Contamos con una vasta experiencia funcional lo que apoya a nuestra relacin con los clientes, a nuestra capacidad de anlisis y al proceso de diseo de sistemas. Permanentemente exploramos nuevas herramientas de desarrollo de software de manera entregarle al cliente soluciones en tecnologa de punta.

Proceso Unificado de Rational

De Wikipedia, la enciclopedia libre Saltar a navegacin, bsqueda

El Proceso Unificado Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

29

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades.

Base de Datos
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto independiente.

Contenido
[ocultar]

Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:
[editar] Adaptar el proceso

El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin. El tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal.
[editar] Equilibrar prioridades

Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
[editar] Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados
[editar] Colaboracin entre equipos

El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

30

[editar] Elevar el nivel de abstraccin

Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin

Base de Datos
del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
[editar] Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

[editar] Ciclo de vida

Esfuerzo en actividades segn fase del proyecto.

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos.

31

Base de Datos
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se selecciona algunos Casos de Uso, se refina su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una disciplina vara.

[editar] Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).....

[editar] Fases

32

Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: 'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)

Modelado de negocio

Base de Datos

Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

Gestin del cambio y configuraciones Gestin del proyecto Entorno

La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Inicio(Tambin llamado Incepcin o Concepcin) Elaboracin Desarrollo(Tambin llamado Implementacin, Construccin) Cierre (Tambin llamado Transicin)

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

33

[editar] Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:

Base de Datos
Inicio:

Documento Visin Especificacin de Requisitos

Elaboracin:

Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lgica

Diagrama de clases Modelo E-R (Si el sistema as lo requiere)

Vista de Implementacin

Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin

Vista Conceptual

Modelo de dominio

Vista fsica

Mapa de comportamiento a nivel de hardware.

34