Fundamentos de Desarrollo de Sistemas Unidad III

FUNDAMENTOS DE DESARROLLO DE SISTEMAS

UNIDAD III
PARADIGMAS DE LA INGENIERA DE SOFTWARE
La ingeniera de software esta compuesta por una serie de pasos de abarcan los metodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingenieria de software. La eleccin de un paradigma para la ingeniera de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los metodos, herramientas a usar, los controles y entregas requeridos. Gama de paradigmas de la ingeniera de software

3.1 EL ENFOQUE ESTRUCTURADO

!uchos especialistas en sistemas de informacin reconocen la dificultad de comprender de manera completa sistemas grandes y comple"os. El m#todo de desarrollo del an$lisis estructurado tiene como finalidad superar esta dificultad por medio de %. la divisin del sistema en componentes y 2. la construccin de un modelo del sistema.
Instituto Tecnolgico de Ciudad.Jurez

39

Fundamentos de Desarrollo de Sistemas Unidad III

El m#todo incorpora elementos tanto de an$lisis como de dise&o. El an$lisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin. 'ermite que las personas observen los elementos lgicos (lo que har$ el sistema) separados de los componentes fsicos (computadora, terminales, sistemas de almacenamiento, etc.). *espu#s de esto se puede desarrollar un dise&o fsico eficiente para la situacin donde ser$ utilizado. El an$lisis estructurado es un m#todo para el an$lisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya e+istentes. ,ste an$lisis permite al analista conocer un sistema o proceso en una forma lgica y mane"able al mismo tiempo que proporciona la base para asegurar que no se omite ning-n detalle pertinente.

Componentes
Smbolos grficos: .conos y convenciones para identificar y describir los componentes de un sistema "unto con las relaciones entre estos componentes. Diccionario de datos: descripcin de todos los datos usados en el sistema. 'uede ser manual o automatizado. Descripciones de procesos y procedimientos: declaraciones formales que usan t#cnicas y lengua"es que permiten a los analistas describir actividades importantes que forman parte del sistema. Reglas: est$ndares para describir y documentar el sistema en forma correcta y completa.

Diseo Estructurado. El dise&o Estructurado es otro elemento del !#todo de *esarrollo por /n$lisis Estructurado que emplea la descripcin gr$fica, se enfoca en el desarrollo de especificaciones del software. El ob"etivo del *ise&o Estructurado es programas formados por mdulos independientes unos de otros desde el punto de vista funcional.

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad III

El *ise&o Estructurado es una t#cnica especfica para el dise&o de programas. La herramienta fundamental del *ise&o Estructurado es el diagrama estructurado que es de naturaleza gr$fica y evitan cualquier referencia relacionada con el hardware o detalles fsicos. 0u finalidad no es mostrar la lgica de los programas (que es la tarea de los diagramas de flu"o). Los *iagramas Estructurados describen la interaccin entre mdulos independientes "unto con los datos que un mdulo pasa a otro cuando interacciona con #l.

Anlisis de flujo de datos. Estudia el empleo de los datos para llevar a cabo procesos especficos de la empresa dentro del $mbito de una investigacin de sistemas usa los diagrama de flu"os de datos y los diccionarios de datos.

erramientas Las herramientas muestran todas las caractersticas esenciales del sistema y la forma en que se a"ustan entre si, como es muy difcil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, "unto con sus acciones.

!."." Diagrama de flujo de datos.

1n *iagrama de 2lu"o de *atos es una descripcin gr$fica de un procedimiento para la resolucin de un problema. 0on frecuentemente usados para describer algoritmos y programas de computador. Los diagramas de flu"o de datos est$n compuestos por figuras conectadas con flechas. 'ara e"ecutar un proceso comienza por el .3.4.5 y se siguen las flechas de figura a figura, e"ecut$ndose las acciones indicadas por cada figura6 el tipo de figura indica el tipo de paso que representa.

Instituto Tecnolgico de Ciudad.Jurez

4!

Fundamentos de Desarrollo de Sistemas Unidad III

*el 0oftware, *2* es un software dise&ado para construir y analizar algoritmos 1d. puede crear diagramas de flu"o de datos para la representacin de algoritmos de programacin estructurada a partir de las herramientas de edicin que para #ste propsito suministra el programa. *espu#s de haber ingresado el algoritmo representado por el diagrama, podr$ e"ecutarlo, analizarlo y depurarlo en un entorno interactivo dise&ado para #ste fin. La interfaz gr$fica de *2*, facilita en gran medida el traba"o con diagramas ya que simula la representacin est$ndar de diagramas de flu"o en ho"as de papel. El Diagrama de #lujo de Datos, ilustra una de las t#cnicas para representar 70oluciones8 a problemas del !undo 9eal en forma visual, es decir6 en forma grafica. Esta t$cnica mediante graficas de Diagrama de #lujo , ilustra como dise&ar los procedimientos o sentencias con coherencia lgica, que representan la solucin al problema planteado. / continuacin se muesta una representacin gr$fica seg-n algunos autores en cuanto a la simbologa para los diagramas de flu"o de datos.

#igura: smbolo seg%n algunos autores.

Instituto Tecnolgico de Ciudad.Jurez

42

Fundamentos de Desarrollo de Sistemas Unidad III

Procesamiento de Proceso Datos

&ateriales

Flujo

#lujo de Datos

Conectores
En la pgina #uera de la pgina

Entrada/Salida Almacenamiento de Datos o archivos Fuentes o destino de los datos

&ostrada en las lneas de flujo

#igura : 'aleta de smbolos para los diagramas de flujo de datos.

:ambi#n en concepto es el modelo del sistema. Es la herramienta m$s importante y la base sobre la cual se desarrollan otros componentes. El modelo original se detalla en diagramas de ba"o nivel que muestran caractersticas adicionales del sistema. 4ada proceso puede desglosarse en diagramas de flu"os de datos cada vez m$s detallados. 9epiti#ndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra ba"o investigacin. El diagrama fsico de datos da un panorama del sistema en uso, dependiente de la implantacin, mostrando cuales tareas se hacen y como son hechas. .ncluyen nombres de personas, nombres o n-meros de formato y documento, nombres de departamentos, archivos

Instituto Tecnolgico de Ciudad.Jurez

43

Fundamentos de Desarrollo de Sistemas Unidad III

maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos. El diagrama lgico de datos da un panorama del sistema, pero a diferencia del fsico es independiente de la implantacin, que se centra en el flu"o de datos entre los procesos, sin considerar los dispositivos especficos y la localizacin de los almacenes de datos o personas en el sistema. 0in indicarse las caractersticas fsicas.

Caractersticas

Sint$tica: La representacin que se haga de un sistema o un proceso deber$ quedar resumido en pocas ho"as, de preferencia en una sola. Los diagramas e+tensivos dificultan su comprensin y asimilacin, por tanto de"an de ser pr$cticos.

Simboli(ada: La aplicacin de la simbologa adecuada a los diagramas de sistemas y procedimientos evita a los analistas anotaciones e+cesivas, repetitivas y confusas en su interpretacin.

De forma )isible a un sistema o un proceso: Los diagramas nos permiten observar todos los pasos de un sistema o proceso sin necesidad de leer notas e+tensas. 1n diagrama es comparable, en cierta forma, con una fotografa a#rea que contiene los rasgos principales de una regin, y que a su vez permite observar estos rasgos o detalles principales.

'ermitir al analista asegurarse que ha desarrollado todos los aspectos del procedimiento. *ar las bases para escribir un informe claro y lgico. Es un medio para establecer un enlace con el personal que eventualmente operar$ el nuevo procedimiento.

Como se Construye

