Sunday, July 16, 2006

Object Design (Wirts-Brock/McKean) – Capitulo 2

El Responsability-Driven es un metodo informal y la herramienta principal es el poder de abstracción. Responsabilidad describe que es lo que nuestro software debe hacer para cumplir su proposito.Vamos desde los requerimientos iniciales a las primeras descripciones y modelos, desde este punto a unas descripciones y modelos mas detallados de los objetos , de los objetos candidatos y los modelos detallados de sus responsabilidades, con patrones y collaboration.

Project definition and planning.
Aunque nuestro proyecto sea pequeño siempre debemos realizar la declaracion del projecto(statement) incluyendo un proposito, una vista general, la definición del alcance y los beneficions. El Project plan describe lo siguiente:
- Como se va a desarollar el soft.
- Los valores importantes para el proyecto y la gente involucrada.
- Los recursos y sus roles, los procesos y los ingresos esperados.
- Los entregables.
- Early description.
El analisis incluye la definición del sistema, la descripción y el analisis de las actividades de los objetos.Requerimientos del usuario, administrador, o cliente pueden ser:Uso, performance, configuración, autenticación, concurrencia, escalabilidad, seguridad, confiabilidad.
No importa cuanto trates, nunca vas a identificar todos los requerimientos.

Diseño.
En diseño construimos un modelo de cómo va a funcionar nuestro sistema. Dividiendo esta etapa en 2 subfases.
-Crear un diseño inicial
-Crear una solucion mas comprensiva.
Esta etapa se divide porque la mayoria de las aplicaciones son demasiado complejas para llegar a un correcto diseño la primera vez.

Viendo desde multiples perspectivas.
Cada sponsor de nuestro proyecto tiene distintas necesidades. Los diseñadores de objetos tenemos dos desafios:Interpretar correctamente los requerimientos y concerns (preocupaciones) de nuestros stakeholders.Presentar nuestro trabajo de diseño de modo que sea bien entendido por una basta audiencia.

Analisis description
Transformamos vagas ideas en especificaciones de lo que queremos construir.
Los errores en la especificación del producto son los mas costosos porque afectan a todas las siguientes actividades.Uno de nuestros objetivos es dejar en claro lo que es ambiguo.colectar y describir de manera uniforme de que es responsable nuestro software.Nos esforzamos por entender donde termina nuestro software, donde comienza el entorno y que funciones debe realizar.

Usage descriptions.
UML Define a un Actor como algo o alguien fuera del sistema que interactua con el. Estos tienden a estar agrupados en tres diferentes campos:
-Usuarios
-Administradores
-Proframadores externos y devices
Y tienen dos caracteristicas comunes:
-Son externos a la aplicación
-Ellos interactuan con nuestro sistema.

Se utilizan 3 formas de casos de uso: Textos simples narrativos, escenarios con pasos numerados y conversaciones que enfatizan el dialogo entre el usuario y el sistema.Las conversaciones describen la interaccion entre el usuario y el software como un dialogo.

Conceptual Objects
A medida que realizamos actividades de diseño mas detalladas, nuestros objetos van a ir teniendo caracteristicas mas relacionadas con computers y apareceran mas extraterrestres para los demas.Core del software:Nuestro soft necesita un núcleo solido. Esto puede entenderse de varias formas:Objetos, conceptos y procesos clave.Objetos que implementan algoritmos complejosInfraestructura tecnica.Objetos que administran tareas de la aplicaciónObjetos de interface de usuario.

CRC Cards
Las ideas principales sobre los objetos candidatos se guardan en CRC Cards.donde podemos definir datos acerca de nuestros objetos, como son chicas y no estan en la computadora se pueden ordenar fácilmente sobre una mesa y ver de distintas forma pero al mismo tiempo.

No comments: