Cap. 1 Análisis y Diseño Orientado a Objetos
p.3
El probervio "tener un martillo no te hace un arquitecto"
UML es una notación visual estándar. Tan útil como aprender una notación, hay cosas orientadas a objetos importantes que aprender; concretamente, cómo pensar en objetos (cómo diseñar sistemas orientados a objetos). UML no es A/DOO o un método, es simplemente una notación. No es tan útil aprender a hacer diagramas UML sintácticamente correctos y quizás una herramienta CASE para UML, si no se es capaz de crear un diseño excelente o evaluar uno existente. Ésta es la habilidad más difícil y valiosa.
El Proceso Unificado es un proceso iterativo.
Asignación de responsabilidades
Esto es habilidad fundamental e Inevitable. Se presentan y aplican nueve principios fundamentales en el diseño de objetos y asignación de responsabilidades. Se organizan en una ayuda al aprendizaje denominada patrones GRASP.
p.6
¿Qué es Análisis y qué es Diseño?
El Análisis pone énfasis en una investigación del problema y los requisitos, en vez de ponerlos en la solución.
Ejm. Si se desea un nuevo sistema de información informatizado para una biblioteca ¿Cómo se utilizará?
Análisis de requisitos (un estudio de los requisitos)
Análisis de objetos (un estudio de los objetos de dominio)
El Diseño pone énfasis en la solución conceptual que satisface los requisitos, pero no así en la implementación
Diseño de objetos
Diseño de bases de datos
En otras palabras,
El Análisis: hacer lo correcto El Diseño: hacerlo correcto
"el qué" "el cómo (conceptualmente)"
Análisis y Diseño Orientados a Objetos
Durante el Análisis Orientado a Objetos, se presta especial atención a encontrar y describir los objetos (o conceptos) en el dominio del problema.
Ejm. En una biblioteca, libro, socio, etc.
Durante el Diseño Orientado a Objetos, se presta especial atención a la definición de objetos de software y como colaboran para satisfacer los requisitos.
Ejm. Libro: título (atributo), ObtenerCapitulo(método)
p.7
Un ejemplo
Se presenta de un modo superficial, unos pocos pasos y diagramas claves.
* Definición de casos de uso
* Definición del modelo del dominio
* Definición de diagramas de interacción
* Definición de diagramas de clases de diseño
Def. Casos de Uso, son simplemente historias escritas (no son artefactos orientados a objetos)
El Análisis de los Requisitos, podría incluir una descripción de los procesos del dominio relacionados, que podrían representarse como casos de uso
Ejm. Jugar una partida de dados: (descripción del caso de uso)
Def. Modelo del Dominio
La finalidad del análisis orientado a objetos es crear una descripción del dominio desde la perspectiva de la clasificación de objetos. Una descomposición del dominio conlleva identificación de conceptos, atributos y asociaciones que se consideran significativas.
El resultado se puede expresar en un modelo de dominio, que se ilustra mediante un conjunto de diagramas que muestran los objetos o conceptos del dominio.
p.8
Nótese que un modelo de dominio no es una descripción de los objetos de software, es una visualización de los conceptos en el dominio del mundo real.
Def. Diagramas de Interacción
Estas son las vistas dinámicas de las colaboraciones entre objetos.
La finalidad del análisis orientado a objetos: es crear una descripción del dominio desde la perspectiva de la clasificación de objetos.
La finalidad del diseño orientado a objetos: es definir los objetos software y sus colaboraciones (Se pueden utilizar diagramas de interacción para representar dichas colaboraciones).
Def. Diagramas de clases de diseño
Esta es la vista estática de las definiciones de las definiciones de las clases mediante un diagrama de clases de diseño.
UML
Citando textualmente:
El Lenguaje Unificado de Modelado (UML) es un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas de software, así como para el modelado del negocio y otros sistemas de software.
El UML se ha convertido en la notación de facto, en 1994 empezaron juntándose los métodos de Booch y OMT (Object Modeling Technique), luego Objectory.
UML fue adoptado en 1997 como estándar por el OMG (Object Management Group)
Lecturas adicionales
* UML Distilled, de Martin Fowler
* The Rational Unified Process-An Introduction, de Philippe Kruchten
* The Unified Modeling Language Reference Manual y The Unified Modeling Language User Guide, de Booch, Jacobson y Rumbaugh
* OMG Unified Modeling Language Specification en www.omg.org. Los trabajos de revisión UML que van a estar pronto se pueden encontrar en www.celigent.com/uml
* Design Patterns de Gamma, Helm, Johnson y Vlissides.
-------------------------------------------------------------------------------------------------------------------------
Cap. 2 Desarrollo iterativo y el Proceso Unificado
p.13
El desarrollo iterativo es un enfoque para el desarrollo de software que requiere un entrenamiento y poseer ciertos conocimientos, y juega un papel central en el modo que se presenta A/DOO en este libro.
De manera informal, un proceso de desarrollo de software, describe un enfoque para la construcción, desarrollo y, posiblemente, mantenimiento de software. En particular se ha adoptado ampliamente el Proceso Unificado de Rational o RUP, un refinamiento detallado del Proceso Unificado.
p.14
La idea más importante de UP: desarrollo iterativo
El UP se basa en varias prácticas, una de las más importantes es: el desarrollo iterativo. En este enfoque, el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (por ejemplo, cuatro semanas) llamadas iteraciones; el resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. Cada interacción incluye sus propias actividades de análisis, diseño, implementación y pruebas.
El ciclo de vida iterativo se basa en la impliación y refinamiento sucesivos del sistema mediante múltiples iteraciones, con realimentación cíclica y adaptación como elementos principales elementos principales que dirigen para converger hacia un sistema adecuado. El sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración, y por ello, este enfoque se conoce como desarrollo iterativo e incremental.
Las primeras ideas sobre procesos iterativos se conocieron como desarrollo en espiral y desarrollo evolutivo.
El resultado de cada iteración es un sistema ejecutable, pero incompleto; no está preparado para ser puesto en producción. El sistema podría no estar listo para su puesta en producción hasta después de muchas iteraciones; por ejemplo, 10 ó 15 iteraciones.
La salida de una iteración no es un prototipo experimental o desechable, y el desarrollo iterativo no es prototipado. Más bien, la salida es un subconjunto con calidad de producción del sistema final. (NO ENTIENDO BIEN ESTO ULTIMO)
Aunque, en general, cada iteración aborda nuevos requisitos y amplía el sistema incrementalmente, una iteración podría, ocasionalmente, volver sobre el software que ya existe y mejorarlo; por ejemplo, una iteración podría centrarse en mejorar el rendimiento de un subsistema, en lugar de extenderlo con nuevas características.
p.16
Aceptando los cambios: retroalimentación y adaptación
Esto no quiere decir que el desarrollo iterativo y el UP fomenten un proceso dirigido por una "adición de características" de una manera incontrolada y reactiva. El UP llega a un equilibrio entre la necesidad (por un lado) de llegar a un acuerdo y estabilizar un conjunto de requisitos, u (por otro lado) la realidad de los requisitos cambiantes, cuando el personal involucrado clarifica su visión o cambia el mercado.
Cada iteración conlleva la elección de un pequeño conjunto de requisitos y, rápidamente, diseñar, implementar y probar.
Tener retroalimentación en una etapa temprana vale su peso en oro; más que las especulaciones sobre requisitos y diseños correctos, la retroalimentación, a partir de la construcción y prueba realista de algo, aporta un conocimiento práctico y crucial, y una oportunidad de modificar o adaptar la comprensión de requisitos o el diseño.
p.17
Beneficios del desarrollo iterativo
.......
Longitud de una iteración y fijación de la duración
El UP y los desarrolladores con experiencia en aplicar procesos iterativos, recomiendan que la longitud de una iteración sea de dos a seis semanas. Menos de dos semanas es difícil de completar el trabajo suficiente para tener resultados significativos y retroalimentación; más de seis u ocho semanas, y la complejidad se vuelve bastante abrumadora, se retrasa la retoalimentación. Con iteraciónes muy largas pierde su sentido el desarrollo iterativo. Lo corto es bueno.
p.18
Conceptos y buenas prácticas de UP adicionales
........
p.19
Las fases del UP y términos orientados a la planificación
Un proyecto UP organiza el trabajo y las iteraciones en cuatro fases fundamentales:
1.- Inicio: visión aproximada, análisis del negocio, alcance, estimaciones impresisas.
2.- Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de los riesgos altos, identificación de más requisitos y alcance, estimaciones realistas.
3.- Construcción: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles, preparación para el despliegue.
4.- Transisción: pruebas beta, despliegue
Esto no se corresponde con el antiguo ciclo de vida "en cascada" o secuencial en el que primero se definían todos los requisitosy, después, se realizaba todo, o la mayoría, del diseño.
(Pregunta¿Se podría pensar en esto como que cada fase es una medición de la madurez holística del proyecto?)
RECORDAR, Fases:
* Inicio
* Elaboración
* Construcción
* Transición
Las disciplinas del UP (antes flujos de trabajo)
El UP describe actividades de trabajo, como escribir casos de uso, en disciplinas (llamadas originalmente flujos de trabajo). Informalmente, una disciplina es un conjunto de actividades (y artefactos relacionados) en un área determinada, como las actividades en el análisis de requisitos. En el UP, un artefacto es el término general para cualquier producto del trabajo; código, gráficos Web, esquema de base de datos, documentos de texto, diagramas, modelos, etc
Disciplinas y fases
Como se muestra en la fig. 2.4, durante una iteración, el trabajo se desarrolla en la mayoría o todas las disciplinas. Sin embargo, el esfuerzo relativo en estas disciplinas cambia a lo largo del tiempo. Las primeras iteraciones, naturalmente, tienden a aplicar un esfuerzo relativo mayor a los requisitos y al diseño, en las posteriores disminuye, cuando los requisitos y el diseño central se estabilizan, mediante un proceso de retroalimentación y adaptación.
En la fig. 2.5 se muestran las disciplinas en las que centrará el aprendizaje del presente libro
Adaptación del proceso y el Marco de Desarrollo
Artefactos opcionales
Algunas prácticas y principios del UP deben seguirse siempre, como desarrollo iterativo y dirigido por el riesgo, y la verificación continua de la calidad.
Sin embargo, es importante saber que en el UP todas las actividades y artefactos (modelos, diagramas, documentos...) son opcionales, a excepción del código que es indispensable para construir el sistema. El conjunto de artefactos posibles del UP debería entenderse como un conjunto de medicinas en la farmacia. Exactamente igual que uno no toma medicinas indiscriminadamente, sino que elige según la dolencia, en un proyecto UP es lo mismo para el equipo de trabajo según las necesidades que se planteen.
Marco de Desarrollo
La elección de los artefactos del UP para un proyecto podría recogerse en un documento breve denominado Marco de Desarrollo (un artefacto en la disciplina Entorno).
Los artefactos de ejemplo que se presentan en este caso de uso de ningún modo son suficientes, o adecuados, para todos los proyectos. Por ejemplo, un sistema de control de una máquina encontraría útil realizar muchos diagramas de estados. Un sistema de comercio electrónico basado en web podría centrar su atención en los principios de interfaz de usuario. Un proyecto de desarrollo nuevo, en un campo en el que no se tenga experiencia tendría necesidades muy diferentes, en cuanto a los artefactos de diseño, de las de un proyecto de integración de sistemas.
El UP ágil
....
El ciclo de vida "en cascada" secuencial
A diferencia del ciclo de vida iterativo del UP, una antigua alternativa era el ciclo de vida "en cascada", lineal o secuencial. En su acepción habitual, definía los pasos más o menos de la siguiente forma:
1. Determinar, registrar y acordar un conjunto de requisitos completo y fijo.
2. Diseñar un sistema basado en dichos requisitos.
3. Implementar en base al diseño.
No se entendió UP cuando...
.....
Lecturas adicionales
referencias bibliográficas de RUP y UP
referencias bibliográficas de Metodologías Ágiles
--------------------------------------------------------------------------------------------------------------------------
Cap. 3 Caso de Estudio: El sistema de punto de venta Nueva Era
El sistema de punto de venta (PDV) NuevaEra.
Un sistema PDV es una aplicación informática utilizada (en parte) para registrar ventas y realizar pagos; normalmente se utiliza en tiendas. Incluye componentes de hardware, como un ordenador y un lector de códigos de barras, y un software para ejecutar el sistema. Interactúa con varias aplicaciones de servicios, como un servicio de cálculo de impuestos y un control de inventarios, de terceras partes. Estos sistemas deben ser, relativamente tolerante a fallos; es decir, incluso si los servicios remotos no están disponibles temporalmente (como el sistema de inventario), todavía deben ser capaces de capturar las ventas y gestionar, al menos, los pagos en efectivo (de manera que no se impida que el negocio funciones de manera adecuada).
Un sistema PDV, progresivamente, debe soportar múltiples y variados terminales e interfaces del lado cliente, como un terminal con un navegador Web de una arquitectura "cliente delgado" (thin client).
Además, estamos creando un sistema PDV comercial que se venderá a diferentes clientes con necesidades dispares en términos de procesamiento de reglas del negocio. Cada cliente deseará un conjunto exclusivo de lógica a ejecutar en ciertos puntos predecibles en escenarios de uso del sistema, como cuando se inicia una venta o cuando se añade una nueva línea.
Capas arquitectónicas y el énfasis del caso de estudio
Un sistema de información orientado a objetos típicos se diseña en función de varias capas arquitectónicas o subsistemas, véase la siguiente figura
* Interfaz de Usuario: interfaz gráfica; ventanas.
* Lógica de la aplicación y Objetos del Dominio: objetos software que representan conceptos del dominio (por ejemplo una clase denominada Venta) que satisfacen los requisitos de la aplicación.
* Servicios técnicos: objetos de propósito general y subsistemas que proporcionan servicios técnicos de apoyo, como conexión con una base de datos o registrar los errores. Normalmente, estos servicios son independientes de la aplicación y se pueden reutilizar en varios sistemas.
El caso de estudio NuevaEra se centra principalmente en los objetos del dominio del problema, asignándoles responsabilidades para satisfacer los requisitos de la aplicación. El diseño orientado objetos también se aplica para crear un subsistema de servicio técnico para interactuar con una base de datos.
En este enfoque de diseño, la capa de interfaz de usuario tiene muy poca responsabilidad; se dice delgada. Las ventanas no contienen código que ejecute o procese la lógica de la aplicación, sino que, las peticiones de realización de tareas se envían a otras capas.
No hay comentarios:
Publicar un comentario