1. 3.2 Enfoque Orientado a Objetos.
Historia:
Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades
hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser
clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es
sorprendente que se proponga una visión orientada a objetos para la creación de Software
de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a
entenderlo y gobernarlo mejor.
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de
Software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han
necesitado casi veinte años para llegar a ser ampliamente usadas. Durante los años 90, la
ingeniería del Software orientada a objetos se convirtió en el paradigma de elección para
muchos productores de Software y para un creciente número de Sistemas de información y
profesionales de la ingeniería.
Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente de
Software) lleva a un desarrollo de Software más rápido y a programas de mejor calidad. El
Software orientado a objetos es más fácil de mantener debido a que su estructura es
inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben
hacer cambios. Los Sistemas orientados a objetos son más fáciles de adaptar y más
fácilmente escalables (pueden crearse grandes Sistemas ensamblando subSistemas
reutilizables).
Hacia mediados de los 80, los beneficios de la programación orientada a objetos
empezaron a obtener reconocimiento, y el diseño de objetos pareció ser un enfoque
sensato para la gente que deseaba utilizar el lenguaje de programación orientada a
objetos. Un enfoque orientado a objetos para programar ofrece muchos beneficios sobre
un enfoque estructurado.
El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen
ciertos comportamientos y atributos que determinan la manera en que interactúan y
funcionan. No se intenta proporcionar un orden para las acciones al momento del diseño
debido a que los objetos funcionan basados en la manera en que funcionan otros objetos.
La programación orientada a objetos ayuda a los desarrolladores a crear objetos que
reflejan escenarios del mundo real.
Las implementaciones orientadas a objetos ocultan datos, lo cual significa que muestran
únicamente los comportamientos a los usuarios y ocultan el código subyacente de un
objeto. Los comportamientos que el programador expone son únicamente aquellos
elementos que el usuario de un objeto puede afectar.

2. El enfoque orientado a objetos permite que los objetos estén autocontenidos. Los objetos
existen por sí mismos, con una funcionalidad para invocar comportamientos de otros
objetos. Al utilizar un enfoque orientado a objetos, los desarrolladores pueden crear
aplicaciones que reflejan objetos del mundo real, como rectángulos, elipses y triángulos,
además de dinero, números de partes y elementos en un inventario.
En un enfoque orientado a objetos, los objetos, por definición, son modulares en su
construcción. Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser
altamente reutilizables. Las aplicaciones orientadas a objetos se construyen sobre el
paradigma de los mensajes o de los eventos en donde los objetos envían mensajes a otros
objetos, como el Sistema operativo Microsoft® Windows®.
a. El paradigma orientado a objetos
Durante muchos años el término Orientado a Objetos (OO) se usó para referirse a un
enfoque de desarrollo de Software que usaba uno de los lenguajes orientados a objetos
(Ada 95, C++, Eiffel, Smalltalk, etc.). En el libro TheStructure of ScientificRevolutions, el
historiador Thomas K describía un paradigma como un conjunto de teorías, estándar y
métodos que juntos representan un medio de organización del conocimiento: es decir, un
medio de visualizar el mundo. 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 cómo se
estructura la información dentro de la computadora.
Jenkins y Glasgow observan que “la mayoría de los programadores trabajan en un
lenguaje y utilizan sólo un estilo de programación. Ellos programan en un paradigma
forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a métodos
alternativos de resolución de un problema, y por consiguiente tienen dificultad en ver la
ventaja de elegir un estilo más apropiado al problema a manejar”. Bobrow y Stefik
sugieren que existen cuatro clases de estilos de programación:
Orientados a procedimientos: Algoritmos.
Orientados a objetos: Clases y Objetos.
Orientados a lógica: Expresado en cálculo de predicados.
Orientados a reglas: Reglas if-then.
No existe ningún estilo de programación idóneo para todas las clases de programación. La
orientación a objetos se acopla a la simulación de situaciones del mundo real.
b. Orientación a Objetos
La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan
y modelan Software, que facilitan la construcción de Sistemas complejos a partir de
componentes.

