You are currently browsing the category archive for the ‘Ingenieria del software’ category.

Simplemente enlazo esta página donde habla de como realizar flujos de trabajo aprovechando el poco coste del branching en Git.

También puede servir como punto de entrada al libro Pro Git de Scott Chacon. Ayuda mucho a entender el funcionamiento de Git sus explicaciones de como están implementadas internamente estas funcionalidades.

Algunas notas interesantes:

  • Git no guarda cambios incrementales sino que guarda instantaneas completas del estado del código en el momento del commit.
  • La rama principal y las demás ramas son apuntadores a estas instantaneas.
  • En el momento de crear una nueva rama, se crea un apuntador a la instantánea del último commit.
  • Esta política hace que el coste del branching sea bajo en comparación a otros
  • Permite, por tanto, la existencia y utilización con ramas temporales para los flujos de trabajo.

En la siguiente imagen del libro podemos ver reflejadas todas estas ideas:

gitBranching

Diagrama de clases en UML2 que hicimos de la aplicación ParaMul con VP-UML y que utilizaremos desde Kunagi para diferentes elementos de Scrum y GitX para el control de versiones:

UML_CD_ParaMul

Roles

  • Product Owner: es el que sabe como debe ser el producto, por lo que escribe historias de usuario (requisitos funcionales), las ordena por prioridad, las coloca en el product backlog, pone fechas y se encarga de aceptar o rechazar los entregables. Por ejemplo, en kunagi:

scrum_PO

  • ScrumMaster: es el encargado de asegurar que los procesos Scrum se cumplan, que se cumplan las reglas, que los equipos trabajen como es debido, eliminando obstáculos y aislándolos de distracciones. Por ejemplo, en kunagi:

scrum_SM

  • Development Team: es el equipo multidisciplinar de entre 5 y 9 personas con habilidades transversales (diseño, implementación, documentación…) que se autoorganiza para tener los entregables en los plazos.

scrum_T

Reuniones

  • Daily Scrum (15m): cada dia a la misma hora y en el mismo sitio de pie para que cada miembro del equipo diga que hizo ayer, que ara hoy y que impedimentos está encontrando.
  • Scrum de Scrum (15m):  después del daily scrum y a nivel de equipos cuando existen varios. Un representate por equipo para explicar que hizo su equipo ayer, que ará hoy, que problemas tiene y si va a subir algo que se encontraran el resto de equipos.
  • Sprint Planning Meeting (8h): al empezar un sprint para prepararlo. Seleccionar que es lo que se hará, construir el sprint backlog y asignar plazos.
  • Sprint Review Meeting (4h): revisar que se ha conseguido y que no. Demo únicamente de lo entregable.
  • Sprint Retrospetive Meeting (4h): opinión de todos sobre las demos.

Documentos

  • Product Backlog: que se tiene que hacer en el producto.
  • Sprint Backlog: que se tiene que hacer en el sprint actual.

En la web de ScrumAlliance encontramos el siguiente resumen:

scrumFramework

En el siguiente post de Henrik Kniberg comenta como llevar a la práctica los conceptos tratados en los posts sobre Software Configuration Management y Agile Software Development.

El siguiente gráfico, del mismo post, resume todo lo tratado en el artículo:

gitScrum

A continuación sencillos comentarios interesantes que aparecen en el post:

  • Cada branch (rama), incluso la mainline (tronco), tiene un owner (propietario) y una policy (política).
  • Tenemos to do, in progress y done como estados para cada user story.
  • Done (hecho) significa releasable (entregable), es decir, que si en ese momento el cliente quisiera entrar y empezar a probarlo, nadie tuviera que decirle que no puede, que tiene que esperar.
  • El tronco es la rama hecho, es decir, la que entrará en producción llegado el momento.
  • La política del tronco puede ser o (exclusivo) entregable at any time (en cualquier momento) o lo antes posible (asap).
  • Crear ramas cuantas menos mejor. Solo crearemos una cuando queramos probar algo y no lo podamos hacer con ninguna de las existentes sin violar sus políticas.
  • Como entegrable incluye las pruebas de integración y no podemos hacerlo sobre la mainline, necesitamos una nueva rama: work branch (rama de trabajo) o development branch (rama de desarrollo).

