Nomenclatura GxSoft & vs GIK

Curso Básico de Introducción a GeneXus Nomenclatura

http://www.GxSoft.com. GxSoft ARGENTINA.

1

Nicolás: El escrito que sigue nunca fue terminado, no obstante nosotros, en GxSoft, usamos un conjunto de reglas mucho mas extenso que abarcó a los subtipos, tablas, procedures, etc. . También esta nomenclatura la usamos en otros ámbitos e hicimos un “codificador” de nombres que se usaba para usuarios y también se usó para localidades (en un sistema de transporte que usaba 4 letras para sus nombres) El fuerte de esta regla es que nosotros “calculamos” el nombre de los atributos y objetos, por ejemplo, si tenemos un programa corriendo, en el FORM de la transacción “vemos” las descripciones o títulos de los atributos en la pantalla y con certeza sabemos cuál es el nombre exacto del atributo que contiene la información. Elegimos el juego entre 4 y 3 para que llegar a 10 fácilmente, esto dependerá de los gustos y podría ser configurado, más ahora que piensan levantar el límite de 10 caracteres para los nombres de los objetos GeneXus, no obstante, la cantidad de caracteres debe ser fijo y previamente conocido por el equipo que trabaja sobre una KB. La idea sería implementarlo como un asistente de escritura en tiempo de diseño de la KB, te puedo mandar un programa que simule esto que te estoy diciendo, también debería existir un diccionario de sinónimos para asistir en run-time al diseñador, luego podría existir un re-nomenclador a partir de una KB existente (usando GxPublic no habría problemas). Por último y lo más delicado: el orden de toma de datos en la creación de atributos debería ser al revés que ahora 1ro descripción del atributo y luego el nombre. Si te parece, te puedo mandar más KBs nuestras que usan esta nomenclatura. La que te mando esta escrita por 3 personas y la hicimos usando esta nomenclatura. La otro que acá no está es que la nomenclatura alcanza o debería alcanzar TODOS los objetos GeneXus, desde un atributo, pasando por los dominios y llegando a folder. Léelo y contéstame. Mientras me pondré a trabajar en el programa que hace de asistente de la nomenclatura... . Nota: Al Final hay un ANEXO que compara GIK .vs. Nomenclatura GxSoft



2

Nomenclatura GxSoft (adaptada a GeneXustm )

1. Introducción. Antes de comenzar con la “escritura” de un sistema debemos acordar los nombres de las entidades de la realidad, a partir de los cuales se deducirá la denominación. La Nomenclatura presente esta pensada para sistemas de gran porte y para maximizar las posibilidades de trabajo en equipo que brinda GeneXus.

1.1. DEDUCIR UN NOMBRE

Cuando nos enfrentamos a desarrollos de gran porte, no es fácil conocer o memorizar todos los nombres de los elementos de un sistema. Cuando decimos elementos nos referimos a los Objetos GeneXus a las tablas a las Variables, Funciones, etc.. Puede uno recordar los nombres que ha ido usando a través del desarrollo de una aplicación, pero por cuánto tiempo?. Es probable entonces que en el corto plazo de una aplicación y mientras estemos “sobre” ... recordemos gran cantidad de nombres y si no fuera así quizá consultando un diccionario de datos, si lo fuimos construyendo, podamos encontrar la denominación de un elemento dado. Pero qué pasará cuando trabajemos en equipo?, cómo podrá cada integrante del equipo entender lo que otro integrante ha escrito?.

1.2. ENTENDER LOS NOMBRES:

Para solucionar este problema de “entender” lo que cada uno escribe, o tener que “recordar” los nombres de los objetos que se irán usando a través de la aplicación hay que “acordar” una nomenclatura en común para cada uno de los elementos que se deban denominar en un desarrollo. La nomenclatura elegida debe indicarnos de que se trata sino además debe ser también “deducible” (que dado un nombre de la “realidad” exista una regla de denominación tal que el nombre del elemento sea único) es decir, partiendo de la denominación de un elemento en la “vida real” se llegue a una única denominación. Estos objetivos no son fáciles de conseguir, pero tampoco son poco importantes como para que no hagamos el esfuerzo necesario para alcanzarlo.

1.3. MINIMIZAR LA “DISYUNCIÓN”

