En el 1750 Linnaeus creó la taxonomía de las especies; trabajó en ella durante años, y todo ello con el objetivo de resolver la confusión existente y recuperar la gran cantidad de conocimiento sobre los seres que habitan la tierra, conocimiento que estaba disperso, inconexo, bajo múltiples terminologías y clasificaciones. Hasta esta importante aportación se había estado descubierto especies durante siglos, pero nunca se habían organizado y relacionado.
En el campo del diseño software más de cuarenta años de experiencia han aportado mucho conocimiento. Hoy tenemos elementos de conocimiento en diseño muy populares como son los patrones y las refactorizaciones, pero también muchos otros, menos conocidos e igualmente importantes: principios, heurísticas, malos olores (bad smells), buenas practicas, defectos, anti-patrones, patrones de error (bug patterns), etc.
Pero el diseño software aún sufre la falta de estructura y clasificación de su conocimiento. Este se transmite con dificultad, sin organización, y es en la mayoría de las ocasiones conocimiento desaprovechado, donde los ingenieros aún siguen creando soluciones desde cero para los mismos problemas, problemas que han sido resueltos muchas veces años atrás.
Ya hace bastante que para resolver estos problemas nos propusimos definir una ontología que organizase el conocimiento en diseño. Que aunque el nombre suene “raro” no es más que una manera de describir el conocimiento de un dominio (similar a la taxonomía de las especies).
La ontología describe tres entidades principales: reglas, patrones y refactorizaciones. Sus relaciones, o como la aplicación de una regla (por ejemplo la de inversión de la dependencia o inversion of control) nos lleva a aplicar un patrón (en el ejemplo un creacional, un service locator o un assembler). Y como reglas y patrones han de poder introducirse en el diseño, por lo que están relacionadas con refactorizaciones concretas. El tema es más amplio y aquí se explica con más detalle.
Antes de terminar me gustaría destacar el concepto de regla. Aunque hay numerosa terminología diferente, términos como heurística, malos olores, mejores prácticas, principios, etc., tienen una estructura común que coincide con la de una regla, donde de cumplirse una condición ofrecen una recomendación. Conviene destacar como las reglas son diferentes a los patrones, ya que las reglas dicen “qué se podría mejorar” y los patrones “cómo solucionar un problema”, están mas basadas en el uso del lenguaje natural; los patrones están más formalizados que las reglas y la descripción de los patrones es siempre más amplia.
Debido a la importancia del término regla, también hace tiempo, realizamos un catálogo de las mismas, que las unificara tanto en formato como en descripción, forma, etc., y que ahora estamos subiendo a la Web. Y que está aquí.
Poco a poco iremos completando las reglas, e, importante, añadiendo más a la lista… y para ello sería un placer y un honor añadir cualquier regla que cualquier lector de este blog propusiera desde su experiencia, obviamente citando al autor de la misma, así como a quien complete y nos ayude a mejorar las ya existentes.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier, el link donde explicas con mas detalle el tema de la ontología en la ingenierí del software no se encuentra funcionando adecuadamente, redirecciona al home de Kybeleconsulting pero no a un artículo específico, pasa lo mismo con el catalogo de las reglas. Por otra parte está muy interesante el tema.