GUA DE ELABORACIN DE MODELOS CONCEPTUALES

Oficina de Informtica

Departamento Nacional de Planeacin

Bogot D.C., Colombia, 2013

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 2 de 10 VERSIN: 0

TABLA DE CONTENIDO

1 Introduccin ................................................................................................................... 3
2 OBJETIVO .................................................................................................................... 4
3 ALCANCE ..................................................................................................................... 4
4 CONCEPTOS BSICOS ................................................................................................ 4
A. Propsito ...................................................................................................................... 4
B. Alcance y aplicacin ...................................................................................................... 4
C. Requisitos previos ......................................................................................................... 4
4.1 Representacin ............................................................................................................. 5
A. Modelos y diagramas .................................................................................................... 5
B. Notacin y lenguaje ....................................................................................................... 5
C. Herramienta y ubicacin ................................................................................................ 5
4.2 Pasos para construir el modelo....................................................................................... 5
A. Definir y delimitar el alcance del dominio ......................................................................... 6
B. Elaborar un glosario ...................................................................................................... 6
C. Identificar Conceptos dentro del glosario ......................................................................... 6
D. Definir relaciones entre conceptos .................................................................................. 6
Relaciones binarias ........................................................................................................... 6
4.3 Conceptos universales, instancias individuales ............................................................... 6
4.4 Relaciones jerrquicas o taxonmicas ............................................................................ 7
4.4.1 Tipo especializacin - generalizacin ..................................................................... 7
4.4.2 Tipo todo - parte .................................................................................................. 7
4.4.3 Relaciones no jerrquicas ..................................................................................... 8
4.4.4 Elaborar el modelo como diagrama(s) de clases ..................................................... 8
Bibliografa. ............................................................................................................................... 9

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 3 de 10 VERSIN: 0

Gua para la elaboracin de modelos conceptuales

The belief that complex systems require armies of designers and programmers is wrong. A system that is not
understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not
be built.

Communication problems grow as the size of the design team grows. Whether they are obvious or not, when
communication problems predominate, the team and the project are both in deep trouble.
Niklaus Wirth. A Plea for Lean Software. IEEE Computer Magazine. 1995.

1 Introduccin
Niklaus Wirth, uno de los grandes pioneros y cientficos de la computacin, ganador del premio Turing y autor,
entre otras cosas, del lenguaje de programacin Pascal, escriba en 1995 un notable ensayo sobre como
construir software de calidad, su artculo se titulaba Una splica por software liviano (A Plea for Lean
Software) (Wirth, febrero 1995), si bien el documento se centraba en el buen uso de la orientacin a objetos,
haca una crtica a la complejidad innecesaria en el diseo de software y aconsejaba centrarse en lo esencial,
al final del documento conclua nueve lecciones aprendidas en las actividades de disear un nuevo software,
hacemos nfasis en la 5 y la 6 que respectivamente dicen:
La creencia que los sistemas complejos requieren ejrcitos de diseadores y de programadores es
errada. Un sistema que no es comprendido en su totalidad, o por lo menos a un grado de detalle
suficiente por parte de cada individuo, probablemente no ser construido.
Los problemas de comunicacin crecen a medida que el tamao del equipo crece. Si predominan
los problemas de comunicacin, as sean obvios, el equipo y el proyecto estarn en problemas.

La comprensin y la comunicacin estn estrechamente relacionadas: no podramos comunicar efectivamente

si el entendimiento de la conceptualizacin que se comparte no es aceptado unvocamente por cada uno de
los involucrados; un buen entendimiento pasa por discernir cul de esa informacin formal y explcitamente
comunicada representa conocimiento vlido y relevante?.

