taller de desarrollo de sistemas fase de programacion

TALLER DE DESARROLLO DE SISTEMAS

ICI - 543

FASE DE IMPLEMENTACIN/PROGRAMACIN

LAURA GRIFFITHS

[email protected]

1 Semestre 2015

Taller de Desarrollo de Sistemas

Proceso de Desarrollo de SW


Anlisis de requisitos

Especificacin De requisitos

Diseo y Arquitectura

Programacin Prueba

Documentacin

Mantencin (correctiva/evolutiva)

1. Implementacin del SW


Implementacin programacin

Propsito : satisfacer requisitos de la manera especificada en diseo detallado(a veces no es suficiente!)

Se deben revisar los documentos anteriores al diseo, para disminuir inconsistencias

NO OLVIDEMOS que Un SW de calidad DEBE satisfacer las

necesidades reales de los usuarios!

1. Implementacin del SW


Temario

Estilos de programacin

Estndares de programacin

Herramientas para la programacin

Calidad de la programacin (Inspecciones)

1.1 Estilos de Programacin


La programacin no debe ser simplemente escribir cdigo fuente

El programador debera estar seguro de la precisin del programa antes de COMPILARLO

Crear cdigo correcto (apropiado para los requisitos establecidos) es una de las metas de la ingeniera de software



Los compiladores verifican la sintaxis del cdigo

Escribir cdigo correcto es responsabilidad de los programadores!

En la prctica los programadores:

No siempre verifican el cdigo antes de compilarlo

No verifican en detalle el cdigo despus de compilarlo



Etapas sugeridas: 1. Completar el diseo detallado (lo que faltaba.)

2. Inspeccionar el diseo (revisarlo!!!)

3. Escribir el cdigo - no compilar todava!

4. Inspeccionar el cdigo - no compilar todava!

5. Compilar el cdigo (y corregir errores sintcticos si corresponde!!!)

6. Inspeccionar el cdigo nuevamente

7. Probar el cdigo (pruebas unitarias)

En cada etapa: registrar problemas, soluciones, tiempo requerido

(esto es lo IDEAL! / NO LO REAL!)



Principios generales en la prctica de la programacin: 1. Intente la reutilizacin primero:

Considere reutilizar cdigo existente (confiable), antes de escribir cdigo

propio (uso de cdigo, uso de APIs, uso de bibliotecas de clases)

Una bsqueda (en la web), de componentes reutilizables, (casi) siempre vale la pena!

2. Cumpla los propsitos:

Si el cdigo debe usarse de una manera particular, escrbalo para que no se pueda usar de otra forma

Debera estar claro Cmo utilizarn el cdigo otras partes de la aplicacin?



El cdigo debe ser:

Fcil de leer

Fcil de comprender

Bien documentado:

Con comentarios!

Con ejemplos si es necesario!

1.1 Estilo de Programacin


Manejo de errores:

Gran parte de la programacin est centrada en el manejo de errores

Debemos usar enfoque sistemtico elegir un enfoque, que todo el equipo lo entienda y cumpla

La meta debe ser la prevencin de errores, NO su correccin!

1.2. Estndares de programacin


Describen convenciones para escribir cdigo fuente.

En la actualidad..la mayora de los LP tiene un estndar (Guas de Estilo o

Convenciones de codificacin)

El uso de convenciones mejora :

La disciplina de la programacin

La legibilidad del programa

La portabilidad del programa

La mantenibilidad del programa



Las convenciones son importantes :

80% del costo del cdigo de un programa se gasta en mantencin.

Casi ningn SW lo mantiene (toda su vida til) el autor original.

Las convenciones de cdigo mejoran la lectura del SW, permitiendo entender cdigo nuevo mucho ms rpido y ms profundamente.

Si distribuimos cdigo fuente como un producto, necesitamos asegurarnos que esta bien hecho y presentado como cualquier otro producto.

