5.4 MODELO DE IMPLEMENTACIN.

DEFINICIN DE IMPLEMENTACION DE UNIDADES

La implementacin se refiere a programacin. Unidad se refiere a la parte ms
pequea de la implementacin a la que se dar mantenimiento por separado y
puede ser un mtodo individual o una clase.
METAS DE IMPLEMENTACIN
El propsito de la implementacin es satisfacer los requerimientos de la manera
que especifica el diseo detallado. Aunque el diseo detallado debe ser suficiente
como documento contra el que se programa, es comn que el programador
examine todos los documentos, para ayudar a disminuir las inconsistencias entre
documentos.


1.- Los estndares de codificacin se identifican de manera que el cdigo fuente
tenga una apariencia comn.
2.- La arquitectura determina cules son el marco de trabajo y los paquetes de
aplicacin. Cada clase de cada paquete se implementa codificando los mtodos
determinados por los requerimientos y el diseo detallado. Los paquetes de marco
de trabajo se requieren antes de poder construir los paquetes de aplicacin.
3.- Cada clase se inspecciona tan pronto est lista.
4.- Cada clase se prueba como se describe.
5.- Los paquetes o clases se liberan para la integracin en la aplicacin que surge.
Una manera de preparar la implementacin
1. Confirmar los diseos detallados que deben implementarse
Slo cdigo a partir de un diseo escrito.
Mapa conceptual para la implementacin
2. Preparar la medicin del tiempo dedicado, clasificado por:
Diseo detallado residual; revisin del diseo detallado; codificacin;
revisin del cdigo; compilacin y reparacin de defectos de sintaxis;
pruebas de unidades y reparacin de defectos encontrados en las
pruebas.
3. Preparar para registrar los defectos usando una forma
Severidad: importante (requerimiento no satisfecho), trivial o ninguno
Tipo: error, nombre, entorno, sistema, datos, otros
4. Comprender los estndares requeridos
Para codificacin
Para la documentacin personal que debe guardar
5. Estimar el tamao y el tiempo con base en sus datos anteriores
6. Planear el trabajo en segmentos de 100 lneas de cdigo.







IMPLEMENTACIN EN EL PROCESO UNIFICADO DE DESARROLLO DE
SOFTWARE
El proceso unificado de desarrollo de software (USDP) considera la
implementacin como otro modelo (junto con el modelo de casos de uso, el
modelo de pruebas, etctera). Aunque las partes del diseo deben corresponder lo
ms fielmente posible a las del sistema de archivos fsicos, tal vez no sea prctico
un simple mapeo. Por ejemplo, varias clases pueden corresponder a un archivo y
los artefactos y versiones comprimidas como archivos JAR. El modelo de
implementacin muestra la organizacin de los artefactos fsicos programados, y
el mapeo de los elementos de diseo en ellos.
El modelo de implementacin consiste en subsistemas anidados. Estos contienen
componentes como archivos e interfaces de implementacin.









LENGUAJE DE PROGRAMACIN
Existen una gran variedad de lenguajes de programacin que van desde los
especializados (como lenguajes de pruebas de hardware) a los generales de
orden superior como C++, Java y COBOL. Solo el desarrollo del internet involucra
una cantidad amplia de lenguajes. Los lenguajes OO son los que apoyan esos
principios de manera ms directa. Los lenguajes meta previstos para la aplicacin
influyen en su diseo. Por ejemplo, quizs sea preferible disear de una forma
funcional, de arriba hacia abajo, si se usan lenguajes como C, aun cuando los
diseos orientados a objetos pueden aplicarse en C, hasta cierto punto. Algunos
lenguajes, como Javascript y las primeras versiones de Visual Basic, estn
basados en objetos, y dan a los programadores la posibilidad de encapsular y
agregar, pero no de heredar.
PROGRAMACIN Y ESTILO
La imagen popular de la programacin como el acto de someter material teclado a
un compilador es solo una pequea parte de la imagen. La meta real de la
ingeniera de software es crear el cdigo correcto (es decir, justo el apropiado para
los requerimientos), pero los compiladores solo pueden verificar la sintaxis y
generar un cdigo objeto. Lo correcto es responsabilidad humana. Por lo tanto, es
Implementacin en el proceso unificado
Partes del modelo de implementacin en el proceso
unificado
esencial que el profesional este convencido por completo de la exactitud del
cdigo antes de someterlo a compilacin. Aunque en principio es posible compilar
primero y verificar que sea exacto o correcto despus, estos es tan poco efectivo
como corregir la sintaxis de una carta antes de estar seguro que expresa el
pensamiento adecuado. Ms aun, los programadores tienden a omitir la
verificacin exhaustiva del cdigo de programa una vez que compila sin errores
(de sintaxis).
A continuacin se indican los pasos que pueden seguir los programadores; esta
seccin describe consejos tpicos para el estilo de programacin.
Una manera deimplementar el cdigo, 1 de 2.
1. Planear la estructura y el diseo residual para el cdigo (complete los
diseos detallados que faltan, si los hay)
Note las precondiciones y pos condiciones
Registre el tiempo dedicado
2. Auto inspeccione su diseo y/o estructura
Observe tiempo dedicado, tipos de defectos, fuente (etapa) y
severidad
3. Teclee su cdigo
No compile todava
Intente los mtodos enumerados a continuacin
Aplique estndares requeridos
Codifique de manera que la verificacin sea sencilla
Use mtodos formales si es apropiado

