Unidad 4 Modelo de Diseño

[Escriba aqu]

GLOBALTEC

Modelo de Diseo

UNIDAD 4

Integrantes del Equipo:

Cinthia Guadalupe Ramrez Montes

Lezly Susette Reyes Norman

Franklin Iztcoatl Monreal Cristerna

Bernardo Dvila Jimnez

Alfredo Pablo Hernndez

GlobalTec

Fundamentos de Ingeniera del Software UNIDAD 4

Ingeniera en Sistemas Computacionales Pgina 3 de 22

Contenido

4.1 Estrategias de Diseo....................................................................................................................... 4

4.2 Diseo de Objetos ............................................................................................................................. 7

4.4 Revisin del Diseo ....................................................................................................................... 12

4.5 Diagramas de Secuencias del Diseo ........................................................................................ 15

Referencias .............................................................................................................................................. 22

GlobalTec



4.1 Estrategias de Diseo

El diseo de software es un proceso de definicin de la arquitectura, componentes,

interfaces y otras caractersticas de un sistema o componente y la planificacin de una

solucin de software. Despus de que el propsito y las especificaciones de software

estn determinados, los desarrolladores de software disean o utilizan los diseadores

para desarrollar un plan para una solucin. Un diseo de software puede ser

independiente de la plataforma o especfico de plataforma, en funcin de la

disponibilidad de la tecnologa llamada por el diseo.

Las estrategias generales de diseo de software ms conocidas son:

Divide y vencers Implica resolver un problema difcil, dividindolo en partes ms simples tantas veces

como sea necesario, hasta que la resolucin de las partes se torna obvia. La

solucin del problema principal se construye con las soluciones encontradas.

Refinamiento en pasos sucesivos Se desarrolla una jerarqua descomponiendo una funcin de forma sucesiva hasta

que se llega a las sentencias del lenguaje de programacin. Comenzamos con una

declaracin de la funcin (o una descripcin de la informacin) definida a un nivel

superior de abstraccin. Es decir, la declaracin describe la funcin o la informacin

conceptualmente, pero no proporciona informacin sobre el funcionamiento interno

de la funcin o sobre la estructura interna de la informacin, sino que se va a

realizando sucesivamente, dando cada vez ms detalles.

Top-down vs bottom-up Se formula un resumen del sistema, sin especificar detalles. Cada parte del sistema

se refina diseando con mayor detalle. Cada parte nueva es entonces redefinida,

cada vez con mayor detalle, hasta que la especificacin completa es lo

suficientemente detallada para validar el modelo. El modelo "Top-down" se disea

con frecuencia con la ayuda de "cajas negras" que hacen ms fcil cumplir

requerimientos aunque estas cajas negras no expliquen en detalle los componentes

individuales. En contraste, en el diseo Bottom-up las partes individuales se disean

con detalle y luego se enlazan para formar componentes ms grandes, que a su vez

se enlazan hasta que se forma el sistema completo. Las estrategias basadas en el

flujo de informacin "bottom-up" se hacen potencialmente necesarias y suficientes

porque se basan en el conocimiento de todas las variables que pueden afectar los

elementos del sistema.

(Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista

de las entradas que recibe y las salidas o respuestas que produce, sin tener en

cuenta su funcionamiento interno.)

GlobalTec



Abstraccin de datos y ocultamiento de informacin La abstraccin de datos es un conjunto de datos que describen un objeto, como

puede ser el DNI de una persona, que est compuesta por conjunto de partes de

informacin, pero que nos podemos referir a todos los datos mencionando el

nombre de la abstraccin de datos.

El principio de ocultamiento de la informacin sugiere que los mdulos deben

especificarse de forma que la informacin (procedimientos y datos) contenida dentro

de un mdulo sea inaccesible a otros mdulos que no necesiten tal informacin.

Por tanto se trata de definir una serie de mdulos independientes que se

comuniquen slo a travs de la informacin necesaria para realizar la funcin de

software. El uso de ocultamiento de informacin en el diseo facilitar las

modificaciones, prueba y mantenimiento del software, ya que como la mayora de

