gar cia civil engineering thesis

8/6/2019 Gar CIA Civil Engineering Thesis

1/106


2/106

Dedicatoria

Al seor Ricardo Mendoza Mamani y la seora Inelia Garca Rojas: mis padres;

quienes, sin exigirme nada, me ensearon a dar lo mximo.

I


3/106

Agradecimientos

A mis padres, mis hermanos Ruth y Victor, mi cuado Frankie, y sobrinitos Tamara

y Lucas: mi familia, y al profesor Ral Sapiain Araya, quienes me animaban

permanentemente a concluir el presente trabajo, cuando la situacin dificultaba su

desarrollo.

A la seorita Magdalena Dobrajska, mi compaera, quien se ha encargado de mantener

mi salud mental y quien ha sacrificado incontables horas de su tiempo libre, para

hacerme compaia durante el desarrollo del proyecto.

A todo el resto de mi familia, en el extranjero y en Chile, quienes siempre se han

encargado de atenuar la melancola que peridicamente aparece al encontrarme tan

distante de mi tierra natal.

A mi permanente grupo de amigos con quienes he compartido penas y alegras y a los

que tengo siempre presente al momento de forjar mi futuro.

Al seor John Hffner, mi supervisor en la compaa que dio soporte econmico

durante un largo perodo de tiempo a mis estudios: Damixa; quien, sin obligacin

alguna, siempre soport mis demandas; especialmente cuando la memoria consuma

gran parte de mi tiempo.

A mi profesor gua, el seor Ramn Guirriman Carrasco, y a mi profesor informante,

el seor Ral Sanhueza Hormazabal, quienes tuvieron la paciencia de guiar, revisar, y

corregir un trabajo a distancia; y durante un perodo de tiempo excepcional.

A la seorita Magdalena Campusano Vergara, siempre dispuesta a resolver los

problemas de los alumnos de la carrera de Ingeniera Civil Elctrica-Electrnica.

A todos los profesores que confiaron en m al momento de seleccionar uno de los

alumnos que viajaran a perfeccionar sus conocimientos al extranjero, y que hicieron

posible concluir mi proyecto final de carrera.

II


4/106

ndice general

Dedicatoria I

Agradecimientos II

Resumen VIII

1. Introduccin 1

1.1. Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. El plus de las universidades . . . . . . . . . . . . . . . . . . . 1

1.1.2. De la teora a la prctica . . . . . . . . . . . . . . . . . . . . . 2

1.1.3. Linux: el camino legal . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Alcances del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Linux y la Electrnica 5

2.1. Linux y el usuario final . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Alternativas gratuitas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Oficina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2. Matemtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2.1. Clculo numrico . . . . . . . . . . . . . . . . . . . 7

2.2.2.2. Clculo simblico . . . . . . . . . . . . . . . . . . . 7

2.2.3. Electrnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3.1. Grupos EDA . . . . . . . . . . . . . . . . . . . . . . 8

II I


5/106

NDICE GENERAL IV

2.2.3.2. Captura esquemtica . . . . . . . . . . . . . . . . . . 8

2.2.3.3. Diseo de placas impresas . . . . . . . . . . . . . . . 9

2.2.3.4. Simulacin electrnica . . . . . . . . . . . . . . . . 10

2.3. Captura esquemtica y simulacin electrnica . . . . . . . . . . . . . . 11

2.3.1. Oregano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2. Qucs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.3. KTechlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Orientacin a Objetos 15

3.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Abstraccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1.1. Abstraccin de un objeto . . . . . . . . . . . . . . . 16

3.1.1.2. Clases de objetos . . . . . . . . . . . . . . . . . . . 18

3.1.1.3. Composicin de clases . . . . . . . . . . . . . . . . 18

3.1.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.2.1. Encapsulacin . . . . . . . . . . . . . . . . . . . . . 19

3.1.2.2. Herencia . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2.3. Polimorfismo . . . . . . . . . . . . . . . . . . . . . 22

3.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1. Enfoque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.2. Procesos de desarrollo . . . . . . . . . . . . . . . . . . . . . . 25

3.2.3. Pautas a seguir . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Rational Unified Process - RUP 28

4.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1. Proceso de desarrollo iterativo . . . . . . . . . . . . . . . . . . 29

4.1.2. Administracin de los requerimientos . . . . . . . . . . . . . . 29

4.1.3. Estructura del RUP . . . . . . . . . . . . . . . . . . . . . . . . 31


6/106

NDICE GENERAL V

4.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1.1. Concepcin . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1.2. Elaboracin . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1.3. Construccin . . . . . . . . . . . . . . . . . . . . . . 32

4.2.1.4. Transicin . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.3. Disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.3.1. Administracin del Proyecto . . . . . . . . . . . . . 34

4.2.3.2. Requerimientos (Anlisis) . . . . . . . . . . . . . . . 35

4.2.3.3. Modelo de Negocio (Anlisis) . . . . . . . . . . . . . 35

4.2.3.4. Diseo . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.3.5. Implementacin . . . . . . . . . . . . . . . . . . . . 35

4.2.4. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.4.1. Modelo de Casos de Uso . . . . . . . . . . . . . . . 36

4.2.4.2. Plan de Iteracin . . . . . . . . . . . . . . . . . . . . 41

4.2.4.3. Modelo del Dominio . . . . . . . . . . . . . . . . . . 424.2.4.4. Modelo del Diseo . . . . . . . . . . . . . . . . . . 46

4.2.4.5. Modelo de la Implementacin . . . . . . . . . . . . . 54

5. Desarrollo de SpiceX 55

5.1. Concepcin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1. Disciplina de Requerimientos . . . . . . . . . . . . . . . . . . 555.1.1.1. Modelo de Casos de Uso . . . . . . . . . . . . . . . 55

5.1.2. Disciplina de Administracin del Proyecto . . . . . . . . . . . 59

5.1.2.1. Plan de Iteracin . . . . . . . . . . . . . . . . . . . . 59

5.2. Elaboracin: Primera Iteracin . . . . . . . . . . . . . . . . . . . . . . 60


7/106

NDICE GENERAL VI

5.2.1. Disciplina de Modelo de Negocio . . . . . . . . . . . . . . . . 60

5.2.1.1. Modelo del Dominio . . . . . . . . . . . . . . . . . . 60

5.2.2. Disciplina de Diseo . . . . . . . . . . . . . . . . . . . . . . . 62

5.2.2.1. Modelo del Diseo: Diagramas de Interaccin . . . . 62

5.2.3. Disciplina de Implementacin . . . . . . . . . . . . . . . . . . 66



5.2.4.1. Plan de Iteracin . . . . . . . . . . . . . . . . . . . . 67

5.2.5. Disciplina de Requerimientos . . . . . . . . . . . . . . . . . . 67


5.3. Elaboracin: Segunda Iteracin . . . . . . . . . . . . . . . . . . . . . . 69

5.3.1. Disciplina de Modelo de Negocio . . . . . . . . . . . . . . . . 695.3.1.1. Modelo del Dominio . . . . . . . . . . . . . . . . . . 69






5.3.4.1. Plan de Iteracin . . . . . . . . . . . . . . . . . . . . 74

5.3.5. Disciplina de Requerimientos . . . . . . . . . . . . . . . . . . 74


5.4. Elaboracin: Tercera Iteracin . . . . . . . . . . . . . . . . . . . . . . 76

5.4.1. Disciplina de Modelo de Negocio . . . . . . . . . . . . . . . . 76

5.4.1.1. Modelo del Dominio . . . . . . . . . . . . . . . . . . 76






8/106

NDICE GENERAL VI I

6. Conclusiones 82

6.1. EDA en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2. Webometrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.3. Alcances logrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Apndice 86

A. Cdigo de SpiceX 86

B. Diagramas de Interaccin 87

Bibliografa 96


9/106

Resumen

El siguiente trabajo implementa una interfaz grfica para asistir la creacin de

topologas de circuitos electrnicos en formato de texto: netlist; que satisfagan la

sintaxis especfica de diversos ncleos de simulacin de lnea de comandos disponibles

en Linux.

Adems, el contenido trata de graficar, en general, el estado actual de los programas

para la automatizacin del diseo electrnico en Linux, y de presentar el marco terico

necesario para entender y mejorar el sistema a futuro.

La metodologa de desarrollo seguida al momento de implementar la aplicacin es el

Rational Unified Process, el cual aborda los requerimientos del proyecto de una forma

rpida, directa, organizada y eficaz.

Independiente del pequeo avance alcanzado en las fases del proceso de desarrollo,

y gracias a las pautas de implementacin propuestas por el mismo, la arquitectura

principal de la aplicacin est prcticamente finalizada. Es as que el programa es

funcional, puede ser y ha sido fcilmente testeado, y permite recibir realimentacin

efectiva. Todo esto, en conjunto con un cdigo y funcionalidad de fcil expansin por

parte de los usuarios.

Los alcances tcnicos logrados son: implementacin de circuitos electrnicos de forma

grfica y asistida, con posibilidades de modificacin y almacenado; simulacin de

anlisis transiente de los circuitos, disponiendo para ello de una librera de componentesbsicos, pero suficientes para una amplia gama de configuraciones; el soporte de

los ncleos de simulacin Spice y Ngspice, para efectuar dichas simulaciones; y

la posibilidad de incrementar la cantidad de componentes soportados, mediante la

importacin de libreras de componentes para Spice.

VIII


10/106

Captulo 1

Introduccin

1.1. Motivacin

1.1.1. El plus de las universidades

Es de conocimiento general la preocupacin de las universidades por mejorar y destacar

