El conocimiento de los desarrolladores de sistemas: cómo nutrirlo, sistematizarlo y potenciarlo. Alan Calderón Castro

Transcripción

1 El conocimiento de los desarrolladores de sistemas: cómo nutrirlo, sistematizarlo y potenciarlo Alan Calderón Castro

2 Temario Motivación Patrones de análisis de dominio Familias de productos de software Patrones de análisis y otros patrones Lenguajes de patrones y familias de productos de software Conclusiones

3 Motivación Mi trabajo académico con patrones consiste en: Enseñar el análisis y diseño orientado a objetos. Conceptualizar herramientas basadas en patrones para el desarrollo de familias de productos de software (FPS)

4 Qué son y para qué sirven los patrones? Un patrón describe primero un problema que ocurre una y otra vez en nuestro entorno, y a continuación describe el núcleo de la solución a dicho problema, de tal manera que usted puede usar la solución millones de veces sin repetir la solución específica una sola vez. Christopher Alexander (Timeless Way of Building)

5 Qué son y para qué sirven los patrones? Un patrón incluye cinco aspectos ( Problema (o Fuerzas), Solución, Contexto, Consecuencias, Conexiones) para sintetizar el conocimiento de expertos en diseño de software, en un dominio de aplicaciones o en un área del proceso de desarrollo de software.

6 Categorización de patrones de análisis Un patrón de análisis puede sistematizar conocimiento de análisis aplicable en muy diversos dominios. Un patrón de análisis de dominio (PAD) específico sistematiza conocimiento de un dominio o FPS específica. En tal caso sistematizan problemas y soluciones que aparecen en el contexto de una FPS.

7 Dominio específico Dominio (de aplicación): es un área de actividad o de conocimiento asociado con el desarrollo de una familia de productos de software. (Clements & Northrop). Por esta razón, más recientemente Gomaa plantea que análisis de dominio es simplemente el análisis que se hace al construir una familia de productos de software (o software product line ).

8 Visión de Fowler sobre los patrones de análisis El término patrón de análisis se atribuye a Martin Fowler (1997) que lo usa para: Sistematizar modelos asociados con un dominio de aplicación (o dominio específico) con el objetivo de reutilizarlos a lo largo de varias aplicaciones. Focalizar los aspectos organizacionales, sociales y económicos del proceso del desarrollo de software, ya que son fundamentales para el análisis de requerimientos, así como la usabilidad y aceptación final de todo sistema.

9 Qué es la IFPS? Desde la perspectiva de Software Product Lines (en adelante FPS) de Clements y Northrop: Una FPS es un conjunto de sistemas intensivos en software que comparten un conjunto administrado de características que satisfacen las necesidades específicas de un segmento particular de un mercado o de un tipo de misión crítica y que son construidos a partir de un conjunto básico de activos de una manera prescrita.

10 Qué es la IFPS? Arquitectura de dominio específico: es una arquitectura genérica que describe los miembros de una familia de productos de software, sus similitudes y diferencias actuales y proyectadas. Se pueden usar patrones arquitectónicos o estilos arquitectónicos para representar la(s) arquitectura(s) típica(s) de una FPS.

11 Un patrón de análisis de dominio específico El siguiente ejemplo muestra cómo se puede especificar un patrón de análisis de dominio (PAD). Actualmente no existe un esquema estándar para especificar (PADs). La fuente principal es el patrón Accountability de Fowler.

12 Personas y Relaciones (Nombre e Intencionalidad) Nombre: Personas y Relaciones Origen: "Accountability" de Fowler Intencionalidad: Diferenciar claramente entre las entidades Persona, Relación entre Personas, Tipo de Relación entre Personas y Clase de Personas visualizando los casos de uso, operaciones y atributos más comunes en el análisis de este tipo de entornos.

13 Personas y Relaciones (Contexto típico) Este patrón aplica en contextos en los cuales la empresa cliente requiere un manejo sofisticado de sus relaciones con proveedores, clientes, socios y otros. Es el caso por ejemplo de empresas distribuidoras que pueden requerir clasificar sus proveedores y clientes. El manejo de estas relaciones podrían implicar la representación de reglas de negocio para restringir las relaciones entre personas con base en las relaciones entre clases de personas.

14 Personas y Relaciones (Análisis de contexto) El analista ajustará los modelos del patrón en colaboración con usuarios, clientes y expertos en el dominio centrándose en la personalización de: La navegabilidad entre casos de uso. Los atributos de los documentos y paneles de control. Las operaciones de los documentos y paneles de control.

