PONTIFICIA UNIVERSIDAD CATÓLICA DE CHILE

ESCUELA DE INGENIERÍA
DEPARTAMENTO DE CIENCIA DE LA COMPUTACIÓN
IIC 1102 INTRODUCCIÓN A LA PROGRAMACIÓN
Profesor: Rodrigo Sandoval U.

Capítulo I - Resolución de Problemas

1 CONCEPTOS DE RESOLUCIÓN DE PROBLEMAS.................................................................................... 1

1.1 EL PROCESO DE RESOLUCIÓN DE PROBLEMAS ................................................................................................. 1
1.2 DEFINICIONES ................................................................................................................................................. 1
1.2.1 Problema ................................................................................................................................................ 1
1.2.2 Objeto..................................................................................................................................................... 2
1.2.3 Instancia................................................................................................................................................. 2
1.2.4 Modelo ................................................................................................................................................... 2
1.3 ALGORITMOS .................................................................................................................................................. 2
1.3.1 ¿Qué es un Algoritmo?........................................................................................................................... 2
1.3.2 ¿Cómo se especifican o describen los algoritmos?................................................................................ 3
1.3.3 ¿Existe un único algoritmo de solución? ............................................................................................... 3
1.3.4 ¿Qué es una metodología? ..................................................................................................................... 3
1.3.5 Las soluciones también pueden tener problemas ................................................................................... 4
2 ORIENTACIÓN A OBJETOS ........................................................................................................................... 5
2.1 TERMINOLOGÍA BÁSICA DE LA PROGRAMACIÓN ORIENTADA A OBJETO ........................................................ 6
3 ESTRATEGIAS PARA LA SOLUCIÓN DE PROBLEMAS .......................................................................... 7
3.1 METODOLOGÍA DE RESOLUCIÓN DE PROBLEMAS............................................................................................ 7
3.2 DESCRIPCIÓN GRÁFICA DE SOLUCIONES ......................................................................................................... 8
3.2.1 Diagrama de Casos de Uso - UML ........................................................................................................ 8
3.2.2 Diagrama de Clases – UML................................................................................................................... 9
3.2.3 Árboles de Decisión ............................................................................................................................. 10
3.2.4 Ejemplo: Árbol de Decisión: ¿Qué hago el sábado por la noche? ...................................................... 10
3.3 EJEMPLOS DE APLICACIÓN DE LA METODOLOGÍA ......................................................................................... 11
3.3.1 Simulando la Ejecución de un Penal.................................................................................................... 11
3.3.2 Simulando la preparación de un pastel................................................................................................ 14
3.3.3 Cambio de neumático desinflado ......................................................................................................... 16
3.3.4 Llamada Telefónica.............................................................................................................................. 18

Material preparado por Rodrigo Sandoval U en Marzo 2004,

basado en los apuntes de clase del curso IIC1102, año 2003, de M. Nussbaum, Marcos Sepúlveda, et.al
Los ejemplos fueron adaptados por MSR Lab del DCC de la Escuela de Ingeniería de la P. Universidad Católica de Chile
Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

1 Conceptos de Resolución de Problemas

Resolver problemas no es trivial, pues es necesario comprender qué se quiere resolver, encontrar las
herramientas adecuadas para resolver el problema, y luego implementar la solución con las herramientas
disponibles.

1.1 El proceso de resolución de problemas

1.2 Definiciones

1.2.1 Problema
Un problema es una abstracción de la realidad para la cual nos interesa conocer una solución,
entendiendo que una solución altera el estado inicial del problema, llevándolo a un estado deseado. Es
decir, una solución es un procedimiento o método para establecer el mecanismo de transformación del
mundo que nos lleve a satisfacer ciertos requerimientos.

IIC 1102 Página: 1

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

1.2.2 Objeto
El mundo está compuesto de objetos físicos y simbólicos. Los “objetos” en programación OO son
elementos simbólicos que representan objetos físicos del mundo real.
En particular se utiliza el término “clase” para describir un tipo de objeto en particular, que tiene ciertas
características comunes.

1.2.3 Instancia
Una instancia es un objeto específico que se puede relacionar con otras instancias u objetos del mismo
tipo o de otro tipo. Específicamente, una instancia es un objeto de una clase específica.

1.2.4 Modelo
Toda estructura que se utiliza para dar razón y abstraer de la realidad a un conjunto de acciones o
fenómenos que guardan entre sí ciertas relaciones.
El ejemplo más simple de un modelo es una instancia, la que no tiene relación alguna mas que la de ella
misma con su objeto respectivo.
Modelos más complejos son los arreglos, registros, archivos y combinaciones de éstos. Los lenguajes de
programación normalmente proveen varias combinaciones (no todas) de modelos más complejos. Un
enfoque más reciente (años ‘90) para la resolución de problemas, se basa en la utilización de “Objetos”,
estableciendo un esquema en que cada elemento del mundo real se representa con mayor precisión y
fidelidad, logrando así soluciones modulares (compuestas por partes hasta cierto punto independientes,
que potencialmente pueden reutilizarse en otros modelos) y con encapsulación (que logra ocultar la
complejidad de soluciones en ciertos módulos, evitando que los participantes de la solución tengan que
dominar cada parte de ésta). A este esquema se le conoce como Orientación a Objetos.
El diseño e implementación de un modelo son fundamentales para la solución de un problema
computacional.

1.3 Algoritmos

1.3.1 ¿Qué es un Algoritmo?

Un algoritmo es un procedimiento detallado y preciso para resolver un problema en pasos (o etapas),
cada uno de los cuales toma un tiempo finito.
Los algoritmos se especifican en términos de un conjunto de operaciones básicas, en las que se
involucran diferentes objetos que forman parte de la solución. Se manipulan las variables del algoritmo y,
en general, cambiar el mundo en que se desarrolla el problema. Algunas de estas operaciones permiten
también controlar el flujo de ejecución del algoritmo. Llevando a cabo las operaciones que componen el
algoritmo, según su estructura de control, obtendremos la solución para el problema en cuestión.
El flujo de las operaciones especifica la secuencia en que se llevan a cabo las actividades:
• Toma de decisiones: La secuencia se decide de acuerdo a ciertas condiciones que dependen de
los datos del algoritmo.
• Iteración: Permite especificar la repetición de operaciones, también en forma controlada por
condiciones que dependen de los datos.
Al describir un algoritmo es necesario ser lo más preciso posible, de modo que sea sencillo implementar
el procedimiento especificado. En primer lugar, es necesario definir una serie de operaciones básicas y
objetos con las cuales se hará la especificación.