los datos y de los procedimientos estn ocultos a otras partes del software, ser

menos probable que los errores que se introduzcan durante la modificacin se

propaguen a otros mdulos del software.

Uso de heursticas La resolucin de problemas es especficamente distinta del aprendizaje de hechos,

la creacin de estructuras conceptuales y la adquisicin de destrezas, algoritmos y

valores. Sin embargo es una importante tcnica metodolgica para la formacin de

conceptos y para establecer relaciones entre ellos. Son reglas muy generales que

permiten transformar el problema en una situacin ms sencilla, nos ayudan a

comprender el problema y favorecer el xito en encontrar la solucin.

Uso de patrones Contribuyen a reutilizar diseo grfico, identificando aspectos claves de la estructura

de un diseo que puede ser aplicado en una gran cantidad de situaciones. La

importancia de la reutilizacin del diseo no es despreciable, ya que sta nos provee

de numerosas ventajas: reduce los esfuerzos de desarrollo y mantenimiento, mejora

la seguridad informtica, eficiencia y consistencia de nuestros diseos, y nos

proporciona un considerable ahorro en la inversin. Mejoran (aumentan, elevan) la

flexibilidad, modularidad y extensibilidad, factores internos e ntimamente

relacionados con la calidad percibida por el usuario.

GlobalTec



Aproximacin iterativa e incremental En la aproximacin iterativa los requerimientos y soluciones evolucionan mediante la

colaboracin de grupos auto organizado y multidisciplinario. La iteracin debe durar

de una a cuatro semanas. Cada iteracin del ciclo de vida incluye: planificacin,

anlisis de requerimientos, diseo, codificacin, revisin y documentacin. Al final

de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto. En cuanto

a la aproximacin incremental se comienza el desarrollo del sistema para satisfacer

un subconjunto de requisitos especificados. Las ltimas versiones prevn los

requisitos que faltan. De esta forma se logra una rpida disponibilidad del sistema,

que aunque incompleto, es utilizable y satisface algunas de las necesidades bsicas

de informacin. Cada versin parte de una previa sin cambios pero con nuevas

funciones.

GlobalTec



4.2 Diseo de Objetos

Este mtodo fue definido por G. Booch a principios de los aos 80 y ha conocido varias

versiones sucesivas. Desde el punto de vista de las aplicaciones industriales, es

probablemente uno de los mtodos precursores de la aproximacin orientada a objetos.

Fue definido para el Departamento de Defensa estadounidense (DOD) para racionalizar

el desarrollo de las aplicaciones en ADA. Posteriormente ha sido ampliado para el

lenguaje C++. Por lo tanto, se trata de un mtodo de desarrollo (especificacin tcnica e

implementacin) y no de diseo (anlisis de las necesidades y especificacin formal).

Con posterioridad ha inspirado numerosos mtodos, algunos de los cuales son

extensiones directas, como HOOD.

La idea principal de OOD es sugerir a los programadores la utilizacin de los paquetes

de ADA, no para poner en ellos cualquier procedimiento o definicin de tipo, sino para

implementar clases en el sentido de la aproximacin orientada a objetos. De este modo,

cualquier objeto del sistema se representa como un paquete. Lo esencial del mtodo

est dedicado a la elaboracin del modelo esttico (describir los objetos del sistema); el

modelo dinmico (cambios de estado de los objetos frente a ciertos eventos) solamente

se aborda muy parcialmente y el modelo funcional (describe los procesos de

transformacin de los usuarios) no se tiene en cuenta. OOD recomienda sin embargo el

anlisis de las funciones segn el mtodo SADT.

Los Modelos del Mtodo.

OOD se centra en la definicin del modelo esttico, y completa esta definicin con

algunos diagramas de estados para representar el aspecto dinmico.

En el mbito lgico se proponen dos tipos de diagramas: los diagramas de clases y los

diagramas de objetos (o de instancias). Los principales conceptos siguientes

constituyen los elementos de estos diagramas:

Objeto: adems de su definicin por sus atributos, sus operaciones y su identificador,

un objeto posee adems un estado o un conjunto de estados que controlan su

