ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

INSTITUTO TECNOLGICO SUPERIOR DE COATZACOALCOS.

ITESCO ALUMNA:

ANEL XOLO PARRA.

MATERIA: FUNDAMENTOS DE DESARROLLO DE SISTEMAS.

UNIDAD 3: PARADIGMAS DE LA INGENIERIA DE SOFTWARE.

DOCENTE: ISC. ANZONY SANCHEZ GOMEZ.

CARRERA: INGENIERIA EN SISTEMAS COMPUTACIONALES.

SEMESTRE: 6

GRUPO: B

COATZACOALCOS, VER; a 02 DE MAYO 2012.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

INTRODUCCION
La Ingeniera de Software es reconocida como una disciplina legtima, digna de tener una investigacin seria, un estudio cuidadoso y ha generando una gran controversia. En la industria el Ingeniero del software ha sustituido al programador como titulo de trabajo preferente. Los modelos de procesos de software, mtodos de ingeniera de software y herramientas se han adoptado con xito en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la necesidad de un enfoque ms disciplinado del software. Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas, que permite producir programas con una directriz especfica, tales como: estructura modular, fuerte cohesin, alta rentabilidad, etc. [11] Existen tres categoras de paradigmas de programacin: [11] a) Los que soportan tcnicas de programacin de bajo nivel (ejemplo: copia de ficheros frente estructuras de datos compartidos) b) Los que soportan mtodos de diseo de algoritmos (ejemplo: divide y vencers, programacin dinmica, etc.) c) Los que soportan soluciones de programacin de alto nivel, como los descritos en el punto anterior

UNIDAD 3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

3.1 EL ENFOQUE ESTRUTURADO 3.1.1 DIAGRAMAS DE FLUJOS DE DATOS

El DFD (Data Flow Diagram) surgi de la necesidad de un nuevo mtodo de especificacin sencillo de implantar, fcil comprensin y comunicacin. El DFD fue desarrollado por De Marco en los aos 70s y fue popularizado por Yourdan. Es un mtodo de especificacin utilizado hasta la fecha. Para empezar se puede preguntar Que son los diagramas de flujos de Datos? Un diagrama de flujo de datos (DFD) es una representacin grfica de los procesos que se realizan con los datos en su organizacin, con el uso de tan solo cuatro smbolos, se puede crear una descripcin grafica de los procesos que, con el tiempo, contribuirn a desarrollar una slida documentacin del sistema. En seguida mencionan las ventajas sobre las explicaciones descriptivas en relacin con la forma en que los datos se mueven a travs del sistema: 1. Libertad para emprender la implementacin tcnica del sistema en las primeras etapas. 2. Comprensin ms profunda de la interrelacin entre sistemas y subsistemas. 3. Comunicacin con los usuarios sobre el conocimiento del sistema actual mediante diagramas de flujos de datos. 4. Anlisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. La ventaja ms grande es la libertad conceptual para utilizar los cuatro smbolos, los DFDs hacen nfasis en el procesamiento o la transformacin

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS conforme estos pasan por una variedad de procesos. En los DFDs lgicos no hay distincin entre procesos manuales o automatizados. Los procesos tampoco se representan grficamente en orden cronolgico. En vez de ello, se agrupan solo si el anlisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los procesos automatizados tambin se pueden agrupar. Simbologa En los diagramas de flujos de datos se usan cuatro smbolos bsicos para graficar el movimiento de los datos: Un cuadrado doble, una flecha, un rectngulo con esquinas redondeadas(o una burbuja) y un rectngulo abierto (cerrado en el lado izquierdo y abierto en el derecho), como se muestra en la Figura 3.1 a continuacin. Con la combinacin de estos cuatro smbolos se puede describir grficamente un sistema completo y varios subsistemas.

Entidad

Flujo de datos

Proceso

Almacn de datos Figura 3.1 Simbologa

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 ed

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

El cuadrado doble se usa para describir una entidad externa (otro departamento, un negocio, una persona o una maquina) que puede enviar datos al sistema o recibirlos de el. La entidad externa, o solo entidad, tambin se llama origen o destino de datos, y se considera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque interacta con el sistema, se considera fuera de los lmites de este. La misma entidad se podra usar ms de una vez en un diagrama de flujo de datos en particular para evitar que las lneas se crucen en el flujo de datos. La flecha muestra el movimiento de los datos de un punto a otro, con la punta de la flecha sealando hacia el destino de los datos. Los flujos de datos que ocurren simultneamente se pueden describir mediante flechas paralelas. Una flecha tambin puede se debe describir con un nombre, debido a que representan los datos de un apersona, lugar o cosa. Rectngulo con esquinas redondeadas se usa para mostrar la presencia de un proceso de transformacin. Los procesos siempre denotan un cambio en los datos o una transformacin de estos; por lo tanto el flujo de datos que sale de un proceso siempre se designa de forma diferente al que entra en el. Los procesos representan trabajo que se realiza en el tema y se deben nombrar usando uno de los formatos siguientes: Se le debe asignar un nombre claro ya que este permite reconocer fcilmente lo que hace un proceso. 1. A los procesos de alto nivel asigna el nombre del sistema. Por ejemplo: SISTEMA DE CONTROL DE VENTAS.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 2. Para nombrar un subsistema principal, se usa un nombre como SUBSISTEMA DE INFORMACION DE VENTAS O SISTEMAS DE CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET. 3. Para los procesos detallados se usa un formato de sustantivoverbo-adjetivo. El sustantivo indica cual es el resultado principal del proceso, tal como INFORME O REGISTRO. El verbo describe el tipo de actividad, tal como CALCULAR, VERIFICAR, PREPARAR, IMPRIMIR O AGREGAR. El adjetivo describe el resultado especfico que se produce tal como NUEVO PEDIDO o INVENTARIO. Ejemplos de nombres de procesos son CALCULAR IMPUESTOS DE VENTAS, VERIFICAR ESTADOS DE CUENTA DEL CLIENTE, PREPARAR FACTURA DE ENVIO, IMPRIMIR INFORME DE NUEVOS PEDIDOS, ENVIAR CONFIRMACION AL CLIENTE POR CORREO ELECTRONICO, VERIFICAR SALDO DE TARJETA DE CREDITO Y AGREGAR REGISTRO DE INVENTARIO. A un proceso se le debe de asignar un nmero de identificacin nico y exclusivo, que indique su nivel en el diagrama. Podra haber varios flujos de datos que entren y salgan de cada proceso. Los procesos con solo un flujo de entrada y salida se deben examinar en busca de flujos de datos perdidos. El rectngulo abierto representa un almacn de datos. Estos smbolos se dibujan con el espacio suficiente para que quepan las letras de identificacin como se muestra en la figura. En los diagramas de flujo de datos lgicos no se especifica el tipo de almacenamiento a un lugar. En este punto el smbolo del almacn de datos simplemente muestra un lugar de depsito para los datos que permite examinar, agregar y recuperar datos.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS El almacn de datos podra representar un almacn manual, tal como un gabinete de archivo, un archivo o una base de datos de computadora. A los almacenes de datos se les asigna un nombre debido a que representan a una persona, lugar o cosa. Los almacenes de datos temporales, tales como papel borrador o un archivo temporal de computadora, no se incluyen en el diagrama de flujo de datos. Para identificar el nivel del almacn de datos, a cada uno asgnele un nmero de referencia nica, tal como D1, D2, D3 etc. Desarrollo de diagramas de flujos de datos Los diagramas de flujos de datos se pueden y deben dibujar de manera sistemtica. Primero se deben visualizar los flujos de datos desde una perspectiva jerrquica de arriba a bajo. En seguida se describen los pasos a seguir. Lista de actividades: Para empezar un diagrama de flujo de datos, se debe sintetizar la narrativa(o historia) del sistema de la organizacin en una lista con las cuatro categoras de entidad externa, flujo de datos, procesos, y almacn de datos. Esta lista a su vez ayudara a determinar los lmites del sistema que describir. Una vez que se haya recopilado una lista bsica de elementos de datos se empieza a dibujar el diagrama de contexto. Creacin de diagrama de contexto: Con un enfoque jerrquico de arriba hacia abajo para diagramar el movimiento de los datos, los diagramas van de lo general a lo especfico. Aunque el primer diagrama ayuda a entender el movimiento bsico de los datos, lo general de su naturaleza limita su utilidad. El diagrama de contexto inicial debe de mostrar un panorama global que incluya las entradas bsicas, el sistema general y las salidas. Este diagrama ser el mas general, con una visin muy superficial

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS del movimiento de los datos en el sistema y una visualizacin lo mas amplia posible del sistema. El diagrama de contexto es el nivel ms alto en un diagrama de flujo de datos y contiene un solo proceso, que representa a todo el sistema. Al proceso se le asigna el numero cero. En este diagrama se muestran todas las entidades externas, as como los flujos de datos principales que van desde y hacia dichas entidades. El diagrama no contiene ningn almacn de datos. Es bastante simple la creacin ya que se conocen las entidades externas y el flujo de datos desde y hacia ellas. Dibujo del diagrama 0 (el siguiente nivel): Al ampliar los programas se puede lograr un mayor detalle que con los diagramas de contexto. Las entradas y salidas especificadas en el primer diagrama permanecen constantes en todos los diagramas que le siguen. Sin embargo, el resto del diagrama original se amplia para incluir de tres a nueve procesos y mostrar almacenes de datos y nuevos flujos de datos de menor nivel. Cada diagrama ampliado debe ocupar una sola hoja de papel. Al ampliar los DFDs para representar subprocesos, en este paso se empiezan a completar los detalles del movimiento de los datos. El manejo de excepciones se ignora en los primero dos o tres niveles del diagrama de flujo de datos.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Entrada A Entidad 1

