Hoy me llamo mucho la atención esta noticia, donde CNN destaca una encuesta sobre los mejores trabajos en America,  y los trabajos relacionados con las tecnologías de información no han salido tan mal parados, vean.

• Information Technology     Systems Engineer     1
• Information Technology     Information Technology Project Manager     5
• Information Technology     Computer/Network Security Consultant     8
• Information Technology     Software Developer     12
• Information Technology     Software Product Manager     16
• Information Technology     Business Analyst, IT     17
• Information Technology     Technical Writer     28

La verdad que creo que en Nicaragua esta encuesta estaria encabezada por otras carreras, seguramente Derecho o Turismo. Pero las carreras de informática estan demostrando que si tu te preparas bien podrás tener acceso a muy buenos salarios o incluso trabajar como Freelance por tu cuenta, como he echo yo en algunas ocasiones.

Respecto al nivel de vida que ofrecen las carreras, la de desarrollador de sistemas está en 4º lugar.

• I1      Education/Training Consultant      35      60.0%
• 2     Physical Therapist     7     59.5%
• 3     College Professor     3     59.2%
• 4     Software Developer     12     59.0%

Otro dato interesante es que el área de desarrollo de sistemas esta dando trabajo

• 1      Telecommunications Network Engineer      30      53%       21,000
• 2     Systems Engineer     1     45%     88,000
• 3     Personal Financial Advisor     N.A.     41%     20,000

Lamentablemente no estamos entre los mejores pagados, estamos en un 8º lugar.

• 1      Anesthesiologist      11      $292,000
• 2     Physician/Ob-Gyn1     22     $222,000
• 3     Psychiatrist     24     $177,000
• 4     Nurse Anesthetist     15     $157,000
• 5     Sales Director2     10     $140,000
• 6     Actuary     N.A.     $129,000
• 7     Finance Director     29     $121,000
• 8     Software Architect3     N.A.     $117,00

¿Crees que esta lista refleja la condición laboral en Nicaragua para los Programadores?

La mejor forma de analizar es con la Metodología, UML es un buen lenguaje para analizar. Yo anteriormente presente una Metodología muy buena, que use en mi Monografia, Fusión.

• Fusion Parte I
• Fusion Parte II
• Fusion Parte III

Pero lo dificiles para muchos, sobre todo los que inician programando y luego usan UML como herramienta de documentacion (mala idea), se les hace dificil modelar.

Iniciare con algo sencillo.

Herencia

La herencia, simplemente se dibuja como una Generalización en UML y se representa en Java como un extends.

package org.jp.developer.test;
 
public class Padre {
 
}
 
public class Hijo extends Padre {
 
}

Asociación

Las asociaciones son instancias de clases dentro de otras clases, pero sin ninguna relacion directa o indirecta, solo estan relacionadas.

//Asociacion Directa
public class Hijo {
	Padre padre;
}

Asociacion Directa

En este ejemplo, Padre e Hijo, Padre es el cabeza de familia, pero la Vida del Hijo no depende de la del padre, solo tiene una relacion familiar, por eso la relación directa, se dibuja una flecha de Hijo->Padre, pues Hijo es el que tiene relacion con el Padre. Si en el caso que Padre tuviese una instancia de Hijo la relacion seria Bidireccional y se dibuja como una linea recta.

Asociaciones con Multiplicidad

Existe multiplicidad, cuando existen Objetos como Array, List, Vector, Collection, donde representa que se pueden almacenar uno o muchos objetos, en este caso Padre.

//Asociacion 0 a Muchos
public class Hijo {
	private List ListaPadres;
}

Agregación y Composición

La agregación y la composición pueden ser un poco confusas, una agregación en Java se representa como una Asociación, pero tiene un enfoque diferente, la agregacion representa una parte de un todo, pero no necesariamente tiene que existir para que el todo exista, es el caso de Aplicacion y Base de Datos, una aplicación puede existir sin ella, igualmente una Base de Datos no necesita una Aplicación para existir. En el caso de la composición, es diferente, en el ejemplo puse la clase Codigo, que es parte de la composición de Aplicación, que no puede existir sin Código, por eso se dibujo como una Composición.

package org.jp.developer.test;
 
