Taxonomías del software Patrones, estilos y tácticas · 2021. 3. 6. · Arquitectura del Software Escuela de Ingeniería Informática Universidad de Oviedo Taxonomías del software

Arquitectura del SoftwareE

scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Taxonomías del softwarePatrones, estilos y tácticas

Jose Emilio Labra GayoCurso 2020/2021


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Taxonomías del softwareConstrucción y mantenimiento

Gestión de configuracionesModularidad

Descomposición en tiempo de desarrolloTiempo de ejecución

Componentes y conectoresIntegraciónDisposición

Empaquetamiento, distribución, despliegueEntorno de negocio y empresa


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Construcción y mantenimiento del software

Jose E. Labra GayoCourse 2018/2019


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o Construcción y mantenimientoSoftwareGestión de configuraciones


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Software: ¿producto ó servicio?Software as a Product (SaaP):

Software entregableModelo comercial: software vendido a clientesDistribuido o descargado

Ejemplo: Microsoft OfficeSoftware as a Service (SaaS):

Software desplegadoModelo comercial: los clientes se suscribenNormalmente disponible en alguna URL

Ejemplo: Google docs


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o Gestión de configuraciones softwareGestión de la evolución del software

Gestionar los aspectos de construcción de softwareEspecialmente, evolución y cambio del software

Aspectos:Identificar líneas base (baseline) e ítems de configuración

Baseline: Un producto sujeto a gestiónContiene ítems de configuración: documentos, ficheros de

código, etc...Control y auditoria de configuraciones

Sistemas de control de versionesGestión y automatización de la construcciónTrabajo en equipo y colaboraciónSeguimiento de defectos e incidencias


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Construcción de softwareRepaso a metodologías

Tradicionales, iterativas, ágiles,...Herramientas de construcción

Lenguajes, herramientas de construcción, etc.


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Incremental piecemealCrecimiento según necesidadCodificar sin considerar la arquitecturaSoftware de usar y tirarLimitaciones presupuestarias


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Propuesto en años 70

Cascada

Análisis de requisitos

Diseño de software y sistema

Implementación y pruebas unitarias

Pruebas integración y

sistema

Despliegue y mantenimiento


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Modelo en V

Requisitos

Análisis

Diseño

DiseñoObjetos

PruebasUnitarias

PruebasIntegración

PruebasSistema

PruebasAceptación

Tiempo

Nivelde detalle

Bajo

Alto


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Big Design Up FrontAntipatrón de modelos tradicionales

Demasiada documentación que nadie leeDocumentación diferente al sistema desarrollado

Arquitectura degradadaSistemas que no son usados


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Modelos iterativos

Basado en prototiposEvaluación de riesgos

Requisitos

Análisis

Diseño

Prueba

Despliegue

Valoración

Iteración 1

Requisitos

Análisis

Diseño

Prueba

Despliegue

Valoración

Iteración 2

Requisitos

Análisis

Diseño

Prueba

Despliegue

Valoración

Iteración 3


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

RUP (Rational Unified Process)

Fuente: Wikipedia. http://es.wikipedia.org/wiki/Archivo:Rup_espanol.gif

Uno de los modelos iterativos más utilizadosProceso iterativo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ÁgilesNumerosas variantes

RAD (www.dsdm.org, 95)SCRUM (Sutherland & Schwaber, 95)XP - eXtreme Programming (Beck, 99)Feature driven development (DeLuca, 99)Adaptive software development (Highsmith, 00)Lean Development (Poppendieck, 03)Crystal Clear (Cockburn, 04)Agile Unified Process (Ambler, 05). . .


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágilesManifiesto ágil (www.agilemanifesto.org)

Individuos e interacciones sobre

Herramientas y procesos

Software quefuncione Documentaciónsobre

Colaboracióncon cliente

sobre Negociación decontrato

Responder alcambio

sobre Seguimiento deun plan


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágilesRealimentación

Ajustes constantes en el códigoMinimizar riesgo

Software en intervalos cortosIteraciones de horas o díasCada iteración pasa todo el ciclo de desarrollo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágilesAlgunas prácticas (XP)