Una manera deimplementar el cdigo, 2 de 2.
4. Autoinspeccione el cdigo; no complique todava
Asegure sus cdigo realiza el trabajo requerido
El compilador nunca har esto por usted, solo verificara la sintaxis !
Registre el tiempo dedicado, defectos encontrados, tipo, fuente y
severidad.
5. Compile su cdigo
Repare los defectos de sintaxis
Registre tiempo dedicado, tipo de defectos, severidad y lneas de
cdigo
6. Pruebe su cdigo
Aplique los mtodos de prueba de unidades.


1. INTENTE EL REUSO PRIMERO
2. CUMPLA LOS PROPOSITOS
Si su cdigo debe usarse solo de manera particular, escrbalo de modo que no se
pueda usar de ninguna otra forma.

PRINCIPIOS GENERALES DE UNA IMPLEMENTACIN ACERTADA
1. Se ha resaltado la necesidad de disear las propias aplicaciones de manera
que permitan el reus de las componentes que se construyen. Con el mismo
nimo, es muy recomendable considerar el reus de cdigo existente
confiable, antes de escribir su propio. Por ejemplo, considere usar
componentes GUI de Java Swing o un Java Bean antes de desarrollar su
propia interfaz grfica. Una bsqueda rpida en internet de las componentes
de reus casi siempre es una inversin que vale la pena.
2. Si tiene en mente un propsito de como otras partes de la aplicacin deben
usar el cdigo que est desarrollando, entonces trate de cumplir con esta
intencin. El autor llama a interfaces de usuario, donde no se permite al
usuario introducir datos ilegales. Sin embargo, se hace hincapi en ello para
el procesamiento interno. El principio de cumplir las intenciones es anlogo
a construir curvas e islas en las carreteras para dirigir el transito justo por las
trayectorias que deseaban los ingenieros de trnsito, y no por otras. Este
cumplimiento de intenciones hace a las carreteras ms seguras y se extiende
a cada rama de la ingeniera. A continuacin se presentan ejemplos del
principio de cumplir las intenciones en ingeniera de software.
Use calificaciones como final, const en C++,y abstrac para cumplir
las intenciones correspondientes. Las clases final no pueden ser
heredadas; los mtodos final no pueden dominar a las clases
heredadas; el valor de las variables de final no puede cambiarse. Si
esto ocasiona errores de compilacin, significa que todava no se
comprende bien su programa, y no hay danos. Lo que se quiere
evitar en especial son los errores durante la ejecucin.
Hagan que las constantes, variables y clases sean ms locales
posibles. Por ejemplo, defina contadores de ciclos dentro de los
ciclos, no les d una alcance mayor.
Use el patrn de diseo Solitario si debe haber una sola instancia de
una clase.
En trminos generales, haga que los miembros sean inaccesibles si
no hay una intencin especfica de tener acceso directo a ellos.
Los atributos deben ser privados (private). Se llega a ellos a travs
de funciones de acceso ms pblicas, si se requiere. (En Java, los
atributos protegidos)(proteced) proporcionan a los miembros de una
subclase acceso a los miembros de sus clases base, lo que con
frecuencia es indeseable).
Los mtodos deber ser private si son solo uso por mtodos de la
misma clase.
Incluya ejemplos en la documentacin. Los programadores suelen
dudar al hacer esto, pero los ejemplos pueden ayudar mucho a
lector. El caso de estudio proporciona un ejemplo en los comentarios
para el mtodo ajustarCualidad{} de la clase juegoEncuentro.
Enumere los mtodos en orden alfabtico en lugar de intentar
encontrar una orden de llamada entre ellos. Algunos programadores
prefieren agrupar en mtodos privados, protegidos y pblicos, y
despus hacer subgrupos de mtodos estticos y no estticos. (El
caso de estudio no sigue esta prctica).
INDICADORES Y REFERENCIAS
Las siguientes sugerencias se tomaron de Horstmann[Ho3].
Evite usar parmetros apuntadores en C++, use referencias en su lugar.