3. El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y
herramientas con las cuales se modela y representa el mundo real tan fielmente como sea
posible. Estos conceptos y herramientas orientados a objetos son tecnologías que permiten
que los problemas del mundo real sean expresados de modo fácil y natural.
Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir
Sistemas de Software complejos a partir de unidades de Software modularizado y
reutilizable. Se necesita un nuevo enfoque para construir Software en la actualidad. Este
nuevo enfoque debe ser capaz de manipular tanto Sistemas grandes como pequeños y
debe crear Sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para
cumplir las necesidades del cambio.
La orientación a objetos trata de cubrir las necesidades de los usuarios finales, así como las
propias de los desarrolladores de productos Software. Estas tareas se realizan mediante la
modelización del mundo real. El soporte fundamental es el modelo objeto.
Un objeto es la instancia de una clase. Una clase es la representación abstracta de un
concepto en el mundo real, y proporciona la base a partir de la cual creamos instancias de
objetos específicos. Como ejemplo, puede crear una clase que defina a un cliente. Después
puede crear una nueva instancia de la clase cliente para tener un objeto utilizable de
Cliente. Para poder crear un objeto de la clase cliente, debe crear una nueva instancia
basada en esa clase.
Por ejemplo:
PrivateObjeto Customer?asClase Customer?
Objeto Customer = New Clase Customer()
Cada objeto es un elemento único de la clase en la que se basa. Si una clase es como un
molde, entonces un objeto es lo que se crea a partir del molde. La clase es la definición de
un elemento; el objeto es el elemento. El molde para una figura de cerámica en particular,
es como una clase; la figura es el objeto.
Todos los objetos están compuestos de tres cosas:
Interfaz:
La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que se declaran
como públicos en su alcance y que pueden invocar los programas escritos para usar
nuestro objeto.

4. Implementación:
Al código dentro de los métodos se le llama Implementación. Algunas veces también se le
llama comportamiento, ya que este código es el que efectivamente logra que el objeto
haga un trabajo útil. Es importante entender que las aplicaciones del cliente pueden
utilizar nuestro objeto aunque cambiemos la implementación, siempre que no cambiemos
la interfaz. Siempre que se mantengan sin cambio nuestro nombre de método, su lista de
parámetro y el tipo de datos de devolución, podremos cambiar la implementación
totalmente.
Estado:
El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma
clase. El estado se describe a través de las variables del Miembro o de la Instancia. Las
variables del miembro son aquellas declaradas, de tal manera que están disponibles para
todo el código dentro de la clase. Por lo general, las variables del miembro son Privadas en
su alcance. Algunas veces, se les conoce como variables de la instancia o como atributos.
Observe que las propiedades no son variables del Miembro, ya que son un tipo de método
que funciona para recuperar y establecer valores.
¿Qué es una clase?
Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase
define las características de un objeto, incluyendo las propiedades que definen los tipos de
datos que ese objeto puede contener y los métodos que describen el comportamiento del
objeto. Estas características determinan la manera en que otros objetos pueden acceder y
trabajar con los datos que se incluyen en el objeto.
Para definir una clase, se coloca la palabra clave Class antes del nombre de su clase, y
después se insertan los miembros de la clase (datos y métodos) entre la definición del
nombre de la clase y la instrucción EndClass. Si incluye los métodos, entonces el código de
cada método también se debe incluir entre la declaración del método y el final del mismo.
Por ejemplo, si desea construir objetos que representen perros, puede definir una clase
Perro con ciertos comportamientos, como caminar, ladrar y comer, y propiedades
específicas, como altura, peso y color. Una vez que haya definido la clase Perro, puede
crear objetos con base en esa clase. Es importante observar que todos los objetos Perro
creados con base en la clase perro compartirán los mismos comportamientos, pero
tendrán sus propios valores específicos para el mismo conjunto de propiedades.

