Preparar la implementación
Comprender la tarea o el problema
Antes de empezar con una tarea de implementación, el implementador debe tener claro el ámbito, tal como se especifica
en las asignaciones de trabajo o en los planes de iteración. Una tarea de implementación puede centrarse en obtener
alguna funcionalidad específica (por ejemplo, implementar una realización de guión de uso de diseño o solucionar un
defecto) que implica varios elementos de diseño que contribuyen a esa funcionalidad. O bien, una tarea de
implementación puede centrarse en un determinado elemento de diseño, por ejemplo, un subsistema de diseño o una clase
de diseño, e implementarlo según sea necesario para la iteración actual.
Configurar el entorno de desarrollo
Esta tarea da como resultado la creación o la actualización de uno o varios archivos (elementos de implementación).
Como parte de la preparación de la implementación, el implementador debe garantizar que su entorno de desarrollo esté
configurado correctamente para que estén disponibles las versiones correctas de los elementos que se van a actualizar y
los otros elementos necesarios para la compilación y la prueba de unidad. El implementador debe tener en cuenta la
configuración del proyecto y los procedimientos de gestión de cambios, donde se describen cómo se controlan los
cambios, cómo se crean las versiones y cómo se entregan para su integración.
Analizar la implementación existente
Antes de implementar una clase desde cero, observe si hay código existente que se pueda reutilizar o adaptar. Conocer
cómo se adecua la implementación a la arquitectura y al diseño del resto del sistema permite al implementador
identificar las oportunidades de reutilización y garantiza que la implementación se adapte al resto del sistema.
Implementación incremental
Se recomienda realizar una implementación incremental; compile, enlace y ejecute pruebas de regresión varias veces al
día. Es importante recordar que no todas las operaciones públicas, atributos y asociaciones se definen durante el
diseño.
Cuando trabaje con defectos, asegúrese de que ha solucionado el problema, no el síntoma; el objetivo debe ser
solucionar el problema subyacente en el código. Realice los cambios uno a uno; como la resolución de errores es una
tarea propensa a errores, es importante realizar una implementación incremental de los arreglos, para facilitar la
ubicación de las nuevas anomalías.
El implementador debe tener en cuenta las directrices de implementación específicas del proyecto, incluidas las
directrices de programación de los lenguajes de programación específicos.
|
Transformar diseño en implementación
Existen varias técnicas para transformar el diseño en implementación. Estos son algunos ejemplos:
-
Se pueden utilizar modelos visuales específicos de la plataforma para generar una infraestructura de código
inicial. Esta infraestructura de código se puede elaborar con código adicional no especificado en el diseño.
-
Se pueden detallar modelos y utilizarlos para generar prototipos ejecutables. Se pueden utilizar diagramas de
estructura (diagramas de clase y de paquete) y de comportamiento (diagramas de estado y de actividad) para generar
código ejecutable. Estos prototipos se pueden perfeccionar según sea necesario.
-
Un modelo también se puede detallar hasta que represente completamente la implementación. En este caso, en lugar de
transformar un diseño abstracto en una implementación de código, se toma el diseño y se añaden detalles de
implementación directamente al modelo.
-
El diseño puede ser independiente de la plataforma en distinto grado. Se pueden generar modelos de diseño (o
incluso código) específicos de la plataforma mediante transformaciones que apliquen varias reglas para
correlacionar elementos específicos de la plataforma de abstracciones de alto nivel. Este es el objetivo de la
iniciativa Arquitectura dirigida por modelos (MDA) del Grupo de gestión de objetos (OMG) (http://www.omg.org).
-
También se pueden aplicar patrones estándar para generar elementos de código y diseño a partir de implementaciones
y diseños relacionados. Por ejemplo, se puede aplicar un patrón de transformación estándar a una tabla de datos
para crear clases java para acceder a la tabla de datos. Otro ejemplo es la utilización de un modelo de la
Infraestructura de modelado de eclipse (http://www.eclipse.org/emf/) para generar código para almacenar datos que coincidan con el
modelo y generar una implementación de interfaz de usuario para rellenar los datos.
No obstante, en todos los casos, se detalla alguna abstracción de diseño para convertirse en implementación, ya sea
manualmente o mediante la aplicación de alguna transformación automatizada.
|
Completar la implementación
Tal como se ha descrito en el paso anterior, la transformación de diseño en implementación puede dar como resultado
varios grados de completitud de la implementación. Puede que sea una implementación completa y aceptable. Sin embargo,
normalmente se requiere un esfuerzo considerable para completar la implementación, por ejemplo:
-
Ajustar los resultados de la transformación (por ejemplo, para mejorar el rendimiento o para mejorar la interfaz de
usuario)
-
Añadir detalles que faltan, por ejemplo:
-
completar las operaciones descritas en el diseño: elegir algoritmos y escribir el código.
-
añadir clases, operaciones y estructura de datos de soporte adicionales
|
Evaluar la implementación
Aquí es donde se verifica que la implementación se adecua a su objetivo. Además de las pruebas (descritas en
otras tareas), se pueden realizar algunas otras comprobaciones:
-
Lea mentalmente el código. Mantenga una lista de comprobación personal de los errores comunes que comete
normalmente en las implementaciones y busque dichos errores.
-
Utilice herramientas para buscar errores de código. Por ejemplo, un comprobador de regla de código estático o un
compilador establecido con el nivel de aviso detallado.
-
Utilice herramientas que puedan visualizar el código. La visualización del código puede ayudar a un implementador a
identificar patrones como, por ejemplo, un exceso de acoplamiento, dependencias circulares, etc.
|
Proporcionar información de retorno al diseño
A medida que se implementan y se prueban los diseños, se pueden descubrir errores inevitables, por ejemplo, errores que
afectan al diseño. Si una abstracción de diseño se mantiene para futuros esfuerzos de mantenimiento, o por motivos
contractuales o de comunicación, el diseño se tiene que actualizar.
Cómo se haga dependerá de la configuración y el proceso de gestión de cambios del proyecto. Generalmente, si el cambio
necesario es pequeño y la misma persona diseña e implementa la clase, no hay necesidad de una solicitud de cambio
formal. La persona puede realizar el cambio en el diseño.
Si el cambio necesario tiene un impacto mayor, por ejemplo, un cambio en una operación pública, deberá enviar una
solicitud de cambio formal.
|
|