proposicional a la publi

1. DISEÑO ORIENTADO
A OBJETOS
ALEJANDRA CABRERA
JUAN C. LIBREROS
JORGE A. RAMIREZ
PABLO ALTAMAR
ANDRES F. OÑATE
FABIO MARQUEZ

2. INTRODUCCION
El diseño orientado a objetos mas
conocido como DOO, transforma el
modelo de análisis creado, usando
análisis orientado a objetos.
un modelo de diseño sirve como
anteproyecto para la construcción de
un software. El trabajo de diseñador
de software puede ser un poco
complicado.

3. Gamma y sus colegas:
“El diseño de software orientado a objetos
es difícil, y el diseño de software reusable
orientado a objetos es aun más difícil”
“ Se deben identificar los objetos
pertinentes, clasificarlos dentro de las
clases en el grado correcto, definir
interfaces de clases y jerarquías de
herencia y establecer relaciones clave
entre ellos. “
“El diseño debe ser específico al problema
que se tiene entre manos, pero
suficientemente general para adaptarse a
problemas y requerimientos futuros”

4. Gamma y sus colegas:
“Además se deberá evitar el
rediseño, o por lo menos
minimizarlo. Los diseñadores
experimentados en OO dicen que un
diseño reusable y flexible es difícil, si
no imposible de obtener «bien», la
primera vez. Antes de que un diseño
sea terminado, usualmente tratan de
reutilizarlo varias veces,
modificándolo cada vez.”

5. La mayoría de los componentes de
los sistemas, están organizados en
subsistemas.
Los datos y operaciones que
manipulan los datos se encapsulan
en objetos.
El DOO debe describir la organización
especifica de los datos, atributo y
detalles de cada operación.

6. ¿Qué es?
El DOO requiere la definición de:
una arquitectura multicapa.
la especificación de subsistemas que
realizan funciones y proveen soporte
de infraestructura.
Una descripción de objetos (clases).
Una descripción de los mecanismos
de comunicación.

7. ¿Quién lo hace?
El DOO lo realiza un ingeniero del
software.

8. ¿Por que es importante?
Es importante porque, establece un
anteproyecto de diseño, el cual hace
que se maximice la reutilización de
este.

9. ¿Cuales son los pasos?
Se divide en dos:
Diseño de sistema: crea un arquitectura del
producto definiendo una serie de capas, que
cumplen funciones, e identifica las clases
encapsuladas.
Diseño de objetos: se centra en los detalles
internos de cada clase, definición de
atributos. Operaciones y detalles de los
mensajes.

10. ¿Cuál es el producto obtenido?
No es mas, que la descripción de la
interfaz de usuario.
Desarrollo de Componentes de
gestión.

11. DISEÑO PARA SISTEMAS
ORIENTADOS A OBJETOS
Se divide en 4 capas:
– La capa subsistema: contiene una
representación de cada uno de los
subsistemas, para conseguir sus requisitos
definidos por el cliente.
– La capa de clases y objetos: contiene la
jerarquía de clases, que permite al sistema ser
creado usando generalizaciones y con
especificaciones mas acertadas.

12. – la capa de mensaje: contiene detalles
de diseño, que permite a cada objeto
comunicarse son sus colaboradores.
– La capa de responsabilidades:
contiene estructuras de datos y diseños
algorítmicos, para todos los atributos y
operaciones de cada objeto.

14. La capa fundamental se centra en el
diseño de los objetos del dominio.
Estos juegan un papel clave, en la
construccion de la infraestructura del
sistema OO aportando soporte para
las actividades, admon de tareas y
gestion de datos.

15. ENFOQUE CONVENCIONAL VS
OO
Los dos aplican el diseño de datos cuando
los atributos son representados, el diseño
de interfaz cuando se desarrolla un
modelo de mensajeria y diseño a nivel de
componentes. (para operaciones de
diseño).
La arquitectura de diseño de OO tiene que
ver mas con la colaboracion entre objetos
que con el control de flujos de
componentes.

