0.

- PREFACE
<<Orientación a Objetos>> es lo último:
 complementando y reemplazando en muchos casos a la <<estructuración>>

En estos casos en inevitable: El método objeto-orientado no es una mera moda:

 que el término sea usado poro personas diferentes con diferentes significados.  No es trivial (superficial)  aunque se intentará abordara del modo más claro posible
 Una secuencia de reacciones:  Funciona
o <<Es trivial>>  Es diferente e incluso incompatible, en cierto punto, con técnicas que aún se usan.
o <<No puede funcionar>>
o <<Así es como lo estaba haciendo todo el tiempo>>

La tecnología de objetos  tiene el potencial para afrontar los cambios fundamentales de la industria del software.
 Y está aquí para quedarse.

Se espera que el lector:

 Progrese a lo largo de este texto
 Compare estas opiniones acerca de este modo prometedor de: análisis, diseño e implementación de software.

Modo para el análisis, diseño e implementación de software

Para presentar el método objeto-orientado: Esta no es la única posible perspectiva de aplicación de los principios objeto-orientados.
 Este libro toma un punto de vista de ingeniería de software.  Otras áreas: programación exploratoria, inteligencia artificial, …
o Métodos, herramientas, y técnicas
o para desarrollar software de calidad Esta presentación no excluye estas aplicaciones:
o en entornos de producción.  simplemente no están enfatizadas.

El principal objetivo del texto es:

 estudiar cómo los desarrolladores de software pueden usar la tecnología de objetos
 para mejorar (incluso dramáticamente) la calidad del software que producen
 en entornos industriales y académicos.

ESTRUCTURA, FIABILIDAD, EPISTEMOLOGÍA Y CLASIFICACIÓN

La tecnología de objetos es, en su núcleo, la combinación de 4 ideas:
 un método de estructuración
 una disciplina fiable
 un principio epistemológico (del estudio del conocimiento)
 una técnica de clasificación

MÉTODO DE ESTRUCTURACIÓN  Se aplica a la descomposición y reutilización del software.

Los sistemas de software: El concepto resultante es  la clase
 realizan ciertas acciones en objetos de ciertos tipos.  un mecanismo remarcablemente potente y versátil.
 Para obtener sistemas flexibles y reutilizables  basar sus estructuras en:  Que sirve de base, en construcciones de software OO:
o los tipos de objetos o Para la estructura modular
o mejor que en las acciones. o Para el sistema de tipos.

DISCIPLINA FIABLE  Enfoque radical para construir software que haga lo que se supone que debe hacer.
La idea es:
 Tratar cualquier sistema como un conjunto de componentes que colaboran entre ellos
 De modo que cada componente o parte:
o se adhiere a los contratos de obligaciones y beneficios que les incumbe
o definidos explícitamente

PRINCIPIO EPISTEMOLÓGICO Direcciona la cuestión de cómo se deben describir las clases

En la tecnología de objetos:
 los objetos descritos por una clase son sólo definidos por: <<qué se puede hacer con ellos>>
o operaciones  también llamadas características
o propiedades formales de esas operaciones  los contratos
Esta idea es formalmente expresada por la: teoría de tipos de datos abstractos.
 Se cubre en detalle en el Capítulo 6 de este libro.
Esto tiene implicaciones de largo-alcance y que van más allá del software:
 El concepto de <<objeto>> es más que el del su significado ordinario
El modelado tradicional de sistemas de la información:
 normalmente asume una <<realidad externa>> que es anterior al programa que la usa.
En el desarrollo OO:
 esta noción (realidad externa al programa que la usa) no tiene sentido.
 La realidad no existe independientemente de que queramos hacer con ella.
 Lo que existe o no existe es una cuestión irrelevante:
o Sólo se conoce:
 Lo que se puede usar
 Y cómo se puede usar  que define lo sabemos de ese algo.

TÉCNICA DE CLASIFICACIÓN  Se deduce de la observación de que:

 se requiere la creación de taxonomías (clasificaciones - orden)
 para el trabajo intelectual en general
 para el razonamiento científico en particular