sus carreras, logrando as prestigio y distincin entre sus pares. As como algunas

universidades se destacan por la sobresaliente capacidad administrativa que presentan

los alumnos que egresan de stas, otras lo hacen por el bagaje tecnolgico que poseen

los profesionales que en ellas se forman.

Mirando los criterios de evaluacin de excelencia, aplicados por importantes medios

de comunicacin al momento de elaborar rankings de universidades a nivel mundial,

queda de manifiesto la importancia de las publicaciones generadas en las instituciones

de educacin superior[7]. En este contexto, no existe una ley que limite el desarrollo y

proliferacin de investigaciones, manuales y cualquier tipo de publicaciones cientfico-

tcnicas, a los acadmicos de las universidades.

Asumiendo esto, el alumno tiene la capacidad de aportar en forma directa al

prestigio que posee la institucin que a futuro respaldar su nivel de educacin,

usando como herramienta la publicacin del conocimiento[4]. Es decir, el estudiante

tiene la posibilidad de generar ese plus tan conveniente, tomando en sus manos la

responsabilidad hasta ahora delegada a las administraciones universitarias.

1


11/106

CAPTULO 1. INTRODUCCIN 2

1.1.2. De la teora a la prctica

Cmo lograr esto? La respuesta a esta interrogante es tema de interesantes debates.

Una medida inicial puede ser la generacin de espacios de tiempo para desarrollar

esta capacidad, tan limitada por la saturacin de asignaturas presente en las carreras

de Ingeniera. Sin embargo, con un alumno desmotivado, cualquier optimizacin

curricular sera infructuosa. Independiente de la forma como se impulse este macro

objetivo, sea como resultado de una buena poltica de accin de parte de losacadmicos o como producto de la motivacin interna del estudiante, ste ltimo

debera incursionar, en el transcurso de su formacin profesional, en el mbito de

la investigacin, innovacin y publicacin. Posteriormente, si la consecuencia del

esfuerzo son buenas crticas, es muy probable que el afn de superacin genere en

el alumno una motivacin extra.

Sin embargo, se debe tener presente que llevar a cabo una publicacin en formato

electrnico requiere una serie de programas, entre los cuales estn: sistema operativo,

editores de texto, hojas de clculo, editores de ecuaciones, editores grficos, sistemas

para administracin de bases de datos, etctera. Si la publicacin est relacionada con el

mundo de la Ingeniera Electrnica, se podran necesitar, adems, programas para rea-

lizar las siguientes tareas: clculo simblico, clculo numrico, captura esquemtica,

diseo de PCBs, y simulacin electrnica, entre otros.

No se puede pensar en reconocimiento institucional, partiendo de una base ilegal.

Lamentablemente, muchas universidades carecen de recursos suficientes para la

adquisicin de las licencias necesarias para que sus alumnos realicen publicaciones.

De ms esta decir, que para un alumno en particular esto resulta imposible.

Esto ltimo significa un gran impedimento para el objetivo propuesto, siempre y

cuando, se considere la utilizacin de programas comerciales como herramientas de

trabajo.


12/106


1.1.3. Linux: el camino legal

Es en este punto donde hace su aparicin Linux. Este sistema operativo provee todas

las herramientas necesarias para llevar a cabo cualquier tipo de publicacin en forma

totalmente gratuita, sin temor a enfrentar problemas de patentes y demandas tanto a

nivel personal como institucional.

Tambin es cierto que la migracin hacia un sistema operativo distinto supone una curva

de aprendizaje, la cual se relaciona con el proceso de adaptacin a una nueva forma de

hacer las cosas; no ms difcil, pero s diferente. Por tal motivo, en la actualidad, la

mayora de las aplicaciones en Linux disponen de interfaces grficas, similares a las

que utiliza Windows; las cuales facilitan la migracin y el acercamiento a las nuevas

herramientas informticas.

Sin embargo, existe una excepcin, que la conforman las aplicaciones CAD1,

particularmente, las de uso en Ingeniera Elctrica y Electrnica. Estas herramientasde lnea de comandos, si bien han sido el ncleo de muchas aplicaciones comerciales

de Windows, an son poco intuitivas.

La posibilidad de eliminar esa carencia presente en Linux, muchas veces clave en la

decisin de un electrnico de no utilizar este sistema operativo, y el sueo de aportar

con algo al mejoramiento de la excelencia acadmica en la universidad; no slo por la

institucin, sino, adems, por el pas y la regin. . . es motivante.

1.2. Objetivo General

Por todo lo expuesto anteriormente, el objetivo principal de este proyecto es la creacin

de una interfaz grfica para el simulador electrnico Spice2 de Linux: SpiceX; que se

familiarice con las herramientas de trabajo actuales de los estudiantes de Ingeniera

Electrnica.1CAD: Computer Aided Design.2Spice es la herramienta de simulacin electrnica que dio origen a Pspice, un popular simulador

electrnico para Windows, considerado un standard en la industria.


13/106


1.3. Alcances del Proyecto

Se desea poner a disposicin del alumno, todas las herramientas necesarias para llevar

a cabo un trabajo de investigacin, sin producir cambios drsticos en su metodologa

de trabajo. Considerando la complejidad del objetivo, el desarrollo deber enfocarse de

tal forma que el programa presente las siguientes caractersticas:

1. cdigo de fcil desarrollo y mantencin,

2. funcionalidad suficiente para comenzar su distribucin,

3. y libreras electrnicas de fcil expansin por parte de los usuarios.


14/106

Captulo 2

Linux y la Electrnica

Al momento de escribir el presente captulo, Linux se encuentra compitiendo

seriamente con otros sistemas operativos que, por haberse enfocado desde su gnesis

en la facilidad de uso, continan ocupando la mayora de los escritorios de usuarios.

2.1. Linux y el usuario final

En Enero del 2006, la organizacin de consumidores y usuarios de Espaa, public

un interesante artculo que compara las ventajas y desventajas de los sistemas

operativos: Windows XP, Mac OS X, y Ubuntu Linux, al momento de ser utilizados

en computadores personales[3].

Independiente de los resultados finales de aquella comparacin, queda de manifiesto

que Linux est dejando de ser el sistema operativo utilizado nicamente por expertos

en informtica. De hecho, la distribucin1 evaluada busca facilitar el acercamiento del

usuario final, el cual no est dispuesto a dedicar mucho tiempo a la solucin de tareas

triviales.

1Existen diversas compaias o agrupaciones, las cuales empaquetan el kernel Linux con distintos

tipos de programas, para as ser distribuido a los usuarios. Dicho conjunto de programas, presentando

pequeas diferencias en torno a la gestin del sistema, recibe el nombre de distribucin.

5


15/106

CAPTULO 2. LINUX Y LA ELECTRNICA 6

Aportando al mismo objetivo de las distribuciones orientadas al escritorio, cierto tipo

de pginas web2 se dedica a reunir informacin de inters para usuarios que desean

comenzar a utilizar opciones gratuitas, frente a los programas de pago que les presiona

a utilizar la popularidad del sistema operativo Windows.

Dichas herramientas informticas, conocidas generalmente como alternativas libres, si

bien no se restringen al sistema operativo Linux, en muy pocos casos lo excluyen.

2.2. Alternativas gratuitas

Sera imposible mencionar todas las aplicaciones gratuitas que estn disponibles para el

sistema operativo Linux. Es por eso que en esta seccin se mencionarn, nicamente,

algunas de las alternativas disponibles en las reas que competen a un estudiante de

Ingeniera Elctrica y Electrnica.

2.2.1. Oficina

Al momento de escribir reportes que acompaen trabajos prcticos o de laboratorio,

se dispone del conjunto ofimtico: OpenOffice3. Este grupo de programas, que

comenz como un proyecto privado y comercial de Sun Microsystems, presenta todos

los componentes disponibles en su anloga comercial Microsoft Office; incluyendo:

procesador de texto, hoja de clculo, editor y presentador de diapositivas, editor de

ecuaciones, editor de grficos y base de datos.

Aunque no perfecta, la compatibilidad con la contra parte comercial es casi total,

permitiendo la lectura y escritura de los archivos generados por cada uno de los

mdulos que componen Microsoft Office.

2.2.2. Matemtica

En el estudio de la ingeniera, existen dos importantes reas de las matemticas que

demandan el uso del computador para agilizar su aplicacin: el clculo numrico y el

clculo simblico.2http://alts.homelinux.net/, http://www.linuxrsp.ru/win-lin-soft/index-spanish.html, entre otras.3http://www.openoffice.org/


16/106


2.2.2.1. Clculo numrico

Para agilizar el clculo numrico, el estudiante necesita de un programa estilo Matlab,

y las alternativas presentes son: Scilab4 y Octave5. En los dos casos, la interaccin con

el usuario se efecta de manera similar a Matlab, a travs de sentencias de lnea de

comandos, y utilizando prcticamente el mismo grupo de instrucciones.

Cabe mencionar que Scilab dispone de SciCos, un mdulo estilo Simulink de Matlab,

que podra determinar una ventaja con respecto a Octave. Sin embargo, ambos

programas buscan ambiciosamente, y para beneficio de los usuarios insertos en

entornos comerciales, la compatibilidad con Matlab; apuntando principalmente, a la

ejecucin de programas escritos para esta aplicacin.

2.2.2.2. Clculo simblico

Para agilizar el clculo simblico, el estudiante necesita de un programa estilo

Mathematica, y las alternativas presentes son: Maxima6 y Mupad7. Nuevamente, la