IIC 1102 Página: 2

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Luego, a partir de los objetos y operaciones definidas, se procede a enumerar los pasos que componen el
algoritmo. En esta etapa se puede emplear los componentes básicos de control de flujo (decisión e
iteración).
La principal destreza que se debe desarrollar para escribir algoritmos consiste en poder abstraer un
problema y conceptualizarlo de modo que se pueda expresar su solución en términos de las operaciones
básicas entre objetos que se definieron. Para esto nos apoyaremos en la descomposición en partes y
subproblemas más simples, las cuales también requieren de cierto grado de conceptualización.
Aún cuando muchos algoritmos resulten simples al final, el proceso para llegar a ellos puede ser muy
complicado. Existen varios enfoques que se pueden seguir para elaborar un algoritmo a partir de la
definición del problema:
• Buscar similitud con otros problemas
• Utilizar ejemplos conocidos
• Utilizar algoritmos genéricos conocidos
• Conceptualizar actividades y objetos participantes
• Descomponer en subproblemas
La metodología presentada en este curso hace uso de los dos últimos, aunque en algunos casos
recurriremos al resto como apoyo.

1.3.2 ¿Cómo se especifican o describen los algoritmos?

Para especificar un algoritmo puede utilizar el "lenguaje natural" y también el "pseudocódigo" (casi
código).
El lenguaje natural debe utilizar una cantidad suficiente de palabras en frases cortas, pero con sentido
completo como para que el algoritmo especificado quede claro.
El pseudocódigo suele ser muy utilizado cuando se está diseñando un algoritmo que resuelve algún
problema computacional, abstrayendo varios detalles de la sintaxis rígida de algún código o lenguaje de
programación, como es el caso del lenguaje C#.

1.3.3 ¿Existe un único algoritmo de solución?

Para cualquier problema, pueden existir varios algoritmos de solución, tantos como personas que quieran
resolverlos. No existe un algoritmo "único" de solución para un problema dado. Ello de ninguna manera
quiere decir que estos algoritmos distintos producen soluciones distintas. Aunque ellos sean distintos,
todos ellos pueden ofrecer el mismo resultado de solución.
Inclusive un mismo algoritmo que quiere ser implementado mediante algún código de computadora puede
ser implementado de distintas maneras, tantas como personas que lo implementen.

1.3.4 ¿Qué es una metodología?

Aplicación coherente de un conjunto de operaciones ordenadas con que se pretende obtener un
resultado. Se puede decir que una metodología es como un algoritmo genérico.
Se aplicará entonces una metodología que empezando de un problema, llegue a la especificación de un
algoritmo de solución.
Existen muchas metodologías para encontrar una solución a un problema. En este curso se adoptará la
metodología descrita más adelante, para contar con un lenguaje común que pueda dar lugar a su
entendimiento por todos aquellos que lo quieran analizar. Esta estrategia en particular se focaliza en el
análisis del problema para luego describir una solución donde se identifican los objetos involucrados y

IIC 1102 Página: 3

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

una secuencia de pasos, o algoritmo, que establece las relaciones entre los objetos, alcanzando el
objetivo buscado.
Una especificación de un algoritmo de solución, puede presentar problemas: que el algoritmo resuelva
más de lo que el problema pide (aunque esto por lo general no es perjudicial) o que el algoritmo no
resuelva todo lo que el problema requiere.

1.3.5 Las soluciones también pueden tener problemas

Para resolver estos problemas es necesario entonces validar la solución y/o especificar limitaciones del
algoritmo de solución. A veces esta tarea puede ser compleja, debido que para validar la solución y
conocer sus limitaciones hay que ser exhaustivo con el análisis o seguimiento de la especificación del
algoritmo, considerando todos los casos posibles.
Los casos posibles que generalmente no resuelven todas las partes del problema dado, son los casos
extremos, como por ejemplo datos nulos si se trata de números, datos negativos si se trata de
operaciones aritméticas con números positivos, o por ejemplo para la receta de cocina que se utilice
"huevos" pasados en lugar de frescos, etc.
Tanto para el diseño de un algoritmo de solución a un problema dado, como para su validación se
requiere experiencia. PARA TENER EXPERIENCIA ES NECESARIO TENER PRÁCTICA EN LA
RESOLUCION DE PROBLEMAS. PARA TENER PRÁCTICA ES NECESARIO RESOLVER MUCHOS
PROBLEMAS.

IIC 1102 Página: 4

 Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

2 Orientación a Objetos
En años recientes se ha adoptado, más que una técnica, un enfoque basado en lo que genéricamente se
denomina “Objeto”, a diferencia de esquemas tradicionales, denominados “Procedurales”, en los cuales la
solución se especifica como una secuencia de pasos y subpasos.
En el esquema de Orientación a Objetos se parte de la premisa “El Mundo Real está compuesto de
Objetos que interactúan”, y no es un mundo procedural, en que todo ocurre secuencialmente.
La Programación Orientada a Objetos tiene como punto medular el uso de “objetos”, que en realidad son
estructuras lógicas que representan elementos o entidades del mundo real. Esta representación se basa
en los siguientes aspectos:
• Se usan nombres que permiten hacer una rápida asociación con el correspondiente objeto. Por
ej: para representar un vehículo, se puede definir un objeto o entidad denominado “Auto”.
• Para representar el estado del objeto, se utilizan variables, denominadas atributos o
propiedades, que almacenan diferentes valores que pueden ir cambiando en el tiempo. Por ej: el
auto puede estar representado por “cilindraje”, “velocidad”, etc.
• Para describir el comportamiento del objeto y cómo éste interactúa con otros de su mismo tipo o
de otro tipo, se definen métodos, que corresponden a acciones específicas del objeto, una vez
más, simulando el mundo real. Por ej: “avanzar”, “frenar”, “abrir la puerta delantera derecha”, etc.

El objeto “Automóvil” en el mundo real.

Atributos: Métodos (acciones):

- Cilindraje - Avanzar
- Cantidad de Puertas - Frenar
- Velocidad a la que se desplaza - Cambiar Velocidad
- Abrir Puerta N

Representación Lógica del Automóvil Æ Clase Automóvil.

IIC 1102 Página: 5

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

El enfoque OO es una evolución natural de un concepto establecido en la programación procedural, que

