Antología de definiciones de conceptos base en la

Orientación a Objetos, compilada con enfoque en la

problemática que existe en el aprendizaje de la OO en

la carrera de Ingeniería en Computación FCQI/UABC.

Por: Yail Rafael Abraham Gómez Tagle Karosuo

En colaboración con Raúl Navarro Almanza

02 de Septiembre de 2013

Antología de definiciones de conceptos base en la Orientación a

Objetos, compilada con enfoque en la problemática que existe en el

aprendizaje de la OO en la carrera de Ingeniería en Computación

FCQI/UABC.

Es totalmente cierto que la comprensión del paradigma orientado a objetos es un

elemento con el que no contamos o estamos acostumbrados a utilizar de manera regular en

nuestra vida cotidiana, de ahí el resultado negativo que frecuentemente se tiene en los alumnos

al saber de él por primera vez.

Un estudiante promedio, llega a la carrera de ingeniería en computación buscando en su

mayoría, darle uso a sus capacidades de abstracción y lógica matemática, conocer la

metodología de cómo desarrollar un videojuego, encaminar su gusto por los dispositivos

electrónicos o seguir la idea familiar de que “la tecnología es lo de hoy y un trabajo con

futuro”.

Un ingeniero en computación, en efecto tiene la capacidad de diseñar y generar

circuitos electrónicos, juegos de video y utiliza la abstracción y la lógica matemática como

herramienta diaria; sin embargo, hay un elemento que para el caso estudiado, es sin duda

trascendente y no recibe la suficiente, o de hecho, ninguna atención por parte del estudiante de

esta rama. ¡La complejidad!, esa complejidad inherente [4] en cualquier proceso que

realicemos, y que en el área de la ingeniería se vuelve aún más intrincada.

Mientras ese ingeniero se prepara académicamente, está siendo entrenado para “resolver

problemas de manera óptima” y con ello facilitarle la existencia a cualquier ser humano o a sí

mismo, ¿cómo lo logra?, uniendo conocimiento (ciencia), metodologías (técnica) y pericia

mental (habilidades); sin embargo ninguna de esas propiedades características de un ingeniero

se pueden desarrollar si no se pone al límite su capacidad, entonces, presentan numerosos

problemas de “alta complejidad” durante su carrera[28].

Cuando se tienen problemas de complejidad simple o moderada, como los que vivimos

día a día y que estamos acostumbrados a resolver, nos basta y sobra una secuencia de pasos

cortos para resolverlo, sin embargo cuando el problema se extiende en el tiempo o en la misma

capacidad humana de comprensión y resolución [8], esa secuencia de pasos cortos deja de ser

suficiente.

"Técnicamente no podemos dar igual atención a dos tareas cognitivas exigentes...no

podemos leer a Shakespeare y aprender física cuántica al mismo tiempo..."

-.Edward Hallowell. (Entrevista BBC Mundo, 19 de Noviembre de 2011)

Para enfrentarnos a un problema más complejo, es necesario desglosarlo en secciones

más pequeñas y más fáciles de comprender [5], de ahí el nacimiento de métodos de análisis

como “top-down” que es parte del paradigma estructurado [6]; sin embargo, siguió habiendo

problemas cada vez más complejos que requerían segmentar aún más y definir un orden de

operaciones, siendo tan grande la cantidad de variables a tomar en cuenta, que llegó el

momento en el que esa solución se convertía de nuevo en un problema; aquí es donde se genera

la orientación a objetos, para definir un problema en función de los componentes que

interactúan en él y la manera en cómo hacen.

Para lograr una efectividad en el uso de un método de análisis, es necesario comprender

su funcionamiento y origen, involucrando el conocimiento científico (sobre todo los

fundamentos de matemáticas, física, lógica y comprensión de problemas) y la capacidad de

abstracción.

La programación, según el diccionario de la Real Academia Española de la Lengua,

significa:

“Elaborar programas para la resolución de problemas mediante ordenadores.”

Es importante señalar que no está indicando un método específico para “elaborar”

dichos programas informáticos, puesto que eso depende totalmente de las herramientas

disponibles, del problema a resolver, del equipo de cómputo disponible, entre muchos otros

factores.

Debido a que este texto tiene por objetivo mostrar los conceptos base de la orientación a

objetos y la problemática asociada a su aprendizaje, resumiré su desarrollo como una serie de

cambios importantes en el hardware de los equipos de cómputo y a su vez, en la complejidad de

los problemas a los que se enfrentaban los científicos, debido a esta forma de cambio, la

metodología pasó de ser secuencial a ser segmentada (en estructuras) [5] y luego a orientación a

objetos. [6] y [4]

En el ámbito tratado de la computación, la programación orientada a objetos es uno de

los pilares del perfil de egreso para el ingeniero en cuestión; sin embargo, se ha visto que

comprender la función de dicho paradigma, la utilidad, sus componentes y el orden de las

relaciones entre ellos, son una dificultad muy grande y parece ser que es debido al vocabulario

usado, que si bien es obvio que pertenece al paradigma, no hay un estándar de su aplicación y

cada autor usa el que considere apropiado dependiendo de su perspectiva y profundiza en

explicaciones de igual forma, como podemos ver comparativamente entre [4] y [1], incluso en

este texto, deliberadamente se utilizaron palabras pertenecientes a conceptos del paradigma en

los párrafos 3 y 5, mostrando así que las definiciones son muy variadas y que posiblemente, las

definiciones convenientes para su comprensión, no las tengamos a la mano.

Debido a lo anterior, se presenta ésta antología sobre los conceptos fundamentales de la

Orientación a Objetos, que son:

Abstracción.

Encapsulamiento.

Jerarquía.

Modularidad.

Se incluyeron ejemplos de cada fundamento, en el Anexo A.

Es oportuno hacer la anotación de que basados en la observación del párrafo 16 “, son una

dificultad muy grande y parece ser que es debido al vocabulario usado” y sabiendo que el

léxico de la programación informática proviene del idioma inglés, se evitó hacer la traducción

de las definiciones o citas descriptivas, para mantener la idea original que busca transmitir el

autor.

Abstracción: “La abstracción es la propiedad que permite representar las características esenciales de

un objeto, sin preocuparse de las restantes características no esenciales. En otras

palabras, la abstracción es la vista externa de un objeto y permite separar su

comportamiento de su implementación.” [10]

“The well-known idea of software objects is that they model objects that physically

exist in the real world. Their data and processes are seen to be characteristics…” [11]

“An object that represents a useful model of a

problem domain or solution domain entity”[12]

“Es una descripción simplificada o especificación de un sistema que enfatiza algunos de

los detalles o propiedades del sistema, mientras suprime otros.”[14]

Encapsulamiento: “…es la propiedad que permite asegurar que el contenido de la información de un

objeto está oculta al mundo exterior…es entonces la ocultación de la información de un

objeto permitiendo la división de un programa en módulos implementados mediante

clases, de forma que una clase representa la encapsulación de una abstracción.” [15]

“Simply stated, the abstraction of an object should precede the decisions about its

implementation. Once an implementation is selected, it should be treated as a secret of

the abstraction and hidden from most clients…Encapsulation hides the details of the

implementation of an object…Encapsulation provides explicit barriers among different

abstractions and thus leads to a clear separation of concerns” [17]

“The idea of encapsulation is extended to include the direct usability of a class’s data

and processes by other classes…The practical power of encapsulation is that it

functionally separates interfaces from implementations” [18]

“We (speaking as an object) do not share with the world any notion of our internal

structure and certainly no sense of how we do what we do.” [19]

“En programación, el término se refiere al énfasis en el "¿qué hace?" más que en el

"¿cómo lo hace?" (…caja negra)” [13]

Modularidad: “The act of partitioning a program into individual components can reduce its

complexity to some degree. . . . Although partitioning a program is helpful for this

reason, a more powerful justification for partitioning a program is that it creates a

number of well-defined, documented boundaries within the program. These boundaries,

or interfaces, are invaluable in the comprehension of the program” [20]

“To manage branching, the concept of structuring software came about. Most succinctly

put, this grouped the steps between the branches, creating a logical organization, with

each branch referencing a group. Further, this created modules, isolated pieces of

software, and even categorized them, meaning that different modules could accomplish

the same types of things.” [21]

“The major advancement in the area of modular programming has been the

development of coding techniques and assemblers which (l) allow one module to be

written with little knowledge of the code in another module, and (2) allow modules to

be reassembled and replaced without reassembly of the whole system.” [22]

“…es la propiedad que permite subdividir una aplicación en partes más pequeñas o

módulos, cada una de las cuales debe ser tan independiente como sea posible de la

aplicación en sí y de las restantes partes.” [15]

Jerarquía: “According to the presuppositions of the object paradigm, a child class is a behavioral

extension of the parent. A dog has all the behavior of a mammal plus some additional

behavior that’s specific to dogs… Behavior is the abstraction that we use to

differentiate among objects, and it should be the only criterion that we use to establish

our taxonomy…

If we say that child classes have access to the resources of their parents via inheritance,

that is, by virtue of the parent-child relationship, our use of inheritance remains

consistent with the object paradigm.” [24]

“La herencia es el proceso mediante el cual un objeto adquiere las propiedades de otro.

Con esto se consigue lo que se conoce como clasificación jerárquica generalmente del

tipo top-down…. La herencia también interactúa con el encapsulado” [15]

“Hierarchy is a ranking or ordering of abstractions. The two most important hierarchies

in a complex system are its class structure (the “is a” hierarchy) and its object structure

(the “part of” hierarchy).” [25]

Como se puede observar en las diferentes citas y definiciones, el uso de ciertas palabras u

omisión de otras, hacen la diferencia entre el alcance de la definición y por tanto el uso de esa

propiedad, por eso se optó por mencionar más de una definición y que provinieran de fuentes

varias desde libros clásicos y potentes [4], hasta apuntes recientes y cortos [1].

Ahora, teniendo conocimiento de varias definiciones de los conceptos básicos de la orientación

a objetos, se puede hacer una referencia a la relación que tienen entre ellas para dejar en claro,

que no son elementos independientes y que se presentan, casi paralelamente, en el proceso de

desarrollo de software.

“Abstraction is a good thing, but in all except the most trivial applications, we may find

many more different abstractions than we can comprehend at one time.

Encapsulation helps manage this complexity by hiding the inside view of our

abstractions.

Modularity helps also, by giving us a way to cluster logically related abstractions. Still,

this is not enough. A set of abstractions often forms a hierarchy, and by identifying

these hierarchies in our design, we greatly simplify our understanding of the problem.”

.-Booch, G The meaning of hierarchy, (p.83) [4]

El desarrollo de software es un ámbito que se encuentra en constante cambio, eso ha evitado

precisamente que se generen estándares para todas sus áreas, sin embargo,

Es interesante y alentador, saber que existe el desarrollo de proyectos en nuestra facultad como

los son TIPOO (Tutorial Inteligente para la enseñanza de la Programación Orientada a

Objetos), para apoyar el aprendizaje duradero y la comprensión real de este paradigma que es

en extremo útil, pues segmenta los elementos del problema, después estos interactúan como lo

harían en la vida real y se genera la solución, haciendo que podamos resolver problemas

inmensos y abrumadores para nuestra percepción y pensamiento.

Espero que sea cada vez sea mayor el apoyo a los estudiantes para lograr un aprendizaje en

ellos de maneras alternativas y que a través de software como TIPOO se pueda estandarizar un

vocabulario del paradigma con definiciones precisas y aceptadas, por lo menos, por nuestra

comunidad estudiantil y así reducir, en la medida de lo posible, el mal entendido, ya sea por

falta o por exceso de elementos en cada definición.

Ejercicios de ejemplo y aplicación de los conceptos básico de la OO.

Abstraccio n.

[7]

“Problem: Design and build a computer hockey game

Solution:

Object: Hockey player

Characteristics: Position, height, weight, salary, number of goals

Responsibilities: Pass the puck, shoot, skate forward, skate backward, punch another player,

etc.”

[4]

Problem:

“On a hydroponics farm, plants are grown in a nutrient solution, without sand, gravel, or other

soils. Maintaining the proper greenhouse environment is a delicate job and depends on the kind

of plant being grown and its age. One must control diverse factors such as temperature,

humidity, light, pH, and nutrient concentrations. On a large farm, it is not unusual to have an

automated system that constantly monitors and adjusts these elements. Simply stated, the

purpose of an automated gardener is to efficiently carry out, with minimal human intervention,

growing plans for the healthy production of multiple crops.

One of the key abstractions in this problem is that of a sensor. Actually, there are several

different kinds of sensors. Anything that affects production must be measured, so we must have

sensors for air and water temperature, humidity, light, pH, and nutrient concentrations, among

other things. Viewed from the outside, a temperatura sensor is simply an object that knows how

to measure the temperature at some specific location. What is a temperature? It is some

numeric value, within a limited range of values and with a certain precision, that represents

degrees in the scale of Fahrenheit, Centigrade, or Kelvin, whichever is most appropriate for our

problem. What is a location? It is some identifiable place on the farm at which we desire to

measure the temperature; presumably, there are only a few such locations.

Hat is important for a temperature sensor is not so much where it is located but the fact that it

has a location and identity unique from all other temperature sensors. Now we are ready to ask:

What are the responsibilities of a temperatura sensor? Our design decision is that a sensor is

responsible for knowing the temperature at a given location and reporting that temperature

when asked.

More concretely, what operations can a client perform on a temperature sensor? Our design

decision is that a client can calibrate it, as well as ask what the current temperature is.” Result:

[4] p.48

Abstraction: Temperature Sensor

Important Characteristics:

temperature

location

Responsibilities:

report current temperature

calibrate

“

Cabe señalar que la abstracción depende completamente del contexto, es decir el problema dado ya

está dando un contexto de partida, con ciertos parámetros de restricción, de ahí se puede ver qué hacer,

además de depender del nivel de conocimientos técnicos y comprensión del paradigma tenga el

analista.

Problema: Genere una clase de operaciones básicas binarias.

Como podemos ver, se trataba de una abstracción de una operación matemática, cosa que no se

puede palpar físicamente, sin embargo existe como entidad.

Operación binaria significa que habrá 2 factores (variables) operándose entre ellos y un tercer

factor (variable) que será el resultado.

Las características entonces están bien definidas:

Factor 1, Factor 2 y resultado.

Así como las acciones esperadas, que sería operar y servir el resultado de dicha operación.

Hay que notar, que aunque pueda haber más operaciones binarias o que esta clase pueda tener

más características o acciones, no se están tomando en cuenta, como las definiciones de

abstracción mencionaban, se toman los datos que son relevantes para el contexto actual.

OPERACIONES BINARIAS BÁSICAS

Es importante hacer notar que éste segmento de código es una clase y aunque está completa, no

puede ejecutarse por sí misma, necesita de hacer uso de las características del tipo “static” o

depender de que un método en otra clase genere una instancia de Operaciones Básicas Binarias.

Encapsulamiento.

Se está dando un ejemplo de la posible aplicación de encapsulamiento.

Este segmento de código está escribo en C++, a diferencia de Java como en el ejemplo anterior

de abstracción, C++ es más estricto con los delimitadores de acceso a sus variables, resaltando

entonces, el hecho de que a algunas características no se tienen acceso y como bien se sabe, eso

es parte del encapsulamiento.

¿Para qué me sirve eso?, para evitar que otra clase1 acceda a algunas características que definen

un cierto estado de mi objeto y las cambien (con o sin consciencia) y mi objeto deje de tener

ese estado deseado.

1 Para consultar la definición de clase, vea [4], capítulo 3.

[4]

Problem:

“To illustrate the principle of encapsulation, let’s return to the problem of the Hydroponics

Gardening System. Another key abstraction in this problem domain is that of a heater. A heater

is at a fairly low level of abstraction, and thus we might decide that there are only three

meaningful operations that we can perform on this object: turn it on, turn it off, and find out if it

is running.

All a client needs to know about the class Heater is its available interface.

Turning to the inside view of the Heater, we have an entirely different perspective.

Suppose that our system engineers have decided to locate the computers that control each

greenhouse away from the building (perhaps to avoid the harsh environment) and to connect

each computer to its sensors and actuators via serial lines. One reasonable implementation for

the Heater class might be to use an electromechanical relay that controls the power going to

each physical heater, with the relays in turn commanded by messages sent along these serial

lines. For example, to turn on a heater, we might transmit a special command string, followed

by a number identifying the specific heater, followed by another number used to signal turning

the heater on.

Separation of Concerns We do not make it a responsibility of the Heater abstraction to maintain

a fixed temperature. Instead, we choose to give this responsibility to another object (e.g., the

Heater Controller), which must collaborate with a temperature sensor and a heater to achieve

this higher-level behavior. We call this behavior higher-level because it builds on the primitive