16. Fichman y Kemerer:
1. representación de la jerarquía de módulos.
2. especificación de las definiciones de datos.
3. especificación de la lógica procedimental.
4. indicación de secuencias de proceso final-a-final
5. representación de estados y transiciones de los
6. definición de clases y jerarquías.
7. asignación de operaciones a las clases.
8. definición detallada de operaciones.
9. especificación de conexiones de mensajes.
10. identificación de servicios exclusivos.

17. ASPECTOS DEL DISEÑO
Bertrand: sugiere 5 criterios para juzgar
la capacidad de métodos de diseño para
conseguir modularidad y los relaciona al
diseño orientado a objetos:
1. Descomponibilidad
2. Componibilidad
3. Comprensibilidad
4. Continuidad
5. Protección

18. Meyer:
sugiere 5 principios básicos de
diseño, que pueden ser deducidos
para arquitecturas modulares:
1. unidades lingüísticas Modulares
2. pocas interfaces
3. pequeñas interfaces (acoplamiento
débil)
4. interfaces explícitas
5. ocultación de información

19. el lenguaje de programación que se usará
debe ser capaz de definir directamente la
modularidad.
Los módulos se definen como unidades
lingüísticas modulares, cuando
«corresponden a unidades sintácticas en
el lenguaje usado»
Para lograr el bajo acoplamiento, el
número de interfaces entre módulos debe
minimizarse y la cantidad de información
que se mueve a través de la interfaz
también debe ser minimizada

20. Siempre que los componentes se comunican,
deben hacerlo de manera obvia y directa.
Por ejemplo:
si el componente X y el componente Y se
comunican mediante el área de datos global (a lo
que se llama acoplamiento) violan el principio de
interfaces explícitas porque la comunicación entre
componentes no es obvia a un observador
externo. Finalmente, se logra el principio de
ocultamiento de información, cuando toda
información acerca de un componente se oculta
al acceso externo, a menos que esa información
sea específicamente definida como pública.

21. EL PANORAMA DE DOO
El método de Booch: abarca un
«proceso de micro desarrollo» y un
<<proceso de macro desarrollo».
– El macro desarrollo engloba una actividad de
planificación arquitectónica, que agrupa
objetos similares en particiones arquitectónicas
separadas, capas de objetos por nivel de
abstracción, identifica situaciones relevantes,
crea un prototipo de diseño y valida el
prototipo aplicándolo a situaciones de uso.

22. – El micro desarrollo define un conjunto
de «reglas» que regulan el uso de
operaciones y atributos y las políticas
del dominio específico para la
administración de la memoria, manejo
de errores y otras funciones.

23. El método de Rumbaugh: La técnica de
modelado de objetos engloba una actividad de
diseño que conduce a dos diferentes niveles de
abstracción. El diseño de sistema se centra en el
esquema de los componentes que se necesitan
para construir un sistema o producto completo.
El modelo de análisis se divide en subsistemas,
los cuales se asignan a procesadores y tareas. Se
define una estrategia para implementar la
administración de datos, y se identifican los
recursos y mecanismos de control requeridos
para accesarlos.

24. El método de Jacobson. El diseño para ISOO
(Ingeniería del software orientada a objetos) es
una versión simplificada del método propietario
Objectory, también desarrollado por Jacobson.
El modelo de diseño enfatiza la planificación para
el modelo de análisis ISOO. El modelo idealizado
de análisis se adapta para acoplarse al ambiente
del mundo real. Después los objetos de diseño
primarios, llamados bloques’, son creados y
catalogados como bloques de interfaz, bloques de
entidades y bloques de control. La comunicación
entre bloques durante la ejecución se define y los
bloques se organizan en subsistemas.

25. El método de Coad y Yourdon. se
desarrolló estudiando «cómo es que los
diseñadores orientados a objetos
efectivos» hacen su trabajo. La
aproximación de diseño dirige no sólo la
aplicación, sino también la infraestructura
de la aplicación, y se enfoca en la
representación de cuatro componentes
mayores de sistemas:
– la componente de dominio del problema
– la componente de interacción humana
– la componente de administración de tareas
– la de administración de datos.

