UNIDAD 4 MODELO DE DISEO Competencia a desarrollar. Aplicar modelos, tcnicas y herramientas para la etapa de diseo del software. Su temas!

4.". #strate$ias de diseo 4.%. Diseo de o &etos 4.'. Diseo de sistema 4.4. (e)isi*n del diseo 4.+. Dia$ramas de secuencias del Diseo. 4.,. -erramientas CAS# para el diseo

4.1 Estrategia de diseo. .a meta del diseo es crear un modelo de software /ue implemente todos los re/uisitos del cliente de manera correcta y compla0ca a a/ullos /ue lo usen. #l proceso de diseo a)an0a de una )isi*n $eneral del software a una )isi*n m1s estrecha /ue define el detalle re/uerido para implementar un sistema. #l proceso de diseo comien0a con un enfo/ue en la ar/uitectura. Abstraccin 2ara un pro lema determinado se pueden considerar muchos $rados de a stracci*n. #n un alto $rado de a stracci*n una soluci*n se esta lece en trminos $enerales con el len$ua&e de entorno del pro lema. #n los $rados de menor a stracci*n se proporciona una soluci*n m1s detallada de la soluci*n. Una a stracci*n procedimental se refiere a una secuencia de instrucciones /ue tiene una funci*n espec3fica y limitada. Una a stracci*n de datos es una colecci*n nom rada de datos /ue descri e un o &eto de datos. Arquitectura .a ar/uitectura del software alude a la estructura $eneral del software y las formas en las /ue la estructura proporciona una inte$ridad conceptual para un sistema. .a ar/uitectura es la estructura u or$ani0aci*n de los componentes del pro$rama 4m*dulos5, la manera en /ue estos componentes interact6an, y la estructura de datos /ue utili0an los componentes. Patrones Un patr*n de diseo descri e una estructura de diseo /ue resuel)e un pro lema recurrente de diseo particular dentro de un conte7to espec3fico y en medio de fuer0as /ue pueden tener un impacto en la manera en /ue se aplica y utili0a el patr*n. Modularidad .os patrones de ar/uitectura y diseo de software materiali0an la modularidad8 es decir, el software se di)ide en componentes con nom res independientes y /ue es posi le a ordar en forma indi)idual. #stos componentes llamados m*dulos se inte$ran para satisfacer los re/uisitos del pro lema. .a modularidad se asa en la estrate$ia di)ide y

)encer1s 4es m1s f1cil resol)er un pro lema comple&o cuando ste se di)ide en pie0as m1s mane&a les5. Ocultacin de informacin #l principio de ocultaci*n de informaci*n su$iere /ue los m*dulos se caracteri0an por las decisiones de diseo /ue cada uno oculta a los otros. .os m*dulos de en especificarse y disearse de manera /ue la informaci*n 4procedimientos y datos5 /ue est1 dentro del m*dulo sea inaccesi le para otros m*dulos /ue no necesiten esta informaci*n. Independencia funcional #s la suma de directa de la modularidad y de los conceptos de a stracci*n y ocultaci*n de informaci*n. .a independencia funcional se consi$ue al desarrollar m*dulos con una funci*n determinante y una a)ersi*n a la interacci*n e7cesi)a con otros m*dulos. .os m*dulos independientes son m1s f1ciles de mantener, pro ar, modificar y se reduce la propa$aci*n de errores. Refinamiento #l refinamiento es una estrate$ia de diseo descendente. #l desarrollo de un pro$rama se reali0a al refinar de manera sucesi)a los ni)eles de detalle procedimentales. #l refinamiento hace /ue el diseador tra a&e so re el enunciado ori$inal y /ue proporcione m1s y m1s detalles conforme se reali0a cada refinamiento sucesi)o. .a a stracci*n y el refinamiento son conceptos complementarios. 4.2 Diseo de objetos Un sistema orientado a o &etos est1 compuesto de o &etos /ue interact6an, los cuales mantienen ellos mismos su estado local y pro)een operaciones so re su estado. .a representaci*n del estado es pri)ada y no se puede acceder a ella directamente desde fuera del o &eto. #l proceso de diseo de o &etos comprende el diseo de clases de o &etos y las relaciones entre estas clases. #l diseo orientado a o &etos comprende el desarrollo de un modelo orientado a o &etos de un sistema de software para implementar los re/uerimientos identificados. .os o &etos en un diseo orientado a o &etos est1n relacionados con el pro lema a resol)er. Un proceso $eneral para el diseo orientado a o &etos puede contener las si$uientes etapas! Comprender y definir el conte7to y los modos de utili0aci*n del sistema Disear la ar/uitectura del sistema. Identificar los o &etos principales del sistema. Desarrollar los modelos de diseo. #specificar las interfaces de los o &etos.