Pareciera que las lecciones aprendidas expuestas en el ensayo de Wirth tuvieran que ver menos con la
ingeniera de software y ms con la gestin y representacin del conocimiento, pero comprensin y
comunicacin estn naturalmente sugeridas en la definicin formal de ontologa como mecanismo formal para
la representacin del conocimiento y como componente clave en la gestin del mismo an dentro de la
ingeniera del software. De acuerdo con Tom Gruber (Ling Liu, 2009) En el contexto de la informtica, una
ontologa define un conjunto de primitivas de representacin con las cuales se modela un dominio de
conocimiento o discurso. Las primitivas de representacin son tpicamente clases (o conjuntos), atributos (o
propiedades) y asociaciones (o relaciones entre sus miembros).

No se debe al azar esta coincidencia; una ontologa define y representa los trminos y conceptos relevantes a
un tpico o rea de inters particular (dominio) y un sistema de informacin es la representacin (parcial o
total) de un sistema de gestin del mundo real (dominio particular).
Si bien no queremos ni debemos desde la ingeniera del software hacernos con la responsabilidad y la
carga de manejar el formalismo y el rigor metodolgico de una ontologa si requerimos organizar y representar
los conceptos y sus relaciones dentro del mbito o contexto particular donde ocurre nuestro sistema de
informacin (o de gestin, propiamente dicho) para comunicarlo y compartirlo con el grupo.
Pero la comprensin y la comunicacin de una realidad si justifica la elaboracin de una versin ligera de
ontologa, variacin que efectivamente existe y se denomina modelo conceptual (o de dominio). Si para
alguien no fuera suficiente esta justificacin, se podran citar numerosos estudios y recomendaciones que
3

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 4 de 10 VERSIN: 0

demuestran su valor para agregar calidad, en trminos cuantitativos y cualitativos, al proceso de ingeniera de
software. Cuantitativo porque se ha demostrado que un buen modelado conceptual ayuda a reducir el
esfuerzo y el tiempo en elaborar los modelos posteriores de anlisis (lgicos) y de diseo (fsicos).
Cualitativos porque un buen modelo conceptual impacta en mejores modelos lgicos y fsicos que producen
una implementacin en cdigo que al final redunda en una sustancial disminucin de defectos o fallas en el
software.

2 OBJETIVO

El presente documento provee un instructivo paso a paso para la elaboracin de un modelo conceptual
como artefacto y entregable dentro de los lineamientos del esquema de desarrollo de software y configura
tambin una normativa que demanda aprobacin o consentimiento por parte de la Oficina de Informtica.
Comienza con las definiciones y conceptos relacionados contina con los formalismos de su representacin
y termina con la descripcin de los pasos requeridos para obtenerlo.

3 ALCANCE

Esta gua debe ser aplicada por los integrantes de un proyecto de desarrollo o mantenimiento de software que
conozca o provea el contexto y la problemtica del negocio cuya solucin o producto informtico pretende
lograr el proyecto.

4 CONCEPTOS BSICOS

A. Propsito
Un modelo conceptual - tambin conocido como modelo de dominio - tiene como propsito
fundamental organizar y representar, de manera semi formal y unvoca, el conocimiento de un rea o
campo especifico asociado a un sistema de gestin o de informacin. Est orientado a describir
semntica y aseveraciones sobre la informacin del dominio particular que representa.
La elaboracin de dicho modelo es abstracta e independiente de consideraciones de diseo o de
tecnologa, es decir se identifican las cosas fundamentales sin dar demasiada importancia a ejemplos o
instancias particulares y sin dejarse influenciar por la eventual participacin de estos conceptos en
elementos o componentes de software o de una solucin de informtica.

B. Alcance y aplicacin
El modelo conceptual es un entregable inicial dentro del proceso de construccin de software, esto
quiere decir que est antes del tiempo y del espacio de las disciplinas de anlisis y diseo, podramos
afirmar que est a caballo entre el modelado de negocio y los requerimientos. Por esta razn para crear
un modelo conceptual es suficiente con una buena definicin y explicacin de conceptos o entidades de
negocio y de sus relaciones. Pero su vigencia y alcance estar presente a los largo de todas las fases
del proyecto.
Dado que su utilidad primordial es dar contexto y comprensin a los requerimientos y compartir ese
entendimiento entre los miembros del equipo, un modelo conceptual aplica tanto para proyectos de
desarrollo de software transaccionales (OLTP) como de inteligencia de negocios (OLAP).