public class Aplicacion {
	private Codigo codigo;
	private BaseDeDatos bd;
}
public class Codigo {
}
public class BaseDeDatos {
}

La etapa final de la metodología de Fusión es la conversión del diseño en una implementación efectiva.  La transición es relativamente sencilla ya que las decisiones más complejas en cuanto al diseño ya han sido tomadas.  La implementación debe ser correcta, debe satisfacer los requerimientos, al mismo tiempo debe ser económica y no debe hacer uso excesivo de los recursos ni exceder el tiempo y el almacenamiento estipulado.

El resultado de la fase de implementación es el software que satisface los requisitos funcionales y no funcionales.

El proceso de implementación se encuentra dividido en tres partes: codificación, desempeño y revisión.

1. Codificación: En esta etapa existen cuatro elementos a traducir: El ciclo de vida, la descripción de las clases, el contenido de los métodos y el diccionario de datos.




2. Desempeño: El desempeño de una aplicación debe ser considerado desde el análisis, diseño y proceso de implementación.  No es necesario ser obsesivo con respecto al mismo, si la aplicación carece de velocidad se debe examinar cada componente de forma individual para saber en dónde focalizar los esfuerzos.  La depuración de partes individuales puede beneficiar a la aplicación cuando ésta se ejecute de forme integrada.  Los sistemas pueden ser eficientes más no así perfectos, se puede llegar a una condición ideal en el cual la aplicación sea lo suficientemente rápida que satisfaga la demanda de muchos usuarios en cuánto a velocidad y lo suficientemente robusta para que soporte inserciones masivas y/o procesos complejos.  Todo esto es un proceso de suficientes recursos a nivel de hardware (memoria, espacio y conectividad) y el uso adecuado de los mismo.
3. Revisión: Una vez que el código ha sido producido, este debe ser revisado.  Las inspecciones requieren que el código sea leído y entendido por personas distintas a sus autores.  Se revisa el comportamiento actual del sistema o partes del sistema, contra los requerimientos y especificaciones.  El objetivo de esto es detectar errores antes de que éstos entren en producción.

En la IV y ultima parte presentare un cuadro resumen sobre la Adaptación de la Metodologia de Fusión y ejemplos.

El diseñador escoge como se va a construir el sistema. Durante este proceso, los métodos se
unen a las clases. El diseñador también escoge cómo los objetos se relacionan entre ellos y qué relaciones de herencia entre estas clases son apropiadas.

La fase de diseño de Fusión se basa en las CRC y los métodos de Booch.

La salida del diseño es una estructura de software orientado a objeto que contiene la misma información y mantiene las relaciones definidas en el modelo de objetos del sistema.¹

Durante esta fase se desarrollan los tres modelos siguientes:

• Gráficos de Interacción de Objetos. Describen cómo los objetos interactúan en tiempo de ejecución para conseguir la funcionalidad especificada en el modelo de funcionamiento en la fase
  de análisis.

• Descripciones de Clases. Proporciona una especificación de la interface de la clase, atributos de referencia a objetos, y signaturas de los métodos para todas las clases en el sistema.

• Gráficos de Herencia. Describen las estructuras de herencia clases/subclases.

a. Introducción

Fusión, proporciona un método de desarrollo de software orientado a objeto, que abarca desde la definición de requisitos a la implementación en un lenguaje de programación.

Es considerada como una metodología de segunda generación, porque proviene de:

• OMT: modelo de objetos.
• CRC: interacción de objetos.
• BOOCH: visibilidad.

Los métodos formales: pre y post condiciones.

• Proporciona un proceso de desarrollo, que se divide en: Análisis, Diseño e Implementación.
• Ofrece notaciones para los modelos, que describen varios aspectos del software.
• Proporciona herramientas de gestión.

b. Análisis

El análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace. Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la perspectiva de la máquina. El análisis casa con el dominio del problema y se preocupa por el comportamiento visible externamente.

La meta de la fase de análisis es capturar tantos requisitos del sistema como sea posible. Se producen los siguientes modelos del sistema.

• Modelo de Objetos
• Modelo de la Interfase
• Modelo del funcionamiento.
• Modelo del ciclo de vida.

