Antología de definiciones y relaciones entre conceptos base en la Orientación a Objetos con...
-
Upload
rafael-karosuo -
Category
Documents
-
view
17 -
download
0
description
Transcript of Antología de definiciones y relaciones entre conceptos base en la Orientación a Objetos con...
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.
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.