UNIDAD 1

CONCEPTOS BASICOS DEL MODELADO DE OBJETOS

1.1 Reconocimiento de objetos y clases en el mundo real y la interacción
entre ellos.

La capacidad de reconocer objetos físicos es una habilidad que los humanos aprenden en edades
muy tempranas. Una pelota de colores llamativos atraerá la atención de un niño, pero casi
siempre, si se esconde la pelota, el niño no intentará buscarla; cuando el objeto abandona su
campo de visión, hasta donde él puede determinar, la pelota ha dejado de existir. Normalmente,
hasta la edad de un año un niño no desarrolla lo que se denomina el concepto de objeto, una
habilidad de importancia crítica para el desarrollo cognitivo futuro. Muéstrese una pelota a un
niño de un año y escóndase a continuación, y normalmente la buscará incluso si no esta visible. A
través del concepto de objeto, un niño llega a darse cuenta de que los objetos tienen una
permanencia e identidad además de cualesquiera operaciones sobre ellos. Informalmente
podemos entender un objeto como una entidad tangible que exhibe algún comportamiento bien
definido. Desde la perspectiva de la cognición humana, un objeto es cualquiera de las siguientes
cosas:

• Una cosa tangible y/o visible

• Algo que no puede comprenderse intelectualmente
• Algo hacia lo que se dirige un pensamiento o acción

Clases

Para comprender la naturaleza de una clase, se deberán considerar dos niveles de definición:
El abstracto y el de instrumentación.
El nivel abstracto de una clase proporciona la esencia de la clase. En seguida se define una clase en
el nivel abstracto. En el nivel abstracto, una clase se describe como una interfaz que define el
comportamiento de sus objetos.

Una clase se puede describir como una interfaz, porque su propósito principal es describir las
operaciones, o funciones, que pueden realizar sus objetos. De esta manera, se define el
comportamiento común para todos sus objetos. Por comportamiento, se entiende cómo actúa y
reacciona un objeto de una clase dada cuando se acceda

1.2 La abstracción y el encapsulamiento.

Las personas normalmente comprenden el mundo construyendo modelos mentales de parte de

los mismos; tratan de comprender cosas con las que pueden interactuar: un modelo mental es una
vista simplificada de cómo funciona de modo que se pueda interactuar contra ella. En esencia,
este proceso de construcción de modelos es lo mismo que el diseño de software, aunque el
desarrollo de software es único. El diseño de software produce el modelo que puede se
manipulado por una computadora.
La abstracción es esencial para el funcionamiento de una mente humana normal y es una
herramienta muy potente para tratar la complejidad. Considerar, por ejemplo, el ejercicio mental
de memorizar números. Un total de siete dígitos se puede memorizar con más o menos facilidad.
Sin embargo, si se agrupan y se denominan números de teléfono, los dígitos individuales se
relegan en sus detalles de más bajo nivel, creándose un nivel abstracto y más alto, en el que los
siete números se organizan en una única entidad. Utilizando este mecanismo se puede memorizar
algunos números de teléfonos, de modo que la agrupación de diferentes entidades conceptuales
es un mecanismo potente al servicio de la abstracción.

Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los
demás tipos de objeto y proporciona así fronteras conceptuales nítidamente definidas respecto a la
perspectiva del observador.

Una abstracción se centra en la visión externa de un objeto y, por tanto, sirve para separar el
comportamiento esencial de un objeto de su implantación.

Seidewitz y Stara sugieren que «existe una gama de abstracción, desde los objetos que modelan
muy de cerca entidades del dominio del problema a objetos que no tienen una verdadera razón
para existir». De mayor a menor utilidad, estos tipos de abstracción incluyen:

• Abstracción de entidades. Un objeto que representa un modelo útil de una entidad del dominio
del problema o del dominio de la solución.

• Abstracción de acciones. Un objeto que proporciona un conjunto generalizado de operaciones, y

todas ellas desempeñan funciones del mismo tipo.