Estos modelos describen:

1. Clases de objetos que existen en el sistema.
2. Relaciones entre esas clases.
3. Operaciones que puedan realizarse en el sistema.
4. Secuencias permitidas de estas operaciones.

Figura 2. Metodología de Fusión – Análisis

La entrada para la fase de análisis es un documento de definición de requisitos en lenguaje natural.

i) Modelo de Objetos

La finalidad del modelo de objeto en Fusión es:

• Capturar los conceptos que existen en el dominio del problema y las relaciones entre ellos.
• Mostrar clases y sus relaciones, (no mostrar objetos)
• El modelo de objeto representa:
  • La estructura estática de la información en el sistema.
  • Las clases y las relaciones entre ellas.
  • Atributos de las clases.
  • Agregación
  • Especialización/generalización

Definiciones

Un objeto es cualquier cosa que puede ser identificada. Puede tener una serie de valores nombrados, llamados atributos.

Los objetos se agrupan en conjuntos, llamados clases.

Las relaciones se usan para modelar la idea de la asociación o correspondencia entre objetos que pertenecen a clases.

Para describir una relación, se consideran los puntos siguientes:

• Restricciones de Cardinalidad. Cardinalidad es el número de clases que pueden asociarse entre sí en una relación.
• Invariantes. Restricciones de que alguna propiedad se debe cumplir.
• Roles. Las clases que participan en una relación tienen roles. Los nombres para los roles o papeles en una relación deben ser únicos.
• Atributos de la relación. Las relaciones, como los objetos, pueden tener atributos.
• Relaciones ternarias y más altas. Las relaciones ternarias relacionan tres objetos separados. Las que involucran más de tres objetos se llaman relaciones n-arias.
  • La agregación es un mecanismo para estructurar el modelo de objetos. Permite la construcción de una clase agregada a partir de las otras clases componentes. La agregación modela las relaciones todo/parte.
  • La generalización permite a una clase, llamada supertipo, ser formada sacando las propiedades comunes de varias clases, llamadas subtipos. La especialización es el caso inverso en el que un nuevo subtipo se define como una versión más especializada de un supertipo.
  • La especialización múltiple permite definir un nuevo subtipo como una especialización de más de un supertipo inmediato. La subclase hereda los atributos y relaciones de todas las superclases.

Un diagrama de modelado de objetos puede ser dividido en subdiagramas.

ii) Modelo de Objetos del Sistema

El modelo de objetos del sistema es un subconjunto del modelo de objetos que describe el sistema a ser construido. Se forma excluyendo todas las clases y relaciones que pertenecen al entorno.

Usa la información sobre la interface del sistema para indicar qué clases y qué relaciones pertenecen al estado del sistema, y no a su entorno.

Las clases que quedan fuera del modelo de objetos del sistema no participan en las relaciones dentro del modelo de objetos del sistema. El modelo de objetos del sistema es la base en la que se hace el resto del desarrollo.

iii) Modelo de la Interface

El modelo de la interfaz describe el comportamiento de un sistema, por ejemplo, define la comunicación de entrada y salida del sistema. La descripción está en términos de eventos y el cambio de estado que ellos causan.

Un sistema se modela como una entidad activa que interactúa con otras entidades activas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemas hardware o software. Las características importantes de un agente son que es activo y se comunica con el sistema.

Un modelo de la interfaz utiliza dos modelos para diferentes aspectos del comportamiento:

• Modelo de Funcionamiento
• Modelo de Ciclo de Vida

1. Modelo del Funcionamiento

El modelo de funcionamiento (modelo funcional) especifica el comportamiento de las operaciones del sistema utilizando un Esquema de Modelado de Funcionamiento.
Define efectos del funcionamiento en términos de cambios de estado, eventos que son salida.

Una operación del sistema es un evento de entrada y su efecto en un sistema. Las operaciones del sistema son invocadas por agentes en el entorno. Una operación del sistema puede:

• Crear una nueva instancia de una clase
• Cambiar el valor de un atributo de un objeto existente
• Agregar o anular alguna tupla de objetos de una relación
• Enviar un evento a un agente