5. El siguiente ejemplo representa la definición de la clase Perro. Tome en consideración que
ésta no es una sintaxis estricta de VB.NET; simplemente es un ejemplo de la definición de
clase.
PublicClass Perro
Dim Altura As Decimal
Dim Peso As Decimal
Dim Color As String
Sub Caminar(ByVal Pasos As Integer)
End Sub
Sub Ladrar()
End Sub
Sub Comer()
End Sub
End Class
#]
Vamos con otro ejemplo. El siguiente ejemplo define una nueva clase, Persona, con dos
partes de información relevante asociadas: el nombre de la persona, su fecha de
nacimiento y un Método que calcula la edad de la persona. A pesar de que la clase Persona
se define en el ejemplo, no existe aún el objeto Persona. Deberánsercreados.
[@
Public Class Persona
Private mstrNombre As String
Private mdtFechaNacimiento As Date
Public Function Edad() As Integer
Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now())
EndFunction
EndClass
Una clase es un tipo definido por el usuario en contraposición a un tipo proporcionado por
el Sistema. Al definir una clase, en realidad crea un nuevo tipo en su aplicación.
Ahora que ya sabéis todo esto, vamos con os elementos (propiedades) más importantes de
este modelo. Estas son:
Abstracción.
Encapsulamiento.

6. Modularidad.
Jerarquía.
Polimorfismo.
Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es
orientado a objetos.
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 la propiedad que permite
representar las características esenciales de un objeto, sin preocuparse de las restantes
características (no esenciales). Abstracción es la técnica de quitarle a una idea o a un
objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y
mínima. Una buena abstracción elimina todos los detalles poco importantes y le permite
enfocarse y concentrarse en los detalles importantes.
Una abstracción se centra en la vista externa de un objeto, de 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, una pluma estilográfica es un objeto que tiene un estado (llena de tinta o
vacía) y sobre la cual se pueden realizar algunas operaciones (escribir, poner o quitar la
tapa, llenar de tinta si está vacía, etc.).
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.
La abstracción es un principio de Software importante. Una clase bien diseñada expone un
conjunto mínimo de métodos cuidadosamente considerados que proporcionan el
comportamiento esencial de una clase en una forma fácil de usar. Crear buenas
abstracciones de Software no es fácil. Encontrar buenas abstracciones generalmente
requiere de un entendimiento muy claro del problema y de su contexto, gran claridad de
pensamiento y amplia experiencia.
Existe un principio muy importante relacionado con la abstracción, y esta es, la
Dependencia mínima. Las mejores abstracciones de Software hacen que las cosas
complejas sean simples. Logran esto al ocultar por completo los aspectos no esenciales de
una clase. Estos aspectos no esenciales, una vez que han sido debidamente ocultados, no

7. se pueden ver, ni usar, ni depender de ellos. Este principio de dependencia mínima es lo
que hace que la abstracción sea tan importante. El cambio es normal en el desarrollo de
Software. Lo mejor que puede hacer es minimizar el impacto de un cambio cuando éste
sucede. Y cuanto menos dependa de algo, menos se verá afectado cuando cambie.
Los lenguajes orientados a objetos proporcionan la Encapsulación. La encapsulación se
puede utilizar para aplicar el concepto de Abstracción.
Encapsulamiento
El Encapsulamiento o encapsulación 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 secretos 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. La interfaz de una clase captura sólo su vista externa y la
implementación contiene la representación de la abstracción, así como los mecanismos
que realizan el comportamiento adecuado.
Encapsulación es la capacidad de contener y controlar el acceso a un grupo de elementos
asociados. Las clases proporcionan una de las formas más comunes para encapsular
elementos. En el siguiente ejemplo, la clase Bank Account? Encapsula los métodos, campos
y propiedades que se describen en una cuenta bancaria. Sin una encapsulación, usted
necesitaría declarar procedimientos y variables por separado para almacenar y
administrar información para la cuenta bancaria, y sería difícil trabajar con más de una
cuenta bancaria a la vez. La encapsulación le permite utilizar los datos y procedimientos en
la clase Bank Account como una unidad. Usted puede trabajar con varias cuentas
bancarias al mismo tiempo sin confusión, debido a que cada cuenta está representada por
una instancia única de la clase.
La encapsulación también le permite controlar la forma en que se utilizan los datos y los
procedimientos. Puede utilizar modificadores de acceso, como Private o Protected, para
evitar que los procedimientos externos ejecuten métodos de clase o lean y modifiquen
datos en propiedades y campos. Usted debe declarar los detalles internos de una clase
como Private para evitar que sean utilizados fuera de su clase; a esta técnica se le llama
ocultamiento de datos. En la clase Bank Account, la información del cliente, como el saldo
de la cuenta, se protege de esta forma. Una de las reglas básicas de la encapsulación es
que los datos de la clase sólo se pueden modificar o recuperar a través de los
procedimientos o métodos Property. Ocultar los detalles de implementación de sus clases
evita que se usen de maneras no deseadas, y le permite modificar esos elementos

