Patrón ERPAC y ontologías

¿Por qué las metodologías de desarrollo de ontologías no dan más valor a los patrones de análisis o (patrones de diseño como los llaman ellos)? 

Particularmente las aplicaciones las inicio pensando en en patrón ERPAC o en FAP ;-)

https://docs.google.com/document/pub?id=1LZYbsx5SMDKv14VU3EZLRC_cTMzkhX8u0OhBhkn-egk

Open Knowledge Base Connectivity OKBC

Open Knowledge Base Connectivity OKBC


... However, the resulting system may need to interoperate with other systems and applicatons, both intelligent and conventional. The other systems and applications will then typically demand services from the intelligent system and accesss to its konowledge, which implies communication between them. Owing to the potential variety of the underlying knowledge represetnation formalisms, providing communication interfaces and ensuring reliable interoperability may be difficult. Implementation of full-scale communication and interoperation may be time-consuming and may become quite cumbercome. Even worse, supporting all the idiosyncrasies of the underlying knowledge representation formalisms for each particular application may turn out to mean an enormous multiplication of effort"

Model Driven Engineering and Ontology Development

Dragan Gasevic

VirtualBox over Centos

Instalar VirtualBox


http://wiki.centos.org/HowTos/Virtualization/VirtualBox



Compración entre VirtualBox y KVM
http://www.ilsistemista.net/index.php/virtualization/12-kvm-vs-virtualbox-40-on-rhel-6.html

Quick references cards

http://www.digilife.be/quickreferences/quickrefs.htm

Competency question - Ontology

Un buen artículo sobre el desarrollo de ontologías (ejemplo: sobre vinos)
http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html

Define claramente qué son preguntas de competencia

Competency questions.

One of the ways to determine the scope of the ontology is to sketch a list of questions that a knowledge base based on the ontology should be able to answer, competency questions(Gruninger and Fox 1995).

Y otro aún mejor  (ejemplo: sobre servicios de empleo)

http://kmi.open.ac.uk/events/sssw08/presentations/Gomez%20Perez-NeOn-Methodology-OntologySpecification-v3.pdf

Y otros 

http://marinemetadata.org/references/competencyquestionsoverview

http://softwareontology.wordpress.com/2011/04/01/user-sourced-competency-questions-for-software/

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.5530

Innovar en la AAPP

http://www.ogov.eu/documento-innovar-en-la-administracion-publica/

Semantics of Business Vocabulary and Business Rules

Especificación OMG para escriribir reglas de negocio (en los anexos está lo interesante).

http://www.omg.org/spec/SBVR/1.0/PDF/

Ejercicio reglas de negocio

http://www.brcommunity.com/b627.php

The exercise

Mike loves sandwiches.  He loves them so much that after visiting his favorite sandwich store in New York, he realized that he could organize a better process and offer a lower price just by writing down a few rules for his employees.  He lays the ingredients out so that his customers can see their choices and so that his staff can quickly assemble the sandwiches.  The rules for assembling ingredients into a customer's sandwich are as follows:

Bread:  Every sandwich must have exactly one bread.  (Mike has three choices for bread:  White, wheat, and sourdough.)  A patron must choose a half or a whole loaf for a sandwich.

Meat:

• A regular sandwich must have at most one meat.
• A meat-lover's sandwich must have at most two meats.
• (Mike offers 5 choices for meat:  Turkey, Roast Beef, Ham, Salami, Pepperoni.)

Cheese:  A sandwich must not have more than one cheese.  (Mike offers American and Swiss cheese.)

Vegetables:  A sandwich must have all the vegetables that a patron wishes.  (Mike offers lettuce, tomato, peppers, onions, olives, sprouts, and pickles.)

Escribir reglas de negocio

Cómo escribir reglas de negocio de forma estructurada.


http://www.brcommunity.com/b282.php

Tésis:UNA APROXIMACIÓN MDA BASADA EN LÍNEAS DE PRODUCTOS SOFTWARE PARA EL DESARROLLO DE APLICACIONES

Esta tésis toca bastante sobre variabilidad y la aplica a casos reales

http://riunet.upv.es/bitstream/handle/10251/3793/tesisUPV2943.pdf

Variabilidad czarnecki y más---

La administración de la variabilidad es la principal preocupación en el desarrollo, mantenimiento y evolución de las SPLs. La variabilidad puede ser definida como la diferencia funcional dentro de los productos de una Línea [13]. Los retos relacionados con la variabilidad se centran en su representación, y en la derivación  de un producto a partir de la selección y expresión de esta variabilidad.


El principio básico para representar la variabilidad se basa en que las características de un producto que se diferencian de otros productos deben poderse representar. Diferentes aproximaciones para representar y expresar la variabilidad se basan en los modelos de rasgos [19], [11]. Un modelo de rasgos es un  árbol donde la raíz representa un concepto y sus nodos descendientes representan rasgos. Un rasgo es una propiedad del sistema que es relevante para algún stakeholder [12]. Semánticamente un modelo de rasgos describe un conjunto de todos las posibles configuraciones válidas [11], donde una configuración corresponde a la selección de un conjunto determinado de rasgos.

MD-SPL

http://paradigma.uniandes.edu.co/index.php?option=com_content&task=view&id=67&Itemid=31&showall=1&lang=en


"Una de las actividades principales descritas en el enfoque SPLE es el desarrollo de los activos base de la Línea de producto. De acuerdo al enfoque MDD, en esta fase se deben generar los metamodelos de los diferentes dominios (negocio, arquitectura, tecnología, etc.), las reglas de transformación respectivas y las plantillas de generación de código. Es importante tener en cuenta el nivel de abstracción que tienen los metamodelos de cada dominio, puesto que este nivel definirá los posibles conceptos soportados por los productos de la Línea que se esté diseñando."