1. Planificaciones cortas2. Pruebas 3. Programación en parejas (revisiones de código)4. Refactorización5. Diseño simple6. Propiedad de código compartida7. Integración continua8. Cliente en lugar de desarrollo9. Entregas pequeñas10.Horarios normales11.Estándares de codificación


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles

1. Planificaciones cortasDespués de cada iteración, volver a planificarRequisitos mediante historias de usuario

Descripciones breves (Tamaño tarjeta)Objetivos priorizados por clientesRiesgo y recursos estimados por desarrolladores

Historias de usuario = pruebas aceptaciónPreparación para el cambio

Plan original

Plan actual


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles2.- Utilización de pruebas

Escribir pruebas incluso antes del códigoInicialmente el código va a fallarObjetivo: pasar las pruebasResultado:

Batería de pruebas automáticas (test-suite)Facilita la refactorización


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Diferentes tipos de pruebasPruebas unitarias

Probar cada unidad separadamentePruebas de integración

Smoke testingPruebas de aceptación

Pruebas con historias de usuarioPruebas de capacidad/rendimiento

Pruebas de cargaPruebas de regresión

Chequear que los cambios nuevos no introducen nuevos errors, o regresiones


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles2.- Pruebas

Tipos de pruebas

Pruebas de aceptaciónFuncionales

DemostracionesPruebas usabilidad

Pruebas exploración

Pruebas aceptación no funcional(capacidad, seguridad,…)

Pruebas unitariasPruebas integración

Pruebas sistema

Automáticas Manuales

Automáticas Manuales/ Automáticas

Sopo

rte

al d

esar

rollo

Critica al proyecto

Dirigidas al negocio

Dirigidas a tecnología


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles

2. PruebasBehaviour-driven development (BDD)

Pruebas a partir de historias de usuarioDeben escribirse junto con cliente

Herramientas: Cucumber, JBehave, Specs2,...Sirven como contratoMiden el progreso Feature: Buscar cursos

Para mejorar el uso de los cursosLos estudiantes deberían ser capaces de buscar cursos

Scenario: Búsqueda por asuntoGiven hay 240 cursos que no tienen el asunto “Biología”And hay 2 cursos A001, B205 que tienen el asunto “Biología" When Yo busco el asunto “Biología"Then Yo debería ver los cursos:

| Código || A001 || B205 |


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles2. PruebasPrincipios FIRST

F - FastLa ejecución de pruebas debe ser rápida

I - Independent: Los casos de prueba son independientes entre sí

R - Repeatable: Tras ejecutarlos N veces, el resultado debe ser el mismo

S - Self-checkingSe puede comprobar si se cumplen automáticamente, sin

intervención humanaT - Timely

Pruebas escritos al mismo (o antes) tiempo que código


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Dobles de pruebasObjetos Dummy:

Se pasan pero no se utilizanObjetos falsos (fake):

Tienen implementación parcialStubs:

Respuestas precocinadas a ciertas preguntasEspías: son stubs que pueden registrar cierta

información para depuraciónMocks: simulan comportamiento de otros objetos

Programados con ciertas expectativas sobre qué tipo de llamadas deben recibir

Fixtures. Elementos fijos de soporte a las pruebasEj. Bases de datos con ciertas entradas, determinados

ficheros, etc.


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Entornos

Entorno de ensayo (staging) también se utiliza en ocasiones

Entorno de desarrollo

Entorno de pruebas

Entornode producción

Servidorpruebas

Servidorintegración

Controlde versiones

Servidor producciónGranja servidores


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles

3. Programación en parejas2 ingenieros software trabajan juntos en un

ordenadorEl conductor maneja el teclado y crea implementaciónEl observador identifica fallos y da ideas

Los roles se intercambian cada cierto tiempoPull requests: antes de aceptar cambios, el

código puede ser revisado


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles4. Diseño simple

Reacción a Big Design Up FrontDiseño más simple que funcione

Documentación automatizadaJavaDoc y similares


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles5. Refactorización

Mejorar diseño sin cambiar la funcionalidadSimplificar código (eliminar código duplicado)Buscar activamente oportunidades de abstracción

Pruebas de regresiónSe basa en la batería de pruebas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles6. Propiedad colectiva del código

El código pertenece al proyecto, no a un ingeniero particular