8. posteriormente sin riesgo de tener problemas de compatibilidad. Por ejemplo, versiones
posteriores de la clase Bank Account enlistadas más adelante, podrían cambiar el tipo de
datos del campo Account Balance?, sin peligro de dañar la aplicación que depende de que
este campo tenga un tipo de dato específico.
Class BankAccount
Private AccountNumberAs String
Private AccountBalanceAs Decimal
Private HoldOnAccountAs Boolean = False
Public Sub PostInterest()
' Add code to calculate the interest for this account.
End Sub
ReadOnly Property Balance() As Decimal
Get
Return AccountBalance 'Returns the available balance.
End Get
End Property
End Class
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 sí 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.
La Modularidad es la propiedad de un Sistema que permite su descomposición en un
conjunto de módulos cohesivos y débilmente acoplados. Por supuesto no todos los
módulos son iguales: tomar un programa monolítico y separarlo de forma aleatoria en
archivos no es óptimo. Se debe tener en cuenta los conceptos asociados de dependencia,
acoplamiento, cohesión, interfaz, encapsulación y abstracción. Una vez identificado lo que
es un buen módulo, se puede contemplar la reutilización de un buen módulo como
componente.
El Módulo A depende del Módulo B si cualquier cambio en el Módulo B implica que el
Módulo A también tenga que ser modificado. A veces se dice que el Módulo A es un cliente
del Módulo B, o que el Módulo B actúa como servidor del Módulo A. En general, es normal
que un mismo módulo sea tanto cliente como servidor. Esto significa, que depende de
algunos módulos, mientras que otros módulos dependen de él. Incluso es posible que un
par de módulos se tengan uno al otro de cliente; sin embargo, éste es un ejemplo de

9. dependencia circular, que debe evitarse cuando sea posible debido a que impide la
reutilización.
La dependencia a veces se conoce como acoplamiento. Un Sistema con muchas
dependencias tiene fuerte acoplamiento. Los buenos Sistemas tienen débil acoplamiento,
porque en ese caso los cambios en una parte del Sistema son menos probables de
propagarse a través del Sistema.
Los módulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan
una abstracción de algún elemento conocido de manera intuitiva que puede, no obstante,
ser difícil de implementar. Este tipo de módulos se dice que tienen una fuerte cohesión. El
módulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador
del cliente está protegido de la información irrelevante relativa a cómo el módulo hace lo
que hace.
Resumiendo: Abstracción es cuando un cliente de un módulo no necesita saber más de lo
que hay en la interfaz. Encapsulación es cuando un cliente de un módulo no es capaz de
saber más de lo que hay en la interfaz.
Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción (tiene fuerte
cohesión y débil acoplamiento) puede ser factible reutilizarlo en Sistemas posteriores, o
sustituirlo en el Sistema existente.
Jerarquía
La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos
jerarquías más importantes de un Sistema complejo son: estructura de clases (jerarquía
“es-un” (is-a): generalización/especialización) y 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 más 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.
Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es
el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad

10. tome muchas formas. En términos prácticos, el polimorfismo permite referirse 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.
Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación
comer es una operación fundamental en la vida de los mamíferos, de modo que cada tipo
de mamífero debe poder realizar la operación o función comer. Por otra parte, una cabra o
una vaca que pastan en un campo, un niño que se come un caramelo y un león que devora
a otro animal, son diferentes formas que utilizan diferentes mamíferos para realizar la
misma función (comer).
El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es
decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la
propiedad de derivación de clases o herencia.
El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto
sólo se puede producir en lenguajes de programación orientados a objetos. Los lenguajes
no orientados a objetos soportan ligadura temprana o anterior (también llamada
estática), esto significa que el compilador genera una llamada a un nombre específico de
función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se
ha de ejecutar. En POO, el programa no puede determinar la dirección del código hasta el
momento de la ejecución. Cuando se envía un mensaje a un objeto, el código que se llama
no se determina hasta el momento de la ejecución. El compilador asegura que la función
existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no
conoce el código exacto a ejecutar.
y ¿Cuáles son los beneficios? , Buena pregunta eh …!!!
En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a
que:
Los programas son fáciles de diseñar debido a que los objetos reflejan elementos
del mundo real.
Las aplicaciones son más sencillas para los usuarios debido a que los datos
innecesarios están ocultos.
Los objetos son unidades autocontenidas.
La productividad se incrementa debido a que puede reutilizar el código.
Los Sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de
negocios.
Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
Simplifica los datos complejos.
Reduce la complejidad de la transacción.
Confiabilidad.
Robustez.

11. Capacidad de ampliación.
Otras propiedades:
El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas sino que es
conveniente que soporte, además, estas otras propiedades:
Concurrencia (multitarea): el lenguaje soporta la creación de procesos paralelos
independientes del Sistema operativo.
Esta propiedad simplificará la transportabilidad de un Sistema de tiempo real de
una plataforma a otra.
Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de
poder permanecer después de la ejecución del programa
Genericidad: las clases parametrizadas (mediante plantillas o unidades genéricas)
sirven para soportar un alto grado de reutilización.
Estos elementos genéricos se diseñan con parámetros formales, que se
instanciarán con parámetros reales, para crear instancias de módulos que se
compilan y enlazan, y ejecutan posteriormente.
Manejo de Excepciones: se deben poder detectar, informar y manejar condiciones
excepcionales utilizando construcciones del lenguaje. Esta propiedad añadida al
soporte de tolerancia a fallos del Software permitirá una estrategia de diseño
eficiente.
Taxonomía de lenguajes orientados a objetos
Una taxonomía de lenguajes de programación con propiedades de orientación a objetos
fue creada por Wegner. La clasificación incluye los siguientes grupos:
Basado en objetos: Un lenguaje de programación es basado en objetos si su
sintaxis y semántica soportan la creación de objetos que tienen las propiedades
descritas en el punto anterior. Por ejemplo: Ada-83, Clipper 5.2, Visual Basic
4/5/6.
Basado en clases: Si un lenguaje de programación es basado en objetos y
soporta además la creación de clases, se considera basado en clases. Por
ejemplo: Clu.
Orientación a objetos: Un lenguaje de programación orientado a objetos es un
lenguaje basado en clases que soporta también herencia. Por ejemplo: Visual
Basic .NET, C# .NET, C++, Java, Delphi, Eiffel, Simula.
Conceptos de orientación a objetos:
Coad y Yourdon definen el término Orientación a Objetos de la siguiente forma:
Orientación a Objetos = objetos + clasificación + herencia + comunicación