interaccin con el usuario se efecta a travs de un intrprete de comandos, pero se

debe tomar en cuenta que, en esta ocasin, los lenguajes utilizados por las alternativas

gratuitas difieren entre ellos y del lenguaje implementado en su anlogo comercial.

Sin embargo, Maxima es la evolucin de uno de los primeros programas creados para el

clculo simblico: Macsyma; del cual tambin derivan algunos programas comerciales,entre ellos Mathematica. Por esta razn, los lenguajes implementados en Maxima y

Mathematica presentan ciertas similitudes, lo que podra ser un punto a favor de esta

alternativa libre.

Lamentablemente, Mupad ha descontinuado la entrega de licencias gratuitas para

estudiantes, y en estos momentos se trata de un programa de pago ms. No obstante,

algunas versiones antiguas pueden continuar siendo utilizadas de forma gratuita.

4http://www.scilab.org/5http://www.octave.org/6http://maxima.sourceforge.net/7http://www.mupad.de/


17/106


2.2.3. Electrnica

En el mundo de la electrnica, Linux puede ser utilizado de dos formas: como sistema

operativo incorporado en un dispositivo electrnico (embedded), o como plataforma

para la ejecucin de tareas relacionadas con la automatizacin del diseo electrnico:

EDA8.

Considerando los alcances del proyecto, en esta seccin se analizarn las aplicaciones

EDA para Linux, sin considerar el grupo de programas con funcionalidades similares a

SpiceX: a los cuales se dedicar una seccin en detalle.

2.2.3.1. Grupos EDA

Frente a la preponderante necesidad de contar con un conjunto completo de

herramientas para realizar tareas de EDA en Linux, se han formado varios grupos de

programadores que buscan proveer la tan solicitada suite informtica. De entre estos

grupos se pueden nombrar: gEDA9 y Open Circuit Design10.

La diferencia entre estos grupos est determinada por el conjunto de programas que

se han seleccionado, para suplir las diferentes necesidades que aparecen durante los

procesos de diseo, prueba, e implementacin de circuitos electrnicos.

Lamentablemente, ms all de reunir los paquetes, empaquetarlos bajo un nico

nombre, y promocionarlos de manera insuficiente, el trabajo de desarrollo de cada unode los componentes de software sigue siendo una tarea, prcticamente, individual.

2.2.3.2. Captura esquemtica

Los programas de captura esquemtica son aplicaciones creadas para esbozar circuitos

electrnicos y exportar los esquemas como archivos netlist; los cuales satisfacen la

sintaxis de algn ncleo de simulacin en particular.

8EDA: Electronic Design Automation.9http://www.geda.seul.org/

10http://opencircuitdesign.com/


18/106


Dentro de este grupo de programas, que delegan al usuario la tarea de enlazar los

archivos netlist generados con el ncleo de simulacin, se encuentran: XCircuit11, y

gschem12; pertenecientes a los grupos Open Circuit Design y gEDA, respectivamente.

La principal caracterstica de ambos programas, es que pueden generar dibujos de

circuitos de gran calidad, debido a la tecnologa utilizada en su implementacin: el

lenguaje Postscript para la descripcin de diagramas.

Sin embargo, se aprecia una ligera diferencia entre estas dos aplicaciones, lo cual podraayudar a discriminar entre una y otra. Por una parte, el autor de gschem reconoce que

XCircuit produce mejores salidas grficas; y por otra, gschem esta ms orientado al

diseo de circuitos que a dibujos de calidad en s, lo cual se aprecia en su funcionalidad.

Lamentablemente, la desventaja de programas de este tipo, es el hecho de tener

que enlazar explcitamente el ncleo de simulacin; lo cual incrementa la curva de

aprendizaje de usuarios provenientes de ambientes ms amigables.

2.2.3.3. Diseo de placas impresas

Al momento de disear las placas impresas que conectarn elctricamente los circuitos

diseados, se puede recurrir a programas como: PCB13 o MUCS-PCB14. PCB forma

parte de ambos grupos EDA: gEDA y Open Circuit Design; mientras que MUCS-PCB

es soportado nicamente por gEDA.

El principal objetivo de ambos programas es la creacin de layouts, que son esquemas

de rutas que sealizarn la trayectoria a seguir por el cobre en un sustrato. Considerando

esto, la principal funcionalidad provista es la automatizacin en la creacin de las rutas,

dejando unos pocos segmentos del circuito a ser detallados de forma manual por el

diseador.

Los archivos generados por estas herramientas pueden especificar las dimensiones de

la placa y los lugares donde se taladrarn los hoyos, entre otras caractersticas. Adems,

es importante destacar que las placas diseadas pueden ser exportadas como archivos

Gerber, el cual es el formato estndar utilizado por los fabricantes de placas impresas.

11http://opencircuitdesign.com/xcircuit/index.html12http://www.geda.seul.org/tools/gschem/index.html13http://pcb.sourceforge.net/14http://www.cs.manchester.ac.uk/apt/projects/tools/mucs-pcb/


19/106


La gran diferencia entre ambos programas radica en la interfaz de usuario, siendo

grfica en el caso de PCB, y de lnea de comandos en el caso de MUCS-PCB. Esto

ltimo determina una ventaja para PCB, al momento de ser utilizado por usuarios

provenientes de ambientes grficos.

Otra ventaja a favor de PCB es la posibilidad de importar un tipo especial de

archivos netlist, los cuales difieren ligeramente de los archivos netlist generados por

los programas de captura esquemtica, para las herramientas de simulacin. De esta

forma, no es difcil encontrar aplicaciones de captura esquemtica con la habilidad de

exportar esquemas de circuitos como archivos netlistpara PCB:XCircuites un ejemplo.

2.2.3.4. Simulacin electrnica

Una etapa fundamental en el diseo de un circuito electrnico es la prueba del

funcionamiento. En los aos previos a la aparicin de los primeros programas de

simulacin electrnica, los diseadores tenan que lidiar con lentos y costosos procesos

de prueba, en los cuales se utilizaba directamente un prototipo del hardware a

producir[1].

De entre los programas para realizar simulacin electrnica en Linux, se pueden

mencionar: Spice15, Xspice16, y Ngspice17.

Spice es un simulador de circuitos de propsitos generales, cuyas siglas significan

Simulation Program with Integrated Circuit Emphasis. Esta aplicacin fue uno de los

primeros programas de simulacin electrnica disponibles en el mercado, lo que la

llev a convertirse en un estndar de la industria en los aos ochenta.

Entre las capacidades de Spice se encuentran los anlisis: DC, de pequea seal

AC, transiente, de polos y ceros, de distorsin de pequea seal, de sensibilidad,

y de ruido. Adems, los circuitos pueden contener resistencias, condensadores,

inductores, inductores mutuos, fuentes independientes de voltaje y corriente, cuatro

tipos de fuentes dependientes, lneas de transmisin con prdida y sin prdida (dos

implementaciones separadas), interruptores, lneas RC uniformemente distribuidas,

15http://bwrc.eecs.berkeley.edu/Classes/IcBook/SPICE/16http://users.ece.gatech.edu/ mrichard/Xspice/17http://ngspice.sourceforge.net/


20/106


y cinco de los ms comunes dispositivos semiconductores: diodos, BJTs, JFETs,

MESFETs, y MOSFETs[12].

Sin embargo, se debe tener en mente las limitaciones de Spice, como son: el grado de

precisin de las simulaciones de circuitos depende de los comportamientos modelados

en los componentes; las simulaciones estn libres de ruido e interferencia, a no ser

que se modelen explcitamente; y, finalmente, el simulador no predice el fallo de los

componentes, aunque se excedan los parmetros de tolerancia mxima[5].

Continuando, Xspice es una extensin de Spice que provee la habilidad de usar

tcnicas de modelado por cdigo para la adicin de nuevos modelos. La librera de

modelos de Xspice contiene ms de cuarenta nuevos bloques funcionales, incluyendo:

sumadores, multiplicadores, integradores, modelos magnticos, limitadores, funciones

de transferencia en el dominio S, compuertas digitales, elementos de almacenamiento

digital, y una mquina de estados digitales generalizada.

Finalmente, Ngspice es una mezcla entre Spice, Xspice, y Cider. Esta ltima aplicacin

mejora la precisin de las simulaciones de dispositivos crticos, soportando la

descripcin de estos ltimos en trminos de estructuras y materiales.

En todos los casos, la interaccin con el usuario se realiza a travs de archivos de

descripcin de circuitos: netlist; los cuales incluyen una descripcin textual de los

circuitos a simular, las instrucciones que indican el tipo de simulacin a realizar, y

los parmetros necesarios para efectuar los anlisis.

2.3. Captura esquemtica y simulacin electrnica

MicroSim Corporation, compaa que actualmente pertenece a Cadence Design

Systems, el ao 1984 introdujo la primera versin de Spice para PCs18: Pspice. Siendo

esto un gran avance, este visionario grupo de ingenieros tuvo un logro que podracalificarse an ms significativo el ao 1991.

Bajo el lema de diseo desde el principio a fin, Microsim elabor DesignLab; el

primer sistema integrado para EDA, uniendo la captura esquemtica con la simulacin

electrnica, entre otras etapas del diseo de circuitos.

18PCs: Personal Computers.


21/106


En esta seccin se nombrarn las ventajas y desventajas de los programas disponibles

para realizar captura esquemtica y simulacin electrnica de forma integrada en

Linux; siendo sta, la misma tarea que busca asistir SpiceX.

2.3.1. Oregano

Oregano19 ha pasado por dos grandes ciclos de desarrollo durante su existencia. El