El Agile Software Development (desarrollo ágil de software) es un paradigma de la ingenieria del software cuyas principales características son:

  • la idea general es el desarrollo iterativo e incremental minimizando costes.
  • una iteración es el software desarrollado en una unidad de tiempo, entre una y cuatro semanas.
  • cada iteración no agrega mucha funcionalidad pero debe estar libre de errores y funcionar.
  • en cada iteración: planificación, analisis, diseño, implementación, prueba y documentación.
  • al final de cada iteración se reevaluan las prioridades del proyecto.
  • se enfatiza la comunicación cara a cara.

Scrum es un ejemplo concreto de metodología ágil. El diagrama de la empresa Mountain Goat Software de Mike Cohn es bastante autoexplicativo:

scrum

aquí una introducción de ellos mismos a estos temas.

¿Alguna herramienta libre para llevar ésto a la práctica? Pués, por ejemplo, PangoScrum o Kunagi. Según ellos mismos, “PangoScrum is a agile project management tool for Scrum.Keeping it simple, it focus on the continuously efficiency improvement of software development”, “Kunagi is a free web-based tool for integrated project management and collaboration based on Scrum“.

Finalmente, en esta página de Scrum Manager, los princípios de la Orientación a Objetos.

Seguimos con SCM, con el libro Software Configuration Management Patterns: Effective Teamwork, Practical Integration, desde donde lo dejamos en el último post sobre el tema.

Private Workspace

¿Cómo lo hacemos, con una codeline que cambia contínuamente, para realizar progresos sin que nos distraiga este entorno cambiante debido a los que están por debajo de nosotros?

Realiza tu trabajo en un workspace privado donde controlemos las versiones del código y los componentes que estamos utilizando. Debemos tener control total sobre cuando y como cambia nuestro entorno.

Repository

¿Cómo obtener las versiones correctas de los componentes correctos en un nuevo workspace?

Private System Build

¿Cómo verificas que tus cambios no rompen la construcción o el sistema antes de colocarselos?

Antes de hacer un submit al control de fuente, construir el sistema de manera privada de manera similar a como será.

SCM_psb

Integration Build

¿Cómo asegurarse de que el código base siempre se construye de manera fiable?

Asegurate de que todos los cambios (y sus dependencias) se construyen utilizando un proceso para la construcción de la integración centralizado.

SCM_ib

Third Party Codeline

¿Cúal es la estrategia mas efectiva para coordinar las versiones de vendedores de código con las versiones de productores de código?

SCM_tpc

Task Level Commit

¿Cuanto trabajo debemos realizar entre submits al sistema de control de versiones? ¿Cuando tiempo deberíamos esperar antes de colocarlos?

Realizar un commit por cada pequeña tarea de grano fino consistente.

Codeline Policy

¿Como saben los desarrolladores en que codeline deben comprobar su código y que tests deben realizar antes de hacerlo?

Para cada rama o codeline define una política que determine cómo y cúando los desarrolladores realizarán cambios. La política debe ser concisa y auditable.

Smoke Test

¿Cómo saber que el sistema seguirá funcionando después de que realizemos un cambio?

Somete cada construcción a una prueba de humo que verifique que la aplicación no se rompe de una manera evidente.

Unit Test

¿Cómo comprobar si un módulo continua funcionando tras realizar un cambio?

Desarrolla y realiza pruebas unitarias.

Regression Test

¿Cómo asegurarse de que el código existente no empeora con las nuevas mejoras?

Ejecutar pruebas de regresión en el sistema siempre que lo desee para asegurar la estabilidad de la codeline, como antes de liberar una construcción, o antes de un cambio especialmente arriesgado.
Crea las pruebas de regresión a partir de los casos de prueba que hicieron fallar al sistema en el pasado.

Private Versions

¿Cómo puedes experimentar con un cambio complejo y beneficiarse del sistema de control de versiones sin hacer el cambio público?