En este modelado definimos la semántica todas las operaciones del sistema y que fueron utilizadas en el modelo de ciclo de vida usando un esquema de modelo de funcionamiento.

2. Modelo del Ciclo de Vida

El modelo del ciclo de vida del sistema describe como el sistema se comunica con su entorno desde su creación hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresión del ciclo de vida define las secuencias aceptables de interacciones en las que un sistema puede participar en su tiempo de vida. Es algo parecido al modo en que una gramática describe las secuencias aceptables de símbolos que son aceptados por un compilador.

iv) Proceso de Análisis

El análisis no es un proceso anárquico: hay una sucesión definida de pasos que pueden aplicarse iterativamente para producir una especificación completa y consistente que capture los requisitos.

El análisis es una actividad incremental e iterativa que formaliza los requisitos. Puede llevarse a cabo de una manera sistemática.

En Fusión, el proceso de análisis se define como sigue:

1. Desarrolle un modelo de objetos para el dominio del problema.
2. Determine la interfase del sistema.
3. Identifique los agentes, operaciones del sistema, y eventos.
4. Produzca el modelo de objetos del sistema agregando el límite al modelo de objetos.
5. Desarrolle un modelo de interfase.
6. Desarrolle un modelo de ciclo de vida.
7. Desarrolle un modelo de funcionamiento.
8. Verifique el modelo de análisis.

Desarrollo del modelo de objetos

El análisis debe empezarse con un alto nivel de abstracción. Es mejor utilizar los requisitos para una tormenta de ideas de posibles clases y relaciones. Solo después de que su estructura global sea satisfactoria deben añadirse los detalles. Se debe recordar que el modelo de objetos utiliza clases, mientras que un documento de requisitos es expresado principalmente en términos de objetos específicos.

Casi cualquier nombre puede dar lugar a una clase. Sin embargo, para serlo, el nombre debe pertenecer a un concepto que sea importante para la comprensión del dominio. Posibles fuentes de clases candidatas son:

• Objetos Físicos.
• Personas y organizaciones.
• Abstracciones.

Para definir las relaciones se deben modelar correspondencias entre objetos. Comunicaciones, asociaciones físicas, contenciones, y acciones son todas las posibles fuentes para relaciones candidatas. Una vez que las listas candidatas se han hecho, deben racionalizarse. En este punto deben de usarse las clases y relacionar las mismas considerando aspectos como:

• Generalización
• Agregación
• Atributos
• Cardinalidades
• Invariantes

Determinación de la Interface del Sistema

Durante el análisis, un sistema es modelado como una entidad activa que coopera con otras entidades activas, llamadas agentes. El sistema y los agentes se comunican enviando y recibiendo eventos. Cuando los eventos recibidos por el sistema, pued
en causar un cambio de estado y eventos de salida. Un evento de la entrada y su efecto asociado son conocidos como una operación del sistema.
La interfase de un sistema es el conjunto de operaciones del sistema a las que puede responder y los eventos que puede enviar.

Una operación del sistema siempre es invocada por un agente, no por un objeto; la fase del análisis no se preocupa por mensajes internos entre los objetos.

La información obtenida en la determinación de la interfase del sistema es el punto de partida para desarrollar el modelo de la interfase.

El escenario es una técnica útil para definir la interfase del sistema.Un escenario es una sucesión de eventos que fluyen entre agentes y el sistema para algún propósito.

Un escenario se representa como un diagrama de secuencia, que muestra las órdenes temporales del sistema y los eventos que fluyen a los agentes. Los diagramas de secuencia no pueden mostrar caminos alternativos de comunicación. Por consiguiente, en general pueden necesitarse diagramas múltiples para un solo escenario.

Los diagramas de secuencia de escenario aportan una herramienta para intuir las consecuencias del diseño de la interfase y visualizar cómo se comporta el sistema. Son útiles al validar decisiones de la interfase con clientes porque son simples e intuitivos de entender.

Desarrollo del Modelo de la Interfase

El modelo de la interfase comprende un modelo del ciclo de vida y un modelo del funcionamiento. El orden del desarrollo no es fijo. Sin embargo, es mejor empezar con el modelo del ciclo de vida porque el ciclo de vida puede ser una ayuda al desarrollo del esquema del modelo de funcionamiento.