Para que funcionen las convenciones, cada persona que escribe SW debe seguirla!!! (NO SOMOS LA EXCEPCIN!!!)



Recomendaciones generales:

Usar estndares/convenciones para:

La indentacin

Los comentarios

Las declaraciones

Las sentencias

Espacios en blanco

Para la nomenclatura de identificadores



Convenciones de indentacin en JAVA:

Sangra: 4 caracteres.

Longitud de lnea : no ms de 80 caracteres. Divisin de lneas: Cuando expresin ocupe ms de una lnea, se divide segn los siguientes criterios:

Despus de una coma,

Antes de un operador,

Se recomienda las rupturas de nivel superior a las de nivel inferior.

Alinear la nueva lnea con el inicio de la expresin al mismo nivel que la lnea anterior.

Si las reglas anteriores generan cdigo poco comprensible, entonces estableceremos tabulaciones de 8 espacios.



Convenciones de comentarios en JAVA:

2 tipos de comentarios:

De implementacin : de bloque, de lnea, al final de la lnea

De documentacin : tambin denominados "comentarios javadoc", se utilizan para describir la especificacin del cdigo, desde un punto de vista independiente de la implementacin, de forma que pueda ser consultada por desarrolladores que probablemente no tengan acceso al cdigo fuente.



Documentar las clases:

Que representa la clase

Que atributos tiene

Qu operaciones realiza

Tipo de clase (jerarqua / concreta o abstracta)



Documentar los mtodos:

Precondiciones y post-condiciones

Que hace el mtodo?

Por qu lo hace?

Que parmetros recibe?

Que excepciones lanza?

Razn para la eleccin de visibilidad (local, global/pblico,privado)

Maneras en que cambian las variables de instancias los atributos

Fallas conocidas

Descripcin de pruebas

Historia de cambios

Ejemplos de cmo trabaja el mtodo



Documentar los atributos:

Que representa el atributo?

Que valores puede tomar el atributo?

Requiere un valor inicial el atributo?



Convenciones para las declaraciones en JAVA: Una declaracin por lnea

Inicializacin : Toda variable local debe ser inicializada al declararla, excepto si su valor inicial

depende de algn valor que tenga que ser calculado.

Localizacin: Las declaraciones se ubican al principio de cada bloque en el que se usen, y nunca en el momento de

su uso. La nica excepcin a esta regla son los ndices de los bucles "for. Se debe evitar el uso de declaraciones que oculten a otras declaraciones de mbito superior.

Declaracin de clases/interfaces:

No incluir ningn espacio entre el nombre del mtodo y el parntesis inicial del listado de

parmetros. El carcter inicio de bloque ("{") debe aparecer al final de la lnea que contiene la sentencia de

declaracin. El carcter fin de bloque ("}") se sita en una nueva lnea tabulada al mismo nivel que su

correspondiente sentencia de inicio de bloque, excepto cuando la sentencia sea nula, en tal caso se situar detrs de "{".

Los mtodos se separarn entre s mediante una lnea en blanco.



Convenciones para las sentencias en JAVA:

Cada lnea debe contener como mximo una sentencia.

Las sentencias pertenecientes a un bloque de cdigo estarn tabuladas un nivel ms a la derecha con respecto a la sentencia que las contiene.

El carcter inicio de bloque "{" debe situarse al final de la lnea que inicia el bloque. El carcter final de bloque "}" debe situarse en una nueva lnea tras la ltima lnea del bloque y alineada con respecto al primer carcter de dicho bloque.

Todas la sentencias de un bloque deben encerrarse entre llaves "{ ... }", aunque el bloque conste de una nica sentencia. Esta prctica permite aadir cdigo sin cometer errores accidentalmente al olvidar aadir las llaves.



Convenciones para los espacios en blanco en JAVA:

Las lneas y espacios en blanco mejoran la legibilidad del cdigo permitiendo identificar las secciones de cdigo relacionadas lgicamente.

Se utilizarn espacios en blanco en los siguientes casos:

Entre una palabra reservada y un parntesis. Esto permite que se distingan las llamadas a mtodos de las palabras reservadas.

Tras cada coma en un listado de argumentos.

Para separar un operador binario de sus operandos, excepto en el caso del operador ("."). Nunca se utilizarn espacios entre los operadores unarios (p.e., "++" o "--") y sus operandos.

Para separar las expresiones incluidas en la sentencia "for".

Al realizar el "casting" de clases.



Convenciones para la nomenclatura de identificadores en JAVA:

Los identificadores deben ser simples y descriptivos

El prefijo del paquete siempre corresponder a un nombre de dominio de primer nivel, tal como: es, eu, org, com, net, etc. El resto de componentes del paquete se nombrarn de acuerdo a las normas internas de organizacin de la empresa: departamento, proyecto, seccin, organismo, rea, etc. Generalmente se suele utilizar el nombre de dominio de Internet en orden inverso. Cuando dicho nombre contenga un carcter "-", este se sustituir por el carcter "_.

Los nombres de clases deben ser sustantivos y tener la primera letra en maysculas. Si el nombre es compuesto, cada palabra componente deber comenzar con mausculas. Debe evitarse el uso de acrnimos o abreviaturas, salvo en aquellos casos en los que dicha abreviatura sea ms utilizada que la palabra que representa (URL, HTTP, etc.)

Las interfaces se nombrarn siguiendo los mismos criterios que los indicados para las clases. Como norma general toda interfaz se nombrar con el prefijo "I" para diferenciarla de la clase que la implementa (que tendr el mismo nombre sin el prefijo "I") ej: class IAgendaService



Los mtodos deben ser verbos escritos en minsculas. Cuando el mtodo est compuesto por varias palabras cada una de ellas tendr la primera letra en maysculas.

Las variables se escribirn siempre en minsculas. Las variables compuestas tendrn la primera letra de cada palabra componente en maysculas.

Todos los nombres de constantes tendrn que escribirse en maysculas. Cuando los nombres de constantes sean compuestos las palabras se separarn entre s mediante el carcter de subrayado "_".



Otros

Visibilidad de atributos de instancia y de clase

Atributos de instancia y de clase sern siempre privados, excepto cuando tengan que ser visibles en subclases herederas, en ese caso sern protegidos.

Acceso a los atributos de una clase se realizar por medio de los mtodos "get" y "set" correspondientes, incluso cuando el acceso a dichos atributos se realice en los mtodos miembros de la clase.

Otras prcticas (uso de parntesis en expresiones, valores de retorno .)

Nombres de programas fuentes / bibliotecas ,

Cmo Organizar contenido de programas fuentes / bibliotecas

VER DOCUMENTO Java Code Conventions

1.3. Herramientas y entornos de programacin


Los entornos de desarrollo integrado (IDE - Integrated development environment ) permiten:

Editar cdigo (muchas veces con autocompletado inteligente)

Compilar / Interpretar

Depurar (Debugger) (detectar errores , para corregir)

Ejecutar

Obtener ayuda sensitiva al contexto, Obtener ayudas automticas

(wizards)

Programacin visual de la interfaz, etc.

Algunos IDEs soportan mltiples lenguajes!!!!



Ejemplos:

Eclipse, Netbeans, Jbuilder

Devcpp, CodeBlocks

Aptana, PHPEd, Eclipse PDT, phpDesigner

Etc.



HERRAMIENTAS CASE (Computer Aided Software Engineering ):

Herramientas de ingeniera directa:

Generan cdigo fuente a partir de los modelos de objetos

Generan solamente los esqueletos del cdigo, lo cual el programador debe completar

Herramientas de ingeniera reversa:

Tienen cdigo fuente como entrada y generan una documentacin limitada

Generan modelos de objetos a partir del cdigo fuente

1.4. Calidad de la implementacin


Inspecciones de cdigo: principal objetivo mejorar la estructura del cdigo fuente