Provee a los desarrolladores de un mecanismo de checkpoints de cambios en una granularidad que se sienta cómodo. Esto puede hacerse mediante un área de control para versiones locales. Sólo los conjuntos de código estables se registrarán en el repositorio del proyecto.

Release Line

¿Cómo mantener versiones publicadas sin interferir en el trabajo actual de desarrollo?

SCM_rl

Release-Prep Codeline

¿Cómo se puede estabilizar una codeline para un lanzamiento inminente, además de facilitar el continuar trabajando en la codeline activa?

SCM_rpc

Task Branch

¿Cómo puede nuestro equimo hacer a una codeline múltiples cambios a largo plazo superpuestos sin comprometer su consistencia e integridad?

SCM_tb

Alguna definicion previa (mantendremos la nomenclatura inglesa):

Un workspace es un lugar donde el desarrollador tiene todos las entidades que necesita para realizar su tarea. En concreto, puede ser un arbol de directorios en disco en el area de trabajo del desarrollador o una colección de ficheros mantenidad en un espacio abstracto por una herramienta. Está asociado con versiones particulares de las entidades. Debe disponer de un mecanismo para construir ejecutables a partir de su contenido.

Una codeline es un conjunto de fichero fuente y otras entidades que forman parte y que cambia a lo largo del tiempo. Cada vez que modificamos un fichero u otra entidad en el sistema de control de versiones, creamos una revisión de los mismos. Una codeline contiene cada versión de cada entidad a lo largo de un camino de evolución.

Dado que las ramas en las que se trabaja en paralelo no constituyen conjuntos disjuntos, el merge siempre tiene un overhead debido a posibles conflictos.

En cada uno de los patrones aparecen los problemas que intenta resolver y el esquema de solución.

Mainline
¿Cómo mantener el numero de codelines activas de manera que sea un conjunto manejable, y evitar que el crecimiento del arbol de versiones deproyecto lo lleve a ser demasiado amplio o demasiado denso? ¿Como evitar el overhead del merging?

mainlineDevelopment

Active Development Line
¿Cómo conseguir una codeline rapidamente evolucionable pero lo suficientemente estable para poder utilizarse?

labelingNamedStableBases

Private Workspace

Acabo de conseguir el libro Software Configuration Management Patterns: Effective Teamwork, Practical Integration de Stephen P. Berczuk, Brad Appleton y Kyle Brown en el que se abordan diferentes patrones para la Gestión de Configuración de Software. Además, encontre una presentación de G. Serrano basada en el libro que cubre sobradamente nuestros intereses.

En la práctica, la SCM se preocupa de como construir y lanzar un producto, así como de la identificación y el seguimiento de sus modificaciones.

Para empezar, ¿qué entendemos por patrón? La idea de patrón tal y como la utilizaremos aparece originalmente en el trabajo que el arquitecto Christopher Alexander hizo en construcción arquitectónica para describir las cualidades de un buen diseño arquitectónico. Define patrón como una “solución a un problema en un contexto”, como algo que “describe un problema que ocurre una y otra vez en nuestro entorno, y describe la esencia de la solución a dicho problema, de manera que puedes utilizar esa solución millones de veces sin tenerlo que hacer dos veces de la misma manera”.

El esquema de patrones que seguiremos es:

SCMPatternLanguage

Para poder generar los call graph y los caller graph desde doxygen necesitamos tener instalado Graphviz.

Aquí tenemos la direccion desde donde nos lo podemos bajar. En el caso de mac, es un pkg que instala el fichero binario dot en el directorio /src/local/bin. Tendremos que añadir este path en la variable DOT_PATH en la pestaña Expert de doxygen.

A continuación, unos ejemplos del tipo de diagramas generados:

Además, en la segunda captura podemos observar que las clases pueden mostrarse con estilo UML.

Cuando eramos niños, nos pasabamos el curso esperando la llegada de las vacaciones. Sin embargo, a medida que pasaban, cada vez tenías mas ganas de volver a las clases.