C. Requisitos previos
Documento de visin, modelos de negocio, casos de uso de negocio, deseable que existiera una
especificacin de casos de uso del sistema y una versin del glosario de proyecto.

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 5 de 10 VERSIN: 0

4.1 Representacin

A. Modelos y diagramas
An persiste entre nosotros cierta confusin entre modelo y diagrama y aunque en ocasiones usamos
indistintamente ambos trminos con idntico significado y sin problema, es imprescindible dejar en
claro su distincin.
Si bien los dos conceptos se utilizan como mecanismos de representacin o demostracin, un modelo
tiene un uso mas general y mas abstracto que un diagrama pero un significado ms preciso en
cuanto es un: Esquema terico, generalmente en forma matemtica, de un sistema o de una
realidad compleja para lograr la: Representacin en pequeo de alguna cosa., segn las
acepciones 2 y 3 que el Diccionario de la Lengua de la Real Academia Espaola otorga a este
sustantivo (Espaola). El mismo diccionario define diagrama como: Dibujo en el que se muestran
las relaciones entre las diferentes partes de un conjunto o sistema..
La distincin no admite controversia; el diagrama es un elemento grfico (dibujo) que hace parte de un
modelo. Con frecuencia un modelo contiene otros elementos diferentes a los componentes grficos
incluidos en los diagramas. Solamente cuando un modelo es susceptible de representarse
suficientemente con un diagrama se pueden usan indistintamente ambos trminos.

B. Notacin y lenguaje
Un modelo conceptual se representa en uno o ms diagramas de clases con un alto nivel de
abstraccin. Un diagrama de clases es un grafo acclico dirigido (mapa) de los conceptos y sus
relaciones. Este, o estos diagramas se elaboran en notacin UML y hace uso fundamental de los
elementos bsicos gramaticales, ortogrficos y semnticos de la versin 2.4.1 de este lenguaje para
este tipo de diagrama, esto es: clases, atributos y relaciones.
La notacin no slo determina que el modelo se muestre en una notacin icnica o grfica
(diagramas), tambin exige que se documente cada elemento identificado y/o mostrado en el
diagrama, por lo que requiere un repositorio para incluir los elementos textuales que conforman dicha
documentacin.

C. Herramienta y ubicacin
El diagrama se elaborar utilizando la herramienta Enterprise Architect y se ubicar en el repositorio
que para el proyecto se haya creado en una base de datos SQL Server dentro de los servidores de
DNP. Las referencias a este diagrama se harn teniendo en cuenta estas consideraciones de
herramienta y ubicacin.

4.2 Pasos para construir el modelo.

No hay una nica forma de modelar un dominio - siempre hay alternativas viables y correctas -. La mejor
solucin es aquella que logra el objetivo de representar y de hacer explicito el conocimiento y el
entendimiento de ese dominio. Existen diversos enfoques metodolgicos tomados desde la gestin del
conocimiento que implican gran formalismo y mayor rigor metdico, en esta gua proponemos una
metodologa con pocos pasos, algunos de los cuales ya se han recorrido con otras actividades del esquema
de desarrollo, estos pasos son:
1. Definir y delimitar el alcance del dominio.
2. Elaborar un glosario
3. Identificar conceptos dentro del glosario.
4. Definir relaciones entre conceptos
a. Relaciones jerrquicas o taxonmicas
i. Tipo Especializacin generalizacin
ii. Tipo todo-parte, agregaciones y composiciones.
b. Relaciones no jerrquicas entre pares (asociaciones)
5. Elaborar los diagramas de clases utilizando los conceptos y sus relaciones identificadas

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 6 de 10 VERSIN: 0