se denominó “Tipo de Dato Abstracto”, siguiendo una intención de modularizar y a la vez encapsular la
complejidad de implementación de la lógica de un programa.
Más en detalle, la abstracción de datos es una metodología que permite aislar la implementación de un
tipo de datos compuesto a partir de tipos básicos. La idea es estructurar los programas de modo que
trabajen sobre datos abstractos, sin conocer su implementación. Los programas deben usar los tipos de
datos de manera que no se hagan suposiciones sobre los datos que no sean estrictamente necesarias
para cumplir con la tarea involucrada.
¿Cuál es la ventaja de esto? Si tenemos que saber siempre cómo están implementados los tipos de
datos, nuestros programas dependerán de esa implementación. Esto quiere decir que si se producen
cambios en la implementación del tipo de datos, será necesario cambiar el programa para que siga
funcionando. Para poder hacer uso de estos datos, sin conocer su implementación, se define una interfaz
que especifica cómo se puede interactuar con estos datos u objeto.
Adicionalmente, la otra gran ventaja del esquema de orientación a objetos es la posibilidad de reutilizar
partes de una solución para resolver un segundo problema, donde se comparte parte de la lógica resuelta
en el primer problema. Esta es una facultad tremendamente importante en la ingeniería de software
actual, donde se busca disminuir el esfuerzo involucrado en la implementación de soluciones a problemas
de cada día mayor complejidad.
Consideremos el caso de un auto. Somos capaces de conducir distintos autos, de distintas marcas,
modelos y años, sin tener necesidad de saber cómo funciona cada uno de sus componentes. De hecho,
no todos los autos tienen los mismos componentes. Incluso, los componentes que son comunes, a pesar
de tener la misma funcionalidad, difieren en marcas, modelos, rendimiento, costo, etc. En resumen, la
implementación es distinta pero tienen la misma funcionalidad.
De manera similar, una implementación particular de un tipo de datos es independiente de los programas
que lo usan. Lo único que es intocable es la interfaz.
Volviendo al ejemplo del auto, todas las marcas y modelos poseen algo en común: Una forma de uso
establecida por parámetros de operación y por la forma de entregar esos parámetros (forma de usar el
volante, el acelerador, el freno, etc). Nadie compraría un auto en que el freno se encuentre a la derecha
del acelerador, o que el volante funcione girando el auto a la derecha cuando se mueve hacia la
izquierda.

2.1 Terminología Básica de la Programación Orientada a Objeto

- Objeto: entidad lógica que representa un objeto según lo conocemos los humanos en el mundo
real.
- Clase: un “tipo de objeto”, descripción lógica que especifica características comunes a todos los
objetos de un tipo común, por ejemplo “Vehículo” describe genéricamente todos los objetos de
ese tipo.
- Instancia: un objeto particular de una clase específica. También se los conoce como “objetos”
propiamente tales. Una instancia tiene su propio nombre y se diferencia de otras instancias de la
misma clase, por los valores que puedan tener sus atributos en un instante en particular.
- Atributos o Propiedades: son variables de estado, cuyo valor se asocia a una instancia en
particular de una clase de objeto.

IIC 1102 Página: 6

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

3 Estrategias para la Solución de Problemas

Tomando en cuenta el objetivo de aprender a enfrentar problemas de cierto nivel de complejidad, se hace
necesario contar con una estrategia de resolución, que permita, estructuradamente y predeciblemente,
enfrentar y entender el problema y plantear una solución entendible y que claramente se enfoque en
resolver el problema planteado.
En la literatura existen numerosas estrategias, todas enfocadas con mayor énfasis a cierto tipo de
problemas. A continuación se presenta una metodología de resolución de problemas de tipo genérico,
que será el puntal para este curso.

3.1 Metodología de Resolución de Problemas

El proceso que permite obtener una solución a un problema puede dividirse en las siguientes etapas:
1. Definición del problema (planteamiento original)
El primer paso: Definición del Problema, busca definir el contexto en que se establece el
problema, indicando el alcance u objetivo que se pretende atacar. Este paso se
descompone en tres partes:
1.1. Conceptualización. Conceptualizar el mundo o contexto en que ocurre el problema. Cualquier
suposición sobre el dominio del problema debe ser descrita aquí. Además, debe quedar claro cuál es la
información que se conoce relativa al problema (entradas del algoritmo).
1.2. Objetivo. Determinar el objetivo que se quiere alcanzar, en forma cualitativa (descripción de lo que
se desea) y cuantitativa (forma en que se medirá el logro alcanzado).
1.3. Elementos involucrados. Especificar los elementos activos (usuarios) y pasivos (recursos
disponibles y/o modificables) que están involucrados en el problema.
2. Conceptualización de la solución
El segundo paso: Conceptualización de la solución, se focaliza en una descripción de
los elementos involucrados en la solución al problema planteado. Esta sección se enfoca
en un esquema de orientación a objeto, ya que el núcleo de esta definición no son las
acciones a tomar, propiamente tales, sino que los objetos que estarán involucrados en la
solución. A su vez, esta descripción de elementos se descompone en tres partes:
2.1. Entidades involucradas. Haciendo un paralelo con el problema en el mundo real que se está
representando, se determinan cuáles son las entidades que participan en la solución del problema,
indicando su funcionalidad básica. Las entidades que son muy complejas pueden definirse en base a
otras más simples.
2.2. Clases de Objetos. Para cada una de las entidades descritas en el punto anterior debe definirse un
“tipo de objeto” que la implemente, también llamado “clase”. La definición de cada clase debe incluir
únicamente la funcionalidad del tipo (¿para qué sirve?) y la interfaz (¿cómo se usa?). La interfaz se
define en términos de un conjunto de métodos con parámetros claramente establecidos. También
deben mencionarse las limitaciones de cada una de las clases.
2.3. Instancias. Deben definirse las instancias de cada clase que se emplearán en la solución del
problema, indicando el uso particular que se dará a cada una. A su vez, debe especificarse aquellos
datos simples adicionales que estarán involucrados en la solución.

3. Especificación del algoritmo

El tercer paso: se especifica una secuencia de pasos principales (no detallados), en que
las distintas instancias interactúan para producir el objetivo esperado. Se detalla paso
por paso el procedimiento principal, donde incluso se especifica algunos valores iniciales
de las instancias requeridas.

IIC 1102 Página: 7

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Especificar la secuencia de actividades que conforman la solución del problema. Esta especificación debe
ser autocontenida y debe estar dada en términos de las entidades/objetos definidos en (2).
Cada uno de los pasos del algoritmo podrá ser una operación simple o alguna operación sobre uno de las
instancias de los objetos.