A diferencia de otras nomenclaturas, la propuesta es más rígida que otras existentes, pero obtenemos como ventaja su “deducibilidad”. Con el objetivo de que el mismo objeto de la realidad se denomine igual en cada “cita” interna en la Knowledge Base.

1.4. MINIMIZAR LA “COLISIÓN”

Un problema que se puede dar es que la raíz de dos objetos de la realidad sea la misma, en este caso se puede prevenir Nombrando los Objetos de la realidad que participaran en el sistema antes de comenzar a escribir la KB. El largo total de un nombre es de 10 (diez) caracteres de manera que se respetará este límite. La nomenclatura para la mayor parte de los elementos es de 4 letras a las cuales se le agregarán Sufijos y/o prefijos de 3 letras llegando a 10 caracteres cuando se le agreguen ambos ( un prefijo y un sufijo).



3

2. Reglas de Nomenclatura. Nota:Las preposiciones de, del se Ignoran!.

2.1. Regla General 1. Los Nombres se truncan a 4 letras. Todo nombre tiene cuatro caracteres, el mismo deriva de la denominación en la realidad (Cliente, Factura, Artículos, Calles). Este componente de 4 Letras se denominará de aquí en adelante NUCLEO de la nomenclatura.

2.1.1. Si es de una Palabra. La palabra se corta sin abreviar a sus cuatro primeros caracteres.

2.1.2. Si es de dos Palabras. El nombre resulta de la primera letra de la primera palabra concatenada a las tres primeras letras de la segunda palabra.

2.1.3. Si es de tres Palabras. El nombre resultará de la primera letra de la primera palabra concatenada a la primera letra de la segunda palabra y las dos primeras letras de la tercera palabra.

2.1.4. Si es de cuatro Palabras. El nombre resultará de concatenar la primera letra de cada una de las cuatro palabras.

2.1.5. Si hay Colisión de nombres. Cuando de dos objetos de la realidad a nomenclar y aplicando la REGLA 1 se produzca el mismo resultado, se buscarán sinónimos del elemento en la vida real (p.e. Productos = Artículos, Materiales, Parte, Repuesto, etc.) y si de todas maneras sigue ocurriendo la colisión se le eliminarán vocales, en el nombre menos importante y si se volviera a colisionar se usará la primera letra de cada silaba. ver anexo 1.



4

2.2. Regla General 2. Se derivarán “Nombres” de los de 4 Letras tomando las 3 Primeras para especificar la

Pertenencia a o Función del elemento a nomenclar. Esta regla se aplica en combinaciones para denominar los elementos del sistema ver ejemplos en la Regla General 3 (denominación de Atributos) y Regla General 4 (especificar función y pertenecia).

2.3. Regla General 3. Nomenclatura de Atributos. La denominación de Atributos necesita una regla específica que usa las Reglas Generales 1 y 2. El Nombre de los atributos estará conformado por dos partes claramente diferenciables el “Nucleo” o nombre del Atributo propiamente dicho y un prefijo de tres letras que derivará de la transacción a la que pertenezca (Regla General 2). Ejemplos: Transacción Atributo Nomenlatura Cliente (Clie) Nombre (Nomb) CliNomb Cliente (Clie) Codigo (Codi) CliCodi Insumo (Insu) Cantidad (Cant) InsCant Insumo (Insu) Precio (Prec) InsPrec

Elemento de la Realidad Regla 1 Clientes Clie Localidades Loca Paises Pais Proveedores Prov Provincias (“colisión”)->> Prvn Fecha de Nacimiento FNac Fecha de Emisión FEmi Elementos de la Realidad ERea Numero de Cheque NChe Fecha Probable de Parto FPPa Forma de Pago FPag Certificado Libre Deuda CLDe Estado Civil ECiv Tipo de Documento TDoc Codigo Unico de Identificación Laboral

CUIL



5

2.4. Regla General 4. Cuando haya que especificar Pertenencia o Función los nombres de los elementos en el sistema se darán por combinación de las Reglas Generales 1 y 2 . Nombres de Atributos, Subtipos, Indices .

Cuando un Objeto es parte de otro existente, se denominará usando la Regla General 1, pero se le agregará al nombre un prefijo o sufijo (Regla General 2) correspondientes a las 3 primeras letras del Objeto al cual pertenecen o 3 letras especificando la Función que cumplirá el elemento que se está denominando..