4.3 Diseo de sistema Lenguajes de programaci n #s importante sealar /ue un diseo orientado a o &etos no necesariamente se tiene /ue implementar mediante un len$ua&e orientado a o &etos. Sin em ar$o, es m1s natural hacerlo de esta manera. #sto es de ido a /ue los len$ua&es orientados a o &etos tienen

un apoyo directo a los conceptos del an1lisis orientado a o &etos 4encapsulamiento, $enerali0aci*n, polimorfismo5. Sin em ar$o, se puede traducir cual/uier concepto o mecanismo orientado a o &etos a otros e7istentes en los len$ua&es no orientados a o &etos. #l pro lema con este tipo de len$ua&es es su con)eniencia, mantenimiento y protecci*n contra errores. Un len$ua&e orientado a o &etos hace /ue la escritura, mantenimiento y e7tensi*n de los pro$ramas sea m1s f1cil y se$ura. Ca e mencionar /ue no todos los len$ua&es de pro$ramaci*n orientados a o &etos implementan de la misma forma los conceptos de la metodolo$3a orientada a o &etos. Aspectos como mane&o de encapsulamiento, referencias, herencia m6ltiple )ar3an de manera importante entre los len$ua&es de pro$ramaci*n. Inter!aces gr"!icas .as interfaces $r1ficas tienen como o &eti)o principal administrar la interacci*n entre el usuario mediante elementos $r1ficos, como son otones, men6s y te7tos. .as aplicaciones interacti)as donde el control del rat*n y teclado desempean un papel importante se conocen como sistemas controlados o diri$idos por e)entos. #stos e)entos comprenden! mo)er el rat*n, oprimir uno de sus otones, oprimir una tecla, etc. #ases de datos .as ases de datos son fundamentales en los sistemas de informaci*n. Una decisi*n estrat$ica importante en tal conte7to es si de e utili0ar ases de datos relacionales u orientadas a o &etos. #n $eneral se consideran tres modelos de ases de datos principales! 9odelo relacional! se define una colecci*n de ta las donde cada una tiene un n6mero espec3fico de columnas y un n6mero ar itrario de filas. Cada o &eto se representa como una fila en una ta la y donde cada columna corresponde a un atri uto distinto en el o &eto. 9odelo relacional e7tendido! el modelo relacional se e7tiende mediante procedimientos, o &etos, )ersiones y otras nue)as capacidades. No hay un solo modelo relacional e7tendido, m1s ien hay una )ariedad de ellos, aun/ue todos comparten las ta las y consultas 1sicas del modelo relacional. 9odelo orientado a o &etos! se define un modelo orientado a o &etos donde )ar3a el tipo de encapsulamiento de datos y los procedimientos en el o &eto. #l trmino orientado a o &etos )ar3a se$6n cada autor .as ases de datos son dep*sitos de datos $uardados en uno o m1s archi)os.

$rc%i&os Aun/ue es m1s efecti)o tra a&ar con ases de datos, es posi le utili0ar archi)os, so re todo cuando la especificaci*n del sistema as3 lo re/uiera. #n el caso de usar una ase de datos, re$ularmente una clase se comunica con el D:9S para hacer solicitudes a cual/uier ta la.