4. Validación de la Solución
El cuarto paso: habiendo definido el problema y descrito una solución se hace un estudio
de los posibles escenarios en que la solución puede funcionar. Los escenarios se definen
en función de los rangos de valores que los parámetros de la solución pueden recibir.
4.1. Dominios. Especificar un conjunto de problemas tipo y sus soluciones, los cuales
caracterizan el dominio del problema. Debe haber un problema para cada posible dominio.
4.2. Ejecución. Ejecutar el algoritmo obtenido en (3) para cada uno de los problemas que representan
los distintos dominios, validando que se obtengan las soluciones especificadas, es decir, que se
alcancen los objetivos propuestos en cada caso.

5. Limitaciones del algoritmo

Identificación de puntos débiles y escenarios en los cuales el algoritmo no funciona o tiene deficiencias
(condiciones críticas).

3.2 Descripción Gráfica de Soluciones

La idea de las representaciones gráficas, o diagramas, es apoyar la descripción que se hace, tanto de las
problemas y modelos, como de sus soluciones. En estas descripciones gráficas se intenta ilustrar, ya sea
con metáforas visuales o con gráficos descriptivos las diferentes condiciones que se imponen sobre la
situación a odelar y que requiere ser resuelta, así como de los elementos que componen su solución.
Particularmente como apoyo a los procesos de diseño de soluciones Orientadas a Objeto, se ha
desarrollado en los últimos años un lenguaje de modelamiento, llamado directamente Lenguaje de
Modelamiento Unificado (Unified Modeling Language – UML), que consisten en la conjunción de
diferentes técnicas tradicionales, en un enfoque más actualizado con la tecnología actual.
En este contexto sólo se analizarán algunos tipos de diagramas manejados en UML, que permiten tanto
describir los requerimientos de las soluciones que deberán ser diseñadas, así como los elementos que
componen y definen el modelo de solución a un problema dado.

3.2.1 Diagrama de Casos de Uso - UML

El primer tipo de diagrama utiliza elementos gráficos muy simples para describir las
funcionalidades de una solución requerida, a nivel macro. En estos diagramas se identifican:
- Actores: elementos que interactúan con la solución, lo que incluye tanto a usuarios,
como a elementos externos al sistema o aplicación, como son bases de datos
Actor1
externas, archivos, u otros sistemas.
- Funcionalidades o Casos de Uso, que describen una operación o un conjunto de
operaciones que se pueden gatillar por parte de un usuario o de otro actor, y Caso de Uso
que producen un resultado medible.
- Cada actor puede activar un caso de uso (es decir, su decisión inicia el
funcionamiento descrito por dicho caso de uso), o bien, el actor puede recibir la
acción de un caso de uso iniciado por otro lado. Esto se representa por una flecha
unidireccional, que indica quién activa a quién.

IIC 1102 Página: 8

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Tomemos por ejemplo el caso de un cajero automático. En este caso, consideraremos que el programa
que reside en el cajero es la aplicación a describir, y que los actores involucrados son: un usuario o
cliente que acudirá al cajero, y el sistema central que tiene los datos de las cuentas corrientes de los
clientes.
En este modelo, un cliente efectúa dos posibles acciones sobre el cajero: Consulta de Saldo y Retiro de
Dinero. El cajero a su vez requiere consultar los datos al sistema central para ambos casos, y en
particular en el retiro de dinero, adicionalmente actualiza el saldo del cliente en el mismo sistema central.

3.2.2 Diagrama de Clases – UML

En aquellas soluciones en las que se definen clases que representan objetos del mundo real, pero
estructurados y especificados de una manera precisa en el modelo, se utiliza el diagrama de clases
donde no sólo se identifican gráficamente cada una de las clases (o tipos de objetos) que interactúan en
la solución, sino que además se especifican detalles como los elementos que componen cada una de
estas clases y cómo se relacionan entre ellas. Este esquema, totalmente dependiente de la modelación al
estilo Orientación a Objeto, permite definir en forma visual el diseño de la solución. Entre las relaciones
que este tipo de diagrama permite definir entre clases, resultan relevantes dos: la herencia entre clases, y
la composición de clases dentro de otras.
En estos diagramas se reconocen básicamente los siguientes objetos:
Clase: Vehículo
- Clases: con sus respectivos elementos componentes. Estas se representan por
un rectángulo que interiormente describe los componentes, lo que se verá en
detalle más adelante.
- Relación de Herencia: identificada por una flecha de línea sólida y una punta
triangular vacía, que va desde la clase derivada a la clase padre.
- Relación de Composición: que define que una clase contiene una o más instancias de otra clase,
y se identifica por una línea sólida, que puede terminar en flecha con * 0 ..1

punta abierta, e incluye un rombo en la mitad, donde se describe la

cardinalidad (o cuántas instancias de la clase referenciada están
contenidas en cada instancia de la clase contenedora o compuesta).
En el siguiente ejemplo, se representa en forma simple la siguiente situación. Se tiene una clase
Vehículo, que representa genéricamente los vehículos de cualquier tipo. De ella se derivan dos clases, el
Camión, y la Motocicleta. A su vez existe una 4ª clase, que representa un automotora, que en realidad
contiene varias instancias de vehículos, ya sean camiones o motocicletas. Por ello, en este diagrama, la
clase Vehículo es la central, y de ella se derivan las otras clases.

IIC 1102 Página: 9

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Clase: Vehículo * 0..1 Clase: Automotora

Clase: Motocicleta Clase: Camión

3.2.3 Árboles de Decisión

Los árboles de decisión son una herramienta gráfica muy útil para representar algoritmos en los que
están involucradas una gran cantidad de decisiones a lo largo de su ejecución.
El objetivo es ilustrar la forma en que el algoritmo va evolucionando conforme se van tomando
decisiones, normalmente sobre la base de información suministrada por el usuario. Cada punto de
decisión se representa con una caja rectangular, en la cual se describe brevemente los aspectos a
considerar para tomar dicha decisión.
Una vez que se conocen los criterios para tomar la decisión en uno de estos puntos, se señala con
flechas las distintas posibilidades hacia donde evolucionaría el algoritmo, llevando el desarrollo de la
ejecución hacia otro punto de decisión. Para identificar las posibles opciones, se etiquetan las flechas.
Las posibilidades pueden ser múltiples, produciéndose varias bifurcaciones en cada punto de decisión, o
simplemente dos, en cuyo caso se obtendría un árbol binario. Este es el caso del ejemplo que se muestra
a continuación.
Al llegar al último nivel, es decir, cuando ya no hay decisiones que tomar, se ha obtenido una solución y
el algoritmo ha concluido. A estos nodos dentro del árbol se les conoce como hojas, o también como
nodos terminales.

