analisis de diseño

10
INSTITUTO TECNOLOGICO SUPERIOR DE CIUDAD ACUÑA CARRETERA A PRESA LA AMISTAD KM. 9 C.P. 26280 CD. ACUÑA, COAHUILA TEL: (877)773 1800 FAX: EXT 107 www.tecnologicodeacuna.edu.mx ACADEMIA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. Análisis de diseño. MATERIA: Arquitectura y diseño de software. CARRERA: Ingeniería en Sistemas Computacionales. CATEDRÁTICO: Ing. J. Christian Martínez Contreras ALUMNO: Marlene Rojas Sandoval MATRICULA: 2113S4846 SEMESTRE: 8vo. Turno Nocturno

Upload: marlen-rojas

Post on 08-Nov-2015

228 views

Category:

Documents


0 download

DESCRIPTION

Redes

TRANSCRIPT

03 de Octubre de 2005

Anlisis de diseo.MATERIA:Arquitectura y diseo de software.CARRERA:Ingeniera en Sistemas Computacionales.CATEDRTICO:Ing. J. Christian Martnez ContrerasALUMNO:Marlene Rojas SandovalMATRICULA:2113S4846SEMESTRE:8vo.Turno Nocturno

CD. ACUA, COAHUILA, MXICO 18 de Marzo del 2015

2.7.1.- Diagrama de secuencia.Un diagrama de secuencia es una forma de diagrama de interaccin que muestra los objetos como lneas de vida a lo largo de la pgina y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la lnea de vida origen hasta la lnea de vida destino. Los diagramas de secuencia son buenos para mostrar qu objetos se comunican con qu otros objetos y qu mensajes disparan esas comunicaciones. Los diagramas de secuencia no estn pensados para mostrar lgicas de procedimientos complejos.

Lnea de Vida

Una lnea de vida representa un participante individual en un diagrama de secuencia. Una lnea de vida usualmente tiene un rectngulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la lnea de vida representa el clasificador que posee el diagrama de secuencia.

Algunas veces un diagrama de secuencia tendr una lnea de vida con un smbolo del elemento actor en la parte superior. Este usualmente sera el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y lmite de los diagramas de robustez tambin pueden contener lneas de vida.Mensajes

Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; sncronos o asncronos: llamadas o seales. En el siguiente diagrama, el primer mensaje es un mensaje sncrono (denotado por una punta de flecha oscura), completo con un mensaje de retorno implcito; el segundo mensaje es asncrono (denotado por una punta de flecha en lnea) y el tercero es un mensaje de retorno asncrono (denotado por una lnea punteada).2.7.2.- Diagrama de colaboracin.

Un diagrama de colaboracin destaca la organizacin de los objetos que participan en una interaccin, un diagrama de colaboracin se construye colocando en primer lugar los objetos que participan en la colaboracin como nodos de un grafo. A continuacin se representa los enlaces que conectan esos objetos como arcos de grafo, por ltimo, estos enlaces se adorna con los mensajes que envan y reciben los objetos, esto da al lector una seal visual clara del flujo de control en el contexto de la organizacin estructural de los objetos que colaboran.

Los diagramas colaboracin tienen dos caractersticas que los distinguen de los diagramas de secuencia, el primero para indicar cmo se enlaza un objeto a otro, se puede asociar un objeto al extremo ms lejano de un enlace con la palabra local que indica que el objeto designado es local al emisor. En segundo lugar est el nmero de secuencia, para indicar la ordenacin temporal de los mensajes, se precede de un nmero iniciando con el numeral 1, que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control.2.7.3.- Diagramas de clases de diseo.Un Diagrama de Clases de Diseo muestra la especificacin para las clases software de una aplicacin. Incluye la siguiente informacin:

Clases, asociaciones y atributos.

Interfaces, con sus operaciones y constantes.

Mtodos.

Navegabilidad.

Dependencias.

A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra definiciones de entidades software ms que conceptos del mundo real. En la siguiente figura se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.

Relaciones de Dependencia Para Representar Visibilidad Entre Clases

Cuando una clase conoce a otra por un medio que no es a travs de un atributo (una asociacin con la navegabilidad adecuada), entonces es preciso indicar esta situacin por medio de una dependencia.

Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se dice entonces que el primer objeto tiene visibilidad sobre el segundo. La visibilidad ms directa es por medio de atributo, cuando hay una asociacin entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia:

Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo .

Local: Cuando en un mtodo de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo .

Global: Cuando hay una variable global en el sistema, instancia de una clase A, y un mtodo de una clase B llama a un mtodo de A, se dice que la clase B tiene visibilidad global sobre la clase A. La relacin de dependencia entre ambas clases se etiqueta con el estereotipo .

No es necesario representar la relacin de dependencia entre clases que ya estn relacionadas por medio de una asociacin, que se trata de una dependencia ms fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qu elementos hay que revisar cuando se realiza un cambio en el diseo de un elemento del sistema.2.8.- Patrones GRASP

Un patrn es una descripcin de un problema bien conocido que suele incluir:

Descripcin

Escenario de Uso

Solucin concreta

Las consecuencias de utilizar este patrn

Ejemplos de implementacin

Lista de patrones relacionados

GRASP es el acrnimo de General Responsibility Assignment Software Patterns.Describen los principios fundamentales de diseo de objetos para la asignacin de responsabilidades. Una de las cosas ms complicadas en Orientacin a Objeto consiste en elegir las clases adecuadas y decidir cmo estas clases deben interactuar. Incluso cuando utilizamos metodologas rpidas como programacin extrema (extreme programming) y centramos el proceso en el desarrollo continuo, es inevitable elegir cuidadosamente las responsabilidades de cada clase en la primera codificacin y, fundamentalmente, en la refactorizacin (continual) de nuestro programa.

Lo patrones de GRASP, no compiten con los patrones de diseo. Los patrones de GRASP, nos guan para ayudarnos a encontrar los patrones de diseo (que son ms concretos).

2.9.- Patrones GOF.

Lo ms comn es agruparlos en creacionales, estructurales y de comportamiento, pero estudiarlos en orden ascendente de dificultad nos permitir una mayor comprensin.

Patrones sencillos

Facade

Provee de una nica interfaz para acceder a un sistema completo, que acta como nico punto de acceso al mismo, y hace que ste sea ms fcil de utilizar.

Singleton

Restringe la creacin de objetos pertenecientes a una clase o el valor de un tipo a un nico objeto.

Mediator

A modo de Man in the middle, define un objeto que encapsula como interactuan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explcitamente, y permite variar la interaccin entre ellos de forma independiente.

La bolsa acta como un Mediator. sta media entre compaas, inversores, reguladores del gobierno, etc, limitando la interaccin directa entre ellos.Iterator

Este patrn se basa en el recorrido de todos los elementos de una colleccin, una vez cada uno, y sin seguir un orden en concreto.