domingo, 30 de diciembre de 2007

T.L.E. o Tiempo de Lectura Estimado

Estoy leyendo el libro "Un mundo sin fin" de Ken Follet que tiene 1178 páginas a 25 de media que leo por día... 48 días !!

Vamos que hasta Marzo más o menos tengo la lectura de ocio ocupada, gracias por el regalo Nai!!

Cohesión y acoplamiento (2 de 2)

Acoplamiento

El acoplamiento puede ser fuerte o débil.

Cuando un componente es fuertemente acoplado (tightly coupled) dicho componente depende mucho de componentes externos para completar su funcionalidad.

Por contra, cuando un componente es débilmente acoplado no depende o depende en menor medida de otros componente externos.

Básicamente, cuanto más débil es la unión entre los componentes, más sencillo es para desarrollador trabajar con dicho componente sin causar problemas al resto de la aplicación.

Como regla general podemos asumir que un componente debe depender lo menos posible de otros componentes. Si existe una dependencia, la conexión entre ellos debe ser tan clara como se pueda de tal manera que pueda definir una interfaz de manera fácil. Otra razón para definir de manera clara las dependencias en el diseño es la de asegurar que las decisiones futuras no provoquen errores en la solución, facilitando así las pruebas de integración y regresión.

Cohesión y acoplamiento (1 de 2)

Hoy vamos a hablar de dos características muy importantes a la hora de diseñar nuestros componentes, la cohesión y el acoplamiento.

¿Que es cohesión?
Es la relación entre varios elementos internos de un componente.

¿Que es acoplamiento?
Son las relaciones de un componente con otros componentes

Vamos un poco más en detalle la cohesión:

Un componente cuyos servicios están fuertemente relacionados se dice que posee una alta cohesión. La fiabilidad de un componente es directamente proporcional de lo fuerte que sea la relación entre sus servicios. La cohesión puede ser beneficiosa o no en base al motiva en que fué creada.

La Cohesión puede ser:
  • Funcional: Cada unidad realiza unicamente una tarea. (El tipo más fuerte de cohesión)
  • Secuencial: Cada unidad contiene operaciones que deben ser ejecutadas en un orden específico y que deben compartiendo datos.
  • Comunicativa: La operaciones en una unidad utilizan los mismos datos pero no estan relacionadas de ninguna otra manera. Este tipo de cohesión minimiza la sobrecarga de comunicación en la aplicación.
  • Temporal: las operaciones están combinadas porque se realizan a la vez.
Sin embargo no siempre la cohesión es beneficiosa. Otros tipos de cohesión pueden ocurrir en una solución poco organizada, dificultando que su entendimiento, depuración y modificación. (una ruina, vamos...)

Los tipos ineficaces de cohesión son:
  • Procedural: las operaciones se agrupan porque son ejecutadas en un mismo orden. A diferencia de la cohesión secuencial, las operaciones no comparten datos.
  • Coincidencia: Las operaciones son agrupadas sin ninguna interrelación aparente.
En el próximo post hablaremos del acoplamiento...

viernes, 28 de diciembre de 2007

Reto matemático 1

Hoy les propongo resolver un problema matemático:

Si listamos los seis primeros números primos: 2, 3, 5, 7, 11, y 13 observamos que el sexto número primo es 13.

¿Cual es el número primo que ocupa la posición 10.001?

La solución (y el código fuente de una implementación) en unos días.

Espero sus respuestas.

jueves, 20 de diciembre de 2007

Feliz navidad y prospero año nuevo

Para los lectores (pocos pero fieles) de este blog les deseo felices fiestas y un descanso merecido. El 2008 puede ser el año perfecto para sacar esa certificación o ese título de inglés deseado. (o apuntarse al gimnasio, la natación, montar esa estantería, matricularse en la U.N.E.D....)

Bueno, lo dicho feliz año 2008.

Importancia de aplicar una metodología

Poco a poco iremos avanzando y profundizando en el M.S.F.
Pero realmente la metodología es un campo de estudio amplio y mi tiempo limitado. Lo que podeis tener por seguro es que:

"Sin un buen diseño conceptual se puede crear una gran solución para el problema equivocado"

martes, 18 de diciembre de 2007

Modelos de Procesos (2 de 2)

Continuemos viendo estas dos vertientes de modelado del ciclo de vida del proyecto:
  • Modelo en cascada:
    Establece una secuencia de puntos de control. Este modelo utiliza jalones (milestones) como transición y puntos de evaluación. La esencia del modelo es la de completar las tareas de una fase antes de pasar a la siguiente. Este modelo es ideal en caso de proyectos donde los requisitos estén claramente definidos y no vayan a sufrir modificaciones en el futuro. (casi nada...). Como este modelo posee unas transacciones prefijadas entre fases es realmente sencillo de supervisar, asignar responsabilidades o facturar los hitos.

  • Modelo en espiral:
    Establece un modelo circular que encamina el proceso a su solución. Este modelo es efectivo en aplicaciones de desarrollo rapido o muy pequeños. Puede generar una buena sinergia entre los desarrolladores y los clientes, puesto que estos se ven implicados aportando su feedback y aprobando los avances. Por otro lado el método en espiral no incorpora puntos de control y puede que el desarrollo sea algo caótico.

