INFORME ARQUITECTURA DE SOFTWARE

Como pugali es un red social corporativa necesitamos implementar una interfaz simple para el usuario y al mismo tiempo manejar subsistemas complejos por detrás que manejen la lógica del negocio. Es para esto que se recomienda la utilización del patrón “Remote facade”. Además al ser una aplicación compleja que manejará hartas vistas e interfaces dependiendo del cliente y del dispositivo utilizado, es que su crecimiento será exponencial. Al utilizarse en empresas grandes se hace necesario que sea escalable, ya que su edición será constante es necesario un patrón que divida las responsabilidades para esto se propone “Modelo-Vista-Controlador”. También se debe resolver la cuestión de cómo se trabajarán los datos de sesión del cliente, si queremos obtener información de las acciones de loggeo o no, y si, tomando en cuenta la cantidad de datos transferida por cada cliente, es aceptable enviar los datos del cliente en cada consulta y la persistencia de los datos del cliente aunque no este conectado es necesario…es considerando esto más las características de Pugali que se recomienda usar el patrón “Client Session State”. Mas detalles en el link

https://dl.dropboxusercontent.com/u/42013397/informe%20final%20practica.docx

PEEA: Caso Pugali.

Dentro del Proyecto Pugali, se pueden utilizar los siguientes patrones arquitectonicos de aplicaciones empresariales:

1. Domain Model: aquel que organiza lógicas de dominio complejas, es decir, aquellas que realizan calculos complejos con los datos y validación de gran cantidad de datos, entre otras funcionalidad complejas.
   
   En Pugali se tiene una gran cantidad de relaciones entre las clases de la aplicación y, ademas, los calculos y validaciones que se generán para las evaluaciones, van aumentando a medida que mas personas utilizan el sistema. Todo esto genera una lógica de dominio compleja y lentitud en procesamiento, por lo que es necesario un patrón, como domain model, que organize eficientemente el sistema.
   
   
2.  Two Step View: aquel que divide el desarrollo de las vistas en dos partes, la primera genera una pantalla lógica desde los datos del dominio, y la segunda, genera la vista única de las pantallas lógicas en un único HTML.
   
   En Pugali se busca que la aplicación sea usada desde moviles como de paginas web como tambien que los cambios en el HTML sea reflejado facilmente en ambas plataformas. Para esto se debe compartir un mismo diseño entre paginas, haciendo que el HTML se genere en un solo lugar. Lo anterior se lograr a traves del patrón de diseño Two Step View y sus dos partes explicadas anteriormente.
   
   
3. Unit Work: aquel que mantiene un registro de los objetos leidos o modificados desde la base de datos, todo esto para evitar problemas de concurrencia que se puedan producir por algún proceso que funciona al mismo tiempo que la aplicación trabaja con los objetos del dominio.
   
   En Pugali se busca que las evaluaciones realizadas se carguen y salven exitosamente en la base de datos, es por ello, que a traves de Unit Work, se puede seguir la pista de cada nueva evaluación y asegurar la escritura exitosa en la base de datos.

Autor: Pablo Vásquez M.

Referencias:

• http://msdn.microsoft.com/es-es/library/bb972251.aspx
• http://ocw.udl.cat/enginyeria-i-arquitectura/enginyeria-del-software-iii/Continguts/2%20-%20Patrones/Patrones%20Arquitectonicos%20de%20Aplicaciones%20Empresariales.pdf 

Patrones de diseño arquitectónico para aplicaciones empresariales

En este trabajo se presenta la descripción de algunos patrones arquitectónicos para aplicaciones empresariales, que en este caso puedan ser utilizados en el sistema pugali. Además se entrega una pequeña explicación del problema especifico que se resolvería con la utilización de ese patrón.

En este documento se describen los patrones : MVC, Client Session State y Data Mapper. 

Y además se entrega la fundamentación de por qué se deberían aplicar en pugali.

Descargar el documento aquí.

Patrones de diseño Pugali - José Camacho

Resumen