"Una de las actividades principales descritas en el enfoque SPLE es el desarrollo de los activos base de la Línea de producto. De acuerdo al enfoque MDD, en esta fase se deben generar los metamodelos de los diferentes dominios (negocio, arquitectura, tecnología, etc.), las reglas de transformación respectivas y las plantillas de generación de código. Es importante tener en cuenta el nivel de abstracción que tienen los metamodelos de cada dominio, puesto que este nivel definirá los posibles conceptos soportados por los productos de la Línea que se esté diseñando.
"La variabilidad generalmente es representada por un modelo de rasgos (el cual se explicará en la siguiente sección). A través de un modelo de rasgos se pueden Especificar características deseadas de un producto en particular. Una vez definidas las características que tendrá el sistema a generar, se realiza el proceso de derivación, el cual incluye la ejecución de un conjunto de reglas. De esta manera, para cada posible selección de características debe existir un conjunto de reglas que se encargan de crear un producto conforme a la funcionalidad seleccionada.

La ventaja que tiene una MD-SPL sobre una SPL tradicional es que permite diseñar una Línea de producto en donde es posible abstraer los conceptos principales de los diferentes dominios y plasmarlos en metamodelos que, por naturaleza, limitan las posibles características soportadas por los productos. De esta manera, un conjunto de características determinado puede ser representado por un modelo que puede ser transformado automáticamente a través de los diferentes dominios hasta obtener el código fuente.""

Pluggable UC

http://alistair.cockburn.us/Pluggable+use+cases

UC wins BPMN

Parece que los CU se entienden más que BPMN

http://www.cs.put.poznan.pl/lolek/homepage/Research_files/06-BIS-Nawrocki,%20Ne%CC%A8dza,%20Ochodek,%20Olek%20-%20ver1.pdf

y gustan más
http://kettenisblogs.blogspot.com/2007/10/demystifying-business-process-modeling.html

Metamorphosis of actors - Writting Use Cases

De http://www.cs.put.poznan.pl/lolek/homepage/Research_files/06-BIS-Nawrocki,%20Nędza,%20Ochodek,%20Olek%20-%20ver1.pdf


UC-3: Earning a bachelor degree
Main actors: University
{Candidate alias Admitted alias Student alias Graduated alias
Free Student alias Deleted}
Supporting actors: Senate, Rector
Main scenario
1. Senate defines the rules concerning admission.
2. Rector appoints members of the Enrolment Committee.
3. University organizes the Open Doors action.
4. Candidate makes the application.
5. Enrolment Committee announces lists of admitted. Candidate becomes
Admitted
6. Admitted starts up his study. Admitted becomes a Student.
7. Student successfully passes through semesters from 1 to 7.
8. Student takes a diploma exam. Student becomes Graduated.
9. Graduated receives a diploma.
Extensions
5a. Candidate is not admitted due to lack of free places.
5a1. Candidate is studying as a Free Student. Go to step 8.

Figure 7. A use case with actor metamorphosis

Flujo paralelos con CU

Tan sencillo como:

“Steps 5-13 are optional and can happen in any order”

Releer BPMN

Estoy volviendo a leer cosas de BPMN. Todavía me gustan más los CUs.

Ejemplo
http://bizagi.com/docs/BPMNbyExampleSPA.pdf
Especificación y más
http://www.bpmn.org/

¿Cómo medir la expresividad de nuestros DSL?

How do you measure the expressive power of your DSL?

Since comparison of programming languages in this regard isn't easy to be formalized, no de facto standard has been given yet. Have you ever tried to measure the expressive power of your DSL against e.g. Java, or C?

Antonio Vallecillo •  In my experience the Expressiveness of a language is hard to measure in an objective way. Using a similar approach to ISO-9126, which defines quality characteristics and sub-characteristics, I think Expressiveness is a characteristic that can be decomposed in terms of 4 sub-characteristics:

1.  Conciseness, 
2. Precision (i.e., lack of vagueness :-)
3.  Completeness and 
4. Suitability. 

Other important characteristics of DSLs are: 

• Usability (Learnability, Understandability, Operability, Attractiveness), 
• Maintainability (Analysability, Changeability, Stability, Testability) 
• and Reliability (Consistency, Maturity). 

Although such classification is nice, it is useless unless we have a set of objective measures that can help evaluate them - for particular languages and in particular domains, of course! 


There is some *intuition* that for instance the number of metaclasses and relationships between them (i.e., the size) of the metamodel that defines the abstract syntax of the language can positively impact the Completeness and negatively impact the Learnability, Understandability, or Maintainablity of a language. Or that the use of the adequate symbols in the concrete syntax may favour the attractiveness of the language, although it is not clear whether visual or textual concrete syntaxes favour operability or not. In any case, this issue opens up an interesting research field related the quality of DSLs. 

Coming back to expressiveness, given that we do not have such measures yet, it could be (needs to be) evaluated by


experiments that show some evidences about how the language positively or negatively impacts its four related subcharacteristics, 