26. El método de Wirfs-Brock: Wirfs-Brock,
Wilkerson y Weiner definen un conjunto de tareas
técnicas, en la cual el análisis conduce sin duda al
diseño. Los protocolos para cada clase se
construyen refinando contratos entre objetos.
Cada operación (responsabilidad) y protocolo
(diseño de interfaz) se diseña hasta un nivel de
detalle que guiará la implementación. Se
desarrollan las especificaciones para cada clase
(definir responsabilidades privadas y detalles de
operaciones) y cada subsistema (identificar las
clases encapsuladas y la interacción entre
subsistemas).

27. Para llevar a cabo un diseño orientado
a objetos, un ingeniero de software
debe ejecutar las siguientes etapas
generales:
1.Describir cada subsistema y asignar a
procesadores y tareas.
2.Elegir una estrategia para implementar la
administración de datos, soporte de
interfaz y administración de tareas.

28. 3. Diseñar un mecanismo de control,
para el sistema apropiado.
4. Diseñar objetos creando una
representación procedura para cada
operación, y estructuras de datos
para los atributos de clase.

29. 5.Diseñar mensajes, usando la
colaboración entre objetos y
relaciones.
6. Crear el modelo de mensajería.
7.Revisar el modelo de diseño y
renovarlo cada vez que se requiera.

30. ALEJANDRA CABRERA….

31. PROCESO DE DISEÑO DE
SISTEMAS
El diseño de sistema desarrolla el
detalle arquitectónico requerido
para construir un sistema o
producto. El proceso de diseño
del sistema tiene algunas
actividades.

32. ACTIVIDADES
✓ Partición del modelo de análisis en
subsistemas.
✓ Identificar la concurrencia dictada por el
problema.
✓ Asignar subsistemas a procesadores y tareas.
✓ Desarrollar un diseño para la interfaz de
usuario.
✓ Elegir una estrategia básica para implementar
la admón o gestión de datos.

33. ✓ Identificar recursos globales y los
mecanismos de control requeridos para su
acceso.
✓ Diseñar un mecanismo de control
apropiado para el sistema, incluyendo
administración de tareas.
✓ Considerar como deben manejarse las
condiciones de frontera.
ACTIVIDADES

34. Particionar el Modelo de
Análisis
Uno de los principios fundamentales del
Análisis es hacer particiones. El diseño de
Sistemas OO particiona el modelo de
Análisis ,
Congruentes
para definir colecciones
de clases, relaciones y
Comportamiento. Estos elementos de diseño
Se definen como subsistemas.

35. Particionar el Modelo de
Análisis
Todos los elementos de un subsistema
comparten alguna propiedad en común y se
integran para completar la misma función,
deben administrar la misma clase de
recursos. Los subsistemas se caracterizan
por sus responsabilidades, es decir un
Subsistema puede identificarse por sus
servicios.

36. Particionar el Modelo de
Análisis
se diseñan los subsistemas , seCuando
Deben seguir algunos criterios de diseño:
✓ El subsistema debe tener una interfaz bien
definida, a través de la cual se reduzcan
todas las comunicaciones con el resto del
sistema.
✓ El número de subsistemas debe ser bajo.
ser particionado
ayudar a reducir
✓ Un subsistema puede
Internamente para
la complejidad.

37. Particionar el Modelo de
Análisis
Cuando dos subsistemas se comunican entre
si, pueden establecer un enlace cliente -
servidor o un enlace punto-punto.
en un enlace cliente-servidor, cada uno de
los subsistemas asume uno de los papeles.
el servicio fluye del servidor al cliente en
una Sola dirección. En un enlace punto-
punto los Servicios pueden fluir en cualquier
dirección.