3.2.4 Ejemplo: Árbol de Decisión: ¿Qué hago el sábado por la noche?

Para ilustrar el uso de los árboles de decisión, se presenta un árbol que guía a un usuario a tomar una
decisión sobre qué hacer el sábado por la noche. La profundización en el árbol se lleva a cabo de
acuerdo a las respuestas que va dando el usuario a las interrogantes que se le plantean. Cuando se llega
a un nodo terminal en el árbol (hoja), el usuario recibe una recomendación sustentada en el desarrollo de
la interacción.

IIC 1102 Página: 10

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

3.3 Ejemplos de Aplicación de la Metodología

3.3.1 Simulando la Ejecución de un Penal

Este primer ejemplo ilustra la situación de ejecución de un penal de fútbol, reconociendo los elementos
involucrados en esta situación y cómo se relacionan para producir un resultado.
1. Definición del problema
Conceptualización: El problema consiste en ejecutar un penal, donde un jugador patea la pelota hacia el
arco y el arquero trata de detenerla. Particularmente se pretende determinar si al ejecutar un penal, el gol
fue convertido o fue atajado. En este caso, un usuario indicará la dirección en que patea el jugador y la
dirección en que se lanza el arquero. Si ambas direcciones coinciden, se considera penal atajado. Si no
coinciden, se considera penal convertido.
Objetivo: El objetivo es determinar para una combinación de direcciones en que se patea la pelota y se
lanza el arquero, ingresadas por el usuario, si el penal fue convertido o no.
Elementos Involucrados: Elementos activos, el usuario que indicará las direcciones respectivas.
Elementos pasivos, el jugador y la dirección en que lanzará, y el arquero y la dirección en que se lanzará.

IIC 1102 Página: 11

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

2. Conceptualización de la solución
Entidades Involucradas: Dos objetos esenciales se reconocen en este problema: el jugador y el arquero.
Clases de Objetos: En este caso particular, ambas entidades se representan cada una por su respectiva
clase.
Clase Jugador: Representa a un jugador que lanzará la pelota tratando de convertir el penal.
Atributos: El número en su camiseta, y la dirección en que lanzará.
Métodos: patear la pelota
Clase Arquero: Representa a un jugador que intentará impedir que el gol sea convertido.
Atributos: la dirección en que se lanza para atajar.
Métodos: Lanzarse a atajar.
Instancias Involucradas: en este caso sólo se necesita una instancia de la clase Jugador, que representa
a quien ejecutará el penal, y adicionalmente se requiere una única instancia de la clase Arquero, ya que
sólo uno de ellos participa en el penal.

Atributos:
- Número
- Dirección
Atributos:
- Dirección

Métodos:
- Lanzarse

Métodos:
- Patear

3. Especificación del algoritmo

Siguiendo el procedimiento de ejecución de un penal, se involucra al usuario para hacerle las preguntas
del caso.
1. Se instancia el jugador (j1), y se instancia el arquero (a1)
2. Se le pregunta al usuario la dirección en que pateará el jugador Æ se asigna a la instancia j1
3. Se le pregunta al usuario la dirección en que se lanzará el arquero Æ se asigna a la instancia a1
4. Se invoca el método Patear del objeto j1
5. Se invoca el método Lanzarse del objeto a1
6. Se comparan ambas direcciones.

IIC 1102 Página: 0

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

a. Si coinciden, se indica al usuario que el penal fue atajado.

b. Si no coinciden, se indica al usuario que el gol fue convertido.

4. Validación de la Solución
Dominios: Los posibles dominios que existen en el contexto de este problema se constituyen a partir de
los valores de dirección que el usuario puede ingresar. Es decir, los escenarios posibles se conforman de
las 4 diferentes combinaciones de direcciones para ambos jugadores: der-der; izq-izq; izq-der; der-izq.
Validación: revisando las cuatro posibles combinaciones de valores indicados por el usuario, se llega en
todos ellos a un resultado predecible por el algoritmo principal, por lo que se valida su ejecución.

5. Limitaciones
Si los valores ingresados por el usuario no son controlados, entonces se podría asumir que el programa
podría tener un comportamiento incoherente.

Posibles soluciones:

Versión de Consola

Versión Windows

IIC 1102 Página: 13

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

3.3.2 Simulando la preparación de un pastel

En este ejemplo se emplea la metodología de solución de problemas para definir e implementar los pasos
necesarios para simular la solución a un problema simple: hornear y servir un pastel de fruta.
1. Definición del problema
Conceptualización: El problema consiste en preparar un pastel de alguna fruta específica, de acuerdo a
cierta receta, y servirlo a cierta cantidad de comensales.
Se recibirá como entrada la receta para hornear, es decir, la cantidad de huevos, harina y mantequilla
que se empleará, la fruta con que se cubrirá el pastel y la cantidad correspondiente, así como el tiempo
que debe permanecer en el horno. Adicionalmente, se recibe el número de comensales que disfrutarán
del producto final, para poder cortarlo y servirlo.
Objetivo: El objetivo es poder seguir la receta proporcionada de modo que podamos obtener como
resultado un pie de fruta que podamos repartir a los comensales.
Elementos involucrados: El único elemento activo será la persona que llevará a cabo el proceso (el
cocinero). Los elementos pasivos involucrados son la receta del pastel: sus ingredientes y cantidades
(huevos, harina, mantequilla, fruta). En este caso, los comensales podrían considerarse como elementos
pasivos, pues no participan de la solución (existen, pero simplemente esperan).