semantics of temperature sensors and heaters and adds some new semantics, namely, hysteresis,

which prevents the heater from being turned on and off too rapidly when the temperature is

near boundary conditions. By deciding on this separation of responsibilities, we make each

individual abstraction more cohesive.

Abstraction: Heater

Important Characteristics:

Location:

Status:

Responsibilities:

turn on

turn off

provide status

Related Candidate Abstractions: Heater Controller, Temperature Sensor

Responsabilities full fill the encapsulation necessity of defined interface.“

Jerarquí a.

[4]

“Examples of Hierarchy: Single Inheritance

Inheritance is the most important “is a” hierarchy, and as we noted earlier, it is an essential

element of object-oriented systems. Basically, inheritance defines a relationship among classes,

wherein one class shares the structure or behavior defined in one or more classes (denoting

single inheritance and multiple inheritance, respectively). Inheritance thus represents a

hierarchy of abstractions, in which a subclass inherits from one or more superclasses.

Typically, a subclass augments or redefines the existing structure and behavior of its

superclasses. Consider the different kinds of growing plans we might use in the Hydroponics

Gardening System. An earlier section described our abstraction of a very generalized growing

plan. Different kinds of crops, however, demand specialized growing plans. For example, the

growing plan for all fruits is generally the same but is quite different from the plan for all

vegetables, or for all floral crops. Because of this clustering of abstractions, it is reasonable to

define a standard fruitgrowing plan that encapsulates the behavior common to all fruits, such as

the knowledge of when to pollinate or when to harvest the fruit. We can assert that

FruitGrowingPlan “is a” kind of GrowingPlan.

Abstractions form a hierarchy.

60 SECTION I CONCEPTS

In this case, FruitGrowingPlan is more specialized, and GrowingPlan is more general. The

same could be said for GrainGrowingPlan or VegetableGrowingPlan, that is,

GrainGrowingPlan “is a” kind of GrowingPlan, and VegetableGrowingPlan “is a” kind of

GrowingPlan.

Here, GrowingPlan is the more general superclass, and the others are specialized

subclasses. As we evolve our inheritance hierarchy, the structure and behavior that are common

for different classes will tend to migrate to common superclasses. This is why we often speak

of inheritance as being a generalization/specialization hierarchy.

Superclasses represent generalized abstractions, and subclasses represent specializations in

which fields and methods from the superclass are added, modified, or even hidden. In this

manner, inheritance lets us state our abstractions with an economy of expression. Indeed,

neglecting the “is a” hierarchies that exist can lead to bloated, inelegant designs. “Without

inheritance, every class would be a free-standing unit, each developed from the ground up.

Different classes would bear no relationship with one another, since the developer of each

provides methods in whatever manner he chooses. Any consistency across classes is the result

of discipline on the part of the programmers. Inheritance makes it possible to define new

software in the same way we introduce any concept to a newcomer, by comparing it with

something that is already familiar” [64].

There is a healthy tension among the principles of abstraction, encapsulation, and hierarchy.

“Data abstraction attempts to provide an opaque barrier behind which methods and state are

hidden; inheritance requires opening this interface to some extent and may allow state as well

as methods to be accessed without abstraction” [65]. For a given class, there are usually two

kinds of clients: objects that invoke operations on instances of the class and subclasses that

inherit from the class.

Liskov therefore notes that, with inheritance, encapsulation can be violated in one of three

ways: “The subclass might access an instance variable of its superclass, call a private operation

of its superclass, or refer directly to superclasses of its superclass” [66]. Different programming

languages trade off support for encapsulation and inheritance in different ways. C++ and Java

offer great flexibility.

Specifically, the interface of a class may have three parts: private parts, which declare members

that are accessible only to the class itself; protected parts, which declare members that are

accessible only to the class and its subclasses; and public parts, which are accessible to all

clients.”

[4]

“Examples of Hierarchy: Multiple Inheritance

The previous example illustrated the use of single inheritance: the subclass FruitGrowingPlan

had exactly one superclass, the class GrowingPlan. For certain abstractions, it is useful to

provide inheritance from multiple superclasses.

CHAPTER 2 THE OBJECT MODEL 61

For example, suppose that we choose to define a class representing a kind of plant. Our analysis

of the problem domain might suggest that flowering plants and fruits and vegetables have