NO tiene como objetivo descubrir bugs *(de hecho se inspeccionan los

cdigos fuentes no el programa en ejecucin)

El incorporar esta fase de revisin no implica omitir la fase de testing.

Puede realizarla un equipo de inspeccin o inspector de cdigo..

[*] bugs: error o falla en un programa que genera un resultado no deseado



Inspecciones de cdigo global para clases:

Es apropiado el nombre?

Puede ser abstracta?

Describe el propsito?

Se hace referencia a los requerimientos o elemento de diseo al que corresponde?

Establece el paquete al que pertenece?

Es tan privada como puede ser?



Inspeccin de atributos:

Es necesario?

Es apropiado el nombre?

Es tan privado como puede ser?

Es tan independiente como puede ser?

Hay una estrategia de inicializacin?



Inspeccin de constructores:

Es necesario el constructor?

Inicializa todos los atributos?

Es tan privado como es posible?

Ejecuta los constructores heredados?



Inspeccin de encabezados de mtodos:

Es apropiado su nombre?

Es tan privado como es posible?

El encabezado describe el propsito del mtodo?

Se hace referencia a los requerimientos y diseo?

Establece todas las precondiciones y poscondiciones?

Los tipos de parmetros son restringidos?



Inspeccin de cuerpo de mtodos: Implementa el diseo detallado?

Supone slo las precondiciones establecidas?

Produce todas las post-condiciones?

Terminan todos los ciclos?

Se cumplen los estndares de notacin?

Se ha verificado cada lnea?

Se consideran parmetros ilegales?

El cdigo regresa el tipo correcto?

Contiene comentarios amplios?



Tipos de problemas hallados en las inspecciones de cdigo:

Problemas de lgica:

Casos o pasos olvidados

Lgica duplicada

Descuido de condiciones extremas

Funciones innecesarias

Prueba de condiciones faltantes

Verificacin de variables equivocadas

Mala interpretacin

Ciclo incorrecto, Ciclo infinito, etc.



Problemas de clculo:

Ecuaciones incorrectas

Perdida de precisin (tipos de datos) / problemas aritmticos (overflow/underflow)

Asumir prioridad errnea de operadores

Divisin por cero

Problemas de interfaz:

Interrupciones mal manejadas

Tiempo de I/O incorrecto

Mala asociacin de subrutinas (o mdulos)



Problemas de manejo de datos:

Variables mal inicializada o no inicializada

Acceso o almacenamiento de datos incorrecto

Escala o unidades de medida incorrectas

Dimensin de datos incorrecta (overflow) exceder tamao vectores

Problemas de datos:

Datos de operador incorrectos o faltantes

Datos externos incorrectos o faltantes

Datos de salida incorrectos o faltantes

Datos de entrada incorrectos o faltantes



Otros:

Problemas de documentacin

Incumplimiento de estndares

Problemas de interoperabilidad

Clasificacin de severidad de defectos:

Importante Requerimiento no satisfecho

Media

Trivial No afectar la operacin o el mantenimiento



Documentacin personal de software (DPS): Cada ingeniero debe conservar la documentacin de su trabajo

Permite reportar el estado de avance en todo momento

Parte del DPS se convierte en parte del documento de proyecto

El proceso de software personal (Personal Software Process - Software

Engineering Institute) requiere la informacin de tiempo y defectos



Elementos a incluir en DPS:

Cdigo fuente

Notas de defectos:

Tipo

Etapa personal en la que se incluy

Etapa personal en la que se elimin

Notas de tiempo tiempo dedicado a diseo detallado adicional, codificacin, compilacin, pruebas

Notas de ingeniera estado de diseo detallado adicional, del cdigo, incidentes, aspectos importantes de desarrollo



Etapas personales:

Diseo detallado adicional

Codificacin registro de defectos detectados y reparados antes de compilar

Compilacin registro de defectos detectados en el intento de compilar

Prueba unitaria

taller de desarrollo de sistemas fase de programacion

Documents