2. Conceptualización de la solución
Entidades Involucradas: el objeto principal es la receta del pastel, que será preparado durante el
proceso. La receta se compone de las cantidades respectivas de cada ingrediente, además del tiempo de
horneado, el tipo de fruta, y los trozos en que deberá partirse.
Clases de Objetos: la única clase requerida es pastel, la cual se define con ciertas propiedades privadas,
y algunos métodos públicos. Las propiedades privadas son las cantidades de huevos, harina,
mantequilla, y fruta, el tiempo de horneado, el tipo de fruta, y la cantidad de pedazos. Todos ellos son
datos numéricos a excepción del tipo de fruta, que es de tipo texto.
El proceso de hornear y servir el pastel abarca varias etapas. En primera instancia se debe obtener la
receta a emplear. Esto consiste en especificar la cantidad de huevos, mantequilla y harina, así como el
tipo y la cantidad de fruta que se utilizará. El segundo paso consiste en preparar la base del pie,
mezclando la cantidad especificada de huevos, harina y mantequilla. Luego, la base es horneada durante
cierto tiempo (lo cual también es parte de la receta). El siguiente paso es preparar la fruta con la que se
cubrirá la base. Finalmente, se procede a cortarlo y servirlo a todos los comensales. Por esto, los
métodos de esta clase son:
MezclarBase(): Se toman las cantidades definidas de huevos, harina y mantequilla y se mezclan para
lograr la base.
HornearBase(): Según el tiempo definido, que representa la cantidad de minutos que deberá permanecer
la base en el horno, este proceso se encarga de hornear la base durante dicho tiempo.
PrepararFruta(): Usando el tipo o nombre de la fruta que se empleará para cubrir la base, y la cantidad
(en gramos) de dicha fruta que debe emplearse (según la receta), este proceso prepara la cubierta.
CortarServir(): Tomando el tipo de fruta con que se cubrió el pastel y la cantidad de invitados
establecidos, este proceso se encarga de cortar el pastel en tantos pedazos como comensales haya y lo
sirve para que los invitados lo puedan comer. El tipo de fruta es necesario para que al servirlo a los
comensales se les pueda indicar qué tipo de pie van a comer.
Instancias: En el contexto de nuestro problema, será necesario representar una variable u objeto de clase
Pastel, que representa el pastel a preparar en base a su receta (huevos, harina, mantequilla, fruta), el
tiempo que debe permanecer el pie en el horno, y la cantidad de comensales que lo disfrutarán. El
nombre de esta instancia: pas.

IIC 1102 Página: 14

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Atributos:
- Huevos Métodos:
- Harina - MezclarBase()
- Mantequilla - HornearBase()
- Fruta - PrepararFruta()
- Tiempo de horneado - CortarServir()
- Tipo de fruta
- Cantidad pedazos

3. Especificación del algoritmo

El algoritmo presentado a continuación emplea la instancia de la clase definida y llama secuencialmente a
los métodos respectivos para resolver nuestro problema. En este caso no fue necesario emplear
operaciones de control de flujo, pues el algoritmo se puede especificar en forma totalmente secuencial.
Algoritmo:
1. Crear la receta del Pastel, obteniendo del usuario los ingredientes: huevos, harina,
mantequilla, tipo, fruta y tiempo, y la cantidad de pedazos en que se debe cortar.
2. MezclarBase()
3. HornearBase()
4. PrepararFruta()
5. CortarServir()

La implementación en C# de este algoritmo resulta bastante simple. Basta con implementar e invocar el
método para cada una de las tareas involucradas. Esta función simulará el proceso que debe llevar a
cabo la tarea. Las primeras líneas del algoritmo involucran la creación de la instancia, junto con la entrada
de datos por parte del usuario del programa (debe proporcionar los valores apropiados para las
propiedades de esta instancia).

4. Validación de la Solución
Dominios: Los posibles dominios que existen en el contexto de este problema se constituyen a partir de
los distintos valores de entrada que pueden recibirse del usuario. Es decir, distintos tipos de fruta,
distintas cantidades para cada ingrediente, distintos tiempos en el horno y distintas cantidades de
comensales.
Validación: Debe ejecutarse (verbalizarse su ejecución) el algoritmo para los dominios definidos, es decir,
cambiando valores para cada dato de entrada, y verificando que se puede alcanzar el objetivo buscado.
A priori, no hay validación de las cantidades numéricas indicadas, por lo que el algoritmo funcionaría, aún
cuando se ingresen valores que no tengan sentido de acuerdo al contexto, como por ejemplo usar
cantidades de minutos negativas o cero, o nombres incongruentes de frutas.

5. Limitaciones de la Solución
En principio, no hay limitaciones evidentes en el caso de la solución planteada en este ejemplo, ya que el
programa funcionaría incluso con números incoherentes (números negativos, nulos) en los valores
indicados por el usuario.

IIC 1102 Página: 15

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

3.3.3 Cambio de neumático desinflado

Un auto queda detenido en la carretera al desinflársele un neumático. Para tratar este problema particular
se aplicará la metodología para la solución de problemas presentada anteriormente.
1. Definición del problema
Conceptualización: El problema tiene lugar en una carretera, en donde un auto se ha quedado parado,
pues uno de sus 4 neumáticos se ha desinflado. El auto cuenta con las herramientas necesarias para que
el conductor pueda cambiar el neumático, así como también con un neumático de repuesto en buenas
condiciones. El único dato de entrada con que se cuenta es la posición del neumático desinflado, es
decir, en cuál de las cuatro ruedas ocurrió el percance.
Objetivo: Cualitativamente, el objetivo es cambiar el neumático desinflado por el de repuesto, de modo
que el auto pueda andar. Cuantitativamente, el logro del objetivo puede medirse verificando que los 4
neumáticos estén inflados.
Elementos involucrados: Existe un único elemento activo que es el conductor del auto. Además, existen
los siguientes elementos pasivos, que formarían parte del equipamiento del auto:
• Maletero
• Ruedas, una de las cuales tiene el neumático desinflado
• Pernos que sujetan cada rueda
• Neumático de repuesto, en buenas condiciones, ubicado en maletero del auto
• Gata hidráulica en el maletero del auto
• Llave de cruz en el maletero del auto

2. Conceptualización de la solución
Entidades Involucradas: el objeto principal es claramente el auto. Es esta entidad la que contiene todos
los elementos relevantes de manejar en esta solución, como son las ruedas, el maletero, y todos los
elementos dentro de él, necesarios para el cambio de rueda.
Clases de Objetos: la única clase requerida en este caso, es Auto, la cual es descrita por medio de
ciertos atributos y métodos.
Los atributos se definen directamente en función de los elementos pasivos requeridos en la solución, más
un atributo indicando la rueda que está desinflada: maletero, gata hidráulica; llave de cruz; un perno (su
número: 1, 2, 3, ó 4); neumático desinflado; neumático de repuesto.
El método constructor de esta clase recibirá como parámetro el Nº del neumático desinflado.
Los otros métodos, se pueden resumir en las siguientes actividades:
- Retirar y colocar cosas
- Aflojar y apretar pernos
- Subir y bajar el auto con la gata
De esa manera, se podrían definir los siguientes métodos:
- Retirar "algo" de un "lugar"
- Colocar "algo" en un "lugar"
- Aflojar "un determinado perno"
- Apretar "un determinado perno"
- Subir auto desde "una determinada posición"
- Bajar auto desde "una determinada posición"