0
Salida C Entrada B

Nombre del Sistema

Entidad 3

Entidad 2

1
Entrada A Entidad 1

2
Flujo de datos B

Salida C

Proceso general AAA

Proceso general BBB

Entidad 3

Registro A

Registro E

D1

Almacn de

Datos 2

D2

Almacn de

Datos 2

Registro A

Registro E

3
Entrada B Entidad 2

4
Flujo de datos D

Proceso general CCC

Proceso general DDD

Figura 3.2 Representacin del diagrama de contexto y del diagrama cero

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 ed

El diagrama cero es la ampliacin del diagrama de contexto y puede incluir hasta nueve procesos, esto se hace porque si se agregan ms procesos producir un diagrama difcil de entender. Por lo general, cada proceso se numero con un entero, empezando en la esquina superior izquierda del diagrama y terminando en la esquina inferior derecha. En el diagrama cero se incluyen los principales almacenes de datos del sistema (que representan a los archivos maestros) y todas las entidades externas. La figura 3.2 representa grficamente el diagrama de contexto y el diagrama cero.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal), se puede empezar en cualquier punto del diagrama e ir hacia delante o hacia atrs. Si no esta seguro de lo que podra incluir en cualquier punto, tome una entidad externa, un proceso o un almacn de datos diferente y empiece a dibujar el flujo a partir de l: 1. Empezamos con el flujo de datos de una entidad en el lado de la entrada. Se hacen preguntas como: Qu sucede con los datos que entran en el sistema? Se almacenan? Esta entrada es para varios procesos? 2. Trabajamos hacia atrs a partir de un flujo de datos de salida. Examinamos los campos de salida de un documento o pantalla. (Este enfoque es ms sencillo si se han creado prototipos.) Se pregunta sobre cada campo de la salida: "De dnde viene?" o "Se calcula o almacena en un archivo?" Por ejemplo, cuando la salida es un RECIBO DE NOMINA, el NOMBRE DEL EMPLEADO y la DIRECCION se podran localizar en un archivo EMPLEADO, las HORAS TRABAJADAS podran encontrarse en un REGISTRO DEL TIEMPO y el SUELDO BRUTO y las DEDUCCIONES se tendran que calcular. Cada archivo y registro estara conectado al proceso que produce el recibo de nmina. 3. Examinamos el flujo de datos desde o hacia un almacn de datos. Se pregunta: "Qu procesos ponen los datos en el almacn?" o "Qu procesos usan los datos?" Observamos que un almacn de datos utilizado en el sistema en el que se esta trabajando podra ser producido por un sistema diferente. Por lo tanto, desde su punto de vista, tal vez no haya ningn flujo de datos hacia el almacn de datos.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 4. Analizamos un proceso bien definido. Vea qu entrada de datos necesita el proceso y qu salida produce. Se hace un vnculo la entrada y la salida con los almacenes de datos y las entidades adecuadas. 5. Tome nota de cualquier rea confusa en donde no est seguro de lo que se debe incluir o de la entrada o la salida que se requiera. Al conocer las reas problemticas podr realizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave. Revisin de Errores en lo diagramas Cuando se dibujan diagramas de flujos de datos se pueden cometer varios errores comunes como los siguientes: 1. Olvidar incluir un flujo de datos o apuntar con una flecha en la direccin incorrecta. Un ejemplo es un proceso dibujado que muestra todos sus flujos de datos como entrada o salida. Cada proceso transforma datos y debe recibir una entrada y producir una salida. Este tipo de error ocurre generalmente cuando el analista olvida incluir un flujo de datos o coloca una flecha que apunta en la direccin incorrecta. 2. Conectar directamente entre s almacenes de datos y entidades externas. Los almacenes de datos y las entidades externas no se deben conectar entre s; slo se deben conectar con un proceso. Un archivo no interacta con otro archivo sin la ayuda de un programa o una persona que mueva los datos. Las entidades externas no trabajan directamente con los archivos. Dos entidades externas conectadas directamente indican que desean comunicarse entre s. Esta conexin no se incluye en el diagrama de flujo de datos a menos que el sistema facilite la comunicacin. La elaboracin de un informe es un ejemplo de esta clase de comunicacin. Sin embargo,

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS es necesario interponer un proceso entre las entidades para producir el informe. 3. Asignar nombres incorrectos a los procesos o al flujo de datos. Es necesario revisar el diagrama flujo de datos para asegurar que cada objeto o flujo de datos tenga un nombre adecuado. Un proceso debe indicar el nombre del sistema o usar el formato sustantivoverbo-adjetivo. Cada flujo de datos se debe describir con un sustantivo. 4. Incluir ms de nueve procesos en un diagrama de flujo de datos. La inclusin de demasiados procesos origina un diagrama confuso difcil de entender y obstaculiza la comunicacin en lugar de facilitada. Si en un sistema existen ms de nueve procesos, agrupe en un subsistema algunos de los procesos que trabajan en conjunto y pngalos en un diagrama hijo, 5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es decir, flujo de datos en el cual cada proceso tiene slo una entrada y una salida. El flujo de datos lineal no es muy comn, excepto en los diagramas de flujo de datos hijos muy detallados, su presencia normalmente indica que al diagrama le falta algn flujo de datos. 6. Crear una separacin (o ampliacin) desequilibrada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso padre, Una excepcin a esta regla son las salida menores, como las lneas de error, que se incluyen solamente en el diagrama hijo. En seguida se sintetizan los pasos para desarrollar eficazmente diagramas de flujo de datos, usando un enfoque jerrquico de arriba a bajo:

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 1. Haga una lista de las actividades del negocio y sela para determinar lo siguiente: Entidades externas Flujos de datos Procesos Almacn de datos

2. Crear un diagrama de contexto que muestre las entidades externas y los flujos de datos desde y hacia el sistema. No muestre ejemplos ni almacenes de datos detallados. 3. Dibujar el diagrama 0(el siguiente nivel). Muestre procesos, pero que sean generales. En este nivel muestre almacenes de datos. 4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0 5. Revise que no haya errores y asegrese de que sean significativos los nombres que haya asignado a cada proceso y flujo de datos. 6. Desarrolle un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico. Distinga entre los procesos manuales y automatizados, describa los archivos reales y los informes por nombre y agregue controles para indicar cuando se completan los procesos o cuando ocurren errores. 7. Ahora se hace una particin el diagrama de flujo de datos fsico separando o agrupando sus partes con el propsito de facilitar la programacin y la implementacin.

