Académique Documents
Professionnel Documents
Culture Documents
ICI - 543
FASE DE
IMPLEMENTACIN/PROGRAMACIN
LAURA GRIFFITHS
l.griffiths.m@gmail.com
1 Semestre 2015
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
1. Implementacin del SW
Temario
Estilos de programacin
Estndares de programacin
2.
3.
4.
5.
6.
7.
1.
2.
Fcil de leer
Fcil de comprender
Bien documentado:
Con comentarios!
Con ejemplos si es necesario!
Convenciones de codificacin)
La disciplina de la programacin
La legibilidad del programa
La portabilidad del programa
La mantenibilidad del programa
Las convenciones de cdigo mejoran la lectura del SW, permitiendo entender cdigo
nuevo mucho ms rpido y ms profundamente.
Para que funcionen las convenciones, cada persona que escribe SW debe seguirla!!!
(NO SOMOS LA EXCEPCIN!!!)
La indentacin
Los comentarios
Las declaraciones
Las sentencias
Espacios en blanco
Para la nomenclatura de identificadores
Sangra: 4 caracteres.
2 tipos de comentarios:
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
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.
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.
Las lneas y espacios en blanco mejoran la legibilidad del cdigo permitiendo identificar
las secciones de cdigo relacionadas lgicamente.
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.
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.
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 "_".
Compilar / Interpretar
Ejecutar
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?
Es necesario?
Es apropiado el nombre?
Es tan privado como puede ser?
Es tan independiente como puede ser?
Hay una estrategia de inicializacin?
Es necesario el constructor?
Inicializa todos los atributos?
Es tan privado como es posible?
Ejecuta los constructores heredados?
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?
Problemas de clculo:
Ecuaciones incorrectas
Problemas de interfaz:
Problemas de datos:
Problemas de documentacin
Incumplimiento de estndares
Problemas de interoperabilidad
Cdigo fuente
Notas de defectos:
Tipo