primer perodo transcurri desde su creacin el ao 1999 hasta su abandono el ao

2001; y el segundo perodo comenz el ao 2003, cuando el grupo LUGFI20 retom su

desarrollo hasta el da de hoy.

Esta aplicacin tiene caractersticas que se acercan bastante a los alcances propuestos

por SpiceX: es sencillo de utilizar, presenta una obvia similitud con la interfaz de

Pspice-Schematics, y dispone de una buena cantidad de componentes en sus libreras.

Adems, esta diseado para trabajar con cualquiera de los siguientes ncleos desimulacin derivados de Spice: Ngspice o Gnucap21.

Su principal desventaja, sin embargo, es el lenguaje de programacin utilizado en su

implementacin: C. Esta caracterstica hace difciles y tediosas las modificaciones del

cdigo fuente, obstaculizando el impulso grupal del proyecto.

El problema a llegado a tal punto que, actualmente, su desarrollo se encuentra detenido.

Los programadores del grupo LUGFI estn evaluando el rendimiento de segmentos

de cdigo en Python y C#, para as decidir el posible lenguaje a utilizar en futuras

versiones del programa. Los resultados parciales indican una ventaja para el segundo

lenguaje evaluado[10].

Lamentablemente, el abandono del proyecto es otra de las posibilidades a seguir por el

grupo de programadores, debido, principalmente, a la carencia de una metodologa de

diseo en la gnesis del programa[10].

19http://oregano.gforge.lug.fi.uba.ar/index.php20Grupo de Usuarios de GNU/Linux de la Facultad de Ingeniera de la Universidad de Buenos Aires.21http://www.gnu.org/software/gnucap/


22/106


2.3.2. Qucs

Qucs22 es otro intento por crear un entorno integrado de trabajo para la esquematizacin

y simulacin de circuitos electrnicos en Linux. Su desarrollo se encuentra en etapas

iniciales, debido a los ambiciosos objetivos propuestos por su grupo de desarrolladores.

A diferencia de SpiceX, Qucs no busca ser una interfaz de captura esquemtica para

ser utilizado con uno de los ncleos de simulacin actualmente disponibles; ste busca

la implementacin de un ncleo propio de simulacin, con toda la complejidad que

esto implica. A futuro, Qucs podra ser una opcin a considerar por electrnicos ya

acostumbrados al sistema operativo Linux.

En la actualidad, la aplicacin presenta las siguientes funcionalidades: anlisis AC,

anlisis DC, anlisis transiente, anlisis de ruido AC, entre otras. Adems, ya es posible

efectuar algunas simulaciones mixtas, entre componentes anlogos y digitales. Todo lo

anterior de forma grfica y asistida.

Finalmente, vale decir que el cdigo de Qucs est implementado en el lenguaje de

programacin C++, con todas las ventajas que esto acarrea desde el punto de vista de

evolucin del software.

2.3.3. KTechlab

KTechlab23 es un nuevo intento por crear un entorno integrado de trabajo para la

esquematizacin y simulacin de circuitos electrnicos en Linux. Su desarrollo se

encuentra en etapas iniciales, debido a los objetivos propuestos por su grupo de

desarrolladores: los cuales son incluso ms ambiciosos que los de Qucs.

Esta aplicacin, est orientada a la simulacin anloga y digital mixta, con especial

nfasis en la inclusin de dispositivos microcontroladores PICs24 en los circuitos.

Adems se pretende interactuar con dispositivos de hardware directamente conectadosal computador mediante los puertos serie y paralelo.

22http://qucs.sourceforge.net/index.html23http://ktechlab.org/24http://www.microchip.com/


23/106


El tipo de simulacin realizada por este programa se aleja de los profundos anlisis

efectuados por las aplicaciones de simulacin electrnica previamente vistas. El

anlisis as realizado se conoce como: simulacin de tiempo real. Dicha simulacin

podra compararse con el tipo de simulacin conseguida mediante otro de los programas

pioneros en la simulacin electrnica: Electronic Workbench.25

Actualmente, la aplicacin presenta las siguientes caractersticas: simulacin electr-

nica mixta, incluyendo la simulacin de PICs; disponibilidad de un osciloscopio para

la visualizacin de seales elctricas; simulacin lgica de alta velocidad; interaccin

con hardware a travs de los puertos serie y paralelo; y la programacin de microcon-

troladores PIC, mediante los lenguajes FlowCode26 o Microbe.

25http://www.electronicsworkbench.com/26Diagrama de flujos.


24/106

Captulo 3

Orientacin a Objetos

El primero de los alcances del proyecto enfatiza que SpiceX debe disponer de un

cdigo de fcil desarrollo y mantencin. Se pretende que la comunidad electrnica, con

conocimientos de programacin, pueda continuar su desarrollo; convirtindolo en la

utilidad que pretende ser, ms all del resultado parcial elaborado con fines acadmicos.

3.1. Principios

Un programa es un conjunto de instrucciones, escritas en un lenguaje de programacin,

destinadas a satisfacer distintas necesidades de usuarios. Cuando se implementa una

aplicacin en particular, se relaciona el entorno donde se presenta el problema y el

computador, que es la herramienta ejecutora de las acciones que proveen la solucin.

El entorno que agrupa todos los objetos o entidades1, que son administrados,

monitoreados o controlados por un sistema, recibe el nombre de dominio del problema.

De igual forma, el entorno donde se modela el problema, por ejemplo un computador,

recibe el nombre de dominio de la solucin[11].

El paradigma orientado a objetos es un enfoque de anlisis, diseo, e implementacinde una aplicacin, que provee una manera distinta de relacionar el dominio del

problema con el dominio de la solucin, produciendo las siguientes ventajas:

1Colectividad considerada como unidad. Lo que constituye la esencia o la forma de una cosa.

15


25/106

CAPTULO 3. ORIENTACIN A OBJETOS 16

facilidad de mantencin en las aplicaciones,

expansibilidad del cdigo implementado,

simplificacin del proceso de desarrollo;

lo cual concuerda con el primer alcance precisado para SpiceX.

3.1.1. Abstraccin

Las capacidades de los lenguajes de programacin imperativos, paradigma que precede

a la orientacin a objetos, inducen a relacionar el problema que se quiere solucionar con

la solucin en s, pensando en trminos de instrucciones computacionales. El esfuerzo

requerido para realizar esta asociacin, y el hecho de que esto es extrnseco al lenguaje

de programacin, produce programas difciles de escribir y mantener[6].

Por otra parte, los lenguajes orientados a objetos proveen herramientas para representar

objetos del problema que se est atacando, mediante objetos de software. Es decir,

se describe el problema a solucionar en trminos del problema, y no en trminos de

instrucciones computacionales.

La asociacin necesaria entre los dominios del problema y la solucin, recibe el nombre

de abstraccin. La abstraccin producida mediante lenguajes orientados a objetos es

ms flexible y poderosa que la producida mediante los lenguajes precedentes, debido

a que cuando se lee el cdigo describiendo la solucin, se estn leyendo palabras que

tambin expresan el problema. Esto ltimo se traduce en facilidad de mantencin y

expansin del software.

3.1.1.1. Abstraccin de un objeto

Si se observa por algunos segundos un entorno cualquiera, se puede identificar la vastacantidad de objetos que lo componen. Una lmpara, una mesa, una cama, dos espejos,

una puerta, etc. Pensando en modelar objetos de software, se puede enfocar la atencin

en solo un objeto, por ejemplo: la lmpara. Una posible descripcin de ste objeto,

basada en la figura 3.1, puede ser:


26/106


La lmpara es de color azul, tiene 30 cm de altura, y puede ser encendida

o apagada posicionando el interruptor en on u off, respectivamente.

Esta descripcin se basa en las caractersticas (datos), y comportamientos (funciona-

lidades) del objeto lmpara. Si bien los lenguajes imperativos proveen herramientas

para describir grupos de caractersticas (variables miembro) en una sola entidad:

la estructura; los lenguajes orientados a objetos aaden la capacidad de incluir

comportamientos (funciones miembro) a esas estructuras. Este nuevo tipo de entidad

de software recibe el nombre de clase.

La figura 3.2 muestra la abstraccin computacional del objeto lmpara. Esta abstraccin

no profundiza en otras caractersticas de la lmpara como son: voltaje, peso, volumen,

etc. La seleccin de caractersticas y comportamientos a ser modelados recibe el

nombre de nivel de abstraccin.

El nivel de abstraccin requerido, para relacionar objetos del dominio del problema

con objetos del dominio de la solucin, depender de la aplicacin en particular. Si se

quiere modelar una lmpara para un sistema de ventas en una tienda comercial, puede

ser necesario abstraer slo el modelo y el precio; en cambio, si se quiere modelar la

lmpara en el contexto de una aplicacin para administrar cargas en una compaa de

envo de paquetes, puede resultar necesario modelar, adems, el peso y volumen de la

lmpara.

Figura 3.1: Lmpara real.

Lampara

-color

-altura

-encendido

+encender()

+apagar()

Figura 3.2: Representacin en software.


27/106


3.1.1.2. Clases de objetos

La lmpara utilizada para realizar la abstraccin fue comprada en una tienda de

artculos para el hogar. Es as que existen cientos de lmparas con el mismo modelo en

el mercado, y sta viene a ser una ms entre tantas. Se puede decir que la abstraccin

realizada al objeto lmpara fue de la clase o modelo de sta, y no del elemento en

particular; ya que no se especifican las caractersticas propias del objeto en observacin:

color azul, altura igual a 30 cm, etc.

