Arquitectura y Diseño de Un Entorno de Desarrollo

Arquitectura y diseño de un
entorno de desarrollo
Ricardo Borillo Domenech
borillo@uji.es
Índice
 Características, requisitos y arquitectura de los entornos de desarrollo actuales

 Metodologías de desarrollo: Clásicas vs Ágiles
 Herramientas de documentación y gestión del conocimiento
 Sistemas de control de versiones
 Herramientas de construcción
 Integración contínua
 Gestión de proyectos e incidencias
 Pruebas unitarias del software
 Repositorio de componentes
 Aseguramiento de la calidad: Análisis estático del codigo
 IDE para el desarrollo de aplicaciones. Conexión entre todos los elementos
Ricardo Borillo Domenech (borillo@uji.es)

Características, requisitos y arquitectura de
los entornos de desarrollo actuales
Los tres aspectos más importantes en

un equipo de desarrollo:
 Personas, personas y personas

Objetivos para el equipo humano:

 Formación:
 Todos conocen el entorno y herramientas
 Todos conocen la tecnología
 Transferencia de conocimiento de los más expertos
a los menos expertos
 Motivación:
 Todos pueden asumir tareas de innovación
 A cualquiera se le puede asignar cualquier tarea

Características del entorno:

 Equipos de trabajo de tamaño limitado
 Visión integrada de producto:
 Pautas comunes
 Reutilización de código
 Módulos específicos para cada necesidad
 Estándares de desarrollo bien definidos
(directrices a seguir)

Características del entorno:

 Diseño gráfico uniforme
 Reutilización de código: Librerias de
componentes
 Construcción de interfaces en base a pautas de
diseño y usabilidad

Objetivos:
 Producir software de calidad (sin bugs)
 Producir software mantenible y documentado
 Entorno de trabajo adecuado:
 Integrado
 Predecible
 Alto de nivel de interacción entre desarrolladores
 Propiedad colectiva del código

Arquitectura deseable:
 Separación entre desarrollo y producción
 Despliegue controlado de aplicaciones
 Compartición de código
 Registro global de bugs, tareas y mejoras
 Testeo automático de aplicaciones
 Documentación de funcionalidades y procesos

Índice


Metodologías de desarrollo: Clásicas vs
Ágiles
 No todo es blanco ni negro

 Método = Conjunto ordenado de buenas prácticas
 Metodologías clásicas:
 Análisis, diseño, implementación y pruebas
 Análisis opoyado en notaciones gráficas: DFD, E/R, UML
 Estricto, rígido y poco reactivo a cambios
 Metologías ágiles:
 Desarrollo iterativo
 El código es la base
 Ágil, dinámico y muy flexible

Ágiles
XP: eXtreme Programming

Ágiles
El Manifiesto Ágil valora:

 A los individuos y su interacción, por encima de
los procesos y las herramientas
 El software que funciona, por encima de la
documentación exhaustiva
 La colaboración con el cliente, por encima de la
negociación contractual
 La respuesta al cambio, por encima del
seguimiento de un plan
Ágiles
XP es una metodología ágil:

 Diseñada para entornos dinámicos
 Pensada para equipos pequeños (hasta 10
programadores)
 Orientada fuertemente hacia la codificación
 Énfasis en la comunicación informal, verbal

Ágiles
Programador:
 Responsable de decisiones técnicas y de construir el sistema
 Sin distinción entre analistas, diseñadores o codificadores
 En XP, los programadores diseñan, programan y realizan las pruebas
Jefe de Proyecto:
 Organiza y guía las reuniones
 Asegura condiciones adecuadas para el proyecto
Cliente:
 Es parte del equipo
 Determina qué construir y cuándo
 Establece las pruebas funcionales

Ágiles
Captura de requisitos: Historias del Usuario

(User-Stories)
 Establecen los requisitos del cliente
 Trozos de funcionalidad que aportan valor
 Se les asignan tareas de programación con un nº de horas
