Buscar este blog

miércoles, 27 de mayo de 2015

Metodología OMT.


Qué es la metodología omt o de rumbaugh?
 
Es una de las metodologías de análisis y diseño orientadas a objetos más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.[1]

Para qué se utiliza el diagrama de objeto?

Los diagramas de objetos permiten representar gráficamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: los diagramas de clases y los diagramas de casos concretos (instancias). Los diagramas de clases describen las clases que componen el sistema y que permitirán la creación de casos concretos, los diagramas de casos concretos describen la manera en que los objetos del sistema se relacionan y los casos concretos que existen en el sistema de cada clase. En los diagramas que componen este modelo se pueden representar los siguientes elementos del sistema: objetos y clases, atributos, operaciones, y relaciones o asociaciones.

Fig. 1.0 Organización de la metodología OMT

Fases del diseño:

Las fases que conforman a la metodología OMT son:

Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos.


En esta parte se maneja de forma exacta la construcción de los modelos objetos. 
Pasos: 

IDENTIFICACIÓN DEL MODELO OBJETO: 
  • Identificar los Objetos y Clases. 
  • Identificar la asociación entre Objetos. 
  • Identificar los atributos. 
  • Agrupar las clases y módulos. 
  • Preparar el diccionario de datos.  
IDENTIFICACIÓN DEL MODELO DINÁMICO:

  • Definir para cada objeto qué eventos tendrá. 
  • Construir los diagramas de estado para el comportamiento de los objetos.
IDENTIFICACIÓN DEL MODELO FUNCIONAL:
  •  Manejar la elaboración de diagramas de flujo de datos para identificar la independencia que existe entre operaciones. 
  • Distinguir los valores de entrada y salida.






Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.




Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.).




Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad.




Diagrama de objetos vs. de clase:




Un video que explica vagamente las diferencias principales sobre un diagrama de clases y otro de objetos.






Ventajas

  • Proporciona una serie de pasos perfectamente definidos al desarrollador.
  • Tratamiento especial de la herencia.
  • Facilita el mantenimiento dada la gran cantidad de información que se genera en el análisis.
  • Es fuerte en el análisis

Metodología OMT 2:

-OMT2 declara que los casos de uso están limitados a la etapa de análisis de OMT. Esto requiere añadir 2 nuevos modelos a la etapa de análisis:
  • Modelo de dominio. Este modelo es creado explorando el dominio general y adquiriendo conocimiento de las tareas que serán efectuadas. 
  • Modelo de aplicación. Este modelo es construido sobre el modelo de dominio examinando los casos de uso del dominio.
-—Introduce cambios en el modelo de objetos para hacerlo compatible con UML.


Conclución:


Resulta fundamental entender las diferencias entre un diagrama de clases y uno de objetos motivo por el cual puse el video informativo anterior, OMT según lo leido es una metodología madura y eficiente, lo que resulta útil a la hora de definir con precisión la estructura del sistema lo cual lo vuelve una herramienta ideal para el diseño en la ingeniería de software. Se debe tener eso si una referencia adecuada para no caer en un espaguetis de clases.







Fuentes:


[1] Victor E Chavez and Juan C Olivares, "Metodología OMT," Monografía 2013.
[2] geocities. [Online]. http://www.geocities.ws/alpizarcbh/archivos/tapsu4.pdf
[3] http://es.slideshare.net/MCruz29/analisis-y-diseo-de-sistemas-2-momt
[4] https://adnerugma.wikispaces.com/file/view/OMT4.pdf

lunes, 11 de mayo de 2015

Github, plataforma de desarrollo colaborativo utilizando git.


Qué es un software de control de versiones? 


Un software de control de versiones es utilizado para gestionar las modificaciones de un software de en un entorno compartido, la mayoría de éstos softwares son utilizados tanto para gestionar
el código como la documentación, esquemas, diagramas, hasta dibujos, entre otros recursos, lo que lo hace útil para no solo un entorno de desarrollo, si no también de diseño. Estos softwares están pensado en el desarrollo en un entorno compartido, donde trabajan desde unos cuantos a decenas de personas sobre un mismo proyecto, como por ejemplo un par de programadores trabajando sobre un mismo repositorio (figura 1.0).

Figura 1.0: Trabajando en un mismo repositorio.