Diagramas de flujos de datos lgicos y fsicos

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Los diagramas de flujo de datos se catalogan como lgicos o fsicos. Un diagrama de flujo de datos lgico se enfoca en el negocio y en el funcionamiento de ste. No se ocupa de manera en que se construir el sistema. Ms bien, describe los eventos que ocurren en el negocio y los datos requeridos y producidos por cada evento. Por el contrario, un diagrama de flujo de datos fsico muestra cmo se implementar el sistema, incluyendo el hardware, el software, los archivos y las personas involucradas en el sistema. En la Tabla 3.1 se muestra un cuadro que compara las caractersticas de los modelos lgico y fsico. Observe que el modelo lgico refleja el negocio, mientras que el modelo fsico describe el sistema.
Caractersticas del diseo
Que describe el modelo

Lgico
Como funciona el negocio

Fsico
Como se implementar el sistema (o como funciona el sistema actual) Programas, mdulos del programa y procedimientos manuales Archivos y bases de datos fsicos, archivos manuales Archivos maestros, archivos de transicin. Cualesquier proceso que operen en dos momentos diferentes deben conectarse mediante un almacn de datos Muestra controles para validar los datos de entrada, para obtener un registro (el estado de un registro), para asegurar la realizacin exitosa de un proceso y para la seguridad del sistema

Que representan los procesos Que representan los almacenes de datos Tipos de almacenes de datos

Las actividades del negocio

Colecciones de datos independientemente de como se almacenan. Muestra almacenes de datos que representan colecciones de datos permanentes

Que representan los almacenes de datos

Que representan los almacenes de datos

Tabla 3.1 Caractersticas modelos lgicos y fsicos

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 ed

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Diagrama de flujo de datos lgico actual

Obtenga el diagrama de flujo de datos lgico para el sistema actual examinando el diagrama de flujo de datos fsico y separando las actividades nicas del negocio

Nuevo diagrama de flujo de datos lgico Nuevo diagrama de flujo de datos fsico

Cree el diagrama de flujo de datos lgico para el nuevo sistema agregando al diagrama de flujo de datos lgico del sistema actual las entradas, salidas y procesos requeridos en el nuevo sistema Obtenga el diagrama de flujo de datos fsico examinando los nuevos procesos en el nuevo diagrama lgico. Determine en donde deben existir la interfaz de usuario, la naturaleza de los procesos y los almacenes de datos necesarios Tabla 3.2 Progresin del diagrama de flujo de datos

Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 ed

Una ventaja de construir el diagrama de flujo de datos lgico del sistema actual es que puede usar para crear el diagrama de flujo de datos lgico del nuevo sistema. Los procesos innecesarios en el nuevo sistema se podran eliminar y agregar nuevas caractersticas, actividades, salidas, entradas y datos almacenados. Mediante este enfoque se garantiza que el nuevo sistema conservar las caractersticas esenciales del sistema anterior. Adems, el uso del modelo lgico del sistema actual como base para el sistema propuesto ofrece una transicin gradual para el diseo del nuevo sistema, Una vez desarrollado el modelo lgico para el nuevo sistema, se podra usar para crear un diagrama de flujo de datos fsico par tal sistema. Particionamiento de los diagramas de flujos de datos Este es un proceso de examinar un diagrama de flujo de datos y se determina como se debe dividir en colecciones de procedimientos manuales y colecciones de programas de cmputo. Analice cada

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS procedo para determinar si debe ser un proceso manual o automatizado. Agrupe los procedimientos automatizados en una serie de programas de cmputo. Usualmente se traza una lnea punteada alrededor de un proceso o grupo de procesos que deben colocarse en un solo programa de cmputo. Existen seis razones para particionar diagramas de flujos de datos: 1. Diferentes grupos de usuarios. Los procesos son realizados por varios grupos de usuarios diferentes, con frecuencia en distintas ubicaciones fsicas de la compaa?. Si es as, se deben particionar en diferentes programas de cmputo. 2. Sintonizacin. En esta parte se debe examinar que los procesos se sincronicen. Si dos procesos se realizan en diferentes momentos, no se puede agrupar en un programa. 3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible agruparlos en un solo programa de cmputo. 4. Eficiencia. En un programa se podra combinar varios procesos para realizar un procesamiento eficiente. 5. Consistencia de los datos. Los procesos se podran combinar en un solo programa para mantener la consistencia de los datos. 6. Seguridad. Los procesos se podran particionar en diferentes programas por razones de seguridad.

3.1.2 DICCIONARIOS DE DATOS

El diccionario de datos surge de la necesidad de catalogar los procesos, flujos almacenes estructuras y elementos de datos. Los nombres que se usan son muy importantes. Cuando se tiene la oportunidad de asignar

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS nombre a los componentes de los sistemas orientados a datos, es necesario trabajar en la creacin de un nombre significativo pero diferente al de otros componentes de datos existentes. Se ha propuesto el diccionario de datos como gramtica casi formal para describir el contenido de los objetos definidos durante el anlisis estructurado. Esta notacin ha sido definida de la siguiente forma por Yourdon en 1989: El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tenga una misma comprensin de las entradas, salidas, de los componentes de los almacenes y tambin los clculos intermedios. Muchos sistemas de administracin de base de datos estn equipados con un diccionario de datos automatizado. Estos diccionarios pueden ser complejos o sencillos, algunos diccionarios de datos computarizados catalogan automticamente los elementos de datos cuando se hace la programacin; otros simplemente proporcionan una plantilla para motivar a la persona que llene el diccionario a que lo haga de una manera uniforme para cada entrada. A pesar de la existencia de los diccionarios de datos automatizados, entender qu datos conforman un diccionario de datos, las convenciones usadas en estos ltimos y cmo se desarrolla un diccionario de datos, son problemas que el analista de sistemas debe tener siempre presentes durante el esfuerzo de sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Adems de proporcionar documentacin y eliminar la redundancia, el diccionario datos se podra usar para: 1. Validar la integridad y exactitud del diagrama de flujo de datos. 2. Proporcionar un punto de partida para desarrollar pantallas e informes, 3. Determinar el contenido de los datos almacenados en archivos. 4. Desarrollar la lgica para los procesos del diagrama de flujo de datos, Deposito de datos Aunque el diccionario de datos contiene informacin de los datos y procedimientos, una coleccin ms grande de informacin de proyectos se llama depsito, El concepto depsito es uno de los muchos impactos de las herramientas CASE y podra contener lo siguiente: 1. Informacin sobre los datos mantenidos por el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros y elementos. 2. Lgica de procedimientos. 3. Diseo de pantallas e informes. 4. Relaciones entre datos, por ejemplo cmo se vincula una estructura de datos con otra. 5. Requerimientos del proyecto y productos del sistema final. 6. Informacin sobre la administracin del proyecto, tal como itinerarios de entrega," problemas pendientes de solucin y usuarios del proyecto.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Por lo general, los flujos de datos son los primeros elementos que se definen. Las entradas y salidas del sistema se determinan mediante las entrevistas y la observacin de los usuarios, y el anlisis de documentos y de otros sistemas existentes. La informacin capturada se puede resumir usando un formulario que contenga la siguiente informacin: 1. ID, un numero de identificacin opcional. A veces este se codifica usando un esquema para identificar el sistema y la aplicacin del sistema. 2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama y se debe referenciar en todas las descripciones que usen el flujo de datos. 3. Un a descripcin general del flujo de datos. 4. La fuente del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn de datos. 5. El destino del flujo de datos. Esta podra ser una entidad externa, un proceso o influjo de datos proveniente de un almacn de datos. 6. Algo que indique si el flujo de datos es un registro que esta entrando o saliendo de un archivo o un registro que contiene un informe, formulario o pantalla. Si el flujo de datos contiene datos que se usan entre los procesos, se designa como interno. 7. El nombre de la estructura de datos que describe los elementos encontrados en este flujo de datos. Para un flujo de datos simple, podran ser uno o varios elementos. 8. el volumen por unidad de tiempo. Los datos podran ser registros por da o cualquier otra unidad de tiempo. 9. Un rea para comentarios adicionales y anotaciones sobre el flujo de datos.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Descripcin de las estructuras de datos Normalmente las estructuras de datos se describen usando una notacin algebraica. Este mtodo permite al analista producir la vista de los elementos que constituyen la estructura de datos junto con informacin referente a dichos elementos. La notacin algebraica usa los siguientes smbolos: 1. Un signo de igual (=) significa esta compuesto de. 2. Un signo de suma (+) significa y. 3. Las llaves { } indican elementos repetitivos, tambin llamados grupos de repeticin o tablas. En el grupo podra haber un elemento de repeticin o varios de ellos. El grupo de repeticin podra tener condiciones, tal como un nmero fijo de repeticiones o limites superiores e inferiores para el nmero de repeticiones. 4. Los corchetes [ ] representan una situacin de uno u otro. Se podra representar un elemento u otro, pero no ambos. Los elementos listados entre los corchetes son mutuamente excluyentes. 5. Los parntesis ( ) representan un elemento opcional. Los elementos opcionales se podran dejar en blanco en la entrada de las pantallas y podran contener espacios o ceros para campos numricos en las estructuras de archivos. Elementos de datos Cada elemento de datos se debe definir una vez en el diccionario de datos y tambin se podra introducir previamente en un formulario de descripcin del elemento. Caractersticas de un formulario de descripcin de elementos: 1. ID del elemento. Esta entrada opcional permite construcciones entradas de diccionario de datos

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 2. El nombre del elemento. El nombre debe ser descriptivo, nico y basado en el propsito al cual esta destinado el elemento en la mayora de los programas o por el usuario principal del elemento. 3. 4. 5. Alias, son sinnimos u otros nombres para el elemento. Una descripcin breve del elemento Si el elemento es base o derivado. Elemento base es el que se teclea inicialmente en el sistema, nombre del cliente direccin o ciudad; se deben almacenar en archivos. Los elementos derivados son creados por procesos como resultado de clculo. 6. La longitud del elemento. Algunos elementos tienen longitudes estndar y otras veces pueden variar para otros elementos, aqu se debe decidir en conjunto con el usuario la longitud final. 7. 8. El tipo de datos: numrico, fecha, alfabtico o carcter que a veces se llama datos alfanumricos o de texto. Los formatos de entrada y salida se deben incluir, usando smbolos de codificacin especiales para indicar como se deben presentar los datos. 9. Los criterios de validacin para asegurar que el sistema capture los datos correctos. Los elementos pueden ser discretos, lo cual significa que tiene ciertos valores fijos o continuos, con un rango parejo de valores. 10. Cualquier valor predeterminado que pudiera tener el elemento. El valor predeterminado se despliega en las pantallas de entrada y se usa para reducir la cantidad de datos que tuviera que teclear el operador. 11. Un rea adicional para observaciones o comentarios.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Creacin del diccionario de datos

