Pensar en C++ (Volumen 1) - Grupo ARCO

Pensar en C++ (Volumen 1) - Grupo ARCO Pensar en C++ (Volumen 1) - Grupo ARCO

arco.esi.uclm.es
from arco.esi.uclm.es More from this publisher
13.01.2015 Views

✐ ✐ ✐ “Volumen1” — 2012/1/12 — 13:52 — page 24 — #62 ✐ Capítulo 1. Introducción a los Objetos 2. Montaje de objetos. Si está construyendo un objeto descubrirá la necesidad de nuevos miembros que no aparecen durante la fase de descubrimiento. Las necesidades internas del objeto pueden requerir otras clases que le den soporte. 3. Construcción del sistema. Una vez más, pueden aparecer más requisitos para un objeto a lo largo de esta etapa. Conforme aprende, evoluciona sus objetos. La necesidad de comunicación e interconexión con otros objetos en el sistema puede cambiar las necesidades de sus clases o requerir clases nuevas. Por ejemplo, puede descubrir la necesidad de clases utilería o ayudantes (helper), como una lista enlazada, que contienen o no una pequeña información de estado y que simplemente ayudan a la función de otras clases. 4. Extensión del sistema. Cuando añada nuevas características a un sistema puede descubrir que su diseño previo no soportaba extensiones sencillas del sistema. Con esta nueva información, puede reestructurar partes del sistema, posiblemente añadiendo nuevas clases o jerarquía de clases. 5. Reutilización de objetos. Esta es la verdadera prueba de estrés para una clase. Si alguien intenta reutilizarla en una situación completamente nueva, probablemente descubrirá algunos defectos. Si cambia una clase para adaptarla a nuevos programas, los principios generales de la clase se verán más claros, hasta que consiga un tipo verdaderamente reutilizable. Sin embargo, no espere que muchos objetos del diseño de un sistema sean reutilizables -es perfectamente aceptable que la mayor parte de los objetos sean específicos para el sistema. Los tipos reutilizables tienden a ser menos comunes, y deben resolver problemas más generales para ser reutilizables. Directrices para desarrollo de objetos Estas etapas sugieren algunas directrices cuando se piensa sobre el desarrollo de clases: 1. Permita que un problema específico dé lugar a una clase, después deje que la clase crezca y madure durante la solución de otros problemas. 2. Recuerde, descubrir las clases que necesita (y sus interfaces) supone la mayor parte del diseño del sistema. Si ya tenía esas clases, será un proyecto fácil. 3. No se esfuerce por saber todo desde el principio; aprenda conforme avanza. Ocurrirá así de todos modos. 4. Comience a programar; consiga tener algo funcionando para poder aprobar o desaprobar su diseño. No tenga miedo a que acabe haciendo código procedural espagueti -las clases dividen el problema y ayudan a controlar la anarquía y la entropía. Las clases malas no estropean las buenas. 5. Manténgalo simple. Pequeños objetos claros con utilidades obvias son mejores que grandes interfaces complicadas. Cuando aparezcan los puntos de decisión, aplique el principio de la Navaja de Occam: Considere las alternativas y elija la más simple, porque las clases simples casi siempre son mejores. Empiece con clases pequeñas y sencillas, y podrá ampliar la interfaz cuando la entienda mejor, pero cuando esto ocurra, será difícil eliminar elementos de la clase. 24 ✐ ✐ ✐ ✐