4.4 'e&isi n de( diseo #s una herramienta /ue fue desarrollada so re la ase de la filosof3a de /ue los pro lemas de diseo se producen cuando se reali0an cam ios en los diseos de in$enier3a e7istentes /ue ya han sido pro ados con 7ito. #n in$enier3a de software, una re)isi*n estructurada es una forma de re)isi*n de software por cole$as en la cual un diseador o pro$ramador lidera a los miem ros de un e/uipo de desarrollo y otra de las partes in)olucradas a tra)s de un producto de software, y los participantes hacen pre$untas y comentarios acerca de posi les errores, )iolaci*n de est1ndares de desarrollo, y otros pro lemas. #l ;producto de software; normalmente se refiera a un tipo de documento tcnico. <al como es indicado por la definici*n de la I###, esto puede ser un documento de diseo de software o c*di$o fuente de un pro$rama, pero tam in casos de uso, definiciones del proceso de ne$ocios, especificaciones de casos de prue a y una )ariedad de otra documentaci*n tcnica tam in puede ser re)isada. Una re)isi*n estructurada difiere de una re)isi*n de software tcnica en la forma a ierta de su estructura y su o &eti)o de familiari0aci*n.

4.) Diagramas de secuencias de( diseo #l dia$rama de secuencia es un tipo de dia$rama usado para modelar interacci*n entre o &etos en un sistema. Utilidad Un dia$rama de secuencia muestra la interacci*n de un con&unto de o &etos en una aplicaci*n a tra)s del tiempo y se modela para cada caso de uso. 9ientras /ue permite el modelado de una )ista business del escenario, el dia$rama de secuencia contiene detalles de implementaci*n del escenario, incluyendo los o &etos y clases /ue se usan para implementar el escenario y mensa&es intercam iados entre los o &etos. <3picamente se e7amina la descripci*n para determinar /u o &etos son necesarios para la implementaci*n del escenario. Si se dispone de la descripci*n de cada caso de uso como una secuencia de )arios pasos, entonces se puede ;caminar so re; esos pasos para descu rir /u o &etos son necesarios para /ue se puedan se$uir los pasos. Un dia$rama de secuencia muestra los o &etos /ue inter)ienen en el escenario con l3neas discontinuas )erticales, y los mensa&es pasados entre los o &etos como flechas hori0ontales. Tipos de mensajes #7isten dos tipos de mensa&es! sincr*nicos y asincr*nicos. .os mensa&es sincr*nicos se corresponden con llamadas a mtodos del o &eto /ue reci e el mensa&e. #l o &eto /ue en)3a el mensa&e /ueda lo/ueado hasta /ue termina la llamada. #ste tipo de mensa&es se representan con flechas con la ca e0a llena. .os mensa&es asincr*nicos terminan inmediatamente, y crean un nue)o hilo de e&ecuci*n dentro de la secuencia. Se representan con flechas con la ca e0a a ierta.

<am in se representa la respuesta a un mensa&e con una flecha discontinua. 2ueden ser usados en dos formas

De instancia! descri e un escenario espec3fico 4un escenario es una instancia de la e&ecuci*n de un caso de uso5. =enrico! descri e la interacci*n para un caso de uso8 Utili0a ramificaciones.

Estructura .os mensa&es se di u&an cronol*$icamente desde la parte superior del dia$rama a la parte inferior8 la distri uci*n hori0ontal de los o &etos es ar itraria. Durante el an1lisis inicial, el modelador t3picamente coloca el nom re > usiness> de un mensa&e en la l3nea del mensa&e. 91s tarde, durante el diseo, el nom re > usiness> es reempla0ado con el nom re del mtodo /ue est1 siendo llamado por un o &eto en el otro. #l mtodo llamado, o in)ocado, pertenece a la definici*n de la clase instan ciada por el o &eto en la recepci*n final del mensa&e. 4.* +erramientas ,$SE para e( diseo. .a tecnolo$3a CAS# supone la automati0aci*n del desarrollo del software, contri uyendo a me&orar la calidad y la producti)idad en el desarrollo de sistemas de informaci*n. 2ara me&orar la calidad y la producti)idad de los sistemas de informaci*n a la hora de construir software se plantean los si$uientes o &eti)os! 2ermitir la aplicaci*n pr1ctica de metodolo$3as estructuradas, las cuales al ser reali0adas con una herramienta conse$uimos a$ili0ar el tra a&o. ?acilitar la reali0aci*n de prototipos y el desarrollo con&unto de aplicaciones. Simplificar el mantenimiento de los pro$ramas. 9e&orar y estandari0ar la documentaci*n. Aumentar la pota ilidad de las aplicaciones. ?acilitar la re utili0aci*n de componentes software. 2ermitir un desarrollo y un refinamiento )isual de las aplicaciones, mediante la utili0aci*n de $r1ficos.