Las entradas del diccionario de datos se podran crear despus de completar el diagrama de flujo de datos, o se podran construir conforme se desarrolle el diagrama de flujo de datos. El uso de notacin algebraica y registros estructurales permite desarrollar el diccionario de datos y los diagramas de flujos de datos mediante un enfoque jerrquico de arriba a bajo. Despus de realizar varias entrevistas adicionales para descubrir los detalles del sistema, se puede extender el diagrama de flujo de datos y se crearan los diagramas hijos. Posteriormente se modifica el diccionario de datos para incluir los nuevos registros estructurales y elementos recabados en las entrevistas, observacin y anlisis de documentos posteriores. Cada nivel de un diagrama de flujo de datos debe usar datos adecuados para el nivel. El diagrama 0 debe incluir nicamente formularios, pantallas informes y registros. Conforme se creen los diagramas hijos, el flujo de datos que entre y salga de los procesos ser cada vez incluyendo los registros estructurales y los elementos. Uso del diccionario de datos El diccionario de datos ideal es automatizado, interactivo, en lnea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organizacin, se agregan elementos de datos al diccionario de datos. El diccionario de datos no es un fin en si mismo y nunca debe serlo, siempre debe verse como una actividad paralela al anlisis y diseo de sistemas. mas detallado,

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS El diccionario de datos debe vincular a varios programas de sistemas para que cuando un elemento se actualice o elimine del diccionario de datos, ocurra lo mismo en la base de datos. El diccionario de datos se vuelve una curiosidad histrica sino se mantiene actualizado.

3.1.3 DISEO DE MODULOS

El concepto de modularidad se ha ido exponiendo desde hace casi cinco dcadas en el software de y computadora. abordados por La arquitectura de computadora expresa la modularidad; es decir, el software se divide en componentes problema. Se ha afirmado que La modularidad es el nico atributo del software que permite gestionar un programa intelectualmente. El software monoltico (es decir, un programa grande formado por un nico modulo) no puede ser entendido fcilmente por el lector. La cantidad de rutas de control, la amplitud de referencias, la cantidad de variables y la complejidad global har que el entendimiento este muy cerca de ser imposible. Para ilustrar este punto, tomemos en consideracin el siguiente argumento basado en observaciones humanas sobre la resolucin de problemas. Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mnimos que sean (por nombrados separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular. Diseo modular efectivo La modularidad se ha convertido en un enfoque aceptado en todas las disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un aspecto crtico de la capacidad de mantenimiento del software), y da como resultado una implementacin ms fcil al fomentar el desarrollo paralelo de las diferentes partes de un sistema. El concepto de independencia funcional es la suma de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. En referencias obligadas sobre el diseo del software, Pamas y Wirth sugieren a las tcnicas de refinamiento que mejoran la independencia de mdulos. Trabajos posteriores de Stevens, Wyers y Constantine consolidaron el concepto. La independencia funcional se consigue desarrollando mdulos con una funcin determinante y una aversin a una interaccin excesiva con otros mdulos. Es necesario disear el software de manera que cada mdulo trate una subfuncin de requisitos y tenga una interfaz sencilla cuando se observa desde otras partes de la estructura del programa. Los mdulos independientes son ms fciles de mantener (y probar) porque se limitan los efectos secundarios originados por modificaciones de diseo/cdigo; porque se reduce la propagacin de errores; y porque es

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS posible utilizar mdulos usables. En resumen, la independencia funcional es la clave para un buen diseo y el diseo es la clave para la calidad del software. La independencia se mide mediante dos criterios cualitativos: la cohesin y el acoplamiento. La cohesin es una medida de la fuerza relativa funcional de un mdulo. El acoplamiento es una medida de la independencia relativa entre los mdulos. Algunos lineamientos para la programacin modular son: Mantener cada mdulo de un tamao manejable (de manera ideal incluyendo slo una funcin). Prestar atencin particular en las interfaces criticas (esto es, a los datos y a las variables de control que pasan entre los mdulos). Minimizar el nmero de mdulos que el usuario necesite modificar cuando haga cambios. Mantener las relaciones jerrquicas establecidas en las etapas de descenso. 3.1.4 DESCOMPOSICION EN PROCESOS Las fases que generalmente caracterizan al proceso del software son: definicin desarrollo y soporte, se aplican a todo software. El problema es seleccionar el modelo de proceso apropiado para la ingeniera del software que debe aplicar el equipo. El gestor del proyecto debe decidir que modelo de proceso es el ms adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizara el trabajo; 2. Las caractersticas del producto en si y

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 3. El entorno del proyecto en el que trabaja el equipo de software. Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en conjunto de actividades estructurales. Una vez establecido el plan preliminar, empieza la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales.

