Introduccin

Pasos para el DOF

Diseo Arquitectnico
Diseo Detallado

Introduccin
Definicin y Caractersticas

Ventajas
Mtodos Componentes

Comunicacin y Herencia
Proceso

Este diseo es utilizado despus de un anlisis estructurado, cuyo producto es el DFD

y las descripciones del proceso.

Como mtodo de diseo, es un combinacin entre dos tcnicas diferentes interrelacionadas: - ASS (Anlisis de sistemas estructurados). Orientado a la construccin de modelo del problema mediante DFD. - AS (Diseo de estructurado). Orientado a la bsqueda de soluciones mediante el uso de estructuras chart (diagrama de estructura de cuadros).

Utiliza la estrategia de descomposicin Top-down. Se busca transformar un DFD en una estructura chart. Y para ello se han propuesto las siguientes estrategias:

DISEO ORIENTADO A FUNCIONES

Obtener una arquitectura inicial (alta abstraccin) a partir del DFD nivel 0.

Diseo Arquitectnico

Dividir al DFD en subtareas funcionales. Generar niveles (mdulos ms detallados a partir del DFD inicial. Refinar el DFD hasta un nivel adecuado. Diseo de la Interfaz de Usuario Elaborar un Diccionario de Datos del sistema

Diseo de la Interfaz de Usuario

Anlisis y Diseo de la interfaz. Prototipo y EValuacin de la interfaz. Organizar los procesos de los DFD en transacciones relacionadas al sistema.

Diseo Detallado

Transformar los DFD obtenidos en Estructuras Chart. Organizar las Estructuras en jerarquas a part r de una funcin central. Organizar las llamadas de la funcin central a Ios subsistemas. Combinar las Estructuras Chart y refinarlas. Definir el Pseudocdigo de acuerdo al diagrama de Estructura Chart.

 Existe una variedad de estilos arquitectnicos que permiten definir al sistema. Para sistemas
orientados a funciones es recomendable utilizar estilos arquitectnicos de Llamado y Retorno,

donde se tiene un programa principal desde el cual se realizan llamados a subprogramas, los cuales
retornan datos.

Para usar el estilo arquitectnico de Llamado y Retorno con un programa principal y subrutinas, se
deben tener en cuenta los siguientes aspectos:

Componentes (programa principal y los subprogramas). Conectores: determinar las invocaciones a los subprogramas (llamados). Control de ejecucin: determinar las jerarquas de invocacin de los subprogramas (algoritmos). Comunicacin de datos: determinar los parmetros que ayudan al intercambio de datos. Coherencia de Diseo: se debe utilizar el mtodo de Anlisis y Diseo estructurado (SSAISD), incluyendo
estrategias de descomposicin Top-Down.

 SELECCIN DE PUNTOS DE VISTA:

En el caso del diseo orientado a funciones se van a seleccionar los

puntos de vista funcionales y construccionales.

Puntos de vista funcionales: representados por el diagrama de flujo de

datos y pseudocdigo.

Puntos de vista construccionales: representados mediante estructuras

chart.

 Para realizar el diseo arquitectnico de un sistema orientado a funciones se

debe partir del diagrama de flujo de datos nivel 0 (diagrama de contexto), hasta obtener una arquitectura inicial con un alto nivel de abstraccin, para luego ir refinndola sucesivamente hasta alcanzar un diseo detallado del sistema representado por una estructura chart y el uso de pseudocdigo.

 Se debe generar niveles ms detallados a partir del diagrama de contexto

inicial, para esto se puede utilizar la estrategia Top-Down, en la cual al

DFD de nivel cero se lo divide en subtareas funcionales, hasta obtener el

DFD ms simples que representen funciones especficas del sistema.

Grafico 1 Grafico 2

Diseo Detallado

Una vez que el diagrama de flujo de datos est completo y tiene un nivel adecuado de
detalle, se debe realizar un proceso de transformacin hacia estructuras chart.

Para ello hay que identificar las transacciones que estn involucradas en el problema e
identificar los componentes del DFD que corresponden a cada transaccin, para luego agruparlos.

Diseo Detallado

Diseo Detallado

Finalmente, se deben combinar las estructuras chart creadas, y refinarlas, hasta obtener un diagrama como el siguiente:

Diseo Detallado

PSEUDOCODIGO

Las estructuras chart permiten representar al sistema desde un punto de vista

construccional, de bajo nivel, sin embargo antes de la implementacin es recomendado desarrollar el pseudocdigo de los mdulos del sistema.

Cabecera:

Programa Modulo Tipos de datos Constantes variables

Cuerpo:

Inicio

Instrucciones
Fin

El DOO es mucho ms complejo que el diseo estructurado clsico, ya que lo que se busca es crear un diseo genrico-abierto y no cerradoconcreto.

A diferencia con otros mtodos de diseo, el DOO produce un diseo que interconecta objetos de datos y operaciones de procesamiento para esos objetos, de forma que se modulariza la informacin y el procesamiento, en lugar de aislar el procesamiento.

El Diseo Orientado a Objetos se define como un diseo de sistemas que utiliza objetos auto-contenidos y clases de objetos.

Caractersticas Principales:
- Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas.

- Los objetos son independientes y encapsulan el estado y la representacin de informacin.

- La funcionalidad del sistema se expresa en trminos de servicios de los objetos. - Las reas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parmetros.

- Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en

paralelo.

Fcil de mantener, los objetos representan entidades auto

contenidas Los objetos son componentes reutilizables

Para algunos sistemas, puede haber un mapeo obvio entre las

entidades del mundo real y los objetos del sistema

Algunos mtodos que fueron originalmente basados en funciones (mtodo de Yourdon) han sido adaptadas al diseo orientado a objetos. Otros mtodos como el mtodo de Booch han sido especficamente desarrolladas especficamente para el Diseo Orientado Objetos El Diseo Orientado a Objetos es un mtodo de diseo desarrollado para

soportar la programacin en Ada.

JSD (Jackson system development) tiene una cierta orientacin a objetos pero no contiene informacin sobre estados entidad. Se ha definido una unificacin de las notaciones utilizadas en estos mtodos------UML

Objeto: Componente del mundo real, es una entidad. En un Sistema de Informacin es un producto o consumidor de informacin (un encapsulamiento

de informacin).

Dicha entidad tiene un estado y un conjunto definido de operaciones que operan sobre ese estado. El estado se representa mediante un conjunto de atributos del objeto. Las operaciones asociadas con el objeto proveen servicios a otros objetos (clientes) que requieren estos servicios cuando necesitan realizar alguna actividad de cmputo.

Los objetos se crean de acuerdo a una definicin de clase objeto.

La definicin de la clase objeto sirve como template (plantilla) para los objetos. Esta incluye las declaraciones de todos los atributos y servicios asociados con un objeto de dicha clase.

Objeto: OBJETO Datos: filamento, bombilla, rosca. Operaciones: encender foco

LA CLASE TRANSPORTES

Los objetos se comunican a travs de la solicitud de servicios (llamando a mtodos) de otros objetos y, si es necesario, intercambiando la informacin

requerida para que ese servicio se suministre. Las copias de la informacin

necesaria para ejecutar el servicio y los resultados de la ejecucin del servicio se pasan como parmetros.

En

los sistemas basados en servicios las comunicaciones de los objetos se

implementan directamente como mensajes de texto que los objetos intercambian. El objeto receptor analiza el mensaje, identifica el servicio y los datos asociados, y lleva a cabo el servicio solicitado. Sin embargo, cuando los

objetos coexisten en un mismo programa, las llamadas a los mtodos se

implementan como llamadas a procedimientos o funciones en un lenguaje.

La comunicacin entre los objetos puede ser:

SINCRONA El objeto invocador espera a que la peticin del servicio se complete. ASINCRONA El objeto invocador contina en operacin mientras que el servicio solicitado se ejecuta. (procesos concurrentes).

Los objetos son miembros de clases que define tipos de atributos y operaciones Las clases pueden organizarse en jerarquas de clases donde una clase se deriva de una clase existente (super-clase). Una sub-clase hereda los atributos y operaciones de su super-clases y puede aadir nuevos mtodos o atributos propios.

Las clases se pueden organizar mediante una generalizacin o jerarqua de herencia que muestra las relaciones de las clases generales y ms especficas. La clase ms especfica concuerda completamente con la clase general, pero incluye informacin adicional. En la notacin UML, la generalizacin se indica mediante una flecha que apunta a la clase padre. En los lenguajes de programacin orientados a objetos, por lo regular la generalizacin se implementa utilizando un mecanismo de herencia. La clase hija hereda los atributos y operaciones de la clase padre.

Como se indic al principio, existen varios mtodos DOO. Se puede definir las siguientes etapas como comunes en los procesos de DOO.

Comprender y definir el contexto y los modos de utilizacin del sistemas. Disear la arquitectura del sistema. Identificar los objetos principales en el sistema. Desarrollar los modelos de diseo. Especificar las interfaces de los objetos.

 La primera etapa en el proceso de diseo de sistema es comprender las

relaciones entre el sistema que se est diseando y el entorno externo.

El contexto del sistema y el modelo de utilizacin del sistema representan dos

modelos complementarios entre un sistema y su entorno:

El contexto del sistema es un modelo esttico que describe a los otros

sistemas de su entorno.

El modelo de utilizacin del sistema es un modelo dinmico que describe

cmo el sistema interacta con su entorno.

 Una vez que se han definido las interacciones entre el sistema de software que se est
diseando y el entorno del sistema, se puede utilizar esta informacin como base para disear la arquitectura del sistema. Para ello, es necesario tener conocimiento general de los principios de diseo arquitectnico.

En general, se debe tratar de descomponer un sistema de tal forma que las

arquitecturas sean lo ms sencillas posible. Una regla que siempre funciona es que no debe haber ms de siete entidades fundamentales en un modelo arquitectnico.

 En esta etapa del proceso de diseo ya se tuvo que haber formulado algunas
ideas de los objetos esenciales del sistema que se est diseando. En general, en

un principio, los objetos tienden a emerger durante el proceso de diseo. Sin

embargo, por lo general, hay que buscar y documentar otros objetos que pudieran ser relevantes.

Aunque esta seccin se ha denominado identificacin de objetos, en la prctica

este proceso se refiere a la identificacin de clases. El diseo se describe en funcin de estas clases. De forma inevitable, se tienen que refinar las clases identificadas de forma inicial y volver a esta etapa del proceso conforme se vaya

obteniendo una comprensin ms profunda del diseo.

 Existen dos tipos de modelos para describir un DOO: .Modelos estticos, que describen la estructura esttica del sistema en trminos de
las clases del sistema y sus relaciones.

.Modelos dinmicos, que describen la estructura dinmica del sistema y que muestran
las interacciones entre los objetos del sistema (no entre las clases). Las interacciones que se documentan incluyen la secuencia de servicios solicitados por los objetos y la

forma en que el estado del sistema se relaciona con estas interacciones de objetos.

UML provee 12 modelos estticos y dinmicos que pueden ser utilizados en el

documento de diseo. No se cuenta con suficiente espacio para abordar a todos ellos , etc.

 Una parte importante de cualquier proceso de diseo es la especificacin de las

interfaces entre los diferentes componentes del diseo. Es necesario identificar las interfaces para que los objetos y otros componentes se puedan disear en paralelo. Una vez que la interfaz se ha especificado, los desarrolladores de otros objetos pueden suponer que la interfaz ser implementada.