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.