Un equipo debera tener un grado significativo de flexibilidad en la eleccin del paradigma de ingeniera de software que resulte mejor para el proyecto y de las tareas de ingeniera del software que conforman el modelo de proceso una vez elegido. Un proyecto cuando es relativamente pequeo se debe realizar con un enfoque secuencial lineal. Si hay limites de tiempo muy severos y le problema se puede compartir, el modelo apropiado es el DRA. Si se tiene el tiempo limitado lo mas apropiado es tomar una estrategia incremental. Una vez que hemos elegido el modelo de proceso, la Estructura Comn de Procesos (ECP) se adapta a el. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos iterativos e incrementales, para modelos de evolucin e incluso para modelos concurrentes o de ensamblaje de componentes. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organizacin.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Las tareas de trabajo reales si varan. La descomposicin del proceso comienza cuando el gestor del proyecto pregunta Cmo vamos a realizar esta actividad ECP? Un proyecto simple requiere las siguientes tareas para la actividad de comunicacin con el cliente: 1. Desarrollar una lista de aspectos que se deben aclarar 2. Reunirse con el cliente para aclara los aspectos de la lista 3. Desarrollar en conjunto una exposicin del mbito del proyecto 4. Revisar el alcance del proyecto con todos los implicados 5. Modificar el alcance del proyecto cuando se requiera. Este tipo de acontecimientos pueden ocurrir en un periodo de menos de 48 hrs. Representan una descomposicin del problema apropiado para proyectos pequeos relativamente sencillos. Si se considera un proyecto ms complejo que tenga un mbito ms amplio y un mayor impacto comercial. Un proyecto como se podra requerir las siguientes tareas para la actividad de comunicacin con el cliente: 1. Revisar la peticin del cliente 2. Planificar y programar una reunin formal con el cliente 3. Realizar una investigacin para definir soluciones propuestas y enfoques existentes. 4. Prepara un plan de trabajo y una agenda para la reunin formal 5. Realizar la reunin 6. Desarrollar conjuntamente mini-especificaciones que reflejen la informacin, funcin y caractersticas de comportamiento del software

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS 7. Revisar todas las mini-especificaciones para comprobar su correccin , su consistencia la ausencia de ambigedades 8. Ensamblar las mini-especificaciones de un documento de alcance del proyecto 9. revisar ese documento general con todo lo que pueda afectar 10. modificar el documento de alcance del proyecto cuando se requiera. 3.2 EL ENFOQUE ORIENTADO A OBJETOS El anlisis orientado a objetos (AOO) y el diseo orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas tcnicas se basan en los conceptos de la programacin orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelacin), un lenguaje estandarizado de modelacin en el cual los objetos generados no solo incluyen cdigo referente a los datos sino tambin instrucciones acerca de las operaciones que se realizaran sobre los datos. EL Paradigma Orientado a Objetos es una disciplina de ingeniera de desarrollo y modelado de software que permite construir ms fcilmente sistemas complejos a partir de componentes individuales. Objetos + Mensajes = Programa El proceso Orientado a Objetos se mueve a travs de una espiral evolutiva que comienza con la comunicacin con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases bsicas del problema. La planificacin y el anlisis de riesgos establecen una base

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS para el plan de proyecto OO. El trabajo tcnico asociado con la ingeniera del software OO sigue las siguientes tareas: 1. 2. 3. 4. 5. 6. Identificar clases candidatas Buscar clases en biblioteca Extraer nuevas clases si existen Desarrollar las clases sino existen Aadir las nuevas clases a la biblioteca Construir n-esima iteracin del sistema

La ingeniera de software hace hincapi en la reutilizacin. Por lo tanto las clases se buscan en una biblioteca (de clases existentes) antes de construirse Las Caractersticas del Enfoque Orientado a Objetos son: a) Objeto: Los datos estn cuantificados en entidades discretas y distinguibles llamadas objetos. b) Clase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase. c) Atributo: Describen la clase o el objeto de alguna manera d) Mensajes: Medio por el cual interactan los objetos e) Polimorfismo: Significa que una misma operacin puede comportarse de modos distintos en distintas clases. f) Herencia: Compartir atributos y operaciones entre clases tomando como base una relacin jerrquica. Objeto

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Un objeto es una unidad de cdigo compuesto de variables y mtodos relacionados. Un objeto encapsula datos, operaciones, otros objetos, constantes y otra informacin relacionada. Pueden ser: Entidades externas, ocurrencias o eventos, papeles o roles, unidades organizacionales, lugares, estructuras. Los Objetos tienen caractersticas y comportamientos. Mantiene sus caractersticas en una o ms "variables", e implementa su comportamiento con "mtodos". Un mtodo es una funcin o subrutina asociada a un objeto. Cuando a las caractersticas del objeto le ponemos valores decimos que el objeto tiene estados. Las variables almacenan los estados de un objeto en un determinado momento. Para ser considerado como valido un objeto debe de tener las siguientes caractersticas:

Informacin retenida Servicio necesario Atributos mltiples Atributos comunes Operaciones comunes Requisitos esenciales

Clase La clase es un modelo o prototipo que define las variables y mtodos comunes a todos los objetos de cierta clase.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Una clase es una descripcin generalizada que describe una coleccin de objetos con caractersticas similares. Todos los objetos que existen dentro de una heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin de clases y una instancia de una clase. Una instancia de una clase es otra forma de llamar a un objeto. En realidad no existe diferencia entre un objeto y una instancia. Slo que el objeto es un trmino ms general, pero los objetos y las instancias son ambas representacin de una clase. Atributo Los Atributos estn asociados a clases y objetos, ellos describen la clase y el objeto de alguna manera. Un atributo puede tomar un valor definido por un dominio enumerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores especficos. En situaciones ms complejas el dominio puede ser un conjunto de clases. Mensajes Los mensajes son el medio a travs del cual los objetos intercambian informacin. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta una operacin.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Un objeto es intil si est aislado. El medio empleado para que un objeto interacte con otro son los mensajes. Hablando en trminos un poco ms tcnicos, los mensajes son invocaciones a los mtodos de los objetos. Encapsulamiento El encapsulamiento significa que toda la informacin de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de un programa. El encapsulamiento consiste en unir en la clase las caractersticas y comportamientos, esto es, las variables y mtodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstraccin y el ocultamiento. La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde slo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesar ser conocer qu hace la clase pero no ser necesario saber cmo lo hace. EL Ocultamiento es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer slo los detalles que sean necesarios para el resto del sistema. [7] El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque habr cierto comportamiento privado de la Clase que no podr ser accedido por otras Clases. Y controlar porque daremos ciertos

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS mecanismos para modificar el estado de nuestra Clase y es en estos mecanismos dnde se validarn que algunas condiciones se cumplan. En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected delante de las variables y mtodos. Herencia La herencia consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de los atributos y mtodos propios, tiene incorporados los atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes. Solo es necesario declarar que la clase A hereda de la clase B y despus proporcionar cualquier detalle adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programacin adicional. [7] Polimorfismo El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.

3.2.1 ANALISIS
El AOO ha sido muy exitoso en derribar problemas que se resisten al anlisis estructurado, como las interfaces de usuario. El AOO proporciona una transicin sin igual hacia el DOO y la programacin en lenguajes como

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Smalltalk, Ada y C++, y es el mtodo de anlisis preferido cuando los mtodos orientados a objetos van a ser utilizados posteriormente en la vida del sistema. Adems, los partidarios del AOO argumentan que los objetos dentro de un sistema son ms fundamentales (importantes, necesarios) para su naturaleza que las funciones que proporciona. Las especificaciones basadas en los objetos sern ms adaptables que las especificaciones basadas en las funciones. Los mtodos que marcan las directrices del AOO son: Coad-Yourdon Tcnica de modelado de objetos de Rumbaugh (Object Modelling Technique OMT) Shlaer-Mellor Booch ROOM Fusin

Coad y Yourdon Coad y Yourdon describen un mtodo de Anlisis Orientado a Objetos basado en cinco actividades principales: Definicin de las clases y objetos Identificacin de estructuras Identificacin de temas Definicin de atributos Definicin de servicios