evolucin en el tiempo.

Asociaciones: adems de las asociaciones de herencia, de instanciacin y de

metaclases, el modelo esttico comporta una relacin que expresa un mensaje enviado

por un objeto a otro. Esta relacin se denomina relacin de utilizacin (un objeto utiliza

los servicios de otro objeto).

GlobalTec



Objeto cliente: es un objeto que utiliza los recursos de otro objeto.

Protocolo de un objeto: es la lista de operaciones que un objeto puede efectuar sobre

los dems objetos (conjunto de relaciones de utilizacin partiendo de dicho objeto).

Comportamiento de un objeto: es el protocolo del objeto ms la lista de operaciones

que los dems objetos pueden efectuar sobre l (lista de los servicios que solicita ms

los que ofrece).

Funcin de un objeto: un objeto puede ser cliente o actor (o activo) cuando opera sobre

otros objetos (les solicita servicios). Puede ser servidor(o pasivo) cuando es utilizado

por los dems (les ofrece servicios). Puede ser agente cuando es a la vez cliente y

servidor.

Concurrencia entre objetos: un objeto puede tener un comportamiento secuencial (se

dice que es un objeto secuencial) o concurrente (objeto concurrente). Un objeto

secuencial realiza una solicitud de servicio a otro objeto y espera el resultado. Un objeto

concurrente realiza una solicitud de servicio y sigue con su trabajo hasta la llegada del

resultado, que tendr en cuenta seguidamente. Un objeto secuencial solamente efecta

un servicio a la vez. Un objeto concurrente puede rendir varios servicios

simultneamente.

Objeto persistente: OOD menciona la persistencia de los objetos sin enunciar la

naturaleza del sistema que gestionar dicha persistencia. En realidad, como el mtodo

viene muy marcado por el lenguaje ADA, que no gestiona la persistencia, esta ltima

no se toma en cuenta realmente en el mbito lgico o fsico.

GlobalTec



4.3 Diseo de Sistema

Para los sistemas orientados a objetos, podemos definir una pirmide diseo, pero las capas son un poco diferentes. Haciendo referencia a la Figura 22,1, las cuatro capas de la OO diseo de la pirmide son: La capa subsistema contiene una representacin de cada uno de los subsistemas que permiten al software para conseguir sus requerimientos definidos en el cliente y a implementar la infraestructura tcnica que soporta los requerimientos del cliente. La clase y la capa de objeto contienen las jerarquas de clases que permiten al sistema que se cre mediante generalizaciones y cada vez ms orientada especializaciones. Esta capa tambin contiene representaciones de cada objeto. La capa de mensaje contiene los detalles de diseo que permiten a cada objeto para comunicarse con sus colaboradores. Esta capa establece el externo e interfaces internas para el sistema. La capa responsabilidades contiene la estructura de datos y algoritmos diseo para todos los atributos y operaciones para cada objeto.

La pirmide de diseo se centra exclusivamente en el diseo de un producto o sistema.

GlobalTec



Cabe sealar, sin embargo, que otra "capa" de diseo existe, y esta capa forma la base sobre la que descansa la pirmide. La capa de base se centra en el diseo de objetos de dominio (llamados patrones de diseo ms adelante en este captulo). Objetos de dominio desempean un papel clave en la construccin de la infraestructura para el sistema orientado a objetos mediante el apoyo a actividades de interfaz humano/ordenador, gestin de tareas y gestin de datos. Los objetos de dominio tambin se pueden utilizar para profundizar en el diseo de la propia aplicacin. El diseo del sistema se obtiene teniendo en cuenta las necesidades generales de los clientes (representados con casos de uso) y los eventos y estados que son externamente observables (el modelo objeto-comportamiento). Clase y diseo de objetos se asigna a partir de la descripcin de los atributos, operaciones y colaboraciones contenidas en el modelo CRC. El mensaje de diseo es impulsado por el modelo objeto-relacin, y el diseo de las responsabilidades est derivadas de los atributos, operaciones y colaboraciones descritas en el modelo de CRC. Fichman y Kemerer [FIC92] sugieren diez componentes de modelado de diseo que se pueden utilizar para comparar diversos mtodos de diseo convencionales y orientados a objetos: 1. Representacin de la jerarqua de mdulos. 2. Especificacin de las definiciones de datos. 3. Especificacin de la lgica procesal. 4. Indicacin de secuencias de procesamiento de extremo a extremo. 5. Representacin de estados y transiciones de objetos. 6. Definicin de las clases y las jerarquas. 7. La asignacin de las operaciones a las clases. 8. Definicin detallada de las operaciones. 9. Especificacin de conexiones de mensajes. 10. Identificacin de los servicios exclusivos.

