[Escriba aqu]

GLOBALTEC
UNIDAD 4

Modelo de Diseo

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

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

Ingeniera en Sistemas Computacionales

Pgina 3 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.)

Ingeniera en Sistemas Computacionales

Pgina 4 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 5 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 6 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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).

Ingeniera en Sistemas Computacionales

Pgina 7 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 8 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 9 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 10 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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

Ingeniera en Sistemas Computacionales

Pgina 11 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 12 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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

Ingeniera en Sistemas Computacionales

Pgina 13 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 14 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 15 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Representacin de un Objeto
en un Diagrama de Secuencias.

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).

Ingeniera en Sistemas Computacionales

Pgina 16 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 17 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 18 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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

Ingeniera en Sistemas Computacionales

Pgina 19 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

Modelo de Casos de Uso

Diagramas de Secuencia

Ingeniera en Sistemas Computacionales

Pgina 20 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

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.

Ingeniera en Sistemas Computacionales

Pgina 21 de 22

GlobalTec
Fundamentos de Ingeniera del Software

UNIDAD 4

Referencias

Diagramas secuenciales y aplicaciones CASE

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

Diseo de sistema
Software Engineering
APRACT IT I O N ER SAPPR OAC 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

Ingeniera en Sistemas Computacionales

Pgina 22 de 22

GlobalTec
Fundamentos de Ingeniera del Software

Ingeniera en Sistemas Computacionales

UNIDAD 4

Pgina 23 de 22