El software no es una excepción:
 el método OO  se basa fuertemente en una disciplina de clasificación: Herencia.

SIMPLE PERO POTENTE

Los 4 conceptos: clases, contratos, tipos de datos abstractos y herencia llevan inmediatamente a una serie de cuestiones:
 cómo se encuentra n y describen las clases
 cómo los programas debieran manipular las clases y sus instancias (objetos) correspondientes
 cuáles son las posibles relaciones entre las clases
 cómo se relacionan estas ideas con las preocupaciones claves de la ingeniería de software (como extensibilidad, eficiencia, facilidad de uso, …)

Las respuestas a estas preguntas:

 se basan en una pequeña pero poderosa gama de técnicas para producir software de calidad (reutilizable, extensible, fiable, …):
o polimorfismo y enlace dinámico
o una nueva visión de tipos y chequeo de tipos
o genéricos, restricciones y sin-restricciones
o ocultación de la información
o aserciones
o manejo seguro de excepciones
o recolector de basura (garbage collector) automático
 Técnicas de implementación eficientes han sido desarrolladas para permitir aplicar estas ideas exitosamente:
 tanto a proyectos pequeños como largos
 bajo las estrictas condiciones del desarrollo de software comercial

Las técnicas OO han tenido también un impacto considerable en:

 interfaces de usuario
 entornos de desarrollo
 permitiendo producir software interactivo sistemas mucho mejores.

ORGANIZACIÓN DEL TEXTO

Este texto revisa los métodos y técnicas de la construcción de software OO.
 Está dividido en 6 partes

PARTE 1  Introducción y visión general

Proporciona una primera visión del enfoque OO:
 Comienza explorado los temas fundamentales de la calidad de software.
 Continúa con un apuntamiento (reseña) de las características técnicas del método.

PARTE 2  <<El camino hacia la OO>>

Describe las preocupaciones metodológicas que llevan a los conceptos OO centrales:
 Su enfoque es la modularidad  necesaria para diseñar estructuras satisfactorias en construcciones de sistemas a larga-escala.
 Termina con la presentación de tipos de datos abstractos bases matemáticas para tecnología de objetos.
o Las matemáticas involucradas son elementales
o Pero se presenta la base teórica necesaria para un entendimiento pleno de los principios y problemas OO.

PARTE 3  Núcleo técnico del libro.

Se presentan, uno a uno, los componentes técnicos del método OO.
 Clases
 Objetos y el modelo run-time asociado
 Temas de administración de la memoria
 Genéricos y tipado
 Diseño por contrato, Aserciones, Excepciones
 Herencia  con sus conceptos y aplicaciones asociadas:
o Polimorfismo
o Enlace dinámico

PARTE 4  Discute la metodología OO (énfasis especial en análisis y diseño)

Se presentan algunos patrones de diseño fundamentales Comienza con un meta-discusión de los requerimientos intelectuales:
 A través de varios casos de estudio  De los metodólogos
 Y otros asesores
Cubre cuestiones centrales como:
 Cómo encontrar las clases Concluye con:
 Cómo usar la herencia propiamente  una revisión del proceso de software (modelo del ciclo-de-vida) para el desarrollo OO
 Cómo diseñar librerías reusables.  una discusión de cómo es mejor aprender el método en la industria y universidades.

PARTE 5  explora temas avanzados

Como:
 concurrencia, distribución, desarrollo cliente-servidor e Internet
 persistencia, evolución de esquemas, bases de datos OO
 diseño de sistemas interactivos con GUIs modernas

PARTE 6  revisión de cómo estas ideas pueden ser implementadas o emuladas en varios lenguajes y entornos.
Incluye:
 en particular, los lenguajes OO principales: Simula, Smalltalk, Objective-C, C++, Ada 95 y Java
 evalúa cómo obtener beneficio de OO en lenguajes no-OO como: Fortran, Cobol, Pascal, C y Ada

PARTE 7  Haciendo las cosas bien.

Describe un entorno:
 que va más allá de estas soluciones
 proporcionando un set de herramientas integradas para soportar las ideas del libro.

Apéndice  como material de referencia complementario.