GlobalTec



El diseo del sistema (Figura 2.4) se centr en proporcionar la funcional del sistema a travs de sus diferentes componentes. Las actividades que se realizan en este proceso son:

1. Dividir requerimos: Analice los requerimientos y organcelos en grupos afines. Normal existen varias opciones posibles de divisin, y pueden sugerir varias alternativas en esta de procesos.

2. Identificar subsistemas. Debe identificar los diferentes subsistemas que pueden,

individual o colectivamente, cumplir los requerimientos. Los grupos de requerimiento estn normalmente relacionados con los subsistemas, de tal forma que esta actividad y la divisin de requerimientos se pueden fusionar. Sin embargo, la identificacin de subsistemas se puede ver influenciada por otros factores organizacionales y del entorno.

3. Asignar requerimientos a los subsistemas. Asigne los requerimientos a los

subsistemas. En principio, esto ser sencillo si la divisin de requerimientos se utiliza para la identificacin de subsistemas. En la prctica, no existe igualdad entre las divisiones de requerimientos y la identificacin de subsistemas. Las limitaciones de los subsistemas comerciales pueden significar que tenga que cambiar los requerimientos para acomodarlos a estas restricciones.

4. Especificar la funcionalidad de los subsistemas. Debe enumerar las funciones

especficas asignadas a cada subsistema. Esto puede verse como parte de la fase de diseo del sistema o, si el subsistema es un sistema de software, como parte de la actividad de especificacin de requerimientos para ese sistema. Tambin debe especificar las relaciones entre los subsistemas en esta etapa.

5. Definir las interfaces del subsistema. Defina las interfaces necesarias y

requeridas por cada subsistema. Una vez que estas interfaces se han acordado, es posible desarrollar estos subsistemas en paralelo.

Figura 2.4

GlobalTec



4.4 Revisin del Diseo

El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:

El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente.

Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software.

El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin.

Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son:

Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software.

El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y sub funciones especficas.

Un diseo debe contener abstracciones de datos y procedimientos. Debe producir mdulos que presenten caractersticas de funcionamiento

independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los

mdulos y el entorno exterior. Debe producir un diseo usando un mtodo que pudiera repetirse segn la

informacin obtenida durante el anlisis de requisitos de Software.

Una revisin es un proceso o reunin durante la cual un producto de trabajo, un

conjunto de productos de trabajo o la evidencia de la ejecucin de un proceso se

presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes

interesadas para su comentario o aprobacin.

Las revisiones al diseo de los productos de software se realizan por demanda con el

objetivo de detectar e identificar no conformidades en el diseo antes de pasar a la

codificacin, as como tambin identificar aspectos de mejoramiento. Entre otros, en

esta actividad se verifica la arquitectura y utilizacin de patrones en el diseo.

GlobalTec



Cuando el diseo se completa se mantienen reuniones con los clientes para revisarlos

antes de avanzar al desarrollo, el proceso de revisin se realiza en tres etapas en

correspondencia con los pasos del proceso del diseo:

1. Revisin del diseo preliminar

Los clientes y usuarios se renen para validar el diseo conceptual.

Se asegura que todos los aspectos relativos a los requerimientos han sido

apropiadamente completados en el diseo

Se invita a participar a ciertas personas claves:

Cliente(s): ayudan a definir los requerimientos del sistema. Analista(s): quien colabora para definir los requerimientos del sistema. Usuario(s): potenciales del sistema Diseador(es): del sistema Un moderador, un secretario y otros desarrolladores.