38. Particionar el Modelo de
Análisis
Cuando un sistema es particionado en
subsistemas, se lleva a cabo otra actividad
de diseño llamada estratificación de capaz,
contiene uno o más subsistemas.
Ejemplo: una arquitectura de 4 capas debe
Incluir lo siguiente:
✓ Una capa de presentación, que es el
subsistema asociado con la interfaz de U.

39. Particionar el Modelo de
Análisis
✓ Una capa de aplicación, que es el
subsistema que lleva a cabo procesos
asociados con la aplicación.
✓ Una capa de formato de datos, son los
subsistemas que preparan los datos para ser
procesados.
✓ una capa de base de datos, es el
subsistema asociado con la admón de los datos.

40. Particionar el Modelo de
Análisis
Buschman y sus colegas sugieren el sgte
Enfoque para estratificación por capaz:
1. Establecer los criterios de estratificación por
capaz, esto significa como se agruparan
los subsistemas.
2. Determinar el número de capaz ya que
muchas de ellas pueden complicar
innecesariamente el diseño.
3. Nombrar las capaz y asignar subsistemas

41. Particionar el Modelo de
Análisis
4. Diseñar interfaces para cada capa.
5. Definir el modelo de mensajeria
para la comunicación entre capaz.
6. Revisar el diseño de capaz.

42. Asignación de
Concurrencia y
Subsistemas
El aspecto dinámico delmodelo objeto –
Comportamiento provee una indicación de
Concurrencia entre clases. Si la clases o
Subsistemas no se activan al mismo tiempo,
No hay necesidad para el procesamiento
Concurrente, esto significa que las clases
Pueden ser implementadas en el mismo
Procesador de hardware.

43. Asignación de
Concurrencia y
Subsistemas
Cuando los subsistemas son concurrentes,
Existen dos opciones de alojamiento:
✓ Alojar cada subsistema en procesadores
independientes.
✓ O alojar los subsistemas en el mismo
procesador y proporcionar soporte de
concurrencia sobre las características del
sistema operativo.

44. Asignación de
Concurrencia y
Subsistemas
Las tareas concurrentes se definen
examinado el diagrama de estado para cada
objeto. Para determinar cual de las opciones
de asignación de procesadores es apropiada
El diseñador debe considerar los requisitos
De desempeño, costos y el encabezado
Impuesto por la comunicación entre
Procesadores.

45. Componentes de Admón
de Tareas
Coad y Yourdon, sugirieron la siguiente
Estrategia, para el diseño de objetos que
Manipulan tareas concurrentes:
✓ Se determinan las características de la tarea.
✓ Se define un coordinador de tarea y objetos
asociados.
✓ Se integran el coordinador y las otras tareas.

46. Componentes de admón. de
Tareas
Se debe determinar la prioridad y criticidad
de la tarea. Las tareas de alta prioridad
deben tener acceso inmediato a los recursos
del sistema, las tareas de alta criticidad
deben continuar operando aun cuando la
disponibilidad de un recurso es reducida.

47. Componentes de admón. de
Tareas
Una vez que las características de la tarea
Se han determinado se definen los atributos
Y operaciones del objeto requerido, para
Alcanzar coordinación y comunicación con
Otras tareas.

48. Componentes de admón. de
Tareas
Plantilla básica de una tarea
Nombre de la tarea: el nombre del objeto.
descripción: un relato que describe el
Propósito del objeto.
Prioridad: de la tarea (alta, media, baja)
Servicios: lista de operaciones que son
Responsabilidad del objeto.
Coordinados por: la manera como se invoca
El comportamiento del objeto.
Comunicados: datos de E/S de la tarea.

49. JORGE A RAMIREZ

50. Proceso de Diseño de Objetos
En este proceso vamos a desarrollar
el diseño detallado de los objetos y
sus interacciones con el sistema. En
este de desarrollan particularmente
los atributos, como funcionan y como
los objetos se enlazan con los
demás.
En esta fase las estructuras de datos
y los algoritmos