A. Definir y delimitar el alcance del dominio

La primera tarea es definir y acotar el dominio o campo de nuestro modelo. Esta actividad ya est
trabajada en el documento de visin, puntualmente en la definicin del alcance funcional y
organizacional que le hemos dado al proyecto. As que nuestro paso consiste en verificar que existe esta
seccin dentro del documento de visin.

B. Elaborar un glosario
Un modelo conceptual se orienta ya lo dijimos - a identificar, definir y representar trminos y
conceptos relevantes al tpico o rea determinado en el paso anterior con el propsito de comunicarlo y
compartirlo dentro de un colectivo para de este modo lograr univocidad consensuada. Esto nos obliga a
ocuparnos de los problemas que el lenguaje plantea como medio de relacin social, en consecuencia
conviene recordar lo que se plantea desde la lingstica respecto a los trminos: son unidades
usadas en el seno de una comunidad de especialistas para designar los objetos de una realidad ya
existente (Perez, 2006) .
El glosario del dominio del proyecto o glosario del proyecto es el primer insumo en esta identificacin
de conceptos, constituye un documento formal cuya estructura y contenido ha sido definido dentro de los
lineamientos y cuenta con su propia gua de elaboracin. (ver Gua de elaboracin del Glosario de
Trminos en la rebeca) (DNP, 2010)

C. Identificar Conceptos dentro del glosario

Es altamente probable que ya exista una versin del glosario para el proyecto, puesto que usualmente
se elabora paralelamente al documento de visin. Si ya existe se debe examinar para extraer los
principales trminos identificados y definidos all que hacen referencia a sustantivos (o frases
sustantivas), esto es, que nombran entidades del mundo real que tienen existencia discreta e
identificable y que son susceptibles de expresarse y comprenderse a travs de atributos y caractersticas
diferenciales. Estos conceptos tambin tienen el carcter de universalidad, esto es, que no determinan
instancias singulares (o individuales) del concepto.
Si el glosario an no existe se debe comenzar a elaborar con las consideraciones del numeral anterior
y con el propsito de identificar entidades como conceptos universales, pues este es un paso
imprescindible en obtener un modelo de dominio.

D. Definir relaciones entre conceptos

Relaciones binarias
Debemos recordar o reiterar que el nivel de abstraccin de nuestro modelo es de carcter
conceptual, pero no obstante representa un sistema de gestin de la vida real y en este entorno es
inusual y poco probable encontrar trminos o conceptos aislados, por el contrario la mayor parte
interactan o se estructuran de diversas formas. La elaboracin del modelo de dominio hace obligatorio
explorar y descubrir esas relaciones.
El diagrama conceptual se orienta a describir esencialmente las relaciones binarias (entre dos
conceptos), en una definicin simple una relacin es una conexin con contenido semntico - es decir,
significativa e interesante entre entidades dentro del problema de dominio, estas conexiones pueden
involucrar tanto las propiedades (atributos) como las asociaciones de interaccin, en cualquier caso las
relaciones dentro de un modelo de dominio deben, adems, considerarse desde el punto de vista
estructural o esttico.

4.3 Conceptos universales, instancias individuales

El trmino Ministerio De Educacin lo utilizamos con un sentido nico para referirnos a una entidad
concreta siempre y cuando hayamos delimitado el alcance y el dominio de nuestro modelo conceptual (por
ejemplo, el estado Colombiano) en cuyo caso podemos describirlo en trminos de propiedades o atributos
(ubicacin, personas de contacto, persona a cargo de la direccin general, presupuesto de gastos asignados
para un ao, etc), de lo contrario, sin un dominio delimitado, es una entidad o concepto abstracto (ente u
6

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 7 de 10 VERSIN: 0

organismo oficial y pblico encargado de tratar los asuntos administrativos relacionadas con la educacin)
que puede aplicarse de manera comn a otros conceptos o entidades: Ministerio de Educacin de Chile,
Ministerio de Educacin de Per, Ministerio de Educacin de Bolivia, Ministerio de Educacin de
Colombia, etc.