*ebe de indicar claramente dnde inicia y dnde termina el diagrama. 4ualquier camino del diagrama debe de llevarte siempre a la terminal de fin.
Instituto Tecnolgico de Ciudad.Jurez

44

Fundamentos de Desarrollo de Sistemas Unidad III

5rganizar los smbolos de tal forma que siga visualmente el flu"o de arriba hacia aba"o y de izquierda a derecha.

3o usar lengua"e de programacin dentro de los smbolos. 4entrar el diagrama en la p$gina. Las lneas deben ser verticales u horizontales, nunca diagonales.

E"emplo *2* de nivel alto de un sistema de procesamiento de pedidos

&ateriales

, 'rocesar el embar+ue
Documentos de Embar+ue Datos de Embar+ue

"

* 'rocesar los datos de embar+ue

Datos de la #actura

Cliente
'edido

'rocesar el pedido

Datos del 'edido

#actura

! 'rocesar factura

'ago

!."."." Diagrama de flujo de datos.

1n diagrama de flu"o es una representacin gr$fica de un algoritmo o de una parte del mismo. Los diagramas de flu"o ayudan en la comprensin de la operacin de las estructuras de control (Si, Mientras). La venta"a de utilizar un algoritmo es que se le puede construir independientemente de un lengua"e de programacin, pues al momento de llevarlo a cdigo se
Instituto Tecnolgico de Ciudad.Jurez

4"

Fundamentos de Desarrollo de Sistemas Unidad III

puede hacer en cualquier lengua"e. *ichos diagramas se construyen utilizando ciertos smbolos de uso especial como son rect$ngulos, diamantes, valos, y peque&os crculos, estos smbolos est$n conectados entre s por flechas, conocidas como lneas de flujo. / continuacin se detallan estos smbolos.

Nombre

Smbolo

Funcin
9epresenta el inicio y fin de un programa. :ambi#n puede representar una parada o interrupcin programada que sea necesaria realizar en un programa. 4ualquier tipo de introduccin de datos en la memoria desde los perif#ricos o registro de informacin procesada en un perif#rico. 4ualquier tipo de operacin que pueda originar cambio de valor, formato o posicin de la informacin almacenada en memoria, operaciones aritm#ticas, de transformaciones, etc. .ndica operaciones lgicas o de comparacin entre datos (normalmente dos) y en funcin del resultado de la misma determina (normalmente si y no) cual de los distintos caminos alternativos del programa se debe seguir 0irve para enlazar dos partes cualesquiera de un diagrama a trav#s de un conector en la salida y otro conector en la entrada. 0e refiere a la cone+in en la misma pagina del diagrama .ndica el sentido de la e"ecucin de las operaciones 0e utiliza en ocasiones en lugar del smbolo de salida. El dibu"o representa un pedazo de ho"a. Es usado para mostrar datos o resultados.

Terminal

Entrada / salida

Proceso

Decisin

Conector Misma Pgina

Indicador de direccin o lnea de flujo

Salida

Instituto Tecnolgico de Ciudad.Jurez

4#

Fundamentos de Desarrollo de Sistemas Unidad III

!.".* Diccionario de Datos.

1n diccionario de datos es un cat$logo, un depsito, de los elementos de un sistema. Estos elementos se centran alrededor de los datos y la forma en que est$n estructurados para satisfacer los requerimientos y las necesidades de la organizacin. En #l se encuentran la lista de todos los elementos que forman parte del flu"o de datos en todo el sistema. 4ontiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. .dentifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el an$lisis de flu"o de datos y au+ilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambi#n se emplea durante el dise&o. 9azones para su utilizacin !. 'ara mane"ar los detalles en sistemas muy grandes, ya que tienen enormes cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos. Los sistemas al sufrir cambios continuos, es muy difcil mane"ar todos los detalles. 'or eso se registra la informacin, ya sea sobre ho"a de papel o usando procesadores de te+to. Los analistas mas organizados usan el diccionario de datos automatizados dise&ados especficamente para el an$lisis y dise&o de software. ;. 'ara asignarle un slo 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 flu"o de datos en el sistema, de tal manera que todo pueda localizarse con rapidez. <. 'ara documentar las caractersticas del sistema, incluyendo partes o componentes as como los aspectos que los distinguen. :ambien es necesario saber ba"o que circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren. 'roduciendo una comprensin mas completa. 1na vez que las caractersticas est$n articuladas y registradas, todos los participantes en el proyecto tendr$n una fuente com-n de informacin con respecto al sistema.