de desarrollo
 Las establece el cliente
 Son la base para las pruebas funcionales

Ágiles
Planificación:
 Planificación por entregas (releases)
 Se priorizan aquellas user-stories que el cliente selecciona
porque son más importantes para el negocio
 Entregas:
 Son lo más pequeñas posibles
 Se dividen en iteraciones (iteración = 2 o 3 semanas)
 Están compuestas por historias
 A cada programador se le asigna una tarea de la user-
story
Ágiles
Programación:
 La programación de tareas se realiza por parejas
 La pareja diseña, prueba, implementa e integra el
código de la tarea
 Código dirigido por las pruebas (TDD)
 Código modular, intentando refactorizar siempre que
se pueda

Ágiles
Practicas:
 El juego de la planificación
 Entregas pequeñas
 Diseño simple
 Pruebas
 Refactoring
 Programación en parejas (compartir experiencia / detectar fallos)
 Propiedad colectiva
 Cliente in situ
 Estándares de programación

Ágiles
SCRUM

Ágiles

Índice


Herramientas de documentación y gestión del
conocimiento
Requisitos:
 Formato estándar de representación
 Documentación accesible online
 Fácil modificación y mantenimiento
 Conversión a otros formatos como PDF
 Búsqueda y buena gestión del conocimiento

conocimiento
Posibles alternativas y puntos fuertes:

 Wiki:
 Sintaxis sencilla
 Herramienta online
 Multitud de herramientas (MediaWiki, Confluence,
DokuWiki)
 DocBook:
 XML
 Facilmente convertible a otros formatos

conocimiento
Wiki:

conocimiento
DocBook:

Índice


Sistemas de control de versiones
Requisitos:
 Repositorio unificado para el código
 Soporte para el versionado
 Soporte para realizar comparaciones entre
versiones
 Compartición de código entre desarrolladores
 Integrado con las herramientas de desarrollo

Tipos de repositorios:
 Centralizados (CVS o Subversion):
 Existe un repositorio centralizado con todo el
código
 Para trabajar sobre un recurso, hay que descargar
una copia local
 Los ficheros modificados hay que subirlos de nuevo
para que estén accesibles para todos
 Los desarrolladores sólo tienen en su copia local
aquellos fuentes que han solicitado del servidor

Tipos de repositorios:
 Distribuidos (GIT o Mercurial):
 No hay un repositorio central
 Todos los desarrolladores tienen su propia copia del
repositorio, con todas las versiones y toda la historia.
 Permiten que dos desarrolladores puedan compartir
cambios (sincronizarse).
 Sule haber un repositorio de fuentes que se considera
oficial o central (obtener la primera copia, versiones
probadas, backup)




Índice


Herramientas de construcción
Requisitos:
 Evitar compilación, construcción y despliegue manual
del código
 Independencia del IDE
 Flexibilidad y soporte para casi cualquier tipo de
herramienta necesaria
 Integración de las pruebas unitarias, generación de
documentación, despliegue en pre-producción,
métricas de código … Todo en uno y desde un único
sitio!!

Objetivos:
 Evitar errores
 Aplicación desplegable por cualquiera sin
conocimientos concretos de la misma
 Control automático de las dependencias
 Integración completa con el entorno
 Necesario ejecutar siempre los controles de
calidad

Ant:
 Similar a los makefiles
 Mejor para Java, aunque se puede utilizar para cualquier
lenguaje
 Proceso de construcción = Secuencia de ”targets”
 Cada ”target” realiza un paso del proceso y ejecuta unas
”tasks”
 Muchas ”tasks” ya predefinidas: Compilación, SCP,
empaquetado, etc
 Muy buena integración con Eclipse

<?xml version=”1.0”?>
<project name="MyProject" default="compile" basedir=".">
<property name="src" location="src"/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<target name="init">
<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init" description="compile the source">
<javac srcdir="${src}" destdir="${build}"/>
</target>
</project>