Estas actividades son usadas para construir cada capa de un modelo de objetos de cinco niveles. Los objetos existen en el mbito del problema.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Las clases son abstracciones de objetos. Los objetos son instancias de clases. La primera tarea del mtodo es identificar las clases y los objetos. La segunda tarea del mtodo es identificar las estructuras. Se reconocen dos tipos de estructuras: estructuras de generalizacin especializacin y estructuras globales [whole-part]. El primer tipo de estructura es como un rbol genealgico: es posible la herencia entre los miembros de una estructura. El segundo tipo de estructura es utilizado para modelar relaciones de entidades (por ejemplo: cada motor contiene una armadura). Los modelos grandes y complejos pueden necesitar una organizacin temtica, con cada (asunto, atributo, en lugar de tema) tema dedicado a un aspecto particular del problema. Por ejemplo, el modelo de objetos de un vehculo de motor puede tener una perspectiva mecnica o una perspectiva elctrica. Los atributos caracterizan a cada clase. Por ejemplo, un atributo de una mquina puede ser el numero de cilindros. Cada objeto tendr un valor para ese atributo. Los servicios definen lo que los objetos hacen. Definir los servicios es equivalente a definir las funciones del sistema. La importancia fundamental del mtodo de Coad y Yourdon es su descripcin breve y concisa, as como el uso de textos generales como fuentes para las definiciones; de modo que las definiciones se enmarcan dentro del sentido comn y reducen el empleo de modismos. La debilidad principal del mtodo es su notacin compleja, la cual es difcil de utilizar sin

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS el apoyo de una herramienta. Algunos usuarios del mtodo Coad-Yourdon han utilizado la dotacin de diagramacin de OMT en su lugar. Tcnica de Modelado de Objetos La Tcnica de Modelado de Objetos (OMT, Object Modelling Technique) transforma la definicin del problema del usuario (como la que se documenta en un Documento de Requerimientos del Usuario) en tres modelos: Modelo de objetos Modelo dinmico Modelo funcional

Los tres modelos en conjunto crean el modelo lgico requerido por los Estndares de Ingeniera de Software. El modelo de. El procedimiento para construirlo es el siguiente: Identificacin de los objetos Identificacin de las clases de objetos Identificacin de las asociaciones (ejemplo: las relaciones) entre objetos Identificacin de los atributos de los objetos Uso de herencia para organizar y simplificar la estructura de clases Organizacin de las clases y asociaciones estrechamente acopladas dentro de mdulos Acompaar a cada objeto con breves descripciones textuales

Los tipos ms importantes de asociacin son la adicin (es parte de) y la generalizacin (es un tipo de).

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

El

modelo

dinmico

muestra

el

comportamiento

del

sistema,

especialmente la secuencia de interacciones. El procedimiento para construirlo es el siguiente: Identificar las secuencias de eventos dentro del mbito del problema y documentarlo en el seguimiento (rastreo) de eventos Construir un diagrama de transicin de estados para cada objeto que sea afectado por los eventos, mostrando los mensajes que fluyen, las acciones que son realizadas y los cambios en el estado de los objetos que tienen lugar cuando ocurren los eventos. El modelo funcional muestra la forma en que se obtienen los valores, sin considerar el momento en que sean computadas. El procedimiento para construirlo no requiere el uso de la descomposicin funcional, sino de: Identificar la entrada y salida de valores que el sistema recibe y produce Construir diagramas de flujo de datos que muestren la forma en que los valores de salida son computados a partir de los valores de entrada Identificar los objetos que son utilizados como almacenes de datos Identificar las operaciones de los objetos que comprenden cada proceso El modelo funcional es sintetizado a partir de las operaciones de objetos, en vez de descomponerlo desde una funcin de alto nivel. Las operaciones de los objetos pueden ser definidos en cualquier etapa durante el modelado. Los aspectos ms importantes del OMT son sus capacidades simples aunque poderosas de notacin as como su madurez. Ha sido aplicado en varios proyectos por sus autores antes de ser

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS publicado. La principal debilidad es la falta de tcnicas para integrar los modelos de objetos, los modelos dinmicos y los modelos funcionales. Schlaer y Mellor Schlaer y Mellor comienzan el anlisis identificando el mbito del problema del sistema. Cada mbito es un mundo separado habitado por sus propias entidades conceptuales u objetos. Los mbitos ms grandes son divididos en subsistemas. Despus, cada mbito o subsistema es analizado de forma separada en tres etapas: Modelado de la informacin Modelado de estado Modelado de procesos

Las tres actividades de modelado crean en conjunto el modelo lgico requerido por los Estndares de Ingeniera de Software. El objetivo del modelado de informacin es identificar: Los objetos dentro del sistema Los atributos de cada objeto Las relaciones entre cada objeto

El modelo de informacin es documentado mediante diagramas y definiciones de objetos, atributos y relaciones. El objetivo del modelo de estado es identificar: Los estados de cada objeto, y las acciones que se realizan sobre ellos Los eventos que causan que los objetos pasen de un estado a otro

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Las secuencias de estados que forman el ciclo de vida de cada objeto Las secuencias de mensajes que comunican los eventos que fluyen entre los objetos y los subsistemas Los modelos de estado son documentados mediante diagramas de modelo de estados (mostrando las secuencias de estados), diagramas de modelos de comunicacin de objetos (mostrando los mensajes que fluyen entre los estados), y listas de eventos. El objetivo del modelo de proceso es identificar: Las operaciones de cada objeto requeridas durante cada accin Los atributos de cada objeto que son almacenados en cada accin

Los modelos de proceso son documentados mediante diagramas de accin de flujo de datos, mostrando las operaciones y el flujo de datos que ocurren en cada accin, y los diagramas de modelo de acceso de objeto, mostrando el acceso de datos entre objetos. Los procesos complejos tambin deben ser descritos. La fuerza del mtodo Schlaer-Mellor es su madurez (sus autores declaran haber estado desarrollndolo desde 1979) y la existencia de tcnicas para integrar los modelos de informacin, los modelos de estado y los modelos de proceso. La principal debilidad del mtodo es su complejidad. Booch Booch modela un diseo orientado a objetos desde un punto de vista lgico, el cual define las clases, los objetos y sus relaciones; y desde un punto de vista fsico, que define la arquitectura de mdulos y procesos. La

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS perspectiva lgica corresponde al modelo lgico que deben construir los ingenieros de software de acuerdo a los requerimientos de los estndares de Ingeniera de Software. El mtodo orientado a objetos de Booch tiene cuatro pasos: 1. Identificacin de clases y objetos a un nivel dado de abstraccin 2. Identificacin de la semntica de estas clases y objetos 3. Identificacin de las relaciones entre esas clases y objetos 4. Implementacin de las clases y objetos Las primeras tres etapas deben ser completadas dentro de la etapa de Requerimientos del Sistema. La ltima etapa es realizada dentro de las fases de AD y DD. Booch sostiene que el proceso de diseo orientado a objetos no es deductivo [top-down] ni inductivo [bottom Up], sino algo que l denomina round-trip gestalt design [diseo gestalt (conocimiento) de viaje redondo]. El proceso desarrolla un sistema a manera de incrementos e iteraciones. A los usuarios del mtodo de Booch se les advierte que deben integrar las fases SR y AD en una sola fase de modelado. Booch ofrece cuatro tcnicas para la documentacin de la perspectiva lgica: Diagramas de clase: consiste en un conjunto de clases y relaciones entre ellas. Puede contener clases, clases paramtricas, utilidades y metaclases. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciacin y metaclase. Diagramas de objetos: muestra objetos en el sistema y su relacin lgica. Pueden ser diagramas de escenario, donde se muestra cmo colaboran los objetos en cierta operacin; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Diagramas de estado-transicin: muestran los estados posibles de cada clase, as como los eventos que ocasionan las transiciones de un estado a otro Diagramas de tiempo: aumenta un diagrama de objetos con informacin acerca de eventos externos y tiempo de llegada de los mensajes

Los libros de Booch sobre mtodos orientados a objetos han sido descritos por Stroustrup, el inventor de C++, como los nicos y mejores libros sobre el tema. Este cumplido revela los diversos alcances y la profundidad de un buen anlisis y prctica de diseo en sus escritos. Sin embargo, la notacin de Booch es molesta y hay pocas herramientas disponibles. ROOM ROOM es una metodologa de Modelado Orientada a Objetos en Tiempo Real desarrollado por la compaa Object Time Developer. Esta metodologa ofrece varios puntos importantes: La complejidad esencial de reactivar sistemas es suficientemente alta para requerir conceptos de modelado especializado. ROOM toma ventajas de muchos desarrollos recientes de la tecnologa de computadoras (mtodos formales, el paradigma de objetos, interfaces grficas al usuario) Tambin, ROOM fue diseado explcitamente para tomar ventaja de la automatizacin basada en computadoras de las dems actividades mecnicas de desarrollo. Esto proporciona un potencial nico para beneficios significativos en productividad y calidad

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Estructura del modelado Utiliza sintaxis grfica para una fcil comprensin Abstracciones para tratar con fenmenos arquitectnicos de alto nivel de grandes sistemas de tiempo real. Protocolo basado en mltiples interfaces Objetos concurrentes (actores) Estructuras dinmicas Estructuras reproducidas