Instituto Tecnolgico de Ciudad.Jurez

4$

Fundamentos de Desarrollo de Sistemas Unidad III

=. 'ara facilitar el an$lisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema. *etermina si son necesarias nuevas caractersticas o si est$n en orden los cambios de cualquier tipo. 0e 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 especifica. !rc"i#os $ %ases de datos detalles de las transacciones y registros maestros que son de inter#s para la organizacin. Ca&acidad del sistema >abilidad 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. /-n en los manuales, se revelan errores.

Contenido de un Registro del Diccionario El diccionario tiene dos tipos de descripciones para el flu"o de datos del sistema, son los elementos datos y estructura de datos. Elemento dato son los bloques b$sicos para todos los dem$s datos del sistema, por si mismos no le dan un significado suficiente al usuario. 0e agrupan para formar una estructura de datos. Descri&cin 4ada entrada en el diccionario consiste de un con"unto de detalles que describen los datos utilizados o producidos por el sistema. 4ada uno esta identificado con 'n nom%re para distinguir un dato de otro.
Instituto Tecnolgico de Ciudad.Jurez

4%

Fundamentos de Desarrollo de Sistemas Unidad III

Descri&cin indica lo que representa en el sistema. !lias porque un dato puede recibir varios nombres, dependiendo de quien uso este dato.

(ongitud porque es de importancia de saber la cantidad de espacio necesario para cada dato.

)alores de los datos porque en algunos procesos solo son permitidos valores muy especficos para los datos. 0i los valores de los datos est$n restringidos a un intervalo especifico, esto debe estar en la entrada del diccionario.

Estructura de datos es un grupo de datos que est$n relacionados con otros y que en con"unto describen un componente del sistema.

Descripci-n 0e construyen sobre cuatro relaciones de componentes. 0e pueden utilizar las siguientes combinaciones ya sea individualmente o en con"uncin con alguna otra. Relaci-n secuencial: define los componentes que siempre se incluyen en una estructura de datos.

*elacin de seleccin (uno u otro), define las alternativas para datos o estructuras de datos incluidos en una estructura de datos. *elacin de iteracin (repetitiva), define la repeticin de un componente. *elacin o&cional los datos pueden o no estar incluidos, o sea, una o ninguna iteracin.

.otaci-n
Instituto Tecnolgico de Ciudad.Jurez

49

Fundamentos de Desarrollo de Sistemas Unidad III

Los analistas usan smbolos especiales con la finalidad de no usar demasiada cantidad de te+to para la descripcin de las relaciones entre datos y mostrar con claridad las relaciones estructurales. En algunos casos se emplean t#rminos diferentes para describir la misma entidad (alias) estos se representan con un signo igual (A) que vincula los datos. 0e usa smbolos especiales con la finalidad de limitar la cantidad de te+to necesario empleado para describir las relaciones entre los datos y al mismo tiempo mostrar con claridad las relaciones estructurales. La simbologa empleada se describe a continuacin

Smbolo
/