✐ ✐ ✐ “Volumen1” — 2012/1/12 — 13:52 — page 25 — #63 ✐ 1.9. Análisis y diseño 1.9.4. Fase 3: Construir el núcleo Esta es la conversión inicial desde el diseño rudo al cuerpo del código compilable y ejecutable que se puede probar, y que aprobará y desaprobará su arquitectura. No es un proceso en un solo paso, más bien es el principio de una serie de pasos que iterativamente construirán el sistema, como verá en la fase 4. Su objetivo es encontrar el núcleo de la arquitectura de su sistema que hay que implementar para generar un sistema funcional, sin importar lo incompleto que esté el sistema en la pasada inicial. Está creando una estructura que se puede construir con más iteraciones. También está llevando a cabo la primera de muchas integraciones del sistema y pruebas, y dando a los clientes realimentación sobre cómo serán y cómo progresan sus sistemas. Idealmente, también expone algunos de los riesgos críticos. Probablemente descubrirá cambios y mejoras que se pueden hacer en la arquitectura original - cosas que podría no haber aprendido sin implementar el sistema. Parte de la construcción del sistema es la dosis de realidad que se obtiene al probar su análisis de requisitos y su especificación del sistema (existe de cualquier forma). Asegúrese de que sus pruebas verifican los requisitos y los casos de uso. Cuando el núcleo de su sistema sea estable, estará preparado para progresar y añadir más funcionalidad. 1.9.5. Fase 4: Iterar los casos de uso Una vez que la estructura del núcleo está funcionando, cada conjunto de características que añade es un pequeño proyecto en sí mismo. Añada una colección de características durante cada iteración, un periodo razonablemente corto de desarrollo. ¿Cómo de grande es una iteración Idealmente, cada iteración dura unas tres semanas (puede cambiar dependiendo del lenguaje de implementación). Al final de ese periodo, tendrá un sistema probado e integrado con más funcionalidades de las que tenía antes. Pero lo que es particularmente interesante son las bases de la iteración: un único caso de uso. Cada caso de uso es un paquete de funcionalidades relacionadas que se puede construir en su sistema de una vez, a lo largo de una iteración. No sólo le da una mejor idea de qué alcance debería tener, también le da más valor a la idea un caso de uso, ya que el concepto no se descarta después del análisis y diseño, sino que es una unidad fundamental de desarrollo durante el proceso de construcción de software. Se deja de iterar cuando se consigue la funcionalidad deseada o se acaba el plazo impuesto y el cliente está satisfecho con la versión actual. (Recuerde, el software es una subscripción de negocios). Como el proceso es iterativo, tiene muchas oportunidades para enviar un producto en lugar de un simple punto final; los proyectos de software libre trabajan exclusivamente en un entorno iterativo con alta realimentación, que es precisamente la clave de su éxito. Un proceso de desarrollo iterativo es valioso por muchas razones. Puede mostrar y resolver pronto riesgos críticos, los clientes tienen abundantes oportunidades de cambiar sus opiniones, la satisfacción del programador es más alta, y el proyecto puede dirigirse con más precisión. Pero un beneficio adicional importante es la realimentación para los clientes, los cuales pueden ver en el estado actual del producto exactamente donde se encuentra todo. Esto puede reducir o eliminar la necesidad de abrumadoras reuniones de control y aumentar la confianza y el apoyo de los clientes. 25 ✐ ✐ ✐ ✐

✐<br />

✐<br />

✐<br />

“Volum<strong>en</strong>1” — 2012/1/12 — 13:52 — page 25 — #63<br />

✐<br />

1.9. Análisis y diseño<br />

1.9.4. Fase 3: Construir el núcleo<br />

Esta es la conversión inicial desde el diseño rudo al cuerpo del código compilable<br />

y ejecutable que se puede probar, y que aprobará y desaprobará su arquitectura. No<br />

es un proceso <strong>en</strong> un solo paso, más bi<strong>en</strong> es el principio de una serie de pasos que<br />

iterativam<strong>en</strong>te construirán el sistema, como verá <strong>en</strong> la fase 4.<br />

Su objetivo es <strong>en</strong>contrar el núcleo de la arquitectura de su sistema que hay que<br />

implem<strong>en</strong>tar para g<strong>en</strong>erar un sistema funcional, sin importar lo incompleto que esté<br />

el sistema <strong>en</strong> la pasada inicial. Está creando una estructura que se puede construir<br />

con más iteraciones. También está llevando a cabo la primera de muchas integraciones<br />