Por qué github?


Github es uno de los lideres de plataforma de desarrollo colaborativo en la actualidad, utiliza el control de versiones git que opera sobre una plataforma online donde los usuarios de ésta comunidad suben sus proyectos, repositorios y códigos. Además de mostrarte cuales son los lenguajes actuales, te permite trabajar sobre repositorios existentes subidos por usuario. Git es en la actualidad el software de control de versiones mas utilizados por los programadores, a pesar de que muchos desarrolladores optan por mercurial, cvs, svn, etc, la gran mayoría elige github por la inmensa comunidad que tiene por detrás y el gran numero de repositorio disponible gracias a ésta comunidad.


Ejemplo de código c++ modificado en github.


Leyenda: en un tono de magenta se ven las lineas de código de versión anterior, y en verde las modificadas.

Para comenzar con github


Git immersion es una página dónde se puede descargar git, es muy útil para empezar a entender el software. Sitio: http://gitimmersion.com

Github tiene también su tutorías para principiantes, así cómo hay numerosos videos que ayudan a entender a la plataforma y/o al scv.

Aquí un video interesante con una breve introducción a los sistemas de control de versiones.






Blog bastante interesante y amplio para comenzar con github:
http://conociendogithub.readthedocs.org/en/latest/data/dinamica-de-uso/

Git para científicos de la computación



Demostraciones de cómo se puede utilizar git para diferentes aspectos de la ciencia de la computación. Sitio:http://eagain.net/articles/git-for-computer-scientists/




jueves, 30 de abril de 2015

Metodología SUM: Metodología orientada al desarrollo de videojuegos.

Metodología SUM y actualidad



Prologo


En referencia a éste informe, mas allá de un trabajo de campo de la cátedra, espero que sirva como información de interés para compañeros, colegas programadores, e incluso aquellos que tienen un titulo de programador/desarrollador... ya que es inmenso nuestro campo de acción, año a año vemos el crecimiento exponencial del área, motivo por el cual me cuesta des-contextualizar información, cuando es mucho lo que se quiere decir y poco lo que damos a entender, algunos datos interesantes y por el cual pensé en ésta metodología como el hincapié de algo mas grande (si ya no lo es).
Comenzando por la idea de que muchos de nosotros tenemos ganas de proyectos grandes, pequeños, ambiciosos, simples, prácticos, robustos, etc. pero nos acobardamos por la tonelada de información redundante o algunas veces equivoca, o parcial  y el sopesar de tener que investigar e instruirnos por nuestra cuenta, tal vez nos sentimos inhibidos por la faltas de recursos, o incluso el hecho de que no sería algo serio por ser solo nosotros, o "yo y uno mas". En mi caso es el hecho de poder desarrollar pequeños proyectos de software con cuales cuento con la mínima cantidad de recursos, en si no imaginé tener la necesidad de una metodología para el desarrollo(por simple ignorancia) lo cual hacía que se vuelva una labor totalmente inestable y difícil de retomarla. Ya trabajando en equipo la perspectiva es otra, la metodología se vuelve totalmente imprescindible. La organización que propone sum es la utilización de los mismos roles y estructuras que se utilizan en scrum, pero con ciertas adaptaciones necesarias para la producción del desarrollo, en éste caso el juego.



Introducción a la metodología



La metodología sum es una metodología basada en scrum, utilizando la tendencia de las metodologías agile debido al contexto con el que se trabaja, programación rápida, precisa, optimizada y adaptable son requerimientos comunes de los proyectos en cuestión, con el que se cuenta poco personal, poco tiempo y un escenario dinámico, con pocas características y funcionalidades bien especificas.
La metodología surge básicamente como la necesidad de cumplir con un proyecto con escasa cantidad de recursos, pero con una fuerte cohesión entre ellos utilizando una metodología adecuada para el trabajo, es ahí cuando SUM surge como la solución frente a éstos parámetros de trabajos. Muchas de las industrias de videojuegos de hoy en día utilizan la metodología scrum para el desarrollo, como es crytek, DICE, nokia, cuales cuentan con un nutrido número de recursos, por ello SUM se basa en scrum con para "poco personal".