En esto de programar pasa un poco lo mismo. Cuando estas metido en un proyecto en el que te pasas dias y dias escribiendo, probando código y peleandote con los ordenadores, lo que mas desea uno en el mundo es acabar con aquello. Sin embargo, una vez terminado y pasado un tiempo, después de disfrutar de un merecido descanso y del placer y de la potencia de ver aquello funcionando, nos entra el gusanillo de volver a la carga.

Existen muchos modelos para el ciclo de vida del software, es decir, diferentes maneras de enfrentarte al reto de como desarrollar sofware. Sin embargo, con el tiempo y despues de acumular muchas “horas de vuelo”, uno ya tiene mas o menos definida su pequeña estrategia. Son cosas de sentido común, pero que no va mal tenerlas presente.

Para empezar, es muy importante tener una visión global del sistema, de manera que, nuestro primer diseño, es interesante que lo abarque todo. Para ello van bien, por ejemplo, realizar el diagrama de casos de uso, el diagrama de clases, y algunos diagramas de comunicación y de secuencia. Además, existe software que sera capaz de generarnos, a partir de ellos, la arquitectura de la aplicación, es decir, el conjunto de todos los ficheros de clases que necesitaremos y la interrelación entre ellos.

Sin embargo, en el momento de empezar a implementar el software, a escribir el programa, es mejor seguir una estrategia en espiral.

cuya idea de fondo es sencilla: no pretender programarlo todo de golpe sino hacerlo de manera incremental. Para ello, empezamos seleccionando un pequeño conjunto del global de los objetivos de nuestro software, seleccionaremos las clases que nos permitiran asumirlos, las implementaremos y las probaremos. Llegados a este punto habremos dado una vuelta en la espiral ya que estaremos en condiciones de volver a empezar la misma rutina con otro pequeño conjunto de objetivos pero con la diferencia de que nuestro programa habrá crecido con respecto a la vuelta anterior y lo que allí nos propusimos estará funcionando.

Pues nada, teniendo ésto presente y sin mas preámbulos, nos ponemos el mono de programador y, por fin, ¡a programar!

El Dr. Treb Lae y la Dra. Aini Vadh simulan colisiones de objetos compactos. Para poder hacerlas es para lo que me utilizan. Mi nombre es Tnala y soy una supercomputadora. Pero no una cualquiera, no, soy una de las que aparece en el TOP500.

—Vamos a hacer otra simulación —dice Treb—. ¿Qué colocamos esta vez?

—Probemos con una estrella de neutrones y un agujero negro. Pero vamos a cambiar algunas cosillas —contesta Aini.

Coge el ratón, se inclina sobre la pantalla y empieza a trabajar. Para empezar, distribuye los objetos sobre el escenario de la simulación, a continuación, define los parámetros que caracterizan a cada uno de los objetos compactos y, finalmente, modifica algunas cuestiones referentes a la propia simulación. Pero cuando ya parece que lo tiene, se reclina sobre la silla y se queda pensando. No lo tiene claro. Casi siempre, antes de empezar cualquier simulación, cambian una y otra vez las cosas. Es por eso que, hasta que no empiezo a simular, no pierdo el tiempo creado una y otra vez los diferentes objetos. Simplemente me guardo la información para luego.

—Creo que será mejor trabajar solo con estrellas —afirma finalmente Aini con determinación—. Probemos con dos estrellas con estas ecuaciones de estado, ¿te parece?

Treb se lo piensa. Tras el silencio esboza una leve sonrisa. Acaba de entender lo que pretende Aini.

—Perfecto. Creo que esta vez si que lo conseguimos —contesta feliz—. ¡Eres realmente brillante!

Aini sonríe contenta e inmediatamente lanza la simulación.

—¡Ya está! —exclama—. Vamonos. A ver si mañana tenemos buenas noticias.

Se marchan a casa a dencansar y me dejan. Yo no necesito descansar. Ahora es cuando me pongo manos a la obra.