51. Descripción de Objetos.
La descripción del diseño puede
tomar una o dos formas:
Descripción del protocolo: Descripción de implementación:
Se diseña la interfaz del
objeto, definiendo mensajes
que puede recibir y las
operaciones que puede
realizar al momento de
recibir un mensaje.
Muestra los detalles de
implementación para cada
operación implicada en el
mensaje pasado a un objeto
Esto incluye la parte
privada, detalles internos de
un objeto.

52. Es un conjunto de mensajes y un
comentario, para cada uno de los
mensajes.
Para sistemas demasiado grandes los
mensajes deben de ser
categorizados siempre y cuando
cumplan la misma función.
Descripción de Protocolo.

53. Descripción de Implementación.
En este proceso suministramos
detalles internos para la
implementación de los objetos.
El diseñador debre crear los detalles
internos del objeto, pero otro
diseñador no lo necesita por ende
solo utiliza la descripción de
protocolo.

54. Requiere la siguiente información:
Descripción de Implementación.
Primero TerceroSegundo
Especificación
del nombre
del objeto y
referencia de
la clase
Especificación
de las
estructuras de
datos y los
tipos de
datos.
Descripción de
procedimiento
de cada
operación que
posea el
objeto.

55. El diseño de algoritmos y estructuras
de datos deben ser diseñados
utilizando un enfoque ya sea el de la
ingeniería de software convencional
o la OO. En este caso trataremos el
enfoque orientado a objetos para
definir dichas estructuras y
algoritmos.
Diseño de Algoritmos y ED

56. Para cada operación debe
desarrollarse un algoritmo, este
desarrollo debe de ir en una
secuencia que puede ser
computacional o procedural y puede
ser implementada como modulo de
software.
Las ED se desarrollan al mismo
tiempo que los algoritmos.
Diseño de Algoritmos y ED

57. Ya que las operaciones manipulan
todos los atributos de una clase.
Las operaciones se pueden dividir en
tres categorías:
Diseño de Algoritmos y ED
Operaciones que
manipulen datos,
es decir,
agregando,
eliminando, etc.
Las operaciones
que ejecutan
cálculos.
Operaciones que
supervisan y
controlan el
comportamiento
de un objeto.

58. Son la base para la búsqueda de
soluciones a problemas comunes del
desarrollo de software.
Los patrones de diseño proporcionan
elementos reusables para el diseño
de sistemas de.
Estos patrones no deben ser
utilizados siempre.
Patrones de Diseño.

59. Estos deben ser utilizados solo si
poseemos el mismo problema o
similar que el patrón pueda
solucionar.
Los patrones de diseño nos expresan
esquemas para definir diseños con la
cual construir un sistema.
Patrones de Diseño.

60. Gamma y sus colegas dicen que este
patrón vuelve el DOO mas flexible,
elegante y en especial reutilizable.
La persona encargada del diseño
debe estar en la capacidad de
observar cada oportunidad donde
pueda reutilizar y crear el patrón de
diseño.
Patrones de Diseño.

61. Modelos de clases
Es una descripción de las
clases en un sistema y sus
relaciones; no describe el
comportamiento dinámico
del sistema , como por el
ejemplo el
comportamiento de
objetos individuales .

62. PABLO ALTAMAR

64. Generalizacion
Esta relación es la que se
mantiene entre la clase X y
la clase Y, donde la clase Y
es el ejemplo mas
especifico

65. Agregracion en UML

66. Diagrama en UML

68. Agregación
En esta la línea con un rombo hueco indica que la
clase describe objetos que agregan otros objetos,
la clase con el rombo unido a ella describe
objetos, que contiene objetos definidos por la
otra clase.

69. Composición
Es una forma especial de agregación,
esta se usa cuando se tiene en la que un objeto
contiene un numero de otros objetos y cuando el
objeto contenedor se elimina todas las instancias
de los objetos que están contenidos desaparecen
.

70. Asociaciones
Una relación ocurre entre dos clases
cuando existe alguna relación entre
ellas.
Ejemplo de relación simple

71. Relación de 1 a 1..*

