Análisis y Dise˜no

More documents

Recommendations

Info

}interface Observer {}public void update(Subject o);class ObserverConcreto implements Observer {private String state = "";public void update(Subject o) {estado = o.getState();System.out.println("Nuevo estado" + estado);}}Otros ejemplos de patrones muy conocidos incluyen el patron Strategy,también conocido como Policy pattern, que es utilizado para implementar distintosalgoritmos que compartan la interfaz pero puedan utilizarse indistintamente,con la ventaja de que se puede cambiar de algoritmo dinámicamente(ver figura 20). El patrón Composite es utilizado para construir jerarquíasde objetos que comparten una interfaz en la que unos elementos pueden formarparte de otros (por ejemplo, el las interfaces de usuario las ventanas secomponen de paneles, botones campos de texto, etc. y a su vez por ejemplolos botones de una etiqueta de texto y una imagen). Otro patrón conocidoes Iterator que nos permite recorrer los elementos de una clase contenedorade objetos (como puede ser un Vector) sin conocer su implementación; unejemplo de su uso es la interface java.util.Enumeration como se muestraa continuación el el caso de tener una colección de Strings:Enumeration e = vector.elements();while (e.hasMoreElements())String s = (String) e.nextElement();System.println(s);}37
Figura 20: Patrón StrategyAdemás, se puede hacer una reseña al concepto de antipatrón, que aunquese describen de manera semejante a la de un patrón, lo intentan es prevenircontra errores comunes en el diseño del software. Los antipatrones intentandetallar problemas que acarrean ciertos diseños muy comunes y que a primeravista correctos, pero que a la larga las desventajas superan los beneficios. Losantipatrones definen pueden definirse a distintos niveles, y por ejemplo, sehan detallado antipatrones de gestión. Sin embargo, a nivel de diseño, losantipatrones puede clasificarse como refactorizaciones.4.2. Software frameworks, plug-ins y componentesObviamente es mucho mejor la reutilización a nivel de arquitecturas ydiseños que no a nivel de clases. Los patrones de diseño nos permiten reutilizarun pequeño número de clases en conjunto, los frameworks, plug-ins ycomponentes van más allá, permitiéndonos reutilizar diseños y arquitecturasenteras para dominios concretos.38
Page 3: 4.3. Diseño por contratos . . . .
Page 6 and 7: Abstracción de control. Define a u
Page 9 and 10: Figura 1: (a) Acoplamiento débil;
Page 11 and 12: estándar ISO/IEC 42010:2007, defin
Page 13 and 14: Figura 2: Estilo arquitectónico de
Page 15 and 16: Figura 5: (a) Cliente-servidor; (b)
Page 17 and 18: Figura 6: Evolución de los método
Page 19 and 20: Figura 8: Niveles en los diagramas
Page 21 and 22: Regla1 2 3CondicionesEdad > 60 Sí
Page 23 and 24: ases de datos. El modelo Entidad/Re
Page 25 and 26: Al igual que con los métodos estru
Page 27 and 28: Kruchten [23] mediante modelos y di
Page 29 and 30: Figura 13: Diagrama de clasesDiagra
Page 31 and 32: Figura 15: Ejemplos de diagrama de
Page 33 and 34: Resumen del diseño orientado a obj
Page 35 and 36: Finalmente, el paradigma de la orie
Page 37 and 38: solución un millón de veces en el
Page 39: Figura 19: Patrón Observerclase de
Page 43 and 44: Es decir, el framework debe ser lo
Page 45 and 46: nentes, donde la no disposición de
Page 47 and 48: 5. Diseño de sistemas distribuidos
Page 49 and 50: distribuido. Para ello deben de imp
Page 51 and 52: Un tipo de validación, aunque meno
Page 53 and 54: Dentro de la orientación a objetos
Page 55 and 56: Profundidad en árbol de herencia (
Page 57 and 58: software y cubre tanto las metodolo
Page 59 and 60: [10] Mohamed E. Fayad, Douglas C. S
Page 61: [34] James Rumbaugh, Ivar Jacobson,

Análisis y Dise˜no

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?