12. Clases y Objetos:
Un modelo Orientado a Objetos de Software de computadora debe exhibir abstracciones
de datos y procedimientos que conducen a una Modularidad eficaz. Una clase es un
concepto Orientado a Objetos que encapsula las abstracciones de datos y procedimientos
que se requieren para describir el contenido y comportamiento de alguna entidad del
mundo real.
Las abstracciones de datos (atributos) que describen la clase están encerradas por una
“muralla” de abstracciones procedimentales (llamadas operaciones, métodos o servicios)
capaces de manipular los datos de alguna manera. La única forma de alcanzar los
atributos (y operar sobre ellos) es ir a través de alguno de los métodos que forman la
muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que
manipula los datos (los métodos que componen la muralla). Esto posibilita la ocultación de
información y reduce el impacto de efectos colaterales asociados a cambios.
Nota: Un objeto encapsula datos (atributos) y los métodos (operaciones, métodos o
servicios) que manipulan esos datos.
Atributos:
Los atributos están asociados a clases y objetos, y describen la clase o el objeto de alguna
manera. Las entidades de la vida real están a menudo descritas con palabras que indican
características estables. La mayoría de los objetos físicos tienen características tales como
forma, peso, color y tipo de material. Las personas tienen características como fecha de
nacimiento, padres, nombre y color de los ojos. Una característica puede verse como una
relación binaria entre una clase y cierto dominio.
La “relación” binaria implica que un atributo puede tomar un valor definido por un
dominio enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto
de valores específicos. Por ejemplo, supongamos que una clase Coche tiene un atributo
color. El dominio de valores de color es blanco, negro, plata, gris, azul, rojo, amarillo,
verde.
Las características (valores del dominio) pueden aumentarse asignando un valor por
defecto (característica) a un atributo. Por ejemplo, el atributo color tiene el valor por
defecto negro.
Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser único.

13. Operaciones, métodos y servicios:
Un objeto encapsula datos (representados como una colección de atributos) y los
algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, métodos
o servicios y pueden ser vistos como módulos en un sentido convencional.
Cada uno de los métodos encapsulados por un objeto proporciona una representación de
uno de los comportamientos del objeto. Por ejemplo, el método Determinar Color?, para el
objeto Coche extraerá el color almacenado en el atributo color. La consecuencia de la
existencia de ese método es que la clase coche ha sido diseñada para recibir un estímulo
(mensaje) que requiere el color de una instancia particular de una clase. Cada vez que un
objeto recibe un estímulo, éste inicia un cierto comportamiento, que puede ser tan simple
como determinar el color del coche o tan complejo como la iniciación de una cadena de
estímulos que se pasan entre una variedad e objetos diferentes.
Nota: Siempre que un objeto es estimulado por un mensaje, inicia algún comportamiento
ejecutando un método.
Mensajes:
Los mensajes son el medio a través del cual interactúan los objetos. Un mensaje estimula
la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se
realiza cuando se ejecuta un método.
Una operación dentro de un objeto emisor genera un mensaje de la forma:
destino.operación (parámetros)
Donde destino define al objeto receptor el cual es estimulado por el mensaje, operación se
refiere al método que recibe el mensaje y parámetros proporciona información requerida
para el éxito de la operación.
Los mensajes proporcionan una visión interna del comportamiento de objetos individuales,
y del Sistema Orientado a Objetos como un todo.
Nota: El paso de mensajes mantiene comunicado un Sistema orientado a objetos.

