Cap 01

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

3

TERMINOLOGÍA BÁSICA DE LA PROGRAMACIÓN ORIENTADA A OBJETO ........................................................ 6

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 Cantidad de Puertas Velocidad a la que se desplaza

Avanzar Frenar 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: -

-

-

IIC 1102

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 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 que producen un resultado medible.

Actor1

Caso de Uso

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.

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, * 0 ..1 y se identifica por una línea sólida, que puede terminar en flecha con 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

Clase: Vehículo

Clase: Motocicleta

Rodrigo Sandoval U.

*

0..1

Clase: Automotora

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

3.3

Rodrigo Sandoval U.

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

Atributos: - Huevos - Harina - Mantequilla - Fruta - Tiempo de horneado - Tipo de fruta - Cantidad pedazos

Rodrigo Sandoval U.

Métodos: - MezclarBase() - HornearBase() - PrepararFruta() - CortarServir()

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: -

IIC 1102

Un teléfono público en buen estado, que funciona en la forma que se indicó. El teléfono tiene los siguientes componentes:

Página: 18

Intro a la Prog. – Resolución de Problemas

-

o

Ranura para insertar monedas

o

Auricular

o

10 teclas numéricas (una con cada dígito)

o

Ranura para devolución de monedas

Rodrigo Sandoval U.

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 IIC 1102

Las distintas combinaciones de monedas que pueden formarse para llevar a cabo la llamada. Página: 21

Intro a la Prog. – Resolución de Problemas

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).

Rodrigo Sandoval U.

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