IIC 1102 Página: 16

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Los términos resaltados en cursiva corresponden a variables de entrada (parámetros) que proporcionan
generalidad a las operaciones. Por ejemplo, el primer método puede emplearse para retirar el neumático
de repuesto del maletero, pero también para retirar la llave de cruz del maletero y un perno de la rueda.
Una definición más formal involucra especificar claramente cuáles son los parámetros con los que trabaja
cada operación. Así, la lista definitiva de operaciones será la siguiente:
- Retirar
Parámetros: Lo que se desea retirar y el lugar de dónde se retirará
- Colocar
Parámetros: Lo que se desea colocar y el lugar dónde se colocará
- Aflojar perno
Parámetros: La posición de la rueda, el número de perno que se desea aflojar.
- Apretar perno
Parámetros: La posición de la rueda, el número de perno que se desea apretar, y la herramienta
que se usará
- Subir auto
Parámetros: La posición de la rueda en donde se desea subir el auto y la herramienta (gata) que
se usará
- Bajar auto
Parámetros: Ninguno.
Instancias: En el contexto del problema la única instancia necesaria es una de la clase Auto, que
simplemente se llamará auto1, la cual contiene todos los atributos necesarios para representar la
situación.

3. Especificación del algoritmo

El algoritmo presentado a continuación emplea las operaciones (tareas) definidas anteriormente para
resolver el problema de cambiar el neumático desinflado. Se resalta los argumentos de cada operación.
La única operación elemental que se emplea para cambiar el flujo de control de las tareas es la iteración.
Algoritmo:
Considere N como la posición del neumático desinflado (dato de entrada), referenciado como 1, 2, 3, ó 4.
1. Declarar instancia de Auto, con N como parámetro.
2. Auto.Retirar( gata hidráulica, del maletero )
2. Auto.Retirar( llave de cruz, del maletero )
3. Itere sobre cada perno P = 1,2,3,4
3.1. Auto.Aflojar( perno P, en rueda N)
4. Auto.Subir( posición N )
5. Itere sobre cada perno P = 1,2,3,4
5.1. Auto.Retirar( perno P, de rueda N)
6. Auto.Retirar( neumático D, de rueda N)
7. Auto.Retirar( neumático R, del maletero )
8. Auto.Colocar( neumático R, en rueda N)
9. Auto.Colocar( neumático D, en maletero )
10. Itere sobre cada perno P = 1,2,3,4

IIC 1102 Página: 17

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

10.1. Auto.Colocar( perno P, en rueda N )

11. Auto.Bajar()
12. Itere sobre cada perno P = 1,2,3,4
12.1. Auto.Apretar( perno P, en rueda N )
13. Auto.Colocar( llave de cruz, en maletero )
14. Auto.Colocar( gata hidráulica, en maletero )

4. Validación del algoritmo

Dominios: Los posibles dominios que existen en el contexto de este problema se constituyen a partir del
neumático que se haya desinflado. Por ejemplo, un posible dominio será aquel en que el neumático
desinflado es el de la rueda izquierda delantera.
Validación: Ejecutando el algoritmo para cualquiera de los cuatro neumáticos del auto puede verificarse
que la parametrización de las operaciones elementales permite alcanzar el objetivo buscado.
Al final de la ejecución del algoritmo, para cualquier dominio (es decir, considerando cualquiera de los
cuatro neumáticos), el auto contará con todos sus neumáticos inflados y por consiguiente podrá andar.
5. Limitaciones del algoritmo
El desarrollo del algoritmo se hizo para un auto que tuviera 4 pernos sujetando cada rueda. Sin embargo,
puede modificarse para recibir este valor como un dato de entrada.
Por simplicidad se dejaron de lado algunas consideraciones, como por ejemplo, abrir y cerrar el maletero,
transportar los neumáticos y las herramientas, etc. Además, la solución presentada se aplica únicamente
a autos que cuenten con cuatro neumáticos.

3.3.4 Llamada Telefónica

Se desea conceptualizar el problema de efectuar una llamada telefónica en un teléfono público que
recibe monedas de $10, $50 y $100. El costo mínimo de la llamada es de $100 por 5 minutos. El proceso
se inicia desde que se levanta el auricular y finaliza cuando se cuelga. Se aplicará la metodología para la
solución de problemas presentada anteriormente.

1. Definición del problema

Conceptualización: El problema tiene lugar en cualquier teléfono público que acepta monedas de $10,
$50 y $100, con un costo de llamada mínima de $100 por 5 minutos. Supondremos que el aparato
funciona apropiadamente y que el usuario cuenta con suficientes monedas, de cualquier denominación,
para completar su llamada. Los datos de entrada son: 1) el número de teléfono que se desea marcar, y 2)
las monedas que lleva consigo la persona que hará la llamada.
Objetivo: Cualitativamente, el objetivo es que el usuario pueda completar su llamada. Cuantitativamente,
el logro del objetivo puede verificarse si el tiempo de duración de la llamada del usuario es mayor que
cero.
Elementos involucrados: Existe un único elemento activo, que es el usuario que realiza la llamada.
Además, existen los siguientes elementos pasivos:
- Un teléfono público en buen estado, que funciona en la forma que se indicó. El teléfono tiene los
siguientes componentes:

IIC 1102 Página: 18

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

o Ranura para insertar monedas

o Auricular
o 10 teclas numéricas (una con cada dígito)
o Ranura para devolución de monedas
- Un conjunto de monedas que se compone de:
o Un subconjunto de monedas de $10, que puede ser vacío
o Un subconjunto de monedas de $50, que puede ser vacío
o Un subconjunto de monedas de $100, que puede ser vacío