del sistema y pruebas, y dando a los cli<strong>en</strong>tes realim<strong>en</strong>tación sobre cómo serán<br />

y cómo progresan sus sistemas. Idealm<strong>en</strong>te, también expone algunos de los riesgos<br />

críticos. Probablem<strong>en</strong>te descubrirá cambios y mejoras que se pued<strong>en</strong> hacer <strong>en</strong><br />

la arquitectura original - cosas que podría no haber apr<strong>en</strong>dido sin implem<strong>en</strong>tar el<br />

sistema.<br />

Parte de la construcción del sistema es la dosis de realidad que se obti<strong>en</strong>e al probar<br />

su análisis de requisitos y su especificación del sistema (existe de cualquier forma).<br />

Asegúrese de que sus pruebas verifican los requisitos y los casos de uso. Cuando<br />

el núcleo de su sistema sea estable, estará preparado para progresar y añadir más<br />

funcionalidad.<br />

1.9.5. Fase 4: Iterar los casos de uso<br />

Una vez que la estructura del núcleo está funcionando, cada conjunto de características<br />

que añade es un pequeño proyecto <strong>en</strong> sí mismo. Añada una colección de<br />

características durante cada iteración, un periodo razonablem<strong>en</strong>te corto de desarrollo.<br />

¿Cómo de grande es una iteración Idealm<strong>en</strong>te, cada iteración dura unas tres semanas<br />

(puede cambiar dep<strong>en</strong>di<strong>en</strong>do del l<strong>en</strong>guaje de implem<strong>en</strong>tación). Al final de<br />

ese periodo, t<strong>en</strong>drá un sistema probado e integrado con más funcionalidades de las<br />

que t<strong>en</strong>ía antes. Pero lo que es particularm<strong>en</strong>te interesante son las bases de la iteración:<br />

un único caso de uso. Cada caso de uso es un paquete de funcionalidades<br />

relacionadas que se puede construir <strong>en</strong> su sistema de una vez, a lo largo de una iteración.<br />

No sólo le da una mejor idea de qué alcance debería t<strong>en</strong>er, también le da más<br />

valor a la idea un caso de uso, ya que el concepto no se descarta después del análisis<br />

y diseño, sino que es una unidad fundam<strong>en</strong>tal de desarrollo durante el proceso de<br />

construcción de software.<br />

Se deja de iterar cuando se consigue la funcionalidad deseada o se acaba el plazo<br />

impuesto y el cli<strong>en</strong>te está satisfecho con la versión actual. (Recuerde, el software es<br />

una subscripción de negocios). Como el proceso es iterativo, ti<strong>en</strong>e muchas oportunidades<br />

para <strong>en</strong>viar un producto <strong>en</strong> lugar de un simple punto final; los proyectos de<br />

software libre trabajan exclusivam<strong>en</strong>te <strong>en</strong> un <strong>en</strong>torno iterativo con alta realim<strong>en</strong>tación,<br />

que es precisam<strong>en</strong>te la clave de su éxito.<br />

Un proceso de desarrollo iterativo es valioso por muchas razones. Puede mostrar<br />

y resolver pronto riesgos críticos, los cli<strong>en</strong>tes ti<strong>en</strong><strong>en</strong> abundantes oportunidades<br />

de cambiar sus opiniones, la satisfacción del programador es más alta, y el proyecto<br />

puede dirigirse con más precisión. Pero un b<strong>en</strong>eficio adicional importante es la realim<strong>en</strong>tación<br />

para los cli<strong>en</strong>tes, los cuales pued<strong>en</strong> ver <strong>en</strong> el estado actual del producto<br />

exactam<strong>en</strong>te donde se <strong>en</strong>cu<strong>en</strong>tra todo. Esto puede reducir o eliminar la necesidad de<br />

abrumadoras reuniones de control y aum<strong>en</strong>tar la confianza y el apoyo de los cli<strong>en</strong>tes.<br />

25<br />

✐<br />

✐<br />

✐<br />

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!