Significado
Es equivalente aB o esta compuesto /lias de C 1no u otro (0eleccion de una de varias alternativas) .teraciones de 5pcional (&uede estar &resente o ausente' 4omentario Identi(icador )cam&o cla*e' &ara un almac+n se&ara o&ciones alternati*as en la construccin

Explicacin

Uso
*enota sinnimos

4oncatenacin, componentes que *enota una relacin de siempre est$n incluidos en una estructura secuencia *efine opciones entre los componentes de una estructura *enota una relacin de seleccin

12

34

*efine la repeticin de un componente de *enota una relacin de la estructura iteracin *efine componentes de la estructura que *enota una relacin puede o no estar presente una sola vez opcional.

56 77 8

Ejemplo de un Diccionario de datos para el almacenamiento de un arc9i)o log

Instituto Tecnolgico de Ciudad.Jurez

"

Fundamentos de Desarrollo de Sistemas Unidad III

Por ejem&lo+ &odemos definir nombre A ttulo de cortesa D nombre D (segundo nombre) D apellido paterno D apellido materno ttulo de cortesa A E0r. F 0rta. F 0ra. F *r. F 'rofesor G nombre A Hcaracter legalI apellido paterno A Hcaracter legalI apellido materno A Hcaracter legalI 3ombre A :itulo 4ortesiaD 3ombre'ilaD /pellido :itulo4ortesia A E J0rJ F J0raJ G 3ombre'ila A H 4aracter I /pellido A H 4aracter I 4aracter A E J/J@JKJ F JaJ@JzJ G

:teraciones 0e pueden indicar los lmites de las iteraciones 'alabra A HLetraI 'alabra A %HLetraI 'alabra A HLetraI%L 'alabra A %HLetraI%L 0in lmite (indeterminado) !nimo %, m$+imo indeterminado !nimo indeterminado, m$+imo %L !nimo %, m$+imo %L
Instituto Tecnolgico de Ciudad.Jurez

"!

Fundamentos de Desarrollo de Sistemas Unidad III

'alabra A %LHLetraI%L

E+actamente %L

!.".! Diseo de &-dulos.

La calidad del dise&o debe ser una meta para el dise&ador. El dise&o estructurado ofrece guas para apoyar al dise&ador a determinar mdulos, y sus intercone+iones, que me"or realizar$n los requerimientos especificados por el analista. Las dos reglas m$s importantes son las referentes al acoplamiento y la cohesin. Co9esi-n. Grado en el cu$l los componentes de un mdulo (tpicamente las instrucciones individuales que lo conforman) son necesarios y suficientes para llevar a cabo una sola funcin bien definida. En la pr$ctica, esto significa que el dise&ador debe asegurarse de no fragmentar los procesos esenciales en mdulos, y tambi#n debe asegurarse de no "untar procesos no relacionados en mdulos sin sentido. Los me"ores mdulos son aquellos que son funcionalmente cohesivos (es decir, mdulos en los cuales cada instruccin es necesaria para poder llevar a cabo una tarea bien definida). Los peores mdulos son los que son coincidentalmente cohesivos (es decir, donde sus instrucciones no tienen una relacin significativa entre uno y otro). Los grados de cohesin, de menor a mayor son a. 4ohesin 4oincidental. 3o e+iste una relacin significativa entre los elementos del mdulo. b. 4ohesin Lgica. La relacin entre los elementos del mdulo est$ basada en obtener venta"as en el procesamiento, por e"emplo, todos manipulan el mismo dato. 3ormalmente esto implica tener un cdigo truculento o compartido, que degrada los propsitos de un buen dise&o. c. 4ohesin :emporal. Los elementos del mdulo constituyen un con"unto que se e"ecuta secuencialmente en un punto fi"o en el tiempo. /unque tiende, a veces, a confundirse con la cohesin lgica, la diferencia est$ en que este tipo de mdulo s m$s simple y se e"ecuta sin la intervencin de otras aplicaciones. d. 4ohesin 4omunicacional. Los elementos del mdulo hacen referencia al mismo con"unto de datos. /qu se presenta un grado JaceptableJ de cohesin. e. 4ohesin 0ecuencial. .mplica que la salida de un elemento es la entrada para el pr+imo.

Instituto Tecnolgico de Ciudad.Jurez