2.4.1. Pertenencia. Prefijo . Al nombre de los atributos que pertenecen a una transacción se les agrega un prefijo de tres letras iguales a la 3 primeras letras de la transacción.

2.4.2. Pertenencia o Función. Atributo-SubType & Grupo Cuando en un sistema surge la necesidad del uso de SubTipos la denominación del mismo será igual al SuperTipo (3+4) + un sufijo de tres letras. Se distinguen dos casos 1) USO: SubTipo x Aplicación de un atributo en una misma tabla: el sufijo aclarará el uso que se le da al atributo-SubTipo o bien a la transacción a la cual pertenece el atributo-SubTipo. 2)TRN: SubTipo para diferenciar la pertenecia a una transacción dada: el sufijo será igual a las tres primeras letras de la transacción a la cual pertenece el atributo-SubTipo.



6

Ejemplos: Caso de Aplicación Uso /

Transacción Atributo Nomenclatura

(1) Guarda Localidad Origen Origen (uso) LocCodi LocNomb LocCPos

LocCodiOri LocNombOri LocCPosOri

(1) Guarda Localidad Destino Destino (uso) LocCodi LocNomb LocCPos

LocCodiDes LocNombDes LocCPosDes

(1) Transferencia Inter Depósito - Guarda Depósito de Salida

Salida (uso) DepCodi DepNomb

DepCodiSal DepNombSal

(1) Transferencia Inter Depósito - Guarda Depósito de Entrada

Entrada (uso) DepCodi DepNomb

DepCodiEnt DepNombSal

(2) Para

2.5.

2.5.1.

2.5.2. Ejemplos de Nomenclatura como resultado de aplicar la Regla General 2.

Elemento de la Realidad Regla 1 Nombre del Cliente CliNomb Codigo del Cliente CliCodi Codigo de Localidades LocCodi Nombre de la Localidad LocNomb Codigo Postal de Localidad LocCPos Fecha de Nacimiento de Asistente

AsiFNac

Fecha de Emisión de Factura FacFEmi Nombre del Elemento de la Realidad

EReNomb

Numero de Cheque del Valor ValNChe Fecha Probable de Parto de Tabla Embarazos

EmbFPPa

Forma de Pago de Factura FacFPag Certificado Libre Deuda del Automotor

AutCLDe



7

2.6. Regla Tipográfica. El usar una nomenclatura para la denominación de todos los objetos tiene un beneficio secundario que es la claridad de la lectura del sistema. Pero no es suficiente, para que este beneficio se logre podemos ayudar con la TipoGrafía que se use. Se propone que, dado un nombre o combinación de ellos se Tipee la primera letra de cada palabra usada para obtener el nombre definitivo en mayúscula y las letras siguientes en minúscula, en los ejemplos arriba citados se ha usado esta TipoGrafía.

2.6.1. Si es de una Palabra. La palabra se corta sin abreviar a sus cuatro primeros caracteres. Si un nombre de cuatro letras esta formado por 1 palabra estará compuesto por 1 Mayúscula y 3 minúsculas Ejemplos: Clie (Cliente) / Loca (Localidad) /Prov (Proveedor) / Fech(Fecha) /Arti (Articulo)

2.6.2. Si es de dos Palabras. El nombre resulta de la primera letra de la primera palabra concatenada a las tres primeras letras de la segunda palabra. Su nombre de cuatro letras esta formado por 2 palabras tendrá 2 Mayúsculas y 2 minúsculas Ejemplos: FNac(Fecha de Nacimiento) /CPos(Código Postal) /PPar(Punto de Partida)

2.6.3. Si es de tres Palabras. El nombre resultará de la primera letra de la primera palabra concatenada a la primera letra de la segunda palabra y las dos primeras letras de la tercera palabra. Si un nombre de cuatro letras esta formado por 3 palabras tendrá 3 Mayúsculas y 1 minúscula Ejemplos: FPPa(Fecha Probable de Parto)

2.6.4. Si es de cuatro Palabras Si un nombre de cuatro letras esta formado por 4 palabra s estará compuesto por 4 Mayúsculas que serán las cuatro iniciales de la palabras.