• Abstracción de máquinas. Un objeto que agrupa operaciones, todas ellas virtuales utilizadas por
algún nivel superior de control, u operaciones que utilizan todas algún conjunto de operaciones de
nivel inferior.

• Abstracción de coincidencia. Un objeto que almacena un conjunto de operaciones que no tiene

relación entre sí. Se persigue construir abstracciones de entidades, porque imitan directamente el
vocabulario de un determinado dominio de problema

Encapsulamiento
Dicho sencillamente, la abstracción de un objeto debería preceder a las decisiones sobre su
implementación. Una vez que se ha seleccionado una implantación, debe tratarse como un
secreto de la abstracción, oculto para la mayoría de los clientes. Como sugiere sabiamente Ingalls,
«ninguna parte de un sistema complejo debe depender de los detalles internos de otras partes».

Mientras que la abstracción «ayuda a las personas a pensar lo que están haciendo», el
encapsulamiento «permite que los cambios hechos en los programas sean fiables con el menor
esfuerzo».

La abstracción y el encapsulamiento son conceptos complementarios: la abstracción se centra en

el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la
implementación que da lugar a este comportamiento. El encapsulamiento se consigue a menudo
mediante la ocultación de información, que es el proceso de ocultar todos los secretos de un
objeto que no contribuye a sus características esenciales; típicamente, la estructura de un objeto
esta oculta, así como la implantación de sus métodos.

El encapsulamiento proporciona barreras explícitas entre abstracciones diferentes y por tanto

conduce a una clara separación de intereses. Por ejemplo considérese la estructura de una planta.

Para comprender como funciona la fotosíntesis a un nivel alto de abstracción, se pueden ignorar
detalles como los cometidos de las raíces de la planta o la química de las paredes de las células.
Análogamente, al diseñar una aplicación de bases de datos, es práctica común el escribir programa
de forma que no se preocupen de la representación física de los datos, sin que dependan solo de
un esquema que denota la vista lógica de los mismos. Los objetos a un nivel de abstracción están
protegidos de los detalles de implementación a niveles más bajos de abstracción.

Para resumir, se define el encapsulamiento como sigue:

El encapsulamiento es el proceso de almacenar en un mismo compartimento de los elementos de

una de una abstracción que constituye su estructura y su comportamiento; sirve para separar el
interfaz contractual de una abstracción y su implantación.

1.3 La POO y la complejidad del software.

La abstracción es la clave para diseñar buen software. En los primeros días de la informática, los
programadores enviaban instrucciones binaras a una computadora, manipulando directamente
interrupciones en sus partes frontales. Los nemotécnicos del lenguaje ensamblador eran
abstracciones diseñadas para evitar que los programadores tuvieran que recordar las secuencias
de bits que componen las instrucciones de un programa. El siguiente nivel de abstracción se
consigue agrupando instrucciones primitivas para formar macroinstrucciones.

Por ejemplo, un conjunto se puede definir por abstracción como una colección no ordenada de
elementos en el que no existen duplicados. Utilizando esta definición, se puede especificar si sus
elementos se almacenan en un array, una lista enlazada o cualquier otra estructura de datos.
Un conjunto de instrucciones realizadas por un usuario se pueden invocar por un
macroinstrucción; un macroinstrucción instruye a la máquina para que realice muchas cosas.

Tras los lenguajes de programación ensambladores aparecieron los lenguajes de programación de

alto nivel, que supusieron un nuevo nivel de abstracción. Los lenguajes de programación de alto
nivel permitieron a los programadores distanciarse de las interioridades arquitectónicas
específicas de una máquina dada. Cada instrucción en un lenguaje de alto nivel puede invocar
varias instrucciones máquina, dependiendo de la máquina específica donde se compila el
programa. Esta abstracción permitía a los programadores escribir software para propósito
genérico, sin preocuparse sobre que máquina corre el programa.

El proceso de abstracción fue evolucionando desde la aparición de los primeros lenguajes de

