Taller de Desarrollo de Sistemas Fase de Programacion

TALLER DE DESARROLLO DE SISTEMAS
ICI - 543
FASE DE
IMPLEMENTACIN/PROGRAMACIN
LAURA GRIFFITHS
l.griffiths.m@gmail.com
1 Semestre 2015
Taller de Desarrollo de Sistemas
Proceso de Desarrollo de SW
Anlisis de
requisitos
Especificacin
De requisitos
Diseo y
Arquitectura
Programacin
Documentacin
Mantencin (correctiva/evolutiva)
Prueba
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:
Intente la reutilizacin primero:
1.
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!
Cumpla los propsitos:
2.
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!!!!

programacin
Ejemplos:
Eclipse, Netbeans, Jbuilder

Devcpp, CodeBlocks
Aptana, PHPEd, Eclipse PDT, phpDesigner
Etc.

programacin
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

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Taller de Desarrollo de Sistemas Fase de Programacion

Загружено:

Авторское право:

Доступные форматы

TALLER DE DESARROLLO DE SISTEMAS

Taller de Desarrollo de Sistemas

Taller de Desarrollo de Sistemas

Propsito : satisfacer requisitos de la manera especificada en diseo

Se deben revisar los documentos anteriores al diseo, para

Taller de Desarrollo de Sistemas

Herramientas para la programacin

Calidad de la programacin (Inspecciones)

Taller de Desarrollo de Sistemas

1.1 Estilos de Programacin

La programacin no debe ser simplemente escribir cdigo fuente

El programador debera estar seguro de la precisin del programa

Crear cdigo correcto (apropiado para los requisitos establecidos) es

Taller de Desarrollo de Sistemas

1.1 Estilos de Programacin

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

Taller de Desarrollo de Sistemas

1.1 Estilos de Programacin

Completar el diseo detallado (lo que faltaba.)

Inspeccionar el diseo (revisarlo!!!)

Escribir el cdigo - no compilar todava!

Inspeccionar el cdigo - no compilar todava!

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

Inspeccionar el cdigo nuevamente

Probar el cdigo (pruebas unitarias)

Taller de Desarrollo de Sistemas

1.1 Estilos de Programacin

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

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

Cumpla los propsitos:

Si el cdigo debe usarse de una manera particular, escrbalo para que no

Debera estar claro Cmo utilizarn el cdigo otras partes de la

Taller de Desarrollo de Sistemas

1.1 Estilos de Programacin

Taller de Desarrollo de Sistemas

1.1 Estilo de Programacin

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

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

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

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin

El uso de convenciones mejora :

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin

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.

Si distribuimos cdigo fuente como un producto, necesitamos asegurarnos que esta

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin

Longitud de lnea : no ms de 80 caracteres.

Despus de una coma,

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin

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

De documentacin : tambin denominados "comentarios javadoc", se utilizan para

Taller de Desarrollo de Sistemas

1.2. Estndares de programacin