La interpretacin del trmino Ministerio De Educacin sin un dominio especfico se denomina universal
porque lo podemos asociar a un sustantivo (o frase sustantiva) comn o genrica que agrupa una pluralidad
de objetos que conocen por sus caractersticas comunes, sin expresar rasgos distintivos, es decir hace
referencia a una clase de objetos. La lista de trminos que particulariza a cada elemento frente a los dems
de una misma clase o especie se llaman individuales porque distinguen instancias propias, en el caso del
ejemplo, es un Ministerio De Educacin acotado, en el nombre a un pas particular, incluso pueden haber
otras caractersticas o atributos para remarcar esa diferenciacin: Ministerio de Educacin y Cultura de
Uruguay, Ministerio de Educacin de la Nacin Argentina.

La diferencia entre universal e individual (o clase e instancia) es intuitivamente comprendida y no requiere

mayor explicacin, la dificultad e importancia de la correcta interpretacin de un concepto en una de estas
categoras es fundamental en un modelo de dominio y depende precisamente de este alcance.
Las relaciones pueden ser homogneas en el sentido de la categora de elementos que conecta, esto es
universales con universales, individuales con individuales o pueden ser heterogneas.

Un tipo de relacin heterognea es la clasificacin, que se da entre universales e individuos. La sola

definicin de una entidad universal declara tcitamente una relacin con sus individuos particulares que se
denomina instanciacin, esta correspondencia entre instancias especificas con su entidad universal se
conoce como del tipo es un, por ejemplo, el Departamento Nacional de Planeacin es una Entidad
Pblica, aqu, Entidad Pblica es el universal y Departamento nacional de Planeacin es el individual
Esta asociacin entre conceptos configura la forma ms sencilla, comn e implcita de relacin en un modelo
de dominio, tan implcita que no es necesario explicitarse dentro de un diagrama conceptual.

4.4 Relaciones jerrquicas o taxonmicas

4.4.1 Tipo especializacin - generalizacin

Es la relacin jerrquica en la que se identifica a los conceptos por su pertenencia a una categora, en la que
un concepto genrico se considera superordinado de otros conceptos ms especficos. Los conceptos
subordinados comparten las caractersticas del concepto genrico pero, adems, poseen algunas
peculiaridades propias que los diferencian y hacen ms especficos. Se establece, por tanto, una relacin que
va en dos sentidos diferentes: vertical, es decir, la que se establece entre un concepto especfico
(subordinado) y su genrico (superordinado) y horizontal, la que sostienen varios conceptos especficos que
poseen el mismo genrico y que se diferencian entre s por poseer alguna caracterstica distintiva (conceptos
coordinados).
Son las relaciones del tipo clase/subclase , tipo/subtipo o padre/hijo . La generalizacin, como relacin
binaria, implica recprocamente la especializacin; en una relacin de especializacin/generalizacin los
objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). Las
jerarquas creadas con este tipo de relacin permiten manejar la complejidad, ordenando los objetos dentro
de un rbol de abstraccin creciente (generalizacin) o decreciente (especializacin), Estas estructuras son
utilizadas convenientemente para implementar clasificaciones, particularmente clasificaciones taxonmicas.

4.4.2 Tipo todo - parte

Se refiere a la relacin que existe entre conceptos que estn formados por ms de una parte y dichas partes
constituyentes. En lingstica se denomina meronimia a este tipo de relaciones semnticas no-simtricas
entre los significados de dos palabras dentro del mismo campo semntico. Se denomina mernimo a la
palabra cuyo significado constituye una parte del significado total de otra palabra, a la cual se denomina

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 8 de 10 VERSIN: 0