A la hora de realizar un desarrollo de software, hay que contemplar varios aspectos y etapas del proyecto. Una de estas etapas es la de arquitecto de software, en la cual es necesario definir el diseño y especificación de la estructura global del sistema, de cómo se relacionara cada parte del sistema. En esta etapa pueden aparecer muchas complicaciones y problemas a solucionar, para esto existen Patrones de Arquitectura de Aplicaciones Empresariales.

Estos patrones han sido creados para solucionar problemáticas que se han repetido en el tiempo, con soluciones que han sido probadas y utilizadas durante años.

De esta manera es necesario conocer los patrones existentes para así poder implementarlos en los sistemas a desarrollar.

Link Documento

Referencias:

http://www.martinfowler.com/eaaCatalog/index.html

http://metodologiasdesistemas.blogspot.com/2008/02/estrategias-para-persistir-objetos.html

http://ocw.udl.cat/enginyeria-i-arquitectura/enginyeria-del-software-iii/Continguts/2%20-%20Patrones/Patrones%20Arquitectonicos%20de%20Aplicaciones%20Empresariales.pdf

Patrones de arquitectura que se pueden usar en el proyecto Pugali Alumno: Alexis Miranda Neira

Patrones de arquitectura

Domain Model

Permite resolver la complejidad de la lógica de negocios en un Sistema de Información, principalmente en sistemas grandes.Debido a que el comportamiento de las empresas está sujeto a una gran cantidad de cambios, existe la necesidad de tener un modelo de dominio el cual reduce el costo total de esos cambios, de tal manera de encapsular todo el comportamiento de la empresa(reglas de negocios asociadas a estos datos) y reducir una gran cantidad de tiempo, debido a que todos los cambios se realizarán en un solo lugar.

Data Mapper

Resuelve el problema de tener que depender de una tecnología dada de persistencia, de una base de datos en específica, por ejemplo Mysql, postgresql, sql server, etc.De esta forma Data Mapper nos permite abstraernos de la base de datos, cumpliendo su función, preocupandose sólo del modelo del dominio, con el diseño de diagrama de clases con las asociaciones pertinentes.

Mvc

El problema principal, es tener que mantener aplicaciones donde la lógica de negocios, acceso a fuentes de datos y código de presentación estén presentes en un solo lugar, sea clase, librería o en una sola página.La experiencia indica que estas aplicaciones son muy difíciles de mantener, por lo tanto se prentende encapsular estos 3 componentes en sitios distintos, ahorrando tiempo en el desarrollo, mantención, reutilizando código fuente.Estos 3 componentes son los modelos, las vistas y los controladores.

Alumno: Alexis Miranda Neira

Enlace:https://www.dropbox.com/s/ksu7ki8bm29q914/3patronesdearquitecturadesoftware%20%281%29.pdf

Patrones de diseño de Arquitectura Pugali - ALUMNO: PATRICIO PARRA PONCE

Arquitecturas que se pueden utilizar en Pugali:

Data Mapper

Ésta arquitectura de software propone que los objetos de negocio no tenga nada de código que los acople a una tecnología de persistencia debido a que no es su función manejarla. Los objetos de negocio solo se preocupan de cumplir con el modelo de dominio a través del diseño del diagrama de clases con las asociaciones pertinentes. La responsabilidad del data mapper recae en que debe transferir datos entre los objetos y la base de datos y debe aislarlos, de ésta forma, los objetos que están en memoria no necesitan saber siquiera que hay una base de datos, no tienen necesidad de código SQL.

Modelo Vista Controlador:

El modelo Vista Controlador es un patrón para desarrollar aplicaciones que se basa en separar los datos, la interfaz de usuario y la lógica interna. Se utiliza comúnmente en aplicaciones web donde la vista es la página HTML, el modelo es la base de datos y la lógica interna y el controlador es responsable de recibir eventos y darles una solución. Las capas se separa en:

1) Modelo: Es la representación de la información en el sistema. Trabaja junto a la vista para mostrar la información al usuario y es accedido por el controlador para añadir, eliminar, consultar o actualizar datos.

2) Vista: Es la presentación al modelo en un formato adecuado para que el usuario pueda interactuar con él, casi siempre es la interfaz de usuario.

3) Controlador: Es el elemento más abstracto. Recibe, trata y responde los eventos enviados por el usuario o por la propia aplicación. Interactúa tanto con el modelo como con la vista.

