En mi anterior entrada hablaba sobre como crear enlaces en SendTo y preparar nuestra aplicación para recibir los nombres de los archivos seleccionados. He de confesar, que desde que uso XP x64 y VS2008 tengo varios problemas con los instaladores MSI que genero con VS, asi que estoy esperando a que pasen los TechDays para ponerme a instalar XP normal ..., el caso es que elaborando dicho artículo no pude probar correctamente la parte de instalación ya que, literalmente, aparecia un error de acceso a memoria un poco chungo cuando le daba a "Install" desde el VS, poco después me dí cuenta de que el error no aparece al ejecutar el .msi directamente y me dí cuenta que la manera de generar el enlace en la carpeta SendTo no funciona!!

Leer el artículo completo...

Si desarrollamos una aplicación que manipule archivos puede ser útil disponer en el menu contextual "Enviar a" (SendTo) un enlace que permita enviar los archivos seleccionados directamente a nuestra aplicación trabajar con ellos. Esta es la típica cosita facilona y que lleva 5 minutos pero que resulta extremandamente útil cuando lo que desarrollamos es una herramienta de uso cotidiano.

Los elementos SendTo se encuentran en la carpeta %homepath/SendTo% de cada usuario, pero explicaré como añadirlo directamente con el instalador de nuestra aplicación.

Leer el artículo completo...

Vamos con una de Arts Attack... El ProgressBar de .NET es "bonito", sobre todo en Windows Vista, pero a mi gusto prefería menos destellos fashion y un poco más de información... y ya puestos ... un estilo flat :D 

En vez de crear uno from scratch, mucho mejor extender el ProgressBar, añadirle nuevas propiedades y redefinir como repintarlo. Código fuente al final del artículo ;)

Leer el artículo completo...

Antes de empezar a desarrollar una aplicación, es conveniente revisar el diseño lógico para asegurar que es esta completo y correcto. Esto viene a ser evaluar el diseño en los siguientes terminos:

• Evaluación de ejecución:
  • Rendimiento.
  • Escalabilidad.
  • Disponibilidad.
  • Recuperación.
  • Seguridad.
• Evaluación de la arquitectura:
  • Mantenibilidad.
  • Extensibilidad.
• Evaluación de los requerimientos:
  • Casos de uso.

Leer el artículo completo...

Siguiendo con el tema del modelado del software en capas, es el turno de crear modelos físicos más precisos para los programadores que han de escribir el código. Los modelos físicos indican como los programadores deberían desarrollar la aplicación.

Un diagrama de componentes indica los componentes ó paquetes de los que se compondrá la aplicación y las dependencias de estos. Un componente es un conjunto de clases relacionadas formando una unidad distribuible, como una DLL, un control ó un Webservice. Los componentes se representan por rectangulos con dos pequeños rectangulos a su izquierda, en el nombre se indica la capa a la que pertenecen separados con dos dobles puntos ('::'). Otros rectangulos mayores que agrupan varios componentes simbolizan un contenedor de distribución llamado nodo, que suele indicar una separación física, como estar en distinto hardware.

Leer el artículo completo...

El modelado en capas de un sistema representa como se planea dividir el código en partes lógicas ó grupos. La abstracción del código en capas permite mejorar, reparar y reemplazar partes de la aplicación de forma sencilla y sin que afecte a las demás. Además provee una representación lógica y clara de la aplicación.

El modelo en capas más comun es el de tres capas, presentación, lógica de negocio y base de datos. El model n-capas extiende este modelo de forma que cualquier capa puede dividirse en subcapas, aportando así mayor claridad.

La capa más alta es en la que se interactua con el usuario, la capa más baja donde los datos son almacenados/recuperados y las capas intermedias son las encargadas de realizar el procesado de datos, el movimiento de estos de la base de datos al usuario y el control del estado de la aplicación.

Leer el artículo completo...

Un modelo lógico representa los conceptos reales que ha de cubrir la aplicación y permite asegurar que el software cubrirá dichos conceptos.

El modelado de funciones de objetos (Object Role Modeling - ORM) es el proceso de representar conceptos del mundo real que definen ó influyen en el software. Los diagramas ORM incluyen unos objetos primarios llamados entidades, las relaciones entre esas entidades y los atributos que definen esos objetos. Estos diagramas se crean descomponiendo los requerimientos de usuario y los casos de uso en entidades, relaciones y atributos.

Leer el artículo completo...

Después de evaluar los requerimientos y el diseño previo de una aplicación, el siguiente paso es realizar un prototipo.

Un prototipo tiene el propósito de cubrir los huecos  que quedan entre la teoría y la práctica, es decir, entre los requerimientos junto el diseño y la implementación real.

Las maquetas se usan para proponer y validar interfaces de usuario y la navegación por el sistema. Se pueden crear desde con papel y lapiz a herramientas como Microsoft Visio. También se conocen como prototipos horizontales y verifican el cumplimiento de los requerimientos y casos de uso a través de una serie de formularios clave.

Los prototipos de prueba de concepto prueban la arquitectura propuesta con todas sus capas, se conoce también como arquitectura de referencia. Se deben crear con las tecnologías propuestas ó aproximadas. También se conocen como prototipos verticales (por lo de que influyen todas las capas).

Leer el artículo completo...

Los requerimientos de un proyecto deberían ser definidos desde múltiples perspectivas:  

• Requerimientos del negocio: Definidos por los gerentes y comerciales. Exponen que puntos se consideran importantes para el éxito del proyecto.
• Requerimientos de usuario: Definidos por los futuros usuarios. Exponen que tareas deben ser capaces de realizar con la aplicación para cumplir los objetivos de su trabajo.
• Requerimientos funcionales ó especificaciones funcionales: Definidos por el lider técnico ó el arquitecto. Definen las caracteristicas que se deben desarrollar para cumplir los requerimientos anteriores. Son definidos mejor a través de herramientas de modelado, sin tener que hacer por un lado un documento de requerimientos y por otro el modelado de dichos requerimientos.
• Requerimientos de calidad de servicio: Definen requerimientos sobre el rendimiento, escalabilidad y estandares a cumplir, no sobre aspectos funcionales ó problemas específicos.

Unos requerimientos bien expuestos no deberian presentar ambiguedad. No deben exponer metas a conseguir, si no cosas que se pueden hacer y estimar. No deben dar lugar a malas interpretaciones.

Leer el artículo completo...