Para desarrollar el modelo de ciclo de vida se debe entender que éste es una expresión generalizada de los escenarios que se expresan en diagramas de secuencia. Las expresiones del ciclo de vida son más expresivas que el diagrama de secuencia, porque pueden expresar repetición, alternación y opcionalidad, así como el encadenamiento.

Una expresión del ciclo de vida puede definir un conjunto de escenarios, mientras que un diagrama de secuencia puede mostrar sólo un solo escenario.

El proceso para formar el modelo del ciclo de vida es:

1. Generalice los escenarios para formar expresiones del ciclo de vida nombradas.
2. Combine las expresiones del ciclo de vida para formar el modelo de ciclo de vida.

Para definir el modelo de funcionamiento se debe definir la semántica de cada operación del sistema en la interfase del sistema usando un esquema de modelo del funcionamiento.

El proceso para desarrollar un esquema puede resumirse de la siguiente manera:

1. Desarrolle las cláusulas Asume y Resultados.
2. Extraiga las cláusulas Envía, Lee, y Cambia de Asume y Resultados.

v) Verificando los Modelos del Análisis

La perfección es inasequible y normalmente no se requiere. Sin embargo, una especificación con errores graves no sirve. Verificar los modelos del análisis es una manera estos errores. Si los chequeos no revelan ningún problema entonces se puede pensar que la fase de análisis está completa.

Existen dos aspectos que deben ser verificados: completitud (integridad) y consistencia.

La integridad puede medirse contra los requisitos. Los modelos del análisis deben probarse contra los requisitos, y también el conocimiento y expectativas de los clientes y expertos del dominio.

1) Chequeo de la integridad contra los Requisitos
Hay que verificar que:

• Todos los posibles escenarios son cubiertos por el ciclo de vida.
• Todas las operaciones del sistema son definidas por un esquema.
• Toda la información estática es capturada por el modelo de objetos del sistema.

Un conjunto de modelos es consistente cuando los modelos no se contradicen entre ello, explícitamente o implícitamente. En un modelo debe verificarse su consistencia interna y también para esas áreas donde se solapa con otros modelos.

2) Chequeo de la Consistencia Simple

Estos chequeos tratan las áreas de solape entre los modelos del análisis. Verifica que todas las clases, relaciones y atributos mencionados en el modelo del funcionamiento aparecen en el modelo de objetos del sistema.

3) Chequeos de la Consistencia Semántica

Estos chequeos intentan agrupar que las implicaciones de los modelos son consistentes. Verificando que:

• La salida de eventos en el modelo de ciclo de vida y el modelo de funcionamiento deben ser consistentes. El esquema para una operación del sistema debe generar los eventos de salida que lo siguen en los escenarios del modelo de ciclo de vida.
• El modelo de funcionamiento debe conservar invariantes del modelo de objetos del sistema. Si existe alguna invariante acerca de una relación o clase, entonces cualquier operación que puede cambiarlo debe respetar el invariante en su esquema.
• Ejecutar los escenarios y verificar que los resultados son los esperados.

Los Frameworks son desarrollados con el objetivo  de brindarles a los programadores y diseñadores una mejor organización y estructura a sus proyectos.

Se utiliza la Programación Orientada a Objetos (POO), permitiendo la reutilización de nuestro código. A continuación las características de algunos de los Frameworks para PHP más usados.

Zend Frameworks

El Zend Frameworks es simple, no necesita instalación especial, requiere PHP 5 e incorpora el patrón MVC.

Se debe descargar y
copiarlo hacia nuestro servidor local, veamos a través de un pequeño ejemplo cómo podemos crear un lector de RSS. Los ficheros que creemos podemos copiarlos dentro del directorio “library”.

Symfony

Diseñado con el objetivo de optimizar la creación de las aplicaciones web, con el uso de sus características. Posee una librería de clases que permiten reducir el tiempo de desarrollo.

Symfony está desarrollado en PHP5, se puede utilizar en plataformas *nix (Unix, Linux) y Windows. Requiere de una instalación, configuración y líneas de comando, incorpora el patrón MVC, soporta AJAX, plantillas y un gran número de bases de datos.