specialized properties that are relevant to our application.

For example, given a flowering plant, its expected time to flower and time to seed might be

important to us. Similarly, the time to harvest might be an important part of our abstraction of

all fruits and vegetables. One way we could capture our design decisions would be to make two

new classes, a Flower class and a FruitVegetable class, both subclasses of the class Plant.

However, what if we need to model a plant that both flowered and produced fruit? For

example, florists commonly use blossoms from apple, cherry, and plum trees. For this

abstraction, we would need to invent a third class, FlowerFruitVegetable, that duplicated

information from the Flower and FruitVegetable classes.

A better way to express our abstractions and thereby avoid this redundancy is to use multiple

inheritance. First, we invent classes that independently capture the properties unique to

flowering plants and to fruits and vegetables. These two clases have no superclass; they stand

alone. These are called mixin classes because they are meant to be mixed together with other

classes to produce new subclasses.

For example, we can define a Rose class that inherits from both Plant and FlowerMixin.

Instances of the subclass Rose thus include the structure and behavior from the class Plant

together with the structure and behavior from the class FlowerMixin.

Similarly, a Carrot class could be. In both cases, we form the subclass by inheriting from two

superclasses.

Now, suppose we want to declare a class for a plant such as the cherry tree that has both

flowers and fruit.

62 SECTION I CONCEPTS

Multiple inheritance is conceptually straightforward, but it does introduce some practical

complexities for programming languages. Languages must address two issues: clashes among

names from different superclasses and repeated inheritance.

Clashes will occur when two or more superclasses provide a field or operation with the same

name or signature as a peer superclass.

CHAPTER 2 THE OBJECT MODEL 63

Repeated inheritance occurs when two or more peer superclasses share a common superclass.

In such a situation, the inheritance lattice will be diamond-shaped, so the question arises, does

the leaf class (i.e., subclass) have one copy or multiple copies of the structure of the shared

superclass?

Some languages prohibit repeated inheritance, some unilaterally choose one approach, and

others, such as C++, permit the programmer to decide. In C++, virtual base classes are used to

denote a sharing of repeated structures, whereas nonvirtual base classes result in duplicate

copies appearing in the subclass (with explicit qualification required to distinguish among the

copies).

Multiple inheritance is often overused. For example, cotton candy is a kind of candy, but it is

distinctly not a kind of cotton. Again, the litmus test for inheritance applies: If B is not a kind of

A, then B should not inherit from A. Ill-formed multiple inheritance lattices should be reduced

to a single superclass plus aggregation of the other classes by the subclass, where possible.”

Un ejemplo aplicado de Jerarquía:

Diagrama clases general:

Arriba se puede apreciar la distribución de clases.

Se tiene una relación de herencia simple, ALUMNO y MAESTRO heredan de PERSONA, además de

que PERSONA utiliza la clase TARJETA_PRESENTACIÓN_ASCII y la clase MANEJADROR es donde se

realizan las operaciones de creado de instancias y llamado de acciones.

A continuación se muestra el código de las 3 clases que interactúan en la relación de herencia

simple, MAESTRO, ALUMNO y PERSONA.

Persona

Alumno Maestro

TarjetaPresen

tacionASCII

Manejdor

Nótese, que la palabra reservada “abstract” no está relacionada con el proceso de “Abstracción”

como se ha visto.

Esta instrucción es parte de los lenguajes de programación e indica que el elemento afectado, en

este caso un método “mostrarTarjetaPresentacion()”, solo se va a indicar su prototipo, sin cuerpo

de operaciones.

Si se quiere profundizar más sobre el tema, consultar la documentación propia del lenguaje, en

este caso, Java.

Modularidad.

[4]

Continuing the Hydroponic Problem:

“Let’s look at modularity in the Hydroponics Gardening System. Suppose we decide to use a

commercially available workstation where the user can control the system’s operation. At this

workstation, an operator could create new growing plans, modify old ones, and follow the

progress of currently active ones. Since one of our key abstractions here is that of a growing

plan, we might therefore create a module whose purpose is to collect all of the classes

associated with individual growing plans (e.g., FruitGrowingPlan, GrainGrowingPlan). The

implementations of these GrowingPlan classes would appear in the implementation of this

module. We might also define a module whose purpose is to collect all of the code associated