holnimo, por ejemplo, hoja es un mernimo de libro y libro es mernimo de biblioteca pero a su vez:
biblioteca es holnimo de libro, y libro es holnimo de hoja. En trminos ms coloquiales: un libro est
compuesto de hojas y una biblioteca est compuesta de libros.
En el modelamiento conceptual es la tpica asociacin todo/parte, que especifica la relacin entre el
agregado (todo) y los componentes (partes); en los ejemplos anteriores, libro y biblioteca son el todo
respecto a las partes hoja y libro.
Es, como puede verse, una asociacin binaria con la excepcin, entre otras, que las instancias no pueden
tener agregaciones cclicas, es decir, una parte no puede contener el todo (un libro no podra contener una
biblioteca).
Adicionalmente existen caractersticas que la distinguen de otro tipo de asociacin:
La agregacin es una relacin asimtrica, no es entre pares.
La agregacin es una relacin transitiva (la biblioteca tambin es, conceptualmente, un agregado de
hojas).
La agregacin es una asociacin que slo puede ser binaria, darse entre dos clases.
La agregacin implica un acoplamiento fuerte, en dnde las consecuencias usualmente se propagan (si
desaparecen todos los libros de una biblioteca, ya no existir la biblioteca; si se agregan nuevos captulos
hojas - a un libro, ya no ser el mismo libro).

Debido a que la agregacin no es simtrica, es importante distinguir visualmente cual de las clases en la
relacin es el agregado y cul es el componente, en la representacin visual del diagrama, con UML, esto se
logra adornando la asociacin con un pequeo diamante en el lado del agregado.
El hecho de ser una agregacin significa que una instancia de parte puede existir sin importar la existencia del
todo (puedo tener libros as no tenga una biblioteca y puede haber hojas con contenido, as no hagan parte de
un libro).
Adicionalmente existen otras formas de agregacin ms fuerte llamadas composiciones en donde lo dicho en
el prrafo anterior no aplica, es decir, la existencia de la parte depende del todo y no es posible tener una
parte si no se cuenta con el todo. Es tambin importante aclarar que, en la composicin, la parte slo puede
pertenecer a un nico todo.
En UML la representacin visual de la composicin y de la agregacin estn diferenciadas por elementos de
la notacin debido a que su carga semntica as lo exige, por tanto si as ocurre en la realidad, el modelo lo
debe representar en concordancia.

4.4.3 Relaciones no jerrquicas

Estas son asociaciones binarias simples que se dan entre entidades o conceptos pares o del mismo nivel, es
decir, ninguna de las entidades en la asociacin tiene mayor precedencia o ms importancia que la otra.
Ejemplos de este tipo de relaciones son las de causa-efecto, actividad-lugar de realizacin, proceso-producto,
etc.

Es importante que adems de identificar y representar estas relaciones en un diagrama se documente el

significado de dicha relacin, desde la perspectiva de cada rol y se de defina la cardinalidad de mapeo (uno a
uno, uno a muchos, muchos a muchos) y la obligatoriedad u opcionalidad de ocurrencia de la relacin.

4.4.4 Elaborar el modelo como diagrama(s) de clases

Como nuestro propsito insistimos es representar y comunicar conocimiento a un grupo plural de

personas, los modelos con mayor efectividad en este objetivo son aquellos que facilitan su lectura y
logran mayor eficacia en su comprensin; en tal sentido la densidad de elementos dentro del modelo es
un factor determinante en su interpretacin, pues un nmero muy grande de elementos obliga a
representarlo en espacios (diagramas) con dimensiones de difcil manejo, por ejemplo, para imprimirlos
requieren un dispositivo especial o el trabajo manual de pegar las partes; su lectura requiere exponerlos
8

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 9 de 10 VERSIN: 0