programación. El método más idóneo para controlar la complejidad fue aumentar los niveles de
abstracción. En esencia la abstracción supone la capacidad de encapsular y aislar la información
del diseño y ejecución. En un determinado sentido, las técnicas orientadas a objetos pueden verse
como un producto natural de una larga progresión histórica que va desde las estructuras de
control, pasando por los procedimientos, los módulos, los tipos abstractos de datos y los objetos

1.4 Conceptos del ciclo de vida del software.

El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que
comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo
producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el
último de sus usuarios.
La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario
aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al software, a continuación
dos conceptos:

“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el

mantenimiento del software” IEEE 10744

“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en
el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida
del sistema desde la definición de los requisitos hasta la finalización de su uso” ISO 12207-15

1.4.1 Especificaciones de requerimientos.

Expresión de necesidades.

Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados
los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no
cómo, se va a desarrollar).

Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el
documento resultante suele tener como origen una serie de entrevistas cliente-proveedor
situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas
partes (puede incluso tomarse como base para el propio acuerdo comercial).

Especificaciones.

Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se

tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de
imprecisiones que será necesario completar y depurar.

Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el
sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy
buena elección para llevar a cabo la especificación del sistema).
Lo más normal será que no resulte posible obtener una buena especificación del sistema a la
primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la
evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos
todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan
requerimientos nuevos o modificaciones de los ya contemplados).

Análisis.

Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su

estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, ...que van a dar una
descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué
comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista
relacionados pero diferentes:

• Funcional.
• Estático.
• Dinámico.
• Diseño

Diseño

Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar
como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades
y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos
expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos
a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones
correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos
vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc.

Unas veces se dirán justificadas en simple política de empresa y por mantener "compatibilidad" en
lo que respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de
que tal o cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte
de los casos no serán rumores con fundamento o estudios previos realizados al efecto, sino más
bien debidos a la propia publicidad como consejera).

Implementación.

Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las
etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado
sistema gestor de bases de datos.

Lamentablemente en la actualidad, quedan bastantes empresas en las que, tras una reunión
comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de
tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de
implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de
vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y
diseño con la consiguiente pérdida de control sobre la gestión del proyecto.

Pruebas.

El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin
errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel
de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del
proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.e. de rendimiento).

Validación.

Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los
requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para
esta fase también es interesante contar con los use cases, generados a través de las
correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple
con lo descrito por estos).

Mantenimiento y Evolución.

Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento

para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento
se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de
corrección como de mejora de la aplicación (p.e. mejora del rendimiento), así como otras de
mayor importancia, fruto de la propia evolución (p.e. nuevas opciones para el usuario debidas a
nuevas operaciones contempladas para el producto).

1.4.2 Análisis Orientado a Objetos.

Se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y

se expresa con los casos de uso. El diseño lógico es la solución del equipo de proyecto del negocio
y consiste de las siguientes tareas: Identificar los usuarios y sus roles Obtener datos de los usuarios
Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la
arquitectura de la empresa

El análisis orientado a objetos es un método de análisis que examina los requisitos desde la
perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema

1.4.3 Diseño Orientado a Objetos.

El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición

orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos
estático y dinámico del sistema que diseña.
El diseño de software orientado a objeto anima a pensar en el software como un modelo muy
próximo a la forma en que pensamos, e interaccionamos con él, en el mundo real. En edad
temprana, aprendemos acerca de los objetos y de cómo se manipulan. Los bebés, aprende que si
mueven un sonajero hará ruido. Más tarde, a medida que se desarrollan las capacidades
cognitivas, somos consientes de que los objetos tienen propiedades y empezamos a pensar en
ellos de forma abstracta. Por ejemplo, un bebé crecido pronto se da cuenta de que hacer ruido es
una capacidad de todos los sonajeros
1.4.4 Programación Orientada a Objetos, conceptos y características.

La orientación a objetos puede describirse como el conjunto de disciplinas (ingeniería) que

desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de
componentes.

La programación orientada a objetos permite una representación más directa del modelo de
mundo real en el código. El resultado es que la transformación radical normal de los requisitos de
sistema (definido en términos de usuario) se reduce considerablemente.