with all user interface functions. Our design will probably include many other modules.

Ultimately, we must define some main program from which we can invoke this application. In

objectoriented design, defining this main program is often the least important decision, whereas

in traditional structured design, the main program serves as the root, the keystone that holds

everything else together. We suggest that the object-oriented view is more natural, for, as

Meyer observes, “Practical software systems are more appropriately described as offering a

number of services. Defining these systems by single functions is usually possible, but yields

rather artificial answers. . . . Real systems have no top[23].”

Referencias: [1] Rossainz López, M. (2012). Programación avanzada-prope.mcc. México, Benemérita

Universidad de Pueba. Consultado: Octubre 2012

[2] Anthony, G. (2012). Iterating Infusion: Clearer Views of Objects, Classes, and Systems.

U.S. Apress

[3] Booch, G. (1995). Object Solution: Managing the Object-Oriented Projects. U.S. Addison

Wesley

[4] Booch, G. (2007). Object Oriented Design with Applications. U.S. Addison Wesley

[5] Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules.

U.S. Carnegie-Mellon University

[6] W. Floyd, Robert (1979). The Paradigms of Programming. U.S. Stanford University

[7] Yang, J. y Kang, E. (2010). Object-oriented programming in C++. U.S. MIT open

courseware 6.008 Intro to C/C++

[8] Snoeck, M y Dedene, G. (1996). Generalization/Specialization and Role in Object Oriented

Conceptual Modeling. U.S. Katholieke Universiteit Leuven, Dept. of Applied Economic

Sciences.

[9] West, D. (2004). Object Thinking. U.S. Microsoft Press.

[10] Rossainz López, M. (2012). Programación avanzada-prope.mcc, (p.2). México,

Benemérita Universidad de Pueba. Consultado: Octubre 2012

[11] Anthony, G. (2012). Iterating Infusion: Clearer Views of Objects, Classes, and Systems.

(p.12) U.S. Apress

[12] Booch, G. (2007). Object Oriented Design with Applications, (p.70). U.S. Addison Wesley

[13] Wikipedia (2013). Abstraction. retrieved from: URL:

http://es.wikipedia.org/wiki/Abstracci%C3%B3n_(inform%C3%A1tica) consulted on:

02/09/2013

[14] Zavala, R. (2012). ¿Qué es la ingeniería de Software?, la visión tradicional. retrieved

from: URL: http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#Greiff1994

consulted on: 02/09/2013

[15] Rossainz López, M. (2012). Programación avanzada-prope.mcc, (p.3). México,

Benemérita Universidad de Pueba. Consultado: Octubre 2012

[16] Peralta Mendoza, M.(2008). Ejemplo de uso C++ con clases e instancias. retrieved from:

URL: http://c.conclase.net/?id=vercodigo consulted on: 02/09/2013

[17] Booch, G. (2007). Object Oriented Design with Applications, (p.51). U.S. Addison Wesley

[18] Anthony, G. (2012). Iterating Infusion: Clearer Views of Objects, Classes, and Systems,

(p.35). U.S. Apress

[19] West, D. (2004). Object Thinking, (p.121). U.S. Microsoft Press.

[20] Booch, G. (2007). Object Oriented Design with Applications, (p.79). U.S. Addison Wesley

[21] Anthony, G. (2012). Iterating Infusion: Clearer Views of Objects, Classes, and Systems,

(p.8). U.S. Apress

[22] Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules,

(p.1). U.S. Carnegie-Mellon University

[23] Meyer. (1997). Object-Oriented Software Construction, p. 47.

[24] West, D. (2004). Object Thinking, (p.114). U.S. Microsoft Press.

[25] Booch, G. (2007). Object Oriented Design with Applications, (p.83). U.S. Addison Wesley

[26] Mapa ideal Ingeniería en Computación 2009-2 Final Noviembre 2010 FCQI/UABC.

[27] FCQI Web (2013). Perfil de egreso. retrieved from: URL:

http://fcqi.tij.uabc.mx/usuarios/ingcomp/perfil_egreso.php consulted on: 02/09/2013

[28] Booch, G. (1995). Object Solution: Managing the Object-Oriented Projec, (p.163). U.S.

Addison Wesley.

[29] Booch, G. (1995). Object Solutions: Managing the Object-Oriented Project, (p.148). U.S.

Addison Wesley.