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).
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.
| 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 |
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 |
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.
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 |
|
|
|
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 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.
Aconsejamos mirar la comparacion con la Nomenclatura GIK (GeneXus Incremental KnowledgeBase)
(versión incompleta...) por la version completa comunicarse con Gabriel Medina (gxsoft@gmail.com)