La ventaja de esto ltimo es que se pueden crear tantas lmparas como se desee

en nuestro programa, con el mismo patrn de caractersticas y comportamientos, y

utilizando una misma porcin de cdigo. As como existen los tipos de variables

predefinidos (por ejemplo: int), ahora se pueden crear clases de objetos (por ejemplo:

Lampara). Cuando se crea un objeto de la clase lmpara con caractersticas especficas,

as como se crean variables intque almacenan nmeros enteros especficos, se dice que

se crea una instancia de la clase. La instancia de una clase es lo que se conoce como

objeto.

3.1.1.3. Composicin de clases

El tratamiento que los lenguajes orientados a objetos dan a estas instancias de clases

es similar al de las variables normales; posibilitando la creacin de arrays de objetos,

objetos como parmetros de funciones o procedimientos, etctera. Incluso se pueden

utilizar objetos de una clase escrita previamente, en la composicin de nuevas clases.

Estos objetos reciben el nombre de objetos miembros de una clase.

Esta capacidad es un paso ms en la optimizacin de la abstraccin del dominio del

problema, ya que, generalmente, los objetos presentan esta caracterstica. La lmpara

esta compuesta por distintos objetos: ampolleta, enchufe, cable, pedestal, pantalla,

etctera. El nombre de esta caracterstica es composicin o agregacin, y determina

un tipo de relacin tiene-un, como en la frase: una lmpara tiene una ampolleta.

La diferencia entre los trminos composicin y agregacin esta determinada solo por

la utilidad del objeto miembro cuando no pertenece a la clase.


28/106


Si la clase del objeto miembro fue diseada solo para pertenecer a una clase, y no

tiene utilidad alguna trabajando de forma aislada, se dice que la caracterstica es una

agregacin. Un ejemplo de esto es el objeto cuello, el cual no tiene utilidad al no

pertenecer a la clase camisa. Por el contrario, si la clase del objeto miembro presenta

utilidad propia, se dice que la caracterstica es una composicin. Un ejemplo de esto es

el objeto trabajador, el cual tiene utilidad propia, independiente si pertenece o no a la

clase compaa.

En este punto se justifica que la orientacin a objetos produzca programas ms fciles

de entender, debido a la abstraccin mediante objetos; ms compactos, debido a la

reutilizacin del cdigo que proveen las clases; y, finalmente, ms fciles de programar,

debido a la posibilidad de descomponer el problema en objetos sencillos de entender

que luego pueden componer clases ms complejas.

3.1.2. Herramientas

Las herramientas que diferencian los lenguajes orientados a objetos de los lenguajes

imperativos, buscan proveer medios realistas de representacin para los objetos que

componen el entorno habitual de las personas, lugar donde se presentan los problemas

a solucionar.

3.1.2.1. Encapsulacin

Cuando se utiliza una lmpara, generalmente, no es necesario conocer en detalle el

mecanismo interno que gobierna el funcionamiento del objeto. Desde el punto de vista

del usuario de la lmpara, solo es necesario saber como conseguir o prescindir de

iluminacin: interruptor en On o interruptor en Off, respectivamente.

Los lenguajes orientados a objetos proveen un mecanismo para representar esta

simplicidad en el manejo de la informacin, al momento de trabajar con objetos: la

encapsulacin. As como en el dominio del problema existen usuarios y creadores 2 de

objetos, en el dominio de la solucin existen programadores clientes y creadores de

clases.2Se utiliza la palabra creadores y no fabricantes, debido a la existencia de objetos que no son producto

de procesos de fabricacin. Personas, animales, etc.


29/106


La encapsulacin separa la interfaz de la implementacin de una clase. La interfaz

es la informacin accesible por el programador cliente, necesaria para conocer la

funcionalidad que presenta el objeto. Por otra parte, la implementacin es el conjunto de

instrucciones que determinan las acciones a realizar, para entregar dicha funcionalidad.

Lampara

+encender()+apagar()

Figura 3.3: Interfaz del objeto de software Lmpara.

Esta caracterstica adiciona dos ventajas ms al simple hecho de mejorar la abstraccin

del mundo real. La primera es la de controlar el acceso de los programadores clientes a

la informacin crucial que mantiene la coherencia del objeto. Los clientes solo pueden

obtener o modificar caractersticas de un objeto: las variables miembro; mediante

procedimientos bien definidos previamente por el creador de la clase: las funciones

miembro. Para lograr este control se hace uso de los especificadores de acceso: private,

protected, public, al momento de programar una clase.

Los miembros, variables o funciones que conforman una clase, son los bloques de

cdigo que pueden ser marcados con alguno de los modificadores de acceso. Si el

miembro es una variable, por ejemplo la altura, se puede controlar el acceso a la

informacin; por otra parte, si el miembro es una funcin, por ejemplo la funcin

encender, se puede controlar el acceso a la funcionalidad.

Si el miembro esta marcado como private, el programador cliente no tiene acceso

directo a ste. Si el miembro esta marcado como protected, slo los programadores que

utilicen la clase como base3 para programar otras clases, podrn acceder directamente a

ste. Si el miembro esta marcado como public, todos los programadores clientes podrn

acceder directamente a ste.

3Las clases bases se utilizan mediante la herencia, mecanismo explicado en la siguiente seccin.


30/106


Finalmente, la segunda ventaja extra de la encapsulacin, es la de permitir la

modificacin u optimizacin de la implementacin, manteniendo intacta la interfaz. De

esta forma, las aplicaciones de los programadores clientes no se vern afectadas, por

mejoras en cualquiera de los algoritmos que conforman la funcionalidad del objeto.

3.1.2.2. Herencia

Hasta ahora, se sabe que a travs de las clases de objetos se puede reutilizar cdigopreviamente escrito; aprovechando la similitud en las caractersticas y funcionalidades

de los distintos elementos que componen el mundo real. Pero, qu sucede si se

quiere modelar un objeto ligeramente distinto, es decir, con alguna caracterstica y/o

funcionalidad extra?.

Para reutilizar cdigo y expandir caractersticas y funcionalidades de un objeto, los

lenguajes orientados a objetos disponen de la herencia. Siguiendo con el ejemplo de

la lmpara, se puede decir que sta hereda las caractersticas y funcionalidades de un

electrodomstico. ste ltimo se puede enchufar, desenchufar, presenta un voltaje de

operacin, etctera. Es as que se podra haber creado una clase electrodomstico,

agrupando todas las caractersticas y comportamientos comunes de este tipo de

elementos, y despus heredar los miembros en futuras clases especializadas, como la

lmpara.

La clase de la cual se heredan las caractersticas y funcionalidades recibe el nombre de:

clase base, super clase, o clase padre. Asimismo, la clase que hereda las caractersticas

o funcionalidades recibe el nombre de: clase derivada, clase heredada, subclase, o clase

hija.

La herencia posibilita no slo la adicin de nuevos miembros a las clases, reutilizando

el cdigo de las clases bases, sino que tambin permite la modificacin de miembros

ya existentes. Si se quiere cambiar alguna caracterstica o comportamiento de un objetoderivado, solo hace falta sobreescribir 4 el miembro, en la implementacin de la nueva

clase.

4Por ejemplo, en algunos lenguajes de programacin esto se logra mediante la utilizacin de las