en una mesa o pared y obliga a un esfuerzo mayor de entendimiento por la cantidad de elementos y
relaciones en el dibujo.
El lineamiento de la Oficina de Informtica para presentar estos modelos requiere que los espacios de
dibujo (los diagramas de clases) donde se distribuyen las entidades o conceptos no rebasen una hoja
del tamao que pueda lograrse en una impresora normal de las provistas por el DNP., esto es tamao
carta o tamao oficio, si la complejidad o alcance del contexto real que se pretende modelar sobrepasa
esta consideracin, entonces se debe dividir el modelo en diagramas ms pequeos que si cumplan
este lineamiento. Siempre es posible, adems de deseable, identificar temas conceptuales o de negocio
para los cuales se elaboren diagramas de clases para conformar el modelo total. Si el anlisis del
dominio o contexto no juzga pertinente dividir un diagrama segn estos lineamientos, se debe ajuntar
una justificacin para presentar diagramas con tamaos superiores a los ya mencionados.
El nivel de detalle de los modelos UML, es tambin un factor determinante no slo para su comprensin
sino para garantizar calidad; calidad del diagrama propiamente dicho y de su repercusin en los
ulteriores artefactos y modelos relacionados, incluyendo el software en si mismo (Ariadi Nugroho, 2008).
En un modelo conceptual con alto nivel de abstraccin los detalles no slo son prescindibles en
ocasiones son innecesarios y molestos.
Entonces, para completar cada diagrama que hace parte del modelo conceptual o de dominio bastan
unas reglas simples de nomenclatura en notacin UML y un bajo nivel de detalle para los conceptos o
entidades; pero para las asociaciones, s se debe proveer documentacin de su significado y aportar la
definicin de su tipo (taxonmica, todo-parte, asociacin simple), su multiplicidad o precisin cardinal de
cada rol en relacin identificada. Para la explicacin de los conceptos se debe usar por lo menos una de
dos alternativas:
Exponer alguna(s) propiedad(es) de informacin que sirva(n) para identificar, describir,
cualificar o cuantificar cada instancia o ejemplo de un concepto;
Utilizar una nota de texto que aclare y dilucide el concepto.

Bibliografa.

Ariadi Nugroho, B. F. (2008). Empirical Analysis of the Relation between Level of Detail in UML Models and
Defect Density. (Springer, Ed.) Systems, MoDELS '08 Proceedings of the 11th international conference on
Model Driven Engineering Languages and.

DNP, J. V. (18 de Junio de 2010). Lineamientos Tcnicos para Aplicativos y Portales Web Informticos.
Obtenido de Guia de elaboracin Glosario de Terminos:
http://larebeca/LinkClick.aspx?fileticket=7npFcELZ0qU%3d&tabid=724

Espaola, R. A. (s.f.). RAE. Recuperado el 23 de Abril de 2012, de Diccionario de la Lengua:

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=modelo

Ling Liu, T. O. (2009). Encyclopedia of Database Systems. Springer.

Perez, C. (2006). Explotacin de los corpora textuales informatizados para la creacin de bases de datos
terminolgicas basadas en el conocimiento escrito. Revista electrnica Estudios de Lingstica Espaola
(ELiEs), Universidad de Mlaga.

Wirth, N. (febrero 1995). A Plea for Lean Software. Computer Magazine, 64 - 68.

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP
 GUA DE ELABORACIN DE MODELOS CDIGO:PI-G05

CONCEPTUALES PGINA: 10 de 10 VERSIN: 0

Fecha aprobacin: 15/06/2013

Revis: __________________________
Jorge Valenzuela Buitrago
Contratista Consultor Oficina de Informtica

Aprob: ____________________________
Carlos Alberto Ferrer Infante
Coordinador Grupo de Gestin de Proyectos Informticos

10

ESTE DOCUMENTO ES FIEL COPIA DEL ORIGINAL, QUE REPOSA EN EL GRUPO DE PLANEACIN DEL DNP