72. Casos de uso
EN UML, un caso de uso se
documenta de manera muy simple
en termino de actores y de un caso
de uso, un actor puede ser cualquier
agente que interactue con el sistema
y un caso de uso cualquier accion
que este realize

73. Documentando roles

74. Caso de uso simple

75. Colaboraciones
Durante la ejecucion de un sistema
orientado a objetos, los objetos
interactuan con cada uno de los de
los otros , por ejemplo si un sistema
bancario , hay un objeto cuenta
puede enviar un mensaje a un objeto
transaccion , para crear una
transaccion que ha ocurrido en una
cuenta, toda esta informacion es

76. Importante para el diseñador de un
sistema orientado a objetos durante
el proceso de validación e
identifacion de las clases.

77. FABIO MARQUEZ

78. CASO DE
ESTUDIO

79. CASO DE ESTUDIO
Un caso de estudio es un método
particular de investigación
cualitativa.
Se usa en grandes muestras,
siguiendo un rígido protocolo para
examinar un número limitado de
variables. Los casos de estudio
envuelven una profundización y
examen longitudinal de una sencilla
instancia o evento.

80. CASO DE ESTUDIO
Consiste en una forma sistemática de
observar los eventos, coleccionando
datos, analizando información y
reportando resultados.
Los casos de estudio son una
herramienta de relaciones públicas
que consiste en ejemplos reales en
los que se presenta una historia
positiva sobre los beneficios que un
producto o servicio le han significado
a unos determinados usuarios.

81. EJEMPLO
Libros –en-linea, es una compañía
creada recientemente, que es
subsidiaria de otra compañía
multinacional de comercio, conocida
como POLLDAY PUBLISHING. Los
directores de POLLDAY PUBLISHING
se decidieron a llevar un gran
crecimiento en ventas por internet
entre sus clientes y decidieron
preparar a libros –en- linea para ello.

82. CASOS DE ESTUDIO
EL concepto que POLLDAY tiene es
el de un sitio web de comercio
electrónico, que tenga catalogo de
cada libro que manejan.

83. REQUISITOS LIBROS-EN-
LINEA
1. CAPACIDAD VENTAS EN LINEA
✓Permitir al cliente examinar los
detalles del libro.
✓Ordenarlo y que el cliente registre su
Email para recibir notificaciones.

84. REQUISITOS
2. CUANDO EL CLIENTE INGRESE
✓Despliegue de cada uno de los
recursos mencionados

85. REQUISITOS
3. CUANDO EL CLIENTE
REGISTRE SU CORREO.
✓ Pregunta su información personal:
➢ Nombre
➢Dirección Correo
➢Dirección Postal
✓Administrador de contactos será
responsable de enviar las ofertas

86. REQUISITOS
4. EL CLIENTE PODRA COMPRAR
LIBROS DE CATALOGO EN LINEA.
✓El cliente podra examinar paginas
con detalles de los libros
✓Podra seleccionar el libro, ya sea
mediante un mecanismo ya sea al
presionar un boton.

87. REQUISITOS
✓El sistema deberá mantener un
carrito de compras virtual, en el que
los detalles de cada libro se
almacenan, conforme se llena el
carro se muestra el precio
acumulado de la compra.

88. REQUISITOS
5. CUANDO EL CLIENTE TERMINE
DE COMPRAR EN EL SITIO WEB.
✓Se le pedirá información acerca de
que forma de envió prefiere
✓Por omision se mostrara la opcion de
envio por correo estandar

89. REQUISITOS
6. EL SITIO WEB DEBE
INTERACTUAR CON UN SISTEMA
DE CONTROL DE INVENTARIO.
✓Control de inventario, deberá
manejar el proceso de recepción de
libros de los inventarios de las
editoriales.
✓Además deberá registrar el retiro de
libros por parte de los clientes

90. Pre ordenar Existencias del libro.

91. REQUISITOS
7.CONTROL DE INVENTARIOS
POR PARTE DE UN
ADMINISTRADOR.
▪ El o ella tendrán la responsabilidad
de mantener las ventas, y la
disponibilidad de existencias.
Cuando la existencia de un libro se
encuentra baja, hace un nuevo
pedido.