Se recomienda que el nmero de integrantes sea pequeo de modo que faciliten las

discusiones.

Durante la revisin se presenta a la audiencia el diseo conceptual. Al hacerlo, se

demuestra que el sistema tiene estructura requerida, las funciones y las

caractersticas especificadas por los documentos del anlisis.

Todos los participantes, en conjunto, verifican que el diseo propuesto incluya el

hardware necesario, interfaces con otros sistemas entradas y salidas.

Los clientes prueban los dilogos y mens, los formatos de los informes y el

tratamiento e defectos propuestos.

2. Revisin crtica del diseo.

Realiza una revisin crtica del diseo, donde se presenta una vista general del diseo

tcnico.

Integrantes:

Analistas Diseadores del sistema Moderador Diseadores del programa para el proyecto Probador del sistema

GlobalTec



Analista que escribir la documentacin del sistema y otros desarrolladores.

Este grupo es ms tcnico que el anterior, ya que la revisin trata de aspectos tcnicos.

El moderador conduce la reunin para que se traten dos puntos: si el diseo

implementa todos los requerimientos y si es un diseo de calidad.

Usando diagramas, o datos ambas cosas se explican las estrategias de diseo

alternativa y como y porque se han tomado las principales decisiones de diseo.

Si se identifican problemas mayores el diseo se rehace.

3. Revisin del diseo de programas.

Cuando el diseo tcnico resulta satisfactorio, los diseadores de programas estarn en

posicin de interpretarlo como el conjunto de descripciones de diseo para los

componentes reales, que deben ser codificados y probados.

Despus de completar los diseos de programas, pero antes de comenzar la

decodificacin, se presentan sus planes.

Integrantes:

Analistas Diseadores del sistema Diseadores del programa Moderador, secretario y probador del sistema.

Este proceso se centra en la deteccin de defectos ms que en su correccin.

Adems, se est evaluando el diseo no a los diseadores.

El proceso beneficia a todos al encontrar defectos y problemas cuando aun son

fciles y poco costosos de corregir.

GlobalTec



4.5 Diagramas de Secuencias del Diseo

Diagramas de secuencia

Los diagramas de secuencia se usan para mostrar la interaccin entre los usuarios, las

pantallas y las instancias de los objetos en el sistema. Proveen un mapa secuencial del

paso de los mensajes entre los objetos a lo largo del tiempo. Frecuentemente, estos

diagramas se ubican bajo los casos de uso o los componentes en el modelo para

ilustrar un escenario, cmo interacta un usuario con el sistema y qu sucede

internamente para que el trabajo se lleve a cabo. Muchas veces, los objetos se

representan utilizando conos especialmente estereotipados.

GlobalTec



Como se muestra en el ejemplo anterior. El objeto etiquetado "Pantalla De Ingreso"

(Login Screen) se muestra empleando el cono de interfaz. El objeto etiquetado

"Administrador De Seguridad" (SecurityManager) se muestra usando el cono

controlador. El objeto etiquetado "Usuarios" (Users) se muestra usando el cono

entidad.

La idea primordial es que las interacciones entre los objetos se realiza en una

secuencia establecida y que la secuencia se toma su tiempo en ir del principio al fin. Al

momento de crear un sistema tendr que especificar la secuencia, y para ello, utilizara

al diagrama correspondiente.

Un diagrama de secuencias consta de objetos que se representan del modo usual:

rectngulos con nombre (subrayado), mensajes representados por lneas continuas con

una punta de flecha y el tiempo representado como una progresin vertical

Objetos

Se colocan cerda de la parte superior del diagrama de izquierda a derecha y se

acomodan de manera que simplifiquen al diagrama. La extensin que esta debajo (y en

forma descendente) de cada objeto ser una lnea discontinua conocida como la lnea

de vida de un objeto. Junto con esta se encuentra un pequeo rectngulo conocido

como activacin, el cua representa la ejecucin de una operacin que realiza el objeto.

La longitud del rectngulo se interpreta como la duracin de la activacin.

Mensaje

Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto a la de