palabras claves override o new (C++ o C#, respectivamente).


31/106


La relacin que la herencia determina entre la clase base y la derivada recibe el nombre

de relacin es-un, en el caso de mantener intacta la interfaz de la clase derivada;

y el nombre de relacin es-como-un, en el caso de adicionar nuevos miembros a

la interfaz de la clase derivada. Obviamente, se asume que en el caso de presentarse

una relacin es-un, se sobreescribe algn miembro. De no ser as la aplicacin de la

herencia no tendra sentido.

Al igual que la encapsulacin, esta herramienta de los lenguajes orientados a objetos

tambin adiciona dos ventajas extras a la inherente mejora en la abstraccin de la

realidad. La primera de stas es la obvia reutilizacin de cdigo por parte de los

creadores de clases, los cuales implementan nuevas clases a travs de la herencia; y la

segunda es que posibilita la aplicacin del polimorfismo, herramienta de la orientacin

a objetos explicada en la siguiente seccin.

Generalmente se utiliza la frase reutilizacin de la implementacin, haciendo referencia

a la ventaja de implementar clases con objetos miembros, adems de la creacin de

objetos a partir de clases genricas; y la frase reutilizacin de la interfaz, para hacer

referencia a la ventaja de heredar las caractersticas y funcionalidades de un objeto.

3.1.2.3. Polimorfismo

Previamente, se dijo que la lmpara es un electrodomstico. Una de las funcionalidades

comunes en cada uno de estos elementos es que se pueden prender o apagar, y aunque

no todos los electrodomsticos operan de la misma forma, se tiene una idea general de

como proceder para lograr estas funcionalidades.

Generalmente, no es necesario describir a los usuarios de una sala de computadores:

Cuando se abandone la sala, apagar: el computador presionando el botn rojo en

la torre, el monitor presionando el botn blanco, los parlantes girando la perilla en

contra sentido de reloj, y la luz de la habitacin posicionando el interruptor en off.Un instructivo de uso ms realista podra ser: Cuando se abandone la sala, dejar todo

apagado.


32/106


Los lenguajes orientados a objetos disponen del polimorfismo para abstraer esta

versatilidad de accin en las personas, con la diferencia de que en el dominio de la

solucin, las acciones son efectuadas por el computador. Esto ltimo permite escribir

cdigo (el instructivo de operacin en el mundo real) independiente de tipos o clases

especficas (cada uno de los equipos electrnicos en la sala de computadores).

Pensando en trminos del dominio de la solucin, se podra crear un array de objetos

tipo electrodomstico, y despus aplicar la funcin apagar a cada uno de los objetos

que componen el vector. Lo increble en esta funcionalidad, es que los objetos que

conforman el array podran pertenecer a diferentes clases derivadas de la clase base

electrodomstico, con acciones especficas en la implementacin del procedimiento de

apagado.

Para lograr esto, al momento de implementar una clase base, que se piensa presentar

una funcin genrica pero diferente en cada una de las clases derivadas, se debe marcar

dicha funcin miembro como virtual. Luego, al aplicar herencia para crear las clases

derivadas, se debe implementar las funciones virtuales con acciones especficas que se

adapten a cada objeto.

La diferencia entre esta forma de implementacin y la simple sobre-escritura de

funciones, adems de la posibilidad de aplicar polimorfismo, radica en la determinacin

de la funcin a ejecutar. Mientras que en la simple sobre-escritura de funciones se

decide en tiempo de compilacin, en la sobre-escritura de funciones virtuales, se decideen tiempo de ejecucin. Por lo tanto, al momento de implementar polimorfismo, se debe

considerar el costo en velocidad que determina la aplicacin de este mecanismo.

La principal ventaja del polimorfismo es que: as como se podra adicionar un nuevo

electrodomstico a la sala de computadores, sin necesidad de modificar el instructivo

de uso; se podra adicionar una nueva clase derivada al array de electrodomsticos, sin

modificar las funciones que operan con la clase base del vector original. Es decir, se

facilita la evolucin del software.


33/106


3.2. Metodologa

La metodologa a seguir ser aplicada dentro de las distintas disciplinas que conforman

el proceso de desarrollo, es por esto que conviene tener claro los objetivos de cada

una de stas. Primero que nada, se conoce por anlisis a la investigacin enfocada al

problema y sus requerimientos. Para seguir, el trmino diseo enfatiza una solucin

conceptual que satisface dichos requerimientos5. Y finalmente, la programacin es la

implementacin, mediante algn lenguaje de programacin, del diseo previamente

creado6.

3.2.1. Enfoque

El programador que pretenda sacar provecho a los lenguajes orientados a objetos,

debera comenzar por cambiar el enfoque de anlisis, diseo, e implementacin de

las aplicaciones a desarrollar. De no ser as, los programas implementados carecen de

ventajas frente a los desarrollados mediante lenguajes imperativos7.

A continuacin se presentan cinco consejos de enfoque para aplicar la orientacin a

objetos[6]:

1. Cada cosa es un objeto: En teora, se puede tomar cualquier componente

conceptual del problema y representarlo como un objeto en el programa.

2. Un programa es un manojo de objetos intercambiando instrucciones, mediante

el envo de mensajes: Para solicitar alguna funcionalidad a un objeto, se debe de

enviar un mensaje a ste.

3. Cada objeto est compuesto por otros objetos: De esta forma, se puede

implementar la complejidad de un programa, escondida detrs de la simplicidad

de los objetos.5Se dice que en el anlisis se construye un modelo del dominio del problema, mientras que en el

diseo se construye un modelo del dominio de la solucin.6Generalmente, la programacin recibe el nombre de implementacin.7La carencia de ventajas es especialmente cierta cuando se trabaja con lenguajes orientados a objetos

que permiten, adems, la programacin imperativa. C++ es un ejemplo.


34/106


4. Cada objeto pertenece a una clase: La principal caracterstica que distingue a una

clase es: Qu mensajes se pueden enviar a sta?.

5. Todos los objetos de una clase en particular pueden recibir los mismos mensajes:

La capacidad de reemplazar los objetos es uno de los conceptos ms poderosos

de la orientacin a objetos.

3.2.2. Procesos de desarrollo

Para comenzar el desarrollo de cualquier programa informtico, se debe elegir una

metodologa de trabajo que se adecue a los alcances del proyecto. Informalmente, un

proceso de desarrollo de software es una metodologa para la construccin, entrega8, y

posible mantencin del software[9].

Cuando se programa en lenguajes imperativos, es difcil efectuar cambios en el cdigo

una vez que se ha comenzado la implementacin. Es por esto que se requiere de

metodologas detallistas, al momento de analizar y disear aplicaciones complejas. El

problema surge cuando se presenta una parlisis del anlisis, debido a que hay detalles

en la aplicacin que no sern observables sino hasta el diseo, la implementacin, e

inclusive la prueba del programa[9].

Por el contrario, los lenguajes orientados a objetos facilitan la comprensin, reutiliza-

cin, y expansin del cdigo, simplificando los procesos de desarrollo requeridos. Lasiteraciones, pequeos ciclos de anlisis, diseo, implementacin, y prueba de mdu-

los de la aplicacin final, conforman, hoy en da, el mecanismo de trabajo ms reco-

mendado. Los metodologas basadas en iteraciones, reciben el nombre de procesos de

desarrollo iterativos.

Gracias a la orientacin a objetos, al trabajar con iteraciones se produce informacin

relevante y cdigo utilizable en los siguientes ciclos de desarrollo, es decir, en las

futuras iteraciones.8Entrega de versiones de una aplicacin.


35/106


3.2.3. Pautas a seguir

La experiencia acumulada por programadores experimentados en orientacin a objetos,

genera ciertas pautas a considerar al momento de aplicar el paradigma[6].

1. Primero se debe hacer que el cdigo trabaje, luego que sea rpido. Esto es cierto

an si se sabe que una pieza de cdigo es realmente importante y que ser uno de

los principales cuellos de botella del sistema. Se debera comenzar a trabajar conel diseo ms simple que se pueda; luego, si el cdigo no es lo suficientemente

rpido, se debera mejorar. Casi siempre se descubrir que el cuello de botella no

es lo importante. Se debe ocupar el tiempo en las cosas realmente importantes.

2. Recordar el principio "divide y conquistars". Si el problema que se est

tratando de solucionar es demasiado confuso, se debe intentar imaginar cul es la

operacin bsica que el programa debera llevar a cabo, suponiendo la existencia

de una pieza mgica del programa que manejar las partes complicadas. Esa pieza

de programa ser un objeto. Se debe escribir el cdigo que utilizar ese objeto,

y despus, al enfocarse en ste, se deben encapsular sus partes complicadas en

otros objetos, etctera.

3. El control de acceso permite modificar la clase tanto como sea posible, sin daar

el cdigo del cliente en el cual la clase est siendo utilizada. Con esto en mente,

se debe hacer private cada cosa que sea posible, y hacer slo la interfaz de la

clase public, usando funciones en vez de datos. Los datos deberan ser public solo

cuando sea totalmente necesario. Si una clase no necesita acceder a una funcin,

se debera hacer private. Si una parte de la clase ser expuesta a la herencia como

protected, se debe proveer una interfaz de funciones mejor que exponer los datos.

De esta forma, los cambios en la interfaz tendrn un mnimo impacto en las clases

derivadas.

4. No caer en la parlisis del anlisis. Hay algunas cosas que no se comprendern

hasta que se comience a codificar y/o tener algn tipo de sistema corriendo. Los

errores en una clase o un set de clases no destruirn la integridad del sistema

completo.


36/106


5. El anlisis y diseo debe producir, al menos, las clases del sistema, sus interfaces

pblicas, y sus relaciones con otras clases; especialmente las clases bases. Si

la metodologa de diseo produce ms que esto, se debe cuestionar si todas

las piezas producidas por esa metodologa tienen valor durante el ciclo de vida

del programa. Si no la tienen, la mantencin de stas tendr un costo para el

programador. Los miembros de grupos de desarrollo tienden a no mantener nada

que no contribuya a su productividad; es totalmente cierto que muchos mtodos

de diseo no valen la pena.


37/106

Captulo 4

Rational Unified Process - RUP

El segundo de los alcances del proyecto enfatiza la utilidad de SpiceX al momento

de finalizar la memoria. Aunque la aplicacin no pretende cubrir cada una de las

posibilidades del ncleo de simulacin, desde el punto de vista de libreras electrnicas

disponibles en Spice, sta debera ser una interfaz ejecutable, testeable, y funcional.

4.1. Principios

En el captulo 3, se menciona que la orientacin a objetos necesita ser presentada

en el contexto de un proceso de desarrollo. El Rational Unified Process, ofrece una

metodologa de desarrollo de software para construir sistemas orientados a objetos, lacual satisface las caractersticas de un proceso de desarrollo iterativo y adaptativo1.

Entre sus ventajas se encuentran:

mitigacin temprana de riesgos importantes,

progreso de la aplicacin visible desde un comienzo,

realimentacin y adaptacin a los requerimientos de usuario, durante todo elproceso de desarrollo,

simplicidad en la administracin del proyecto,

mejoramiento del proceso de desarrollo en s, iteracin por iteracin;

1Adaptativo, va: adj. Perteneciente o relativo a la adaptacin o la capacidad de adaptacin. Artculo

nuevo. Avance de la vigsima tercera edicin del diccionario de la Real Academia Espaola.

28


38/106

CAPTULO 4. RATIONAL UNIFIED PROCESS - RUP 29

lo cual concuerda con los dos primeros alcances precisados para SpiceX.

4.1.1. Proceso de desarrollo iterativo

El ciclo de desarrollo de una aplicacin, es el perodo de tiempo que transcurre desde

que se comienza la planificacin del proyecto, hasta que se libera una versin estable

o lista para la produccin. En el RUP, el ciclo de desarrollo est basado en la sucesiva

ampliacin y refinamiento de un sistema a travs de mltiples iteraciones, las cuales

establecen sus bases en la realimentacin y adaptacin cclica para converger a un

sistema que satisfaga al usuario.

Figura 4.1: Desarrollo Iterativo e Incremental.

4.1.2. Administracin de los requerimientos

La metodologa del RUP se enfoca principalmente en afrontar cambios de los

requerimientos, los cuales son capacidades y condiciones que conforman un sistema.

Esta caracterstica en un proceso de desarrollo se denomina: administracin de los

requerimientos[9].

Los procesos de desarrollo utilizados por los lenguajes imperativos, tratan de obtener

los requerimientos finales de usuario cuando se comienza la planificacin del sistema.

Es por esto que se comienza con un largo perodo de anlisis de requerimientos, lo cual

acarrea dos inconvenientes:

el riesgo de caer en la parlisis del anlisis, y


39/106


la inflexibilidad frente a los cambios en los requerimientos de usuario, una vez

comenzado el desarrollo.

Por el contrario, el RUP provee una muestra de lo que se est haciendo al usuario, para

ver si coincide con lo que realmente desea. El proceso de desarrollo est preparado para

enfrentar los cambios en las exigencias del usuario, debido a:

las facilidades de mantencin y expansin del software que provee el paradigmaorientado a objetos, y

al mecanismo de trabajo basado en iteraciones.

Esto no quiere decir que la direccin a la cual apunta el proyecto cambiar de forma

continua durante todo el desarrollo. Slo se tiene conciencia de la posibilidad de haber

malentendido los requerimientos iniciales del usuario, y del cambio en las exigencias,

una vez iniciado el desarrollo del sistema2. Al final del ciclo de desarrollo, la aplicacin

debera satisfacer completamente al usuario.

En el caso de haberla, la diferencia entre lo que tiene en mente el usuario y lo

que se est desarrollando, debera ser ms grande en un comienzo del ciclo de

desarrollo; perodo en el cual se obtienen las primeras realimentaciones y se realizan

las primeras adaptaciones. Esta caracterstica determina una temprana mitigacin de

riesgos importantes.

Adems, no es necesario sobre dimensionar el anlisis de los requerimientos, ya

que las iteraciones proveen la flexibilidad para comenzar un desarrollo confiado y

abierto a las correcciones. Esto disminuye enormemente los gastos en la administracin

del proyecto, la cual se encarga, principalmente, de realizar exhaustivos procesos de

visualizacin de futuros requerimientos. En el RUP los requerimientos futuros no slo

se visualizan, sino que tambin se acogen.

2Una vez que el usuario tiene las acceso a los adelantos del sistema final producidos por las

iteraciones, podra, fcilmente, cambiar o adicionar exigencias que no visualiz en un comienzo.


40/106


4.1.3. Estructura del RUP

Para el RUP, un ciclo de desarrollo consta de cuatro fases: Concepcin, Elaboracin,

Construccin y Transicin; cada una compuesta por una serie de iteraciones. A la

vez, en cada iteracin se ejecutan disciplinas o work-flows, las cuales utilizan varios

artefactos para lograr sus objetivos. Aunque no se conozca el significado y objetivo

de cada uno de los trminos aqu mencionados, se presentan de forma adelantada para

estructurar el proceso, como se muestra en la figura 4.2.

Figura 4.2: Fases e iteraciones en el RUP.

4.2. Metodologa

4.2.1. Fases

Las fases que componen el RUP se diferencian entre s, bsicamente, por la importancia

de los requerimientos abordados. A continuacin se presenta la descripcin de cada una

de las etapas que componen un ciclo de desarrollo:

4.2.1.1. Concepcin

En esta fase se establece un punto vista comn de los objetivos del proyecto, se

determina si es factible de realizar, y se decide si merece una investigacin ms seria

en la fase de elaboracin. Se dice que en esta fase se mitigan los riesgos de negocios de

la aplicacin; aqullos relacionados con la factibilidad econmica del proyecto.


41/106


Si se ha decidido con anterioridad que el proyecto ser realizado, y es claramente

factible, entonces la fase de concepcin podra ser sumamente corta3. En este caso,

podra incluir las primeras actividades de anlisis de requerimientos, y los planes a

seguir durante la primera iteracin. Despus de esto, se debera comenzar de inmediato

la fase de elaboracin.

Los artefactos que se comiencen a utilizar en concepcin se completarn slo de forma

parcial, debido a que sern refinados, una y otra vez, en las siguientes iteraciones.

4.2.1.2. Elaboracin

Esta fase est compuesta por la serie inicial de iteraciones, durante las cuales el

grupo realiza una investigacin seria, implementa (programa y prueba) la arquitectura

principal de la aplicacin, clarifica la mayora de los requerimientos, y aborda los

asuntos de alto riesgo. Se dice que en esta fase se mitigan los riesgos tcnicos del

programa.

La elaboracin a menudo consiste entre dos a cuatro iteraciones; cada una con una

duracin recomendada entre dos a seis semanas, al menos que se trate de un grupo

de desarrolladores masivo. Adems, cada iteracin debera terminar siempre con una

versin estable y probada de los requerimientos que implemente.

4.2.1.3. Construccin

Es la fase donde se abordan los riesgos menos importantes que quedan en el proyecto,

y se prepara la entrega de la aplicacin. Durante la construccin, la mayor parte del

tiempo se dedica al perfeccionamiento del diseo y de la implementacin, y a detallados

tests de la aplicacin; para as, finalmente, converger a un sistema completo.

Se debe recordar que hasta ahora, muchos casos de uso no han sido implementados, y

los que han sido abordados, se han completado solo de forma parcial; lo suficiente para

validar algunas hiptesis, o mitigar los riesgos principales. Se han definido subsistemas

e implementado interfaces; sin embargo, slo una pequea parte del cdigo final ha

sido escrito (principales escenarios de casos de uso, flujos alternativos de eventos, y

manejo de errores). Es por esto que la mayor parte del trabajo an no est hecho[8].

3Esta es la situacin en la que se encuentra SpiceX.


42/106


Los requerimientos implementados en construccin no deberan variar mayormente la

arquitectura del sistema; de no ser as, se ha hecho un mal trabajo durante la etapa de

elaboracin. Debido a que se desarrolla un cdigo de alta calidad, la mayor parte del

tiempo se dedica a la fase de construccin; usualmente entre tres a seis iteraciones, de

menor duracin que las iteraciones de la fase de elaboracin.

4.2.1.4. Transicin

La fase de construccin termina con una versin beta del sistema, la cual debera ser

completamente funcional, e incluir: instalador, documentacin de ayuda, y algunos

ejemplos de uso del programa. Sin embargo, se sabe que esta versin no es el producto

final, y que necesita ser refinada en cuanto a funcionalidad, rendimiento y calidad en

general.

Durante la transicin normalmente se desarrollan una o dos iteraciones que incluyen:

tests del producto, preparndolo as para la primera entrega; y ajustes menores basados

en la realimentacin de los usuarios. En esta fase tambin se pueden completar

funcionalidades remanentes, que han sido postergadas debido a los plazos fijos de

tiempo determinados para las iteraciones.

4.2.2. Iteraciones

En un proceso de desarrollo iterativo, el trabajo es organizado en iteraciones, las cuales

son una serie de pequeos mini proyectos de duracin fija. El producto de cada una de

estas iteraciones es un sistema probado, integrado, y ejecutable. Cada iteracin incluye

sus propias actividades de anlisis, diseo, implementacin, y prueba[9].

El resultado de cada iteracin es un sistema ejecutable pero incompleto; ste no est

listo para la produccin. El sistema puede necesitar varias iteraciones antes de estar

listo para la produccin; por ejemplo, 10 o 15 iteraciones. Sin embargo, el resultado

producido por cada iteracin no es descartable, ste se reutilizar, mejorar o ampliar

en las siguientes iteraciones. La orientacin a objetos posibilita la aplicacin de este

mecanismo de trabajo.


43/106


La duracin de cada iteracin debera ser de entre dos a seis semanas. Menos tiempo,

implicara producir sistemas carentes de suficiente informacin para obtener una

realimentacin de valor; ms tiempo, implicara aumentar los riesgos del proyecto, al no

recibir realimentacin a tiempo. En el caso de prever que no se alcanzarn a cumplir los

objetivos planteados para la iteracin en curso, es conveniente posponer el tratamiento

de algunos requerimientos para futuras iteraciones. Nunca se debe posponer la fecha

de trmino de la presente iteracin.

Aunque, en general, cada iteracin aborda nuevos requerimientos e incrementalmente

extiende el sistema, una iteracin puede ocasionalmente revisar el software existente y

mejorarlo.

4.2.3. Disciplinas

Las disciplinas son conjuntos de actividades, y artefactos relacionados con stas,enfocados a tratar un mismo tema en particular; por ejemplo, todas las actividades

enfocadas a analizar los requerimientos del sistema. Todas las pautas de trabajo del

RUP, caen dentro de alguna disciplina. Un artefacto es el trmino general empleado

para describir el producto de algn trabajo; por ejemplo, esquemas de bases de datos,

documentos de texto, diagramas, modelos, etctera.

Existe una variada cantidad de disciplinas orientadas a diferentes reas del desarrollo

de un sistema; sin embargo, y basndose en las pautas de desarrollo presentadas en el

captulo 3, slo se mencionarn las que van a ser utilizadas durante el desarrollo de

SpiceX.

4.2.3.1. Administracin del Proyecto

Es el conjunto de todas las actividades enfocadas a organizar el trabajo a realizar

durante la ejecucin del RUP.

No se debe confundir esta disciplina con un calendario estricto de actividades. No es el

detalle todos los pasos a seguir durante la completa ejecucin del ciclo de desarrollo.

Para lograr esto, se deberan conocer por adelantado todos los requerimientos que

tienen y tendrn los usuarios, lo cual contradice los principios del RUP.


44/106


Ms bien se trata de dos clases de actividades agrupadas en una sola disciplina: las

que describen los macro-objetivos del proyecto, dejando abiertas las especificaciones

de cmo lograr esto; y las que describen los micro-objetivos del proyecto, qu son los

pasos a seguir en el corto plazo para implementar requerimientos y funcionalidades.

Estas dos clases de actividades se relacionan directamente, ya que los micro-objetivos

buscan satisfacer de forma adaptativa e incremental los macro-objetivos.

4.2.3.2. Requerimientos (Anlisis)

Es el conjunto de todas las actividades enfocadas al anlisis de requerimientos de una

aplicacin, como son la escritura de casos de usos y la identificacin de requerimientos

no-funcionales.

El primer objetivo de un trabajo en el rea de los requerimientos es encontrar,

comunicar, y recordar lo que es realmente necesario, de forma clara para el usuarioy el desarrollador.

4.2.3.3. Modelo de Negocio (Anlisis)

Es el conjunto de todas las actividades enfocadas a modelar el contexto del negocio, y

el alcance del sistema.

4.2.3.4. Diseo

Es el conjunto de todas las actividades enfocadas al diseo del proyecto, incluyendo la

totalidad de la arquitectura, objetos, bases de datos, redes, etctera.

4.2.3.5. Implementacin

Es el conjunto de todas las actividades enfocadas a la programacin y construccin del

sistema, dejando de lado la entrega de la aplicacin.

A medida que se avanza en las fases del desarrollo, las disciplinas cambian su nivel

de importancia. Por ejemplo, en la fase de elaboracin, puede que las disciplinas

de requerimientos y diseo sean las ms importantes; sin embargo, en la fase


45/106


de construccin, cuando los riesgos ms importantes ya han sido mitigados y la

arquitectura principal no se espera vare mucho, la disciplina de implementacin toma

mayor importancia.

4.2.4. Artefactos

Como se mencion con anterioridad, los artefactos son herramientas que ayudarn

a cumplir los objetivos planteados por cada disciplina. Las iteraciones hacen uso

reiterado de las distintas disciplinas para el desarrollo de cada mini-sistema; es por

esto que sera incorrecto asociar una disciplina, y por ende, determinados artefactos a

una fase en particular.

Se debe tener claro que los artefactos son una ayuda para el desarrollo del proyecto, y

no una obligacin. En la prctica, se debera seleccionar un subconjunto determinado de

artefactos a implementar, los cuales aportarn valor al proyecto. Ni siquiera es necesarioterminar en su plenitud los artefactos en curso; slo se deberan madurar hasta un nivel

suficiente, el cual permita tomar decisiones acertadas en base a stos[8].

A continuacin se presentarn algunos artefactos, y se indicar las disciplinas a las

cuales asisten4.

4.2.4.1. Modelo de Casos de Uso

Este artefacto, utilizado dentro de la disciplina de requerimientos, describe los

requerimientos funcionales de un sistema. Adems, es utilizado para obtener los

requerimientos no funcionales relacionados con stos ltimos.

Antes de profundizar en la descripcin del artefacto, resulta conveniente dar a conocer

algunas definiciones relacionadas con ste:

Actor: Es algo con comportamiento, como una persona (identificada por un rol), un

sistema computacional, o una organizacin; por ejemplo, un cajero.

Escenario: Es una secuencia especfica de acciones e interacciones entre actores y

el sistema bajo discusin; tambin se conoce como instancia de caso de uso.

4Para ejemplos, dirigirse al Captulo 5: Desarrollo de SpiceX.


46/106


Pensando en SpiceX, simular con xito un circuito electrnico, o fallar una

simulacin debido a una conexin elctrica errnea, son ejemplos de escenarios.

Segn el RUP, un caso de uso es un conjunto de escenarios, donde cada uno de stos es

una secuencia de acciones que un sistema realiza para otorgar un resultado observable

y de inters para algn actor. Sabiendo esto, el modelo de casos de usos es el conjunto

de todos los casos de usos de un sistema; un modelo de la funcionalidad del sistema y

su contexto.

De acuerdo con la visibilidad en la descripcin de un caso de uso, estos pueden

clasificarse en los tipos: black-box y white-box. Los casos de uso del tipo black-

box son los ms usados y recomendados, y especifican lo que debe hacer el sistema

(requerimientos funcionales) sin preocuparse de como lo har (diseo). En los casos de

uso con visibilidad white-box se describen, adems, detalles que corresponden a la fase

de diseo.

Debido a que este artefacto se presenta dentro de un proceso de desarrollo iterativo que

busca construir sistemas orientados a objetos, resulta adecuado escribir los casos de uso

con visibilidad del tipo black-box; la cual presenta una similitud directa con el concepto

de encapsulacin, estudiado en el capitulo 3.

Por otra parte, de acuerdo a las necesidades, los casos de usos pueden ser escritos con

distintos grados de formalidad, los cuales se describen a continuacin:

Breve: conciso resumen en un prrafo, que describe usualmente el escenario principal

ejecutado con xito.

Casual: varios prrafos informales, los cuales cubren varios escenarios.

Completo: formato ms elaborado, que cubre todos los pasos y variaciones en detalle.

Presenta secciones de soporte, como precondiciones y xitos garantizados.


47/106


Descubriendo casos de uso

Cuando se trabaje con casos de uso, los esfuerzos deberan enfocarse en responder

Cmo se puede proveer valor observable al usuario, o satisfacer sus objetivos,

utilizando el sistema?, en vez de pensar en los requerimientos del sistema como una

simple lista de caractersticas o funciones.

Existen innumerables interacciones entre los usuarios y un sistema. A continuacin sedescribe una estrategia para discriminar casos de uso de poca utilidad, y seleccionar

aqullos que conformarn el grupo de casos de uso base.

Un Proceso de Negocio Elemental, o EBP5, es un trmino del rea de ingeniera de

procesos de negocio, definido como:

Una tarea realizada por una persona, en un lugar, y en un momento

determinado, en respuesta a un evento de negocios, el cual adiciona

valor de negocio medible y deja los datos en un estado consistente.

Por ejemplo, la aprobacin de crdito o una orden de precio.

Dicho esto, la pauta a seguir en el RUP, es: para el anlisis de los requerimientos de

una aplicacin computacional, se deben enfocar los casos de uso a nivel de proceso de

negocio elemental[9].

Aunque la pauta debera seguirse de forma literal para encontrar los casos de uso base,

existen algunas excepciones que llevan a considerar como casos de uso a interacciones

de bajo nivel y que no satisfacen la descripcin de un EBP.

Entre estas interacciones podran considerarse: subfunciones comnmente utilizadas

por casos de uso base, y as evitar la duplicacin de texto; y aquellas subfunciones que

podran formar parte de las precondiciones de casos de uso base, en repetidas ocasiones.

Por ejemplo, el medio de pago a travs de tarjeta de crdito, o la identificacin de unusuario, en cada caso.

5Elementary Business Process.


48/106


Casos de uso y objetivos de usuario

Pensando en satisfacer los objetivos de usuarios, los pasos recomendados para la

escritura de casos de uso son:

1. escoger los lmites del sistema,

preguntndose si el sistema es slo una aplicacin de software, hardware y

software como una unidad, todo esto ms una persona usando el sistema, o una

organizacin completa;

2. identificar los actores primarios,

que son aqullos que tienen objetivos de usuario satisfechos directamente a travs

del uso de servicios del sistema;

3. identificar los objetivos de los actores primarios,

llevando stos a un nivel que satisfaga la pauta del EBP;

4. y finalmente, definir los casos de usos,

los cuales satisfarn los objetivos de usuario. Los casos de uso deberan ser

nombrados de acuerdo a su objetivo, y comenzando por un verbo. Por ejemplo,

para el objetivo: procesar una venta, el nombre del caso de uso podra ser:

Procesar Venta.

Casos de uso y fases del RUP

Los casos de uso son centrales y de vital importancia para el RUP, el cual anima un

desarrollo dirigido por stos. Esto implica que:

los requerimientos son primeramente capturados en casos de uso (en el modelode casos de uso);

los casos de uso son parte importante del plan de iteracin. De hecho, el trabajo

de una iteracin es, en parte, definido por la eleccin de algunos escenarios, o


49/106


casos de uso completos6. Adems, los casos de uso son la fuente de informacin

principal para realizar una estimacin;

la realizacin de casos de uso gua el diseo. Esto significa, que el grupo de

desarrolladores disea objetos y subsistemas colaborando entre s, para ejecutar

o realizar casos de uso;

los casos de uso a menudo influencian la organizacin de los manuales de usuario.

A continuacin se describe el grado de formalidad que deberan presentar los casos de

uso, a medida que se completan las fases del RUP.

Concepcin: dentro de esta fase, la mayora de los casos de uso y actores son

identificados. Adems, se escribe entre el 10 y 20% de los casos de usos en

forma completa y detallada.

Elaboracin: dentro de esta fase se escribe entre el 80 y 90% de los casos de uso

en forma completa y detallada. Los casos de uso abordados s

gar cia civil engineering thesis

Documents