La programación orientada a objetos es un método de implementación en que los programas se

organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una
instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases
unidas mediante relaciones de herencia.

Hay tres características importantes:

1. Utiliza objetos, no algoritmos, como sus bloques lógicos de construcción fundamentales.

2. Cada objeto es una instancia de alguna clase
3. Las clases están relacionadas con otras clases por medio de relaciones de herencia

1.5 Elementos primordiales en el modelo de objetos.

Los elementos más importantes que deben tener los objetos de software que sirven como base
sobre las cuales se fundamenta la programación orientada a objetos, para cumplir con el
paradigma de orientación a objetos son:

• Abstracción
• Encapsulamiento
• Modularidad.
• Herencia y Jerarquía.
• Polimorfismo.

Cada uno de estos puntos requiere de una actitud mental diferente, una forma distinta de pensar
en el problema. Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el
modelo de objetos.

1.5.1 Abstracción.
La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos con la
complejidad inherente al software. La abstracción es el proceso de simplificar un problema
complejo. Al abordar la solución de un problema, uno no se abruma con cada uno de los detalles,
mas bien, lo simplifica enfocándose tan sólo en los aspectos relevantes para la solución.

Una abstracción se centra en la vista externa de un objeto, de un modo que sirva para separar el
comportamiento esencial de un objeto de su implementación. Definir una abstracción significa
describir una entidad del mundo real, no importa lo compleja que pueda ser, y a continuación
utilizar esta descripción en un programa.
El elemento clave de la programación orientada a objetos es la clase. Una clase se puede definir
como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por
su estado específico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, un
pluma estilográfica es un objeto que tienen un estado (llena de tinta o vacía) y sobre la cual se
pueden realizar algunas operaciones (por ejemplo escribir, poner o quitar el capuchón, llenar de
tinta si está vacía).

La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de
clases para gestionar dichas abstracciones en lenguajes de programación ha facilitado
considerablemente su aplicación.

1.5.2 Encapsulamiento.

La encapsulación o encapsulamiento es la propiedad que permite asegurar que el contenido de la

información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el
objeto B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en
esencia, es el proceso de ocultar todos los objetos de un objeto que no contribuyen a sus
características esenciales.

La encapsulación permite la división de un programa en módulos. Estos módulos se implementan

mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la
práctica, esto significa que cada clase debe tener dos partes una interfaz y una implementación. El
interfaz de una clase captura solo su vista externa y la implementación contiene la representación
de la abstracción, así como los mecanismos que realizan el comportamiento deseado.

1.5.3 Modularidad.

La modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas
(llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la
aplicación en si y de las restantes partes.

La modularización, consiste en dividir un programa en módulos que se puedan compilar por

separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los
lenguajes soportan la modularidad de diversas formas. Por ejemplo, en C++ los módulos son
archivos compilados por separado. La práctica usual es situar los interfaces de los módulos en
archivos con nombres con extensión .h (archivos de cabecera) y las implementaciones de los
módulos se sitúa en archivos con nombre con extensión .cpp.
La modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de
módulos cohesivos y débilmente acoplados

1.5.4 Jerarquía y herencia.

Una de las propiedades más importantes de la programación orientada a objetos es la herencia.

De hecho, algunos piensan que un programa que no emplea herencia no es un programa
orientado a objetos.

La herencia es aquella propiedad de la programación orientada a objetos que le permite a una

clase, llamada clase derivada, compartir la estructura y el comportamiento de otra clase, llamada
clase base.

La naturaleza está llena de herencia. Todas las cosas vivas heredan las características o rasgos de
sus antepasados. Aunque usted es diferente de sus padres en muchos sentidos, también es igual
en muchas formas debido a los rasgos genéticos que ha heredado de ellos. En la programación
orientada a objetos, la herencia permite que las clases recién creadas hereden miembros de clases
existentes. Estas nuevas clases derivadas o hijos, incluirán sus propios miembros y miembros
heredados de las clases base o padres. De esta manera, es posible ver una colección de clases con
miembros heredados comunes como una familia de clases, como aquélla a la que usted
pertenece. Las clases se relacionan una con otra a través de la herencia. Tal herencia crea una
jerarquía de clase.

La jerarquía es una propiedad que permite una ordenación de las abstracciones. Las dos jerarquías
mas importantes de un sistema complejo son: estructura de clases (jerarquía «es–un» (is–a):
generalización/especialización) y una estructura de objetos (jerarquía «parte–de» (part– of):
agregación).

Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la

herencia define una relación entre clases, en donde una clase comparte la estructura o
comportamiento definido en una o mas clases (herencia simple y herencia múltiple,
respectivamente).

La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas

lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en
consecuencia, camión es una agregación y ruedas, motor, transmisión y chasis son agregados de
camión.

1.5.5 Polimorfismo.

La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el

polimorfismo. Característica fundamental de la POO, que no es otra cosa que la posibilidad de
construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece
cada uno, con comportamientos diferentes. Esta propiedad no suele ser considerada como
fundamental en los diferentes modelos de los objetos propuestos, pero, dada su importancia, no
tiene sentido considerar un objeto modelo que no soporte esta propiedad.

Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome
muchas formas. En términos prácticos, el polimorfismo permite a objetos de clases diferentes
mediante el mismo elemento de programa y realizar la misma operación de diferentes formas,
según sea el objeto que se referencia en ese momento.

1.6 Historia de los paradigmas en el desarrollo del software.

El significado de paradigma (paradigma en latín; paradeigma en griego) en su origen significaba un

Ejemplo ilustrativo, en particular enunciado modelo que mostraba todas las inflexiones de una
palabra.
Paradigmas: Representan un enfoque particular o filosofía para la construcción del software. No
es mejor uno que otro sino que cada uno tiene ventajas y desventajas

La programación orientada a objetos (POO) se suele conocer como un nuevo paradigma de

programación. Otros paradigmas conocidos son: el paradigma de la programación imperativa (con
lenguajes tales como Pascal o C), el paradigma de la programación lógica (PROLOG) y el
paradigma de la programación funcional (Lisp).

En este sentido, la programación orientada a objetos es un nuevo paradigma. La orientación a

objetos fuerza a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa
realizar computación y sobre como se estructura la información dentro del computador.

1.7 Beneficios del modelo de objetos y de la POO sobre otros paradigmas

La programación orientada a objetos es una técnica para programar: un paradigma para escribir
“buenos” programas para un conjunto de problemas.

El apoyo para un paradigma no viene solo en la forma obvia de los recursos del lenguaje que
permiten emplear directamente el paradigma, sino también en la forma más sutil de verificaciones
en los tiempos de compilación o ejecución, o ambos, contra desviaciones no intencionales
respecto al paradigma. La verificación de tipos es el ejemplo mas obvio de esto; la detección de
ambigüedades y las verificaciones durante la ejecución pude servir para ampliar el apoyo
lingüístico de los paradigmas. Los recursos extra lingüísticos, como las bibliotecas estándar y los
ambientes de programación, pueden proporcionar también un apoyo importante para los
paradigmas.

Un lenguaje no es por fuerza mejor que otro por poseer una característica de la que carece el otro.
Existen muchos ejemplos de lo contrario. Lo importante no es tanto que características posee un
lenguaje, sino que estas sean suficientes para apoyar los estilos de programación deseados en las
áreas de aplicaciones deseadas:

• Todas las características deben estar integradas al lenguaje en forma muy limpia y elegante.
• Debe ser posible utilizar una combinación de características distintivas para lograr soluciones
que de otra manera habrían requerido características independientes adicionales.

• El numero de características espurias y de aplicación especial debe ser lo mas bajo posible.

• La realización de un rasgo distintivo no debe implicar un gasto extra significativo para los
programas que no lo requieran.

• Un usuario solo necesita saber acerca del subconjunto del lenguaje empleado explícitamente
para escribir un programa.