# Alpha–beta pruning

The Alpha-Beta algorithm (Alpha-Beta Pruning, Alpha-Beta Heuristic [1] ) is a significant enhancement to the minimax search algorithm that eliminates the need to search large portions of the game tree applying a branch-and-bound technique. Remarkably, it does this without any potential of overlooking a better move. If one already has found a quite good move and search for alternatives, one refutation is enough to avoid it. No need to look for even stronger refutations. The algorithm maintains two values, alpha and beta.

Alpha–beta pruning is a search algorithm that seeks to decrease the number of nodes that are evaluated by the minimax algorithmin its search tree. It is an adversarial search algorithm used commonly for machine playing of two-player games (Tic-tac-toe, Chess,Go, etc.). It stops completely evaluating a move when at least one possibility has been found that proves the move to be worse than a previously examined move. Such moves need not be evaluated further. When applied to a standard minimax tree, it returns the same move as minimax would, but prunes away branches that cannot possibly influence the final decision.

Allen Newell and Herbert A. Simon who used what John McCarthy calls an “approximation”[2] in 1958 wrote that alpha–beta “appears to have been reinvented a number of times”.[3] Arthur Samuel had an early version and Richards, Hart, Levine and/or Edwards found alpha–beta independently in the United States.[4] McCarthy proposed similar ideas during the Dartmouth Conference in 1956 and suggested it to a group of his students including Alan Kotok at MIT in 1961.[5] Alexander Brudno independently discovered the alpha–beta algorithm, publishing his results in 1963.[6] Donald Knuth and Ronald W. Moore refined the algorithm in 1975[7][8] and Judea Pearl proved its optimality in 1982.[9]

## Improvements over naive minimax

An illustration of alpha–beta pruning. The grayed-out subtrees need not be explored (when moves are evaluated from left to right), since we know the group of subtrees as a whole yields the value of an equivalent subtree or worse, and as such cannot influence the final result. The max and min levels represent the turn of the player and the adversary, respectively.

The benefit of alpha–beta pruning lies in the fact that branches of the search tree can be eliminated. This way, the search time can be limited to the ‘more promising’ subtree, and a deeper search can be performed in the same time. Like its predecessor, it belongs to the branch and bound class of algorithms. The optimization reduces the effective depth to slightly more than half that of simple minimax if the nodes are evaluated in an optimal or near optimal order (best choice for side on move ordered first at each node).

With an (average or constant) branching factor of b, and a search depth of d plies, the maximum number of leaf node positions evaluated (when the move ordering is pessimal) is O(b*b*…*b) = O(bd) – the same as a simple minimax search. If the move ordering for the search is optimal (meaning the best moves are always searched first), the number of leaf node positions evaluated is about O(b*1*b*1*…*b) for odd depth andO(b*1*b*1*…*1) for even depth, or $O(b^{d/2}) = O(\sqrt{b^d})$. In the latter case, where the ply of a search is even, the effective branching factor is reduced to its square root, or, equivalently, the search can go twice as deep with the same amount of computation.[10] The explanation of b*1*b*1*… is that all the first player’s moves must be studied to find the best one, but for each, only the best second player’s move is needed to refute all but the first (and best) first player move—alpha–beta ensures no other second player moves need be considered. When nodes are ordered at random, the average number of nodes evaluated is roughly $O(b^{3d/4})$.[2]

An animated pedagogical example that attempts to be human-friendly by substituting initial infinite (or arbitrarily large) values for emptiness and by avoiding using the negamax coding simplifications.

Normally during alpha–beta, the subtrees are temporarily dominated by either a first player advantage (when many first player moves are good, and at each search depth the first move checked by the first player is adequate, but all second player responses are required to try to find a refutation), or vice versa. This advantage can switch sides many times during the search if the move ordering is incorrect, each time leading to inefficiency. As the number of positions searched decreases exponentially each move nearer the current position, it is worth spending considerable effort on sorting early moves. An improved sort at any depth will exponentially reduce the total number of positions searched, but sorting all positions at depths near the root node is relatively cheap as there are so few of them. In practice, the move ordering is often determined by the results of earlier, smaller searches, such as through iterative deepening.

The algorithm maintains two values, alpha and beta, which represent the maximum score that the maximizing player is assured of and the minimum score that the minimizing player is assured of respectively. Initially alpha is negative infinity and beta is positive infinity, i.e. both players start with their lowest possible score. It can happen that when choosing a certain branch of a certain node the minimum score that the minimizing player is assured of becomes less than the maximum score that the maximizing player is assured of (beta<=alpha). If this is the case, the parent node should not choose this node, because it will make the score for the parent node worse. Therefore, the other branches of the node do not have to be explored.

Additionally, this algorithm can be trivially modified to return an entire principal variation in addition to the score. Some more aggressive algorithms such as MTD(f) do not easily permit such a modification.

## Pseudocode

01 function alphabeta(node, depth, α, β, maximizingPlayer)
02      if depth = 0 or node is a terminal node
03          return the heuristic value of node
04      if maximizingPlayer
05          v := -∞
06          for each child of node
07              v := max(v, alphabeta(child, depth - 1, α, β, FALSE))
08              α := max(α, v)
09              if β ≤ α
10                  break (* β cut-off *)
11          return v
12      else
13          v := ∞
14          for each child of node
15              v := min(v, alphabeta(child, depth - 1, α, β, TRUE))
16              β := min(β, v)
17              if β ≤ α
18                  break (* α cut-off *)
19          return v

(* Initial call *)
alphabeta(origin, depth, -∞, +∞, TRUE)

# programming class

How Programming Languages Evolved
How the computer stores data
Numbering systems the computer likes
Different data types
Different programming Syles
Procedural
Functional
Object Oriented
What does it mean when a language is “strongly” or “weakly” typed
What is compiling and do I need to do it?
When I would do it, and when I would not
Why, what advantage does it provide
Modern Computer Languages Overview
Bash
Perl
Python
Ruby
C
C++
Java
Vala
C#/Mono
Programming methodologies
Waterfall
Summary of Graphical Programming Libraries
GTK
QT
FLTK
SDL
And finally, Programmers tools:
Eclipse
NetBeans
Anjuta

This is a lot of topics, and this week will be an overview. It should get you enough information to recognize the labels on the map, even if you are not 100% sure where the map will lead you. That will be the task for the following weeks.

Una de las trampas de la orientación a objetos en lenguajes como C# son los operadores de copia e igualdad.

En C# al usar el operador = o ==, la igualdad entre objetos referenciados solo se da si en realidad es el mismo objeto y de manera similar al hacer una copia nos podemos llevar una sorpresa si no tenemos cuidado de estar copiando la referencia o el contenido. Por eso la interfaz ICloneable es controversial porque su significado es ambiguo

Referencias:

Implementar ICloneable mediante serialización

ICloneable Interface

Should we Obsolete ICloneable (The SLAR on System.ICloneable)

IClonable deep vs shallow, best practise

Creating and Using Attributes in your .NET application

# Libreria empresarial del grupo de patrones y practicas de Microsoft

La última versión de la Enterprise Library del grupo de Patterns and Practices de Microsoft se libero en mayo del 2007 y es compatible con .Net 2.0 y 3.0.

Información actualizada y material didactico se puede localizar en el sitio comunitario de la libreria empresarial.

#### Enterprise Library: La evolución de los .NET Application Blocks de patterns & practices

Entlib – Enterprise Library es la evolución de los Bloques Aplicativos .NET que han sido desarrollados por el Grupo PAG (Microsoft Platform Architecture Guidance) dentro de Microsoft. Este grupo genera guías y arquitecturas de referencia, patrones de diseño, y código fuente desarrollado con la implementación de diversos escenarios tecnológicos.

Los desarrolladores en su momento puden usar la guía para comprender las mejores prácticas referenciadas y sugeridas por Microsoft para aplicaciones .NET; o incorporar el bloque aplicativo como tal dentro de sus desarrollos, en su formato original y/o extendido.