Muestra algunas importantes y reusables librerías de clases discutidas en el texto
 Proporcionando un modelo para el diseño de código reutilizable.

LA NOTACIÓN
En la programación el pensamiento y lenguaje están estrechamente conectados.
 quizás más que en otros sitios.

A medida que se progrese por este texto: Este libro trata acerca del método OO para:
 se desarrollará cuidadosamente una notación  la reutilización, análisis, diseño, implementación y mantenimiento de software
 para expresar conceptos OO  el lenguaje:
 en todos los niveles: modelado, análisis, diseño, implementación y mantenimiento. o es una consecuencia importante y natural del método
o no un objetivo en sí mismo.

El lenguaje:
 es sencillo
 incluye muy poco más que un soporte directo para el método.

Puede parecer que no es un lenguaje del todo Pero lo que realmente importa es:
 la notación se corresponde uno-a-uno con el método  la simplicidad de la notación
 existe una escasa decoración lingüística encima de los conceptos  y como mapea directamente los conceptos
 La mayoría de libros de software:
 dan por sentado el lenguaje
o ya sea un lenguaje de programación o una notación para análisis y diseño.

Aquí el enfoque es diferente: La mayoría de los capítulos de la parte C:

 involucra al lector en el diseño de la notación.  Incluyen una sección de <<discusión>>
 Por lo que no sólo debe explicar el lenguaje sino también: o Explicando los problemas encontrados durante el diseño de la notación
o Justificarlo o Y cómo fuero resueltos
o Y discutir las alternativas

Espero que las discusiones incluidas en este libro:

 Proporcionen información no sólo acerca de:
o el diseño del lenguaje
o la construcción de software

Ambas tareas están muy relacionadas.

ANÁLISIS, DISEÑO E IMPLEMENTACIÓN

Es siempre un riesgo usar una notación que se parezca extremadamente a un lenguaje de programación
 esto puede sugerir que sólo cubre la fase de implementación.

Esta impresión es difícil de corregir  por lo que a menudo se dice que: La tecnología de objetos:
 <<Existe una brecha de proporciones metafísicas (estudio de la realidad) entre:  Reduce considerablemente esta brecha
o El éter del  análisis-diseño o Enfatizando la unidad esencial del desarrollo de software
o Y el inframundo de  la implementación>> o Frente a las diferencias inevitables entre niveles de abstracción

Este enfoque perfecto de la construcción de software:

 Es una de las mayores contribuciones del método
 Siendo reflejado por el lenguaje de este libro:
o Válido para análisis
o Válido para diseño
o Válido para implementación.

Desafortunadamente la tendencia en la evolución de la materia es ir en contra de estos principios:

 Existen dos fenómenos igualmente lamentables:
o Lenguajes de implementación OOs  Aptos para el análisis y diseño (para razonamiento de alto-nivel, en general)
o Métodos de análisis y diseño OOs  que no cubren la implementación (haciéndose llamar <<leguajes-independientes>>)

Estos enfoques tratan de cancelar gran parte del beneficio potencial del enfoque OO.
 En cambio, en este libro:
o tanto el método como la notación están destinados a ser aplicables en todo el proceso de construcción de software
o una serie de capítulos cubren temas de diseño de alto-nivel
o otro está dedicado al análisis
o otros exploran:
 técnicas de implementación
 implicaciones del método en el rendimiento.

EL ENTORNO
La construcción de software se basa en una tetralogía:
 método  es el núcleo de este libro (método OO)
 lenguaje  anteriormente discutido
 herramientas y librerías  dan soporte según las necesidades.
o Un ejemplo es el entorno OO ISE
o Con su conjunto de herramientas y librerías asociadas.

El entorno es usado sólo como un ejemplo: También hay que tener presente (para el entorno):
 De lo que se puede hacer  La época en la que se está.
 para que los conceptos sean usados por desarrolladores de software.  Cambio en la materia
 Cambio en la industria
Existen muchos entornos OO disponibles:  …
 tanto para la notación de este libro
 como para otros métodos y notaciones OO  análisis, diseño e implementación. También se citan otros entornos OO y non-OO en el texto.