Modelado del comportamiento Alto nivel basado en sintaxis grfica Utiliza mquinas de estado jerrquicas; Permite elegir el modelado poderoso de capacidades, al tiempo que permite implementaciones automatizadas avanzadas y eficientes Prioridad basada en la manipulacin de eventos para tratar con requerimientos de tiempo real Incorpora la industria de lenguajes de programacin estndar (por ejemplo: C++) para detalles especficos. Experiencia Ms de cien diferentes proyectos industriales han utilizado ROOM Varios dominios de aplicacin:Incluyendo generacin de cdigo automtico completo Fusin El Mtodo Fusin est considerado como uno de los mtodos de desarrollo de Segunda Generacin. Proporciona elementos de desarrollo para y

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS con reusabilidad y reingeniera. Los siguientes mtodos o tcnicas han influido en Fusin: OMT (Rumbaugh, 1991): El modelo Objeto es casi similar que en OMT. El modelo operacional es anlogo al modelo funcional en OMT; los diagramas de flujo de datos de OMT no son apropiados de acuerdo con Coleman y han sido formalizados con pre y post condiciones. Mtodos formales: pre y post condiciones son adoptados para describir formalmente qu es lo que hace un sistema. CRC: CRC extendido con informacin de comunicacin ha influenciado en grficas de interaccin de objetos. Diseo OO con Aplicaciones (Booch,1991):La visibilidad de las grficas son influenciadas por informacin de visibilidad en los diagramas Objeto de Booch. Fusin se basa en un pequeo pero comprensivo conjunto de tcnicas para creacin de diagramas bien definidas para la descripcin de las etapas de anlisis y diseo. Fusin consiste de 3 fases: anlisis, diseo e implementacin. Fusin tambin proporciona reglas para verificar la consistencia e integridad del desarrollo de los modelos. En la fase de anlisis se define el comportamiento propuesto del sistema. Los modelos en esta fase describen las clases de objetos, las relaciones entre clases, las operaciones que pueden ser ejecutadas en el sistema y permite la realizacin de secuencias de esas operaciones. En la fase de diseo, los modelos producidos muestran la forma en que las operaciones del sistema son implementadas por objetos interactivos, referencias entre clases, relaciones de herencia, atributos de clases y operaciones en clases.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

En la fase de implementacin, la herencia, la referencia y los atributos de las clases son implementados en clases de un lenguaje de Programacin. Las interacciones entre objetos son programados como mtodos pertenecientes a la clase. Las mquinas estado (State Machines) son implementadas para reconocer secuencias permitidas de operaciones. En sus actividades se encuentran la codificacin, ejecucin y revisin. Fusin mantiene un diccionario de datos, un repositorio donde las diferentes entidades del sistema pueden ser nombradas y descritas.

3.2.2 DISEO
El Diseo Orientado a Objetos (DOO) es un enfoque del diseo de software basado en objetos y clases. Un objeto es una abstraccin de algo en el dominio de un problema o su implementacin, reflejando las capacidades de un sistema para proporcionar informacin acerca de l mismo, interactuar con l o con ambos; es un encapsulamiento de valores de atributo y sus servicios exclusivos. Una clase describe un conjunto de objetos con atributos y servicios comunes. Un objeto es una instancia de una clase, y el acto de crear un objeto se denomina: instantiation. Las clases pueden ser entidades con tipos de datos abstractos, como el Paquete de Telemetra y Espectro, as como entidades ms simples con tipos de datos primitivos como nmeros reales, enteros y cadenas de caracteres. Una clase es definida por sus atributos y servicios. Por ejemplo, la clase Espectro tendra atributos como frecuencia mnima, frecuencia media, frecuencia mxima y servicios tales como calibrar.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Las clases pueden ser divididas en subclases. Por ejemplo, pueden existir varios tipos de Paquetes de Telemetra, y pueden ser creadas subclases de Paquete de Telemetra tales como Paquete de Fotmetro y Paquete de Espectmetro. Las subclases comparten caractersticas familiares, y el DOO permite para ello, que las subclases hereden operaciones y atributos de sus padres. Esto conduce hacia sistemas modulares y estructurados, que requieren menos cdigo para ser implementados. El cdigo comn es automticamente localizado de una manera top-down. Los mtodos de diseo orientado a objetos, a diferencia de otros, ofrecen un mejor soporte para la reutilizacin. El mecanismo tradicional de reus bottom-up donde es perfectamente posible que un mdulo de aplicacin llame a un mdulo de librera. Adems, la caracterstica de herencia permite el reuso top-down de los atributos y las operaciones de la superclase. El DOO combina servicios e informacin, con esto incrementa la modularidad. Las estructuras de control y datos pueden ser definidas de una manera integrada. Otras caractersticas del enfoque orientado a objetos, adems de las clases, los objetos y la herencia son la transmisin de mensajes y el polimorfismo. Los objetos envan mensajes a otros objetos para dirigir sus servicios. Los mensajes tambin son utilizados para transmitir informacin. El polimorfismo es la capacidad, al momento de la ejecucin del programa, para referirse a las instancias de varias clases. El polimorfismo es a menudo implementado para permitir enlaces dinmicos. Las caractersticas de la orientacin a objetos como polimorfismo recaen en la asignacin dinmica de memoria. Esto puede hacer imprevisible el desempeo del software orientado a objetos. Debe tenerse cuidado al

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS momento de programar aplicaciones de tiempo real para asegurar que las funciones que deben completarse dentro de un lmite definido tengan su procesamiento completamente definido al momento de la compilacin y no durante la ejecucin. El DOO es ms efectivo cuando se implementa mediante lenguajes de programacin orientado a objetos que soporten la definicin de objeto, herencia, intercambio de mensajes y polimorfismo. Smalltalk, C++, Eiffel y Object Pascal soportan todas estas caractersticas. Las tcnicas orientadas a objetos han demostrado ser mucho ms satisfactorias para la implementacin de software conducido por eventos, como las Interfaces Grficas de Usuario (GUIs), que los mtodos estructurados. Muchas herramientas CASE para los mtodos estructurados han sido mejoradas para las tcnicas orientadas a objetos. Si los mtodos orientados a objetos van a ser utilizados, esto debe hacerse a todo lo largo del ciclo de vida. Esto significa que el DOO solamente debe ser seleccionado para la fase AD si el Anlisis Orientado a Objetos (OOA) ha sido utilizado en la fase de SR. La transicin del anlisis al diseo, y de este a la programacin es una de las mayores ventajas de los mtodos orientados a objetos, ya que facilita la interaccin. Uno de los primeros trabajos realizados por Booch, describe una tcnica para el diseo orientado a objetos. En la prctica los resultados no han sido satisfactorios. La perspectiva del anlisis estructurado est basado en las funciones y en los datos, y el enfoque de la orientacin a objetos est basada es clases, objetos, atributos y servicios. Estos enfoques son muy diferentes y es difcil mantenerlos en mente simultneamente.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Al igual que el diseo estructurado, el diseo orientado a objetos no es un mtodo nico, sino un nombre para designar una clase de mtodos. Los miembros (Members) de esta clase incluyen: Booch; Diseo Jerrquico Orientado a Objetos (HOOD); Coad-Yourdon; Tcnica del Modelado de Objetos (OMT) Shlaer-Mellor.