Nunca regrese un apuntador a una nueva localidad de memoria en C++.
Esto tiene el efecto de referir a la memoria que queda inusable en adelante,
y coloca la carga de reclamar el espacio sobre el programador.

Recolecte su basura (C++); use delete{} para objetos que ya no se
necesitan. La falla en los programas en C++ permiten a los programadores
asignar memoria solo a travs de funciones utilitarias especficas a fin de
mejorar el control sobre el proceso de asignacin. Es decir, se evita new C
{}. Los programadores deben usar utilidades ya definidas como F::
ObtenerNuevoObjeto() para alguna clase F. tambin se dispone de
herramientas comerciales que indican las fugas de memoria potencial. La
recoleccin de basura en Java es automtica, por lo que no son posibles las
fugas de memoria de la misma manera que en C++. Sin emvbargo los
programas de Java acumulan recursos como archivos y sockets, y el
programador debe estar consciente de los recursos que su programa usa
durante la ejecucin.


FUNCIONES
Evite la bsqueda por tipo (por ejemplo, if (miObjeto instanciaDe MiClase) a
menos que sea obvio su beneficio. Use en su lugar funciones virtuales).
Evite las funciones friend de C++, excepto cuando sea obvio que los
beneficios sobrepasan las desventajas.
Tenga un cuidado especial de no sobrecargar los operadores, porque otros
que lean su programa pueden malinterpretar el significado de sus operaciones.
Por esta razn Java no permite la sobrecarga.



EXCEPCIONES
Use solo las excepciones que se debe manejar.
Si el mtodo actual no puede manejar la excepcin, debe haber un
manejador en un contexto externo que pueda hacerlo.
Si puede manejar parte de la excepcin, entonces maneje esa parte
y despus vuelva invocar la excepcin para manejarla en un contexto
externo.
Sus expectativas acerca de la aptitud de las llamadas para manejar
las excepciones que maneja debe ser razonables; de otra manera,
encuentre un diseo alternativo ya que la excepcin no manejada puede
hacer fallar las aplicaciones.
Tenga cuidado de no usar excepciones en situaciones que deben
estar sujetas a prueba. Por ejemplo, si se especifican como
precondiciones que un mtodo nunca debe llamarse con un parmetro
cuyo valor sea nulo, entonces la prueba debe verificar esto. Invocar una
excepcin que exija que el parmetro no sea nulo no debe ser una manera
rutinaria de manejar el problema.
Si debe elegir entre invocar una excepcin y continuar con los clculos,
contine si puede. Aqu la idea es que continuar una aplicacin puede
ser preferible a detenerla en casos en que las consecuencias deben
pensarse bien.

Horstmann seala varias razones por las que el constructor puede fallar.

La primera razn es un argumento equivocado; recomienda
establecer el objeto a un estado predeterminado y despus pasar por el
control a un manejador de errores.
La segunda razn es que requiera recursos no disponibles, situacin
que se maneja mejor con una excepcin, pues quiz no se pueda hacer
nada al respecto.
En especial los programadores en C++ deben preocuparse por la
memoria que quedara abandonada al invocar una excepcin en respuesta
a una falla del constructor.




MANEJO DE ERRORES

Los desarrolladores se enfrentan de manera constante con qu hacer con datos
potencial- mente ilegales.
Un ejemplo de datos ilegales es un nmero de cuenta que no corresponde a una
cuenta de banco real. Aunque se intente hacer la implementacin lo ms sencilla
posible, el mundo real no es sencillo. Una gran parte de la programacin se dirige
al manejo de errores. Un enfoque disciplinado es esencial: seleccione un enfoque,
establzcalo y asegrese de que todo el equipo los entiende y respeta. Nuestra
meta real es la prevencin de errores, y no su correccin. Utilizar un proceso bien
definido, inspeccionar las etapas, etctera, es la primera lnea de defensa
esencial. Ciertos patrones de diseo tambin pueden ayudar a prevenir errores.




















Una manera de... implementar el manejo de errores
1. Siga el proceso de desarrollo acordado; inspeccione
2. Considere introducir clases para encapsular los
valores legales de los parmetros.
constructor privado, funciones integradas para crear
instancias.
detecta muchos errores durante la compilacin.
3. Cuando los requerimientos especifican el manejo de
errores, debe implementarse segn se requiere.
use excepciones si se pasa la responsabilidad del manejo de
errores
4. Para las aplicaciones que nunca deben detenerse,
prevea todos los defectos de implementacin
posibles (como uso de predeterminados o default)
slo si la operacin desconocida es mejor que nada (poco
usual)
5. De otra manera, siga una poltica consistente para
verificar los parmetros
debe apoyarse ms que nada en buen diseo y proceso
de desarrollo.

OTROS PUNTOS DE LA PRCTICA