"2

Fundamentos de Desarrollo de Sistemas Unidad III

f. 4ohesin 2uncional. /qu, todos los elementos del mdulo est$n orientados a la realizacin de una funcin -nica. Acoplamiento. Grado en el cu$l los mdulos se interconectan o se relacionan entre ellos. Entre m$s fuerte sea el acoplamiento entre mdulos en un sistema, m$s difcil es implantarlo y mantenerlo, pues entonces se necesitar$ un estudio cuidadoso para la modificacin de alg-n mdulo o mdulos. En la pr$ctica, esto significa que cada mdulo debe tener interfaces sencillas y limpias con otros, y que se debe compartir un n-mero mnimo de datos entre mdulos. :ambi#n significa que un mdulo dado no debe modificar la lgica interna o los datos de alg-n otro mdulo6 lo que se conoce como una cone+in patolgica. ;amao del &-dulo. *e ser posible, cada mdulo debe ser lo suficientemente peque&o como para caber en una sola p$gina (o para que se pueda desplegar en una sola pantalla). *esde luego, a veces no es posible determinar qu# tan grande va a ser un mdulo hasta haberlo escrito, pero las actividades iniciales de dise&o a menudo dar$n al dise&ador una buena pista de que el mdulo ser$ grande o comple"o. 0i es as, debe subdividirse en uno o m$s niveles de submdulos. Alcance del control. El n-mero de subordinados inmediatos que un mdulo administrador puede llamar se conoce como el alcance del control. 1n mdulo no debe poder llamar a m$s de una media docena de mdulos de nivel inferior. La razn es evitar la comple"idad si el mdulo tuviera, por e"emplo, que llamar a ;? mdulos de nivel inferior, entonces seguramente contendr$ tanta lgica comple"a que nadie lo entender$ (un sin fin de if@then anidados). La solucin es introducir un nivel intermedio de mdulos administradores, como hara un administrador de una organizacin humana.

Alcance del efecto<alcance del control. Esta regla sugiere que cualquier mdulo afectado por el resultado de alguna decisin debe ser subordinado (aunque no necesariamente un subordinado inmediato) del mdulo que toma la decisin. Es un tanto an$logo a la regla de administracin que dice que cualquier empleado afectado por los resultados de la decisin de alg-n administrador (es decir, dentro del alcance de efecto de la decisin), debe estar dentro del alcance de control del administrador (es decir
Instituto Tecnolgico de Ciudad.Jurez

"3

Fundamentos de Desarrollo de Sistemas Unidad III

traba"ando entre la "erarqua de personas que se reportan con el administrador). Miolar esta regla en un ambiente de dise&o estructurado usualmente lleva a un paso innecesario de banderas y condiciones (lo cual incrementa el acoplamiento entre mdulos), la toma redundante de decisiones o (en el peor de los casos) cone+iones patolgicas entre mdulos.

'arsimonia. 0e refiere a la economa de recursos que se emplean para la obtencin de un resultado. Esto es, slo se debe realizar lo que se pide. !ientras mayor la parsimonia, me"or el dise&o.

&anejo Aut-nomo de Errores. Los mdulos deben tener la capacidad de mane"ar sus propias condiciones de error, tanto en la deteccin cmo en la correccin de los mismos. *e no ser as, el mane"o de banderas (flags) de control y la transmisin de datos errneos a otros mdulos aumentar$ considerablemente el acoplamiento.

!."., Descomposici-n en 'rocesos.

'roceso 0e define como un con"unto de actividades o acciones interrelacionadas entre s que, a partir de una o varias entradas de informacin, materiales o de salidas de otros procesos, dan lugar a una o varias salidas tambi#n de materiales (productos) o informacin con un valor a&adido. 1n proceso est$ compuesto por actividades. 1na actividad est$ compuesta de tareas.

Instituto Tecnolgico de Ciudad.Jurez

"4