Los “Bloques Aplicativos .NET” que en su momento fueron liberados son los siguientes:

Por la forma gradual en que fueron desarrollados dichos bloques aplicativos, los mismos estaban desintegrados y la experiencia de utilización e extensibilidad eran diferentes entre si. Además que la utilización de cada uno de dichas piezas de software obligaba a la instalación de componentes de software independientes.

Con estas áreas de oportunidad la nueva versión de los “.NET Application Blocks” se integró con la nueva etiqueta de Enterprise Library. El grupo de PAG ha anunciado lo siguiente:

Entlib es una librería de activos de software reutilizable que atenderá los retos comunes en el desarrollo del software empresarial.

Entlib está focalizado en la consistencia, extensibilidad, fácil utilización e integración de los diversos bloques aplicativos existentes y futuros.

Es importante aclarar que Enterprise Libray no es un producto como tal, sino que es un componente de software que es proporcionado como está, pero del cual se puede contratar soporte directamente de Microsoft, tratado bajo un esquema parecido al código escrito por los usuarios.

#### Requerimientos:

• Sistema oprativo: Windows Server 2003; Windows Vista; Windows XP

Note: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1. However, you can install the Enterprise Library 3.0 or the Enterprise Library 3.1 when 2.0 is already installed.

• Microsoft .NET Framework 2.0 or 3.0. You need .NET Framework 3.0 for the
Application Block Software Factory and the WCF adapters for the Validation
Application Block and Exception Handling Application Block
• Microsoft Visual Studio 2005 development system (any of the following
editions):

• Microsoft Visual Studio 2005 Standard Edition
• Microsoft Visual Studio 2005 Professional Edition
• Microsoft Visual Studio 2005 Team Edition for Software Developers
• Microsoft Visual Studio 2005 Team Edition for Software Testers
• Microsoft Visual Studio 2005 Team Edition for Software Architects
• Microsoft Visual Studio 2005 Team Suite

• To use the Application Block Software Factory and the Strong-Naming
Guidance Package, you need the Guidance Automation Extensions (GAX). To
modify these guidance packages, you also need the Guidance Automation
Toolkit (GAT).
• Some blocks and samples require the use of Microsoft SQL Server or other
database products.
• Visual Studio Team System or NUnit 2.2 is required if you want to
execute unit tests.

### Referencias:

Enterprise Library 3.1 – May 2007

Acropolis

# La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.

Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

• El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.
• La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado
• La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.
• La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.
• El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

 Liberarí­a Tamaño (MB) Tamaño comprimido (MB) Java 30+ 15 GTK+ 9+ 4 QT 4+ 2 wxWidgets <1 <.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces grÃ¡ficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento “Quasar Technologies”) en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

# Lisp y Scheme

Una de las cosas que me llaman la atención es la convicción tan grande que los programadores de Lisp tienen en el poder de sus paréntesis.

Aún en el contexto de desarrollo Web Paul Graham ha llamado a Lisp su arma secreta, y en el manual de como convertirse en un Hacker de Eric Steven Raymond Lisp se presenta como un experiencia mística. Peter Norvig, en Teach Yourself Programming in Ten Years recomienda aprender lenguajes que soporten abstracción de clases (como Java), abstracción funcional (como Lisp), abstracción sintáctica (como Lisp), especificación declarativa (como Prolog), corutinas (como Scheme), y paralelismo (como Sisal).

El enfoque funcional parece ser fundamental y, por ejemplo, el equipo de desarrollo de C# ha hecho un esfuerzo por soportar este paradigma en la nueva versión a través del mecanismo de delegados.

Es claro que el río suena porque agua lleva. Para el interesado hay material introductorio abundante pero lograr la iluminación requerirá tiempo y esfuerzo.

Para Lisp, como lo indica su nombre, todo son listas y los comando básicos (constructors, selectors y recognizers) son para manipular las mismas:

quote para diferenciar una lista de una llamada a función.
first y rest para separar listas en sus partes.
cons para construir listas.
null y consp para ver si una lista esta vacía.
member para verificar si un elemento es miembro de una lista.
append para unir listas.

Lisp tiene varios dialectos: Common Lisp y Scheme son algunos de los más difundidos. CLisp es un implementación de Common Lisp y Visual CLisp es un puerto a Windows con un GUI. Otra alternativa es CMUCL.

Dorai Sitaram tiene un sitio con ligas a recursos sobre Scheme y Common Lisp, incluyendo un tutorial bastante bueno.

drscheme incluye varias implementaciones de Scheme bajo una interfaz común orientada a un ambiente académico.
Las funciones de Scheme para manipular listas son:

cons
toma dos argumentos y regresa un par o lista.
(cons '1 '2)              is   (1 . 2)

El primer ejemplo es un par y los otros son listas. Pares o listas se pueden utilizar para implementar registros.

carregresa el primer miembro de una lista o par.

(car '(123 245 564 898))             is   123

cdrregresa la lista sin el primer elemento.

(cdr '(7 6 5))               is  (6 5)

null?regresa #t si el objeto es la lista nula. En cualquier otro caso regresa la lista nula.listregresa un alista construida de los argumentos.

(list 'a)                          is  (a)

lengthregresa la longitud de la lista.

     (length '(1 3 5 9 11)) is  5

reverseregresa la lista invertida.

     (reverse '(1 3 5 9 11)) is  (11 9 5 3 1)

appendregresa la concatenación de dos listas.

     (append '(1 3 5)  '(9 11))  is  (1 3 5 9 11)

Expresiones condicionales son de la forma:

(if test-exp then-exp)
(if test-exp then-exp else-exp).

Definiciones son de la forma:

     (define id exp)

Expresiones Lambda son funciones anónimas de la forma:

         (lambda (id...) exp )

Definiciones locales se introducen con las funciones let, let* y letrec. let se aplica en paralelo, let* es secuencial, y letrec permite definiciones recursivas.

• apply regresa el resultado de aplicar el primer argumento al segundo.

1 ]=>  (apply + '(7 5))

;Value:   12

1 ]=>  (apply max '(3 7 2 9))

;Value:   9

• map regresa una lista que es el resultado de aplicar el primer argumento a cada elemento del segundo.

1 ]=>   (map odd? '(2 3 4 5 6))

;Value: (() #T () #T ())

### Referencias:

The Allegro Common Lisp Open Source Center

Allegro CL

http://www.cs.berkeley.edu/~fateman/generic/

Richard J. Fateman

Algoritmos en Scheme

Taller sobre Scheme

Hobbit versión 5 compila R4RS Scheme a código C, que se puede usar con SCM Scheme Implementation

El paquete SLIB es una librería portable del lenguaje Scheme que funciona en varias plataformas e implementaciones, incluyendo Guile.

# Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

MDA asume que están disponibles modelos para cualquier artefacto.

MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

MDA asume que 3 tipos de modelo son suficientes:

computation-independent model,

platform-independent model,

platform-specific model.

MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

El uso de una fábrica de software incluye los siguientes pasos:

• Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.
• Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.
• Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.
• Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes
• Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.
• Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.

Referencias:

Bare-Naked Languages or What Not to Model

CodeGen’ing a Data Access Layer with CodeSmith

LLBLGen

Microsoft DSL

CodeSmith Community: .netTiers

Sean Mccormack’s Codus

Software Factories

Wilson OR Mapper templates for CodeSmith

Codegeneration.net

Can you code gen everything?

CodeSmith Community: Rocky CSLA Templates

CodeSmith Community: Files

Andres Aguiar’s Blog

Eric Smith’s Blog

.nettiers demo/tutorial DAL in 15 mins

Global Bank Scenario

Visual Studio 2005 SDK Version 4.0

http://blogs.msdn.com/jackgr/

Jack Greenfield’s Blog

Code Generation Network