Lo primero que hago es crear el escenario y colocar los objetos tal y como me lo han definido, para lo que utilizo la información que me he guardado previamente. A partir de ahora si que habrá cuerpos compactos creados de verdad. Inicializo el campo gravitatorio (una malla con nodos para la parte elíptica), añadiendo los posibles BH, e inicializó los fluidos de las NS, SS o DW (las partículas para la parte hiperbólica) junto con la descomposición espacial para las relaciones de partículas vecinas. Me guardo el estado inicial.

Ahora si que empiezo con la simulación, que es un vaivén entre la parte elíptica y la hiperbólica, es decir, miraré como el fluido me deforma el espacio-tiempo, desplazaré el fluido según esa deformación y volveré buscar como esa nueva distribución del fluido me modifica nuevamente el espacio-tiempo y vuelta a empezar.

Técnicamente, primero resuelvo el sistema elíptico para el paso de tiempo actual con lo que obtengo una métrica y una curvatura que necesitaré conocer para desplazar las partículas del fluido, que seguirán geodésicas. A continuación tengo que desplazar el fluido. Necesito conocer la densidad, la presión y la velocidad que recuperaré de la densidad, el momento y la energía. Para cada partícula calculo el valor de sus variables conservadas, para lo que necesito sus vecinas, el kernel, las eos y el solve rk4. Lo ideal sería tener un sistema que me resuelva esto para todas las partículas de forma simultánea (¿se puede?) y que en un futuro paralelizaré. Una vez resuelto, desplazo las partículas, actualizo sus vecinos y muevo los agujeros. Almaceno el estado. Finalmente, y antes de volver a empezar, revisó si el paso de tiempo es el apropiado (la simulación de la perdida de momento y de energía fruto de la radiación gravitacional en forma de ondas gravitatorias, así como la viscosidad y la conductividad térmica ya están incluidas en las ecuaciones discretizadas que usamos?).

Hago esto tantas veces como me han configurado, de manera que, en cuanto acabo, tengo almacenados el estado de la simulación en cada instante de tiempo, por lo que Treb i Aini podran visualizarlo y estudiarlo. Creo que el resultado si que es el que se esperaban. Me alegro por ellos (si es que puede una máquina alegrarse :-)).

La siguiente figura muestra un diagrama en el que se ve como se han comunicado los diferentes objetos:

A proposito, ¿sabeis a quién hacen honor los nombres de Treb Lae, Aini Vadh y Tnala? Envia un comentario con la respuesta correcta y participarás en el sorteo… 🙂

El software DualSPHysics es la versión paralela con CPUs y GPUs de SPHysics. El código se ha implementado esta vez en C++ y CUDA.

A continuación mostramos dos diagramas de colaboración de DualSPHysics generados automáticamente por doxygen,

Mostramos como, comentando correctamente nuestro diseño, Visual Paradigm for UML nos genera reports en PDF o HTML con documentación sobre nuestra aplicación.

A continuación mostramos un pequeño fragmento de como queda el HTML:

Otro diagrama disponible en UML 2 es el diagrama de comunicación.

El diagrama de comunicación permite modelar la interacción entre los diferentes objetos que se produce mediante mensajes en secuencia, es decir, muestra que mensajes se pasan los objetos entre si y en que orden. Es un diagrama muy útil, pues muestra tanto información estática, tomada del diagrama de clases, como información dinámica, tomada del diagrama de casos de uso y del  diagrama de secuencia.

A continuación muestro el diagrama de comunicación que he realizado mediante Visual Paradigm for UML de SPHysics:

Técnicamente, tendríamos que hablar de un pseudodiagrama de comunicación, pués el lenguaje de programción es fortran que no trabaja con orientación a objetos, por lo que en lugar de clases  tenemos módulos. Sin embargo, y salvando las distancias, cumple sobradamente su propósito semántico.

Una vez un profesor nos dijo algo así como: “No programeis lo que ya esta programado”, una especie de versión light de la reinvención de la rueda. Lo que quería decir era, sencillamente, que antes de empezar a diseñar algo desde cero para resolver un problema teniamos que investigar si ya existia un software capaz de hacerlo. Si la respuesta era negativa, adelante, pero si la respuesta era positiva, teniamos que plantearnos una serie de preguntas: ¿Es gratuito o hay que pagar por él? ¿Se adapta perfectamente a mis necesidades o necesita cierto grado de adaptación? ¿Tengo acceso al código fuente y tengo permiso para modificarlo a mi medida? ¿Que piensa el cliente al respecto? etc.