A medida que los ingenieros desarrollan, deben poder navegar y modificar cualquier claseAunque no la hayan escrito ellosEvitar fragmentos de una única persona


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles7. Integración continua

Cada pareja escribe sus propios casos de prueba y trabaja para satisfacerlosPasar 100% de casos de pruebaIntegrar

El proceso debe realizarse 1 ó 2 veces al díaObjetivo: evitar integration hell


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Integración continuaMejores prácticas:

Mantener repositorio de códigoAutomatizar la construcciónHacer que la construcción pueda probarseTodo el mundo realiza commits a línea baseTodo commit es construidoMantener la construcción rápidaProbar en una replica del entorno de producciónFacilitar la obtención de los últimos entregablesTodo el mundo puede ver los resultados de la última

construcciónAutomatizar despliegue


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Integración continuaHerramientas

Hudson, Jenkins, Travis, Bamboo

Integracióncontinua

Interfazweb

Informes

checkout/commit

Repositorio central

de código

Equipo de desarrollo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Cliente en lugar de desarrolloCliente disponible para clarificar historias de

usuarios y tomar decisiones críticas de negocioVentajas

Desarrolladores no realizan suposicionesDesarrolladores no tienen que esperar para

decisionesMejora la comunicación


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Entrega continua - continuous delivery

Pequeñas releasesTan pequeñas como sea posible ofreciendo valor

al usuarioObtener realimentación temprana del cliente

Modelos de entregaEntregar algo cada cierto tiempo (noche/semana/...)Entrega continua y automatizada

Delivery pipeline


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles10. Horarios normales

40h/semana = 40h/semanaEvitar horas extraProgramadores cansados escriben código pobre

A largo plazo ralentiza el desarrollo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles

11. Código limpioFacilitar modificación de código por otras personasUtilizar buenas prácticas

Estilos y normas de codificaciónEvitar code smells

Manifiesto software craftmanshipLibros (Robert C. Martin)Clean CodeClean architecture

Fuente: Clean Code. Robert Martin


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Métodos ágiles

VariantesScrum

Gestión de proyectos/personas

División de trabajo en sprintsReunión diaria de 15'Backlog del producto

KanbanModelo lean (esbelto)

Desarrollo Just in TimeLimitar cargas de trabajo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Gestión de configuracionesDiferentes versiones de software

Funcionalidades nuevas o diferentesCorrección de bugsNuevos entornos de ejecución

Gestión de configuraciones: gestión de la evolución del softwareCambios del sistema = actividades en equipoCostes y esfuerzo necesarios


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Control de versionesSistemas que gestionan las diferentes versiones

del softwareAcceso a todas las versiones del sistema

Facilidad para volver atrásDiferencias entre versiones

Código colaborativoFacilidad para gestión de ramificacionesMetadatos

Autor de la versión, fecha actualización, etc.


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Baseline

Baselines (línea de referencia): Software que es sometido a gestión de configuraciones.

Versión1.0

Windows

Versión1.5

Sun

Versión1.5

Linux

Versión2.0

Windows

Versión2.5 Escritorio

Linux

Versión2.5 Escritorio

Servidor


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Releases y versionesVersión: instancia de un sistema funcionalmente

distinta de otras instanciasRelease (entregable): instancia de un sistema

que es distribuida a usuarios externos al equipo de desarrollo.Puede ser considerado un producto final


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Nombres habituales de versionesPre-alfa

Antes de las pruebasAlfa

En pruebasBeta (o prototipo)

Pruebas por usuariosBeta-tester: usuario que hace pruebas

Release-candidateVersión beta que podría ser producto final


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Otros esquemas de nombres

Utilizar algunos atributosFecha, creador, lenguaje, cliente, estado,...

Nombres reconociblesGanimede, Galileo, Helios, Indigo, Juno,...Precise Pangolin, Quantal Quetzal,...