15 Personas y Relaciones (Análisis de contexto) El analista determinará si las características opcionales son requeridas: Se requiere representar relaciones entre clases de personas? Se requiere restringir las relaciones entre personas con base en las relaciones entre clases de personas?

16 Personas y Relaciones (Análisis de contexto) Para el análisis de variaciones más fuertes en el contexto de esta misma categoría de patrones, el analista considerará: La necesidad de un sistema de clasificación múltiple para las personas. El patrón propone que cada persona sólo pertenece a una clase, pero en algunos casos podría ser necesario que pertenezca a varias clases. La necesidad inmediata o tendencia evolutiva hacia personas que representan consorcios o grupos de personas, para lo cual se aplicará el patrón "Consorcios y relaciones". La necesidad inmediata o tendencia evolutiva de incorporar la venta o compra de artículos o servicios en relación con las personas, para lo cual se combinará la aplicación de este patrón con el patrón "Catálogo de Artículos y Servicios".

17 Personas y Relaciones (Problema o Fuerzas)

18 Personas y Relaciones (Solución: VCU)

19 Personas y Relaciones (Solución: OF)

20 Personas y Relaciones (Solución: VCU+OF)

21 Personas y Relaciones (Solución: Modelo del dominio)

22 Personas y Relaciones (Solución parcial: Modelo de Objetos de Análisis)

23 Personas y Relaciones (Consecuencias) Se logra identificar y diferenciar conceptos clave como "persona", "clase de persona", "relación entre personas" y "tipo de relación entre personas". Se logra representar una clasificación flexible de personas. Se logran representar todo tipo de relaciones entre personas y estas pueden evolucionar fácilmente.

24 Personas y Relaciones (Conexiones) Con patrones de análisis este patrón: Puede evolucionar hacia "Consorcios y relaciones". Se complementa con "Address definition" y "Contact mechanism definition" de Silverston. Se complementa con "Geographic locations" de Hay.

25 Qué son y para qué sirven los patrones de análisis? Por tanto, un patrón de análisis: Describe una categoría de problema típico de la etapa de análisis de una FPS (el para qué). Describe una categoría de solución para el problema caracterizado (el qué). Define para la contextualización del PAD (el cuándo y el cómo). Establece conexiones con otros patrones de análisis para variaciones o especializaciones del contexto de análisis (parte del cómo). Establece conexiones con patrones de diseño arquitectónico y de diseño detallado para su aplicación (parte del cómo).

26 Qué son y para qué sirven los patrones de análisis? En síntesis podemos afirmar que los PAD permiten: Sistematizar conocimiento específico de una FPS. Comunicar y distribuir conocimiento. Estandarizar el modelado. Seleccionar código a generar mediante la aplicación junto con frameworks orientados a un dominio específico.

27 Combinando patrones de análisis Persona id nombre propósito direcciones-e teléfonos Condición de Dirección fecha inicio fecha fin función 1..n * Localización Geográfica id nombre abreviatura 1 * Dirección id código postal linea_1 linea_2 1 1 Se aplican "Address definition" de Silverston et.al. y "Geographic locations" de Hay. 1..n Contacto id nombre código telefónico de área código telefónico de país número de teléfono dirección-e Condición de Contacto fecha inicio fecha fin función Se aplica "Contact Mechanism definition" de Silverston et.al.

28 Combinando patrones de análisis y patrones de diseño

29 Lenguajes de patrones Estilo arquitectónico de una FPS PAD PAD Patrónes de Diseño

30 Lenguaje de PAD Parafraseando a Alexander: Un lenguaje de patrones análisis orientado a un dominio de aplicación específico (LPAD) provee a cada ingeniero de software que lo usa el poder de crear una infinita variedad de productos de software únicos y nuevos, pertenecientes a una misma FPS (o SPL), de la misma forma en que su lenguaje ordinario le da el poder de crear una variedad infinita de oraciones

31 LPAD en las FPS En el contexto de FPS los LPAD pueden: Preservar Organizar Representar Distribuir Potenciar el conocimiento experto que adquieren y perfeccionan los desarrolladores de software (arquitectos, analistas y programadores) en dominios específicos (informática hospitalaria, informática jurídica, sistemas de información empresarial, etc.).

32 LPAD en las FPS Potenciar el conocimiento significa: Usarlo en la construcción rápida de productos perteneciente a una FPS. Usarlo en la incorporación plena de los clientes, usuarios o expertos en el dominio al proceso de desarrollo, a través de un lenguaje mutuamente inteligible con los desarrolladores.

33 Abstracción y agilidad The key to process maturity is making agility scale up A pattern language is a domain specific language (DSL) in incubation Jack Greenfield & Keith Short Software Factories