2.7. Nomenclatura de Objetos GeneXus.. Los objetos GeneXus se denominarán usando la Regla General 1. Pero como al mismo objeto de la Realidad se le pueden construir mas de un objeto GeneXus del mismo tipo hay que hacer algunas consideraciones.

2.7.1. TRANSACCIONES. En general hay una sola transacción que representa a un objeto de la realidad, entonces se usa la nomenclatura de 4 letras. Si hubiera mas de una transacción para un objeto de la



8

realidad se le agrega un sufijo de 3 letras que definirán el objetivo de dicha variante de la transacción. Puede ocurrir que una transacción sea suficientemente compleja, con gran cantidad de atributos o con muchos SubFiles, y por ello debamos particionarla en distintas transacciones para acceder a distintas “áreas” de la transacción original. Estas Transacciones “hijas” se diferenciarán con un sufijo que aclare su contenido. También se puede dar el caso que a una transacción se le diseñen diferentes formularios según las vistas de usuarios que se necesiten, en este caso en el sufijo se aclarará la función de la “transacción hija”.

2.7.2. WORK PANELS. El caso de los WKPs es diferente que el de las transacciones ya que, por lo general, hay varios WKPs por cada objeto de la realidad. Por ejemplo para la entidad LOCALIDAD tendremos probablemente una transacción denominada



9

GIK & GxSoft Nomenclature.

Las reglas de Nomenclatura que se verán aplicar acá son las que te mandé en el escrito anterior. Que es un primer borrador e inconcluso sobre la nomenclatura, que nosotros fuimos aplicando y ajustando a través de los años ( desde 1991).

1) GIK , a pesar de busca que un elemento de la realidad sea llamado en forma standard (textual): “...those attributes that representan the same thing will be equally named..” no dice como va conseguir esto, no dice cómo...: Por ejemplo NAME CLIENT,

Object/Element 2.7.3. “correct” GIK

GxSoft 3x4

TRN: Client 2.7.4. No dice, Puede ser

Client, Cli, Clie, Clnt, CLT…

2.7.5. Clie

Attribute: Name Client 2.7.6. 1a:CliNa

2a:CliNm 3a:CliNam 4a:CliNme 1b:ClieNa 2b:ClieNm 3b:ClinNme etc,etc...

2.7.7. CliName

Attribute: Code Client 2.7.8. 1a:CliId

2a:CliIde 3a:CliIdn 4a:CliIdt 1b:CliCode 2b:CliCod 3b:CliCdg 3b:CliCde 1c:ClieCod etc,etc

2.7.9. CliCode

Probando con Qualifier Object: Client Category: Name Qualifier: Branch

2.7.10. 1a:CliBraNam 2a:CliBraNme 1b:CliBrNam 1c:ClieBraNam etc,etc,etc!!!!

2.7.11. CliNameBra



10

Structure Attribute Name=

2.7.12. Object+Category+Qual.

2.7.13. or Object+Qualifier+Categ.

2.7.14. ONLY

2.7.14.1.Objejt(3)+

Category(4) Qualifier(3)

Structure Strict Order? 2.7.15. No 2.7.16. Yes Structure Strict Large? 2.7.17. No 2.7.18. Yes Structure Strict Calculus?

2.7.19. No 2.7.20. Yes

Tien una funcion univoca?

2.7.21. No 2.7.22. Yes

Nicolás: La nomenclatura que propongo y usamos en GxSoft, hace hincapie en que, lamentablemente (je je), que, dado un nombre de la realidad no exista libertad para elegir diferentes resultados! Además, te cuento que en el ejemplo que dan el viejo tratado de methodology donde explican el GIK cometen uno o varios errores al aplicar la nomenclatura. GeneXus METHODOLOGY BOOK: Page 15. Object: Cli Category: Date Qualifier: Maturity Example erroneo: InvDatMat cuando debería ser InvMatDat, porque el libro dice [Object 3 o 4]+[Qualifiers 3]+[Category 2 o 3]. O bien el error esta en la pagina 14 al definirlo, y en todos los atributos del BRANCH o este ultimo mas otros ejemplos estan mal..... Gabriel Medina GxSoft ARGENTINA [email protected] ICQ#: 21496075 Odigo#:817519 FireTalk#:1225932 (CONTINUARA!)

Nomenclatura GxSoft & vs GIK

Documents

Transcript of Nomenclatura GxSoft & vs GIK