Taxonomías del software Patrones, estilos y tácticas · 2021. 3. 6. · Arquitectura del Software...

Arquitectura del SoftwareE

Taxonomías del softwarePatrones, estilos y tácticas

Jose Emilio Labra GayoCurso 2020/2021

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

Construcción y mantenimiento del software

Jose E. Labra GayoCourse 2018/2019

o Construcción y mantenimientoSoftwareGestión de configuraciones

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

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

Construcción de softwareRepaso a metodologías

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

Lenguajes, herramientas de construcción, etc.

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

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

Modelo en V

Requisitos

Análisis

Diseño

DiseñoObjetos

PruebasUnitarias

PruebasIntegración

PruebasSistema

PruebasAceptación

Tiempo

Nivelde detalle

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

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

RUP (Rational Unified Process)

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

Uno de los modelos iterativos más utilizadosProceso iterativo

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). . .

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

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

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

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

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

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

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

Critica al proyecto

Dirigidas al negocio

Dirigidas a tecnología

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 |

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

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.

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

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

Métodos ágiles4. Diseño simple

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

Documentación automatizadaJavaDoc y similares

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

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

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

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

Integración continuaHerramientas

Hudson, Jenkins, Travis, Bamboo

Integracióncontinua

Interfazweb

Informes

checkout/commit

Repositorio central

de código

Equipo de desarrollo

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

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

Métodos ágiles10. Horarios normales

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

A largo plazo ralentiza el desarrollo

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

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

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

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.

Baseline

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

Versión1.0

Windows

Versión1.5

Versión2.0

Windows

Versión2.5 Escritorio

Servidor

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

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

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

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

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

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

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)

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

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, ...

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

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

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

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

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?

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>

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>

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,...

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

Baseline

3Branchs

Tags merge

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

Baseline

3Branchs

Tagsmerge

Control de versiones2 tiposCentralizados

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

DistribuidosCada usuario tiene su propio repositorioGit, Mercurial

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/

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

HEADDirectorio

Trabajolocal

Index/stage

Repositorios remotos

Directoriotrabajo

HistorialCommits

Index/stage

Repositorioremotoorigin

clonefetchpull

commitadd

Máquinalocal

Conectar con repositorios remotosorigin = inicial

Ramas (branches)Git facilita gestión ramas

Master/trunk = rama inicialOperaciones:

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

Baseline

3Branchs

Tagsmerge

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

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)

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

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

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

D E GF

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

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

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

¿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

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

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.

Automatización de construcciónant: Plataforma Java

Orientado a tareasSintaxis XML (build.xml)

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)

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)…

Nuevas herramientasPants (Foursquare, twitter)

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

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

https://buckbuild.com/

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

Jason van ZylCreador Maven

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

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

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/

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

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

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>...

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

MavenCiclo de vida

3 ciclos de vida por defectocleandefaultsite

Cada ciclo de vida tiene sus fases

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

pre-cleancleanpost-clean

Ciclo de vida "default"

Compilación y empaquetado de códigoAlgunas fases validate

initializegenerate-sourcesgenerate-resourcescompiletest-compiletestpackageintegration-testverifyinstalldeploy

Ciclo de vida "site"Generar documentación proyecto

pre-sitesitepost-sitesite-deploy

MavenGestión automática de dependencias

Identificación mediante GAVÁmbito compile testprovide

Tipojar, pom, war,...

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

</dependency>. . .

</dependencies></project>

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

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

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

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

</modules></project>

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

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

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

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

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

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

Globalnpm install -g <packageName>

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 @

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/

Taxonomías del software Patrones, estilos y tácticas · 2021. 3. 6. · Arquitectura del Software...

Documents

Ing del software

Evolucion del hardware y del software

Taxonomías y sitios web - E-LISeprints.rclis.org/32567/1/Taxonomias-estructuras... · 2018. 3. 22. · Taxonomías y sitios web Definiciones, aplicación a contenidos e implementación

Medición del Software

EMCO WinNC GE Series Fanuc 0-TC Descripción del software ... · EMCO WinNC GE Series Fanuc 0-TC Descripción del software/ Versión del software 13.70 Descripción del software EMCO

Conceptos del Mantenimiento del Software

Piratería del Software

Arquitectura del software

Actividad Formativa - Ingeniería del Software fin de master.pdf · “Ingeniería del Software. Un enfoque ... //groups.google.com/d/forum/ingenieria-del-software. ... través de

Ingegneria del software - diies.unirc.it · Ingegneria del software:

introducciã“n a la ingenierã a del software: calidad del software

Manuale del software · 2020. 12. 10. · Versioni in lingua del manuale del software → 5 Avvio del programma 5.1 Software limitato Il software LR DEVICE senza chiave di licenza

Ingenieria Del Software

1 Contenido Crisis del Software Mitos del Software Qué es Ingeniería de Software

Ventajas del software

INGENIERÍA DEL SOFTWARE - UNID · INGENIERÍA DEL SOFTWARE 6 SWEBOK (Software Engineering Body of Knowledge.Guía acerca del ) conocimiento necesario de un ingeniero de software

clasificacion del software

Calidad del software

Compendio de Ingeniería del Software · 2. Evolución histórica del software 3. Tipos de producto software 4. Definición de Ingeniería de Software. 5. Crisis del software 6. Malas

requerimientos del software