92. IDENTIFICACION DE CLASES
❖ Registro Cliente
❖Libro
❖Orden
❖Línea de Orden
❖Carrito
❖Orden Espera
❖Almacén
❖Registros Existencias
❖Nota Empaque
❖Tarjeta Crédito

93. IDENTIFICACION DE
ACTORES
❖Cliente
❖Administrador Marketing
❖Administrador Control Inventarios
❖Registro
❖Ordenar
❖Realizar

94. CASO DE USO PARA ACTOR
CLIENTE

95. DIAGRAMA DE CLASES PARA
EL CASO ESTUDIO

96. RELACIONES DIAGRAMA DE
CLASES
Almacén asocia con registro stock, el
cual checa los libros almacenados en
el almacén.
Un registro de existencia se asocia
con un solo libro y viceversa.
Una orden puede consistir en un
número de líneas de orden, y una
línea de orden será asociada con una
sola orden

97. Un cliente registrara su número de
tarjeta de crédito al sistema, un
número de tarjeta de crédito se asocia
con un solo cliente.
Un cliente se asocia con un número de
ordenes satisfechos, las cuales se
realizan sobre un periodo de tiempo.
Cada orden satisfecha se asocia con un
solo cliente.
Un cliente se asocia con un número de
ordenes en espera, que actualmente no
pueden ser satisfechos. Cada orden
ene spera se asocia con un solo cliente.

98. ANDRES FELIPE OÑATE “El PIPE”

99. Diseño orientado objeto
La etapa final de desarrollo, dentro del
ciclo de vida orientada a objetos, es la
programación.
la programación es analizada como
importante pero como actividad
subsidiaria al análisis y diseño

100. El proceso de programación involucra
la conversión de un diseño orientado a
objetos en un código de programa.
Efectivamente, esto significa que las
clases definidas en el diseño deben ser
convertidas en clases expresadas en
un lenguaje de programación orientado
a objetos como Java, C++ o SmallTalk

101. ejemplo del código esqueleto
de una clase se muestra a
continuación.

102. Class Cliente {
Private String NombreCliente;
Private String DireccionCliente;
// Se definen más atributos aquí
Public String obtenerNombreCliente/)
//código para obtenerNombreCliente
Public void modificarDireccionCliente (String
Direccion j
//código para modificarDireccionCliente
//código para las operaciones restantes

105. Class Contador í
Private int veces;
Public Contador (int valorInicio)
Public void ajustaContadorI int valor)
Public int obtenercuenta ( )
í Public void incrementacuenta
Veces = valorInicio;
Veces = valor;
Return veces;
Veces t ;

106. Existen dos maneras de
combinar clases: la primera es
la herencia y la segunda es la
agregación. Los lenguajes de
programación orientada a
objetos contienen recursos que
permiten a ambas ser
implementadas fácilmente.

107. Recuérdese que, en la
herencia, las operaciones en la
superclase se heredan por la
superclase

108. Class TiempoContador extends Contador {
Time horaAcceso;
Public TiempoContador (int valorInicio)
Super (valorInicio);
HoraAcceso = new Time horaAcceso ( );
Public void ajustaContadori int valor)
isuper.ajustaContador (int valor);
horaAcceso.setNow ( );
Public Time obtenHora ( )
Public void incrernentacuenta ( )
Super. Incrementacuenta í);
horaAcceso.setNow ( );
Return horaAcceso;

109. Esto es, como un lenguaje de
programación orientado a
objetos implementa la herencia.
La implementación de la
agregación es más simple: todo
lo que involucra es la inclusión
de las partes agregadas como
atributos de clase. Por ejemplo,
la clase siguiente :

110. Class Computer {
Private Monitor Mon;
Private KeyBoard kb;
Private Processor proc;
// Demás atributos
//definición de las operaciones
asociadas con la
computadora.//