Luego de descargar, debemos desempaquetar hacia un directorio dentro de nuestro servidor web. Puede configurar el archivo “symfony.bat” e introducir la ruta completa del archivo “php.exe” en la línea 34.

set PHP_COMMAND=c:/xampp/xampp/php/php.exe

Si nos encontramos en el directorio “sf_sandbox” podemos ir a las líneas de comando y conocer la versión del framework: symfony -V. Podemos verificar la creación de nuestro proyecto introduciendo en el navegador, por ejemplo: http://localhost/sf_sandbox/web/frontend_dev.php

Si deseamos crear un weblog debemos crear el archivo “schema.yml” en el directorio “sf_sandbox/config/”. Después de haberlo creado podemos usar las siguientes líneas de comando dentro del directorio “sf_sandbox/”:

• symfony propel-generate-crud frontend post Post : crear y listar Post.
• symfony propel-generate-crud frontend comment Comment : crear y listar comentarios.
• symfony clear-cache : limpiar la cache.

Los modulos serán creados en “sf_sandboxappsfrontendmodules”. Podemos ver el resultado:

• http://localhost/sf_sandbox/web/frontend_dev.php/post
• http://localhost/sf_sandbox/web/frontend_dev.php/comment

Se puede acceder a los archivos y modificar las plantillas a nuestro gusto.

Seagull

El framework Seagull, nos permite realizar una programación modular, posee un Sistema de Gestión de Contenidos (CMS).

Entre sus características de encuentran su compatibilidad con PHP 4 y PHP 5, ORM integrado, incorpora el patrón MVC, uso de templates, soporte para múltiples bases de datos, validación de datos, alto nivel

de configuración, autentificación, integración de librerías PEAR. Debemos descargar el framework, luego descomprimirlo hacia un directorio dentro de nuestro servidor web. Luego introducimos la dirección en nuestro navegador para realizar su instalación. Ejemplo: http://localhost/seagull/www/.

Debemos completar los 6 pasos siguientes:

• Aceptar la licencia
• Autorización
• Debemos crear en el directorio el archivo “AUTH.txt” que contenga el código generado o descargarlo en “seagull/”. Si se crea correctamente podremos continuar al siguiente paso.
• Detección: aquí se detectará los módulos disponibles, así como la configuración y versión de PHP.
• Conexión con las bases de datos: debemos configurar los datos
  necesarios para realizar la conexión con el servidor de base de datos.
• Configuración de la base de datos: introducir el nombre de la base de datos. Se puede utilizar una existente.
• Creación del Usuario Administrador: se creará la cuenta de usuario que utilizaremos para administrar a Seagull Framework.

Luego de Finalizar su instalación podemos crear contenidos visitando http://localhost/ seagull/www/ e introduciendo el usuario y clave de administración.

Prado

Prado está basado en componentes eventos con el objetivo de acelerar el desarrollo de aplicaciones web usando PHP 5.

El concepto del desarrollo de aplicaciones en Prado es diferente, se utilizan componentes, eventos y propiedades en vez de procedimientos, URL y parámetros.

Este Framework combina especificaciones en un archivo XML, plantillas HTML y una clase PHP. Prado, cuenta con soporte para AJAX, validación, autentificación, plantillas, múltiples bases de datos.

Entre los beneficios que podemos encontrar para el desarrollo de aplicaciones web se encuentran:

• Reutilización: los códigos y componentes pueden ser reutilizados.
• Fácil uso: la creación y uso de componentes es fácil.
• Funcionamiento: utiliza una técnica de caché para asegurar el funcionamiento de aplicaciones basadas en el.
• Integración: permite la separación del contenido y la presentación.

Podemos descargar y descomprimir Prado en un directorio, luego acceder al siguiente demo.

Hello World:

Esta aplicación cuenta con los archivos index.php, Home.page y Home.php, organizados con la siguiente estructura, la cual puede ser modificada:

• assets : almacena archivos privados publicados.
• protected: aquí se almacenarán los archivos que serán usados.
• runtime: se almacena la información runtime de la aplicación, así
  como su estado, este directorio debe tener acceso de escritura por el
  servidor web.
• pages: aquí se almacenan todas las páginas de Prado.