Content uploaded by Juan Bautista Cabral
Author content
All content in this area was uploaded by Juan Bautista Cabral on Aug 26, 2019
Content may be subject to copyright.
Desarrollo de una aplicaci´on web
colaborativa para revisiones de modelos
s´olidos param´etricos mediante el enfoque
Lean UX
Jos´e Mar´ıa Guaimas, Marcos Daniel Henning
Director: Dr. Ing. Juan B. Cabral
Co-Director: Ing. H´ector Ruid´ıas
Departamento de Inform´atica
Universidad Gast´on Dachary 2019
Agradecimientos
Antes que nada quisi´eramos agradecer al director, Dr. Ing. J. B. Cabral y al co-director
Ing. H´ector Ruid´ıas; por el entusiasmo, la libertad y la paciencia que nos brindaron durante
la planificaci´on e implementaci´on de este proyecto.
En segundo lugar a nuestras familias y amigos por la comprensi´on, consejos y compa˜n´ıa
en estos a˜nos de estudio.
Y por ´ultimo, y no menos importante, manifestar nuestro enorme respeto y aprecio
por toda la comunidad FLOSS de las herramientas que utilizamos, por su invaluable
generosidad a la hora de compartir conocimiento.
P´agina 2
Resumen
El Desarrollo Colaborativo de Productos y el Co-Dise˜no son conceptos muy utilizados
en las organizaciones, en especial, en las ´areas que involucran el dise˜no y fabricaci´on asis-
tido por computadora CAD/CAM. La evoluci´on de las tecnolog´ıas web ha permitido la
colaboraci´on entre personas dispersas geogr´aficamente, de diferentes campos de especiali-
zaci´on e incluso sin formaci´on en dise˜no.
Al mismo tiempo, la diversidad de conocimientos trae como consecuencia algunos pro-
blemas en la gesti´on de los proyectos, entre ellos: la comunicaci´on imprecisa, la m´ultiple
interpretaci´on de ideas y la complejidad para registrar el progreso o cambios en los dise˜nos.
El presente trabajo propone el desarrollo de un prototipo de aplicaci´on web que provee
un marco para la colaboraci´on multidisciplinaria mediante revisiones de modelos 3D. Esta-
bleciendo as´ı, un tipo de comunicaci´on entre los usuarios que va m´as all´a de la geometr´ıa.
El software llamado Colaborative CAD Application (CoCADa) se desarrolla en base al
enfoque Lean UX y utiliza tecnolog´ıas Free Libre Open Source Software (FLOSS).
Palabras Claves: Co-Dise˜no, CAD/CAM, Dise˜no Param´etrico, Modelado S´olido,
WPDM, FBDE, JavaScript, Lean UX.
P´agina 3
P´agina 4
´
Indice general
Resumen ........................................ 3
Glosario ......................................... 7
1. Introducci´on 11
1.1. Objetivos ..................................... 13
1.1.1. Objetivo general ............................. 13
1.1.2. Objetivos Espec´ıficos ........................... 13
2. Sistemas CAD 15
2.1. Introducci´on .................................... 15
2.2. Dise˜no Param´etrico ................................ 17
2.2.1. Dise˜no param´etrico mediante paquetes aplicativos .......... 17
2.2.2. Dise˜no param´etrico especificado en algoritmos ............. 18
2.3. Modelado S´olido ................................. 19
2.3.1. Representaci´on geom´etrica ........................ 20
2.3.2. Visualizaci´on ............................... 29
2.3.3. Dise˜no de Objetos ............................ 31
2.4. Sistemas CAD .................................. 35
3. Desarrollo Colaborativo de Productos CAD con Lean UX 39
3.1. Introducci´on .................................... 39
3.2. Co-dise˜no ..................................... 40
3.3. Sistemas CAD colaborativos ........................... 45
3.3.1. Soporte inform´atico a la colaboraci´on ................. 46
3.3.2. Sistemas de Modelado S´olido ...................... 47
3.3.3. Gesti´on de Datos del Producto (PDM) ................. 48
3.3.4. Intercambio de datos CAD ....................... 49
3.4. Lean UX ...................................... 53
3.5. Antecedentes ................................... 58
4. Resultados: CoCADa Un software para el dise˜no colaborativo con Lean
UX 61
4.1. Declaraciones ................................... 61
P´agina 5
4.1.1. Hip´otesis de la soluci´on ......................... 62
4.1.2. Personas .................................. 63
4.1.3. Funciones o funcionalidades ....................... 63
4.2. Dise˜no Colaborativo ............................... 64
4.3. PMV y experimentos ............................... 64
4.3.1. Demo #1 ................................. 65
4.3.2. Demo #2 ................................. 66
4.4. Feedback ..................................... 67
4.4.1. Feedback con Demo #1 ......................... 67
4.4.2. Feedback con Demo #2 ......................... 68
4.4.3. Resultados y propuestas ......................... 68
4.5. Sistema CoCADa ................................. 71
4.5.1. Back-End ................................. 71
4.5.2. Front-End ................................. 74
4.5.3. Interacci´on entre Usuarios, Front-End y Back-End .......... 81
5. Conclusiones 83
Bibliograf´ıa ....................................... 85
´
Indice de Figuras .................................... 93
P´agina 6
Glosario
Ace Editor Editor de c´odigo basado en la web, escrito en JavaScript.
Agile Enfoque para la toma de decisiones en los proyectos de software, que se refiere a m´etodos basados
en el desarrollo iterativo e incremental.
API Application Programming Interface, Interfaz de Programaci´on de Aplicaci´on.
API Explorer Explorador de API.
APP Aplicaci´on inform´atica.
ASCII American Standard Code for Information Interchange, C´odigo Est´andar Estadounidense para el
Intercambio de Informaci´on.
AutoCAD Software CAD utilizado para dibujo 2D y modelado 3D.
AutoLisp Lenguaje de programaci´on derivado del lenguaje Lisp para rutinas de AutoCAD.
Back-End Parte de la aplicaci´on que corre del lado del servidor.
Blender Software de c´odigo abierto para creaci´on de gr´aficos 3D.
CAD Computer Aided Design, Dise˜no Asisitido por Computadora.
CAM Computer Aided Manufacturing, Fabricaci´on Asistida por Computadora.
CGCAL Computational Geometry Algorithms Library. Librer´ıa de C++ que provee una colecci´on de
estructuras de datos y algoritmos para geometr´ıa.
CNC Control Num´erico Computarizado.
CPD Collaborative Product Development, Desarrollo Colaborativo de Productos.
CSG Constructive Solid Geometry, Geometr´ıa Constructiva de S´olidos. Modelo de representaci´on de
objetos 3D en forma de ´arbol.
CSG.js Librer´ıa para realizar operaciones de modelado CSG en la web.
CSS Cascading Style Sheet, Hoja de Estilos en Cascada.
DBMS DataBase Management System, Sistema de Gesti´on de Base de Datos.
DE Data Exchange, Intercambio de Datos.
EndPoints Puntos de conexi´on de un servicio, herramienta o aplicaci´on al que se accede a trav´es de una
API.
Express.js Framework de desarrollo de aplicaciones web para Node.js.
FB Featured Based, Basado en Caracter´ısticas.
FBDE Featured Based Data Exchange, Intercambio de Datos Basado en Caracter´ısticas.
FeatureScript Lenguaje de programaci´on dise˜nado para interactuar con OnShape.
P´agina 7
feedback Palabra del ingl´es que significa retroalimentaci´on; se utiliza como sin´onimo de respuesta o
reacci´on.
file storage Almacenamiento de archivos.
FLOSS Free Libre Open Source Software.
framework Marco de trabajo. Conjunto estandarizado de conceptos, pr´acticas y criterios para enfocar
un tipo de problem´atica particular que sirve como referencia, para resolver problemas similares.
Front-End Parte de la aplicaci´on web que interact´ua con los usuarios .
GitHub Plataforma web para alojar proyectos utilizando el sistema de control de versiones Git.
Grasshopper Lenguaje de programaci´on visual para modelado integrado en Rhino.
GUI Graphical User Interface, Interfaz Gr´afica de Usuario.
HTML HyperText Markup Language, Lenguaje de Marcado de Hipertexto.
HTML5 HTML en su Versi´on 5.
HTTP Hypertext Transfer Protocol, Protocolo de Transferencia de Hipertexto.
JavaScript Lenguaje de programaci´on.
JSON JavaScript Object Notation, Notaci´on de ob jeto de JavaScript. Formato de texto sencillo para el
intercambio de datos.
Lean UX Metodolog´ıa de trabajo enfocada en la experiencia de usuario (UX).
lightgl.js Librer´ıa para desarrollar aplicaciones WebGL.
Login Ingresar. Proceso mediante el cual se controla el acceso a un sistema.
Loopback Framework basado en Express.js orientado a construir REST APIs.
Material Design Sistema de Dise˜no Modular para dispositivos digitales que toma criterios de compor-
tamiento y forma basados en las leyes de la realidad, entre ellos la iluminaci´on, movimiento y
materiales.
Modelo.io Plataforma web para presentaci´on y colaboraci´on orientada a arquitectos e ingenieros que
trabajan con CAD.
MongoDB Sistema de base de datos NoSQL orientado a documentos.
Node.js Entorno JavaScript de lado de servidor que utiliza un modelo as´ıncrono y dirigido por eventos.
NoSQL Sistemas de gesti´on de bases de datos que difiere del modelo SGBDR (Sistema de Gesti´on de
Bases de Datos Relacionales).
Nuxt.js Framework para aplicaciones universales basado en Vue.js.
OAuth Est´andar abierto que permite flujos simples de autorizaci´on para aplicaciones inform´aticas.
OnShape Plataforma de dise˜no de productos que combina herramientas CAD, PDM y colaboraci´on en
la nube.
Open-Cascade Open Computer Aided Software for Computer Aided Design and Engineering.
OpenGL Open Graphics Library, Librer´ıa de Gr´aficos Abierta..
OpenJSCAD Software de modelado 3D en la web basado en el lenguaje javascript.
OpenSCAD Software de modelado 3D basado en un lenguaje de descripci´on textual.
P´agina 8
PDM Product Data Management. Gesti´on de Datos del Producto.
PHP Hypertext Preprocessor, preprocesador de hipertexto. Lenguaje de programaci´on.
PMV Producto M´ınimo Viable. Producto con suficientes caracter´ısticas para satisfacer a los usuarios y
proporcionar feedback para desarrollos futuros.
python Lenguaje de programaci´on.
research Investigaci´on.
REST REpresentational State Transfer, Transferencia de Estado Representacional.
Rhino Herramienta de software para modelado en 3D basado en NURBS.
scripting Interfaces de secuencias de comandos.
SCRUM Framework para el desarrollo ´agil de software.
Shared Workspace Marco de Trabajo Compartido.
sketch Boceto o bosquejo.
slider Control deslizante. Permite a los usuarios realizar selecciones a partir de un rango de valores.
SOAP Simple Object Access Protocol. Formato de mensaje XML utilizado en interacciones de servicios
web.
SolidWorks Software CAD para modelado mec´anico en 2D y 3D.
Speckle Proyecto que permite a los usuarios de programas como Grasshopper, compartir dise˜nos en la
web.
SSR Server Side Rendering, Renderizado en el Lado del Servidor.
STEP Standard for the Exchange of Product Data. Formato de intercambio de datos utilizado para
representar objetos 3D CAD e informaci´on relacionada.
STL STereoLithography. Formato de archivo que define geometr´ıa de objetos 3D, excluyendo informaci´on
como color, texturas o propiedades f´ısicas.
Three.js Librer´ıa escrita en JavaScript para crear gr´aficos y animaciones 3D en un navegador web.
URL Uniform Resource Locator, Localizador de Recursos Uniforme.
UX User Experience, Experiencia de Usuario.
Vue.js Framework JavaScript progresivo para crear interfaces de usuario y aplicaciones web.
vuetify Framework basado en Vue.js que implementa las normativas de Material Design.
Web Component Conjunto de caracter´ısticas para la creaci´on de widgets o componentes reutilizables
en documentos y aplicaciones web.
Web Services Servicios Web. Tecnolog´ıas que utiliza un conjunto de protocolos y est´andares para inter-
cambiar datos entre aplicaciones.
WebGL Web Graphics Library, Librer´ıa de Gr´aficos en la Web.
WPDM Web Product Data Management. Gesti´on de Datos del Producto basado en la web.
zoom Capacidad de aumentar o disminuir la escala en una figura o texto.
P´agina 9
P´agina 10
Cap´ıtulo 1
Introducci´on
Los sistemas de dise˜no asistido por computadora en ingl´es Computer Aided De-
sign (CAD) tienen una amplia trayectoria y han demostrado ser excelentes herramientas
para el dise˜no de productos [1], como caracter´ıstica distintiva incorporan el paradigma de
Dise˜no Param´etrico [2] que posibilita la modificaci´on del dise˜no de manera sencilla y r´api-
da mediante el ajuste de sus par´ametros; sin necesidad de modelar todo nuevamente. En
la industria de la manufactura estos sistemas son indispensables, ya que combinados con
la Fabricaci´on Asistida por Computadora en ingl´es Computer Aided Manufacturing
(CAM) y el Control Num´erico Computarizado (CNC), permiten que la fabricaci´on
digital [3] se pueda aplicar a pr´acticamente cualquier producto. La innovaci´on en este
contexto es la vinculaci´on directa entre el modelo CAD y su fabricaci´on CAM.
En Argentina, tal es la inter´es en este campo, que desde el a˜no 2013, el ministerio de
ciencia, tecnolog´ıa e innovaci´on productiva ha impulsado diversas acciones para la difusi´on,
capacitaci´on y apoyo a proyectos de innovaci´on, desarrollo y adopci´on de estas tecnolog´ıas.
Sobre todo en el ´area de la impresi´on 3D [4], al ser una de las m´as difundidas y promisorias
[5].
La masificaci´on de la fabricaci´on digital hace necesario el desarrollo colaborativo de
productos en ingl´es Collaborative Product Development (CPD) [6] entre grupos de exper-
tos con diferentes competencias y muchas veces geogr´aficamente dispersos. Este enfoque,
tambi´en conocido como co-dise˜no [7] requiere de una comunicaci´on efectiva en entornos
distribuidos1; dado que los problemas en los procesos de dise˜no suelen ser ocasionados por
errores en la interpretaci´on de ideas entre los participantes.
Por otra parte, la mayor´ıa de los sistemas CAD/CAM son aplicaciones de escritorio que
necesitan ser instaladas obligatoriamente en cada computadora por separado. Las aplica-
ciones web son menos propensas a este hecho ya que el usuario accede a ellas sin necesidad
de instalar el software en su dispositivo. El uso del CAD en la web se ha incrementado
1Entorno en el que los sistemas inform´aticos en red colaboran aportando sus recursos.
P´agina 11
en los ´ultimos a˜nos gracias a la estandarizaci´on de tecnolog´ıas como HTML52yWebGL
[8] que permiten experiencias de usuario en ingl´es User Experience (UX) [9] similares a
las de las aplicaciones de escritorio. Uno de los avances m´as recientes en este campo es la
capacidad de las aplicaciones web para representar gr´aficos en 3D. [10].
Recientemente han aparecido servicios que proporcionan funcionalidades de CAD y
administraci´on de proyectos de dise˜no en la nube [11]. Un ejemplo es OnShape3que permite
a los equipos colaborar mediante modelos compartidos desde la web. Sin embargo, esta
plataforma est´a orientada a especialistas en el dise˜no de piezas mec´anicas, siendo ideal
para los ambientes de ingenier´ıa y dise˜no industrial pero dif´ıcil de utilizar por personas
sin formaci´on en el ´area de modelado, en consecuencia, dificulta el co-dise˜no en t´erminos
de diversidad de competencias.
Esta situaci´on provoca que los participantes opten por utilizar servicios colaborativos
gen´ericos para comunicarse, como la mensajer´ıa instant´anea, las redes sociales o video-
conferencias mediante Skype4y compartan sus archivos utilizando Dropbox5o sistemas
similares. La multiplicidad de medios produce sesgo en la comprensi´on de los proyectos
a nivel general. Para un equipo es preferible contar con la colaboraci´on integrada en una
misma aplicaci´on web [12]. Otras limitaciones de estos servicios son la falta de mecanismos
para registrar el progreso o cambios de los dise˜nos en todo momento y la imposibilidad de
se˜nalar o “marcar” los problemas detectados de forma precisa, de manera que se pueda
informar sobre estos al resto del equipo.
Ante los problemas planteados, una aplicaci´on web colaborativa y distribuida
para el dise˜no de productos orientados a la fabricaci´on digital proporcionar´ıa
herramientas para facilitar el co-dise˜no entre participantes con diferentes competencias y
mejorar la administraci´on en t´erminos del progreso o evoluci´on de los dise˜nos. La aplicaci´on
o prototipo de software lleva el nombre de Aplicaci´on de CAD Colaborativa en ingl´es
Collaborative CAD Application (CoCADa).
Este documento se encuentra organizado de las siguiente manera: En el Cap´ıtulo
2se explican las caracter´ısticas de los sistemas CAD y los conceptos fundamentales de
los modelos orientados a la fabricaci´on digital. Luego se analizan las ventajas del uso de
Lean UX [13] para desarrollar un software colaborativo y distribuido (Cap´ıtulo 3), se
enuncia el problema y los detalles de la soluci´on (CoCADa) explicando los componentes
constitutivos y las principales funcionalidades implementadas (Cap´ıtulo 4). Finalmente,
en el Cap´ıtulo 5, se realizan la conclusiones y se formulan directivas para trabajos futuros.
2https://www.w3.org/TR/html52/
3https://www.onshape.com/
4https://www.skype.com/
5https://www.dropbox.com/
P´agina 12
1.1. Objetivos
1.1.1. Objetivo general
Desarrollar un prototipo de sistema que facilite la colaboraci´on en el proceso de dise˜no
de productos entre personas con diferentes competencias.
1.1.2. Objetivos Espec´ıficos
Recabar bibliograf´ıa sobre sistemas CAD param´etricos, modelos 3D en la web, mo-
delos orientados a la fabricaci´on digital, sistemas colaborativos y distribuidos, me-
todolog´ıa Lean UX.
Analizar y describir soluciones de CAD existentes, sobre todo aquellas que se ofrecen
como servicios en la nube.
Indagar sobre tecnolog´ıas colaborativas para el dise˜no iterativo de modelos 3D.
Investigar los requerimientos del sistema y los componentes de software a utilizar en
el desarrollo.
Dise˜nar la interfaz gr´afica de usuario en ingl´es Graphical User Interface (GUI) de la
aplicaci´on utilizando el enfoque Lean UX.
Dise˜nar un modelo de dominio de una capa de servicios.
Desarrollar el prototipo de software con herramientas FLOSS [14][15] seg´un los re-
querimientos de la GUI y el Modelo de dominio.
Realizar pruebas para experimentar en diferentes escenarios y evaluar los resultados.
P´agina 13
P´agina 14
Cap´ıtulo 2
Sistemas CAD
En este cap´ıtulo se describen los conceptos generales que involucran la representaci´on
de los modelos 3D, la visualizaci´on, la manipulaci´on y las caracter´ısticas para que puedan
aplicarse en la fabricaci´on digital. Al final del cap´ıtulo se describen algunos antecedentes
de aplicaciones CAD de escritorio y web que incorporan estos conceptos.
2.1. Introducci´on
La interacci´on entre el dise˜nador y el modelo en un proceso de dise˜no no es una
necesidad reciente, de hecho antecede la existencia de la computaci´on. Desde principios
del siglo XX se registran antecedentes como la maqueta que utiliz´o el arquitecto Antoni
Gaud´ı1para representar el modelo de la cripta de la Colonia Guell2(ver figura 2.1), esta se
conformaba por cadenas que sosten´ıan pesos y actuaban por la fuerza de la gravedad [2].
Se puede apreciar que fu´e construida al rev´es (izquierda) y se sac´o una fotograf´ıa (derecha)
para poder visualizarlo correctamente [16].
Una cadena que cuelga tiene por lo menos cuatro par´ametros: su longitud, su peso y
los dos puntos a los que est´a sujetada. Al estar colgando por la acci´on de la fuerza de
gravedad adopta una forma curva, definida por la funci´on explicita de los par´ametros de
la cadena. A pesar de ser an´alogo, este es un modelo param´etrico debido a la presencia
de par´ametros que controlan una forma derivada de una funci´on (calculada por la acci´on
de la gravedad). As´ı, el dise˜nador puede modificar un dise˜no representado por un modelo
visual de forma interactiva y en tiempo real, en este caso mediante arcos catenarios3.
No fue hasta la aparici´on de las computadoras y el primer programa CAD, Sketch-
1http://www.antonigaudi.org/
2http://www.gaudicoloniaguell.org/
3Una catenaria es una curva ideal que representa f´ısicamente la curva generada por una cadena, cuerda
o cable sin rigidez flexional, suspendida de sus dos extremos y sometida a un campo gravitatorio uniforme.
P´agina 15
Figura 2.1: Maqueta gravitatoria de Gaud´ı.
pad [17] (ver figura 2.2) que se facilit´o la interacci´on en tiempo real del dise˜nador y la
computadora [18].
Figura 2.2: Ivan Sutherland utilizando sketchpad en 1963.
En este contexto, para comprender el uso de tecnolog´ıas CAD es fundamental diferen-
ciar los conceptos computarizaci´on del dise˜no ydise˜no computacional. El primero
indica el uso de la computadora como herramienta de dibujo o representaci´on formal orien-
tado a disciplinas creativas, por ejemplo al realizar arte digital4, mientras que el dise˜no
computacional aborda el dise˜no con bases en el pensamiento algor´ıtmico, incluyendo el
dise˜no param´etrico y el generativo [19].
4El arte digital engloba una serie de disciplinas creativas en las que se utilizan tecnolog´ıas digitales en
el proceso de producci´on o en su exhibici´on.
P´agina 16
2.2. Dise˜no Param´etrico
El Dise˜no Param´etrico se entiende en t´erminos generales como un proceso de des-
cripci´on de una problem´atica utilizando variables. Actualmente para describir estas varia-
bles, los dise˜nadores introducen valores o algoritmos en un software especializado como
AutoCAD5, al modificar las variables se generan una serie de alternativas de soluciones
y seg´un el criterio del dise˜nador, se obtiene la soluci´on final. El dise˜no param´etrico en
su definici´on contempor´anea es ´unicamente posible creando un modelo param´etrico y se
define como un conjunto de ecuaciones que expresan una geometr´ıa expl´ıcitamente por
medio de funciones definidas por par´ametros [20]. En la figura 2.3 [21] se puede analizar
el proceso general:
Primero se realiza la abstracci´on de ideas y los conceptos del dise˜no.
A partir de la abstracci´on se establecen las condiciones geom´etricas y matem´aticas
para dar soporte a las ideas iniciales.
Del punto anterior derivan los par´ametros y variables necesarios para programar el
proceso.
Finalmente, de la programaci´on se obtiene la representaci´on visual para explorar los
resultados.
En todo momento el dise˜nador puede modificar las condiciones geom´etricas y ma-
tem´aticas, los par´ametros de la programaci´on y explorar los resultados.
Mediante el dise˜no iterativo en ingl´es iterative design [22] se analizan los resultados,
se vuelve a trabajar y refinar el modelo dise˜nado hasta lograr una versi´on o soluci´on
aceptable.
Los modelos param´etricos permiten a los dise˜nadores alterar y modificar la geometr´ıa
de manera eficiente sin tener que volver a crear el modelo. De esta manera, la parametri-
zaci´on puede elevar la calidad6y la reutilizaci´on de un modelo [12]. Este enfoque de dise˜no
se lleva a la pr´actica utilizando paquetes aplicativos o bien mediante la codificaci´on
por medio de algoritmos.
2.2.1. Dise˜no param´etrico mediante paquetes aplicativos
Los paquetes aplicativos de CAD son aquellos que se instalan en el ordenador y no
requieren del uso de internet, como AutoCAD. En este software, el dise˜no param´etrico
se logra utilizando restricciones aplicadas a la geometr´ıa [23] y se clasifican en dos ti-
pos: las restricciones geom´etricas que controlan las relaciones entre los objetos y las
5https://latinoamerica.autodesk.com/products/autocad/overview
6Capacidad que posee un objeto para satisfacer necesidades.
P´agina 17
Figura 2.3: Proceso general del dise˜no param´etrico.
restricciones por cota que controlan los valores de distancia, longitud, ´angulo y radio
de los objetos. Proporcionan una manera de cumplir con ciertos requisitos que permiten
experimentar con los dise˜nos o hacer modificaciones. Asimismo, las restricciones pueden
aumentar su flexibilidad mediante el uso de f´ormulas y ecuaciones.
En el modelo de la figura 2.4 algunas modificaciones en los par´ametros pueden hacer
cambios autom´aticamente a otros. Se puede apreciar una restricci´on mediante la f´ormula
d2 = d1∗6 de manera que d2 siempre ser´a 6 veces el tama˜no de d1 (las variables est´an
relacionadas). Por otro lado, el valor del di´ametro dia1 es independiente a cualquier otro
par´ametro [23].
Figura 2.4: Restricciones en un dise˜no param´etrico hecho con AutoCAD.
2.2.2. Dise˜no param´etrico especificado en algoritmos
Las interfaces de secuencias de comandos en ingl´es scripting7permiten a los
dise˜nadores/programadores escribir c´odigo para automatizar partes del dise˜no.
7Un script es un programa inform´atico usualmente simple, que por lo general se almacena en un archivo
de texto plano.
P´agina 18
El script, con sus par´ametros de entrada, funciones expl´ıcitas y salidas es una rea-
lizaci´on arquet´ıpica de la definici´on matem´atica de param´etrico [20]. Los sistemas pa-
ram´etricos se basan principalmente en principios algor´ıtmicos, dado que al igual que
los algoritmos, toman un valor o un conjunto de valores como entrada, ejecutan una serie
de pasos computacionales que transforman la entrada y finalmente producen un valor o un
conjunto de valores como salida [24]. Por lo tanto, las interfaces de scripting disponibles en
gran parte de los paquetes CAD est´an naturalmente predispuestas para generar modelos
param´etricos.
En la figura 2.5 se muestra un programa para generar una espiral 3D con bloques
simples (derecha) mediante expresiones anidadas definidas en c´odigo AutoLisp (derecha)
[25].
Figura 2.5: Programa en c´odigo AutoLISP para generar una espiral 3D.
Independientemente de las aplicaciones que se utilicen para el dise˜no, los modelos re-
sultantes son ´utiles para realizar estudios que de otra manera ser´ıan dif´ıciles, por ejemplo
al no contar con el objeto f´ısico. En este aspecto, entra en juego el Modelado Geom´etri-
co [26], haciendo referencia al conjunto de m´etodos utilizados para definir la forma y otras
caracter´ısticas de los objetos. Estos m´etodos son un compendio de las t´ecnicas utilizadas
en varias disciplinas, como la Geometr´ıa Anal´ıtica y Descriptiva, la Topolog´ıa, la Teor´ıa
de Conjuntos, el An´alisis Num´erico, las Estructuras de Datos, el C´alculo Vectorial y los
M´etodos Matriciales. Las aplicaciones de estas t´ecnicas abarcan la Representaci´on,Vi-
sualizaci´on yDise˜no de los objetos.
2.3. Modelado S´olido
El Modelado S´olido [27] es una rama del modelado geom´etrico que hace hincapi´e en
la aplicabilidad general de los modelos, e insiste en crear solamente modelos “completos”de
los s´olidos, es decir, modelos que son adecuados para responder algor´ıtmicamente (sin la
ayuda externa del usuario) a cualquier pregunta geom´etrica que se formule. Se espera que
respondan preguntas geom´etricas t´ıpicas que aparecen en las aplicaciones de ingenier´ıa.
P´agina 19
Por ejemplo: ¿Cu´al es el aspecto del objeto?, ¿C´omo puede fabricarse con los procesos
de manufacturaci´on disponibles? La respuesta podr´ıa ser una imagen, un n´umero o una
constante booleana. De hecho, incluso podr´ıa ser otro modelo s´olido [26].
Las ventajas pr´acticas del modelado s´olido son:
Agiliza el desarrollo y los detalles del dise˜no.
Mejora la visualizaci´on y la comunicaci´on del dise˜no.
Elimina los problemas de interferencias del dise˜no.
Comprueba la funcionalidad y el rendimiento del dise˜no (sin la necesidad de proto-
tipos f´ısicos).
Proporciona de forma autom´atica las caracter´ısticas topol´ogicas para la
fabricaci´on digital, necesarias al programar m´aquinas herramientas de CNC, im-
presoras 3D, etc.
Un sistema de Modelado S´olido maneja dos tipos de informaci´on: los datos geom´etri-
cos ylos datos topol´ogicos. Los datos geom´etricos son aquellos que representan geom´etri-
camente los objetos (coordenadas de v´ertices, ecuaciones de superficies, etc). En cambio,
los topol´ogicos se refieren a c´omo conectar componentes geom´etricos para conseguir un
modelo [26].
2.3.1. Representaci´on geom´etrica
Muchos esquemas de representaci´on y particularmente los modelos s´olidos utilizan
poliedros [28] con caras, aristas y v´ertices. Se pueden apreciar en la figura 2.6 con 2
ejemplos de poliedros: prisma rectangular (izquierda) y tetraedro (derecha). A bajo nivel,
todos los algoritmos que se utilizan se basan en una ´unica primitiva8: el pol´ıgono y los
pol´ıgonos se dividen en elementos m´as simples: tri´angulos.
Figura 2.6: Caras, aristas y v´ertices en 2 poliedros diferentes.
8Las formas geom´etricas se denominan primitivas por su b´asica constituci´on en las partes que la con-
forman.
P´agina 20
Transformaciones 3D
En t´erminos matem´aticos, es com´un encontrar la representaci´on de los modelos por
medio de Matrices [29] (espacio vectorial 3D), estos deben someterse a ciertas transfor-
maciones antes de que su imagen aparezca en la pantalla de un dispositivo. Las transfor-
maciones geom´etricas se definen como la relaciones de los puntos entre dos im´agenes, son
operaciones matriciales sobre los puntos del objeto. Cada objeto se representa como una
matriz constituida por las coordenadas (x, y, z) de los puntos que lo conforman [30].
Las transformaciones b´asicas son: Traslaci´on 3D,Rotaci´on 3D,Escalamiento 3D
y la composici´on de las mismas para lograr secuencias de transformaciones. La traslaci´on
mueve un objeto con una trayectoria en l´ınea recta de una posici´on a otra. La rotaci´on
mueve un objeto de una posici´on a otra a lo largo de una trayectoria circular sobre un eje
de rotaci´on espec´ıfico.
A modo de ejemplo se explica el Escalamiento 3D:
El escalamiento permite cambiar el tama˜no de un objeto expandi´endolo o contray´endo-
lo en sus dimensiones. Esto implica el cambio de tama˜no de un poliedro, donde cada punto
p= (x, y, z) es transformado por la multiplicaci´on de tres factores de escalamiento: sx, sy
ysza lo largo de los ejes X, Y, Z respectivamente, de esta forma, las coordenadas del
nuevo punto p0= (x0, y0, z0) se obtienen como:
x0=x.sx
y0=y.sy
z0=z.sz
Sea s= (sx, sy, sz) el vector de factores de escalamiento, y S(s) la matriz de esca-
lamiento, en coordenadas homog´eneas [31] el escalamiento de un punto pen 3D se puede
expresar como el producto matricial p0=p.S(s) , es decir (ver ecuaci´on Ec.1):
hx0y0z01i=hx y z 1i.
sx0 0 0
0sy0 0
0 0 sz0
0 0 0 1
(Ec.1)
Expresi´on matricial para el escalamiento 3D.
En la figura 2.7 se puede apreciar el escalamiento de un cubo (izquierda) con los factores
sx= 2, sy= 2,5 y sz= 1,5. Al aplicar diferentes factores se produce una variaci´on en las
proporciones del objeto original dando como resultado el objeto de la derecha [32].
El visor o c´amara puede ser considerado como un objeto m´as, respecto a las transfor-
maciones lineales. Sin embargo, el movimiento de los visores tiene sus propias peculiarida-
des, por lo que conviene estudiar de modo independiente las transformaciones lineales que
P´agina 21
Figura 2.7: Escalamiento de un cubo.
se aplican a estos objetos. Por ejemplo: El cambio de escala en el visor produce el efecto
zoom (acercar/alejar) [26].
Topolog´ıa de los modelos s´olidos
Conocer las caracter´ısticas topol´ogicas de los poliedros es importante para la construc-
ci´on de los modelos s´olidos y especialmente para su validaci´on.
Los s´olidos est´an definidos en el espacio Eucl´ıdeo E3, ocupando una determinada por-
ci´on de ese espacio. Por lo tanto, se considera un s´olido como un conjunto de E3. Obvia-
mente no todos los subconjuntos del espacio Eucl´ıdeo son s´olidos (por ejemplo un punto
aislado no es un s´olido). Para que un s´olido abstracto resulte ´util como elemento de repre-
sentaci´on debe poseer las siguientes propiedades: [33]:
Clausura. Toda operaci´on efectuada entre un s´olido o entre diversos solidos debe
producir otro s´olido.
Finitud. Ocupa una porci´on finita del espacio en el que el encuentra inmerso.
Frontera determinista. Debe definir de forma no ambigua la regi´on del espacio
que se corresponde con su interior y la que corresponde con su exterior.
Rigidez. Los s´olidos no se modifican al trasladarlos o rotarlos. O lo que es lo mismo,
dos s´olidos que se diferencian tan solo en una transformaci´on son el mismo s´olido.
Homogeneidad tridimensional. Todas las partes del s´olido deben tener la misma
dimensionalidad, debe ser tridimensional E3en todos sus puntos. En la figura 2.8
se ilustra un objeto que no posee homogeneidad tridimensional (no s´olido), contiene
elementos 2D (cara que cuelga) y 1D (arista que cuelga) [33].
A continuaci´on se estudia la topolog´ıa de algunos poliedros que satisfacen las condi-
ciones para el modelado s´olido: Los poliedros simples, no simples y los objetos de Euler.
P´agina 22
Figura 2.8: Objeto sin homogeneidad tridimensional.
Poliedros simples y no simples
Un poliedro simple es aqu´el que puede ser transformado de forma continua en una
esfera, o sea, es topol´ogicamente equivalente a una esfera.
La F´ormula de Euler para los poliedros simples establece que para un poliedro simple
se cumple que el n´umero de v´ertices V, menos el n´umero de aristas A, m´as el n´umero de
caras C[26] es igual a 2, es decir (ver Ec.2):
V−A+C= 2 (Ec.2)
Los poliedros regulares forman un subconjunto de los poliedros simples, cuya carac-
ter´ıstica principal es que todas sus caras (pol´ıgonos) son iguales, seg´un la f´ormula anterior
se puede demostrar que s´olo existen 5 poliedros regulares: tetraedro, hexaedro o cubo,
octaedro, dodecaedro e icosaedro.
Los poliedros no simples son los equivalentes topol´ogicos de cualquier objeto s´olido
con huecos, por lo que son muy ´utiles en el Modelado S´olido [26].
Para clasificar los poliedros se recurre al concepto de n´umero de conectividad (n).
Si la superficie de un poliedro se puede dividir en dos regiones separadas mediante un
camino cerrado trazado a lo largo de sus aristas, se dice que tiene conectividad n= 0. La
esfera es un cuerpo que siempre cumple con esa condici´on, por ende, cualquier poliedro de
conectividad 0 (simple) puede ser transformado en una esfera. Este fen´omeno se aprecia
con el poliedro simple regular (icosaedro) ilustrado a la izquierda de la figura 2.9. Por otro
lado, el objeto de la derecha cuenta con caminos cerrados que no dividen a su superficie
en dos partes separadas (contiene un hueco). A estos poliedros se les asigna un n´umero de
conectividad mayor que 0 y por ende, al contener huecos se los denomina no simples.
Si bien los poliedros simples y no simples son s´olidos, la f´ormula de Euler establece
condiciones necesarias, pero no suficientes para que un objeto sea un poliedro. Se pueden
construir objetos que satisfagan la f´ormula, pero que no acoten un volumen, sin m´as que
a˜nadir una o m´as caras o aristas colgantes. Se requieren de otras restricciones para
garantizar que un objeto sea un s´olido.
P´agina 23
Figura 2.9: Poliedro simple y poliedro no simple.
Objetos de Euler
Agse conoce como orden o grado del objeto y tambi´en como orden de la su-
perficie. As´ı, una esfera equivale a g= 0, un toro, topol´ogicamente hablando, puede
considerarse como una esfera con 1 asa (g= 1) y as´ı sucesivamente seg´un la cantidad de
huecos que tenga el objeto. En la figura 2.10 se muestran 3 objetos diferentes representados
como esferas con asas (g= 0, g= 1 y g= 2) respectivamente [34].
Figura 2.10: Objetos diferentes que se representan como esferas con gasas.
Los objetos cerrados tridimensionales de orden g≥0 que verifican ciertos requisitos
de construcci´on se denominan objetos de Euler. Estos requisitos son:
Todas sus caras (curvas o planas) han de ser discos topol´ogicos9, es decir que no
tienen huecos ni puntos aislados en ellas.
Cada arista une s´olo dos caras y todas finalizan en un v´ertice en cada extremo.
Como m´ınimo tres aristas se unen en un v´ertice.
En todos los objetos de Euler se cumple que (ver ecuaci´on Ec.3):
V−A+C= 2(S−P) (Ec.3)
S: n´umero de superficies inconexas del objeto.
9Una regi´on, plana o no, que pueda ser transformada en un cuadrado se llama disco topol´ogico.
P´agina 24
P: total de pasajes (t´uneles) en el objeto.
Como el n´umero de pasajes en un objeto es igual al total de “asas” o agujeros que
posea, ocurre que en la ecuaci´on anterior Pes igual al orden del objeto (P=g).
El significado de Sse puede visualizar en la figura 2.11 que muestra tres objetos
eulerianos, con una, dos y tres superficies inconexas. S= 1, S= 2 y S= 3 respectivamente
[26].
Figura 2.11: Objetos de Euler con diferentes valores de S(n´umero de superficies inconexas)
La figura 2.12 ilustra tres objetos eulerianos, si bien estos cuentan con diferentes n´ume-
ro de v´ertices V, aristas Ay caras C, cuando S= 1 y P= 0 (no poseen huecos) la Ec.3 se
reduce a la ecuaci´on de Euler para poliedros simples Ec.2. Se verifica que en los tres casos
se cumple la igualdad, por ende, estos objetos se representan como poliedros simples [26].
Figura 2.12: Ejemplos de objetos de Euler con diferentes n´umeros de v´ertices V, aristas Ay caras C.
En la figura 2.13 se muestran dos objetos con diferentes P. El objeto de la izquierda,
aunque posee una cavidad, esta no llega a atravesar el modelo P= 0. Se trata de un objeto
s´olido topol´ogicamente equivalente a una esfera, es decir, de grado g= 0.
Por otro lado, el objeto de la derecha (ver figura 2.13) es de grado g= 1 (posee un t´unel
que lo atraviesa) P= 1. Es un s´olido topol´ogicamente equivalente a un toro [26].
P´agina 25
Figura 2.13: Objetos eulerianos de g= 0 y g= 1, respectivamente.
Representaci´on por atlas
Uno de los puntos clave en el modelado con poliedros es c´omo se registra su informaci´on
topol´ogica, es decir, las relaciones entre los v´ertices, aristas y caras que los definen. La
forma m´as simple y directa para representar los poliedros consiste en describir cada cara
por separado, se˜nalando expl´ıcitamente c´omo han de unirse. Este m´etodo de representaci´on
se conoce como atlas. La figura 2.14 muestra el atlas de un cubo, el valor del centro
indica el n´umero de cara y los n´umeros cercanos al borde indican el n´umero de arista
correspondiente a cada cara [26].
Figura 2.14: Atlas de un cubo.
Cada eje se etiqueta con un par de n´umeros indicando la cara y el n´umero de la arista
de la cara. As´ı el par (1,0) se interpreta como la arista 0 de la cara 1. Cada uni´on de dos
aristas se especifica por dos pares de n´umeros, identificando las aristas que se unen. De
esta forma, el atlas se puede representar como una matriz (ver Ec.4):
P´agina 26
[(1,0) (2,0)] [(1,1) (5,0)] [(1,2) (4,0)] [(1,3) (3,0)]
[(2,1) (3,3)] [(2,3) (6,2)] [(2,3) (5,1)] [(3,1) (4,3)]
[(3,2) (6,3)] [(4,1) (5,3)] [(4,2) (6,0)] [(5,2) (6,1)]
(Ec.4)
Representaci´on matricial del atlas
Adem´as de especificar qu´e aristas est´an unidas, se debe decir c´omo unirlas. La figura
2.15 muestra dos formas diferentes de unir un par de aristas. La primera, mostrada a
la izquierda, es la uni´on con orientaci´on conservadora, se obtiene como resultado un
cilindro. La segunda (derecha) tiene orientaci´on inversora, se obtiene una cinta de
moebius [26]. Para unir esas dos aristas hay que hacer coincidir los n´umeros de cada una
de ellas. Si se hace mediante la orientaci´on conservadora se obtiene un cilindro y con la
orientaci´on inversora una cinta de Moebius10.
Figura 2.15: Orientaci´on conservadora y Orientaci´on inversora.
Para especificar en el atlas de qu´e forma se van a unir las aristas, se utiliza la paridad
de transici´on que es n´umero ±1 (+ 1 si es conservadora, -1 si es inversora), unido al par
de aristas. La figura 2.16 presenta tres ejemplos de esta notaci´on: Paridad de transici´on
de una esfera (izquierda), de un toro (centro) y a la derecha de una Botella de Klein (se
puede observar la paridad de transici´on −1) [26].
Figura 2.16: Paridad de transici´on de una Esfera, un Toro y una Botella de Klein.
10La cinta de M¨obius o Moebius es una superficie con una sola cara y un solo borde. Tiene la propiedad
matem´atica de ser un objeto no orientable.
P´agina 27
Si se utilizan uniones no conservadoras en un atlas se consiguen algunas curiosidades
matem´aticas llamadas superficies no orientables, como la cinta de Moebius y la bo-
tella de Klein11 (ver figura 2.17). La cinta de Moebius posee una curiosa particularidad.
Si se recorre la cinta comenzando en un punto cualquiera, y se da una vuelta completa,
como se trata de una cinta bidimensional, cuando se llegue al punto de partida se observar´a
que la derecha e izquierda est´an intercambiadas. Si se parte de una cinta de Moebius y se
cierra aplicando una orientaci´on conservadora, se obtiene una botella de Klein (no orien-
table), que no se puede construir en un espacio tridimensional sin que se auto interseque.
Este tipo de superficies se llaman no orientables y se producen al efectuar uniones no
conservadoras entre sus aristas. Por el contrario, si en la superficie nunca se intercambian
la izquierda y derecha, entonces se dice que la superficie es orientable [26].
Figura 2.17: Superficies no orientables. Cinta de Moebius y Botella de Klein.
Para que cualquier superficie cerrada tridimensional sea consistente, debe ser topol´ogi-
camente equivalente a una esfera con “g” asas. Ahora se a˜nade otra condici´on m´as: debe
ser orientable [26].
Representaci´on mediante operadores Booleanos.
Para construir objetos s´olidos complejos se pueden utilizar operaciones entre conjuntos,
tales como uni´on (∪), intersecci´on (∩) y diferencia (−). A estos operadores se les conoce
en modelado como Operadores Booleanos [26]. Al aplicarlos sobre objetos simples se
pueden construir modelos m´as complejos. Es fundamental que los modelos obtenidos sean
´ıntegros (topol´ogicamente v´alidos), y que adem´as sean dimensionalmente homog´eneos,
es decir, que su dimensi´on sea igual a la de los objetos que se combinan. En la figura 2.18
se pueden apreciar los resultados de las operaciones booleanas entre los objetos A(esfera)
11En topolog´ıa, una botella de Klein es una superficie no orientable abierta cuya caracter´ıstica de Euler
es igual a 0; no tiene interior ni exterior.
P´agina 28
y B(cubo). A∪B,A∩B,A−ByB−Arespectivamente [35].
Figura 2.18: Operaciones booleanas entre una esfera y un cubo.
La aplicaci´on de una operaci´on booleana ordinaria a objetos s´olidos no necesariamente
produce otro objeto s´olido. Para evitar esta situaci´on se utiliza el conjunto de operadores
regularizados [26], que preservan la homogeneidad dimensional. Se representan por ∪∗,
∩∗y−∗y se definen de manera que las operaciones con s´olidos siempre generen s´olidos. En
la figura 2.19 se muestra un ejemplo donde la intersecci´on A(∩)Bentre dos objetos v´alidos
3D obtiene como resultado un objeto con una cara que cuelga 2D (no s´olido). La soluci´on
es efectuar una serie de operaciones matem´aticas i(A(∩)B) de manera que se eliminen los
componentes 2D, 1D. Entonces, la intersecci´on ordinaria se reemplaza por la intersecci´on
regularizada (A∩∗B) [33] asegurando que siempre se generen objetos s´olidos.
Figura 2.19: Intersecci´on no regularizada (∩) y regularizada (∩∗) de dos s´olidos.
2.3.2. Visualizaci´on
Un elemento indispensable para visualizar modelos 3D en una pantalla es la S´ınte-
sis de im´agenes, definida como el campo de la inform´atica gr´afica que se dedica prin-
cipalmente al estudio y desarrollo de procesos para sintetizar im´agenes raster [26]. Las
computadoras deben realizar un conjunto de operaciones elementales para conseguir pasar
de la representaci´on de un modelo geom´etrico tridimensional a su imagen plana en
pantalla (2D), pero que para la impresi´on del observador parezca estar contemplando un
sistema de visualizaci´on en el mundo real en 3D.
Esquem´aticamente, el objetivo principal de un sistema gr´afico12 se resume en la figura
12Sistema gr´afico se refiere al conjunto de programas y herramientas auxiliares que permiten la s´ıntesis
P´agina 29
2.20: la visualizaci´on o rendering se produce en funci´on de las condiciones establecidas por
el observador, c´amara o visor f(visor) [26]. Es necesario el visor para generar una imagen
bidimensional discreta (raster) a partir de un espacio vectorial 3D, lo que implica no poder
mostrar simult´aneamente en pantalla toda la informaci´on del modelo sino solamente lo
que alcanza a ver el observador.
Figura 2.20: Esquema de visualizaci´on.
La visualizaci´on se logra mediante una secuencia de operaciones conocida como viewing
pipeline [36] ilustrada en la figura 2.21. En primer lugar, se aplica una proyecci´on que
mapea el objeto 3D a un nuevo objeto “plano” en un plano de visi´on en ingl´es Viewplain.
Luego, se define un sistema de coordenadas en el viewplane especificando un punto como
origen, y dos vectores perpendiculares que dan las direcciones de los ejes de coordenadas.
Se aplica una asignaci´on de coordenadas del viewplane para expresar el objeto “plano”
en t´erminos del sistema de coordenadas del plano bidimensional elegido. Finalmente, el
objeto “plano” se asigna a la pantalla del dispositivo por medio de una transformaci´on de
coordenadas bidimensional [36].
Figura 2.21: Secuencia de operaciones para la visualizaci´on (viewing pipeline).
B´asicamente hay dos m´etodos para proyectar objetos tridimensionales sobre una su-
perficie bidimensional: proyecci´on en perspectiva yproyecci´on en paralelo.
Sea nel vector plano de un viewplane, y sea V(punto de visi´on o c´amara) un punto que
no est´a sobre el viewplane. La proyecci´on en perspectiva de Vsobre nes la transformaci´on
que mapea cualquier punto Pdel objeto, distinto de V, en el punto P0que es la intersecci´on
de la l´ınea V P y el plano n, como se ilustra en figura 2.22 (a). La proyecci´on se efect´ua
mediante l´ıneas que convergen en una posici´on determinada. Si Ves un punto en el infinito,
la proyecci´on es paralela, todos los puntos del objeto se proyectan sobre la superficie
de im´agenes raster, a partir de un modelo vectorial 3D.
P´agina 30
bidimensional mediante l´ıneas paralelas (ver figura 2.22 (b)) [36].
Figura 2.22: Proyecci´on en perspectiva y Proyecci´on en paralelo.
La proyecci´on desde el punto de visi´on Val viewplane nes una transformaci´on tridi-
mensional dada por la siguiente matriz [36] (ver ecuaci´on Ec.5):
M=nTV−(nV )I4(Ec.5)
Siendo I4una matriz identidad de 4x4.
Las tecnolog´ıas de visualizaci´on implementan estos conceptos de diferentes maneras
dependiendo del contexto en que se utilizan, por ejemplo, en OpenGL13 se implementa
la visualizaci´on mediante las matrices Modelo, Vista y Proyecci´on en ingl´es model-view-
projection matrix [37].
En el dise˜no CAD es fundamental que los modelos est´en bien definidos (consistentes) y
la visualizaci´on es auxiliar (aunque necesaria), por lo que no tiene demasiada importancia
la resoluci´on14 de las im´agenes, al menos en las primeras fases de dise˜no.
2.3.3. Dise˜no de Objetos
Los modelos s´olidos se pueden dise˜nar mediante el modelado poligonal [38] que
consta en la manipulaci´on de v´ertices, aristas o caras de los poliedros. Este enfoque es muy
flexible porque los ordenadores pueden renderizar los modelos muy r´apido, sin embargo,
al contener pol´ıgonos planos se dificulta la cobertura geom´etrica al construir modelos de
geometr´ıa compleja, por ejemplo: para generar superficies curvas precisas se necesitan
grandes cantidades de pol´ıgonos. Para solventar ese problema se utilizan otras t´ecnicas de
modelado, incluyendo:
13https://www.opengl.org/
14La resoluci´on de una imagen indica la cantidad de detalles que puede observarse en esta.
P´agina 31
Modelado Booleano (CSG)
Al conjunto de procesos que permiten el dise˜no de s´olidos complejos mediante la com-
binaci´on booleana de objetos simples (primitivas) se conoce como modelado booleano,
o tambi´en Geometr´ıa Constructiva de S´olidos en ingl´es Constructive Solid Geometry
(CSG) [39].
En el modelado booleano, luego de escalar, trasladar y rotar convenientemente las primi-
tivas, se aplican los operadores booleanos regularizados (∪∗,∩∗y−∗) para combinarlas.
Un s´olido construido mediante un modelador booleano (CSG) queda descrito mediante un
´arbol binario en el que:
El nodo ra´ız es el s´olido resultante.
Los nodos internos son los operadores booleanos.
Los nodos hoja son las primitivas.
En los nodos terminales del ´arbol no s´olo se representan las primitivas, sino que tambi´en
se indican las transformaciones lineales que se han de efectuar sobre ellas. En el ´arbol,
tanto las operaciones como los nodos hoja deber´an encontrarse ordenadas, debido a que
las operaciones booleanas no son, en general, conmutativas. El proceso de seguimiento
(recorrido) del ´arbol se har´a partiendo de los nodos terminales.
En el ejemplo de la figura 2.23 se puede ver la descripci´on de un modelo booleano lla-
mado R3como un ´arbol CSG utilizando las operaciones booleanas: uni´on (∪), intersecci´on
(∩) y diferencia (−) [40].
Figura 2.23: ´
Arbol CSG utilizando las operaciones booleanas: uni´on (∪), intersecci´on (∩) y diferencia
(−).
Partiendo de las primitivas P0(cilindro), P1(cilindro), P2(cilindro), P3(esfera) y P4
(cubo) se obtiene el objeto final (R3) despu´es de tres niveles de operaciones booleanas.
P´agina 32
En primer lugar se efect´ua la uni´on de P0yP1, despu´es de haber transformado y
posicionado adecuadamente las primitivas en el espacio, mediante las matrices netas T0y
T1(ver ecuaci´on Ec.6).
R0=P0·T0∪P1·T1(Ec.6)
A continuaci´on el resultado intermedio R0se suma con la primitiva P2(cilindro),
despu´es de haber sido escalada y posicionada por T2(ver ecuaci´on Ec.7).
R1=R0∪P2·T2(Ec.7)
Para producir el resultado R2se realiza la intersecci´on entre P3yP4, despu´es de
haber transformado y posicionado adecuadamente las primitivas en el espacio, mediante
las matrices netas T3yT4(ver ecuaci´on Ec.8).
R2=P3·T3∩P4·T4(Ec.8)
Finalmente, a R2se le resta R1, obteniendo as´ı el objeto ra´ız del ´arbol R3(ver ecuaci´on
Ec.9).
R3=R2−R1= (P3·T3∩P4·T4)−((P0·T0∪P1·T1)∪(P2·T2)) (Ec.9)
En el ejemplo se puede apreciar que las transformaciones han incrementado el tama˜no
del s´olido resultante R3. Por lo general, el escalado de las primitivas no es uniforme, es
decir, los factores de escala sx,sy, y szson diferentes. De este modo, una sola primitiva
puede proporcionar una gran variedad de copias diferentes simplemente usando transfor-
maciones.
Es importante indicar que el modelado booleano es un proceso descriptivo, es decir,
s´olo se limita a especificar qu´e primitivas se utilizan y c´omo se combinan. De manera que
s´olo se dispone de la informaci´on geom´etrica y topol´ogica de las primitivas pero no la de
los objetos resultantes. Para poder combinar las primitivas en un esquema de modelado,
´estas han de ser definidas previamente. Una forma frecuente de crearlas es estableciendo
los par´ametros de las ecuaciones que las definen.
Dise˜no de nuevas primitivas
La figura 2.24 muestra dos primitivas con los par´ametros de control que cada una
requiere (excluidos los de posici´on y orientaci´on). A la izquierda un cono con 2 par´ametros:
altura (H) y radio (R). A la derecha un cono truncado con 3 par´ametros: altura (H),
radio superior (R1) y radio inferior (R2). La primitiva de la izquierda en 3D solo puede
generar conos. La primitiva de la derecha por su parte puede generar cilindros, conos
y conos truncados. [26]. Cuanto m´as flexible es esta definici´on, mayor es la capacidad
P´agina 33
para modelar los diferentes objetos y por consecuencia mayores son las posibilidades de
modelado. Se llama dominio o poder expresivo de un modelador, a la capacidad que
posee para modelar los diferentes objetos.
Figura 2.24: Primitivas con sus par´ametros de control.
El sistema de modelado define un conjunto objetos s´olidos que son relevantes para
un ´area de aplicaci´on determinada. Estos suelen parametrizarse no s´olo en funci´on de las
transformaciones, sino tambi´en con base a otras propiedades. Por ejemplo, objetos como
engranajes o tuercas son tediosos de definir utilizando combinaciones booleanas de objetos
m´as sencillos pero pueden ser formulados f´acilmente con par´ametros de alto nivel como
di´ametro, espesor, n´umero de dientes, etc. (Ver figura 2.25). El cambio en los par´ametros
genera objetos con diferentes caracter´ısticas, por ejemplo: el engranaje de la derecha no
posee ning´un orificio, producto del cambio de valor Radio de orif icio = 0.
Figura 2.25: Dos engranajes generados a partir de la misma primitiva.
La ´unica forma de modelar un nuevo tipo de objeto es describiendo el mecanismo que
lo define, es decir, es necesario escribir las rutinas o programas que lo dibujan o determinan
sus propiedades.
P´agina 34
2.4. Sistemas CAD
Para comprender el estado actual del CAD primero se deben estudiar algunas aplicacio-
nes disponibles. Las soluciones presentadas incluyen herramientas basadas en el escritorio
y basadas en la web. A continuaci´on se describen las caracter´ısticas m´as relevantes para
este trabajo: Permitir el dise˜no param´etrico, contar con interfaz de scripting y proveer
mecanismos para generar modelos s´olidos.
Blender
Blender [41] es una una suite de creaci´on 3D FLOSS compatible con la totalidad
del trabajo en 3D: modelado, rigging, animaci´on, simulaci´on, renderizado, composici´on y
tracking de movimiento, incluso edici´on de video y creaci´on de videojuegos. Est´a prin-
cipalmente orientada a producciones art´ısticas, sin embargo, dispone de herramientas y
primitivas para generar s´olidos orientados a la fabricaci´on digital. Tambi´en permite el uso
de modificadores que son operaciones autom´aticas que afectan a un objeto de una manera
no destructiva15. Con los modificadores, se pueden realizar tareas que manualmente ser´ıan
demasiado tediosas. Entre muchos otros, se encuentra el modificador booleano que val-
ga la redundancia se utiliza para operaciones booleanas entre objetos. Otra capacidad de
Blender es el acceso a su API16 mediante scripting, utilizando el lenguaje de programaci´on
python17.
En la figura 2.26 se puede ver la interfaz de Blender y la aplicaci´on de intersecciones me-
diante el modificador booleano, tambi´en se aprecia el c´odigo en python para realizar la
misma operaci´on mediante su API [42].
Grasshopper
En la ´ultima d´ecada se ha visto la aparici´on de un nuevo tipo de interfaz visual pa-
ra scripting. Este tipo de programaci´on visual implica representar programas no como
texto, sino como diagramas. Un ejemplo de estas aplicaciones es Grasshopper [43], un
editor de algoritmos gr´aficos estrechamente integrado con las herramientas de modelado
3D de Rhino18. Se basa principalmente en nodos que mapean el flujo de relaciones desde
par´ametros, a trav´es de funciones definidas por el usuario, concluyendo normalmente con
la generaci´on de geometr´ıas. Las modificaciones en los par´ametros o las relaciones del mo-
delo hacen que los cambios se propaguen a trav´es de las funciones expl´ıcitas para volver a
15 No destructivo se refiere a hecho de realizar cambios sin sobrescribir los datos del modelo original, de
manera que se puedan revertir.
16https://docs.blender.org/api/current/
17https://www.python.org/
18https://www.rhino3d.com/
P´agina 35
Figura 2.26: Modificador booleano de Blender.
dibujar la geometr´ıa autom´aticamente. Esta es otra forma de crear modelos param´etricos.
En la figura 2.27 se muestra un programa en Grasshopper en forma de diagrama y las
relaciones entre los nodos (derecha). A la izquierda se aprecia el modelo resultante en e
visor 3D de Rhinoceros [44].
Figura 2.27: Programa en Grasshopper.
P´agina 36
OpenJSCAD
OpenJSCAD19 est´a inspirado en OpenSCAD20 y esencialmente proporciona un en-
foque a programadores para desarrollar modelos mediante una interfaz web. El dise˜no
param´etrico se realiza mediante scripts en c´odigo JavaScript [45], utilizando funciones
CSG y otras un tanto especiales, proporcionadas por el mismo entorno. Permite incorpo-
rar par´ametros en la interfaz gr´afica, posibilitando al usuario cambiar los valores de forma
interactiva. Utiliza otras librer´ıas como base para cumplir con sus funcionalidades. Para
modelado booleano requiere de CSG.js21 y para la visualizaci´on de los modelos 3D utiliza
lightgl.js22 que facilita el desarrollo de aplicaciones WebGL, re-implementando la matriz
modelo-vista/proyecci´on23 (analizada en la secci´on 2.3.2) de OpenGL24.
En la figura 2.28 se puede ver a la izquierda el modelo 3D de un engranaje y los
campos con sus par´ametros. A la derecha se sit´ua el editor de texto con el programa
correspondiente escrito en JavaScript [46].
Figura 2.28: Interfaz de OpenJSCAD.
OnShape
OnShape25 (ver figura 2.29) [47] es una aplicaci´on CAD basada en la nube que puede
ser accedida desde cualquier navegador o mediante una aplicaci´on para m´oviles. Su do-
19http://openjscad.org/
20http://openscad.org/
21https://github.com/jscad/csg.js
22https://github.com/evanw/lightgl.js/
23http://www.opengl-tutorial.org/es/beginners-tutorials/tutorial- 3-matrices/
24https://www.opengl.org/
25https://www.onshape.com/
P´agina 37
minio esta fuertemente orientado al dise˜no mec´anico [48] con caracter´ısticas similares a
programas como SolidWorks26. Cuenta con un sistema de control de versiones27 para los
documentos del proyecto (dibujos, modelos 3D y documentos) y soporta la colaboraci´on
en tiempo real. La aproximaci´on de modelado es de manipulaci´on directa, sin embargo,
incluye un lenguaje de scripting que se denomina FeatureScript28 y permite la definici´on
de la geometr´ıa, relaciones y par´ametros para la construcci´on de modelos 3D Param´etricos
[12].
Figura 2.29: Interfaz de OnShape.
26https://www.solidworks.com/es
27Se llama control de versiones a la gesti´on de los diversos cambios que se realizan sobre los elementos
de alg´un producto o una configuraci´on del mismo
28https://cad.onshape.com/FsDoc/
P´agina 38
Cap´ıtulo 3
Desarrollo Colaborativo de
Productos CAD con Lean UX
En este cap´ıtulo se explican los conceptos que involucran el desarrollo de los sistemas
colaborativos y distribuidos para CAD y la metodolog´ıa Lean UX como una herramienta
de soporte para desarrollar un software con tales caracter´ısticas. Finalmente se describen
algunos ejemplos de aplicaciones CAD colaborativas y distribuidas disponibles en la web.
3.1. Introducci´on
La complejidad creciente de los productos hace necesaria la colaboraci´on entre dife-
rentes personas, habitualmente se generalizan en “cliente” y “dise˜nador” a las partes que
interact´uan, pero no necesariamente son una ´unica persona por cada parte, sino equipos
conformados por m´ultiples roles. Sus diferentes habilidades pueden abarcar el modelado
3D, la producci´on f´ısica con diferentes tecnolog´ıas (impresi´on 3D, corte a l´aser, control
num´erico, etc.), el marketing, etc.
Tradicionalmente, la interacci´on se produc´ıa entregando los planos a “contratistas” pa-
ra que construyan las distintas partes que integran un proyecto, los contactos se produc´ıan
de forma presencial y obligaban a frecuentes viajes para mantener el proyecto bajo control
[49]. Esta modalidad de trabajo se caracteriza por utilizar un modelo en cascada, que
ordena rigurosamente las etapas del ciclo de vida de un proyecto, de tal forma que el
inicio de cada etapa debe esperar a la finalizaci´on de la anterior [50]. Este modelo tiene
la ventaja de ser sencillo de comprender e implementar, ya que se sabe de antemano que
esperar del proyecto, con una estimaci´on precisa del costo y duraci´on. Sin embargo, una
vez que un producto se encuentra en la etapa de prueba o revisi´on, es muy dif´ıcil realizar
alg´un cambio por algo que no fue definido adecuadamente. De modo que el riesgo y la
incertidumbre son elevados en los proyectos donde los requerimientos cambian constan-
temente. Por otro lado, no se distingue en involucrar al usuario final o cliente durante el
proceso, si se solicita alg´un cambio no previsto, el proyecto se puede retrasar y salirse del
P´agina 39
presupuesto.
El avance de las tecnolog´ıas web ha democratizado la participaci´on en los procesos
de dise˜no en muchos niveles. Los tel´efonos inteligentes son un ejemplo de la tecnolog´ıa al
servicio de las personas, porque ofrecen oportunidades para la co-creaci´on mediante sus
aplicaciones [51]. En consecuencia, el rol del contratista tradicional ha cambiado y esto
implica que realice su trabajo en estrecha relaci´on con otros actores, en colaboraci´on y sin
necesidad del contacto presencial. En este nuevo escenario, la aparici´on de conceptos como
Desarrollo Colaborativo de Productos en ingl´es Collaborative Product Development
(CPD) [6] impulsan la participaci´on de ingenieros, dise˜nadores industriales, arquitectos,
programadores, artistas e incluso personas sin formaci´on espec´ıfica en procesos conocidos
como co-dise˜no odise˜no colaborativo.
3.2. Co-dise˜no
Se entiende como co-dise˜no al proceso de colaboraci´on creativa entre dise˜nadores y
otras personas, las cu´ales no poseen una formaci´on previa en dise˜no, con el prop´osito de
resolver problemas [7]. En esta definici´on se plantean dos elementos fundamentales que
dan soporte al paradigma colaborativo:
1. Nuevos perfiles: Al grupo habitual de trabajo se suman la iniciativa y la creatividad
de otros perfiles que antes aportaban ideas generalmente como agentes externos: el
investigador y el usuario final. Estos perfiles tienden a mezclarse: El usuario pasa a
jugar un rol de “experto en su experiencia” y puede aportar elementos de valor en
la generaci´on de conceptos e ideas en la etapa inicial del proyecto. El investigador,
a partir de la experiencia del usuario, puede recoger todos los datos y, a la vez,
desempe˜nar un papel fundamental en formalizar las ideas. L´ogicamente, una misma
persona puede cumplir m´as de un rol y el dise˜nador debe cambiar al incluir nuevos
“socios creativos” en un entorno que tradicionalmente le pertenec´ıa.
2. Objetivo en com´un: La idea del objetivo compartido se plantea como una de
las principales diferencias con respecto a los m´etodos tradicionales. Los m´etodos de
dise˜no generalmente se planteaban para ser llevados a cabo solamente por expertos
que realizaban tareas individuales y no era necesario compartir la visi´on del objetivo
general del proceso. En cambio, en un proyecto colaborativo este punto es fundamen-
tal: Para que el equipo funcione correctamente necesita tener la visi´on del objetivo
en com´un [51].
En la figura 3.1 se pueden apreciar las diferencias entre un esquema de dise˜no tradi-
cional vs co-dise˜no [52]. En el esquema de la izquierda (tradicional) los roles trabajan
por separado, el investigador aporta conocimientos para realizar la lista de requerimientos
de dise˜no, la interacci´on del dise˜nador (contratista) con el usuario es a trav´es de dicha
P´agina 40
lista. De esa manera el dise˜nador trabaja en base a los requerimientos y una vez finalizado
todo el trabajo reci´en se efect´ua la entrega.
Por otra parte, en el esquema de la derecha (co-dise˜no) el usuario participa durante
todo el proceso de dise˜no a trav´es de la interacci´on directa con todo el equipo, en este
ejemplo, el contratista cumple el rol de dise˜nador e investigador. La interacci´on se realiza
mediante las herramientas inherentes a cada proyecto, que pueden ser diagramas, refe-
rencias, artefactos, m´etodos y/o t´ecnicas. En lugar de establecer los requerimientos, se
plantean las necesidades de dise˜no y las entregas del trabajo se realizan progresivamente
mediante la revisi´on continua del producto por parte de todos los participantes.
Figura 3.1: Dise˜no tradicional vs co-dise˜no.
La diversidad de profesiones en el co-dise˜no trae como consecuencia que los actores
difieran tanto en la forma de interpretar el dise˜no como en la forma de comunicarlo. Ge-
neralmente la comunicaci´on est´a cargada de jerga propia de cada especialidad y por lo
tanto, es dif´ıcil de comprender para los dem´as participantes. Aun as´ı, si se comprendieran
las palabras, el significado de las mismas puede diferir seg´un la disciplina. Un ejemplo de
palabra con muchos significados es “concepto”, la figura 3.2 muestra c´omo los actores de
diferentes especialidades interpretan de diferente manera la misma palabra en el ambito
de la industria automotriz: a) Para un dise˜nador son los dibujos r´apidos, bosquejos o sket-
ches. b) Un fabricante de prototipos lo materializa en modelos de arcilla u otro material
que permita visualizar r´apidamente los detalles del producto, incluso en escala real. c)
Para un publicista es la representaci´on digital o render del producto final. d) Un ingeniero
mec´anico lo entiende en los documentos t´ecnicos, planos y especificaciones. [53]
En consecuencia, si no se crea un entendimiento compartido sobre el contenido del
dise˜no, se dificulta la colaboraci´on.
P´agina 41
Figura 3.2: Interpretaci´on de la palabra “concepto”seg´un especialistas de la industria automotriz.
Dise˜no Iterativo
La etapa de revisi´on de los dise˜nos es fundamental porque permite evaluar la capaci-
dad de los resultados para cumplir los requisitos del cliente, identificar cualquier problema
y proponer soluciones [54].
Lo m´as habitual es registrar los resultados de las revisiones en actas de reuni´on o bien
en alg´un formato que se haya establecido espec´ıficamente para el control. Estas tareas
parecieran ser anticuadas en t´erminos administrativos, si no se considera que dise˜nar un
objeto tangible implica tener un entendimiento completo de todo lo que se debe hacer
antes de iniciar la producci´on f´ısica, porque esta generalmente es compleja comparada
con la producci´on de bienes intangibles. Por lo que la necesidad de la revisi´on constante
y la tendencia creciente a requerimientos que pueden cambiar, ponen en evidencia las
limitaciones del modelo en cascada. Como soluci´on surgieron los modelos iterativos
que promueven una iteraci´on continua sobre el producto y pruebas a lo largo de todo el
proyecto [55].
El dise˜no iterativo en ingl´es Iterative Design es una metodolog´ıa de dise˜no basada en
un proceso c´ıclico de creaci´on de prototipos1y pruebas, para analizar y refinar un trabajo
que se encuentra en progreso. La interacci´on con el dise˜no se utiliza como una herramien-
ta de investigaci´on para recolectar informaci´on y desarrollar el proyecto, implementando
1Un prototipo es un ejemplar o primer molde en que se fabrica una figura u otra cosa.
P´agina 42
iteraciones o versiones sucesivas. La prueba, el an´alisis, el refinamiento y la repetici´on
son necesarios porque la experiencia del usuario no se puede predecir por completo. Las
decisiones se basan en la experimentaci´on con el prototipo, de esta manera el proyecto se
desarrolla a trav´es de un continuo di´alogo entre los dise˜nadores, el dise˜no y el usuario.
En un nivel superficial, el dise˜no iterativo difiere del modelo de cascada de una sola
manera: en lugar de especificar todo el sistema completo antes de desarrollarlo, se dise˜na y
construye completamente una parte del mismo, y luego se utiliza esa parte y las unidades
completadas previamente como base para m´as dise˜nos y m´as producci´on futura. En otras
palabras, iterar es dise˜nar y, espec´ıficamente, es comprender el dise˜no en el momento
que se construye el dise˜no [56].
En este punto es necesario hacer una aclaraci´on respecto a otro concepto con el que se
suele confundir: el dise˜no incremental que tiene como objetivo un crecimiento progresivo
de la funcionalidad. Es decir, el producto va evolucionando con cada una de las entregas
hasta que se adapta a lo requerido por el cliente. Alistair Cockburn describe al enfoque
iterativo como “aprender al completar” y lo distingue del dise˜no incremental en el sentido
que ´este consiste en agregar nuevos elementos, incluso de forma iterativa, mientras que
iterar trata sobre volver a trabajar y refinar [57]. En ocasiones el concepto de iteraci´on se
puede perder al reemplazarlo por incrementos, lo que provoca que el proyecto tenga las
mismas consecuencias que los en cascada. Jeff Patton, utilizando visualmente el cuadro
de la Mona Lisa (ver figura 3.3) para explicar la diferencia entre los dos m´etodos [58].
En el incremental (arriba) se agregan nuevos elementos a partir de una idea completa
preconcebida del producto. En el iterativo (abajo) se parte de una idea vaga, ejemplo:
“Una mujer en un ambiente campestre”. De forma iterativa se comienza a trabajar sobre
una versi´on m´ınima del producto, refinando en cada ciclo hasta llegar a la soluci´on. Lo
m´as destacado del m´etodo iterativo es el siguiente principio subyacente: Hasta que se no
se haya construido realmente lo que se est´a dise˜nando, no se podr´a comprender en su
totalidad.
El concepto de iterativo se ha extendido con ´exito a otras ´areas como las metodolog´ıas
Agile [57]. Por ejemplo, el marco de desarrollo SCRUM[59] introduce el concepto de 2para
referirse a la iteraci´on.
Riesgo de la metodolog´ıa en cascada frente a las iterativas
En este contexto, el riesgo se refiere a los factores que contribuyen al ´exito o fracaso de
un proyecto. Todos los proyectos tienen alg´un riesgo, independientemente de su enfoque.
En algunas situaciones, los factores inesperados que impactan positivamente el proyecto
tambi´en son riesgos, pero se consideran oportunidades. Una regla que se aplica siempre es
que los riesgos negativos deben detectarse y mitigarse [60].
2Un Sprint, es un intervalo prefijado durante el cual se crea un incremento de producto “Hecho o
Terminado” utilizable, potencialmente entregable
P´agina 43
Figura 3.3: Dise˜no incremental vs iterativo.
En la metodolog´ıa en cascada existen una serie de factores negativos, propios de su
estructura secuencial. Un caso se puede analizar en la parte superior de la figura 3.4 un
modelo en cascada con las etapas definir, construir, testear y lanzar para el desarrollo de
un producto. Testear (probar) el producto justo antes del lanzamiento significa que si se
presentan problemas en esa instancia se pone en riesgo todo el proyecto, la curva de riesgo
incrementa notablemente justo al final de proyecto, en el lanzamiento. Por otro lado, en
la parte inferior (ver figura 3.4) se aprecia un modelo iterativo (Agile) con las mismas
etapas definidas en todas las iteraciones. Si una decisi´on t´ecnica, un requisito o incluso
un producto completo no es factible, el equipo descubre esto en poco tiempo, por ende se
cuenta con m´as tiempo para realizar correcciones. Si la correcci´on no es posible, de todas
maneras el riesgo por el proyecto fallido es menor que con el enfoque en cascada [61].
Son evidentes las ventajas de la iteraci´on y esto ha promovido que los nuevos produc-
tos se lancen a un ritmo creciente. Adicionalmente, tanto el hardware como el software
evolucionaron para admitir la comunicaci´on y el acceso multiusuario a los datos de dise˜no,
la forma de acceso var´ıa desde archivos compartidos hasta accesos compartidos mediante
Sistemas de Gesti´on de Bases de Datos en ingl´es Data Base Management System
(DBMS) [62].
Las aplicaciones CAD colaborativas se pueden identificar mediante una matriz (ver
figura 3.5) seg´un su forma de uso en el tiempo y espacio [63]. A continuaci´on se analiza
las diferentes configuraciones de la matriz.
1. En el mismo sitio y al mismo tiempo es posible con una interfaz para un so-
lo usuario, los dise˜nadores pueden compartir la misma computadora si necesitan
colaborar.
2. En el mismo sitio pero en tiempos diferentes es posible gracias a la gesti´on
de datos t´ecnicos, de manera que est´en disponibles para la misma persona u otros
P´agina 44
Figura 3.4: Riesgo de un proyecto en cascada vs iterativo (Agile).
miembros del equipo luego de que el dise˜no se completa.
3. Al mismo tiempo en sitios diferentes se denomina CAD colaborativo o bien
Co-Dise˜no, diferentes dise˜nadores pueden ver y modificar el dise˜no en diferentes
ubicaciones, viendo la misma imagen en la pantalla y comunic´andose entre s´ı.
4. En sitios diferentes en tiempos diferentes por consecuencia de la distribuci´on
de datos del dise˜no a trav´es de una red (CAD distribuido), permitiendo a los
actores acceder a los dise˜nos independientemente de su ubicaci´on y disponibilidad.
La colaboraci´on implica que el soporte inform´atico (sistemas CAD) debe proporcionar
flexibilidad en la comunicaci´on de datos e ideas, considerando que el dise˜no colaborativo
involucra muchos tipos de conocimiento de diferentes dominios. A continuaci´on se analiza
la forma en que los sistemas soportan estos paradigmas.
3.3. Sistemas CAD colaborativos
El contenido compartido en los ambientes de dise˜no colaborativo y distribuido
por lo general implica el uso de modelos 3D como medio de comunicaci´on entre los
participantes con el fin de visualizar ideas abstractas y se usan iterativamente durante todo
el proceso de dise˜no [64]. Los participantes requieren diferentes vistas del dise˜no, pueden
tener intereses diferentes respecto a las soluciones y su representaci´on asociada. De manera
que, se necesitan m´ultiples niveles de abstracci´on en t´erminos de soporte inform´atico para
gestionar la diversidad de conocimiento.
P´agina 45
Figura 3.5: El uso del CAD en el espacio y tiempo
3.3.1. Soporte inform´atico a la colaboraci´on
La colaboraci´on se puede lograr mediante un Espacio de Traba jo Compartido en
ingl´es Shared Workspace (ver figura 3.6). Este proporciona una comunicaci´on visual y fun-
ciona como un medio en el que un actor puede comprender el modelo/dise˜no de otro sin
necesidad de tener el mismo vocabulario [65]. Un espacio de trabajo compartido CAD se
puede dividir en dos significados: El espacio de trabajo con el que los participantes hu-
manos visualizan el dise˜no e interact´uan y la representaci´on compartida del problema de
dise˜no que utiliza la propia computadora para la persistencia y la comunicaci´on entre pro-
cesos. Por ende se consideran dos categor´ıas de representaciones en el espacio de trabajo:
Representaci´on visual compartida y Representaci´on subyacente compartida. Esto
proviene de los requisitos de los sistemas multiusuario, en el que los usuarios puedan ver
el trabajo de los dem´as. La parte visual es proporcionada por los modelos 3D y adem´as
con la posibilidad que el sistema mantenga una o m´as representaciones de la soluci´on de
dise˜no (versiones). Cualquier otro conocimiento de dominio relevante es proporcionado por
el contenido subyacente, por ejemplo: referencias, documentaci´on t´ecnica, archivos extra
para interactuar con otros sistemas, etc.
Figura 3.6: Representaciones en un espacio de trabajo compartido.
P´agina 46
Aparte de la implementaci´on de un espacio compartido, resolver problemas como el
modelado no es una tarea trivial para los sistemas y se necesita de una infraestructura y
componentes con determinadas caracter´ısticas. A continuaci´on se explican los sistemas de
modelado s´olido.
3.3.2. Sistemas de Modelado S´olido
En la creaci´on de un sistema de modelado de s´olidos o “modelador s´olido” se de-
ben considerar las condiciones geom´etricas y topol´ogicas explicadas en la secci´on 2.3.
M¨antyl¨a expone que la idea fundamental es separar el modelo geom´etrico de la aplicaci´on
y desarrollar t´ecnicas de modelado que sean independientes de los objetos [66]. Los pasos
a dar se ilustran en la figura 3.3.2 y pueden resumir de la siguiente manera:
Inicialmente, los objetos son descritos por el usuario mediante un lenguaje de des-
cripci´on, basados en los conceptos de modelado (poligonal, booleano, etc) aplicados
al sistema. Se introducen utilizando scripting, con lenguajes como OpenSCAD o Pyt-
hon3, o bien mediante una interfaz de usuario para interactuar gr´aficamente. Un
mismo sistema puede incluir varios lenguajes de descripci´on, atendiendo a diferentes
usuarios y aplicaciones.
Una vez introducidos, los objetos son traducidos para crear la representaci´on in-
terna almacenada por el modelador. La relaci´on entre el lenguaje de descripci´on y
la representaci´on interna no necesariamente debe de ser directa: las representaciones
internas pueden emplear conceptos de modelado distintos a la descripci´on original.
La transformaci´on del lenguaje de descripci´on a la representaci´on interna es necesa-
ria para poder encontrar las respuestas a las preguntas geom´etricas. De hecho, para
que un sistema de modelado sea eficiente, debe soportar m´ultiples representaciones
internas de los objetos, por ejemplo con diferentes tecnolog´ıas para geometr´ıas como
CGCAL4uOpen-Cascade5. Por lo tanto, se deben incluir algoritmos de conversi´on
que puedan modificar una representaci´on en otra.
Para comunicarse con otros sistemas de modelado (importaci´on/exportaci´on) el mo-
delador debe proveer interfaces de comunicaci´on. Estas interfaces son utilizadas para
recibir o transmitir modelos hacia o desde otros sistemas de modelado. Necesaria-
mente debe manejar informaci´on geom´etrica utilizando formatos existentes como por
ejemplo STEP acr´onimo de Standard for the Exchange of Product Data [67]oSTL
acr´onimo de Stereolithography [68].
3http://python.org
4https://www.cgal.org/
5https://www.opencascade.com/content/latest-release
P´agina 47
Finalmente, el modelador tambi´en debe incluir facilidades para almacenar las des-
cripci´on de objetos y dem´as datos, en bases de datos permanentes.
Figura 3.7: Sistema de Modelado S´olido.
En estos sistemas se pueden distinguir tres niveles de abstracci´on:
1. Interfaz de usuario. Mediante el lenguaje de descripci´on, el usuario utiliza las ope-
raciones disponibles en cualquier aplicaci´on CAD (crear, modificar, guardar, borrar
y analizar dise˜nos).
2. Infraestructura matem´atica y algor´ıtmica. Implementa las operaciones que
proporciona el nivel anterior (por ejemplo, los algoritmos CSG para trabajar con
objetos mediante operaciones booleanas).
3. Primitivas. A nivel de sistema, son operaciones aritm´eticas y l´ogicas que describen
los objetos primitivos. Se encuentran disponibles de forma permanente en bases de
datos para que puedan ser utilizadas por el nivel anterior.
Dentro de la complejidad de un modelador es indispensable que los datos de los produc-
tos sean accesibles y carezcan de errores. Para lograrlo se utilizan los sistemas de Gesti´on
de Datos del Producto en ingl´es Product Data Management (PDM) [49] los cu´ales se
explican a continuaci´on.
3.3.3. Gesti´on de Datos del Producto (PDM)
Max Ungerer define que un sistema PDM es “algo” que maneja datos sobre productos.
En el n´ucleo central de la informaci´on est´a la identificaci´on del producto y se representa
conceptualmente como un elemento o ´ıtem dentro del sistema [69].
Para garantizar la colaboraci´on distribuida, los PDM tradicionales tienen los mismos
problemas que las aplicaciones de escritorio:
1. Es dif´ıcil proporcionar acceso a los usuarios desde diferentes ubicaciones, especial-
mente aquellos que se encuentran en diferentes redes. En cada implementaci´on del
PDM, las configuraciones de red deben ser homog´eneas.
P´agina 48
2. Las aplicaciones cliente6son dependientes de la plataforma, todos los usuarios deben
usar la misma plataforma inform´atica o bien se debe proporcionar una aplicaci´on
espec´ıfica para cada plataforma de usuario. Actualmente, es casi imposible este man-
dato por la diversidad de sistemas y dispositivos.
3. Las tareas de ampliaci´on y actualizaci´on no son sencillas, cuando se requieren nuevas
funciones, los usuarios deben volver a instalar o actualizar la aplicaci´on completa-
mente.
En consecuencia, es l´ogico utilizar un PDM basado en la web en ingl´es Web based
Product Data Management (WPDM) [70] porque pueden ofrecer soluciones centradas en
la l´ogica de negocio de las empresas y proporcionar una comunicaci´on global sin mucho
esfuerzo, brindando funciones independientes de las redes y la plataforma. Esto se traduce
en una reducci´on del costo general para la implementaci´on. Un WPDM eficiente requiere:
Ser totalmente escalable para proporcionar flexibilidad, porque cada organizaci´on
tiene diferentes prioridades y diferentes flujos de trabajo.
Ser sencillo de usar por todos los participantes.
Tener una arquitectura abierta para que se permite a˜nadir, modernizar y cambiar
sus componentes sin depender de un proveedor.
Estar disponible en una amplia variedad de plataformas y proveer funciones en redes
heterog´eneas.
La mayor´ıa de los sistemas WPDM que se han implementado con ´exito hacen uso de
Servicios Web en ingl´es Web Services [71].
3.3.4. Intercambio de datos CAD
En el pasado, el proceso de intercambio de datos estaba relacionado con los planos
y los documentos t´ecnicos, actualmente se requieren archivos digitales compartidos entre
m´ultiples aplicaciones. Los esfuerzos hacia la integraci´on del CAD generaron el desarrollo
de varios formatos est´andares para el Intercambio de Datos de CAD en ingl´es CAD
Data Exchange [72], as´ı como muchos “no est´andares”. Los formatos han variado desde
archivos para datos de dibujo t´ecnico como DXF7hasta representaciones de modelos 3D
como STEP [67].
En lo ´ambitos de fabricaci´on digital el CAD Data Exchange es la norma, a pesar de
que cada sistema tiene su propio formatos de datos. As´ı, la misma informaci´on puede ser
ingresada varias veces en diferente sistemas, provocando redundancia. Adem´as, el uso de
6El cliente es una aplicaci´on inform´atica que consume un servicio remoto
7https://es.wikipedia.org/wiki/DXF
P´agina 49
modelos 3D de geometr´ıa compleja puede provocar errores en los datos de dise˜no, con
representaciones incorrectas y falta de entendimiento entre los actores. Respecto a esta
problem´atica, desde el a˜no 1999 el Instituto Nacional de Est´andares de EE.UU. (NIST)8
estima que la incompatibilidad de datos se traduce en costos que alcanzan los 90 millones
de d´olares por a˜no [73].
En conclusi´on, el CAD Data Exchange es fundamental en el contexto actual del mo-
delado geom´etrico, ya que es el mecanismo principal para lograr interoperabilidad la entre
las diferentes plataformas.
Data Exchange Geom´etrico
El enfoque establecido para el intercambio de datos se denomina Data Exchange de
la geometr´ıa oDE geom´etrico [74], en este la representaci´on del objeto se transfiere de
un sistema origen a un sistema de destino. En las aplicaciones comerciales se implementan
a trav´es de los formatos neutrales que pueden ser generados y le´ıdos en la mayor´ıa de los
sistema CAD. Algunos ejemplos de ellos son STEP y STL, acr´onimo de STereoLithography
[68].
STEP interpreta un producto como uno o varios documentos. Utiliza grupos de con-
ceptos para organizar los elementos de manera l´ogica y as´ı generar una estructura clara y
comprensible para todas las plataformas. Su estructura depende de la direcci´on que tome
el sistema PDM, sus protocolos de aplicaci´on y su alcance.
Por su parte, los archivos STL describen la geometr´ıa de un objeto 3D mediante
tri´angulos, sin considerar la representaci´on de color, textura u otros atributos. Se pue-
den especificar tanto en ASCII como en binario y se caracterizan por ser ampliamente
utilizados para fabricaci´on digital.
El uso del DE geom´etrico con formatos neutrales o nativos es bastante confiable, aun-
que muchas veces es posible obtener resultados de modelos no s´olidos debido a la perdida
de informaci´on de sus estructuras. No obstante, su principal inconveniente no es la incon-
sistencia geom´etrica, sino el hecho de que no es compatible con el paradigma de dise˜no m´as
com´un de la actualidad: el dise˜no basado en caracter´ısticas en ingl´es Feature Based
(FB), tambi´en llamado dise˜no param´etrico odise˜no basado en la historia como se
explica en la secci´on 2.2. Por esa raz´on es imposible realizar modificaciones de los mode-
los en el lado del sistema destino. Esta situaci´on se puede ver ilustrada en el ejemplo de
la figura 3.8. El usuario en el sistema origen (izquierda) puede visualizar y modificar el
modelo para compartir con el sistema destino mediante un archivo en formato STEP que
incluye los datos geom´etricos. Por otra parte el usuario en el sistema destino (derecha)
puede visualizar el modelo pero no modificarlo, puesto que solamente tiene acceso a los
datos geom´etricos, pero no a los par´ametros necesarios para alterar la representaci´on.
8https://www.nist.gov/
P´agina 50
Figura 3.8: Esquema de Data Exchange Geom´etrico.
De esta limitaci´on surge el Intercambio de Datos Basado en Caracter´ısticas en
ingl´es Feature Based Data Exchange (FBDE) [74].
Data Exchange basado en caracter´ısticas (FBDE)
En el FBDE, dado un grafo o estructura basada en el historial param´etrico de un mo-
delo (caracter´ısticas) en un sistema origen, el objetivo es construir un grafo en un sistema
destino con una geometr´ıa similar, conservando al mismo tiempo la mayor informaci´on
param´etrica posible. En muchos casos, la geometr´ıa puede no ser id´entica debido a dife-
rentes pol´ıticas de tolerancia entre los sistemas CAD. Siempre que la aproximaci´on est´e
controlada es totalmente aceptable en la pr´actica.
El FBDE conserva la inteligencia del dise˜no, permitiendo que se realicen modificaciones
en el lado del sistema destino (ver figura 3.9). El usuario en el sistema origen (izquierda)
puede visualizar y modificar el modelo. La compartici´on del modelo se realiza mediante un
formato o tipo de fichero que contiene los datos geom´etricos y tambi´en expone las carac-
ter´ısticas del modelo mediante los par´ametros. En el sistema destino (derecha) se puede
visualizar y manipular el modelo debido a que posee los datos geom´etricos y param´etricos
para modificar la representaci´on.
Figura 3.9: Esquema de Data Exchange basado en caracter´ısticas (FBDE).
Adicionalmente, el sistema debe contar con mecanismos para evitar o reparar proble-
mas de inconsistencias geom´etricas en los archivos de intercambio.
El modelo se suele representar como un ´arbol o lista de operaciones, com´unmente
llamado ´arbol de historia. Las operaciones crean una nueva geometr´ıa o modifican una
existente. Esta estructura se puede considerar una extensi´on de la geometr´ıa constructiva
P´agina 51
de s´olidos (CSG) explicada en la secci´on 2.3.3. El punto principal de este paradigma es
que las operaciones son siempre de naturaleza param´etrica.
En la figura 3.10 se ilustra un ejemplo con las diferentes versiones de un modelo mec´ani-
co (derecha) y su representaci´on como ´arbol de historia (FBDE) (izquierda). Las versiones
se producen a partir de las operaciones o modificaciones de los par´ametros, desde un mo-
delo original hasta un modelo objetivo. En cada nivel del ´arbol se pueden ver las
operaciones realizadas. Partiendo del modelo original, para obtener la Versi´on #1 se mo-
difica el par´ametro cilindros B = 0 acilindros B = 8 de manera que se agregan 8 cilindros.
Esta operaci´on genera una separaci´on entre la pieza y los cilindros, produciendo un objeto
“no s´olido”. La Versi´on #2 soluciona este problema, convirtiendo al objeto nuevamente
en s´olido con la modificaci´on de la variable cilindros A = 8 y su correspondiente incorpo-
raci´on de 8 cilindros de base. Finalmente a la Versi´on #2 se aplica un operador booleano
de intersecci´on entre el modelo y un cilindro, generando un orificio en el modelo objetivo
[75].
Figura 3.10: Modelo mec´anico y su representaci´on como ´arbol de historia (FBDE).
Por lo anteriormente expuesto, es deseable un sistema de CAD distribuido que
permita el co-dise˜no de productos orientados a la fabricaci´on digital, este debe tener
capacidades para la gesti´on de datos de productos basados en la web (WPDM) y soporte
al intercambio de datos basados en caracter´ısticas (FBDE).
Para que el desarrollo del sistema est´e en sinton´ıa con los principios colaborativos
planteados, se pueden utilizar metodolog´ıas o enfoques orientados a la experiencia de
usuario (UX) como Lean UX.
P´agina 52
3.4. Lean UX
Los equipos de desarrollo de software son un ejemplo de eficiencia en la colaboraci´on,
utilizan t´ecnicas de desarrollo ´agil [57], reduciendo dr´asticamente el tiempo que requiere
modificar una aplicaci´on, realizan cambios en el c´odigo y lo llevan a producci´on9a una
velocidad similar a la de guardar un archivo en un ordenador. Adem´as, utilizan mecanismos
para iterar incorporando lo que han aprendido y tal vez, sin advertirlo, aumentan las
expectativas de los usuarios. GitHub10 es un caso de ´exito como plataforma de trabajo
colaborativo, convirti´endose en la herramienta de gesti´on de c´odigo m´as utilizada en la
actualidad [76]. En este nuevo contexto, las pr´acticas de analizar todo el proyecto al inicio
quedaron obsoletas.
Lean User Experience (Lean UX) [13] es una metodolog´ıa que utiliza las herramien-
tas disponibles y las combina de forma diferente para adecuarlas a esta nueva realidad.
Jeff Gothelf y Josh Seiden la describen como una nueva etapa evolutiva en el dise˜no de
productos . Se considera profundamente colaborativa y multidisciplinaria, en gran medi-
da porque permite implementar t´ecnicas para construir una comprensi´on compartida del
proyecto, logra un ambiente propicio para el feedback con los usuarios finales, replantea
las conversaciones de dise˜no en t´erminos objetivos y cambia la forma en que se comunica
el dise˜no del producto: en lugar de hablar de funciones y documentos, se habla de lo que
efectivamente funciona y de lo que no.
Los 3 pilares principales de Lean UX son:
1. Design Thinking o Pensamiento de Dise˜no
El Design Thinking [77] logra obtener soluciones involucrando a los usuarios para
convertirlos en actores activos en todo el proceso de la construcci´on del producto. Es
una manera de trabajar que alienta la colaboraci´on del equipo, independientemente
del rol que cada actor desempe˜ne. Centra su eficacia en entender y dar soluci´on a
las necesidades reales de los usuarios.
2. Metodolog´ıas de desarrollo ´agil de software.
Los desarrolladores de software las han usado durante mucho tiempo. No obstante,
estas constituyen un reto para los dise˜nadores. Lean UX aplica los 4 principios
b´asicos del desarrollo ´agil al dise˜no de productos [13] :
a)Los individuos y las interacciones son m´as importantes que los proce-
sos y las herramientas: Para generar r´apido las mejores soluciones, se debe
implicar a todo el equipo. La comunicaci´on fluida debe primar por encima de
las restricciones propias de las herramientas.
9Producci´on es la instancia del software cuando se encuentra a disposici´on de los usuarios finales.
10https://github.com/
P´agina 53
b)El software funcional es m´as importante que la documentaci´on ex-
haustiva: Un software que funcione es m´as importante que preocuparse por una
documentaci´on exhaustiva. De esta manera, se puede encontrar de antemano
la soluci´on que mejor se adapte a las necesidades.
c)La colaboraci´on con los clientes es m´as importante que la negociaci´on
de contratos con ellos: Si el equipo colabora con los usuarios/clientes, hay un
entendimiento com´un sobre los problemas y las posibles soluciones. Cualquier
decisi´on se debe tomar por consenso, esto se traduce en iteraciones m´as r´apidas
y una verdadera implicaci´on de todos los actores con la ventaja de trabajar
siempre con soluciones validadas.
d)La respuesta a los cambios es m´as importante que la planificaci´on:
Se asume que el equipo no encontrar´a la soluci´on la primera vez, por lo que el
objetivo consiste en averiguar en que se ha fallado. Luego se pueden ajustar las
propuestas y volver a probarlas iterativamente.
3. M´etodo Lean Startup
Los proyectos han estado enmarcados, tradicionalmente, por los requerimientos y
las entregas. A los equipos se les suministraban requerimientos para que produjeran
entregas. No se inicia a partir de requerimientos, sino de suposiciones. A partir de
ellas, se crean y prueban hip´otesis o una manera de expresar las suposiciones que
se tienen del proyecto de una forma comprobable [13].
Lean Startup [78] utiliza un ciclo de feedback denominado “construir-medir-aprender”
que minimiza el riesgo de los proyectos y consigue que el equipo pueda desarrollar
software y aprenda de ´el en muy poco tiempo (ver figura 3.11). Consiste en poner
en marcha (construir) las ideas que se suponen van a tener ´exito, medir y recabar
los datos para confirmar o desmentir las hip´otesis que se plantearon al principio y
aprender del fracaso o el ´exito resultante. En el centro de la figura se aprecia la
interacci´on entre las ideas, el producto construido (PMV) y los datos recabados [79].
Figura 3.11: Ciclo Construir-Medir-Aprender.
P´agina 54
De esta manera, los equipos pueden desarrollar de inmediato los denominados Pro-
ductos M´ınimos Viables (PMV) en ingl´es Minimum Viable Products (MVP) [80].
El ciclo se desarrolla de la siguiente manera:
En primer lugar, se construye un PMV, es decir, el desarrollo m´as peque˜no
que pueda construirse para probar cada hip´otesis. Se debe tener en
cuenta que tanto el PMV inicial como las siguientes iteraciones deben tener
valor por s´ı mismas. Es decir, se debe obtener un feedback del usuario final.
Para esto, el producto debe tener el mismo tratamiento utilizado en el dise˜no
iterativo. Para un mejor entendimiento de este punto, se puede analizar la figura
3.3 explicada en la secci´on 3.2.
El siguiente paso es entregar el PMV a los usuarios y realizar experimentos que
puedan ser medidos para obtener datos.
Despu´es, se utiliza lo aprendido con ellos para evaluar las hip´otesis y hacer las
modificaciones pertinentes.
Y finalmente se itera, se comienza todo el proceso nuevamente.
Proceso Lean UX
El objetivo final es trasladar todos los valores heredados de los 3 pilares al trabajo de
experiencia de usuario mediante un conjunto de pasos definidos, m´etodos y herramientas
que se analizan a continuaci´on.
Figura 3.12: Proceso Lean UX.
Declaraci´on de suposiciones
Antes de cualquier declaraci´on, se realiza una exploraci´on recurriendo a t´ecnicas de in-
vestigaci´on en ingl´es research [81] sobre los usuarios y sus necesidades. Estas declaraciones
se componen de los siguientes elementos:
P´agina 55
Suposiciones: una declaraci´on de alto nivel que se considera cierta. El primer paso
en Lean UX es declarar las suposiciones (ver figura 3.12), este ejercicio se realiza en
equipo, asegur´andose de que todas las disciplinas est´en representadas. Con toda la
informaci´on recolectada se contin´ua con la declaraci´on del problema.
M´etodo: Declaraci´on de problema
Permite centrar correctamente el trabajo de todo el equipo y define las restricciones
y l´ımites necesarios para que no se pierda de vista el objetivo. Se puede utilizar
la siguiente plantilla: [El servicio/producto] debe cumplir con [estos objetivos]. Sin
embargo, se ha observado que no se est´an alcanzando [estos objetivos], lo que est´a
causando [este efecto adverso] para los usuarios. ¿C´omo se podr´ıa mejorar el [servi-
cio/producto] de modo que los usuarios consigan mejorar sus resultado seg´un [estos
criterios cuantificables o cualificables]?
Generalmente las declaraciones est´a repletas de suposiciones, para extraerlas se uti-
liza una lista u hoja de suposiciones.
En base a las siguientes preguntas, se recopilan las declaraciones que reflejen lo que
el equipo de desarrollo considere cierto respecto a la soluci´on o producto. ¿Qui´enes
son los usuarios del producto? ¿C´omo encaja en su trabajo? ¿Qu´e proble-
mas soluciona? ¿Cu´ales son sus funciones m´as importantes? ¿Qu´e aspecto
debe tener y c´omo debe comportarse?
Si existen diferencias en un punto, lo mejor es reflejar esto de inmediato para facilitar
la discusi´on entre los miembros del equipo de desarrollo. Una vez obtenida la lista
de suposiciones priorizada, es necesario probarlas.
Hip´otesis: descripciones m´as detalladas de las suposiciones, dirigidas a ´areas es-
pec´ıficas del producto o flujos de trabajo con las que se puede experimentar. Es
decir, se transforman las suposiciones a un formato m´as sencillo de probar. Sin em-
bargo, las hip´otesis suelen ser demasiado extensas para que, con una ´unica prueba,
se pueda determinarse su validez. Contiene demasiadas partes, es decir, demasiadas
“sub-hip´otesis”. Para registrar estas partes m´as peque˜nas y espec´ıficas se utiliza la
siguiente plantilla:
Se considera que [haciendo esto, desarrollando esta funci´on, creando esta experiencia
de usuario] para [estas personas] se conseguir´a [este resultado]. Se sabr´a si esto es
correcto cuando se obtenga [esta medida cuantitativa, o este conocimiento cualitati-
vo].
El primer campo se completa con la funci´on o mejora para el producto. El segundo
describe exactamente qu´e usuarios objetivo se beneficiar´an de la funci´on. El ´ultimo,
especifica los beneficios que esos usuarios obtendr´an de ella. La frase final lo une
todo. Esta frase determina si la hip´otesis es cierta o no.
P´agina 56
Resultados: los datos de entrada, proveniente de la experiencia de los usuarios, que
ayudan a validar o invalidar las hip´otesis. Pueden ser cuantitativos o cualitativos. En
principio se encuentran con resultados de alto nivel o generales. Se debe considerar
c´omo dividir esos resultados en componentes m´as peque˜nos, espec´ıficos y cercanos
a la realidad del proyecto. ¿Qu´e funciones en la UI podr´ıan generar un mayor uso?
¿Un visor 3D totalmente funcional o simplemente compartiendo im´agenes? Mediante
estas preguntas, se enuncian resultados que se acercan a las necesidades reales del
proyecto. Ejemplo: Dar soporte a la visualizaci´on de modelos 3D en la web.
Personas: son modelos o arquetipos [13] de los potenciales usuarios para las que se
considera estar resolviendo el problema. Detallan qui´en utilizar´a el producto y por
qu´e lo har´a. Se inicia con esquema muy sencillo, en cuya creaci´on participa todo el
equipo. A medida que se avanza en la investigaci´on se pueden realizar ajustes.
Funciones o funcionalidades: son las t´ecnicas, las funciones, los productos y los
servicios a desarrollar para conseguir los resultados. Normalmente, en este punto
todos los miembros del equipo tienen su propia opini´on, ya que, despu´es de todo, las
funciones son lo m´as concreto con lo que trabajan y les resulta m´as sencillo expresar
sus ideas en t´erminos de funciones. Sin embargo, un error com´un es hacer que el
proceso de dise˜no parta de las funciones.
Con todo el material obtenido se organizan las sub-hip´otesis que deben probarse en
una tabla de sub-hip´otesis. La tabla se organiza con el siguiente formato: Funci´on
/ Persona / Resultado.
Dise˜no Colaborativo
Con la tabla de sub-hip´otesis como gu´ıa se re´une a dise˜nadores y no dise˜nadores
(programadores, administradores de proyectos) para crear los conceptos del producto , y
un entendimiento com´un sobre el problema y las soluciones de dise˜no. Asimismo, permite
decidir qu´e elementos de la interfaz gr´afica implementan mejor las funciones recogidas en
las hip´otesis. A continuaci´on se describen dos herramientas utilizadas para el dise˜no de
interfaces.
Estudio de dise˜no:Un equipo interdisciplinario se re´une en una sesi´on de trabajo
oEstudio de Dise˜no (a veces tambi´en llamado Charrette de dise˜no)[13]. Permite
explorar y analizar qu´e elementos de la interfaz gr´afica pueden implementar mejor
las funciones recogidas en las hip´otesis. La documentaci´on de salida de las sesiones
constan normalmente de esquemas de baja fidelidad en ingl´es sketch (ver figura
4.2). Es esencial que la documentaci´on no sea muy elaborada para que el trabajo
contin´ue siendo maleable. De esta manera, el equipo puede cambiar de direcci´on con
facilidad si las pruebas demuestran que el enfoque adoptado no es el correcto.
P´agina 57
Gu´ıa de estilo: En base a la documentaci´on resultante del estudio de dise˜no se
desarrolla la gu´ıa de estilo, una biblioteca de patrones aceptada por todo el equipo,
para codificar los elementos gr´aficos e interactivos de la interfaz de usuario. Tambi´en
sirve para recopilar los componentes web en ingl´es Web Component11 del producto,
todo lo que forme parte de la experiencia de usuario (UX) aparece en la gu´ıa de estilo.
No solo se define el aspecto y el comportamiento, sino que tambi´en se proporciona
la codificaci´on de los componentes y las hojas de estilo en ingl´es Cascading Style
Sheet (CSS)12. De esta manera, al modificar la gu´ıa de estilo tambi´en se modifica el
producto.
PMV y experimentos
Con la lista de sub-hip´otesis se crean los PMV, explicado en la secci´on 3.4. Se utilizan
para hacer experimentos y determinar qu´e ideas sobre el producto son v´alidas y cu´ales
deben descartarse. Una de las maneras m´as efectivas de crear los PMV es mediante un
prototipo de la experiencia. Un prototipo es una aproximaci´on de la experiencia de usuario
que permite simular c´omo ser´a el uso de un producto o servicio [13]. Es recomendable
probar el PMV en primera instancia con todo el equipo de desarrollo, y luego con otras
personas. Cu´anto m´as se exponga a las miradas ajenas, m´as conocimiento se tendr´a para
validarlo. El siguiente paso es la experimentaci´on de los usuarios finales. La idea es dejar
que lo utilicen libremente, as´ı se puede obtener todo el feedback posible sobre la experiencia.
Feedback
Hasta ahora, todo el trabajo est´a basado en las suposiciones; a partir de este punto
se comienza con el proceso de validaci´on. Un error com´un es realizar este proceso pocas
veces, normalmente al principio del proyecto o al final. La investigaci´on es continua, lo
que significa que se realizan en cada sprint o iteraci´on del producto.
Como consecuencia de usar este enfoque se obtiene: un equipo que trabaja de forma co-
laborativa, iterativamente, reduciendo al m´ınimo los documentos entregables, enfoc´andose
en el software funcional y en el feedback con el usuario final.
3.5. Antecedentes
Speckle
Speckle [82] comenz´o como una investigaci´on de dise˜no colaborativo para arquitectura
en The Bartlett School of Architecture (UCL)13. El proyecto permite que los usuarios
11https://www.webcomponents.org/introduction
12https://www.w3.org/Style/CSS/
13https://www.ucl.ac.uk/bartlett/architecture/
P´agina 58
puedan compartir dise˜nos param´etricos en la web. En la figura 3.13 se puede ver un
modelo param´etrico en la plataforma web Speckle, a la izquierda se pueden apreciar los
par´ametros del modelo [83].
El proyecto consta de:
Un plugin denominado Speckle Streams14 para el ecosistema del software Rhino15,
este permite establecer los par´ametros de los modelos y exportarlos a archivos en un
formato espec´ıfico.
Una plataforma web que permite subir los archivos generados por el plugin para
visualizar modelos 3D param´etricos, generar versiones modificadas, registrar un his-
torial de los cambios y colaborar con otros usuarios.
Figura 3.13: Interfaz web de Speckle.
Lo destacado de esta plataforma es la manera intuitiva de visualizar y modificar los mo-
delos mediante su interfaz con componentes visuales como campos de texto, deslizadores,
etc. Speckle.Works16 es el repositorio FLOSS del proyecto que permite contribuciones
de la comunidad. Actualmente se desarrollan diversas herramientas para la integraci´on
con otros softwares como Blender.
Modelo.io
Es una plataforma web creada por Qi Su y Tian Deng [84] orientada a profesionales
que utilizan Rhino y SketchUp17. La caracter´ıstica de esta herramienta es que permite
una colaboraci´on efectiva entre los miembros de un equipo para perfeccionar los dise˜nos y
presentarlos de forma interactiva.
14https://www.food4rhino.com/app/speckle-streams
15https://www.rhino3d.com/
16https://github.com/speckleworks
17https://www.sketchup.com/es
P´agina 59
Los usuarios pueden explorar los modelos 3D, realizar comentarios, capturas de panta-
lla, anotaciones sobre los modelos, almacenar archivos extras asociados a los proyectos y
otras caracter´ısticas avanzadas como crear presentaciones 3D interactivas para los clientes.
Se utiliza principalmente en proyectos de arquitectura y dise˜no de interiores (ver figura
3.14). En la interfaz web de Modelo.io, a la derecha se puede apreciar la interacci´on entre
los usuarios [85] en un proyecto de arquitectura.
Figura 3.14: Interfaz web de Modelo.io.
P´agina 60
Cap´ıtulo 4
Resultados: CoCADa Un software
para el dise˜no colaborativo con
Lean UX
En este cap´ıtulo se implementa el proceso de Lean UX en el desarrollo de CoCADa. El
mismo se divide en cinco secciones, las cuatro primeras (4.1,4.2,4.3 y4.4) corresponden al
uso de la metodolog´ıa la cual describe las declaraciones, el dise˜no colaborativo, el desarrollo
de los PMVs y experimentos y el feedback con los usuarios. La ´ultima secci´on (4.5) se enfoca
exclusivamente en los aspectos t´ecnicos del sistema tales como la arquitectura de software
y las tecnolog´ıas involucradas.
4.1. Declaraciones
Declaraci´on del problema para CoCADa:
Los proyectos de dise˜nos de productos son desarrollados por equipos de trabajo ge-
neralmente conformados por personas con diferentes competencias (profesiones o grados
de conocimiento). Los participantes requieren comunicar sus ideas, proponer cambios y
comprender la evoluci´on de los productos, para ello es fundamental una comunicaci´on efi-
ciente. En el proceso de investigaci´on o research los participantes han manifestado que las
herramientas de comunicaci´on m´as utilizadas (email, redes sociales, etc.) dificultan la
organizaci´on de los mensajes y la gesti´on de informaci´on sobre los proyectos,
esto causa problemas de interpretaci´on sobre las caracter´ısticas de los productos y dificulta
el control en el trabajo realizado. Dicha situaci´on genera una reducci´on en la participaci´on
durante el desarrollo del proyecto. ¿C´omo se podr´ıa mejorar la comunicaci´on de modo que
los usuarios aumenten la colaboraci´on de una manera ordenada y precisa?
La declaraci´on del problema contiene muchas suposiciones o aspectos que el equipo de
desarrollo considera ciertos respecto a la soluci´on o producto. Para extraerlas se responden
P´agina 61
las siguientes preguntas y se registran en la lista u hoja de suposiciones.
1. ¿Qui´enes son los usuarios del producto?
a)Personas sin conocimientos espec´ıficos. Interesados en participar del pro-
ceso de dise˜no sin tener conocimientos sobre dise˜no 3D. Generalmente solicitan
modelos 3D para la visualizaci´on o para la fabricaci´on digital. Estas personas
pueden ser emprendedores, artistas, docentes, etc.
b)Profesionales encargados de crear dise˜nos 3D. Poseen las capacidades
t´ecnicas y la experiencia sobre procesos y metodolog´ıas para llevar a cabo pro-
yectos de dise˜no de productos.
2. ¿C´omo cambiar´ıa el producto su trabajo?
a) Ahorrar´ıa mucho tiempo en el feedback.
b) De forma positiva, ya que es indispensable la organizaci´on en los cambios de
los dise˜nos.
3. ¿Qu´e problemas soluciona el producto?
a) La imposibilidad de visualizar el estado actual de un dise˜no.
b) La comunicaci´on inexacta a la hora de discutir sobre un producto.
4. ¿Cu´ales ser´ıan las funciones m´as importantes?
a) Visualizar el modelo 3D de un producto.
b) Comunicarse con el Dise˜nador de forma similar a un chat.
5. ¿Qu´e aspectos debe tener el producto y c´omo debe comportarse?
a) Debe ser agradable a la vista, intuitivo y f´acil de usar como una red social.
4.1.1. Hip´otesis de la soluci´on
Una vez identificado el problema y extra´ıdas las suposiciones, se declara una hip´otesis
general como punto de partida para el desarrollo de la soluci´on.
Desarrollando una herramienta de comunicaci´on para proyectos de dise˜no de productos,
se lograr´a una mayor colaboraci´on en los equipos de trabajo. Se sabr´a si el desarrollo es
correcto cuando aumente la participaci´on entre las personas con diferentes competencias
y se generen las condiciones necesarias para el co-dise˜no.
P´agina 62
4.1.2. Personas
En la figura 4.1 se analizan dos arquetipos que representan los dos tipos de usuarios
del sistema. El usuario sin conocimientos de CAD (Persona A) (izquierda) y el usuario
profesional (Persona B) (derecha).
En la parte superior se especifica la informaci´on general del usuario. El cuadrante
inferior izquierdo contiene las necesidades y frustraciones respecto la soluci´on actual, los
puntos de conflicto espec´ıficos que el producto intenta resolver y/o la oportunidad que se
trata de capturar con ´el. El cuadrante inferior derecho contiene las soluciones potenciales,
sugeridas por el usuario.
Figura 4.1: Personas utilizadas en CoCADa.
4.1.3. Funciones o funcionalidades
Con todo el material obtenido se organizan a continuaci´on las sub-hip´otesis que deben
probarse.
N´um. Se desarrolla (funci´on) Para (persona) Para (soluci´on)
1 Un visor de modelos 3D
en la web
Para (Persona A) y
(Persona B)
Solucionar de forma efi-
ciente la visualizaci´on
de los productos
2 Un sistema de comenta-
rios asociado a los mo-
delos 3D
Para (Persona A) y
(Persona B)
Discutir sobre los avan-
ces del proyecto.
3 Un mecanismo para
anotaciones sobre los
modelos 3D
Para (Persona A) y
(Persona B)
Poder comunicar aspec-
tos de dise˜no entre per-
sonas de diferentes dis-
ciplinas
P´agina 63
4 Un sistema para dar de
Alta proyectos
Para (Persona B) Gestionar nuevos pro-
yectos de dise˜no.
5 Un mecanismo para es-
cribir c´odigo de modela-
do
Para (Persona B) Incorporar dise˜nos y
modificarlos mediante
scripting
6 Un mecanismo para ver
los cambios o “versio-
nes”de los dise˜nos
Para (Persona A) y
(Persona B)
Visualizar la evoluci´on
de los modelos y su es-
tado en una fecha deter-
minada
7 Componentes visuales
para modificar los
par´ametros del modelo
3D
Para (Persona A) y
(Persona B)
Modificar geometr´ıas de
forma intuitiva, sin ne-
cesidad de tener co-
nocimientos de progra-
maci´on o de modelado
avanzado
8 Un mecanismo para ini-
cio de sesi´on con usuario
y contrase˜na
Para (Persona A) y
(Persona B)
El ingreso privado
Tabla 4.1: Tabla de sub-hip´otesis para CoCADa
4.2. Dise˜no Colaborativo
En la figura 4.2 se puede apreciar un resultado del estudio de dise˜no explicado en la
secci´on 3.4. Los bosquejos o sketches reflejan los aspectos m´as relevantes de la aplicaci´on
seg´un las funcionalidades analizadas, los posibles escenarios de uso y las interfaces de
usuario necesarias para que CoCADa sea funcional.
Otro resultado es la gu´ıa de estilos (ver secci´on 3.4) con el dise˜no orientado en los
usuarios objetivo. Se puede apreciar en la figura 4.3 un ejemplo de componente web para
conversaciones y su forma de implementaci´on mediante c´odigo HTML,CSSyJavaScript.
4.3. PMV y experimentos
Se utilizaron computadoras con conexi´on a internet y un navegador web mostrando
un modelo por defecto en la pantalla. Los usuarios no recibieron instrucciones sobre el
uso y no tuvieron limitaciones de tiempo. El evaluador se limit´o a observar y registrar la
actividad. Se presentaron de prototipos de alta fidelidad [86] con el objetivo de lograr
un aspecto y comportamiento similar al de la interfaz definitiva.
P´agina 64
Figura 4.2: Bosquejos para CoCADa.
Figura 4.3: Gu´ıa de estilos para CoCADa.
4.3.1. Demo #1
El primer PMV o Demo #1 evalu´o la sub-hip´otesis 1 de la tabla de sub-hip´otesis:
“Un visor de modelos 3D en la web para el usuario (Persona A) y (Persona
B) para solucionar de forma eficiente la visualizaci´on de los productos”.
Se utilizaron tres preguntas para orientar los experimentos:
1. ¿Qui´en interactuar´a efectivamente con el prototipo?
El usuario sin conocimientos de CAD (Persona A).
2. ¿Qu´e se espera aprender de ´el?
Aspectos de funcionalidad y usabilidad de la UI al momento de interactuar con un
modelo 3D.
P´agina 65
3. ¿Cu´anto tiempo se tiene para desarrollar el prototipo?
Aproximadamente 4 d´ıas.
Se present´o un prototipo de visor con un modelo 3D (ver figura 4.4) con funcionalidades
de zoom (alejar, acercar), rotaci´on y traslaci´on. Tambi´en se establecieron par´ametros de
geometr´ıa y color (izquierda). Fu´e programado en base al c´odigo de OpenJSCAD en un
tiempo aproximado de 36 horas.
Figura 4.4: Demo #1. Visor con un modelo 3D y Par´ametros (izquierda).
4.3.2. Demo #2
Se evalu´o la sub-hip´otesis 5 de la tabla de sub-hip´otesis: “Un mecanismo pa-
ra escribir c´odigo de modelado para (Persona B) para incorporar dise˜nos y
modificarlos mediante scripting”.
Se utilizaron las tres preguntas:
1. ¿Qui´en interactuar´a efectivamente con el prototipo?
El usuario profesional (Persona B).
2. ¿Qu´e se espera aprender de ´el?
Aspectos de funcionalidad y usabilidad de la UI y el editor de c´odigo en el momento
de manipular modelos mediante scripting. No se eval´ua el conocimiento sobre el
lenguaje de programaci´on ni las habilidades del usuario.
3. ¿Cu´anto tiempo se tiene para desarrollar el prototipo?
Aproximadamente 4 d´ıas.
Se present´o un prototipo de visor con un modelo 3D, par´ametros y un editor de c´odigo
(ver figura 4.5). Fu´e programado en un tiempo aproximado de 36 horas.
P´agina 66
Figura 4.5: Demo #2. Modelo 3D y par´ametros (izquierda). Editor de c´odigo (derecha).
4.4. Feedback
Al final de la sesi´on de prueba se realizaron una serie de preguntas sobre la experiencia
de usuario, divididas en t´opicos.
Las respuestas posibles fueron: Buena, Regular o Mala. En caso de responder Regular
o Mala se realizaron otras 2 preguntas: ¿Cu´al es el inconveniente? y¿Qu´e sugiere
para resolver ese inconveniente?
En la siguientes tablas se detallan los t´opicos y sus respuestas:
4.4.1. Feedback con Demo #1
´
Item T´opico Experiencia Inconveniente C´omo mejorar
1 Visualizaci´on
del Modelo
Buena - -
2 Zoom Regular Al hacer demasiado
zoom sobre el mode-
lo ocurre que no hay
un limite, lo que pro-
duce que se rompa la
geometr´ıa.
Limitar el zoom o ver
la posibilidad de vol-
ver la visualizaci´on a
su estado original.
2 Rotaci´on Buena - -
3 Translaci´on Mala Al mover demasiado
el modelo, ocurre que
se pierde la visualiza-
ci´on y parece que la
escena esta vac´ıa.
Limitar la opci´on de
mover o ver la posibi-
lidad de volver la vi-
sualizaci´on a su esta-
do original.
P´agina 67
4 Modificaci´on
de par´ame-
tros
Regular Es inc´omodo ingresar
n´umeros utilizando el
teclado
Agregar un elemento
parecido a los que tie-
nen las apps.
Tabla 4.2: Resultados del feedback para Demo #1
4.4.2. Feedback con Demo #2
´
Item T´opico Experiencia Inconveniente C´omo mejorar
1 Visualizaci´on
del Modelo
Buena - -
2 Edici´on de
c´odigo
Buena - -
3 Relaci´on del
c´odigo con el
modelo
Regular Es dif´ıcil darse cuenta
si el c´odigo del editor
es correspondiente al
modelo actual
Agregar un mecanis-
mo de alerta cuando
a´un no se han refleja-
do los cambios.
Tabla 4.3: Resultados del feedback para Demo #2
4.4.3. Resultados y propuestas
Resultados para Demo #1
Zoom (alejar, acercar). En la figura 4.6 se puede apreciar como se “rompe”la geo-
metr´ıa al acercarse demasiado al objeto.
Soluci´on: Agregar un bot´on de “Resetear Vista” (izquierda) para establecer la
c´amara en su posici´on original, con el objeto centrado en la pantalla (ver figura
4.8 , izquierda).
Figura 4.6: Inconvenientes con el zoom en Demo #1.
P´agina 68
Traslaci´on (Mover). En la Figura 4.7 el modelo pr´acticamente desaparece de la
pantalla.
Soluci´on: Utilizar la misma funcionalidad de el punto anterior.
Modificaci´on de par´ametros. El uso de campos de textos no es adecuado para
valores num´ericos. La mayor´ıa de las personas est´an acostumbrados a las interfaces
con componente gr´aficos como controles deslizantes en los que no es necesario escribir
n´umeros con el teclado, sino que permiten a los usuarios realizar selecciones a partir
de un rango de valores definidos. Tanto en la figura 4.6 (izquierda) como en la figura
4.7 (izquierda) no se utilizan este tipo de elementos.
Soluci´on: Incorporar controles deslizantes o slider para los par´ametros num´ericos y
as´ı evitar la carga de valores por teclado.
Figura 4.7: Inconvenientes con la traslaci´on en Demo #1.
Propuestas para Demo #1
Luego de replicar y analizar las experiencias de usuario negativas, se construy´o
un prototipo Demo #1.1 en base al feedback y las recomendaciones del usuario Persona
A en el experimento con Demo #1. Se agreg´o un bot´on “Resetear vista” (ver figura 4.8)
para solucionar el problema del zoom. Se cambi´o el campo de texto del par´ametro “Texto
profundidad” por un slider para mejorar la experiencia de usuario al modificar los valores
num´ericos. El resto de los campos de texto no han sido modificados de forma intencional,
para que el usuario pueda comparar las diferencias respecto al nuevo.
Resultados para Demo #2
Relaci´on del c´odigo con el modelo. En la figura 4.9 se puede apreciar la ex-
periencia de usuario negativa, al modificar el c´odigo existen diferencias entre el
P´agina 69
Figura 4.8: Demo #1.1. Correcci´on de inconvenientes hallados en Demo #1.
programa y el modelo, no existe un mecanismo que brinde informaci´on al usuario so-
bre esta situaci´on para decidir si ver los cambios en el modelo o bien seguir editando
el c´odigo.
Soluci´on: Agregar un mensaje de alerta para indicar cu´ando el usuario ha modifi-
cado el c´odigo y el cambio a´un no se ha reflejado en el modelo.
Figura 4.9: Inconvenientes en la relaci´on del c´odigo con el modelo en Demo #2.
Propuestas para Demo #2
Se construy´o un prototipo Demo #2.1 en base a las recomendaciones del usuario
Persona B en el experimento con Demo #2 (ver figura 4.10). Se agreg´o un componente
con el mensaje de alerta para informar al usuario si los cambios en el c´odigo a´un no se
reflejaron en el modelo.
Al finalizar cada experimento se vuelve al ciclo construir-medir-aprender visto en la
P´agina 70
Figura 4.10: Demo #2.1. Correcci´on del inconveniente hallado en Demo #2.
secci´on 3.4, hasta obtener un prototipo que satisfaga al usuario. De esa manera se obtu-
vieron recomendaciones interesantes para ser implementadas en el futuro. Con la tabla de
sub-hip´otesis y lo aprendido con los usuarios en los experimentos, finalmente se estable-
ci´o la arquitectura de software necesaria para dar soporte a todas las funcionalidades de
CoCADa.
4.5. Sistema CoCADa
En la secci´on 4.1.3 se identificaron las funcionalidades que la aplicaci´on debe proveer a
los usuarios. Adicionalmente, para una colaboraci´on distribuida, se requiere de la Gesti´on
de datos de productos basado en la web (WPDM), explicada en la secci´on 3.3.3.
CoCADa se divide en dos ´areas fundamentales: Back-End yFront-End [87].
4.5.1. Back-End
La aplicaci´on de Back-End o capa de servicios (ver figura 4.11) cuenta con tecnolog´ıas
para tareas que no pueden ser resueltas directamente por los usuarios como la persistencia
de datos y el almacenamiento de archivos. Las tecnolog´ıas utilizadas son:
Node.js1como web server y entorno de ejecuci´on para JavaScript en el lado del
servidor, de la misma manera que lo hacen otros lenguajes como PHP2o Python.
Nuxt.js3. Es un framework para crear aplicaciones isom´orficas o universales con
1https://nodejs.org/es/
2http://php.net/manual/es/intro-whatis.php
3https://nuxtjs.org/
P´agina 71
Vue.js4. Una aplicaci´on universal es aquella que su c´odigo puede ser ejecutado tanto
en el cliente (navegador web) como en el servidor. Nuxt.js incorpora el concepto
Server Side Rendering (SSR)5. El SSR en CoCADa brinda la posibilidad de convertir
los componentes web en cadenas de HTML en el servidor, luego son enviadas al
navegador web y se genera la aplicaci´on en el lado del cliente.
Loopback6. Es un conjunto de m´odulos de Node.js que permiten la implementa-
ci´on de APIs [88] altamente flexibles. Est´a basado en el framework Express.js7y
proporciona funcionalidades para:
- Crear APIs REST din´amicas end-to-end8con poca codificaci´on.
- Acceso a datos para los principales motores de bases de datos, servicios SOAP y
otras APIs.
- Almacenamiento de archivos o File storage.
- Inicio de sesi´on mediante protocolos de autorizaci´on OAuth9.
Nuxt.js se comunica con LoopBack a trav´es de su API REST, obteniendo como
respuesta es un documento JSON.
MongoDB10. El enfoque de CoCADa es agn´ostico11 respecto al motor de base de
datos, sin embargo, se utiliza MongoDB (NoSQL) para la persistencia de datos.
A diferencia de las bases de datos relacionales, los datos se almacenan en tablas,
sino mediante documentos en formato JSON. Esto permite que la integraci´on entre
MongoDB y JavaScript sea mucho m´as directa.
CoCADa API REST
En esta secci´on se desarrolla el modelo l´ogico del sistema, incluyendo el soporte para
Intercambio de datos Basado en Caracter´ısticas (FBDE) explicado en la secci´on
3.3.4. El diagrama de la figura 4.12 ilustra el esquema de datos y las relaciones entre las
4https://vuejs.org/
5https://ssr.vuejs.org/#what-is-server-side- rendering-ssr
6https://loopback.io
7https://expressjs.com/es/
8End-to-end es un enfoque que involucra la visi´on global del encadenamiento de procesos y/o actividades,
desde que surge una necesidad a satisfacer, hasta que esta es satisfecha.
9https://oauth.net/2/
10https://www.mongodb.com/es
11Se refiere a la capacidad de interoperabilidad y compatibilidad de un componente de c´omputo entre
diversos sistemas y ambientes, sin requerir una adaptaci´on especial.
P´agina 72
Figura 4.11: Backend de CoCADa.
entidades. Las especificaciones del modelo y la fuentes de datos (base de datos) se realizan
con LoopBack mediante archivos JSON.
Figura 4.12: Modelo de datos para CoCADa.
Proyecto: Es la entidad que gestiona la evoluci´on de los dise˜nos. Puede contener
una o m´as versiones de un producto, tambi´en llamado ´arbol de historias.
En la figura 4.13 se puede analizar un proyecto con su respectivas versiones y la
evoluci´on de los dise˜nos ordenadas por fecha ascendente. La imagen que identifica
el Proyecto 1 es la misma que la ´ultima versi´on del producto. La Versi´on 1 se inicia
al momento de generar el proyecto, con un modelo de ejemplo (cubo). La Versi´on
2 se genera a partir de la anterior, con los cambios efectuados en el c´odigo y as´ı
sucesivamente.
Versi´on: Es la representaci´on de un dise˜no (producto) individual y su informaci´on
relacionada. Tambi´en se puede entender como una iteraci´on en el proceso de dise˜no.
Usuario. La entidad representa a los usuarios del sistema.
Comentario. Gestiona los comentarios asociados a una Versi´on.
P´agina 73
Figura 4.13: Un proyecto con sus versiones o ”´arbol de historia”.
Rol. Especifica los permisos de los usuarios dentro del sistema, un mismo rol puede
ser asignado a diferentes usuarios.
Archivo. Esta entidad contiene la direcci´on web o URL de un archivo, en CoCADa
estos archivos se asocian a los comentarios.
Para facilitar el desarrollo, LoopBack provee una herramienta (API Explorer12) para
explorar las entidades, los m´etodos HTTP disponibles y los EndPoints13 de la API. En la
figura 4.14 se puede ver el ejemplo de un modelo “Versi´on” con los datos del producto.
4.5.2. Front-End
En las aplicaciones web, el Front-End o capa de presentaci´on implica el uso de las
tecnolog´ıas con las que interact´ua directamente el usuario. Normalmente estas tecnolog´ıas
son desarrolladas en los lenguajes HTML, CSS, javacript y otros recursos como im´agenes
12https://loopback.io/doc/en/lb3/Use-API-Explorer.html
13Un Endpoint en la API de CoCADa es una URL ´unica que representa un objeto o una colecci´on de
objetos.
P´agina 74
Figura 4.14: Herramienta API Explorer de LoopBack.
y gr´aficos vectoriales (ver figura 4.15). Al ingresar al sistema, se muestra la interfaz de
usuario UI tambi´en llamada CoCADa APP.
Figura 4.15: Front-End de CoCADa.
Para la implementaci´on se utilizan las siguientes tecnolog´ıas:
OpenJSCAD (JavaScript) como lenguaje de descripci´on CSG para trabajar en
alto nivel y de forma intuitiva con las primitivas, transformaciones, operaciones boo-
leanas, etc. Adem´as provee mecanismos para la manipulaci´on visual de par´ametros
y exportaci´on de los modelos en formato STL. Una vez procesadas las sentencias del
lenguaje de descripci´on, se traducen a su representaci´on interna (matem´atica)
vista en la secci´on 2.3.1 mediante la API WebGL del navegador web (ver figura
4.15).
P´agina 75
Vue.js14 . Es un framework progresivo para interfaces de usuario, lo que significa
que se pueden incorporar herramientas incrementalmente, a medida que aumenta la
complejidad de la aplicaci´on. Un ventaja de usar esta tecnolog´ıa es su caracter´ıstica
de sistema reactivo [89], manteniendo una interacci´on constante con su entorno y
permitiendo el cambio de estado interno por medio de eventos. Cuando los datos de
la interfaz son modificados por alguna acci´on del sistema o del usuario, por ejemplo:
cada vez que se hace una petici´on al