14. 3.2.1 Análisis
El modelo de análisis se extiende luego para describir la manera en que interactúan los
actores y el Sistema para manipular el modelo del dominio de aplicación. Los
desarrolladores usan el modelo de análisis, junto con los requerimientos no funcionales,
para preparar la arquitectura del Sistema que se desarrolla durante el diseño de alto nivel.
Las actividades del análisis: la identificación de objetos, su comportamiento, sus
relaciones, su clasificación y su organización.
El modelo de análisis está compuesto por tres modelos individuales: el modelo funcional,
representado por casos de uso y escenarios, el modelo de objetos de análisis, representado
por diagramas de clase y objeto, y el modelo dinámico, representado por gráficas de
estado y diagramas de secuencia.
Conceptos de análisis:
Particularmente describimos:
Objetos de entidad, frontera y control: Los objetos de entidad representan la información
persistente rastreada por el Sistema. Los objetos de frontera representan la interacción
entre los actores y el Sistema. Los objetos de control representan las tareas realizadas por
el usuario y soportadas por el Sistema.
Multiplicidad de asociación: el extremo de una asociación puede etiquetarse como un
conjunto de enteros llamados multiplicidad. La multiplicidad indica la cantidad de vínculos
que pueden originarse legítimamente desde una instancia de la clase conectada al
extremo de la asociación.
En UML, un extremo de una asociación puede tener como multiplicidad un conjunto de
enteros arbitrarios. Sin embargo, en la práctica, la mayoría de las asociaciones que
encontramos pertenece a alguno de los siguientes tres tipos:
Una asociación de uno a uno tiene una multiplicidad de 1 a cada extremo. Una asociación
de uno a uno entre dos clases significa que existe solamente un vínculo entre instancias de
cada clase.
Una asociación de uno a muchos tiene una multiplicidad de 1 en un extremo y 0…n
Una asociación de uno a muchos entre dos clases (por ejemplo, Persona y Automóvil)
indica composición
Una asociación de muchos a muchos tiene una multiplicidad de 0. . n o 1. . n en ambos
extremos. Una asociación de muchos a muchos entre dos clases indica que puede existir

15. una cantidad arbitraria de vínculos entre instancias de las dos clases. Este es el tipo más
complejo de asociación.
Asociaciones calificadas:
La calificación es una técnica para la reducción de la multiplicidad usando claves. Las
asociaciones que tienen multiplicidad de 0…1 o 1 son más fáciles de comprender que las
asociaciones con multiplicidad de 0…n o 1…n. Con frecuencia, en el caso de una asociación
de uno a muchos, los objetos del lado de “muchos” pueden distinguirse entre ellos usando
un nombre.
Generalización:
La generalización nos permite organizar conceptos en jerarquías.
El análisis para el enfoque orientado a objetos; En lugar de considerar el SW desde una
perspectiva básica de entrada-proceso-salida como los métodos estructurados se basa en
modelar el Sistema mediante los objetos que forman parte de él y las relaciones estáticas
(herencia y composición ) o dinámicas(uso entre otros objetos ). El análisis identifica las
clases y objetos relativamente en el dominio del problema, el diseño proporciona detalles
sobre la arquitectura, las interfaces y los componentes la implementación transforma el
diseño en código y la pruebas checan tanto la arquitectura como la interfaz y los
componentes.
3.2.2 Diseño
Durante el diseño de objetos cerramos el hueco entre los objetos de aplicación y los
componentes hechos, identificando objetos de solución adicionales y refinando los objetos
existentes.
El diseño de objetos incluye:
• Especificación de servicios, durante la cual describimos con precisión cada interfaz de
clase.
• Selección de componentes, durante la cual identificamos componentes hechos y objetos
de solución adicionales.
• Reestructuración del modelo de objetos, durante la cual transformamos el modelo de
diseño de objetos para mejorar su comprensibilidad y extensibilidad.

16. • Optimización del modelo de objetos, durante la cual transformamos el modelo de diseño
de objetos para tratar criterios de desempeño, como el tiempo de respuesta o la utilización
de la memoria.
El diseño de objetos, al igual que el diseño del Sistema, no es algorítmico.
El diseño de objetos a veces es difícil distinguir claramente el análisis y el diseño Orientado
a Objetos (OO).
Esencialmente AOO es una actividad de clasificación, se analiza un problema con el fin de
determinar clases de objetos que sea aplicables en el desarrollo de la solución.
El de DOO permite al ing. de SW los objetos que se derivan de cada clase de las
interrelaciones entre ellos y proporciona una notificación que refleja las relaciones entre
los objetos.