El próximo día veremos las fases del M.S.F.

lunes, 17 de diciembre de 2007

Modelos de Procesos (1 de 2)

Comenzando por el principio...

¿Que son los modelos de Procesos?

Con el fin de maximizar el éxito de los proyectos empresariales, todos los profesionales involucrados deben centrar sus esfuerzos en las diferentes aspectos que los componen.

Deberemos definir unas directrices o guías que permitan atacar el diseño, desarrollo, despliegue, operatividad y soporte de dichas aplicaciones de forma eficiente y acorde a los patrones de calidad deseados.

Microsoft define sus propias directrices empaquetándolas en el marco de trabajo de soluciones de Microsoft (M.S.F.) basándose en su propia experiencia así como en la de sus clientes, grandes desarrolladores de software, consultores de proyectos tecnológicos e información de la industria de la tecnología de la Información (IT) .

El proceso de modelado, marca el orden de las actividades de los proyectos y representa el ciclo de vida del mismo. Históricamente algunos de los modelos de procesos son estáticos o no admiten checkpoints o puntos de control.
Dos ejemplos de estos modelos de proceso son:
  • Modelo cascada (waterfall)
  • Modelo espiral.
Gráficamente estos modelos se pueden observar en el siguiente gráfico:




El próximo día continuaremos definiendo con un poco más de detalle dichos modelos...

viernes, 14 de diciembre de 2007

Metodología de Desarrollo y Arquitectura del Software

Voy a comenzar una serie de anotaciones relacionados con el tema sobre el que más estoy trabajando últimamente que es la Metodología de Desarrollo y Arquitectura del Software.
Para ello, nos centraremos en la metodología empleada internamente por Microsoft conocida como Microsoft Solution Framework. (M.S.F.)

¿Por que la M.S.F.?

Básicamente porque es una metodología rodada y aplicada con éxito en el mundo empresarial. Esta hereda de la famosa R.U.P. de Rational y por lo tanto, parte de su robusta base modernizando algunos aspectos de la misma y cerrando el circulo sobre otros, que la R.U.P. , a mi modo de ver, esboza de manera muy abstracta.

Por supuesto el mérito de Rational, (ahora parte de I.B.M.) es incuestionable y su validez a día de hoy absoluta pero vamos a decantarnos por analizar más en detalle la forma de trabajar del gigante de Redmond.

Adquirir aunque sea una visión superflua de dicha metodología no es un proceso sencillo ni corto así que dividiré el contenido en diferentes capítulos ordenados que les permitan ir adentrandose poco a poco en estas materias.

Espero que lo encuentren interesante y si lo desean aporten sus comentarios.

Un saludo.

martes, 11 de diciembre de 2007

Tercera ley de Newton

Se sabe que siempre que un cuerpo ejerce una fuerza sobre otro, el segundo ejerce sobre el primero una fuerza de la misma magnitud, dirección opuesta y con la misma línea de acción.
No es posible, por tanto, la existencia de una fuerza aislada.

En palabras de Newton:
"A cada acción se opone siempre una reacción igual: es decir, las acciones mutuas entre dos cuerpos son siempre iguales y están dirigidas hacia partes contrarias"

Segunda ley de Newton

Existen diversas maneras de formular la segunda ley de Newton, que relaciona las fuerzas actuantes y la variación de la cantidad de movimiento o momento lineal:

  • La variación de momento lineal de un cuerpo es proporcional a la resultante total de las fuerzas actuando sobre dicho cuerpo y se produce en la dirección en que actúan las fuerzas.

En términos matemáticos esta ley se expresa mediante la relación:


 \vec{F}=\frac{d \vec{p} }{d t}

Primera ley de Newton

La primera ley del movimiento de Newton no es tan evidente como parece. En primer lugar esta ley afirma que en ausencia de fuerzas aplicadas un cuerpo permanece en reposo o se mueve con movimiento rectilíneo uniforme.

En consecuencia, cuando un cuerpo se ha puesto en movimiento, no es necesario ejercer una fuerza sobre él para mantenerlo en movimiento.

Equilibrio de una particula

La mecánica se basa en tres leyes naturales que relacionan la fuerza y el movimiento, establecidas por primera vez por sir Isaac Newton (1642-1727), y publicadas en 1686 en su "Philosophiae Naturalis Principia Mathematica" (Los fundamentos matemáticos de la ciencia de la naturaleza)

Fueron muchos los científicos que precedieron a Newton en este campo, pero el más importante fue Galileo Galilei (1564-1642) que, en sus estudios sobre el movimiento acelerado, había establecido los fundamentos que permitieron a Newton la formulación de sus tres leyes.

En posteriores posts analizaremos dichas leyes y hablaremos de la fuerza.