in the particular domain your DSL is targeted to. Thus, probably the easiest way is to prepare a set of experiments that test how users perform using the two (or more) competing languages when they have to express something of the domain under study. I believe there have been many different experiments defined for deciding whether textual languages are better than visual ones for programming (for "end-user development" [http://en.wikipedia.org/wiki/End-user_development], and specially when the users are kids). But for DSLs I am not sure I have seen anything like that. The problem for DSLs is that it is VERY dependent on the domain... 

My two cents, 

Antonio

Cockburn

While workflow enactment is often configured through a work-
flow description language based on graphs or rules, an alternative approach takes written Use-Cases to describe a workflow. In this paper
we give evidence for the expressive richness of this approach. We show
that written Use-Cases can describe each of the 43 workflow patterns
identified by the Workflow Patterns Initiative.


http://sydney.edu.au/engineering/it/research/tr/tr611.pdf

Web sobre BA.

Web muy interesante sobre analistas de negocio:

http://www.batimes.com/articles/

Bloqueo innovación

Conferencia sobre SPL - Sept/Oct 2011

http://www.bits-chips.nl/events/eventshpl/programme.html

DSL

At a DSL workshop I organised in June (http://wiki.portal.chalmers.se/cse/pmwiki.php/GSDP/DSL4EE) Fritz Henglein presented his group's work on DSLs for Enterprise Resource Planning: http://www.cse.chalmers.se/~patrikj/DSL4EE2011/DSL4EE_Henglein.pdf
One of the resulting publications is "POETS: Process-Oriented Event-driven Transaction Systems"
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.163.2167

So, if this counts as a partial answer to your question, then Yes, it is worth it, but No, UML is not the path I would recommend.

Also Jeremy Gibbons' talk at the same workshop is about a successful example of implementing an "information system" - in that case in the medical sector (CancerGrid project): http://www.cse.chalmers.se/~patrikj/DSL4EE2011/DSL4EE_Gibbons_dsl4ir.pdf

/Patrik

Modelos, MDD y enseñanza

http://www.se.uni-oldenburg.de/documents/olnse-2-2011-EduSymp.pdf#page=67

Thanks Roda


Algunos recortes:

"(2) MDSD is generally taught top-down, whereas industry success is
more likely when MDSD is applied bottom-up;"



"..Practical application of domain modeling is pragmatic, where DSLs (and accompanying generators) are developed sometimes in as little as two weeks."

"Hence, much MDSD success is ‘hidden’ – in the sense that there is very widespread use of mini-DSLs, often textual, and that there may be many such mini-DSLs used within a single project: one interviewee reported on the use of multiple XML-based DSLs to generate 70% of a system, for example."



"Most modeling courses tend to focus on UML and, furthermore, emphasize the presentation of notation rather  than principles Most UML books put notation first and concept structuring is either only secondary or hidden entirely. Although much more limited, books on DSLs (e.g., [3]) seem to do a better job of teaching general principles of (domain) modeling.

[3] Tony Clark, Paul Sammut, James Willans: Applied Metamodelling, A  Foundation for Language Development, 2nd Edition. Ceteva, 2008."


¡Que bueno!:
" we went out, we bought 4 boxes of the monopoly board game… We gave them this, we said go model the game using these concepts"


 "This way of working suggests that developers find it easier to get to grips with MDSD when they use it to refactor existing assets from the ground-up rather than trying to abstract from above. In turn, it suggests that modeling should be taught bottom-up rather than top-down. "


"Maybe the best way to teach models is not to teach the topic of models. Maybe the best way to teach models is to teach other topics by using models as an explanatory device. "

Administración Electrónica - Asturias

Anemic Domain Model

http://www.martinfowler.com/bliki/AnemicDomainModel.html

gracias Axel.

Business Model Generation Canvas

Business Model Generation Canvas una herramienta muy efectiva para discutir modelos de negocio.

Bajar el pdf en:

http://www.businessmodelgeneration.com/canvas

 

Business Rule Concepts: Getting to the Point of Knowledge

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1814/Business-Vocabulary-The-Most-Basic-Requirement-of-All.aspx

Herramienta CU

Esta herramienta está inspirada en la escritura de CU de Cuckburn (algunas reglas las simplifca) http://www.casecomplete.com/

Language Workbench Competition 2011 Feature Matrix

Inspirada por Pedro Molina http://www.languageworkbenches.net/ar.html

SPLC 2011 - VOELTER

http://www.voelter.de/data/presentations/SPLC2011-Paper.pdf http://www.voelter.de/data/pub/VoelterVisser-PLEusingDSLs.pdf

SPLC2011 -

SPL at SIEMENS http://www.splc2011.net/downloads/achatz_keynote_splc_final.pdf

Normas UNE

Paseando por Las Caletillas, me veo este cartel. ¡Que bien! cumple la UNE-EN 957.
¡La pena es que tengo que pagar 30 euros por capítulo para saber que es!
http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0043466&PDF=Si

Ontology Engineering Methodologies - videolectures.net

Ontology Engineering Methodologies - videolectures.net

Concrete

is a lightweight, web-based editor for Domain Specific Languages (DSLs)
is setup for a specific DSL, knows the language commands and provides Auto Completion
permanently checks the consistency with the DSL and provides Error Annotations
can give language elements almost any look expressible with HTML and CSS
is a Javascript widget which can be embedded into virtually any web application
exchanges data with a backend via the widely used JSON format
is based on Prototype and uses Scriptaculous


http://concrete-editor.org/#documentation

Libros sobre SPL

http://books.google.com/books/about/Applied_Software_Product_Line_Engineerin.html?id=7XO_ghvkpt4C

http://www.mypearsonstore.com/bookstore/product.asp?isbn=0201703327

Articulo de Voelter

http://www.voelter.de/data/pub/VoelterGroher_SPLEwithAOandMDD.pdf

http://www.infoq.com/presentations/MDD-Beyond-Code-Generation

Libro sobre gestión de empresas

Yeray nos propone

Ecosistema para los alumnos de la ETSII

A través de Jesus Torres me entero de

http://blog.klicap.es/archives/957

tendré que contactar con ellos para ver posibles líneas de colaboración.

Web sobre DSL

Otra web sobre DSL con mucho contenido para leer.

http://domain-specific-language.co.tv/

No conocía esta web!. Imperdonable.
http://www.voelter.de/

A model-driven framework for domain specific languages demonstrated on a test automation languag

A model-driven framework for domain specific languages
demonstrated on a test automation languag

http://karlsch.com/frodo.pdf

YAML vs. Xtext

Hasta el momento he visto como crear DSLs usando Xtext y Xpand
Es posible usar YAML como DSL. ¿Cuál sería la metodología de generación? ¿Y la gramática?

Lo que es indudable que los ficheros YAML son senciilos de leer.


http://www.yaml.org/spec/1.2/spec.html

Transferencia tecnológica MDD

Transferencia tecnológica a las empresas de MDD
http://www.taro.ull.es/dsdm10/autogsa-novatica.pdf


MDA vs. DSL
http://www.uclm.es/dep/tsi/pdf/Informe_T.pdf

Biglever and Pure-Systems - SPL

Empresa especializada en SPL su producto GEAR
http://www.biglever.com/
http://www.biglever.com/extras/BigLever_Solution_Brochure.pdf
http://www.biglever.com/extras/Gears_Data_Sheet.pdf


http://www.pure-systems.com/
http://www.pure-systems.com/Downloads.31.0.html
http://www.exmotion.co.jp/service/spl_demo_movie_en.asx

Congreso SPL 2001 en Munich

Congreso SPL 2001
http://www.splc2011.net/tutorials/index.html

Firmar correos con thunderbird y el FNMT

Para firmar correos desde el thunderbird con nuestro certificado de la FNMT primero debemos descargar el certificado raiz de la FNMT.


http://ospatia.blogspot.com/2008/01/descargar-certificado-raiz-de-la-fnmt.html
http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer

SPL

http://grandview.rymatech.com/2009/15-introduction-to-the-sei-framework-for-software-product-line-practice.html

http://grandview.rymatech.com/2009/16-software-product-lines-an-effective-business-and-development-strategy.html

http://grandview.rymatech.com/2010/30-exploring-product-line-opportunities.html

http://grandview.rymatech.com/2009/46-towards-compositional-software-product-lines.html

http://www.cs.helsinki.fi/u/vjkuusel/gradu/vanhat/Software%20Product%20Lines.pdf

FTP con TLS.

Este script sube ficheros a un servidor ftp con tls activado (que no es igual a sftp!)


cat sube-fichero
echo | lftp SERVIDOR-FTP -u USUARIO,PASSWORD< set ftp:ssl-allow true
set ftp:ssl-force true
set ftp:ssl-protect-data true
set ftp:ssl-protect-list true
put $1
EOF

Extensión de Chrome inglés

Para los que están estudiando inglés.
Un extensión de Chrome que lee lo que has seleccionado.

https://chrome.google.com/webstore/detail/pgeolalilifpodheeocdmbhehgnkkbak

Upstart

Página web en la que explica muy el sistema upstart (/etc/init)

http://upstart.ubuntu.com/cookbook/#mountall-ubuntu-specific

KnowledgeTree

Gestión de documentos en la nube.
https://www.knowledgetree.com/f

8 Best Practices for Adopting Document Management

View more documents from KnowledgeTree Inc.

Five Static Code Audits Every Developer Should Know and Use

http://www.infoq.com/presentations/Five-Static-Code-Audits

ESXi. Tech Support Mode for Emergency Support

Como apagar una maquina en ESXi 4.0 cuando VClient falla.

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1003677
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014165

Entrar en modo TSM

1. Alt+F1
2. Escribimos unsupported
3. Metemos el password
4. clear
5. vm-support -x
6. vm-suport -X
o
6. vm-suport -X -w

Mendix - Esto es marketing

Mendix Agile Business Platform™ in 90 Seconds from Mendix | No Code Just Glory on Vimeo.

DSL tools VS. Model Driven Software Factory

Un buen artículo que diferencia estos dos conceptos. DSL tools y MDS Factory

http://www.theenterprisearchitect.eu/archive/2009/02/18/model-driven-engineering-tools-compared-on-user-activities

DSL tool:

* Workbenches: DSL workbench and transformation workbench.
* Input: DSL definitions and transformation rules.
* Output: solution workbench and generator.
* Tool vendor activities: meta language definition, transformation language definition, workbench implementations.
* Tool user activities: DSL definitions, transformation rules, architecture definition, (domain) framework implementation.
* Examples: openArchitectureWare, MetaEdit+, Microsoft DSL Tools, JetBrains Meta Programming System.

Model Driven Software Factory:

* Workbenches: solution workbench.
* Input: functional specification.
* Output: working application.
* Tool vendor activities: DSL definitions, transformation rules, architecture definition, domain framework implementation, solution workbench implementation.
* Tool user activities: application modeling.
* Examples: Mendix (domain: Service Oriented Business Applications).




"--. Building your own DSLs, i.e. using DSL tools, gives you all the flexibility you'll ever need. However, it also comes with a cost: DSL design isn't that easy. Designing a full set of DSLs for modeling all application aspects will cost a lot of effort (the DSLs will evolve along with the applications you build with them). And don't forget the training, language support, standardization, and maintenance of your languages.

A Model Driven Software Factory, on the other hand, is only useful if it precisely targets the domain you're searching a solution for. You also need to commit you to the vendor of the factory. However, the domain of a Model Driven Software Factory can be quite broad and with current business process engines, workflow engines, and business rules engines, the used languages can be both applicable to multiple problem domains and easy to understand for business engineers. With a Model Driven Software Factory you can directly start using the DSLs for modeling your application and you don't need to have the expertise in-house to define the languages, transformations, and generators yourself"

Casos de Uso y Decision Model

Pueden vivir juntos CU y RN

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/1442/Use-Cases-and-Business-Rules-Can-They-Work-Together.aspx

How to start a business analyst career

Dos blogs sobre análisis

Qué estrés cuando uno encuentra blog's tan buenos...

http://www.modernanalyst.com
http://www.pragnalysis.com/
http://www.bridging-the-gap.com/

Dos libros

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers [Paperback]

 Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers [Paperback]

MDA vs. MDD vs. SPL vs. DSL

Ayer, escribiendo un artículo se planteo una duda formal en la frase

"En el diseño del DSL se ha evitado la inclusión de elementos de asociados a la tecnología intentando  aumentar al máximo el nivel de expresividad del mismo acerdándolo al dominio del problema."

Algunos opinan que era incorrecta otros (sólo yo) opinan que es correcta.

En la conversación aperecieron otras discrepancias con la frases, "MDA no está alineado con SPL".

Bueno, intentaré expresar mejor mi opinión  en este post.

Lo primero que quiero decir es que el mundo de Model-Driven y  generación de código los conceptos, ideas y paradigmas se enlazan entre sí de una manera confusa y a veces peligrosa. He buscado en la bibligrafía una comparación entre MDA y MDD que incluyo al final del post.

Brevemente:

• MDA es una iniciativa de OMG interesada en la interoperabilidad entre herramientas,  portabilidad y estandarización. Y no en la productividad y la calidad

• MDA juega con los conceptos UML, MOF, PIM, PSM, XMI, Metamodelos

• MDA no excluye la idea de round-tripping (sincronización de código y modelo). MDD sí
• MDA no usa el concepto de DSL . 

En cambio MDD busca otros objetivos diferentes que son las productividad y calidad en el código.

• MDD usa el concepto de DSL
• Con los DSL hablamos de DSL técnicos o funcionales con mayor o menor grado de expresividad. 
• Si nos vemos forzados a meter detalles tecnológicos  lo que hay que pensar es "no estoy logrando en nivel de abstracción adecuado, ¿es necesario introducir esta semántica en el DSL?" y no "tengo 2 DSLs un PIM y otro PSM". Y mucho menos creer en los mundo de Jupi de MDA y decir "puedo crear otro DSL PSM para otra arquitectura.¡NO!". Si quieres otra arquitectura nos montamos otro generador. E intentaremos mantener el DSL lo más intacto posible de la nueva tecnolgía (si no tendremos otro DSL). El conocimiento de la arquitectura está en el generador y no en los DSL. ¡En algo sustancial se tiene que diferenciar MDD de MDA.!
• Mezclar la idea de DSL PIM y DSL PSM creo que no es buena idea. Pensemos en SQL (un DSL) que intenta abstraerse lo más posible de la integración del sistema gestor de base de datos pero aún así existen diferentes versiones de SQL para diferentes SGDB. No hay un SQL independiente del dominio y otro dependiente.

Sobre la discusión de SPL y MDA, dos detalles:

• La idea de SPL viene SEI y no de OMG
• SPL piensa en productividad y calidad. OMG en interoperabilidad y portabilidad

Análisis del dominio

Técnicas de análisis del dominio.

FODA Feature Oriented Design Analysis
DARE Domain Analysis and Reuse Enviroment
ODE Ontology Based Domain Engineering
FAST Family Oriented Abstraction Specification and Translation


y una presentación sobre SPL
http://redwood.snu.ac.kr/files/Seminar%202008_06_11%20SPL.ppt

DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design

DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design
http://www.theenterprisearchitect.eu/archive/2009/05/06/dsl-development-7-recommendations-for-domain-specific-language-design-based-on-domain-driven-design


MDE - Model Driven Engineering - reference guide

http://www.theenterprisearchitect.eu/archive/2009/01/15/mde---model-driven-engineering----reference-guide#model-interpretation

Model Driven Engineering tools compared on user activities

http://www.theenterprisearchitect.eu/archive/2009/02/18/model-driven-engineering-tools-compared-on-user-activities

Y más
http://www.theenterprisearchitect.eu/tag/model_driven

DSL textuales y su capacidad expresiva

La gran ventaja de los DSL textuales es la facilidad en la que podemos introducir en ellos información relativa a

* Interfaces de usuario
* Entidades de negocio y restricciones
* Procedimientos y procesos
* Reglas de negocio

En otra entrada del blog me cuestiona si los DSL debían solo expresar la variabilidad del espacio del problema, si esto fuera así, ¿no dificultaría esto la evolución correcta del dsl?, pero... ¿para qué poner expresividad en el dsl que el generador nunca usará?

10 best practices for Windows security

http://www.techrepublic.com/blog/10things/10-best-practices-for-windows-security/2383?tag=nl.e101

USB booteable for Windows 7

http://www.askvg.com/a-bootable-usb-utility-to-create-bootable-usb-drive-to-install-windows-vista-server-2008-and-7/

Conoces Dropbox, ahora se une Amazon

https://www.amazon.com/clouddrive/learnmore

Perfiles Windows 7 y otras cosas

Bueno, estos días toca Windows 7 y sus perfiles.

Configurar un perfil obligatorio
http://blogs.technet.com/b/deploymentguys/archive/2009/10/29/configuring-default-user-settings-full-update-for-windows-7-and-windows-server-2008-r2.aspx?PageIndex=1#comments
http://support.microsoft.com/kb/973289/es?p=1

http://technet.microsoft.com/en-us/library/cc786301(WS.10).aspx



Managing User Profiles
from Chapter 9, Microsoft Windows 2000 Administrator's Pocket Consultant by William R. Stanek.
http://technet.microsoft.com/en-us/library/bb726990.aspx


SCCM : Windows 7 deployments & unattended.xml

http://scug.be/blogs/sccm/archive/2010/02/02/sccm-windows-7-deployments-amp-unattended-xml.aspx

Work with Answer Files in Windows SIM

http://technet.microsoft.com/en-us/library/dd799285(WS.10).aspx

Kit de instalación automatizada de Windows para la Beta de Windows 7

http://technet.microsoft.com/es-es/library/dd349343(WS.10).aspx

Redirección de carpetas.
http://technet.microsoft.com/en-us/library/cc732275.aspx

User Stories

Metodología de desarrollo y UPV

La UPV tiene un grupo de trabajo en el desarrollo de una metodología de desarrollo:


http://www.tuneupprocess.com/

¿Por qué no escribir documentación?

Porque no lo van a leer.

TAGRI They Aren't Gonna Read It

http://www.dosideas.com/noticias/metodologias/361-igual-no-lo-van-a-leer.html

Un hilo interesante sobre CU.

http://groups.google.com/group/agile-spain/browse_thread/thread/e6253d01542c2e29

Blog sobre agilismo.

Debería hacer un listado con los blogs que suelo leer... otro más para la tonga.

http://blog.agilmedia.com/

Requerimientos y automatización

No sólo de Xtext viven los DSL

Summary
Bernhard Merkle discusses the various types of DSLs, and compares different language workbenches by using them with the same custom DSL in order to outline the differences between them

http://www.infoq.com/presentations/Textual-Modeling-Tools

User Stories

Articulos interesentas sobre user stories:
http://scalingsoftwareagility.files.wordpress.com/2009/11/user-story-primer_1.pdf

• INVEST
• ¿Cómo definir user stories? Granularidad

http://scalingsoftwareagility.files.wordpress.com/2009/03/agile-porfolio-management-denver-apln-mar-2009.pdf

Libro sobre agilismo y requirimientos.

The Downfall of Agile Hitler

The Downfall of Agile Hitler



Hitler and Unit Testing

Ruby y Rails

Los tutoriales cada vez son más frikis:

http://tryruby.org
http://www.codeschool.com/courses/rails-for-zombies

Retomando las lecturas de ATDD

Concordion is an open source tool for writing
automated acceptance tests in Java
http://www.concordion.org/Example.html

Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD).
http://code.google.com/p/robotframework/


Otras herramientas de ATTD
http://www.dosideas.com/wiki/Herramientas_Para_Pruebas_De_Aceptacion

Libros sobre alta disponibilidad y gestión de almacenamiento

Gestión de virtualización con OpenNebula

El otro día me comentaron este software para gestionar entornos virtualizados. Habrá que probarlo.


http://opennebula.org/start

Fully open source (not open core), thoroughly tested, customizable, extensible and with unique features, excellent performance and massive scalability to manage hundreds of thousands of VMs in your cloud or data center infrastructure:

* Private cloud with Xen, KVM and VMware,
* Hybrid cloud (cloudbursting) with Amazon EC2, and other providers through Deltacloud (ecosystem),
* Public cloud exposing Amazon EC2, OGF OCCI and vCloud (ecosystem) APIs… and much more.

Playframework

Un framwork de desarrollo web en Java con sabor a RoR

A web app in 10 minutes using Play framework from zenexity on Vimeo.

Deuda tecnológica

Supongo que a todos nos ha pasado, ¿en qué momento debemos pagar la deuda tecnológica de nuestros proyectos?


http://www.techrepublic.com/blog/programming-and-development/avoid-getting-buried-in-technical-debt/3849
http://en.wikipedia.org/wiki/Technical_debt
http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html

InfoQ: Textual DSLs Made Simple

InfoQ: Textual DSLs Made Simple

Virtualización de clientes

La solución de virtualización de clientes de VMWare tiene muy buena pinta.
Lo que más que gusta es que permite el modo offline del servidor.

http://www.vmware.com/products/view/

¿cómo lo harán? ¿Usarán entonces toda la potencia de cliente?


La solución de RedHat basada en KVM está muy bien pero parece que no ofrece esta posibilidad.

http://www.redhat.com/virtualization/rhev/desktop/

Herramientas DSL

Una herramienta para desarrollo de DSL textuales (no todo va a ser Xtext)


http://www.jetbrains.com/mps/


También está metaedit, pero esta no es textual.
http://www.metacase.com/cases/dsm_examples.html

Próximo libro de Markus Volter

Ya está en el fuego el próximo libro de Markus Volter,

Aquí está disponible la introducción
http://dsl-engineering.org/wiki/bookintro

Toca muchos palos, y hace una buena clasificación de DSL. En particular algo que estaba buscando sobre DSL y requirimientos.

"

DSLs in Requirements Engineering.

A related topic to application domain DSLs is the use of DSLs in the context of requirements engineering. Here, the focus of the languages is not so much on automatic code generation, but rather on precise and checkably complete description of requirements. Traceability into other artifacts is important. Often, the DSLs need to be embedded or otherwise connected to prose text, to integrate them with "classical" requirements approaches.

Examples include a DSL for helping with the trade analysis for satellite construction or pseudo-structured natural language DSLs that imply some formal meaning into domain entities and terms such as should or must."

Software Factories

Un serie de entradas sobre SF.

http://0x7c00.wordpress.com/2007/08/24/software-factories-introduccion-parte-1/
http://geeks.ms/blogs/lontivero/archive/2007/09/30/software-factories-introducci-243-n-parte-3.aspx
http://geeks.ms/blogs/lontivero/archive/2007/10/02/software-factories-introducci-243-n-parte-4.aspx

Dos libros sobre dsl

Dos libros de DSL de Mannig, con sus capítulos gratis:

Este libro se centra en DSL internos con Ruby, Scala, ...

Introducción a los DSL http://www.manning.com/ghosh/sample_Ch01_DSLsIAfm.pdf

DSL internos: http://www.manning.com/ghosh/sample_Ch04_DSLsIAfm.pdf

El otro libro

http://www.manning.com/ghosh/
Explica que es un DSL http://www.manning.com/rahien/Sample1.pdf

Cómo gestionar la evolución de un DSL

Si estás desarrollando DSL, en algún momento tendrás que plantearte cómo será su evolución a lo largo del tiempo.

http://www.infoq.com/articles/dsl-evolution

Escribir buenos DSL

Debemos aprender a escribir buenos DSL. En este articulo nos enseñan a agrupar condiciones (como nos enseñó Cockburn al escribir en CUs)

One of the common mistakes in a DSL is to create one that solve a demo problem and leave it at that.

As a simple example, let us say that we build a DSL to handle order management. Here is a typical scenario that was talked about during development:

when is_preferred_user and order_amount > 500:
 apply_discount 5.precent

Sounds reasonable, right?

Except, that this isn't really a good way to express a business rule. A common business rule usually have a lot more complexity to it. Here is a good example:

when user.payment_method is credit_card and ((order_amount > 500 and order_amount < 1200) or number_of_payments < 4) and 
    user.is_member_of("weekend buy club") and Now.DayOfWeek in (DayOfWeek.Sunday, DayOfWeek.Sutarday) 
    and applied_discounts < 10:
 apply_discount 5.precent

At a glance, what the !@$!# does this rule do?

This is a good example of stagnant DSL. It is no longer being actively developed (easily seen by the use of framework terms such as DayOfWeek), and the complexity is growing unchecked.

This is usually the case when the DSL design has not taken into account new functionality, or when it relies on developers to be able to extend the language when needed. Because it requires developer involvement, it is often easier to patch it by complex conditional rather than express the actual business logic in a readable way.

A good way to avoid that is to incorporate known best practices from the development side into our DSL. In other words, we need to allow encapsulation and extensibility in our DSLs. As a simple example, we can allow the following:

condition weekend_club_member:
 user.is_member_of("weekend club memeber")
condition sale_on_weekend:
 Now.DayOfWeek in (DayOfWeek.Sunday, DayOfWeek.Sutrday)
condition good_payment_option: # yes, I know, bad name, deal with it
 ((order_amount > 500 and order_amount < 1200) or number_of_payments < 4)

And now the condition becomes:

when user.payment_method is credict_card and good_payment_option and sale_on_weekend 
     and weekend_club_member and applied_discounts < 10:
 apply_discount 5.precent

This is important, because it avoid a language rot and provide the facilities to the end user to add abstraction levels.

Markus Voelter un nuevo faro.

Después de admirar mucho tiempo a Alistair Cockburn por la lectura de su libro "Writting Effective Use Cases", hoy tengo un nuevo faro en lo que se refiere a la ingeniería del software  en el tema de  modelado, DSL y generación de código: Markus Voelter.

Estoy leyendo  http://www.voelter.de/data/articles/TheModelCraftsman.pdf.

Y descubro que es el mismo que el libro "Model Driven Software Development" y tambien lo había escuchado en se-radio.net.

DSL y variabilidad

"Los DSL tienen a establecer la variabilidad dentro de las aplicaciones de un dominio pero no expresan los conceptos éste. Están pensados para generar código no para entender el dominio - Pedro González"




"DSLs aren't for simple use cases. DSLs are for use cases where repetition exists within the problem or solution domains. It's why we create classes with methods (a very simple language expressed as an API), it's why we create XML configuration files, it's why we create content management systems (and metadata management systems), it's why we write little languages and parsers, and why we create languages using visual language toolkits like Microsoft DSL tools, openArchitectureWare and MetaEdit+ . . .
Software product line engineering is about creating a combination of frameworks, re-usable code snippets, DSLs for unbounded variability spaces and configuration managers and feature modelers for bounded variability spaces - often in a structure where ad-hoc custom code can be added for functions that are not worth developing a DSL and an interpreter (framework) or compiler (code generator) for. The trigger point for the effort of developing a DSL providing a ROI depends on the tooling, experience and inclinations of a given developer.
There is no application you can write that I can't generate. There are parts that it may not be worth me generating, but there are patterns of best practices in everything from object modeling to UI design and I think that much more of our skills and best practices can be turned into reusable heuristics than we might like to admit"

Revistas de Pragmatic Programers.

http://www.pragprog.com/magazines

why modeling and code generation are not agile?

http://www.modeldrivensoftware.net/forum/topics/why-modeling-and-code?commentId=2573822%3AComment%3A7911

Toni Dorta

Un buen blog
http://apdorta.blogspot.com/

25 recomendaciones sobre usabilidad

http://uselog.oli.tudelft.nl/publications/Recommendations-VanKuijk.pdf

Wireframes

Un blog muy interesante sobre skecting

http://wireframes.linowski.ca

A partir de él encontré cosas como
http://jasonfurnell.files.wordpress.com/2010/12/business_model_canvas_facilitator_cards1.pdf
o como
http://www.youtube.com/watch?v=pWPjjoOFIu8&feature=player_embedded

InfoQ: Book on Leveraging Domain-Specific Languages by Martin Fowler with Rebecca Parsons

InfoQ: Book on Leveraging Domain-Specific Languages by Martin Fowler with Rebecca Parsons

Virtualización con KVM

http://www.redhat.com/virtualization/rhev/server/

Amazon S3

http://c2.com/cgi/wiki?GuiPrototypingTools

Herramientas para el prototipado de IU

Listado de herramientas para el prototipado.


* Balsamiq una buena opción para el prototipado low-fi.
* y Mockflow




http://c2.com/cgi/wiki?GuiPrototypingTools

Recursos Ruby

Best Partices Ruby
http://majesticseacreature.com/rbp-book/pdfs/rbp_1-0.pdf

Quick Reference Ruby
http://www.digilife.be/quickreferences/qrc/ruby%20language%20quickref.pdf

Tutrial Ruby
http://akitaonrails.com/files/RubyFacil_071105.pdf

Articulo interesante sobre DSL y ruby

http://talhah.com/Thesis/

Martin Fowler - Introducción a DSL (video y slides)

http://www.infoq.com/presentations/domain-specific-languages

Dos libros sobre dsl

Este está en Safari Books online:

DSL y ruby

Advanced DSLs in Ruby

Martin Fowler.- Language Workbenches: The Killer-App for Domain Specific Languages?

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories.
...
http://www.martinfowler.com/articles/languageWorkbench.html

Katas

Página web en el que se propone un kata por mes y la comunidad sube a github sus soluciones.

http://www.12meses12katas.com/

Uncle Bob

http://www.artima.com/weblogs/index.jsp?blogger=unclebob
http://www.artima.com/weblogs/viewpost.jsp?thread=7588

Summary
As software craftsmen, we have rules. Sometimes we feel bad when the rules mut be broken. They're just rules though. What's important is that we have a moral center, a professional core, that refuses to compromise the quality of our work.

---

As software craftsmen we have rules, disciplines, and practices that we follow 
to help us maintain a high degree of quality and professionalism.  However, 
there are always trade-offs, always considerations, always possibilities. 
Sometimes we abandon a complex test case because we need to finish the task,
and visual inspection or manual testing is sufficient.  Sometimes we fail to
write an acceptance test because it's complicated, and the bang-for-buck is
low.  Sometimes we don't program in pairs, because -- well -- we don't have
a partner nearby, or we're sick of programming with someone else, or the
current task is mechanical.  Sometimes we keep a module checked out for more
than a couple of hours.  Sometimes (damned rarely!) we check in code that
fails to pass all the acceptance tests, or all the unit tests.  

They're just rules, and rules are made to be broken.

Blindly following rules is a fools errand.  We have enough grey matter to
discern when the rules are helpful and when they are not.  We have the
responsibility to continuously measure whether the rules are helpful, or
whether they are not.  

But then -- there's something else.  

Something that is cold and hard, and yet simultaneously hot and blazing.
Something, amidst all the compromise and ambiguity, that is neither
compromised nor ambiguous.  Something that spawns and respawns the rules we
follow, and yet challenges those rules at every turn.  

The still small voice; the angel's trumpet, the grim determination, the
joyous declaration: 

  "I WILL NOT SHIP SHIT."  

 - "I am a professional -- a craftsman!"
  -- "No matter what pressures are on me."
  -- "No matter how I've had to bend the rules."
  -- "No matter what shortcuts I've had to take."
  -- "No matter what the gods, or managers, have done or may do."

  --  --  "I WILL DO THE BEST WORK I CAN POSSIBLY DO."
  --  --  "Anything short of my best is shit."
  --  --  "I _ WILL _  NOT _ SHIP _ SHIT."

For me, at least, this is what it all comes down to.  I find that the rules
of XP help me to achieve this most of the time  -- more of the time than any
other set of rules I have followed.  But rules are rules, and when they get
in the way of this goal, they get set aside.

I do not set the rules aside lightly.  Indeed, when in doubt, I follow them.
When the pressure is on, I follow them.  When the deadline looms, I follow
them.  I try hard not to let fear drive me.

Fear is the mind killer.  It breeds idiocies like:

   "We don't have time to write tests."
   "We don't have time to program in pairs."
   "We don't have time to integrate continuously."
   "We don't have time to automate our acceptance tests."

These idiocies are a siren's song.  Their lure is strong.  Look in their
direction and The Despair begins.  All the rules will fall away.
  
Our core of professional pride is the cure.  That something that is both
cold and hard, yet hot and blazing.  It won't set aside a rule out of fear.
It sets aside a rule when *the rule* will cause you to ship shit.   

Go now, the lesson has ended.

Manfiesto agile vs. artesanía del software

Manifiesto artesanos del software

Como aspirantes a artesanos de software que están elevando los estándares dedesarrollo de software profesional mediante la práctica de ella y ayudar a otros aaprender el oficio. A través de este trabajo hemos llegado a valorar:

Para aquellos que desarrollamos software a medida.
Not only working software,but also well-crafted software 

1. (No hacer simplemente software, sino también hacerlo bien diseñado)
   
2. Not only responding to change,but also steadily adding value
   (No solo dar respuesta al cambio, sino también dar valor añadido continuamente)
   
3. Not only individuals and interactions,but also a community of professionals
   (No solo individuos e iteraciones, sino también una comunidad de profesionales)
   
4. Not only customer collaboration,but also productive partnerships
   (No solo colaboración con los clientes, sino también asociaciones productivas.)

Fuente : Manifesto for software craftsmanship

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.