Citando parte de una definición "Pretende obtener resultados predecibles, ad-ministrar eficientemente los recursos y riesgos del proyecto,
y lograr una alta productividad del equipo de desarrollo. SUM fue concebida para que se adapte equipos multidisciplinarios pequeños (de tres a siete integrantes que trabajasen un mismo lugar físico o estén distribuidos),
y para proyectos cortos (menores un año de duración) con alto grado de participación del cliente."[1]




Etapas de desarrollo en SUM:




Ciclo de desarrollo SCRUM.



-Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.
-Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.
-Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.
-Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.
-Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

-Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.






En la actualidad


 Una de las características mas relevantes del desarrollo de videojuegos con sum es la continua "adaptación" que sufre un juego en la actualidad, hoy en día una inmensa mayoría de los juegos no tienen un ciclo de desarrollo definitivo, me refiero a que no culminan en un alpha final, características como son la alta disponibilidad, las velocidades de respuestas inferiores a los 200 ms y la gran interconexión mundial generan una evolución de los juegos hacia el entornos online.
No es ninguna novedad entonces que se necesite de una metodología ágil para lidiar con esta dinámica, aunque para ésto ni siquiera sum es tendencia principal.
En la actualidad las mayorías de los grandes desarrolladores no optan por una metodología en si, coinciden con el hecho de que muchas metodologías podrían utilizarse en un mismo momento; entre ellas son según Blizzard Entertainment..."(Scrum, Agile, Kanban, Cascada y Seis Sigma, entre otras)" [3].




Aspectos importantes (método de usabilidad)


Tal vez se note en la parte de "etapas", cómo la etapa de beta es necesariamente un ciclo de enésimas repeticiones, ésto es debido a que cada vez más se utiliza el método de usabilidad * como parte del desarrollo del software por medio de la ingeniería de la usabilidad, vuelvo a mencionar la necesidad de mantenerme en contexto por la gran cantidad de tendencias en el ámbito, ésto es debido a que cada vez mas se hace hincapié en la incorporación del usuario al desarrollo de "su" sistema logrando así evitar la distancia típica del usuario/desarrollador, como el sistema del desarrollador y no del usuario.

citando la descripción de usabilidad según la norma ISO/IEC 9126:
..."La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso"...

*Método de usabilidad: Es un método de testeo el cuál está constituido por diversas características, pero entre ellas, una de las mas utilizadas en la industria del desarrollo, es la empleada en la etapa de testeo, y consiste en involucrar al mismo usuario para el testeo del beta del sistema en cuestión. Facilita la adaptación del sistema al usuario, y no a la inversa, se ahorran en recursos, logra que se rompa la brecha entre las perspectiva del desarrollador y la del usuario. 



Tradicionales vs evolutivas.



No existe una tendencia definitiva que remarque la necesidad de UN sólo camino de metodologías para el desarrollo del software, aún así se podría decir que si, el camino definitivo es la adaptación de varias metodologías a un solo producto, de manera que no se vuelve obsoleta una metodología tradicional, ni tampoco se vuelve una actual como la única tendencia, más bien, el equipo es quien usa las metodologías, y no la metodología es quien utiliza un equipo.



Como ya se mensionó mas arriba (en la subsección "En la actualidad") todos pueden utilizar cualquier metodología, si sirve para lograr el proyecto, cualquier metodología podría adaptarse al contexto adecuado, o cualquier contexto puede encuadrar en diversas metodologías, solo existe una frontera, y esa frontera es nuestra perspectiva.










Cifras en el mercado de la industria de videojuegos. 


Los "juegos de computadora" o mas bien conocidos como videojuegos, si bien tienden a ser indiferentes para un gran número de personas, es una de las industrias mas insaciables de todos los tiempos, tan solo en el 2000 ( épocas cuales los juegos no se beneficiaban aún tanto por el fenómeno de internet) la industria de los videojuegos llegó a superar a la del cine y de la música juntas, se prevé que en éste año(2015) se llegue a los 82.000 millones de euros.




Fuente:

[1] Nicolas Acerenza, Gustavo Meza, and Ariel coppes. (2009) Una metodología para el desarrollo de Videojuegos. Informe.
[2](2007) SUM para Desarrollo de Videojuego. [Online]. http://www.gemserk.com/sum/
[3] Blizzard entertainment. (2015) Carreras en blizzard. [Online]. http://eu.blizzard.com/es-es/company/careers/roles/production.html