Fundamentos de Desarrollo de Sistemas Unidad III

$!%CES%
ACTIVIDAD TA!EA ## # ACTIVIDAD n TA!EA

###

TA!EA "

La descomposicin del proceso en actividades y tareas se realiza sobre el concepto de ciclo de me"ora '*4/ 7'lan N *o N 4hecO N /ct8 ('lanificacin, e"ecucin, medicin y me"ora).

INICIO

'>A.
Tareas, agenda, asignaciones

'roblemas y acciones correcti)as

AC;

PROCESO

D@
Ejecuci-n de planes y tareas

C EC?
E)aluaci-n y medici-n

FIN

Descomposici-n o E=plosi-n de un 'roceso: 4onsiste en desagregar un proceso padre en un nuevo *iagrama de 2lu"o de *atos en mayor detalle.

3ormas a seguir al descomponer un proceso Numeracin /l e+plosionar el proceso 7n8, se numerar$n los procesos hi"os como n.%, n.;, ... D,D -alanceado :odos los flu"os que entran o salen del proceso padre deber$n entrar y salir del con"unto de procesos hi"os.

Instituto Tecnolgico de Ciudad.Jurez

""

Fundamentos de Desarrollo de Sistemas Unidad III

Diagrama de Con)ex)o 0 b DFD del Ni&el '

DFD ' 1

explosin de proceso ' d1 2 3 DFD del Ni&el