Special Case Pattern/ Null Object Pattern:

 

La solución que propone éste patrón es devolver un objeto nulo. La ventaja de devolver un objeto nulo en lugar de un valor null es que no hay que verificar el valor de retorno porque de hecho es una lista.

La clave del patrón Null Object es una clase abstracta que define la interfaz para todos los objetos de éste tipo. Se implementa como una clase derivada de dicha clase abstracta. Por lo que puede ser usada en cualquier lugar que este tipo de objeto sea necesario.

La clase Objeto Null, tiene la misma interfaz que una clase Real y sabe qué hacer en cada uno de sus métodos. La alternativa a usar este patrón, es usar el valor "null" que, evidentemente, no implementa la interfaz abstracta




MAS EN EL SIGUIENTE LINK


https://dl.dropboxusercontent.com/u/34645170/Patrones%20de%20Dise%C3%B1o%20de%20Arquitectura%20PUGALI%20(PATRICIO%20PARRA).docx


ALUMNO:

PATRICIO PARRA PONCE

Comandos de Git

Comandos elementales:

git help <command> 

git clone <uri> namedir  # clona  un repositorio usando como nombre de directorio namedir.

git add *   # añade recursivamente todos los archivos modificados o nuevos al stage.

git diff --staged   #compara los cambios en el stage con el ultimo commit

git commit # muestra el diff en el editor

git rm --cached <file or regexp> #Remueve archivos añadidos al stage.Los deja en el directorio de trabajo

git rm <file>  #borrar archivos de git.

git mv <file> <renamed_file> #cambia el nombre de un archivo en git

gitk --all #  Herramienta gráfica para git

git commit --amend #Modificar el mensaje del último commit

git reflog  # muestra un listado con todos los commit realizados como HEAD@{0} por ejemplo.

git reset --hard HEAD@{2}# vuelve al commit numero 2 de la lista entregada por git reflog.

git checkout -- <file> # Descartar cambios en el directorio de trabajo para el archivo file.

git add -i #añade archivos al stage de manera interactiva.

Comandos remotos

• git fetch origin # Descarga los objetos  del servidor remoto
• git push origin <branch> #sube la rama <branch> al servidor remoto origin.
• git push origin master # sube los commits realizados en la branch actual a la branch master en el remoto origin al servidor remoto.
• git pull origin master #actualiza la branch actual con la rama master del servidor remoto origin.

Comandos de branches

• git branch <nombre-rama> #crea rama. Puntero al commit actual
• git branch <nombre-rama>  <alguna-branch> #crea una rama putera a <alguna-branch>
• git checkout <nombre-rama> #cambiar a la rama especificada.
• git checkout -b <nombre-rama> #crea  la rama <nombre-rama> y cambia a la rama creada.
• git merge <rama> # Mezcla la rama actual con <rama>
• git branch -d <rama> #elimina la rama
• git push origin --delete <branchName> # Elimina una rama del servidor remoto
• git mergetool #Herramienta gráfica para resolver conflictos
• git branch # lista ramas
• git branch -r # listar ramas remotas
• git branch -v # lista ramas mostrando último commit
• git branch --merged #lista ramas que han sido mezcladas con la actual. Si no tienen un *, pueden borrarse, ya que significa que se han incorporado los cambios en la rama actual.
• git branch --no-merged #lista ramas que no han sido incorporadas a la actual.

Comandos útiles

• git log #revisar los commit que existen en la branch actual
• git show <SHA-1> #ve los cambios realizados en un commit <SHA-1>, dado por el git log
• git blame <archivo> #muestra cada linea de código, mostrando quien modifico o agrego esa linea, la fecha y hora que la realizo el commit y el <sha-1>  en el cual se agrego esa linea.

Sistema de control de Versiones

Sistema de control de versiones

¿ Qué es el sistema de control de versiones?

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de ellos a lo largo del tiempo, de modo que puedas recuperar versiones especificas mas adelante.

Ejemplos de algunos sistemas de control de versiones:

• CVS
• Subversión
• SourceSafe
• Darcs
• Plastic SCM
• Git
• Mercurial

Todos los sistemas de control de versiones(SVC), nos proporcionan:

• modos de almacenamientos de la  información(código fuente,archivos..)
• posibilidad de cambios sobre esos elementos(añadir,borrar,mover,etc)
• crear informes del estado de los archivos
• registro histórico(de los cambios realizados,versiones anteriores y permite volver a un estado de  versión anterior)
• Se diferencian 2 tipos de SVC los centralizados y los  distribuidos.

Sistema de control de versiones Centralizados:

Existe un repositorio centralizado con todo el  código con un  único administrador,todas las  decisiones importantes necesitan la  aprobación del responsable.

Estos sistemas, como CVS,Subversion y Perforce, tienen un único servidor que contiene todos los archivos versionados y varios clientes que descargan los archivos de ese lugar central.Durante muchos años, este ha sido el estándar para el control de versiones.

desventajas:

• Si el servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que estaba trabajando.
• Si el disco duro en el que se encuentra la base de datos central se corrompe y no se han llevado a cabo copias de seguridad adecuadamente,se pierde absolutamente todo.

Sistema de control de versiones Distribuidos(SVC):

En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor se cae o "muere", y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes se pueden copiar en el servidor para restaurarlo.

Se pueden crear diferentes grupos de personas, manteniendo la coordinación y trabajar de manera simultánea.

Esto permite establecer varios tipos de flujos de trabajo que NO son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.

Git como SVC:

Git, es un sistema de control de versiones (SVC) distribuido, creado por  Linus Torvalds, que  gestiona los cambios del software, nos facilita la administración de los  distintos cambios que se realizan en nuestro proyecto.

Ventajas:

• Velocidad
• Diseño sencillo
• Fuerte apoyo al desarrollo no lineal (miles de ramas paralelas)
• Completamente distribuido
• Capaz de manejar grandes proyectos como el núcleo de Linux de manera eficiente (velocidad y tamaño de los datos)

¿Porque Git y no otro sistema de control de versiones?

Aparte de que Git es un sistema de control de versiones distribuido, otra  principal diferencia entre Git y cualquier otro VCS (Subversion y compañía incluidos) es cómo Git modela sus datos.La mayoría de los demás sistemas almacenan la información como una lista de cambios en los archivos, como en la siguiente figura:

Otros sistemas tienden a almacenar los datos como cambios de cada archivo respecto a una versión base.

Git modela sus datos más como un conjunto de instantáneas de un mini sistema de archivos. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente hace una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa instantánea. Para ser eficiente, si los archivos no se han modificado, Git no almacena el archivo de nuevo — sólo un enlace al archivo anterior idéntico que ya tiene almacenado, como en la siguiente figura:

Los 3 estados de Git

Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged). Confirmado significa que los datos están almacenados de manera segura en tu base de datos local. Modificado significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos. Preparado significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación(commit).

Esto nos lleva a las tres secciones principales de un proyecto de Git: el directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).

Directorio de trabajo, área de preparación, y directorio de Git

                            

El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador.

El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar.

El área de preparación es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación. A veces se denomina el índice, pero se está convirtiendo en estándar el referirse a ello como el área de preparación.

El flujo de trabajo básico en Git es algo así:

1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de preparación.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación, y almacena esa instantánea de manera permanente en tu directorio de Git.

Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified). 

Estado de los archivos en Git

Cada archivo que se encuentra en el directorio de trabajo puede estar en uno de 2 estados:

• Tracked(rastreado por Git) :

            Son aquellos archivos que fueron commiteados o son aquellos que fueron clonados de un proyecto que ya estaba en marcha.Los archivos tracked que no han sido modificados son unmodifieded (no han sido modificados), si se editan o cambia  algún archivo, pasan a ser modified (modificados),si se usa el comando git add para añadir esos archivos modified, entonces se dice que están en el staged, listos para ser "commiteados".

•  untracked(no rastreado por Git):

          Son aquellos archivos que fueron recién creados en nuestro directorio local y por lo tanto no esta siendo seguido por Git, y es un archivo que no se ha "commiteado", una vez que sea haga un commit sobre el o se suba al repositorio local, entonces estará Tracked.

En la siguiente figura se muestra este ciclo.