34 Estructura de un LP Según Alexander, la estructura de un LP es un digrafo de patrones cuyos arcos representan la relación se complementa con entre patrones. Es decir, red de patrones conectados por la relación se complementa con.

35 Organización y representación de un LPAD basada en una hiper-red

36 Organización y representación de un LPAD

37 Venta y compra de productos Intencionalidad: Los patrones de esta categoría generalizan artefactos del análisis que modelan requerimientos de información que tienen las organizaciones sobre sus productos y los procesos de venta y compra de dichos productos.

38 Venta y compra de productos Algunos de los requerimientos de información de los PAD son, por ejemplo: "1. Cómo se comparan en calidad y precio los productos de la organización con los de la competencia? 2. Qué nivel de existencias se requiere en cada localización para poder satisfacer las necesidades de los clientes? 3. Cuál es el precio, el costo y la ganancia de los productos ofrecidos? 4. Dónde pueden comprarse los mejores servicios y productos a los mejores precios?" (pág. 41 de [Silverston 96]).

39 Venta y compra de productos Terminología de los PAD: Producto: es un Producto Tangible o un Producto Intangible. Los productos intangibles se conocen típicamente como servicios. Proceso de venta: proceso mediante el cual la organización provee productos o servicios a sus clientes obteniendo a cambio alguna retribución económica o de otro tipo. Proceso de compra: proceso mediante el cual la organización se aprovisiona de bienes para cumplir con los procesos de venta a sus clientes.

40 Categoría Productos

41 Categoría Productos Intencionalidad: Los patrones de esta categoría generalizan artefactos del análisis que modelan requerimientos de información que tienen las organizaciones sobre sus productos, específicamente tipos y categorías de productos.

42 Categoría Productos Los problemas del análisis de este sub-dominio representados por esta categoría son, por ejemplo: Cómo organizar los artículos y servicios en tipos que representen sus atributos relevantes? Se requiere la definición de categorías de productos? Qué tan estables son estas categorías? Se venden artículos? Simples y compuestos? Se venden servicios? Se venden tanto artículos como servicios? En tal caso, qué relaciones relevantes se presentan?

43 Categoría Productos Terminología (primera parte): Producto: es un Producto Tangible o un Producto Intangible. Los productos intangibles se conocen típicamente como servicios. Tipo de artículo: representa un conjunto de artículos que poseen características similares, en particular un mismo número de modelo, o marca o identificador generado por los proveedores de la empresa.

44 Categoría Productos Terminología (segunda parte): Tipo de artículo simple: es un tipo de artículo que, desde la perspectiva de los procesos del negocio, se maneja como una unidad indivisible. Tipo de artículo compuesto: es un tipo de artículo que, desde la perspectiva de los procesos del negocio, se maneja como una composición de otros tipos de artículo que también aparecen dentro de los catálogos de la empresa o simplemente son relevantes para los procesos de producción.

45 Categoría Productos Terminología (tercera parte): Tipo de servicio: es un tipo de actividad que la empresa vende a sus clientes y por cuya realización obtiene algún tipo de beneficio que constituye una meta central en el negocio de la empresa. Categoría de tipos de producto: es una categoría de tipos de artículos o de tipos de servicio que es relevante para los procesos del negocio y que puede tener una existencia temporal o indefinida. En general, se supone que un tipo de producto (artículo o servicio) solo puede pertenecer a una categoría, sin embargo en ciertos contextos organizacionales este supuesto no será válido. Es tarea del analista determinar la aplicabilidad de este supuesto fundamental.

46 PD de Productos

47 Resumen Importancia de patrones de análisis: En general para sistematizar el conocimiento de dominios de aplicación. En FPS para sistematizar el conocimiento de aspectos variables y opcionales de los productos. Existen dos grandes categorías de patrones: orientados a dominio e independientes de dominio.

48 Resumen Se mostró cómo pueden complementarse patrones de análisis con patrones de diseño. Se mostró cómo se pueden representar y organizar lenguajes de patrones de análisis en un contexto de FPS.

49 Síntesis Metáfora: los patrones de software son para las FPS como el ADN para las especies de animales.

50 Bibliografía Software Product Lines. Clements & Northrop, Designing Software Product Lines with UML, Hassan Gomaa, The Data Model Resource Book: A library of logical data models and data warehouse designs. Silverston et.al., 1996.

51 Bibliografía Analysis patterns: Reusable Object Models. Martin Fowler, Object Models: Strategies, Patterns and Applications. Peter Coad et.al., Data Model Patterns: Conventions of thought. Hay, Designing Software Product Lines with UML, Hassan Gomaa, 2004.