Versioneado semántico (http://semver.org)MAJOR.MINOR.PATCH (2.3.5)

MAJOR: cambios incompatibles con versión anteriorMINOR: nueva funcionalidad compatible con versión anteriorPATH: Reparación de bugs compatible con versión anterior

Versión 0 (inestable)Pre-release: 2.3.5-alpha


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Publicación de entregables

Una release supone cambios de funcionalidadPlanificación

Publicar una release no es baratoLos usuarios no suelen querer nuevas releasesFactores externos:

Marketing, clientes, hardware, ...Modelo ágil: releases my frecuentes

Utilizando integración continua se minimiza el riesgo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Publicación de entregablesUna release no es sólo software

Ficheros de configuraciónFicheros de datos necesariosProgramas de instalaciónDocumentaciónPublicidad y empaquetamiento


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Continuous delivery

Continuous delivery/entrega continuaEntregas rápidas para obtener feedback lo antes

posibleUtilización de TDD e integración continuaDeployment pipeline (canal de despliegue)

Ventajas: Afrontar el cambioMinimizar riesgos de integración

Filosofía Wabi-sabiAceptar la imperfecciónSoftware no finalizado: Suficientemente bueno (Good enough)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

DevOps

Unir development y operationsCambio cultural en el que el mismo equipo afronta las

fases:Codificar (code): Desarrollo y revisión de código, Integración

continuaConstruir (build): Control de versiones, construcciónProbar (test) Empaquetar: Gestión de artefactosRelease: automatización de versionesConfigurar y gestionarMonitorizar: Rendimiento, experiencia del usuario


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Lenguajes de construcciónLenguajes de configuración

Definiciones de recursos (Json, XML, Turtle)Ejemplos: .travis.yml, package.json, pom.xml

Lenguajes de scriptingEscritos shell/batch

Lenguajes de programación Ejemplos: Java, Javascript,...

Lenguajes visualesEjemplos: scratch, blender, ...

FormalesEjemplos: B-trees, Z language, OCL, ...


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Program

Aspectos de codificaciónConvenciones de nombres

Importantes para otros programadores, mantenimiento...

Clases, tipos, variables, constantes con nombre...Gestión de erroresOrganización código fuente

Paquetes, directorios...Dependencias

Librerías importadasDocumentación del código

Javadocs, jsdoc...

Programador

Programa

Ordenador

Otros programadores& personas mantenimiento


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

PruebasPruebas unitariasIntegraciónCapacidadRegresión. . .Recomendación:

Separar código de pruebas y dependencias de código de producción


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Construcción para reutilizaciónParametrización

Añadir parámetrosBad smell: números mágicos en código

Ficheros y recursos de configuraciónCompilación condicionalEncapsulación

Separar interfaz de implementaciónBad smell: partes internas públicas en librerías

EmpaquetamientoAntipatrón: tareas manuales en empaquetamiento

DocumentaciónImportante: Documentación API


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Construir reutilizandoSeleccionar unidades reutilizables

Componentes externos (COTS, FOSS)Gestión de dependencias

<ver más adelante>Gestión de actualizaciones

Qué ocurre cuando otras librerías se actualizan?Temas legales

¿Realmente puedo utilizar esa librería?¿Para productos comerciales?

Cuidado con librerías GNU¿Está la librería bien mantenida?


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Herramientas de construcciónEditores de texto

vi, emacs, Visual Studio Code, Sublime,....Integrated Development Environments (IDEs)

Ejemplos: IntelliJ, EclipseConstructores de Graphical User Interface (GUI)

Android Studio UI Editor, QtEditor,... Herramientas para asegurar la calidad (QA)

Test, analysis, ...<Ver siguiente trasparencia>


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Herramientas para asegurar calidadPruebas

xUnit, marcos de pruebas (mocha)Lenguajes de aserciones (chai)Herramientas de cobertura

AsercionesPre-condiciones en métodos

Inspecciones y revisiones de códigoPull requests con revisiones de código

Herramientas de análisis de código<See next slide>


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Herramientas de análisis de códigoAnálisis estático vs dinámico

Sin ejecutar código/tras ejecutar códigoEjemplos: PMD, SonarCube,... (Codacy)

DepuradoresInteractivos vs estáticos, logging

ProfilersInformación sobre uso de recursos

Memoria, CPU, llamadas a métodos, etc.Herramientas cobertura de código

Informan qué líneas de código se han ejecutado en pruebas

Program slicingFragmento de programa (slice) que se ha ejecutado

Ejemplos: CodeSurfer, Indus-kaveri,...


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Control de versiones

DefinicionesAlmacén (repositorio): Lugar en el que se

almacenan los cambios.Baseline: Producto inicial en control de

versionesDelta: cambios de una versión respecto a la

anteriorTrunk: Tronco o rama principal de un

producto. Rama master en GitBranch (Rama): desviación de la rama

principalTag: Etiqueta de una línea de versiones

1

Baseline

4

Trunk

2

3Branchs

5

6

9

7

T1

T2

8

10

Tags merge


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Control de versiones

DefinicionesCheck-out: Copia local de trabajo de una

determinada rama o revisión.Commit: Comprometer los cambios locales

en el sistema de control de versiones.Merge (fusión) : Combinación de dos

conjuntos de cambios en uno.Estilos de ramificación: por característica, por

equipo, por versión

1

Baseline

4

Trunk

2

3Branchs

5

6

9

7

T1

T2

8

10

Tagsmerge


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Control de versiones2 tiposCentralizados

Repositorio centralizado de todo el códigoAdministración centralizadaCVS, Subversion, ...

DistribuidosCada usuario tiene su propio repositorioGit, Mercurial


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

GitSistema de control de versiones distribuidoDiseñado por Linus Torvalds (Linux)Objetivos:

Aplicaciones con gran nº de archivos de códigoTrabajo distribuidoApoyo a desarrollo no lineal (ramificaciones)

Más información:http://rogerdudler.github.com/git-guide/


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Componentes locales3 components locales:

Directorio trabajo localIndex (stage area). También llamada cacheHistorial del proeycto: Almacena versiones o commitsHEAD (versión más reciente)

HistorialcommitsProyecto

commitadd

rm

HEADDirectorio

Trabajolocal

Index/stage


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Repositorios remotos

Directoriotrabajo

local

HistorialCommits

Index/stage

Repositorioremotoorigin

push

clonefetchpull

commitadd

rm

Máquinalocal

HEAD

Conectar con repositorios remotosorigin = inicial


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ramas (branches)Git facilita gestión ramas

Master/trunk = rama inicialOperaciones:

Crear ramas (branch)Cambiar rama (checkout)Combinar (merge)Etiquetar ramas (tag)

1

Baseline

4

Trunk

2

3Branchs

5

6

9

7

T1

T2

8

10

Tagsmerge


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Patrones de ramificaciónGit-flow

Rama develop como principalRamas por características y hotfix

Github-flowTodo en master es desplegableNo se necesita rama hotfixPromueve pull-requests

Trunk-based developmentTodo en rama principal (master)Ramificación por características

de poca duración (días)

masterdevelop hotfix-1feature-1feature-2

0.1

1.0

0.2

tags

Ramas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Gestión de dependenciasLibrería: Colección de funcionalidades utilizadas

por el sistema que se desarrollaEl sistema depende de dicha librería

La librería puede depender de otras libreríasLa librería puede evolucionar

Versiones incompatiblesGrafo de dependencias

Grafo de dependencias de Mozilla FirefoxFuente: The purely functional deployment model. E. Dolstra (PhdThesis, 2006)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Grafo de dependencias

Grafo G = (V,E) dondeV = vértices (componentes/paquetes)E = aristas (u,v) que indican que u depende de v

Métrica CCD (cumulative component dependency)

Suma de dependencias de todos los componentesCada componente depende de sí mismo

A

B C

D E G

En ejemplo:CCD=7+3+4+1+1+1+1=18

F


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Principio de Dependencias cíclicasEl grafo de dependencias no debería tener ciclos

Añadir un ciclo puede hacer crecer la CCDEjemplo:

CCD = 7+7+7+1+7+1+1=31

A

B C

D E GF


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Gestión de dependenciasModelos

Instalación local: las librerías se instalan para todo el sistema.Ejemplo: Ruby Gems

Incluir solamente en proyecto (control de versiones)Garantiza versión adecuada

Enlace externoRepositorio con libreríasDependencia de Internet y evolución de la librería


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de construcción

Herramientas de automatización de la construcción y el despliegueOrganizar las diferentes tareas

Compilar, empaquetar, instalar, desplegar, etc.Dependencias entre tareasDeben garantizar:

Ejecutar todos los prerrequisitosEjecutarlos una sola vez

Inicializar

Preparar datos

de prueba

Compilarcódigofuente

Compilarcódigoprueba

Ejecutar pruebas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de la construcciónAtributos de calidad:

CorrecciónEvitar errores comunes (minimizar "bad builds")Eliminar tareas redundantes o repetitivas

Simplicidad: Gestionar complejidadAutomatización y facilidad de publicación

Disponer de histórico de releases y construccionesIntegración continua

CosteAhorrar tiempo y dinero

"Nunca envíes a un humano a realizar el trabajo de una máquina"G. Hohpe


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

¿Cuándo construir?Bajo demanda

Usuario lanza un script en línea de commandosPlanificada

Automáticamente en ciertas horasEjemplo: nightly builds

TriggeredCada commit al Sistema control de versionsServidor de integración continua enlazado con

Sistema de control de versiones


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

HerramientasMakefile (C world)Ant (Java)Maven (Java)SBT (Scala, JVM languages)Gradle (Groovy, JVM languages)rake (Ruby)npm, grunt, gulp (Javascript)etc.


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de construcción

make: Incluido en UnixOrientado a productoLenguaje declarativo basado en reglas

Cuando el proyecto es complejo, los ficheros de configuración pueden ser difíciles de depurar

Varias versiones: BSD, GNU, MicrosoftMuy popular en C, C++, etc.


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de construcciónant: Plataforma Java

Orientado a tareasSintaxis XML (build.xml)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de construcciónmaven: Plataforma Java

Convención sobre configuraciónGestionar ciclo de vida del proyectoGestión de dependencias

Descarga automática y almacenamiento localSintaxis XML (pom.xml)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Automatización de construcciónLenguajes empotrados

Lenguajes específicos empotrados en lenguajes interpretados de alto nivel

Gran versatilidadEjemplos: gradle (Groovy)sbt (Scala)rake (Ruby)Buildr (Ruby)…


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Nuevas herramientasPants (Foursquare, twitter)

https://pantsbuild.github.io/Bazel (Google)

http://bazel.io/Buck (Facebook)

https://buckbuild.com/


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Maven

Herramienta de automatización de construcciónDescribe cómo construir el softwareDescribe dependencias del softwarePrincipio: Convención sobre configuración

Jason van ZylCreador Maven


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenFases típicas de construcción:

clean, compile, build, test, package, install, deploy

Idenfiticación de módulo3 coordenadas: Grupo, Artefacto, VersiónDependencias entre módulos

Configuración: fichero XML (Project Object Model)pom.xml


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenAlmacenes de artefactos

Guardan diferentes tipo de artefactosFicheros JAR, EAR, WAR, ZIP, plugins, etc.

Todas las interacciones a través del repositorioSin caminos relativosCompartir módulos entre equipos de desarrollo

Local ArtifactRepository

RemoteArtifact

Repository

<usuario>/.m2/repository Maven Central


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Maven Central

Repositorio público de proyectosMás de 1 mill de GAV≈ 3000 proyectos nuevos cada mes (GA)≈ 30000 versiones nuevas al mes (GAV)*

http://search.maven.org/

* Fuente: http://takari.github.io/javaone2015/still-rocking-it-maven.html

Otros repositorios:https://bintray.com/


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

POM - Project Object ModelSintaxis XMLDescribe un proyecto

Nombre y versiónTipo de artefacto (jar, pom, ...)Localización del código fuenteDependenciasPluginsProfiles

Configuraciones alternativas para la construcciónEstructura basada en herenciaReferencia: https://maven.apache.org/pom.html


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

POM - Project Object ModelEstructura basada en herencia

Super POMPOM por defecto de MavenTodos los POM extiende el Super POM salvo que se

indique de formaexplícitaparent

Declara el POM padreSe combinan las dependencias y propiedades


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenIdentificación de proyecto

GAV (Grupo, artefacto, versión)Grupo: Identificador de agrupamientoArtefacto: Nombre del proyectoVersión: Formato {Mayor}.{Menor}.{Mantenimiento}

Se puede añadir "-SNAPSHOT" (en desarrollo)

<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>es.uniovi.asw</groupId><artifactId>censusesN</artifactId><version>0.0.1</version><name>censusesN</name>...


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Maven

Estructura de directoriosMaven utiliza una estructura convencional

src/mainsrc/main/javasrc/main/webappsrc/main/resourcessrc/test/src/test/javasrc/test/resources. . .

Directorio de salida: target


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenCiclo de vida

3 ciclos de vida por defectocleandefaultsite

Cada ciclo de vida tiene sus fases


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ciclo de vida "clean"Borrar código compilado3 fases

pre-cleancleanpost-clean


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ciclo de vida "default"

Compilación y empaquetado de códigoAlgunas fases validate

initializegenerate-sourcesgenerate-resourcescompiletest-compiletestpackageintegration-testverifyinstalldeploy


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ciclo de vida "site"Generar documentación proyecto

pre-sitesitepost-sitesite-deploy


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenGestión automática de dependencias

Identificación mediante GAVÁmbito compile testprovide

Tipojar, pom, war,...

<project>...<dependencies>

<dependency><groupId>javax.servlet</groupId><artifactId>servlet-api</artifactId><version>2.5</version><scope>provided</scope>

</dependency>. . .

</dependencies></project>


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenGestión automática de dependencias

Las dependencias son descargadas Alojadas en repositorio local Pueden crearse repositorios intermedios (proxies)

Ejemplo: artefactos comunes de una empresaTransititivdad

B depende de CA depende de B ⇒ C también se descarga


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenMúltiples módulosProyectos grandes pueden descomponerseCada proyecto crea un artefacto

Tiene su propio fichero pom.xmlEl proyecto padre agrupa los módulos

<project>...<packaging>pom</packaging><modules>

<module>extract</module><module>game</module>

</modules></project>


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Maven Plugins

Maven tiene una arquitectura basada en plugins2 tipos de plugins

BuildSe identifican en <build/>

ReportingSe identifican en <reporting/>

Lista de plugins: https://maven.apache.org/plugins/index.html


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

MavenAlgunas fases habituales

archetype:generate - Genera esqueleto de un proyectoeclipse:eclipse - Genera proyecto eclipsesite - Genera sitio web del proyectosite:run - Genera sitio web y arranca servidorjavadoc:javadoc - Generar documentacióncobertura:cobertura - Informe del código ejecutado en pruebascheckstyle:checkstyle - Chequear el estilo de codificación


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

npmNode.js Package ManagerCreado inicialmente por Isaac Schlueter

Posteriormente, empresa Npm inc.Gestor de paquetes por defecto de NodeJs

Otro gestor para NodeJs: YarnGestiona las dependenciasPermite scripts para tareas comunes

Almacén de softwarePaquetes públicos o de pago

Fichero de configuración: package.json


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Configuración npm: package.jsonFichero configuración: package.json

npm init crea un esqueleto inicialCampos: {

"name": "...obligatorio...","version": "...obligatorio...","description": "...opcional...","keywords": "...","repository": {... },"author": "...","license": "...","bugs": {...},"homepage": "http://. . .","main": "index.js","devDependencies": { ... },"dependencies": { ... }"scripts": { "test": " ... " },"bin": {...},

}

Nota: Yeoman proporciona esqueletos completos


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Paquetes npmBase de datos: http://npmjs.orgInstalación de paquetes:

2 opciones:Localnpm install <packageName> --save (--save-dev)

Globalnpm install -g <packageName>

http://npmjs.org/


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Dependencias npmGestión de dependencias

Paquetes locales en caché, directorio: node_modulesAcceso a módulos mediante: require('...')

Paquetes globales (instalados con opción --global)Cacheados en: ~/.npm folder

Paquetes con ámbito marcados con @


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Comandos y scripts npmNpm contiene numerosos comandos

start ≈ node server.jstest ≈ node server.jsls: muestra lista de paquetes instalados...

Scripts creados por el usuario: run-script <name>Definidos en sección "scripts"

Para gestionar tareas más complejasgulp, grunt

https://docs.npmjs.com/cli-documentation/

https://docs.npmjs.com/cli-documentation/

Documents

Taxonomías del software Patrones, estilos y tácticas · 2021. 3. 6. · Arquitectura del Software Escuela de Ingeniería Informática Universidad de Oviedo Taxonomías del software