Maven:
 Desarrollo Java
 Todos los proyectos tienen la misma estructura y
siguien el mismo proceso de construcción: Life-cycle
 Gestión automática de dependencias
 Multitud de plugins existentes para distintas
necesidades
 Puede utilizar Ant

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
</dependency>
</dependencies>
</project>
Índice


Integración contínua
Martin Fowler:
”Continuous Integration is a software
development practice where members of a
team integrate their work frequently, usually
each person integrates at least daily - leading to
multiple integrations per day. Each integration is
verified by an automated build (including test)
to detect integration errors as quickly as possible.
Many teams find that this approach leads to
significantly reduced integration problems and
allows a team to develop cohesive software more
rapidly.”
Hudson:
 Independiente del lenguaje
 Construcción de software y monitorización de
procesos tipo CRON
 Centenares de plugins
 Responsable de generar todos los artefactos
necesarios para una aplicación:
Documentación, binarios, tests, informes,
análisis del código, etc.

Ejemplo disponible online:

 http://hudson.highsource.org/

Índice


Gestión de proyectos e incidencias
Requisitos:
 Registrar todas las posibles modificaciones que
se hagan sobre el software: Bugs, tareas,
mejoras, etc.
 Reparto de la carga entre los desarrolladores
 Planificación de versiones en nuestro software
 Histórico de aciones: Changelog. Cada tarea
añade todos los comentarios hasta que se
cierra
JIRA:
 Integración con Eclipse: Mylyn
 Interfaz altamente usable
 Muchas métricas de evolución del
proyecto
 API XML-RPC disponible




 http://jira.codehaus.org/

Índice

 IDE para el desarrollo de aplicaciones. Conexión con los distintos elementos de la
arquitectura

Pruebas unitarias del software
Unit testing Wikipedia:

”In computer programming, unit
testing is a software verification
and validation method in which
a programmer tests if individual
units of source code are fit for
use. A unit is the smallest
testable part of an application”
Beneficios:
 Facilitar el cambio y el refactoring
 Integración más sencilla
 Documentación del código
 Diseño siempre y modular del código
(sino no se puede hacer unit testing)

Tipos de pruebas:
 Unitarias o de desarrollo
 Integración
 Rendimiento o estrés
 Funcionales

import org.junit.Assert;
public class AdditionTest

{
private int x = 1;
private int y = 1;
@Test public void addition() {

int z = x + y;
Assert.assertEquals(2, z);
}
}


Herramientas:
 Pruebas de código: jUnit, Nunit,
PHPUnit, PyUnit o incluso utPLSQL

 Pruebas de interfaz: Selenium o
jWebUnit
 Pruebas de estrés: Apache JMeter

TDD Wikipedia:
”El desarrollo guiado por pruebas, o Test-driven
development (TDD) involucra otras dos prácticas:
Escribir las pruebas primero (Test First Development) y
Refactorización (Refactoring). Para escribir las pruebas
generalmente se utilizan las pruebas unitarias (unit
testing). En Primer Lugar se escribe una prueba y se
verifica que las pruebas fallen, luego se implementa el
código que haga que la prueba pase satisfactoriamente
y seguidamente se refactoriza el código escrito. El
propósito del desarrollo guiado por pruebas es lograr un
código limpio que funcione (clean code that works). La
idea es que los requerimientos sean traducidos a
pruebas, de este modo, cuando las pruebas pasen se
garantizará que los requerimientos se hayan
Otros conceptos relacionados:

 Cobertura: porcentaje de nuestro
código cubierto o probado por

nuestros tests unitarios
 Mock o impostor: Objetos que imitan
el comportamiento de objetos reales

de una forma controlada. Como un
dummy en una prueba de colisión
Índice

arquitectura