2. Conceptualización de la solución
Entidades: Para efectos prácticos y funcionales, el problema global de efectuar la llamada telefónica
puede descomponerse en las siguientes tareas actividades: Manipular el auricular (levantarlo y colgarlo);
Manipular las monedas (recolectarlas, ponerlas en la ranura, recuperarlas cuando son devueltas);
Escuchar en el auricular (por el tono de marcar, de llamada en proceso, de conexión aceptada, o de
ocupado); Marcar un número en el teclado del teléfono; Hablar.
El problema se describe en la relación que un usuario hace entre la manipulación de un teléfono y sus
dispositivos, y un conjunto de monedas desde el cual saca la cantidad requerida para realizar las
llamadas.
Clases: Las únicas dos clases que permiten definir la solución a este problema son Telefono, y Bolsillo,
los cuales en forma explícita verbalizan su representación de la realidad. Adicionalmente se define un tipo
de dato especial, que representa un conjunto particular de monedas. Cada una de las clases formales se
compone de atributos y métodos como se describe a continuación:
Clase Telefono
Atributos:
- costo de la llamada, en este caso siempre valdrá $100, por lo que podría manejarse como
una constante.
- tiempo: Corresponde al tiempo que el usuario ha hablado con al teléfono que marcó.
Métodos públicos
o LevantarAuricular(): representa la acción de tomar el auricular, que provoca la activación del
teléfono y la petición de tono.
o DepositarMonedas(monedas): deposita el conjunto de monedas indicado en el teléfono.
o ColgarAuricular(): representa la acción de devolver el auricular a su posición de cuelgue,
desactivando así el teléfono.
o EscucharAuricular(): representa la acción de detectar el tono que tiene el teléfono. Como
retorno, devuelve el tono esuchado, identificando uno de los siguientes valores: TONO,
CONEXION EXITOSA y OCUPADO, DESCONEXION (este tono se escucha cuando se ha
esperado por un tiempo determinado y nadie contesta el teléfono marcado).
o RecuperarMonedas(): permite recuperar las monedas sobrantes, retornando como resultado
el conjunto de estas monedas.
o Marcar(numero): Esta operación marca en el teclado numérico cada uno los dígitos del
número al que se desea llamar.
Variables locales:
D: almacena los dígitos del número al que se desea hablar.

IIC 1102 Página: 19

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

Algoritmo:
1. Iterar sobre cada una de los dígitos D del número que se desea marcar
1.1 Presionar en el teclado numérico el número correspondiente al dígito D
o Hablar(): Esta operación permite que el usuario hable con la persona a la que llamó. Por cada
segundo hablado se incrementa en 1 el tiempo de la llamada. Cuando se han cumplido 5
minutos (300 seg.) se debe introducir $100 para seguir hablando.
Variables propias:
tiempo: almacena el tiempo que se ha hablado hasta el momento.
MB: monedas en el bolsillo seleccionadas. Corresponde a las monedas que el usuario posee.
MS: monedas seleccionadas. Corresponde a las monedas que el usuario utilizará para
efectuar la llamada.
Algoritmo:
1. Al comienzo tiempo es 0 seg.
2. Iterar mientras se desee seguir hablando
2.1 Hablar un segundo.
2.2 Incrementar en 1 la variable tiempo.
2.3 Si tiempo tiene el valor 300 seg.
2.3.1 Recolectar monedas para una llamada de $100 desde conjunto de monedas
MB y almacenarlas en el conjunto de monedas MS.
2.3.2 Depositar monedas del conjunto MS en el teléfono.
2.3.3 Devolver tiempo a 0 seg.

Clase Bolsillo
Métodos públicos
o RecolectarMonedas(monto): recolecta una combinación de monedas de $100, $50, y $10,
que sumen el monto indicado. Como retorno entrega el conjunto de monedas seleccionadas.
Variables locales:
- monto recolectado: almacena el valor de las monedas que se han seleccionado hasta el
momento.
Algoritmo:
1. Al comienzo el monto recolectado es $0.
2. Iterar hasta que el monto recolectado sea el indicado
2.1 Seleccionar del bolsillo del usuario una moneda (una de las de mayor valor
que tenga) y pasarla al conjunto de monedas seleccionadas
2.2 Sumar el monto de la nueva moneda con el monto recolectado
3. Devolver el conjunto de monedas seleccionadas.

Instancias: En el contexto del problema que se intenta resolver, se necesitarán las siguientes instancias:
- El aparato telefónico que se utilizará para la llamada
- El bolsillo que contiene las monedas

IIC 1102 Página: 20

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

- Adicionalmente será necesario representar como dato el número de teléfono que se desea
marcar. La variable que lo denotará será Num.
- Por otro lado, es necesario representar las monedas seleccionadas desde el bolsillo. Esto se
hará con la variable MS.
- tono: Corresponde al tono escuchado en el teléfono.
- intentos: Corresponde al número de intentos que ha hecho el usuario.

3. Especificación del algoritmo

El algoritmo presentado a continuación emplea las clases e instancias definidas anteriormente para
resolver el problema de hacer una llamada telefónica. En este caso, para controlar el flujo de las
operaciones se emplea iteración y decisión.
Además, con el objetivo de que el usuario no se quede indefinidamente intentando hacer la llamada, en
caso de ocupado o que no contesten, se harán únicamente 3 intentos y si no se logra la llamada se
abandonará el proceso y el problema no podrá ser resuelto.
Algoritmo:
Considere Num como el número que el usuario desea marcar, T como el teléfono donde se hará la
llamada, y B como el bolsillo que contiene las monedas con que hará la llamada.
Inicialmente la variable intentos valdrá 0. Iterar los siguientes pasos mientras intentos sea menor que 3.
1. MS = B.RecolectarMonedas(100)
Se recolectan las monedas para una llamada de $100 desde el conjunto de monedas en el
bolsillo B y se almacenan en el conjunto de monedas MS.
2. T.LevantarAuricular().
3. T.DepositarMonedas(MS).
4. tono = T.EscucharAuricular(),
se repite hasta que tono sea TONO.
5. T.Marcar(Num)
6. tono = T.EscucharAuricular().
7. Mientras tono ≠ CONEXION EXITOSA o DESCONEXION.
a. tono = T.EscucharAuricular().
8. Si tono = CONEXION EXITOSA entonces
a. T.Hablar().
b. T.ColgarAuricular().
9. Por el contrario, si tono = DESCONEXION u OCUPADO entonces
a. T.ColgarAuricular().
b. MS = T.RecuperarMonedas().
c. Incrementar variable intentos en uno.

4. Validación del algoritmo

Dominios: Los posibles dominios que será necesario analizar se constituyen a partir de las siguientes
caracterizaciones:
o Las distintas combinaciones de monedas que pueden formarse para llevar a cabo la llamada.

IIC 1102 Página: 21

Intro a la Prog. – Resolución de Problemas Rodrigo Sandoval U.

o El teléfono al que se llama está ocupado.

o No contestan en el teléfono al que se llama.
o Al hacer la llamada se obtiene una respuesta satisfactoria.
o Llamadas de menos de 5 minutos y llamadas de más de 5 minutos.
o Distinto número de intentos al hacer la llamada (1, 2, ó 3).
Validación: La validación debe llevarse a cabo tomando en consideración los dominios definidos en el
punto anterior. Para cada uno de ellos debe probarse que el algoritmo es correcto, es decir, que funciona
de acuerdo a las especificaciones originales.

IIC 1102 Página: 22