DFD ( 2.1 2.2 2. 4

explosin de proceso ( 2. 3 d 2

DFD del Ni&el (

3. EL ENFOQUE ORIENTADO A O!"ETOS.

Estrategias Las estrategias 55 cubren tanto los requisitos como el an$lisis, dise&o y programacin. /n$lisis 5rientado a 5b"etos (55/) *ise&o 5rientado a 5b"etos (55*) 'rogramacin 5rientada a 5b"etos (55')

Este paradigma centra su foco en el concepto @bjeto. @bjeto es aquello que tiene estado (propiedades m$s valores), comportamiento (acciones y reacciones a mensa"es) e identidad (propiedad que lo distingue de los dem$s ob"etos). La

Instituto Tecnolgico de Ciudad.Jurez

"#

Fundamentos de Desarrollo de Sistemas Unidad III

estructura y comportamiento de ob"etos similares est$n definidos en su clase com-n6 los t#rminos instancia y ob"eto son intercambiables. 1na clase es un con"unto de ob"etos que comparten una estructura y comportamiento com-n. La diferencia entre un ob"eto y una clase es que un ob"eto es una entidad concreta que e+iste en tiempo y espacio, mientras que una clase representa una abstraccin, la JesenciaJ de un ob"eto, tal como son. *e aqu que un ob"eto no es una clase, sin embargo, una clase puede ser un ob"eto. Aeneficios del Enfo+ue @@

Los beneficios se&alados por Pooch en %QRS son 'otencia, el uso del modelo 55 ayuda a e+plotar el poder e+presivo de los lengua"es de programacin basados u orientados a ob"etos, como 0malltalO, 5b"ect 'ascal, 4DD, 4L50, /da, Tava, 4U. Reutili(aci-n, el uso del modelo 55 favorece la reutilizacin, no solo del software, sino de dise&os completos. &antenibilidad, produce sistemas que est$n construidos en formas intermedias estables y por ello son m$s resistentes al cambio en especificaciones y tecnologa. 'rincipios del modelo @@ #undamentales: /bstraccin, encapsulacin, modularidad y "erarqua. Pooch afirma que un modelo en el que no est# presente alguno de estos principios 35 es un modelo 55. Complementarios: :ipificacin, concurrencia y persistencia Abstracci-n. 0implificacin en la descripcin o especificacin de un sistema consistente en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de otros. Encapsulaci-n. 5cultacin de los detalles de un ob"eto que no contribuyen a sus caractersticas esenciales. &odularidad. 'ropiedad de un sistema que ha sido descompuesto en un con"unto de mdulos coherentes e independientes. Berar+ua o 9erencia. 5rden de las abstracciones organizado por niveles.

Instituto Tecnolgico de Ciudad.Jurez

"$

Fundamentos de Desarrollo de Sistemas Unidad III

;ipificaci-n. *efinicin precisa de un ob"eto de forma tal que ob"etos de diferentes tipos no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy restringida. Concurrencia. 'ropiedad que distingue un ob"eto que est$ activo de uno que no lo est$. 'ersistencia. 'ropiedad de un ob"eto por la cual su e+istencia trasciende al tiempo (es decir, el ob"eto continua e+istiendo despu#s de que su creador ha de"ado de e+istir) yBo al espacio (es decir, la localizacin del ob"eto se mueve del espacio de direccin en que fue creado).

!.*." Anlisis.
El Anlisis @rientado a @bjetos (..! &or sus siglas en ingl/s de .%ject .riented !nal$sis) Jes un mtodo de anlisis que examina los requerimientos desde la perspectiva de las clases y ob"etos encontrados en el vocabulario del dominio del problemaJ. La programacin estructurada nace para que los programas fueran m$s f$ciles de mane"ar ya que el problema era la comple"idad de los mismos cuando se trataban de resolver quedaban con fallas ocultas. / raz de ello se llevo la programacin estructurada a el an$lisis y dise&o. El enfoque de la metodologa estructurada son los procesos sus entradas y salidas, ofreciendo que los programas sean menos comple"os. / trav#s del tiempo se fue me"orando el hardware y el software, lo que dio origen a utilizar con mayor facilidad los gr$ficos y se observo que la t#cnica de programacin estructurada se poda aplicar con la visin de ob"etos. El concepto de ob"eto nace cuando se comenz a hablar de gr$ficos en los computadores, lo que dio una visin m$s clara de programa. 0e cree que las t#cnicas orientadas a ob"etos son me"ores que los enfoques m$s antiguos, para el mane"o del ritmo de cambio cada vez m$s grande en muchas de las organizaciones actuales. La tecnologa orientadas al ob"eto, al igual que sucedi con el enfoque estructurado, ha evolucionado de aba"o hacia arriba6 se empez con la difusin de los lengua"es de programacin

Instituto Tecnolgico de Ciudad.Jurez

"%

Fundamentos de Desarrollo de Sistemas Unidad III

orientados a ob"etos (L'55), para pasar a promover las primeras metodologas de an$lisis que siguen este paradigma. En el paradigma de la orientacin orientada del ob"eto, un sistema se concibe como un con"unto de ob"etos que se comunican entre si mediante mensa"es. En el aspecto conceptual un ob"eto es una entidad percibida en el sistema que se est$ desarrollando, mientras que el nivel de implementacin, un ob"eto corresponde con un encapsulamiento de un con"unto de operaciones y datos.

!.*.* Diseo.
El Diseo @rientado a @bjetos Jes un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico tal como los modelos est$ticos y din$micos del sistema ba"o dise&oJ. Diseo @rientado a @bjetos Es la apro+imacin m$s popular actualmente, sobre la que se han desarrollado numerosos m#todos partiendo de su concepcin inicial en la d#cada de los RLVs. / trav#s del dise&o orientado a ob"etos (55*), se desarrollan las especificaciones de sistemas como modelos de ob"etos (sistemas compuestos por con"untos de ob"etos que interact-an entre ellos) que, e+puesta de forma muy b$sica, identifica a los nombres como ob"etos, a los verbos como los comportamientos que pueden ofrecer y a los ad"etivos como sus m#todos. 55 no es una estrategia de dise&o. El paradigma de orientacin a ob"etos es m$s amplio y abarca un enfoque general para conceptualizar, dise&ar y programar los sistemas de software.

Instituto Tecnolgico de Ciudad.Jurez

"9