Repositorio de componentes
Objetivos:
 Repositorio Maven de artefactos
 Proxy-cache que recoge cualquier libreria utilizada
 Si necesitamos una libreria externa, nos la consigue
 Control total sobre los productos y versiones utilizadas
 Lugar único de publicación de nuestros artefactos
 Gestión integrada de librerías, control de acceso,
backup, gestión web, etc



 http://repo.jfrog.org/artifactory/webapp/home.html

Índice

 Gestión de proyectos e incidencies
arquitectura

Aseguramiento de la calidad: Análisis estático
del codigo
Análisis estático del código:

 El análisis estático del código es el proceso de
evaluar el software sin ejecutarlo
 Técnica que se aplica directamente sobre el
código fuente, sin transformaciones previas ni
cambios de ningún tipo
 Objetivo: Obtener información que nos permita
mejorar la base de código

del codigo
Objetivo. Encontrar partes del código

que puedan:
 Reducir el rendimiento
 Provocar errores en el software
 Complicar el flujo de datos
 Tener una excesiva complejidad
 Suponer un problema en la seguridad

del codigo
Algunas herramientas para Java:

 PMD. Detección de posibles errores en el
código en base a un conjunto extensible de
patrones
 CPD. Detector de ”copy & paste”.
Duplicacidades en el código que se pueden
refactorizar
 CheckStyle. Además de muy similar a PMD,
también revisa el estilo del código y que el
JavaDoc es correcto
del codigo
Algunas herramientas para Java:

 FindBugs. Detección de errores clasificados en
una serie de categorías.
 Sonar:
 Servidor que ejecuta todos los anteriores en forma
de plugins + muchos otros (cobertura, emma, etc)
 Añade estadísticas sobre complejidad, número de
clases, etc
 Integrable desde Maven

del codigo
Varios proyectos de libres analizados con Sonar:

 http://nemo.sonarsource.org/
Sona para proyectos PL/SQL:

 http://nemo.sonarsource.org/project/index/nl.oracledeveloper:utplsql
Integración de Sonar con Toad Code Xpert:

 http://www.sonarsource.com/plugins/plugin-plsql/

Índice


IDE para el desarrollo de aplicaciones
Eclipse como elemento integrador:

 Plugin Subversion
 Plugin Ant/Maven
 Plugin Mylyn integración con JIRA
 Plugin jUnit
 Plugin análisis estático del código
(PMD, Findbugs, CheckStyle, etc)

Fin
¿Preguntas?

Arquitectura y Diseño de Un Entorno de Desarrollo

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Arquitectura y Diseño de Un Entorno de Desarrollo

Hochgeladen von

Copyright:

Verfügbare Formate

Arquitectura y diseño de un

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

Los tres aspectos más importantes en

Ricardo Borillo Domenech (borillo@uji.es)

Objetivos para el equipo humano:

Ricardo Borillo Domenech (borillo@uji.es)

Características del entorno:

Ricardo Borillo Domenech (borillo@uji.es)

Características del entorno:

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

 No todo es blanco ni negro

Ricardo Borillo Domenech (borillo@uji.es)

XP: eXtreme Programming

Ricardo Borillo Domenech (borillo@uji.es)

El Manifiesto Ágil valora:

XP es una metodología ágil:

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Captura de requisitos: Historias del Usuario

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Posibles alternativas y puntos fuertes:

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

<project name="MyProject" default="compile" basedir=".">

<property name="src" location="src"/>

<property name="build" location="build"/>

<property name="dist" location="dist"/>

<target name="compile" depends="init" description="compile the source">

<javac srcdir="${src}" destdir="${build}"/>

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

<name>Maven Quick Start Archetype</name>

 Características, requisitos y arquitectura de los entornos de desarrollo actuales

Ricardo Borillo Domenech (borillo@uji.es)

Ricardo Borillo Domenech (borillo@uji.es)

Ejemplo disponible online:

Ricardo Borillo Domenech (borillo@uji.es)