Arquitectura software.taxonomias.construccion.002

553 visualizaciones

Publicado el

0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
553
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Arquitectura software.taxonomias.construccion.002

  1. 1. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoArquitectura del SoftwareParte II. Taxonomías de arquitecturaTema 2: DisposiciónJose Emilio Labra Gayo2013Universidad de Oviedo
  2. 2. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoDisposición (Allocation)Relación del software con el entornoConstrucción, despliegue y distribución
  3. 3. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEsquemaConstrucciónEstilos de desarrolloTradicionales, iterativos, ágilesGestión de configuracionesControl de versionesGestión de dependenciasDespliegue e integración continuaDistribuciónCanales de distribución
  4. 4. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoNota: Se ha incluido una selección. Puede consultarse una extensa lista en:http://en.wikipedia.org/wiki/List_of_software_development_philosophies
  5. 5. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIncremental piecemealCrecimiento según necesidadCodificar sin considerar la arquitecturaSoftware de usar y tirarLimitaciones presupuestarias
  6. 6. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPropuesto en años 70CascadaAnálisis derequisitosDiseño desoftware ysistemaImplementacióny pruebasunitariasPruebasintegración ysistemaDespliegue ymantenimiento
  7. 7. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoModelo en VRequisitosAnálisisDiseñoDiseñoObjetosPruebasUnitariasPruebasIntegraciónPruebasSistemaPruebasAceptaciónTiempoNivelde detalleBajoAlto
  8. 8. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBig Design Up FrontAntipatrón de modelos tradicionalesDemasiada documentación que nadie leeDocumentación diferente al sistema desarrolladoArquitectura degradadaSistemas que no son usados
  9. 9. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoModelos iterativosBasado en prototiposEvaluación de riesgosRequisitosAnálisisDiseñoPruebaDespliegueValoraciónIteración 1RequisitosAnálisisDiseñoPruebaDespliegueValoraciónIteración 2RequisitosAnálisisDiseñoPruebaDespliegueValoraciónIteración 3
  10. 10. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoRUP (Rational Unified Process)Fuente: Wikipedia.http://es.wikipedia.org/wiki/Archivo:Rup_espanol.gifUno de los modelos más utilizadosProceso iterativo
  11. 11. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ÁgilesNumerosas variantesRAD (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). . .
  12. 12. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágilesManifiesto ágil (www.agilemanifesto.org)Individuos e interaccionessobre procesos y herramientasSoftware que funcionesobre documentaciónColaboración con el clientesobre negociación de contratoRespuesta al cambiosobre seguimiento de un plan
  13. 13. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágilesRealimentaciónAjustes constantes en el códigoMinimizar riesgoSoftware en intervalos cortosIteraciones de horas o díasCada iteración pasa todo el ciclo de desarrollo
  14. 14. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágilesAlgunas prácticas (XP)1. Planificaciones cortas2. Pruebas3. 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
  15. 15. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles1. Planificaciones cortasDespués de cada iteración, volver a planificarRequisitos mediante historias de usuarioDescripciones breves (Tamaño tarjeta)Objetivos priorizados por clientesRiesgo y recursos estimados por desarrolladoresHistorias de usuario = pruebas aceptaciónPreparación para el cambioPlan originalPlan actual
  16. 16. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2.- Utilización de pruebasUtilización de pruebas extensivaObjetivo: Desarrollo basado en pruebasTDD (Test Driven Development)
  17. 17. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2.- PruebasTipos de pruebasPruebas de aceptaciónFuncionalesDemostracionesPruebas usabilidadPruebas exploraciónPruebas aceptaciónno funcional(capacidad,seguridad,…)Pruebas unitariasPruebas integraciónPruebas sistemaAutomáticas ManualesAutomáticas Manuales/AutomáticasSoportealdesarrolloCriticaalproyectoDirigidas al negocioDirigidas a tecnología
  18. 18. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2. PruebasDesarrollo basado en pruebasAntes de codificar, realizar una pruebaSe arranca con un código que fallaObjetivo: pasar la pruebaResultado:Batería de pruebas automatizada
  19. 19. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2. PruebasBehaviour-driven development (BDD)Pruebas a partir de historias de usuarioDeben escribirse junto con clienteHerramientas: Cucumber, JBehave, Specs2,...Sirven como contratoMiden el progreso Feature: Buscar cursosPara mejorar el uso de los cursosLos estudiantes deberían ser capaces de buscar cursosScenario: 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 |
  20. 20. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2. PruebasPrincipios FIRSTF - FastLa ejecutación de pruebas debe ser rápidaI - Independent:Los casos de prueba son independientes entre síR - Repeatable:Tras ejecutarlos N veces, el resultado debe ser el mismoS - Self-checkingSe puede comprobar si se cumplen automáticamente, sinintervención humanaT - TimelyPruebas escritos al mismo (o antes) tiempo que código
  21. 21. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles2. PruebasDefinicionesDobles de pruebasObjetos Dummy: se pasan pero no se utilizanObjetos fake: Tienen implementación parcialStubs: respuestas precocinadas a ciertas preguntasEspías: son stubs que pueden registrar cierta informaciónpara depuraciónMocks: objetos programados con ciertas expectativas sobrequé tipo de llamadas deben recibirFixtures. Elementos fijos de soporte a las pruebasEj. Bases de datos con ciertas entradas, determinadosficheros, etc.
  22. 22. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles3. Programación en parejas2 ingenieros software trabajan juntos en unordenadorEl conductor maneja el teclado y crea implementaciónEl observador identifica fallos y da ideasLos roles se intercambian cada cierto tiempo
  23. 23. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles4. Diseño simpleReacción a Big Design Up FrontDiseño más simple que funcioneDocumentación automatizadaJavaDoc y similaresUtilización opcional de tarjetas CRC
  24. 24. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles5. RefactorizaciónMejorar diseño sin cambiar la funcionalidadSimplificar código (eliminar código duplicado)Buscar activamente oportunidades de abstracciónPruebas de regresiónSe basa en la batería de pruebas
  25. 25. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles6. Propiedad colectiva del códigoEl código pertenece al proyecto, no a un ingenieroparticularA medida que los ingenieros desarrollan, debenpoder navegar y modificar cualquier claseAunque no la hayan escrito ellosEvitar fragmentos de una única persona
  26. 26. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles7. Integración continuaCada pareja escribe sus propios casos de prueba ytrabaja para satisfacerlosPasar 100% de casos de pruebaIntegrarEl proceso debe realizarse 1 ó 2 veces al díaObjetivo: evitar integration hell
  27. 27. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles8. Cliente en lugar de desarrolloCliente disponible para clarificar historias deusuarios y tomar decisiones críticas de negocioVentajasDesarrolladores no realizan suposicionesDesarrolladores no tienen que esperar para decisionesMejor comunicación
  28. 28. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles9. Entregas pequeñasTan pequeñas como sea posible pero que ofrezcanvalor al usuarioEntregas no son, por ejemplo, implementar BDObtener realimentación temprana del clientePlanificar siguiente entrega tras cada iteraciónEntregar algo cada semanaCuidado:No todo el mundo puede trabajar así
  29. 29. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles10. Horarios normales40h/semana = 40h/semanaEvitar horas extraProgramadores cansados escriben código pobreA largo plazo ralentiza el desarrollo
  30. 30. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágiles11. Código limpioFacilitar modificación de código por otras personasUtilizar buenas prácticasEstilos y normas de codificaciónEvitar code smellsManifiesto software craftmanshipLibro Clean Code (Robert C. Martin)Fuente: Clean Code. Robert Martin
  31. 31. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMétodos ágilesVariantesScrumGestión deproyectos/personasDivisión de trabajo en sprintsReunión diaria de 15Backlog del productoKanbanModelo lean (esbelto)Desarrollo Just in TimeLimitar cargas de trabajo
  32. 32. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedo
  33. 33. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGestión de configuracionesDiferentes versiones de softwareFuncionalidades nuevas o diferentesCorrección de bugsNuevos entornos de ejecuciónGestión de configuraciones: gestión de laevolución del softwareCambios del sistema = actividades en equipoCostes y esfuerzo necesarios
  34. 34. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoControl de versionesSistemas que gestionan las diferentes versionesdel códigoAcceso a todas las versiones del sistemaFacilidad para volver atrásDiferencias entre versionesCódigo colaborativoFacilidad para gestión de ramificacionesMetadatosAutor de la versión, fecha actualización, etc.
  35. 35. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoBaselineBaselines (línea de referencia): Software que essometido a gestión de configuraciones.Versión1.0WindowsVersión1.5SunVersión1.5LinuxVersión2.0WindowsVersión2.5 EscritorioLinuxVersión2.5 EscritorioServidor
  36. 36. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoReleases y versionesVersión: instancia de un sistema funcionalmentedistinta de otras instanciasRelease (entregable): instancia de un sistema quees distribuida a usuarios externos al equipo dedesarrollo.Puede ser considerado un producto final
  37. 37. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoNombres habituales de versionesPre-alfaAntes de las pruebasAlfaEn pruebasBeta (o prototipo)Pruebas por usuariosBeta-tester: usuario que hace pruebasRelease-candidateVersión beta que podría ser producto final
  38. 38. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoOtros esquemas de nombresNúmeros simples1.1, 1.1-alphaUtilización de atributosFecha, creador, lenguaje, cliente, estado,...Nombres reconociblesGanimede, Galileo, Helios, Indigo, Juno,...Precise Pangolin, Quantal Quetzal,...
  39. 39. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublicación de entregablesUna release supone cambios de funcionalidadPlanificaciónPublicar una release no es baratoLos usuarios no suelen querer nuevas releasesFactores externos:Marketing, clientes, hardware, ...Modelo ágil: releases my frecuentesUtilizando integración continua se minimiza el riesgo
  40. 40. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoPublicación de entregablesUna release no es sólo softwareFicheros de configuraciónFicheros de datos necesariosProgramas de instalaciónDocumentaciónPublicidad y empaquetamientoDistribución: medios físicos (CDs, DVDs), Web(descargas), stores
  41. 41. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoControl de versionesDefinicionesAlmacén (repositorio): Lugar en el que sealmacenan los cambios.Baseline: Producto inicial en control deversionesDelta: cambios de una versión respecto a laanteriorTrunk: Tronco o rama principal de unproducto. Rama master en GitBranch (Rama): desviación de la ramaprincipalTag: Etiqueta de una línea de versiones1Baseline4Trunk23Branchs5697T1T2810Tags merge
  42. 42. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoControl de versionesDefinicionesCheck-out: Copia local de trabajo de unadeterminada rama o revisión.Commit: Comprometer los cambios locales enel sistema de control de versiones.Merge (fusión) : Combinación de dosconjuntos de cambios en uno.Estilos de ramificación: por característica,por equipo, por versión1Baseline4Trunk23Branchs5697T1T2810Tagsmerge
  43. 43. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoControl de versiones2 tiposCentralizadosRepositorio centralizado de todo el códigoAdministración centralizadaCVS, Subversion, ...DistribuidosCada usuario tiene su propio repositorioGit, Mercurial
  44. 44. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGitSistema 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)El siguiente contenido es un resumen de:http://rogerdudler.github.com/git-guide/
  45. 45. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit – Sistema distribuidoCada desarrollador tiene copia local de todo elhistorial de cambiosEl repositorio se puede crear:git inito clonargit clone
  46. 46. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit – flujo de trabajo localGit gestiona 3 árboles:Directorio de trabajo localIndex ó área de ensayo (stage)HEAD (última versión comprometida)Directoriode trabajoIndex(stage)add commitHEAD
  47. 47. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit – Flujo de trabajo localgit add: Envía ficheros al área de ensayo (Index)git commit: Compromete ficheros (HEAD)Tras hacer commit, los ficheros están en control deversiones, pero no en repositorio remoto
  48. 48. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit – Enviando ficherosgit remote add origin <servidor>Añade un servidor remotoSi el repositorio es clonado no es necesariogit push origin masterEnvía la versión de HEAD al repositorio remotoPuede ser “master” u otra rama
  49. 49. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit - RamificacionesGit da buen soporte a ramificaciones (branching)Master = rama por defectoEs buena costumbre crear otras ramasEjemplo: develop, release-1, …Las ramas pueden mezclarse (merge)
  50. 50. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit - ramificacionesgit checkout –b rama1Crea una rama llamada “rama1” y cambia a ellagit checkout masterRegresa a la rama “master”git push origin rama1Envía rama1 al repositorio remoto
  51. 51. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit – Actualizaciones y mezclasgit pullActualiza repositorio local a la última versiónEste comando debería ejecutarse al iniciar el trabajogit merge rama2Intenta mezclar la rama “rama2” con la rama actualSi se producen conflictos hay que resolverlosmanualmente y marcarlos mediante “git add”También pueden verse mediante “git diff”
  52. 52. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGit - EntornoEn Eclipse: EGit
  53. 53. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCiclo de trabajoEstación de trabajolocalDesarrolloConstruirBuildAlmacénCentral códigoConstruirBuildpullpushConstruirBuildDone!
  54. 54. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGestión de dependenciasLibrería: Colección de funcionalidades utilizadaspor el sistema que se desarrollaEl sistema depende de dicha libreríaLa librería puede depender de otras libreríasLa librería puede evolucionarVersiones incompatiblesGrafo de dependenciasGrafo de dependencias de Mozilla FirefoxFuente: The purely functional deployment model. E. Dolstra (PhdThesis, 2006)
  55. 55. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGestión de dependenciasModelosInstalación local: las librerías se instalan para todoel sistema.Ejemplo: Ruby GemsInclusión en proyecto (control de versiones)Garantiza versión adecuadaEnlace externoRepositorio con libreríasDependencia de Internet y evolución de la librería
  56. 56. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAutomatización de construcciónHerramientas de automatización de laconstrucción y el despliegueOrganizar las diferentes tareasDependencias entre tareasDeben garantizar:Ejecutar todos los prerrequisitosEjecutarlos una sola vezInicializarPreparardatosde pruebaCompilarcódigofuenteCompilarcódigopruebaEjecutarpruebas
  57. 57. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAutomatización de construcciónmake: Incluido en UnixOrientado a productoLenguaje declarativo basado en reglasCuando el proyecto es complejo, los ficheros deconfiguración pueden ser difíciles de depurarVarias versiones: BSD, GNU, MicrosoftMuy popular en C, C++, etc.
  58. 58. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAutomatización de construcciónant: Plataforma JavaOrientado a tareasSintaxis XML (build.xml)
  59. 59. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAutomatización de construcciónmaven: Plataforma JavaConvención sobre configuraciónGestionar ciclo de vida del proyectoGestión de dependenciasDescarga automática y almacenamiento localSintaxis XML (pom.xml)
  60. 60. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoAutomatización de construcciónLenguajes empotradosLenguajes específicos empotrados en lenguajesinterpretados de alto nivelGran versatilidadEjemplos:gradle (Groovy)sbt (Scala)rake (Ruby)Buildr (Ruby)…
  61. 61. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedo
  62. 62. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenHerramienta de construcciónGestión de dependenciasPrincipio: Convención sobre configuración
  63. 63. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenFases de desarrollo habituales:clean, compile, build, test, package, install, deployIdentificación de módulos3 coordenadas: Grupo, artefacto, versiónDependencias entre módulosConfiguración mediante fichero XMLpom.xml
  64. 64. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenAlmacenes de artefactosGuardan 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 desarrolloLocal ArtifactRepositoryRemoteArtifactRepository<usuario>/.m2/repository Maven Central
  65. 65. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenFichero POM (pom.xml)Sintaxis XMLDescribe un proyectoNombre y versiónTipo de artefacto (jar, pom, ...)Localizaciones de código fuenteDependenciasPluginsProfilesConfiguraciones alternativas de construcción
  66. 66. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenIdentificación de proyectoGAV (Grupo, artefacto, versión)Grupo: Identificador de agrupamientoArtefacto: Nombre del proyectoVersión: Formato {Mayor}.{Menor}.{Mantenimiento}Se puede añadir "-SNAPSHOT" (en desarrollo)<?xml version="1.0" encoding="UTF-8"?><project><modelVersion>4.0.0</modelVersion><groupId>es.uniovi.asw</groupId><artifactId>Entrecine8</artifactId><version>1.0</version></project>
  67. 67. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenEstructura de directoriosMaven utiliza una estructura convencionalsrc/mainsrc/main/javasrc/main/webappsrc/main/resourcessrc/test/src/test/javasrc/test/resources. . .
  68. 68. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenCiclo de desarrollogenerate-sources/generate-resourcescompiletestpackageintegration-testinstalldeploycleanInvocación:mvn cleanmvn compilemvn clean compilemvn compile install...
  69. 69. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenGestión automática de dependenciasIdentificación mediante GAVÁmbitocompiletestprovideTipojar, pom, war,...<project>...<dependencies><dependency><groupId>javax.servlet</groupId><artifactId>servlet-api</artifactId><version>2.5</version><scope>provided</scope></dependency>. . .</dependencies></project>
  70. 70. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenGestión automática de dependenciasLas dependencias son descargadasAlojadas en repositorio localPueden crearse repositorios intermedios (proxies)Ejemplo: artefactos comunes de una empresaTransititivdadB depende de CA depende de B  C también se descarga
  71. 71. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenMúltiples módulosProyectos grandes pueden descomponerseCada proyecto crea un artefactoTiene su propio fichero pom.xmlEl proyecto padre agrupa los módulos<project>...<packaging>pom</packaging><modules><module>maven-training</module><module>maven-training-web</module></modules></project>
  72. 72. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoMavenOtras fases y pluginsarchetype: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
  73. 73. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoEntornos de ejecuciónEntornos habitualesEntornodesarrolloEntornopruebasEntornoproducciónServidorpruebasServidorintegraciónControl deversionesServidor producciónGranja de servidoresTambién puede haber un entorno de ensayo (staging environment)
  74. 74. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoIntegracióncontinuaInterfazWebIntegración continuaServidores de integración continuaHudson, Jenkins, Travis, BambooInformescheckout/commitAlmacén centralde códigoEquipo dedesarrollo
  75. 75. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCodificación socialAlmacenes públicos de códigoDiferentes políticasEjemplos:SourceforgeGoogle projectsBitbucketGithub
  76. 76. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoGithubHerramienta de codificación socialCompañía Github Inc. creada en 20082013: >3 millones de usuarios, >5millones proyectosGestión gratuita de proyectos de código abiertoProyectos públicos por defecto y gratisEs posible tener proyectos privados pagando
  77. 77. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoHerramientas en la nubeExisten diversas herramientas para desarrollo enla nubeEjemplos:IaaS: InfraestructuraAmazon ECSPaaS: PlataformaGoogle AppEngine, HerokuSaaS: SoftwareGMail, GDocs, etc.
  78. 78. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoLíneas de productoCanales de distribución
  79. 79. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoLíneas de productoLínea de producto: productos que comparten unaserie de características comunes satisfaciendo unsegmento de mercado concretoObjetivo:Reducción esfuerzo desarrolloMejorar productividadPasar de un único producto a una línea de productos
  80. 80. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoLíneas de productoRequisitosIdentificar soluciones genéricas a problemascomunesDesarrollo basado en componentesPlataformas genéricasReutilización de softwareGeneración automática de sistemas
  81. 81. Arquitectura del SoftwareEscueladeIngenieríaInformáticaUniversidaddeOviedoCanales de distribuciónDistribución tradicionalCDs, DVDs, etc.Distribución vía WebDescargas, FTP, etc.Mercados de aplicacionesPaquetes de aplicaciones LinuxApple AppStore,Google Play,Windows Store

×