En el caso que nos ocupa, un sofware que promete es SPHysics, un esfuerzo conjunto de investigadores en la Johns Hopkins University (U.S.A.), la University of Vigo (Spain), la University of Manchester (U.K.) y la University of Rome La Sapienza (Italy). Evidentemente, se trata de hidrodinámica newtoniana y no magnetohidrodinámica relativista, por lo que hay un salto cualitativo en la física considerada, además de que se trata de programación modular y no orientada a objetos. Sin embargo, al ser de código abierto y disponer de versión paralela sobre CUDA, nos puede servir de mucha ayuda a la hora de implementar muchas cosas.

A continuación se enlazan dos simulaciones con 100M y 226M partículas en las que se puede apreciar la potencia del software:

Junto al diagrama de clases, que forma parte de los diagramas de modelado estructurado (visión estática del modelo) que ya hemos comentado, existen otros diagramas de modelado de comportamiento (visión dinámica del modelo) ampliamente utilizados como son los diagramas de casos de uso y los diagramas de secuencia.

El diagrama de casos de uso muestra cada una de funcionalidades del sistema modelado en una visión de caja negra de las mismas. Representa al sistema como un rectángulo que contiene tantas elipses como casos de uso diferentes junto con el actor o actores con los que interactuará.

Un ejemplo diagrama de casos de uso de nuestro sistema SPH con un solo caso de uso Simulation podria ser:

El diagrama de secuencia permite modelar cada caso de uso y describe la interacción entre los diferentes objetos de un sistema a través del tiempo para la consecución del mismo. Es por tanto una visión de caja blanca. Se representan los diferentes objetos como rectangulos o conjuntos de rectangulos en función de si son simples o multiples junto con flechas entre los objetos que representan los mensajes entre estos.

Un posible diagrama de secuencia del caso de uso Simulation podria ser:

A continuación se muestra una imagen con todos los fichero generados de forma automática:

y el código que contienen algunos de estos ficheros:

Cada instanciación de una clase define un objeto: Persona es una clase, Jose es un objeto, una instancia de Persona. La clase es una plantilla que permite crear objetos.

Una clase almacena un estado: un conjunto de atributos que guardan información del objeto; y un comportamiento: un conjunto de métodos que nos permiten trabajar con el objeto.

A continuación, nuestro diagrama de clases con una muestra de atributos, métodos y relaciones:

Cuando modelamos sistemas, ciertos componentes pueden estar relacionados con otros y estas interrelaciones deben ser modeladas. La relación de asociación es el tipo de relación básico entre dos clases. Se representa mediante una linea donde podemos incluir roles, cardinalidades, dirección y restricciones. Suele implementarse como variables de instancia de una clase en otra.

Con respecto a la implementacion, podriamos tener algo como:

//asociación: obj1 y obj2 tienen una relación.
public class Obj1 { void func(Obj2 obj2) {} };

Una relación de agregación es un tipo particular de asociación aparecido después y que permite describir cuando una clase está formada por otras clases. En las agregaciones, el ciclo de vida de una parte es independiente del ciclo de vida del todo, es decir, que si el padre se elimina, no se eliminan sus hijos. En el diagrama aparecen con una punta de flecha en forma de diamante negro en la clase padre. El código podría ser:

//agregación: obj1 posee a obj2 que se lo han prestado: cuando obj1 muere obj2 puede vivir.
public class Obj1 { private Obj2 obj2; Obj1(Obj2 obj2) { this.obj2 = obj2; } }

Una relación de composición permite describir el mismo tipo de relación que las agregaciones pero, por el contrario, la dependencia de sus ciclos de vida es mas fuerte: si el padre se elimina también se eliminan todos sus hijos, aunque una parte puede ser eliminada sin eliminar el todo. En el diagrama aparecen con una punta de flecha en forma de diamante blanco en la clase padre. En código:

//composición: obj1 posee a obj2 y es responsable de su tiempo de vida: cuando obj1 muere obj2 también muere.
public class Obj1 { private Obj2 obj2 = new Obj2(); }

La lista de clases obtenida junto con sus relaciones de generalización:

Imagen

(Diagrama realizado con Visual Paradigm for UML)

El diagrama de clases muestra los bloques con los que construiremos un sistema orientado a objetos. Describen la vida estática del modelo, mostrando que atributos y comportamientos ocurren sin entrar a detallar de que manera se realizan. También muestran las relaciones existentes entre las clases: generalizaciones que reflejan herencias, agregraciones para reflejar composición o uso y asociaciones para mostrar conexiones.

Para representar cada clase utilizamos un rectángulo con tres compartimentos. En el primero va el nombre de la clases, en el segundo sus atributos que pueden ir acompañados de su valor inicial y en el último los métodos junto a sus parámetros. La visibilidad se indica mediante los simbolos – para indicar que un atributo o método es privado, y + para indicar que un atributo o un método es público.

Una relación de generalización indica herencia. Se representa mediante una punta de flecha triangular en la clase padre que generaliza una clase hijo. Un objeto instanciado de la clase hijo heredará de manera implícita los atributos y métodos de su clase padre. En nombre de las clases abstractas va en cursiva.

Volviendo a nuestro diagrama particular, las clases abstractas las hemos indicado temporalmente mediante un borde discontinuo y los colores indican posibles paquetes: verde para clases específicas de SPH, amarillo para numericalMethods, azul para astrophysics y rojo para dataStructures.

Vamos a hacer una lista con todas las clases que creemos que vamos a necesitar para la implementación del método SPH y aplicarlo a simulaciones de problemas astrofísicos. A continuación pensaremos en sus atributos y métodos. Finalmente, interrelacionaremos las clases entre si. Para todo ello, nos apoyaremos en el Visual Paradigm. Empecemos:

  1. Dispondremos de un stage donde ocurre la acción de nuestra simulación. Este contendrá una clase abstracta spatialDecomposition que podremos implementar posteriormente en las clases derivadas bsptree, octree, kdtree, linkedList y que utilizaremos para selección de partículas vecinas incluso con h variable. También necesitamos una clase mesh/grid para ir resolviendo las ecuaciones de campo de Einstein, que constituyen un problema PDE elíptico, e ir obteniendo el campo gravitacional en el que se mueve nuestro fluido. Por tanto, también necesitaremos un ellipticSolver que derivaremos en spectralSolver o finiteDifferenceSolver.
  2. Necesitamos una clases fluid que almacenará toda la información referente a un fluido .
  3. Los fluidos nos permitiran modelar compactObjects como blackHole, neutronStar, strangeStar… y en donde dispondremos de una operacion merge.
  4. Y también la clase particle que permitirá almacenar la información de cada una de las partículas de nuestros fluidos.
  5. La clase kernel nos permitirá evaluar la función kernel. Como ya comentamos en un post, para ofrecer la posibilidad de utilizar diferentes funciones kernel, la clase kernel será abstracta ofreciendo métodos virtuales que implementaremos en las clases derivadas gaussianKernel, quadraticKernel, cubicKernel, quinticKernel, tensorialKernel.
  6. Necesitamos también una clase odeSolver que utilizaremos para resolver las distintas ODE que aparecen al “discretizar” las ecuaciones de la hidrodinámica. Como tenemos diferentes posibilidades, la implementaremos en una clase abstracta cuyos métodos virtuales los implementaran rungeKutta2OdeSolver, rungeKutta4OdeSolver, velocityStormerVerletOdeSolver, leapfrogOdeSolver, modifiedEulerOdeSolver y que nos permitirá utilizar cualquiera de ellos indistintamente.
  7. La clase abstracta eos nos permitirá trabajar con diferentes ecuaciones de estado.
  8. Desde el punto de vista matemático, necesitamos definir una clase tensor y sus casos particulares scalar, vector y matrix.
agosto 2017
L M X J V S D
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031