Antes de realizar un cambio de una variable, asegure que no hay falla al
leer el valor. En Java se exhorta a los programadores a respetar esto
porque una excepcin hace que surja un evento de lectura defectuosa;
sin embargo, la excepcin no debe ignorarse y el valor ledo debe
considerarse intil.

Ponga un cuidado especial al aplicar herencias mltiples en C++. (Java
evita estos problemas al prohibir herencias mltiples.) Por ejemplo,
cuando ambas clases padre tienen una variable con el mismo nombre,
el descendiente comn tiene dos versiones de la variable, sta es una
situacin muy confusa.

HERRAMIENTAS Y ENTORNOS PARA PROGRAMACIN
Los entornos de desarrollo interactivos (IDE, interactive development environment)
tienen un uso amplio para permitir que los programadores produzcan ms cdigo
en menos tiempo. Incluyen caractersticas de "arrastrar y dejar" (drag-and-drop)
para formar las componentes de la interfaz grfica, representaciones grficas de
los directorios, depuradores (debuggers), ayudas automticas ("wizards") y otros.
El enfoque en JavaBeans es estandarizar el cdigo fuente de modo que cualquier
entorno de desarrollo Java Bean puede manejar el cdigo fuente. Este enfoque
tiene la ventaja de no limitar a los desarrolladores a un solo IDE. La facilidad con
que los objetos COM se pueden generar ha mejorado mucho.
Los creadores de perfiles como Jprobe se pueden usar para acumular
estadsticas:

CPU acumulado y tiempo transcurrido

Tiempo dedicado a cada mtodo

Cuenta acumulada de objetos generados

Nmero de llamadas

Tiempo promedio del mtodo

Las aplicaciones deben tener alguna forma de cdigo fuente con la finalidad de
que se puedan entregar.

LA CALIDAD EN LA IMPLEMENTACIN












Una manera de... inspeccionar el cdigo II: atributos

A1. Es necesario (el atributo)?
A2. Puede ser esttico?
En realidad cada instancia necesita su propia variable?
A3. Debe ser final?
en realidad cambia su valor?
sera preferible un mtodo "llamador"?
A4. Las convenciones de nombres se aplican de manera adecuada?
A5. Es tan privado como es posible?

A6. Los atributos son tan independientes como es posible?
A7. Existe una estrategia de inicializacin integral?
en el tiempo de la declaracin?
con los constructores?
usa static()?
mezcla lo anterior?, cmo?


Una manera de inspeccionar el cdigo I: global para clases

C1. Es apropiado su nombre (de la clase)?
consistente con el requerimiento o el diseo?
suficiente especializacin / generalidad?
C2. Puede ser abstracto (para usarse slo como base)?
C3. Su ttulo describe su propsito?
C4. El ttulo hace referencia a los requerimientos o elemento de
diseo al que corresponde?
C5. Establece el paquete al que pertenece?
C6. Es tan privado como puede ser?
C7. Debe ser final (Java)?
C8. Se aplicaron los estndares de documentacin?
por ejemplo, Javadoc












C05. Ejecuta los constructores heredados cuando es necesario?


Una manera de... inspeccionar el cdigo IV: encabezados de mtodos

MH1. Es apropiado el nombre del mtodo?
es consistente con los requerimientos?
MH2. Es tan privado como es posible?
MH3. Podra ser esttico?
MH4. Debe ser finar?
MH5. El encabezado describe el propsito del mtodo?
MH6. El encabezado hace referencia a la seccin de los requerimientos y/o
diseo que satisface?
MH7. Establece todas las variantes necesarias? (vea la seccin 4)
MH8. Establece todas las precondiciones?
MH9. Establece todas las poscondiciones?
MH10. Aplica los estndares de documentacin?
MH11. Los tipos de parmetros son restringidos?


Una manera de... inspeccionar el cdigo V: cuerpo de mtodos

MB1. El algoritmo es consistente con el seudocdigo o el diagrama de flujo del
diseo detallado?
MB2. El cdigo supone slo las precondiciones establecidas?
MB3. El cdigo produce todas las poscondiciones?
MB4. El cdigo respeta la invariante requerida?
MB5. Terminan todos los ciclos?
MB6. Se observan los estndares de notacin requeridos?
MB7. Se ha verificado de manera exhaustiva cada lnea?
MB8. Estn balanceados los soportes?
MB9. Se consideran parmetros ilegales?
MB10. El cdigo regresa el tipo correcto?
MB11. El cdigo tiene comentarios amplios?
Una manera de... inspeccionar el cdigo III: constructores

CO1. Es necesario (el constructor)?
sera preferible un mtodo de fbrica?
Ms flexible
Llamadas adicionales de funciones por construccin
C02 Apoya los constructores existentes?
(una capacidad slo de Java)
C03- Inicializa todos los atributos?
C04. Es tan privado como es posible?