Post on 08-Jan-2016
description
[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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 4 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 5 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 6 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 7 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 8 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 9 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 10 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 11 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 12 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 13 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 14 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 15 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 16 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 17 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 18 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 19 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 20 de 22
Modelo de Casos de Uso
Diagramas de Secuencia
GlobalTec
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 21 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 22 de 22
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
Fundamentos de Ingeniera del Software UNIDAD 4
Ingeniera en Sistemas Computacionales Pgina 23 de 22