otro. Un objeto puede enviarse un mensaje a si mismo (Es decir, desde su lnea de vida

hacia su propia lnea de vida).

Representacin de un Objeto en un Diagrama de Secuencias.

GlobalTec



Tipos de mensajes

Simple: Es la transferencia del control de un objeto a otro.

Sincrnico: Este tipo de mensajes sucede cuando un objeto enva un mensaje y

este se queda en espera de la respuesta a tal mensaje antes de continuar su

trabajo.

Asincrnico: Esto sucede si un objeto si un objeto enva un mensaje y no espera

respuesta alguna para continuar su trabajo.

Ilustracin Tipos de mensajes

Tiempo

El diagrama representa tiempo en direccin vertical. El tiempo se inicia en la parte

superior y avanza hacia la parte inferior. Un mensaje que est ms cerca de la parte

superior ocurrir antes que uno que est cerca de la parte inferior.

Con ello el diagrama de secuencias tiene dos dimensiones. La dimensin horizontal es

la disposicin de los objetos, y la dimensin vertical muestra el paso del tiempo

La figura muestra al conjunto bsico de smbolos del diagrama de secuencias,

con los smbolos en funcionamiento conjunto.

GlobalTec



Tipos de diagramas de secuencia (Instancia y Genricos):

Diagramas de secuencia de instancia

Este tipo de diagrama de secuencias solo se centra en un escenario por lo que describe

un escenario especifico (un escenario es una instancia de la ejecucin de un caso de

uso).

Diagrama de secuencias genrico

Este tipo de diagramas de secuencia existe cuando se toman en cuenta todos los

escenarios de un caso de uso al momento de crear el diagrama de secuencias, es

decir, describe la interaccin para un caso de uso en general, mediante el uso de

ramificaciones (branches), condiciones y bucles.

Se puede generar un diagrama de secuencias genrico a partir del diagrama de

secuencias de instancia mediante el uso de condiciones.

GlobalTec



4.6 Herramientas CASE para el Diseo

Herramientas de Anlisis y Diseo: Permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la evaluacin de la validez y consistencia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Entre ellas podemos encontrar:

Herramientas de anlisis y diseo (Modelado). Herramientas de creacin de prototipos y de simulacin. Herramientas para el diseo y desarrollo de interfaces.

Dichas herramientas tiene soporte para diagramas UML 2

Diagramas Estructurales:

Clase

Objeto

Compuesto

Paquete

Componente

Despliegue

Diagramas de Comportamiento:

Casos de Uso

Comunicacin

Secuencia

Descripcin de la Interaccin

Actividad

Estado

Tiempo

GlobalTec



Modelo de Casos de Uso

Diagramas de Secuencia

GlobalTec



Diagrama de Implementacin

ALGUNOS EJEMPLOS DE HERRAMIENTAS CASE:

System Architect, herramientas CASE para Anlisis y Diseo, incluye tcnicas estructuradas y orientadas a objetos.

Win A&D, herramientas CASE para Anlisis y Diseo, incluye tcnicas estructuradas y orientadas a objetos.

CRADLE, conjunto de herramientas CASE integradas que dan soporte a la Planificacin estratgica, Analsis y Diseo.

PowerDesigner 7.0: herramienta CASE de Anlisis y Diseo incluye capacidades de generacin relacional y con orientacin a objetos.

GlobalTec



Referencias

Diagramas secuenciales y aplicaciones CASE

http://www.sparxsystems.com.ar/resources/tutorial/uml-tutorial.html

Diseo de sistema Software Engineering A P R A C T I T I O N E R S A P P R O A C H Captulo 22

Estrategias de diseo

http://indalog.ual.es/mtorres/LP/FundamentosDiseno.pdf

http://translate.google.com.mx/translate?hl=es&langpair=en%7Ces&u=http://neverletdown.net/2010/08/choo

sing-a-software-design-strategy/

Revisin de diseo

http://www.slideshare.net/SergioRios/unidad-21-diseo-de-sistemas Pg. 59

GlobalTec



Unidad 4 Modelo de Diseño

Documents

Transcript of Unidad 4 Modelo de Diseño