Nicolas Bortolotti

La idea de este artículo es introducirnos en la herramienta de modelado Enterprise Architect, en esta oportunidad el objetivo puntual es registrar requerimientos que nos llegan para la realización de una solución de software. Como vemos en la captura anterior existen diversos parámetros que debemos configurar en la definición del requerimiento planteado. En primer lugar tenemos algo muy importante que es la descripción del requerimiento, generalmente debe ser descripto de forma simple y particularmente concisa, pero además tenemos un estado del requerimiento y es bueno para implantar validaciones y seguimiento al mismo, en este ejemplo se muestra en un estado de implementado, siguiendo con el análisis tenemos la dificultad que trae aparejada el requerimiento en relación al flujo detectado por el analista y la prioridad del mismo también en correlación con el análisis detectado. El ejemplo muestra un requerimiento de tipo funcional, muy importante en el desarrollo de soluciones de softw

Como introducción al artículo voy a detallar el porqué de nombre especificado, creo que actualmente se definen de diversas maneras los conceptos de arquitectura de software y ni hablar de las responsabilidades del arquitecto de software. En mi semana laboral he asistido a una charla sobre arquitectura en donde tenía esperanzas de encontrar conceptos sólidos y bien fundados sobre que comprende la arquitectura del software y principalmente el rol y actividades del arquitecto. En cierta forma encontré respuestas pero poco fundadas y que en un 80% se contradecían. En fin voy a intentar recrear una óptica de arquitectura de software para poder entender las funciones de un arquitecto. ¿Qué se entiende por arquitectura? En primer lugar voy a colocar un enfoque muy interesante definido por (Bennett, McRobb y Frarmer) en donde se cita a RIBA (The Royal Institute of British Architects) para la definir que hacen los arquitectos: "Los arquitectos están entrenados para entender sus explicacion

Bueno para los amantes de los patrones en este artículo voy a mostrarles una aplicación de Strategy. Vemos algunas definiciones para comenzar la implementación del ejemplo: "El patrón Strategy permite mantener un conjunto de algoritmos de los que el objeto cliente puede elegir aquel que le conviene e intercambiarlo según sus necesidades." "El patrón strategy (estrategia) está orientado a resolver situaciones en las que nos encontramos con un problema base pero existen diversas estrategias para abordar el problema" La pregunta es: ¿Cuántas veces nos ocurren estos problemas? Y ni hablar la diversidad de soluciones propuestas, muchas con poco sentido. Por este motivo es fundamental entender el objetivo del patrón para poder aplicar de forma consistente a determinados problemas. Les voy a mostrar un diagrama general del patrón después veremos una implementación: (grafico herramienta de modelado EA) La implementación de estrategias extensibles es lo más notorio del patr

Cada artículo que decido escribir tiene objetivos puntuales y la idea es resolver problemáticas del desarrollo actual, esta óptica que les traigo en esta presentación tiene que ver con una mezcla de conceptos que intentan aproximar el modelado de negocio de una problemática organizacional a un esquema ingenieril de desarrollo de software. Desde hace un tiempo que estoy manejando varias opciones para dotar a los desarrollos de análisis del negocio, existen incluso estándares formulados en cuanto al tema, para una introducción al artículo como es ya una tradición les voy a nombrar algo de teoría, finalmente voy a desarrollar algunas opciones prácticas. ¿Qué es el modelado de Negocio? En algo estamos seguros, el entorno organizacional no es simple y mi postura es, la complejidad es más fácil de comprender si se visualiza en alguna manera, no simplemente descripta con palabras. Sabemos que es imposible capturar completamente la esencia del ser de una organización y además la información su

Este artículo tiene por objetivo mostrar de forma simple, algunas herramientas interesantes para realizar una evaluación de las aplicaciones que nos toque desarrollar. En muchas oportunidades para no decir en todas, escucho la simple frase "Da igual usar esta estructura y además no importa como la invoques no influye…". Yo creo que particularmente estas frases son extremadamente simplistas ya que desde mi punto de vista se influye y mucho en las arquitecturas de las aplicaciones este tipo de decisiones. Ahora bien, mucho depende del tipo de aplicaciones que estemos desarrollando y para qué tipo de entorno, en este artículo voy a realizar solo unas pruebas de corte rudimentario con dos herramientas sobre un esquema de aplicativo de escritorio. La comparación planteada tiene que ver con la utilización de ADO.NET para estructuras como DataSet, DataTable y DataReader de esta forma analizar la performance de cada enfoque. Les presento el aplicativo, muy simple para la demostración

Este artículo tiene el objetivo de mostrar cómo podemos interactuar con los modelos e integrar esta información con nuestros sistemas empresariales. Imaginemos el rol de un analista que se encuentra validando un proceso en una organización, hay varias estrategias para estas actividades y esto depende del analista, organización e infinidad de puntos, pero la idea que propongo es realizar la lectura de un diagrama de actividades de forma simple y básica, para poder armar una descripción del proceso luego en esquema formal (algo que generalmente torna muy productivo la captura de requerimientos y permite enlazar la información rápidamente al entorno de desarrollo). Para este punto voy a utilizar la herramienta de modelado EA (Enterprise Architect) y un proyecto de Visual Studio 2005 para armar un plug in que me permita interactuar con mi modelo. Veamos en primer lugar un modelo, solo voy a arrastrar dos actividades y el punto de inicio y fin del diagrama, como para mostrar de forma rápida