En seguida se describe cada uno de ellos. Booch Booch cre el diseo orientado a objetos, y contina jugando un papel principal en el desarrollo del mtodo. Booch modela un diseo orientado a objetos en trminos de un enfoque lgico, el cual define las clases, los objetos y sus relaciones, y un enfoque fsico, el cual define la arquitectura de mdulos y procesos. El enfoque lgico corresponde al modelo lgico que requieren los estndares de la Ingeniera del Software para construir en la fase de SR. El enfoque fsico corresponde al modelo fsico que estos mismos estndares requieren para construir en la fase AD. Booch proporciona dos tcnicas de diagramacin para documentar el enfoque fsico: Diagramas de mdulo, son utilizados para mostrar la asignacin de clases y objetos hacia los mdulos, como los programas, paquetes y

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS tareas en el diseo fsico (el trmino mdulo en el mtodo de Booch es utilizado para describir cualquier componente del diseo); Diagramas de procesos, muestran la asignacin de mdulos hacia los procesadores de hardware. Los libros de Booch en Diseo Orientado a Objetos contienen muchos anlisis sobre la prctica del buen diseo. Sin embargo, la notacin de Booch puede llegar a ser molesta y existen pocas herramientas disponibles. HOOD HOOD (Hierarchical Object-Oriented-Design) El diseo jerrquico orientado a objetos (HOOD) es miembro de una familia de mtodos orientados a objetos que tratan de integrar la orientacin a objetos con los mtodos de diseo estructurado. La jerarqua sigue naturalmente a la divisin del objeto raz del nivel ms alto. Al igual que en el diseo estructurado, las parejas de datos fluyen entre componentes del software. La principal diferencia entre HOOD y los mtodos estructurados es que los componentes del software obtienen su identidad de su correspondencia con cosas en el mundo real, en vez de las funciones que el sistema tiene que realizar. HOOD fue originalmente diseado para utilizarse con Ada, aunque Ada no soporta la herencia, y no es un lenguaje de programacin orientado a objetos. Este no es un problema serio para el diseo HOOD, porque el mtodo no utiliza clases para estructurar los sistemas. HOOD no tiene un mtodo de anlisis complementario. El modelo lgico normalmente es construido utilizando el anlisis estructurado. La transformacin del modelo lgico al modelo fsico es difcil, haciendo difcil la construccin de un diseo coherente.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

HOOD ha sido incluido en aplicaciones Ada. Cuenta ya con un nicho, pero es poco probable que llegue a tener una difusin y un apoyo tan amplio por parte de las herramientas como, por ejemplo, OMT Coad y Yourdon

Coad y Yourdon han publicado un enfoque integral para el anlisis y diseo orientado a objetos. Un diseo orientado a objetos es construido a partir de 4 componentes: Componente del mbito del problema; Componente de interaccin humana; Componente de administracin de tareas; Componente de administrador de datos.

Cada componente est compuesto de clases y objetos. El componente del mbito del problema est basado en el modelo (lgico) construido con el AOO en la fase de anlisis. Define el tema de estudio del sistema y sus responsabilidades. Si el sistema va a ser implementado en un lenguaje orientado a objetos, la correspondencia entre las clases y los objetos del mbito del problema sern uno a uno, y el componente del mbito del problema podr ser programado directamente. Sin embargo, el refinamiento substancial del modelo lgico es normalmente requerido, resultando en la incorporacin de ms atributos y servicios. Las consideraciones de reuso, y la no disponibilidad de un lenguaje de programacin totalmente orientado a objetos, pueden hacer que el diseo del componente del mbito del problema parta de un ideal representado por el modelo de AOO.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Los componentes poco amigables en la interaccin humana envan y reciben mensajes a y desde el usuario. Las clases y objetos en el componente de interaccin humana tiene nombres que son tomados desde el lenguaje de interfaz del usuario, por ejemplo: una ventana y un men. Muchos sistemas tendrn hilos mltiples de ejecucin, y el diseador debe construir un componente de manejo de tareas para organizar el procesamiento. El diseador necesita definir tareas como manejo de eventos (event-driven) o manejo del tiempo (clock-driven), as como sus prioridades de manera crtica. El componente de la administracin de datos proporciona la

infraestructura para guardar y recuperar objetos. Puede ser un simple sistema de archivos, un sistema de administracin de bases de datos relacional, o igualmente un sistema de administracin de bases de datos orientado a objetos. Los cuatro componentes juntos hacen el modelo fsico del sistema. En el nivel ms alto, todos los diseos de Coad y Yourdon Orientado-a-Objetos tienen la misma estructura. Las clases y los objetos son organizados en la generalizacin-

especializacin y en las estructuras completas (wholepart). Las estructuras de generalizacin especializacin son familiar de rboles, con hijos heredando los atributos de sus padres. Estructuras de partes completas (whole-part) son formadas cuando un objeto es descompuesto.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS La fuerza de los mtodos Coad y Yourdon son sus instrucciones, descripciones breves y su uso de texto general como fuentes de definiciones, as que las definiciones se ajustan al sentido comn y el jargon es minimizado. El significado de debilidad del mtodo es su notacin compleja, la cual es difcil de utilizarla sin herramientas de soporte. Algunos usuarios han utilizado en lugar del mtodo Coad-Yourdon la notacin de diagramacin de OMT. OMT La Tcnica de Modelacin de Objetos (Object Modelling Technique OMT) en el diseo tiene un alto nivel estratgico y decisin para resolver los problemas. Los problemas grandes se deben ver desde el punto de anlisis y diseo, este sistema se divide en subsistemas, a su vez este subsistema puede ser dividido en otros subsistemas de manera que puedan ser manejados y cada componente pueda se comprensible. En esta etapa se deben crear estrategias, formular una arquitectura para el sistema y las polticas que deben guiarla adems un detalle del diseo. Se deben tener en cuenta los siguientes aspectos: Distinguir una arquitectura Elegir una implementacin para un control externo Si se usa base de datos elegir el paradigma de administracin de base de datos Determinar oportunidades para el reuso Elegir estrategia para interaccin de datos Elegir una forma de identificar los objetos Detallar el diseo

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Durante el diseo del sistema se debe hacer un cuadro de estrategias y decisiones arquitecturales, tener una idea ms precisa de clases y mtodos individuales. Adicionalmente se puede mejorar el modelo de diseo para mejorar la implementacin. Se debe considerar los siguientes pasos: Uso de transformaciones para simplificar y optimizar el modelo de objetos desde el anlisis. Elaborar un modelo de objeto Elaborar un modelo funcional Evaluar la calidad del diseo del modelo Implementacin

El diseo es trasladado a un lenguaje de programacin actual y cdigo de base de datos. Este paso puede ser aplicado y considerado durante el anlisis y diseo Shlaer y Mellor Shlaer y Mellor describen un Lenguaje de Diseo Orientado a Objetos (OODLE), derivado de la notacin de Booch y Buhr. Existen cuatro tipos de diagramas: Diagrama de Clases que muestran relaciones de utilizacin (cliente/servidor) y de amigos entre clases. Grfica de la estructura de Clase (class) que muestran el aspecto externo de la clase de forma similar a Booch.; Diagrama de Dependencias muestran la estructura de los mtodos de la clase, el flujo de datos y de control; Diagrama de Herencia: representan la herencia.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS Existe un diagrama de clase para cada clase. El diagrama de clase define las operaciones y atributos de la clase. La grfica de la estructura de clase define la estructura del mdulo de la clase (class), el control y flujo de datos entre los mdulos de las clases. Existe una grfica de la estructura de la clase para cada clase. Los diagramas de Dependencia muestran las dependencias entre clases, las cuales pueden ser: Cliente - servidor; Amigables.

Una dependencia cliente-servidor existe cuando una clase (el cliente) llama en las operaciones a otras clases (el servidor). Una dependencia de amistad existe cuando una clase accede al dato interno de otra clase. Esto es una violacin de informacin ocultacin. Los diagramas de herencia muestran la herencia de relaciones entre clases.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

CONCLUSION
El siguiente trabajo se realizo con el fin de que el alumno conozca los temas bien desarrollados de la unidad 3 paradigmas de la ingeniera del software. Tambin como los conceptos de los temas ya que en algn momento los tendremos que poner en practica.

ITESCO FUNDAMENTOS DE DESARROLLO DE SISTEMAS

BIBLIOGRAFA
Sommerville, Ian (2005), Ingeniera de software, Ed. Addison Wesley 7 Edicion. Pressman Roger S. Ingeniera del software, Ed. Mc Graw Hill, 5 edicin Kendall Kenneth E. & Kendall Julie E., Anlisis y diseo de sistemas, Ed. Prentice Hall 6 edicin Tejerina Martn, Monografas Lucas Morea, Sinexi SA, Programacin Orientada a Objetos, [Consulta: Marzo de 2006] http://www.monografias.com/trabajos14/progorie/progorie.shtml