Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Bibliografa bsica
G. Booch, J. Rumbaugh, I. Jacobson. El lenguaje unificado de modelado. Addison-Wesley (1999)
J. Rumbaugh, I. Jacobson, G. Booch, . El lenguaje unificado de modelado. Manual de referencia.
Addison-Wesley (1999)
I. Jacobson G. Booch, J. Rumbaugh. El proceso Unificado de Desarrollo de Software. AddisonWesley (1999)
G.Booch. Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin.
Addison-Wesley/ Daz de Santos (1996).
B. Meyer. Construccin de software orientado a objetos. Segunda edicin. Prentice-Hall (1999).
E. Gamma, R. Helm, R. Johnson, J Vlissides. Patrones de diseo. Elementos de software orientado a
objetos reutilizable. Addisson-Wesley/ Pearson Educacin (2003).
Bibliografa complementaria
L. Joyanes Aguilar. Programacin Orientada a Objetos. Segunda Edicin. McGrawHill (1998).
Pierre-Alain Muller. Modelado de objetos con UML. Eyrolles-Gestin 2000 (1997).
N. Lpez, J. Migueis, E. Pichon. Integrar UML en los proyectos. Eyrolles-Gestin 2000 (1998).
R.C. Martin. Designing Object-Oriented C++ applications using the Booch method
Prentice-Hall (1995)
J.M. Cueva et al. Introduccin a la programacin estructurada y orientada a objetos con Pascal.
Distribuido por Editorial Ciencia-3 (1994).
Tema 1
La complejidad del desarrollo de software
Contenidos
1.1 La complejidad inherente al software
1.2 La estructura de los sistemas complejos
1.3 Imponiendo orden al caos
1.4 Diseo de sistemas complejos
1.5 Resumen
1.6 Test de auto-evaluacin
1.7 Lecturas recomendadas
1.8 Referencias
[Booch 94]
1-1
1-2
1-3
1-4
Por qu el software es
complejo de forma innata?
La complejidad inherente al software se
deriva de los siguientes cuatro
elementos [Booch 94]
1-5
Mantenimiento de software
Cuando se corrigen errores
1-6
La dificultad de gestionar el
proceso de desarrollo
Dirigir un equipo de desarrolladores
mantener la unidad de accin
conservar la integridad del diseo
1-7
1-8
El problema de caracterizar el
comportamiento de sistemas
discretos
La ejecucin de un programa es una transicin entre
estados de un sistema discreto
Cada estado contiene las variables, su valor,
direcciones en tiempo de ejecucin, etc.
Disear el sistema de forma que el comportamiento
de una parte del sistema tenga mnimo impacto en
otra parte del mismo
La transicin entre estados debe ser determinista
Sin embargo a veces no lo es, pues un evento puede
corromper el sistema pues sus diseadores no lo tuvieron en
cuenta
1-9
1-10
1-11
1-12
La estructura de la materia
Estructura jerrquica (tomos, electrones, protones,
neutrones, quarks)
1-13
Componentes
Patrones
Evolucin
1-14
Complejidad organizada y
desorganizada
La forma cannica de un sistema complejo
El descubrimiento de abstraciones y mecanismos comunes
facilita en gran medida la comprensin de sistemas
complejos
Dos tipos de jerarquas
1-15
1-16
El papel de la descomposicin
La tcnica de dominar la complejidad se conoce desde tiempos remotos:
divide et impera (divide y vencers)
Descomposicin algortmica
Por ejemplo por diseo estructurado descendente [Booch 94]
1-17
1-18
El papel de la abstraccin
La abstraccin permite ignorar los detalles
no esenciales de un objeto complejo
La abstraccin permite modelos
generalizados e idealizados de objetos
La abstraccin reduce la complejidad
Los objetos son abstracciones del mundo
real, que agrupan informacin densa y
cohesiva
1-19
El papel de la jerarqua
El reconocimiento explcito de las jerarquas de
clases y objetos dentro de un sistema software
complejo es una forma de incrementar el contenido
semntico de la informacin del sistema
La jerarqua de objetos ilustra como diferentes
objetos colaboran entre s a travs de patrones de
iteraccin denominados mecanismos
La jerarqua de clases resalta la estructura y los
comportamientos comunes en el interior del sistema
La identificacin de las jerarquas no es una tarea
fcil
La jerarqua de clases y objetos incluye herencia y
composicin.
1-20
El diseo es la aproximacin disciplinada que se utiliza para concebir una solucin para algn
problema, suministrando as un camino desde los requisitos hasta la implementacin.
Los productos del diseo son modelos que permiten razonar sobre las estructuras, hacer
concesiones cuando los requisitos entran en conflicto y proporcionar un anteproyecto para la
implementacin
1-21
1.5 Resumen
Las tcnicas de anlisis y diseo orientado a objetos
estn pensadas para desarrollo de software de
dimensin industrial.
El software es complejo de forma innata. La
complejidad de los sistemas excede frecuentemente
la capacidad intelectual humana
La complejidad puede atacarse por medio del uso
de la descomposicin, abstraccin y jerarqua
(complejidad organizada)
Los sistemas complejos pueden evolucionar desde
formas intermedias estables
El diseo orientado a objetos define una
descomposicin, abstraccin y jerarqua basada en
clases y objetos
El diseo orientado a objetos define notaciones y
procesos que conducen a modelos que permiten
razonar sobre diferentes aspectos del sistema que se
est simulando.
Conviene volver a leer este tema cuando se tenga
ms experiencia en Anlisis y Diseo
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
1-22
1-23
1.8 Referencias
[Booch 94] G.Booch. Object-Oriented Analysis and Design with Applications. Second
Edition. Addison-Wesley (1994). Versin Castellana: Anlisis y diseo orientado a
objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de Santos (1996).
[Meyer 97] J.-M. Jzquel, B. Meyer. Design by Contract: the lessons of Ariane.
IEEE Computer. January 1997, Vol. 30, No. 1, pp 129-130.
[Tribuna Astronoma 130, 1996] Comisin de Investigacin del fallo del primer vuelo
del Ariane 5. TRIBUNA DE ASTRONOMA, n 130, pp.81, 1996
1-24
Certificado de calidad
2-1
Conclusiones
2-2
2-3
2-4
2-5
Sistema de calidad
Estructura organizativa, procedimientos, procesos y recursos necesarios
para implantar la gestin de calidad[ISO][AENOR]
Documentacin
Formacin de personal
Creacin y coordinacin de equipos de trabajo
Normativas
ISO [ISO][AENOR]
2-6
2-7
El esfuerzo requerido para aprender el manejo de una aplicacin, trabajar con ella,
introducir datos y conseguir resultados
El grado con que puede controlarse el acceso al software o a los datos a personal no
autorizado
La cantidad de recursos hardware y software que necesita una aplicacin para realizar las
operaciones con los tiempos de respuesta adecuados
El grado que se puede esperar de una aplicacin lleve a cabo las operaciones especificadas
y con la precisin requerida
El grado en que una aplicacin satisface sus especificaciones y consigue los objetivos
encomendados por el cliente
El esfuerzo requerido para probar una aplicacin de forma que cumpla con lo especificado
en los requisitos
2-8
Facilidad de auditoria
Exactitud
Normalizacin de las comunicaciones
Completitud
Concisin
Consistencia
Estandarizacin de los datos
Tolerancia de errores
Eficiencia de la ejecucin
Facilidad de expansin
Generalidad
Independencia del hardware
Instrumentacin
Modularidad
Facilidad de operacin
Seguridad
Auto-documentacin
Simplicidad
Independencia del sistema software
Facilidad de traza
Formacin
2-9
Auditoria fsica
Auditoria de la ofimtica
Auditoria de la direccin
Auditoria de la explotacin
Auditoria de la calidad
Auditoria de la seguridad
Auditoria de redes
Auditoria de aplicaciones
2-10
2-11
2-12
2.12 Referencias
[AENOR] AENOR Asociacin Espaola de Normalizacin y Certificacin..
http://www.aenor.es
[ISO] International Standardization Organization. http://www.iso.ch
[Jackson 1996] P. Jackson, D. Ashton. Implemente calidad de clase mundial. ISO 9000-BS5750.
Limusa (1996).
[Kan 1995] S. H. Kan. Metrics and Models in software Quality Engineering. Addison-Wesley
(1995).
[MAP] Ministerio Administraciones Pblicas de Espaa. Consejo Superior de Informtica.
http://www.map.es/csi
[McCall 1977] James McCall (Editor).Factors in Software Quality. Technical Report, General
Electric, 1977.
[Meyer 1997] B. Meyer. Object-Oriented software construction.Second Edition, Prentice-Hall,
1997. Versin castellana: Construccin de software orientado a objetos,Prentice-Hall,
1999.
[NIST] National Institute of Standars and Technology. http://www.quality.nist.gov/
Norma ISO 9000-1 UNE (31 pginas). International Standardization Organization. Una Norma
Espaola. http://www.aenor.es
Norma ISO 9001 UNE (21 pginas) International Standardization Organization. Una Norma
Espaola. http://www.aenor.es [ISO]
Norma ISO 9000-3 (5 + 15 pginas) International Standardization Organization. Una Norma
Espaola. http://www.aenor.es [ISO]
Norma ISO 9004-1 UNE (41 pginas) International Standardization Organization. Una Norma
Espaola. http://www.aenor.es [ISO]
Norma ISO 8402 UNE (30 pginas) International Standars Organization. Una Norma Espaola
http://www.aenor.es [ISO]
[NOVATICA 137] NOVATICA.Nmero 137, Enero-Febrero 1999. Monogrfico Calidad del
Software / Software de calidad. Publicada por la Asociacin de Tcnicos en Informtica
(ATI). www.ati.es
[Oskarsson 1996] Oskarsson , Glass R.L. An ISO 9000 approach to building Quality Software.
Prentice-Hall (1996)
[Piattini 1996] M.G. Piattini, J.A. Calvo-Manzano, J. Cerveza, y L. Fernndez. Anlisis y diseo
detallado de aplicaciones informticas de gestin. RA-MA (1996).
[Piattini 2001] M.G. Piattini, E. Del Peso (Editores). Auditora Informtica. Un enfoque
prctico. 2 Revisin ampliada y revisada. Ed. RA-MA (2001)
[Pressman 1993] R. S. Pressman. Ingeniera del software. Un enfoque prctico. 3 Edicin.
McGrawHill (1993)
[Pressman 1998] R. S. Pressman. Ingeniera del software. Un enfoque prctico. 4 Edicin.
McGrawHill (1998)
[Sanders 1994] J. Sanders, E. Curran. Software Quality. Addison-Wesley (1994)
[SEI] Software Engineering Institute http://www.sei.cmu.edu
[Tingey 1997] M. O. Tingey. Comparing ISO 9000, Malcom Baldrige and the SEI CMM for
software. Prentice-Hall (1997).
2-13
Tema 3
Introduccin a la
Tecnologa de Objetos
Mundo real
Modelo
3-1
CONTENIDOS
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
Respuestas de auto-evaluacin
3-2
3-3
3-4
3-5
3-6
3-7
Ingeniera web
Lenguajes y especificaciones para aplicaciones en la web
definidos por el World Wide Web Consortium
(www.w3c.org)
Lenguajes de marcas: HTML, XML y SGML
Lenguajes de programacin (Java y C# )
Tecnologas Java y .NET
Lenguajes de script (ASP, JavaScript, VisualBasicScript)
Applets y Servlets
Computacin ubicua
Usabilidad
Servicios web
Gestin del Conocimiento
Internet
3-8
C#
VBASIC.NET
3-9
http://gcc.gnu.org
3-10
3-11
#pragma hdrstop
#include <condefs.h>
//--------------------------#include <iostream>
using namespace std;
//---------------------------// Para el uso de getch() se incluye conio
#include<conio>
//---------------------------#pragma argsused
int main(int argc, char* argv[])
{
cout<<"Hola a todos\n";
3-12
Jefe experto
No te subo el
sueldo porque no
tienes 10 aos de
experiencia en
Java.
Acaso tu puedes
girar sobre ti mismo
sin mover tu trasero
3-13
3-14
3-15
3-16
/**
Tabla de multiplicar nmeros reales
Ilustra el bucle for (para) y conversion de string a real
@author Juan Manuel Cueva Lovelle
*/
import java.io.*;
class TablaMultiplicarReales{
public static void main (String[] arguments) throws IOException{
BufferedReader entrada= new BufferedReader
(new InputStreamReader(System.in));
System.out.println
("Hola, dime de que numero REAL hacemos la tabla de multiplicar");
3-17
<HTML>
<APPLET CODE=HolaMundo.class WIDTH=300 HEIGHT=100>
</APPLET>
</HTML>
3-18
3-19
3-20
3-21
3-22
3-23
3-24
El lenguaje C#
El primer programa
//
//
//
//
Hola.cs
Versin 1.0 6-Enero-2003
Autor: Juan Manuel Cueva Lovelle
Primer programa en C#
using System;
namespace Saludo
{
/// <summary>
/// La clase Hola saluda en la consola
/// </summary>
class Hola
{
/// <summary>
/// El mtodo Main de Hola
/// </summary>
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("Hola a todos");
//Espera que se pulse una tecla
Console.ReadLine();
} //Fin del mtodo Main
} //Fin de la clase Hola
} //Fin del namespace
3-25
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
3-26
Compilacin
public
public static
args ))
static void
void Main(String[]
Main(String[] args
{{ String
usr;; FileStream
FileStream f;
f; StreamWriter
StreamWriter w;
String usr;
usr
w;
try
try {{
usr
GetEnvironmentVariable("USERNAME");
usr=Environment.
=Environment.GetEnvironmentVariable("USERNAME");
GetEnvironmentVariable
("USERNAME");
f=new
f=new FileStream
FileStream(
FileMode.Create);
((C:
C:\
C:
C:\\
\\\test.txt",
\\test.txt",
test.txt",FileMode.Create);
FileMode
.Create);
public
void
args ))
public static
static
void Main(String[]
Main(String[] args
w=new
StreamWriter
(f);
w=new StreamWriter(f);
StreamWriter
(f);
{
String
usr;
usr
;
FileStream
FileStream
f;
f; StreamWriter
StreamWriter w;
{
String
usr
;
w;
w.WriteLine
WriteLine(
usr);
w.
w.WriteLine
WriteLine((usr
);
try
try {{
w.Close();
w.Close();
usr
GetEnvironmentVariable("USERNAME");
usr=Environment.
=Environment.GetEnvironmentVariable("USERNAME");
GetEnvironmentVariable
("USERNAME");
}} catch
catch (Exception
(Exception e){
e){
f=new
FileStream
C:
test.txt",
FileMode.Create);
f=new
FileStream(
((ToString());
ToString
C:\
C:
C:\\\\\\\test.txt",
test.txt",
FileMode
FileMode.Create);
.Create);
Console.
Console.WriteLine("Exception:"+e.
WriteLine
("Exception:"+e.
WriteLine ("Exception:"+e.ToString());
());
w=new
StreamWriter(f);
w=new StreamWriter(f);
StreamWriter
(f);
}}
w.WriteLine
WriteLine(
(
usr
usr
);
w.
w.
WriteLine
WriteLine
(
);
}}
w.Close();
w.Close();
}} catch
catch (Exception
(Exception e){
e){
Console.
Console.WriteLine("Exception:"+e.
WriteLine
WriteLine("Exception:"+e.
("Exception:"+e.ToString());
ToString
ToString());
());
}}
}}
Assembly
(ensamblado)
ensamblado)
Compilador
C#
J#
VBasic.NET
Cobol.NET
Eiffel.NET
Cdigo
fuente
IL (lenguaje intermedio)
Metadatos
Recursos
Ejecucin
CLR
Common Language Runtime
3-27
IL a
compilador
Nativo
Cargador
de clases
Seguridad
Cargador
Assembly
Recolector de basura
Nativo.exe
+ tabla
Recolector
Basura
Gestor
de
Cdigo
Gestor de excepciones
Soporte de Hilos
Debug
COM Interop
3-28
DOO
AOO
POO
3-29
Modelo lgico
Qu clases existen y como se relacionan estas clases?
Qu mecanismos se utilizan para regular la forma en que los objetos
colaboran?
Modelo fsico
Dnde debera declararse y construirse cada clase y objeto?
A qu procesador debera asignarse un proceso, y para un procesador dado,
cmo deberan planificarse sus mltiples procesos?
3-30
Yourdon y Constantine
Wirth
Dahl, Dijkstra y Hoare
Jackson
Warnier y Orr
Booch
OMT (Rumbaugh et al.)
Objectory (Jacobson et al.)
Schlaer-Mellor
Coad/Yourdon
Fusion (Coleman et al.)
Mtrica - 3
3-31
3.2.3 Notaciones
3-32
UML
nombreClase
atributos
operaciones
Objeto:nombreClase
atributos
operaciones
Superclase
Subclase A
Subclase B
Clase agregacin
Clase Parte1
Clase A
Clase Parte2
Clase B
3-33
Visualizar
Especificar
Construir
Documentar
Un mtodo incluye
Publicacin de
UML 1.0, Enero 97
realimentacin
pblica
OOPSLA 95
UML 1.0
Booch 91
Estandarizacin
Booch 93
Otros mtodos
UML 1.1
Industrializacin
Compaeros UML
Expertos
Unificacin
OMT - 2
OMT - 1
OOSE
Fragmentacin
3-34
Cada vista del modelo que resulta del diseo orientado a objetos es un
conjunto de diagramas
Estos diagramas permiten razonar sobre el comportamiento del sistema
Cuando el modelo es estable cada uno de los diagramas permanece
semnticamente consistente con el resto de los diagramas
3-35
Vista de diseo
Vista de despliegue
Vista de implementacin
Vista de procesos
Muestra los requisitos del sistema tal como es percibido por los usuarios
finales, analistas, y encargados de pruebas.
3-36
Se caracteriza por
Est dirigida por los casos de uso
Se utilizan para establecer el comportamiento
deseado por el sistema, para verificar y validar la
arquitectura del sistema, para las pruebas y para
la comunicacin entre las personas del proyecto
Centrado en la arquitectura
La arquitectura se utiliza para conceptualizar,
construir, gestionar y hacer evolucionar el
sistema en desarrollo
Iterativo e incremental
Proceso iterativo es aqul que involucra la
gestin de un flujo de ejecutables
Proceso incremental es aqul que involucra la
continua integracin de la arquitectura del
sistema para producir esos ejecutables, donde
cada ejecutable incorpora mejoras incrementales
sobre los otros.
Un proceso iterativo e incremental est dirigido
por el riesgo, lo que significa que cada versin
se encarga de atacar y reducir los riesgos ms
significativos para el xito del proyecto
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-37
Se descompone en fases
Iniciacin
Elaboracin
Construccin
Transicin
3-38
3-39
3-40
Ejemplo: No debe permitir que una clase padre herede de una clase hija
Completa
Bien diseada, cmoda de utilizar y de usar
Personalizable (se genera en formatos estndar que pueden ser
manejados por herramientas de maquetacin estndar)
3-41
3-42
Abstraccin
Encapsulacin y ocultacin de la informacin
Modularidad
Jerarqua (herencia, polimorfismo y agregacin)
Elementos secundarios
Elementos relacionados
Componentes
Patrones de diseo
3-43
3.4 Abstraccin
Una abstraccin denota las caractersticas esenciales de un objeto que lo
distinguen de todos los dems tipos de objeto y proporciona as fronteras
conceptuales ntidamente definidas respecto a la perspectiva del observador
[Booch 94]
3-44
Abstraccin
En la abstraccin obtenemos objetos del mundo real de los cuales
enfatizaremos algunos detalles o propiedades mientras suprimiremos otros
Tambin nos fijaremos en el comportamiento de los objetos para definir
las acciones u operaciones que son capaces de realizar
Los objetos en el sistema se deben de tratar como seres vivos que nacen
(constructores), viven (estn activos), duermen (estn pasivos), se
reproducen (copia de objetos), y mueren por eutanasia (destructores) o por
inanicin (recolector de basura)
Ejemplo de objetos: una factura, un albarn, un usuario, ...
A partir de objetos que tienen unas propiedades y acciones comunes se
deben abstraer las clases. Los nombres de los objetos son nombres propios.
En las clases se definen las propiedades y operaciones comunes de los
objetos. Los nombres de las clases son nombres comunes.
Los nombres de los mtodos son verbos, pues especifican las acciones que
realizan los objetos
Objetos
Mundo real
Propiedades
y acciones
Abstraccin
3-45
Clases y objetos
[Rumbaught 91]
3-46
Pez
3-47
3-48
Identidad de objetos
En las clases deben disearse atributos de forma que
permitan identificar a los objetos de manera nica
3-49
3.5 Encapsulacin
Es el proceso de almacenar en un mismo compartimento los
elementos de una abstraccin que constituyen su estructura y su
comportamiento; sirve para separar el interfaz contractual de una
abstraccin y su implementacin [Booch 94]
3-50
Encapsulacin
En la encapsulacin los datos o propiedades son privados y
se accede a ellos a travs de los mtodos [Cueva 93]
ACCESO
METODO 1
METODO 6
METODO 2
DATOS
METODO 3
METODO 5
METODO 4
3-51
Clases
Una clase es un conjunto de objetos que comparten
una estructura comn y un comportamiento comn
[Booch 94]
3-52
Clases
Sin detalle
Detalles a nivel de anlisis y diseo
Detalle a nivel de implementacin
+ publico
# protegido
- privado
UML
3-53
<<constructores>>
+ Perro(void)
+ Perro(string unNombre, string unaRaza)
<<destructores>>
+ ~Perro(void)
<<selectores>>
+ verNombre(void):string
+ verRaza(void):string
+ verCodigo(void):long
+ verContador(void):long {static}
<<modificadores>>
+ void ponNombre(string unNombre);
+ void ponRaza(string unaRaza);
<<comportamiento>>
+ void ladra(void);
+ void saluda(void);
3-54
Perro
codigo : Long = 0
contador : Long = 0
nombre : String = "Sin nombre"
raza : String = "Sin raza"
<<Destructor>> ~Perro()
<<Comportamiento>> ladra()
<<Constructor>> Perro()
<<Modificador>> ponNombre()
<<Modificador>> ponRaza()
<<Comportamiento>> saluda()
<<Selector>> verCodigo()
<<Selector>> verContador()
<<Selector>> verNombre()
<<Selector>> verRaza()
3-55
class Perro
{
protected:
string nombre;
string raza;
static long contador; //slo pertenece a la clase
long codigo;
public:
//constructores
Perro (void);
Perro (string unNombre, string unaRaza);
//comportamiento
void ladra (void) {cout<<nombre<<" dice guau, guau"<<endl;};
void saluda(void);
//selectores
string verNombre(void) const { return nombre; };
string verRaza(void) const { return raza; };
long verCodigo(void) const { return codigo; };
static long verContador(void) { return contador; };
//modificadores
void ponNombre(string unNombre) {nombre=unNombre; };
void ponRaza(string unaRaza) {raza=unaRaza; };
//destructor
~Perro(void) {cout<<"Se ha muerto el perro de nombre "<<nombre;
cout<<" y codigo "<<codigo<<endl; };
};
#endif
//fin PERRO_HPP
3-56
#include "Perro.hpp"
long Perro::contador=0;
Perro::Perro(void)
// Constructor de la clase perro
{
nombre="Sin nombre";
raza="Sin raza";
codigo=contador++;
cout << "Ha nacido un perro que se llama: "<<verNombre()<<endl;
}
Perro::Perro(string unNombre, string unaRaza)
{
// Constructor de la clase perro sobrecargado
nombre=unNombre;
raza=unaRaza;
codigo=contador++;
cout << "Ha nacido un perro que se llama: "<<verNombre()<<endl;
}
void Perro::saluda(void)
{
cout<<"Hola, mi nombre es "<<verNombre()<<endl;
cout<<"y soy de la raza "<<verRaza()<<endl;
cout<<"Mi cdigo interno es "<<verCodigo()<<endl;
}
3-57
pancho : Perro
ladra( )
saluda( )
ponNombre( )
ponRaza( )
ladra( )
saluda( )
Perro( )
tom : Perro
Perro( )
pio : Perro
Perro( )
callejero : Perro
~Perro( )
~Perro( )
~Perro( )
~Perro( )
3-58
3-59
Para
3-60
pancho.ponNombre("Pancho");
pancho.ponRaza("Setter");
pancho.ladra();
pancho.saluda();
3-61
cout << "El numero de perros creados por la clase Perro es: ";
//Al ser un mtodo esttico se aplica sobre la clase
cout << Perro::verContador() << endl;
return 0;
}
3-62
3-63
Una clase es un tipo definido por el usuario, que permite crear objetos. Las
clases tienen miembros formados por campos y mtodos. Una struct es una
clase con todos los miembros pblicos.
Los campos miembro suelen declararse protegidos (protected), salvo en
casos especiales que se declaran privados (privated)
Los mtodos pblicos (public) permiten acceder a los campos miembro
desde el exterior de la clase
Los mtodos selectores no modifican el valor de los campos miembro. Se
suelen denominar:
Se aconseja poner siempre destructores (en C++), para saber donde y cuando se
destruyen los objetos.
Se puede poner un mensaje que indique cuando y donde se estn destruyendo los
objetos. Muy aconsejable para depurar programas
3-64
3-65
/**
* clase Vehiculo, ilustra el manejo bsico de clases
* @version 1.0 15 de Julio 1998
* @author Juan Manuel Cueva Lovelle
*/
// Solo los identificadores de clases pueden empezar con maysculas
class Vehiculo {
// campos
//declaracin e inicializacin de cadenas
protected String matricula= "Sin matricular ;
protected String propietario= "Sin propietario ;
// Los campos numricos se inializan implcitamente
protected float velocidadMaxima; // inicializado a cero
protected int numeroPasajeros; //inicializado a cero
// Campos estticos
//Son campos que se comparten por objetos de la clase
//Son definidos en la clase por eso tambin se llaman variables de clase
protected static long numeroVehiculosProducidos;
private long numeroSerie; //almacena en cada objeto el nmero de serie
3-66
// Constructores
// No pueden devolver nada pero pueden tener parmetros
// Si no se definen siempre existe un constructor por defecto (no-arg)
//Constructor mnimo
//Tambin podra tener parmetros
Vehiculo(){
numeroSerie=numeroVehiculosProducidos++;
}
//Sobrecarga de constructores
//Constructor completo
Vehiculo(String unaMatricula,
String unPropietario,
float unaVelocidadMaxima,
int unNumeroPasajeros){
this(); //Invocacin de constructor explcito
//Debe ser la primera instruccin ejecutable
//Tambin puede tener parmetros
//La sobrecarga se resuelve en tiempo de compilacin
matricula = unaMatricula;
propietario = unPropietario;
velocidadMaxima = unaVelocidadMaxima;
numeroPasajeros = unNumeroPasajeros;
}
3-67
3-68
// Mtodo toString
// Es un mtodo especial
// Si un objeto tiene un mtodo toString sin parmetros y que devuelve
// un String, entonces este mtodo ser invocado si aparece el identificador
// del objeto en una concatenacin de cadenas String con el operador
// concatenacin +
public String toString(){
String descriptor = "Nmero de Serie - + verNumeroSerie()+
"( + verMatricula()+ ") ;
return descriptor;
}
3-69
3-70
3-71
3-72
/// <summary>
/// El mtodo Main contiene la prueba unitaria de la clase perro
/// </summary>
[STAThread]
static void Main(string[] args)
{
Perro callejero = new Perro();
Perro pancho=new Perro("Pancho");
Perro tom= new Perro("Tom","Pointer");
callejero.Nombre="Ron";
callejero.Raza="Mastn";
callejero.Edad=2;
callejero.Ladra();
Console.WriteLine("Dime lo que sabes de ... "+callejero);
Console.WriteLine("Dime lo que sabes de ... "+pancho);
Console.WriteLine("Dime lo que sabes de ... "+tom);
//Ejemplo de llamada a mtodo esttico
Console.WriteLine("Los perros creados son "+Perro.VerContador());
//Espera una tecla para finalizar
Console.ReadLine();
} //Fin de Main
} // Fin de la clase Perro
} // Fin del namespace Mascota
3-73
Ocultacin de informacin
Debe ser posible en una clase especificar que caractersticas
estn disponibles a todos los clientes, a los herederos, a
algunos clientes o slo se pueden utilizar internamente
PBLICO
PRIVADO
3-74
Encapsulacin y ocultacin de
informacin
Con la encapsulacin los usuarios de una clase no
necesitan conocer los detalles internos de la
implementacin (a esto ltimo tambin se
denomina ocultacin de informacin)
Por ejemplo las estructuras de datos utilizadas
internamente en una clase
3-75
Objetos (I)
Un objeto tiene estado, comportamiento e identidad; la
estructura y comportamiento de objetos similares estn
definidos en su clase comn; los trminos instancia y
objeto son intercambiables [Booch 94]
3-76
Objetos (II)
3-77
Objetos (III)
3-78
Objetos (IV)
Diagrama de estados de los objetos de la clase Perro
<<Selectores>>
ver...( void )
PorDefecto
<<Destructor>>
<<Modificador>>
~Perro( void )
PonRaza( unaRaza )
<<Selectores>>
<<Constructor>>
<<Destructor>>
ver...( void )
Perro( void )
ConRaza
<<Modificador>>
~Perro( void )
<<Destructor>>
PonNombre( unNombre )
~Perro( void )
<<Selectores>>
ver...( void )
ConNombre
<<Modificador>>
<<Modificador>>
PonRaza( unaRaza )
PonNombre( unNombre )
<<Destructor>>
~Perro( void )
<<Constructor>>
Perro( unNombre, unaRaza )
ver...( void )
<<Selectores>>
Completo
3-79
Objetos (V)
Los estados de los objetos se
modelan con una combinacin de
valores de los atributos
Los estados deben representar una
situacin en la vida del objeto
No es buen diseo generalizar que
cada estado se corresponda con el
valor de un nico atributo. Entre
otras cosas por la gran cantidad de
estados que se generaran
3-80
3-81
ladra( )
Construccin de un objeto
saluda( )
ponNombre( )
ponRaza( )
ladra( )
saluda( )
Destruccin de un objeto
~Perro( )
3-82
3.6 Modularidad
Es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto
de mdulos cohesivos y dbilmente acoplados [Booch 94]
3-83
Modularidad (I)
identificador
3-84
Modularidad (II)
system
Especifica un paquete que representa el sistema completo que
se est modelando
<<system>>
SistemaPerro
<<subsystem>>
Movimiento
<<subsystem>>
Visin
<<subsystem>>
Comportamiento
(from SistemaPerro)
(from SistemaPerro)
(from SistemaPerro)
3-85
Modularidad (III)
[Meyer 1997, captulo 3]
El diseo modular se puede enunciar con 5 criterios, 5 reglas y 5 principios
Los 5 criterios
Las 5 reglas
Descomponibilidad
Componibilidad
Comprensibilidad
Continuidad
Proteccin
Correspondencia directa
Pocas interfaces
Interfaces pequeas
Interfaces explcitas
Ocultacin de la informacin
Los 5 principios
3-86
1- Descomponibilidad modular
Es la tarea de separar un problema complejo en varios
subproblemas menos complejos, conectados por una
estructura simple y suficientemente independiente que
permita construir cada subproblema separadamente
El ejemplo ms tpico de un mtodo que satisface la descomponibilidad
modular es el diseo descendente (Top-down design)
Paquetes
En UML
Movimiento
Visin
Comportamiento
3-87
2 - Componibilidad modular
Es la resolucin de problemas por la composicin de
mdulos previamente desarrollados
3-88
3 - Comprensibilidad
Un mtodo favorece la comprensibilidad modular si ayuda a
producir software que permite comprender cada mdulo por
separado sin tener que conocer los otros, o en el caso peor tener
que examinar slo alguno de los otros mdulos.
4 - Continuidad
Un mtodo satisface la continuidad modular si un pequeo
cambio en las especificaciones del problema obliga a modificar
un mdulo o un pequeo nmero de mdulos.
5 - Proteccin
Un mtodo satisface la proteccin modular si en el caso de que
ocurra un anormal comportamiento en tiempo de ejecucin ste
se detecta en un mdulo, o en el caso peor se propaga a unos
pocos mdulos vecinos.
3-89
1 - Correspondencia directa
La estructura modular concebida en el proceso de
construccin del sistema de software debe permanecer
compatible con cualquier estructura modular creada en
el proceso de modelado del dominio del problema
Esta regla sigue especialmente dos criterios:
Continuidad: Conservando la traza de la estructura
modular del problema ser ms fcil aquilatar y limitar
los impactos de los cambios.
Descomponibilidad: El trabajo realizado para analizar
la estructura modular del dominio del problema puede
ser un buen punto de comienzo para la descomposicin
modular del software.
3-90
2 - Pocas interfaces
Todo mdulo debe comunicarse con el menor nmero de
mdulos posibles.
Esta regla sigue especialmente dos criterios:
Continuidad: El efecto de los cambios se propaga al
nmero menor de mdulos
Proteccin: El efecto de los errores se propaga al
nmero menor de mdulos
3-91
3 - Interfaces pequeas
Si dos mdulos intercambian informacin, esta debe ser la
menor posible
Esta regla sigue especialmente dos criterios:
Continuidad: El efecto de los cambios se propaga al nmero
menor de mdulos
Proteccin: El efecto de los errores se propaga al nmero
menor de mdulos
Jeroglfico
Por qu siempre que se desea dibujar a mano
alzada un mdulo suele pintarse un crculo?
3-92
4 - Interfaces explcitas
Si dos mdulos intercambian informacin, esta debe ser obvia
desde la perspectiva de cada mdulo y desde una perspectiva
global a ambos.
Esta regla sigue especialmente los criterios:
Descomponibilidad: Si es necesario descomponer un mdulo
en varios submdulos cualquier conexin entre ellos debe ser
claramente visible
Componibilidad: Si es necesario componer un mdulo con
varios submdulos cualquier conexin entre ellos debe ser
claramente visible
Continuidad: Facilita encontrar los elementos que pueden ser
afectados por cambios.
Compresibilidad: Facilita la comprensin de cada mdulo y
de todos los mdulos relacionados con dicho mdulo.
3-93
5 - Ocultacin de informacin
El diseador de un mdulo debe seleccionar un subconjunto de
propiedades de cada mdulo como informacin oficial del
mdulo, esta informacin estar disponible para los autores de
los mdulos clientes.
El resto de la informacin es secreta.
Esta regla sigue especialmente el criterio:
Continuidad: Los cambios de un mdulo se tratarn de hacer
en la parte secreta, pero no en la interfaz o parte pblica.
PBLICO
PRIVADO
3-94
3-95
2 - Auto-documentacin
El diseador de un mdulo debe esforzase para hacer que toda
la informacin relativa al mdulo est autocontenida en dicho
mdulo.
Este principio sigue especialmente los criterios:
Compresibilidad: Es obvio que facilita la comprensin de
cada mdulo.
Continuidad: Si el software y su documentacin se tratan
simultneamente se garantiza que ambos permanezcan
compatibles cuando las cosas comienzan a cambiar.
3 - Acceso uniforme
Todos los servicios ofertados por un mdulo deben utilizarse a
travs de una notacin uniforme, que no debe delatar como se
implementa internamente ese servicio.
Tambin se puede ver como un caso particular de la regla de ocultacin
de la informacin.
3-96
4 - Principio abierto-cerrado
Los mdulos deben ser simultneamente abiertos y cerrados.
Esta contradiccin aparente responde a dos de diferente naturaleza:
Un mdulo es abierto si se puede extender. Por ejemplo
utilizando la herencia.
Un mdulo est cerrado si est disponible para ser
utilizado por otros mdulos. Se supone que el mdulo est
definido con una descripcin estable de su interfaz.
5 - Eleccin nica
Siempre que un sistema de software deba soportar un conjunto
de alternativas, uno y slo un mdulo debe conocer la lista
exhaustiva de alternativas.
La tecnologa de objetos ofrece dos tcnicas conectadas con la herencia:
el polimorfismo y el enlace dinmico.
3-97
3.7 Jerarqua
Es una clasificacin u ordenacin de abstracciones
[Booch 1994]
3-98
Herencia
La herencia se debe utilizar para extender atributos y mtodos
dentro de una jerarqua.
Sin embargo no debe verse como la nica forma de trabajo,
as la composicin y la agregacin permite delegar el trabajo a
los objetos apropiados.
Tambin se denomina generalizacin (en UML), derivacin
(en C++ y C#) y extensin (en Java)
[Booch 1994]
3-99
3-100
Termmetro
Barmetro
Anemmetro
Veleta
3-101
Sensor {Abstract}
Veleta
SensorCalibrado {Abstract}
Barmetro
SensorTendencia {Abstract}
SensorHistrico
{Abstract}
Termmetro
GradienteTemperatura
GradienteBaromtrico
Higrmetro
Anemmetro
3-102
Herencia
3-103
Redefinicin de mtodos
(tambin denominada anulacin o sustitucin, en ingls overriding)
Coche
pasajeros : int = 0
ponPasajeros( )
verPasajeros( )
verTodo( )
Coche( )
~Coche( )
Camion
carga : int = 0
ponCarga( )
verCarga( )
verTodor( )
Camion( )
~Camion( )
UML
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-104
3-105
Mdulo Vehiculo.h
Clases: Vehiculo,
versin 2.0, 10 autor: J.M. Cueva
(archivo cabecera)
Coche y Camion
Enero - 2002
Lovelle
#ifndef VEHICULO_HPP
#define VEHICULO_HPP
#include <iostream>
#include <string>
using namespace std;
3-106
#endif
//fin VEHICULO_HPP
3-107
#include Vehiculo.h
Vehiculo::Vehiculo(void)
{
matricula="N/D";
CV=0;
cout<<"-----------------------------"<<endl;
cout<<"Se ha construido un vehiculo"<<endl;
cout<<"-----------------------------"<<endl;
}
void Vehiculo::verTodo(void)
{
cout<<"Vehiculo de matricula "<<verMatricula();
cout<<" y "<<verCV()<<" CV"<<endl;
}
3-108
Coche::Coche(void)
{
//Llamada implcita al constructor por defecto de Vehiculo
pasajeros=0;
cout<<"------------------------------------"<<endl;
cout<<"Se ha construido un coche"<<endl;
cout<<"------------------------------------"<<endl;
}
void Coche::verTodo(void)
{
Vehiculo::verTodo();
cout<<"con "<<verPasajeros()<<" pasajeros"<<endl;
}
3-109
Camion::Camion(void)
{
//Llamada implcita al constructor por defecto de Vehiculo
carga=0;
cout<<"------------------------------------"<<endl;
cout<<"Se ha construido un camion"<<endl;
cout<<"------------------------------------"<<endl;
}
void Camion::verTodo(void)
{
Vehiculo::verTodo();
cout<<"con "<<verCarga()<<" toneladas de carga"<<endl;
}
3-110
Coche r11;
r11.verTodo();
r11.ponMatricula("4444CAC");
r11.ponCV(8);
r11.ponPasajeros(5);
r11.verTodo();
Coche r21("1234BKR", 12, 5);
r21.verTodo();
Camion pegaso;
pegaso.verTodo();
Camion roco("9876JMC",500,5);
roco.verTodo();
return 0;
}
3-111
#pragma hdrstop
#include <condefs.h>
#include "Vehiculo.h"
//-------------------------------------------------------------------------// Para el uso de getch() se incluye conio
#include<conio>
//-------------------------------------------------------------------------USEUNIT("Vehiculo.cpp");
//-------------------------------------------------------------------------#pragma argsused
int main(int argc, char* argv[])
{
Vehiculo moto;
moto.verTodo();
moto.ponMatricula("O-1234-AS");
moto.ponCV(5);
moto.verTodo();
3-112
Coche r11;
r11.verTodo();
r11.ponMatricula("4444CAC");
r11.ponCV(8);
r11.ponPasajeros(5);
r11.verTodo();
Camion pegaso;
pegaso.verTodo();
Camion roco("9876JMC",500,5);
roco.verTodo();
3-113
3-114
3-115
Implementacin de la herencia en
Java
Vehiculo
3-116
3-117
3-118
virtual
Mamifero
Mamifero()
Mamifero()
Hablar()
Perro
Perro()
Perro()
Hablar()
3-119
Animal.cs
Versin 1.0
Fecha 6-Enero-2003
Autor Juan Manuel Cueva Lovelle
Ejemplo de herencia
using System;
namespace Mascotas
{
/// <summary>
/// La clase animal es la base de una jerarqua de clases
/// </summary>
class Animal
{
protected string nombre="Sin nombre";
/// <summary>
/// Propiedad Nombre
/// </summary>
public string Nombre
{
set {nombre=value;}
get {return nombre;}
}
protected int codigo;
protected static int contador=0;
// Propiedad Edad
protected int edad;
public int Edad
{
set
{
if (value>=0)
edad=value;
else
Console.WriteLine("Edad no vlida");
}
get{return edad;}
}
//Sobrecarga de constructores
public Animal()
{
codigo=contador++;
Console.WriteLine("Se construyo el animal "+nombre);
}
3-120
3-121
"+delfin);
"+ballena);
"+pio);
"+pancho);
"+Animal.VerContador());
}
}
}
3-122
Animal
Mamifero
Reptil
Ave
Perro
3-123
Sirena
Centauro
?
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-124
3-125
3-126
Ejemplo: Sirena::Chica::cabeza,Sirena::Pez::cabeza
A
C
B
D
Debe tener la clase que hereda de ambas una sola copia o muchas
copias de la estructura de la clase compartida ?
Algunos lenguajes prohiben la herencia repetida (Eiffel)
C++ permite al programador que decida. Si las clase comn es virtual no
aparecen copias. Si no es virtual se producen copias repetidas, siendo
necesaria la calificacin explcita para resolver la ambigedad al elegir las
copias
Ejemplo: si virtual class A {} una sola copia.
La herencia mltiple se sobreutiliza a menudo y es utilizada de forma
inadecuada por principiantes
Algunos lenguajes orientados a a enseanza (por ejemplo Object Pascal)
no permiten herencia mltiple obligando al principiante a utilizar siempre
herencia simple. Java y C# slo tiene herencia simple, sin embargo tiene
implementacin mltiple de interfaces
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-127
Riesgos de la herencia
[COAD 97, pp. 53]
3-128
UBICACIN
SLIDO
ESFERA
CILINDRO
TOROIDE
3-129
Interfaces
3-130
Interfaces en UML
Veleta
ISensor
Termmetro
ISensor
<<interface>>
Isensor
estereotipo
Realizacin (forma expandida)
Activar()
Calibrar ()
Registrar()
Apagar()
Veleta
operaciones
3-131
Polimorfismo
Es un mecanismo que permite a un mtodo realizar distintas
acciones al ser aplicado sobre distintos tipos de objetos que
son instancias de una misma jerarqua de clases
3-132
Vehculo
-----------anda ( )
Bicicleta
----------anda ( )
#endif
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-133
#include "Vehiculo.h"
void Vehiculo::anda(void)
{
cout<<"andando"<<endl;
};
void Coche::anda(void)
{
cout<<"acelerando"<<endl;
};
void Bicicleta::anda(void)
{
cout<<"pedaleando"<<endl;
};
Vehculo
--------------anda ( )
Coche
------------anda ( )
Bicicleta
----------anda ( )
3-134
Ejemplo de poliformismo
Prueba del mdulo Vehiculo
Versin 1.0: 22-Noviembre-2000
Compilado con g++ (GNU), de la siguiente forma:
g++ -o Prueba.out Prueba.cpp Vehiculo.cpp
Autor: Juan Manuel Cueva Lovelle
#include "Vehiculo.h"
int main()
{
Vehiculo *v[5]; //array de 5 punteros a objetos
v[0]=
v[1]=
v[2]=
v[3]=
v[4]=
new
new
new
new
new
Vehiculo;
Coche;
Bicicleta;
Vehiculo;
Coche;
3-135
//
//
//
//
//
Ejemplo de poliformismo
Prueba del mdulo Vehiculo
Versin 1.0: 22-Noviembre-2000
Compilada con C++Builder 4.0
Autor: Juan Manuel Cueva Lovelle
new
new
new
new
new
Vehiculo;
Coche;
Bicicleta;
Vehiculo;
Coche;
3-136
3-137
Vehculo2
------------anda ( )
Coche
------anda ( )
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
Bicicleta
----------anda ( )
3-138
do {
try {
c=System.in.read();
switch (c){
case 'C': conduce(new Coche()); break;
case 'B': conduce(new Bicicleta()); break;
case 'V': conduce(new Vehiculo2()); break;
case 10:
case 13: break;
default : System.out.println("Ha pulsado el caracter codificado como "+
c +" RECUERDE:Pulse C para crear un coche, B bicicleta, V vehiculo y X salir");
} // Fin del switch
3-139
Sobrecarga
(Overloading)
3-140
Sobrecarga
Restricciones a la sobrecarga de operadores en C++
Operador punto .
Operador resolucin de mbito ::
Operador indireccin .*
Operador ternario ? :
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-141
Sobrecarga
Ejemplo
Vector
x : float
y : float
z : float
nombre : String
Vector( )
Vector( )
+( )
-( )
=( )
verNombre( )
ponX( )
ponY( )
ponZ( )
verVector( )
verVector( )
ponNombre( )
~Vector( )
ponXYZ( )
3-142
class Vector {
protected:
float x, y, z; // vector tridimensional
string nombre;
public:
Vector(void); // Constructores sobrecargados
Vector(float, float, float, string);
Vector operator+(Vector); // Sobrecarga de operadores
Vector operator-(Vector);
Vector operator=(Vector);
void verVector(int); //Sobrecarga de Mtodos
void verVector(void){cout << verNombre();verVector(1);};
string verNombre(void){return nombre;};
void ponX(float unaX){x = unaX;}; // Modificadores
void ponY(float unaY){y = unaY;};
void ponZ(float unaZ){z = unaZ;};
void ponXYZ(float unaX, float unaY, float unaZ)
{x = unaX; y = unaY; z = unaZ;}
void ponNombre(string unNombre){nombre=unNombre;};
~Vector(void);
} ;
#endif
3-143
3-144
3-145
int main(void)
{
Vector a, b(1,2,3,"B"), c(4,5,6,"C");
a.verVector(); b.verVector(); c.verVector();
c = a+b;
c.verVector();
c = a+b+c;
c.verVector();
b.ponX(100); b.ponY(200); b.ponZ(300);
c=b-c;
c.verVector();
a.ponXYZ(10,20,30);
a.ponNombre("A");
c = b = a;
// asignacin mltiple
a.verVector();
c.verVector();
b.verVector();
return 0;
};
3-146
// asignacin mltiple
a.verVector();
c.verVector();
b.verVector();
cout<<"Pulse una tecla para finalizar programa" ;
getch();
return 0;
};
3-147
3-148
Agregacin y composicin
3-149
Agregacin
Composicin
Asociacin
0..1
empresario
*
empleados
Cardinalidad
Roles
3-150
[Joyanes 1996]
// Implementacin en C++
class Ala {...}; // Los ...indican que se ha implementado la clase
class Motor {...};
class TrenDeAterrizaje{...};
class Cabina{...};
class Avion {
Ala *a1, *a2;
Motor *m1, *m2;
TrenAterrizaje *t;
Cabina *c;
...};
3-151
Composicin
Avion
1
1
2
Ala
1
1
TrenAterrizaje
Cabina
2
Motor
// Implementacin en C++
class Ala {...}; // Los ...indican que se ha implementado la clase
class Motor {...};
class TrenDeAterrizaje{...};
class Cabina{...};
class Avion {
Ala a1, a2;
Motor m1, m2;
TrenDeAterrizaje t;
Cabina c;
...};
3-152
class Ala
{
protected:
string codigo;
float envergadura;
public:
Ala(void){codigo="Sin Codigo";envergadura=-1;
cout<<"Se ha construido el Ala:"<<verCodigo()<<endl;};
Ala(string unCodigo, float unaEnvergadura)
{codigo=unCodigo;envergadura=unaEnvergadura;
cout<<"Se ha construido el Ala:"<<verCodigo()<<endl;};
void ponCodigo(string unCodigo) {codigo=unCodigo;};
string verCodigo(void) const {return codigo;};
void ponEnvergadura(float unaEnvergadura){envergadura=unaEnvergadura;};
float verEnvergadura(void)const {return envergadura;};
void verTodo(void)
{cout<<"Ala:"<<verCodigo()<<" Envergadura:";
cout<<verEnvergadura()<<endl;};
~Ala(void)
{cout<<"Se ha destruido el Ala:"<<verCodigo()<<endl;};
};
3-153
class Cabina
{
protected:
string codigo;
float capacidad;
public:
Cabina(void){codigo="Sin Codigo";capacidad=-1;
cout<<"Se ha construido la Cabina:"<<verCodigo()<<endl;};
Cabina(string unCodigo, float unaCapacidad)
{codigo=unCodigo;capacidad=unaCapacidad;
cout<<"Se ha construido la cabina:"<<verCodigo()<<endl;};
void ponCodigo(string unCodigo) {codigo=unCodigo;};
string verCodigo(void) const {return codigo;};
void ponCapacidad(float unaCapacidad){capacidad=unaCapacidad;};
float verCapacidad(void)const {return capacidad;};
void verTodo(void)
{cout<<"Cabina:"<<verCodigo()<<" Capacidad:";
cout<<verCapacidad()<<endl;};
~Cabina(void)
{cout<<"Se ha destruido la cabina:"<<verCodigo()<<endl;};
};
3-154
class Motor
{
protected:
string codigo;
int CV;
public:
Motor(void){codigo="Sin Codigo";CV=-1;
cout<<"Se ha construido el Motor:"<<verCodigo()<<endl;};
Motor(string unCodigo, int unCV){codigo=unCodigo;CV=unCV;
cout<<"Se ha construido el Motor:"<<verCodigo()<<endl;};
void ponCodigo(string unCodigo) {codigo=unCodigo;};
string verCodigo(void) const {return codigo;};
void ponCV(int unCV){CV=unCV;};
int verCV(void)const {return CV;};
void verTodo(void)
{cout<<"Cabina:"<<verCodigo()<<" CV:";
cout<<verCV()<<endl;};
~Motor(void)
{cout<<"Se ha destruido el motor:"<<verCodigo()<<endl;};
};
3-155
class TrenAterrizaje
{
protected:
string codigo;
int numRuedas;
public:
TrenAterrizaje(void)
{codigo="Sin Codigo";numRuedas=-1;
cout<<"Se ha construido el tren de aterrizaje:"<<verCodigo()<<endl;};
TrenAterrizaje(string unCodigo, int unNumRuedas)
{codigo=unCodigo;numRuedas=unNumRuedas;
cout<<"Se ha construido el tren de aterrizaje:"<<verCodigo()<<endl;};
void ponCodigo(string unCodigo) {codigo=unCodigo;};
string verCodigo(void) const {return codigo;};
void ponNumRuedas(int unNumRuedas){numRuedas=unNumRuedas;};
int verNumRuedas(void)const {return numRuedas;};
void verTodo(void)
{cout<<"Tren de Aterrizaje :"<<verCodigo()<<" num. ruedas:";
cout<<verNumRuedas()<<endl;};
~TrenAterrizaje(void)
{cout<<"Se ha destruido el tren de aterrizaje:"<<verCodigo()<<endl;};
};
#endif
//fin ELEMENTOS_AVION_HPP
3-156
//fin AVION_AGREGADO_HPP
3-157
de la Clase Avion
3-158
Aqu el autor decide destruir los agregados en el destructor de la clase contenedora (Avion), pero
podra no ser as. Si se utilizase solamente el constructor donde se pasan los punteros a los
objetos, sera ms razonable, que se destruyeran externamente a la clase contenedora.
3-159
3-160
#include "AvionAgregado.h"
int main()
{
Avion picosEuropa;
picosEuropa.verTodo();
Avion colloto("AlaIzda",100,"AlaDcha",100,
"m1",500,"m2",500,
"c",1000,
"t",16,
"COLLOTO-ZPAF");
colloto.verTodo();
Ala *ai=new Ala("AlaI",200);
Ala *ad=new Ala("AlaD",200);
Motor *mRollsI=new Motor("RollsI",1000);
Motor *mRollsD=new Motor("RollsD",1000);
TrenAterrizaje *tMichelin=new TrenAterrizaje("Michelin",16);
Cabina *cAirBus500=new Cabina("CAirBus500",250);
Avion carbayonia (ai,ad,mRollsI,mRollsD,tMichelin,cAirBus500,
"CARBAYONIA-GABI");
carbayonia.verTodo();
return 0;
}
3-161
3-162
3-163
#include "ElementosAvion.h"
class Avion
{
protected:
Ala a1, a2;
Motor m1, m2;
TrenAterrizaje t;
Cabina c;
string matricula;
public:
Avion(void);
Avion(string unCodigoAla1, float unaEnvergaduraAla1,
string unCodigoAla2, float unaEnvergaduraAla2,
string unCodigoMotor1, int unosCV1,
string unCodigoMotor2, int unosCV2,
string unCodigoCabina, float unaCapacidad,
string unCodigoTrenAterrizaje, int unNumRuedas,
string unaMatricula);
void ponMatricula(string unaMatricula) {matricula=unaMatricula;};
string verMatricula(void) const {return matricula;};
void verTodo(void);
~Avion(void);
};
#endif
//fin AVION_COMPUESTO_HPP
3-164
(II)
// Mdulo AvionCompuesto.cpp
// Implementacin
de la Clase AvionCompuesto
3-165
(III)
Prueba unitaria de la clase Avion con C++Builder
// Prueba unitaria de la clase Avion (Composicion.cpp)
// Clase Avion componiendo Ala, Cabina, Motor, TrenAterrizaje
// versin 2.0, 25 - Enero - 2002
// autor: J.M. Cueva Lovelle
// Compilado con C++Builder 4.0 en modo consola
#pragma hdrstop
#include <condefs.h>
#include <conio>
#include "AvionCompuesto.h"
//-----------------------------------------------------------------------USEUNIT("AvionCompuesto.cpp");
//-----------------------------------------------------------------------#pragma argsused
int main(int argc, char* argv[])
{
Avion picosEuropa;
picosEuropa.verTodo();
Avion colloto("AlaIzda",100,"AlaDcha",100,
"m1",500,"m2",500,
"c",1000,
"t",16,
"COLLOTO-ZPAF");
colloto.verTodo();
getch();
return 0;
}
3-166
(IV)
#include "AvionCompuesto.h"
int main( )
{
Avion picosEuropa;
picosEuropa.verTodo();
Avion colloto("AlaIzda",100,"AlaDcha",100,
"m1",500,"m2",500,
"c",1000,
"t",16,
"COLLOTO-ZPAF");
colloto.verTodo();
return 0;
}
3-167
(V)
Ejecucin de la prueba unitaria de la clase Avion
3-168
(V)
Ejecucin de la prueba unitaria de la clase Avion
(continuacin)
3-169
Agregacin
Ejemplo en Java
Auto
c : Carroceria
m : Motor
r1 : Rueda
r2 : Rueda
r3 : Rueda
r4 : Rueda
1
1
4
Rueda
1
Motor
1
Carroceria
3-170
Agregacin
Una implementacin en Java ( I )
Clase Carrocera
class Carroceria {
protected String color="Blanco";
protected int numeroSerie;
protected static int contador;
Carroceria(){
numeroSerie=contador++;
}
Carroceria(String unColor){
this();
color=unColor;
System.out.println("Se ha fabricado una carrocera de color "+
color);
}
public String verColor() {
return color;
}
public int verNumeroSerie(){
return numeroSerie;
}
public static int verContador(){
return contador;
}
} //Fin de la clase Carrocera
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-171
Agregacin
Una implementacin en Java ( II )
Construccin de la clase Auto por composicin de objetos de
las clases Carrocera, Motor y Rueda
class Motor {} //Implementacin vaca
class Rueda {} //Implementacin vaca
public class Auto {
protected Carroceria c;
protected Motor m;
protected Rueda r1,r2,r3,r4;
Auto(){
c = new Carroceria();
m = new Motor();
r1 = new Rueda();
r2 = new Rueda();
r3 = new Rueda();
r4 = new Rueda();
}
Auto(String unColor){
c = new Carroceria(unColor);
m = new Motor();
r1 = new Rueda();
r2 = new Rueda();
r3 = new Rueda();
r4 = new Rueda();
}
public String toString(){
String describe = "Auto con carroceria de color "
+ c.verColor()+'\n'
+ "y nmero de serie " + c.verNumeroSerie();
return describe;
}
3-172
Agregacin
Una implementacin en Java ( III )
Prueba unitaria de la clase Auto
3-173
Abstraccin
Encapsulacin y ocultacin de la informacin
Modularidad
Jerarqua (herencia, polimorfismo y agregacin)
Elementos secundarios
Elementos relacionados
Componentes
Patrones de diseo
3-174
3-175
3-176
3.9 Concurrencia
Es la propiedad que distingue un objeto
activo de uno que no est activo [Booch 94]
3-177
Concurrencia
La concurrencia se centra en la abstraccin de hilos
(threads) y en la sincronizacin
Los objetos pueden adquirir estas propiedades
El diseo orientado a objetos puede construir
modelos como un conjunto de objetos cooperativos,
algunos de los cuales son activos y sirven as como
centros de actividad independiente
La mayor parte de los sistemas operativos actuales
dan soporte a la concurrencia (UNIX, Linux, OS/2,
familia Windows: NT, 95, 2000, XP,...)
La concurrencia es una caracterstica intrnseca de
ciertos lenguajes de programacin (Java)
En Ada las tareas (task)
En Smalltalk la clase Process
En otros es una caracterstica aadida por medio de
bibliotecas, por ejemplo C++ y la biblioteca de
tareas de AT&T con las clases Sched, Timer, Task
y otras
En ltimo caso pueden utilizarse interrupciones si el
sistema operativo no tiene concurrencia (MS-DOS)
3-178
3.10 Persistencia
Es la propiedad de un objeto por la que su existencia
transciende el tiempo (es decir, el objeto contina existiendo
despus de que su creador deja de existir) y/o el espacio (es
decir, la posicin del objeto vara con respecto al espacio de
direcciones en el que fue creado) [Booch 94]
3-179
Persistencia
La persistencia conserva el estado de un
objeto en el tiempo y en el espacio [Booch 94]
La persistencia implica ms que la mera
duracin de los datos, no slo persiste el
estado del objeto, sino que su clase debe
trascender a cualquier programa individual,
de forma que todos los programas
interpreten de la misma manera el estado
almacenado
Los lenguajes orientados a objetos ofrecen
el soporte de la persistencia por medio de
algn artilugio (almacenamiento de clases
y datos,)
El almacenar objetos en ficheros es una
solucin ingenua para la persistencia, pues
los objetos no son slo datos
El principal problema es que los sistemas
operativos actuales estn basados en
ficheros
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-180
Serializacin
Serializable{Abstract}
Serializable
write()
read()
writeObject()
readObject()
Perro
Gato
3-181
3.11 Distribucin
Computacin de objetos distribuidos (Distributed
Object Computing, DOC)
Es un paradigma de computacin que distribuye
objetos de cooperacin a travs de una red
heterognea y permite que los objetos interoperen
como un todo unificado
3-182
Distribucin
Beneficios de los objetos distribuidos [Orfali 1996]
Independencia de la plataforma y sistema operativo
3-183
OMG : CORBA
Microsoft
URL http:://www.omg.org
CORBA
.NET Remoting
3-184
Distribucin
Terminologa
URL http:://www.omg.org
3-185
3-186
Aplicaciones especficas
no estndar
Application Interfaces
Aplicaciones
especficas de un dominio
Domain Interfaces
Interfaces
horizontales
Common Facilities
Interfaces de
servicios
generales
Object Services
3-187
3-188
Implementaciones de
CORBA
Orbix
NEO
Orb Plus
DSOM
M3
VisiBroker
PowerBroker
DAIS
D.O.M.E.
IONA Technologies
SunSoft
HP
IBM
BEA
Borland
ExperSoft
ICL
OOT
3-189
Qu se encuentra en un ORB?
Compilador IDL
gridC.cc
Parte Stub cliente
gridS.cc
Parte Skeleton servidor
ORB Runtime
ORB server
library
Componente Activacin
3-190
IDL
IDL
IDL
compiler
compiler
Client
stub
Desarrollo
Desarrollo del
del Servidor
Servidor
IDL
IDL
compiler
compiler
Server
skeleton
Client
Server
3-191
width
height
get(row,col)
set(row,col,value)
Server
1
5
21
89
2 3
8 13
34 55
144233
Grid object
Un Interfaz IDL
interface Grid {
readonly attribute short height;
readonly attribute short width;
void set(in short row, in short col,in long value);
long get(in short row, in short col);
};
grid.idl
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-192
Compilando a C++
grid.idl
grid.hh
common
declarations
Client
Server
gridC.cc
client stubs
gridS.cc
server skeleton
ORB client
library
ORB server
library
Ejecucin
target object
p->height();
Client
Server
gridC.cc
client stubs
gridS.cc
server skeleton
ORB client
library
ORB server
library
3-193
grid.
grid.hh
hh
grid.hh
<
iostream.h>
.h>
iostream
<iostream.h>
main () {
Grid_
_var p;
Grid
Grid_var
p
get(2,4) << endl;
endl;
grid[2,4]
p->get(2,4)
};
Cmo trabaja?
Servidor
Cliente
p->height();
Llamadas
remotas
CORBA
1 2 3
5 8 13
21 34 55
89 144233
Implementacin Grid
3-194
class grid_i
{
short m_height, m_width;
public:
height(...);
width(...);
set(...);
get(...);
}
3-195
try {
//Dar el control al ORB
CORBA::Orbix.impl_is_ready();
1 2 3
5 8 13
21 34 55
89 144233
Objeto Grid
} catch { .... }
cout << Servidor finalizado
<< endl;
}
Qu es un server mainline?
Un servidor es el lugar donde los objetos viven
El server mainline es el cdigo que:
Crea los objetos iniciales en el servidor
Da el control al ORB para recibir peticiones
3-196
Registrando el servidor
3-197
3.12 Genericidad
Es la propiedad que permite construir abstracciones modelo
(clases genricas) para otras clases. El modelo puede
parametrizarse con otras clases, objetos y/o operaciones.
[Booch 94]
3-198
TemplateVector.h
Ejemplo de uso de plantillas
Versin 2.0, 1 - Diciembre - 2002
Autor: J.M. Cueva Lovelle
Vector
UML
3-199
PlantillaVector.cpp
Ejemplo de uso de templates
Versin 2.0, 1 - Diciembre - 2002
Autor: J.M. Cueva Lovelle
Compilado con gcc de GNU
$g++ -o PlantillaVector.out PlantillaVector.cpp
-----------------------------------
#include <iostream>
using namespace std;
#include "TemplateVector.h"
int main()
{
Vector<int> x(10);
//Crea un vector con 10 enteros
for (int i = 0; i < x.verTamagno(); ++i)
{
x[i] = i;
// Inicializa el vector.
cout<<x[i]<<endl; // Escribe el vector
}
return 0;
}
3-200
3-201
3-202
//
//
//
//
//
//
ContenedorVector.cpp
Uso del contenedor <vector> de la biblioteca estndar
Versin 2.0, 1 - Diciembre - 2002
Autor: J.M. Cueva Lovelle
Compilado con gcc de GNU
-----------------------------------
#include <iostream>
#include <vector>
//Para usar el contenedor vector
using namespace std;
int main()
{
vector<int> x(10);
for (unsigned i = 0;
{
x[i] = i;
cout<<x[i]<<endl;
}
return 0;
}
3-203
//
//
//
//
//
//
ContenedorVector.cpp
Uso del contenedor <vector> de la biblioteca estndar
Versin 2.0, 1 - Diciembre - 2002
Autor: J.M. Cueva Lovelle
Compilado con C++ Builder 4.0
-----------------------------------
#pragma hdrstop
#include <condefs.h>
#include <conio>
#include <iostream>
#include <vector>
//Para usar el contenedor vector
using namespace std;
#pragma argsused
int main(int argc, char* argv[])
{
vector<int> x(10);
//Crea un vector con 10 enteros
for (unsigned i = 0; i < x.size(); ++i)
{
x[i] = i;
// Inicializa el vector.
cout<<x[i]<<endl; // Escribe el vector
}
getch();
return 0;
}
3-204
3-205
3-206
3-207
EJECUCIN
Ha nacido el pingino Pigui
Atrapada una excepcin: Pigui dice aah ...me caigo
Paracaidas abierto
Ha muerto el pingino Pigui
Se ha matado a una ave
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-208
//para entrada/salida
#include <string>
public:
virtual void volar(void)=0;
3-209
#include "Aves.h"
#pragma argsused
int main(int argc, char* argv[])
{
Pinguino pigui("Pigui");
try
{
pigui.volar();
} catch(exception& e)
{
cout<<"Atrapada una excepcin: "<<e.what()<<endl;
pigui.abrirParacaidas();
}
getch();
return 0;
} // Fin del main
3-210
3-211
3-212
Abstraccin
Encapsulacin y ocultacin de la informacin
Modularidad
Jerarqua (herencia, polimorfismo y agregacin)
Elementos secundarios
Elementos relacionados
Componentes
Patrones de diseo
3-213
3.14 Componentes
Un componente es un elemento de software que por una parte debe
ser suficientemente pequeo para crearse y mantenerse y por otra
suficientemente grande para poder utilizarse, adems debe tener
interfaces estndar para que sea interoperable [Orfali 96]
3-214
Componentes
Un componente es una entidad funcional
que est completamente caracterizada por
sus entradas y salidas
Un componente puede usarse y
comprobarse como una unidad,
independiente del contexto en el que se
est usando eventualmente
La implementacin interna de un
componente est oculta al usuario
Un componente est formado por
Propiedades
Mtodos
Eventos
3-215
Propiedades
3-216
Mtodos
Los mtodos de un componente
funcionan como lo hara
cualquier mtodo de una clase
de C++
Cada mtodo proporciona un
comportamiento de un
componente, ya que obligan al
componente a realizar una
accin
3-217
Eventos o sucesos
Un evento es alguna accin
producida por el usuario o por
actividades internas del sistema
Ejemplos:
pulsar el ratn
llamar a un mtodo
modificar el valor de una propiedad
3-218
Manejo de eventos
Es el cdigo el que responde al evento
cuando ste ocurre
El programador escribir el cdigo
adecuado para responder a cada evento
click
click
3-219
Tipos de componentes
[Szyperski 1997 ] [Chauvet 1997 ][Charte 2001]
ActiveX
Es un nuevo tipo de componentes desarrolado por Microsoft para la mquina virtual CLR
VCL Componentes desarrollados por Borland para trabajar con sus compiladores (Delphi,
C++Builder) para la familia de sistemas operativos Windows.
Las herramientas de Borland permiten transformar los componentes VCL en ActiveX o utilizar
directamente los ActiveX en Windows
Java Beans
Son los componentes de Sun para Java que se aadieron a Java en Octubre de 1996
Slo pueden utilizarse en Java aunque bajo cualquier sistema operativo.
Los componentes Java Beans se caracterizan por
Propiedades
Eventos
Mtodos
Introspeccin (Introspection)
Personalizacin (Customization)
Persistencia
3-220
C++ Builder
Producto de Borland caracterizado por
Compilador de C++ ANSI
Desarrollo rpido de aplicaciones (RAD, Rapid Application Development) para entornos
Windows 95/NT
Entorno de desarrollo basado en componentes ActiveX y componentes VCL (Visual
Component Library)
Permite crear componentes
Tiene componentes para el manejo de bases de datos relacionales
Incluye extensiones a C++ para facilitar el desarrollo
3-221
3-222
3-223
Componente botn
Los componentes se arrastran y se insertan en las fichas
(Form), tanto si su funcin es visual o si no lo es.
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-224
Agregacin de componentes
Para agregar un botn se selecciona un botn del panel y se arrastra a la ficha
3-225
3-226
3-227
click
click
3-228
3-229
//----------------------------------------------------------------#ifndef Unit1_1aH
#define Unit1_1aH
//----------------------------------------------------------------#include <vcl\Classes.hpp>
#include <vcl\Controls.hpp>
#include <vcl\StdCtrls.hpp>
#include <vcl\Forms.hpp>
//-----------------------------------------------------------------class TVentanaPrincipal : public TForm
{
__published:
// IDE-managed Components
TButton *BotonVerde;
TButton *BotonRojo;
TButton *BotonSalir;
TButton *BotonAzul;
TButton *BotonRestaurar;
void __fastcall BotonVerdeClick(TObject *Sender);
void __fastcall BotonRojoClick(TObject *Sender);
void __fastcall BotonSalirClick(TObject *Sender);
void __fastcall BotonAzulClick(TObject *Sender);
void __fastcall BotonRestaurarClick(TObject *Sender);
private: // User declarations
public:
// User declarations
__fastcall TVentanaPrincipal(TComponent* Owner);
};
//----------------------------------------------------------------extern TVentanaPrincipal *VentanaPrincipal;
//----------------------------------------------------------------#endif
3-230
3-231
//--------------------------------------------------------------------------#include <vcl\vcl.h>
#pragma hdrstop
//--------------------------------------------------------------------------USEFORM("Unit1_1a.cpp", VentanaPrincipal);
USERES("CBuilder1_1.res");
//--------------------------------------------------------------------------WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
try
{
Application->Initialize();
Application->CreateForm(__classid(TVentanaPrincipal), &VentanaPrincipal);
Application->Run();
}
catch (Exception &exception)
{
Application->ShowException(&exception);
}
return 0;
}
//---------------------------------------------------------------------------
3-232
3-233
3-234
3-235
Estructurales (Structural). Describen como organizar diferentes tipos de objetos para que puedan trabajar juntos.
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Comportamiento (Behavioral). Estos patrones se utilizan para organizar, gestionar y distribuir comportamientos.
Chain of Responsability
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
3-236
De clases.
De objetos.
Factory Method
Prototype
Adapter
Singleton
Interpreter
Abstract Factory
Template Method
Builder
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
3-237
Propsito
Garantiza que una clase slo tenga una
instancia
Proporciona un nico punto de acceso
global a ella
Se puede extender mediante herencia
3-238
Estructura de la solucin
Singleton
_instancia : Singleton *
otrosDatosSingleton
Singleton()
crearInstancia() : Singleton *
OtrasOperaciones()
crearInstancia()
return nicaInstancia
Ejemplo
Teclado
_instancia : Teclado*
Teclado() : Teclado*
Instancia() : Teclado*
leeCadena() : String
leeEntero() : Integer
Instancia()
return nicaInstanc ia
3-239
Teclado.h
Contiene la clase Teclado
Ejemplo del patrn de diseo Singleton (nico)
Autor: Juan Manuel Cueva Lovelle
Versin 1.0: 8 - Diciembre - 2002
#ifndef TECLADO_HPP
#define TECLADO_HPP
#include <iostream>
#include <string>
#include <stdlib.h> //para usar atoi()
using namespace std;
class Teclado
{
private:
static Teclado* _instancia;
protected:
Teclado (){cout<<"Creado teclado"<<endl;};
public:
static Teclado* Instancia();
string leeCadena(){cout<<"Dame una cadena:";
string cadena;
cin>>cadena;
return cadena;};
int leeEntero(){cout<<"Dame un entero:";
int entero;
string cadena;
cin>>cadena;
//Conversin de cadena a entero
//El mtodo c_str() pasa objetos string a char*
entero=atoi(cadena.c_str());
return entero;};
};
#endif
3-240
Teclado.cpp
Contiene la implementacin de la clase Teclado
Ejemplo del patrn de diseo Singleton (nico)
Autor: Juan Manuel Cueva Lovelle
Versin 1.0: 8 - Diciembre - 2002
#include "Teclado.h"
Teclado* Teclado::_instancia=0;
Teclado* Teclado::Instancia(void){
if (_instancia==0){
_instancia =new Teclado;
}
else
{cout<<"No se puede crear otro teclado, es el mismo"<<endl;};
return _instancia;
}
3-241
//
//
//
//
//
#pragma hdrstop
#include "Teclado.h"
#include <conio>
#pragma argsused
int main(int argc, char* argv[])
{
{
Teclado* miTeclado = Teclado::Instancia();
cout<< miTeclado->leeCadena()<<endl;
cout << miTeclado->leeEntero()<<endl;
}
Teclado* otroTeclado = Teclado::Instancia();
// Sigue siendo el mismo teclado
cout << otroTeclado->leeCadena()<<endl;
cout << otroTeclado->leeEntero()<<endl;
getch();
return 0;
}
3-242
// PruebaPatronSingleton.cpp
// Ilustra la prueba unitaria de un patrn singleton
// Autor: Juan Manuel Cueva Lovelle
// Versin 1.0: 8 - Diciembre - 2002
// Compilado con g++ versin 2.96 (www.gnu.org)
// $ g++ -o PruebaPatronSingleton.out PruebaPatronSingleton.cpp Teclado.cpp
//--------------------------------------------------------------------------#include "Teclado.h"
int main()
{
{
Teclado* miTeclado = Teclado::Instancia();
cout<< miTeclado->leeCadena()<<endl;
cout << miTeclado->leeEntero()<<endl;
}
Teclado* otroTeclado = Teclado::Instancia();
Ejecucin de la prueba
Creado teclado
Dame una cadena:qwerty
qwerty
Dame un entero:5
5
No se puede crear otro teclado, es el mismo
Dame una cadena:5
5
Dame un entero:555
555
3-243
3.16 Reutilizacin
[Meyer 97]
Premisas
Beneficios
Reduccin de tiempos
Decremento del esfuerzo de mantenimiento
Fiabilidad
Qu se debe reutilizar?
Eficiencia
Consistencia
Proteccin de la inversin en desarrollos
La regla de la reutilizacin
Personal (formacin)
Diseos y especificaciones (Patrones de Diseo)
Cdigo fuente (componentes, herencia y genericidad)
Mdulos abstractos (frameworks)
3-244
Precondiciones y post-condiciones
[Meyer 97]
Factores de calidad
Correccin (Comprobacin de aserciones)
Robustez (Manejo de excepciones)
Asertos o aserciones
son expresiones booleanas (con algunas extensiones) que
manejan entidades software comprobando algunas
propiedades que estas entidades pueden satisfacer en
ciertas etapas de la ejecucin del software.
Precondiciones y post-condiciones
Son dos aserciones asociadas a cada mtodo de una clase
Precondicin: comprueba el estado de las propiedades que
se deben cumplir antes de la ejecucin del mtodo.
Post-condicin: comprueba el estado de las propiedades
que se deben cumplir despus de la ejecucin del mtodo.
El lenguaje Eiffel tiene dos secciones en cada mtodo para
precondiciones (require) y post-condiciones (ensure)
Ejemplos: sea una Pila con los mtodos push y pop
3-245
Invariantes de clase
Son aserciones que capturan las propiedades semnticas
profundas y la integridad de las restricciones que
caracterizan la clase
Ejemplo de invariante de una Pila: vaca=(contador=0)
El lenguaje Eiffel tiene la seccin invariant que se coloca
antes del final de cada clase
Juan Manuel Cueva Lovelle - www.ootlab.uniovi.es
3-246
Frameworks
3-247
Frameworks
Un framework (marco estructural) es un
conjunto de bibliotecas de clases preparadas
para la reutilizacin, que pueden utilizar a su
vez componentes.
Ejemplos
o www.junit.org (Pruebas de Software)
o www.jhotdraw.org (Editor de dibujo)
o .NET Framework (Base de la plataforma .NET)
3-248
Lenguajes O O
Mtodos y metodologas
Distribucin
Componentes
Ingeniera Web
Sistemas Operativos O O
Bases de datos Orientadas a
Objetos
Interfaces de usuario
3-249
Resumen
Beneficios del modelo de objetos
Ayuda a explotar la potencia expresiva de los
lenguajes de programacin orientados a objetos,
aunque algunas caractersticas del modelo de
objetos no estn soportadas.
Promueve la reutilizacin. No slo de software
aislado, sino tambin de diseos enteros
(frameworks)
Produce sistemas que se construyen con formas
intermedias estables
Facilita la comunicacin con personas que son
ajenas a la Informtica
3-250
2.
3.
4.
5.
6.
7.
8.
9.
10.
3-251
12.
13.
14.
15.
16.
Uno de los problemas de la herencia mltiple es la herencia repetida A) Ocurre cuando una clase
hereda de dos o ms clases que a su vez heredan de una clase que es un antepasado comn a
ambas B) Algunos lenguajes prohiben la herencia repetida (Eiffel) C) En C++ se permite la
herencia repetida D) Todas las afirmaciones anteriores son correctas E) Ninguna respuesta anterior
es correcta
ActiveX es un tipo de componente que A) puede utilizarse en cualquier sistema operativo B) puede
utilizarse por distintos lenguajes de programacin C) puede convertirse en un Java Beans D) Todas
las respuestas son correctas E) Ninguna respuesta anterior es correcta
Indicar cual de los siguientes lenguajes es un lenguaje orientado a objetos puro A) C++ B) ADA95
C) Object Pascal D) Java E) Ninguno es orientado a objetos puro.
El principio de modularidad denominado abierto cerrado, se enuncia como A) Los mdulos deben
ser simultneamente abiertos y cerrados B) Cuando un mdulo responde a requisitos que cambian
C) Cuando se emplean medios extraordinarios para mantener en una operacin de un mdulo D)
Todas las afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta1.
La Repblica Manzanera Vetustosa desea reconvertir el hpico del Molinn en una lechera,
encargando un proyecto de software para la gestin del ganado vacuno para la produccin de leche.
Despus de un anlisis Orientado a Objetos concienzudo por parte la empresa Chapuzosa se ha
generado la siguiente lista de clases para representar los objetos del dominio del problema: Vaca,
Toro, Novilla, Ganadero, Establo, Inseminar, Reproducir, Fecha, Ordear,... Si se nos pide que
asesoremos a Chapuzosa Qu clases de las siguientes eliminaramos por no representar objetos
del dominio de problema? A) Toro, Novilla B) Ganadero C) reproducir, inseminar, ordear D) Todas
son correctas E) Ninguna es correcta
La clase Vaca se ha diseado de la forma que se refleja en el siguiente cdigo C++
class Vaca {
protected:
float peso;
Fecha nacimiento, ultima_inseminacion, ultimo_parto;
public:
Vaca();
void pon_peso (float unpeso);
float ver_peso();
...
}
Respecto del diseo de los atributos de la clase Vaca se puede decir A) Quedan ocultos para los
objetos de las clases que heredan de Vaca B) No permite a los objetos Vaca tener identidad C) No
permite a los objetos Vaca tener estado D) Todas las respuestas anteriores son correctas E)
Ninguna respuesta anterior es correcta
17.
Las vacas estn en establos, y en cada establo est un servidor que se encarga de manejar todos
los objetos del establo. Usted como asesor/a recomienda A) comprar un Object Request Broker B)
Seguir el estndar definido por OMG C) Organizar los establos con el paradigma de objetos
distribuidos siguiendo CORBA D) Todos las consejos anteriores son vlidos y compatibles entre s
E) Ningn consejo anterior es aceptable
18.
Ante los xitos alcanzados se desean introducir establos de otros animales que producen leche:
Cabras, Ovejas, Buffalas, ... Se desea construir una clase genrica para describir los objetos que
producen leche, usted aconsejara A) Utilizar polimorfismo B) Usar un template C) Crear una clase
abstracta de la que hereden las clases que producen leche D) Todos los consejos anteriores
conducen a la genericidad E) Ninguna respuesta anterior es cierta
19.
Si un programador de la empresa Chapuzosa construye una clase Bicho_raro que hereda de forma
mltiple de Vaca, Cabra y Oveja. Suponiendo que se ha definido el atributo patas a cada uno de
estas clases . Cuntas patas tiene los objetos de la clase Bicho_raro? A) 4 B) 8 C) 12 D) No tiene
patas E) Ninguna respuesta es vlida.
20.
Alguien ha contado a los de Chapuzosa que lo mejor es que usen patrones de diseo, usted les
explica A) Que son un framework potente B) Representan clases abstractas puras C) Son
soluciones a problemas en un contexto particular y que se pueden reutilizar D) Todas las respuestas
anteriores son correctas E) Todas las respuestas anteriores son falsas
3-252
Respuestas de auto-evaluacin
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
B)
D)
E)
D)
E)
E)
D)
D)
B)
D)
D)
E)
D)
A)
C)
B)
D)
D)
C)
C)
3-253
Lecturas recomendadas
3-254
Referencias
[Arnold 1998] K. Arnold and J. Gosling. The Java Programming Language. Second edition. Addison Wesley,
1998
[Baker 97 ] S. Baker.CORBA Distributed Objects. Addison-Wesley, 1997.
[Booch 94] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings (1994).
Versin castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de
Santos (1996).
[Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide. Addison-Wesley
(1999). Versin castellana El lenguaje unificado de modelado. Addison-Wesley (1999)
[Buschman 1996 ] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, M. Stal. PatternOriented software architecture. Volume 1. Wiley, 1996.
[Buschman 2000 ] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, M. Stal. PatternOriented software architecture. Volume 2. Wiley, 2000.
3-255
Tema 4
Clases y objetos
4-1
Implementacin de
clases y objetos
Se implementar una clase Cola
que se ir refinando en
sucesivas versiones
Todas las versiones se compilan
y ejecutan correctamente pero
tienen errores de diseo
En este tema se repasan los
conceptos del tema anterior
desde un punto de vista prctico
4-2
Ejemplo de manejo de la clase cola en C++ con constructores y destructores por defecto
#include <iostream.h>
const Maximo=100;
// Declaracin de la clase cola
// Define como opera una cola de enteros
class cola {
int c[Maximo];
// Por defecto todo es privado
int ultimo, primero; // Indices del array
public:
void inicializa(void);
void meter(int);
int sacar(void);
};
void cola::inicializa()
{
primero = ultimo = 0;
}
void cola::meter(int valor)
{
if(ultimo==Maximo) // Precondicin
{
cout << "La cola est llena\n";
return;
}
ultimo++;
c[ultimo] = valor;
}
int cola::sacar(void)
{
if(ultimo == primero) //Precondicin
{
cout << "La cola est vaca \n";
return 0;
}
primero++;
return c[primero];
}
int main(void)
{
cola a, b; // Se crean dos objetos de la clase cola
a.inicializa();
b.inicializa();
a.meter(10);
b.meter(19);
a.meter(20);
b.meter(1);
cout << a.sacar()
cout << a.sacar()
cout << b.sacar()
cout << b.sacar()
<<
<<
<<
<<
" ";
" ";
" ";
"\n";
4-3
4-4
<<
<<
<<
<<
" ";
" ";
" ";
"\n";
4-5
4-6
4-7
4-8
4-9
//
//
//
//
// Versin 4
#include "cola.hpp"
cola::cola(int id) //Constructor con parmetro
{
primero = ultimo = 0;
identificacion=id;
num_elementos=0;
cout << "El objeto cola "<<identificacion<<" ha sido creado"<<endl;
}
cola::~cola(void) // Se ejecuta automticamente al finalizar el bloque
{
cout << "El objeto cola "<<identificacion<<" ha sido destruido"<<endl;
}
int cola::estaVacia(void)// Mtodo selector
{
if(num_elementos==0) return 1;
else return 0;
}
int cola::estaLlena(void)// Mtodo selector
{
if(num_elementos==Maximo) return 1;
else return 0;
}
void cola::meter(int valor) //Mtodo modificador
// Precondicin: La cola no tiene que estar llena
// Modifica: Almacena valor en la cola
// Postcondicin: La cola tiene un elemento ms
{
if(estaLlena()) //Precondicin
{
cout <<"No se puede introducir el "<< valor;
cout <<" la cola "<<ver_identificacion()<<" est llena"<<endl;
return;
}
int num_elementos_antes=longitud();
cout<<"Introduciendo "<<valor<<" en la cola "<<ver_identificacion()<<endl;
c[ultimo] = valor;
num_elementos++;
ultimo++;
// Si se alcanza el final del array se vuelve al principio
if (ultimo==Maximo) ultimo=0;
//Postcondicin
int num_elementos_despues=longitud();
if (num_elementos_despues!=num_elementos_antes+1)
{
cout <<"Error: La cola "<<ver_identificacion();
cout<<" no tiene un elemento ms"<<endl;
return;
}
}
4-10
int cola::sacar(void)
//Precondicin: La cola no puede estar vacia
//Modifica: Devuelve y elimina de la cola el primer elemento
//Postcondicin: La cola tiene un elemento menos
{
if(estaVacia()) //Precondicin
{
cout << "La cola "<<ver_identificacion()<<" est vaca \n";
return -1;
}
int num_antes=longitud();
int valor=c[primero];
num_elementos--;
primero++;
// Si se alcanza el final del array se vuelve al principio
if (primero==Maximo) primero=0;
cout<<"Sacando "<<valor<<" de la cola "<<ver_identificacion()<<endl;
int num_despues=longitud();
if (num_antes!=num_despues+1) //Postcondicin
{
cout<<"Error: La cola "<<ver_identificacion();
cout<<" no tiene un elemento menos"<<endl;
return -1;
}
return valor;
}
int cola::ver_primero(void)
{
if(estaVacia()) //Precondicin
{
cout << "La cola est vaca \n";
return -1;
}
return c[primero];
}
int cola::ver_ultimo(void)
{
if(estaVacia()) //Precondicin
{
cout << "La cola est vaca \n";
return 0;
}
if (ultimo>0) return c[ultimo-1];
else return c[Maximo-1];
}
4-11
int cola::ver_posicion(int i)
{
if(estaVacia()) //Primera precondicin
{
cout << "La cola est vaca \n";
return -1;
}
if (i>longitud()) //Segunda precondicin
{
cout << "La cola solo tiene "<<longitud()<<endl;
return -1;
}
if(primero+i-1<Maximo) return c[primero+i-1];
else return c[primero+i-1-Maximo];
}
void cola::mostrar_cola(void)
{
cout<<"La cola "<<ver_identificacion()<<" :";
if (estaVacia())
{
cout<<"est vaca"<<endl;
return;
}
for (int i=1; i<=longitud();i++)
cout << ver_posicion(i)<<" ";
cout <<endl;
}
void cola::ver_array(void)
{
for(int i=0;i<Maximo;i++)
cout<<"c["<<i<<"]="<<c[i]<<endl;
}
4-12
4-13
4-14
4-15
#ifndef COLA_HPP
#define COLA_HPP
//---------------------#include <iostream.h>
//----------------------
struct nodo {
int info;
struct nodo *sig;
};
typedef struct nodo NODO;
class cola {
NODO *ultimo, *primero;
int identificacion; //Permite distinguir las colas
int num_elementos;
public:
cola(int);
//Constructor de la clase con un parmetro
~cola(void); //Destructor de la clase.
int estaVacia(void);//Mtodo selector
int longitud(void) {return num_elementos;};//Mtodo selector
void meter(int); //Mtodo modificador
int sacar(void); //Mtodo modificador
int ver_primero(void); //Mtodo selector
int ver_ultimo(void);
//Mtodo selector
int ver_identificacion(void){return identificacion;}; //Mtodo selector
int ver_posicion(int); //Mtodo selector
void mostrar_cola(void); //Mtodo iterador
};
//------------------#endif
4-16
//
//
//
//
// Versin 5
#include "cola.hpp"
cola::cola(int id) //Constructor con parmetro
{
primero = NULL;
ultimo = NULL;
identificacion=id;
num_elementos=0;
cout << "El objeto cola "<<identificacion<<" ha sido creado"<<endl;
}
cola::~cola(void) // Es necesario vaciarla
{
int i;
// Vaciar la cola para liberar memoria
while (!estaVacia()) sacar();
cout << "El objeto cola "<<identificacion<<" ha sido destruido"<<endl;
}
int cola::estaVacia(void)// Mtodo selector
{
if(num_elementos==0) return 1;
else return 0;
}
void cola::meter(int valor) //Mtodo modificador
// Modifica: Almacena valor en la cola
// Postcondicin: La cola tiene un elemento ms
{
int num_elementos_antes=longitud();
cout<<"Introduciendo "<<valor<<" en la cola "<<ver_identificacion()<<endl;
NODO *nuevo;
nuevo=new NODO; //Reserva dinmica de memoria para nuevo
nuevo->info= valor;
nuevo->sig=NULL;
num_elementos++;
if (ultimo==NULL) //Caso de cola vacia
{
ultimo=nuevo;
primero=nuevo;
}
else
//Caso en el que la cola ya tiene elementos
{
ultimo->sig=nuevo;
ultimo=nuevo;
}
//Postcondicin
int num_elementos_despues=longitud();
if (num_elementos_despues!=num_elementos_antes+1)
{
cout <<"Error: La cola "<<ver_identificacion();
cout<<" no tiene un elemento ms"<<endl;
return;
}
}
4-17
int cola::sacar(void)
//Precondicin: La cola no puede estar vacia
//Modifica: Devuelve y elimina de la cola el primer elemento
//Postcondicin: La cola tiene un elemento menos
{
if(estaVacia()) //Precondicin
{
cout << "La cola "<<ver_identificacion()<<" est vaca \n";
return -1;
}
int num_antes=longitud();
NODO *p;
int valor=primero->info;
p=primero;
primero=primero->sig;
delete p;
//Elimina p de la memoria dinmica
if (primero==NULL) ultimo=NULL;
num_elementos--;
cout<<"Sacando "<<valor<<" de la cola "<<ver_identificacion()<<endl;
int num_despues=longitud();
if (num_antes!=num_despues+1) //Postcondicin
{
cout<<"Error: La cola "<<ver_identificacion();
cout<<" no tiene un elemento menos"<<endl;
return -1;
}
return valor;
}
int cola::ver_primero(void)
{
if(estaVacia()) //Precondicin
{
cout << "La cola est vaca \n";
return -1;
}
return primero->info;
}
int cola::ver_ultimo(void)
{
if(estaVacia()) //Precondicin
{
cout << "La cola est vaca \n";
return 0;
}
return ultimo->info;
}
4-18
int cola::ver_posicion(int i)
{
if(estaVacia()) //Primera precondicin
{
cout << "La cola est vaca \n";
return -1;
}
if (i>longitud()) //Segunda precondicin
{
cout << "La cola solo tiene "<<longitud()<<endl;
return -1;
}
NODO *p;
p=primero;
for (int j=1;j<i;j++) p=p->sig;
return p->info;
}
void cola::mostrar_cola(void)
{
cout<<"La cola "<<ver_identificacion()<<" :";
if (estaVacia())
{
cout<<"est vaca"<<endl;
return;
}
for (int i=1; i<=longitud();i++)
cout << ver_posicion(i)<<" ";
cout <<endl;
}
4-19
//
//
//
//
#include "cola.hpp"
int main(void)
{
cola a(1),b(2);
a.meter(10);
b.meter(19);
a.meter(20);
b.meter(1);
a.mostrar_cola();
cout <<"La cola "<<a.ver_identificacion();
cout <<" tiene "<<a.longitud()<<" elementos"<<endl;
cout <<"El ultimo de la cola "<<a.ver_identificacion();
cout <<" es "<<a.ver_ultimo()<<endl;
cout <<"El primero de la cola "<<a.ver_identificacion();
cout <<" es "<<a.ver_primero()<<endl;
a.mostrar_cola();
a.meter(500);
cout <<"La cola "<<a.ver_identificacion();
cout <<" tiene "<<a.longitud()<<" elementos"<<endl;
a.mostrar_cola();
a.meter(1000);
a.mostrar_cola();
cout <<"El ultimo de la cola "<<a.ver_identificacion();
cout <<" es "<<a.ver_ultimo()<<endl;
cout <<"El primero de la cola "<<a.ver_identificacion();
cout <<" es "<<a.ver_primero()<<endl;
cout<<"Sacando elementos de la cola "<<b.ver_identificacion()<<endl;
cout << b.sacar() << endl;
cout << b.sacar() << endl;
b.mostrar_cola();
b.meter(201);
b.meter(202);
b.meter(203);
b.mostrar_cola();
cout<<"Primero "<<b.ver_primero()<<endl;
cout<<"Ultimo "<<b.ver_ultimo()<<endl;
b.sacar();
b.mostrar_cola();
cout<<"Primero "<<b.ver_primero()<<endl;
cout<<"Ultimo "<<b.ver_ultimo()<<endl;
cout <<"La cola "<<b.ver_identificacion();
cout <<" tiene "<<b.longitud()<<" elementos"<<endl;
b.meter(204);
b.mostrar_cola();
cout<<"Primero "<<b.ver_primero()<<endl;
cout<<"Ultimo "<<b.ver_ultimo()<<endl;
cout <<"La cola "<<b.ver_identificacion();
cout <<" tiene "<<b.longitud()<<" elementos"<<endl;
}
4-20
4-21
Comparticin estructural
Se produce cuando la identidad de un objeto recibe
un alias a travs de un segundo nombre
El mismo objeto tiene dos identificadores
En lenguajes como C++ se permite el uso de alias
o referencias
No es aconsejable el uso de alias o de referencias
que no sean parmetros de funciones
4-22
Copia de objetos
Se pretende obtener dos objetos con identificadores
distintos pero con estados iguales
En C++ no debe utilizarse el operador asignacin
(=) para crear copias de objetos, pues para objetos
cuyo estado involucra a punteros a otros objetos,
slo se copia el puntero pero no a lo que apunta el
puntero.
Las soluciones son:
Aadir a la clase constructores de copia
Sobrecargar el operador asignacin en la clase para
que realice la copia correctamente
4-23
4-24
4-25
Genericidad
Notacin de Booch
Cola<int> colaEnteros;
Cola<ElementoPantalla*>colaElementos;
4-26
Metaclases
Una metaclase es una clase cuyas instancias son
clases
Los lenguajes Smalltalk y CLOS soportan
metaclases
Los lenguajes C++, Object Pascal, Ada, Eiffel no lo
soportan
El problema es que se deben crear clases en tiempo
de ejecucin
La notacin de Booch da soporte a las metaclases
con una nube gris y una flecha gris.
4-27
4-28
4-29
Seleccin de operaciones
Eleccin de relaciones
Colaboraciones
Los mtodos de una clase tan slo deben depender de la propia clase
Un mtodo slo debe enviar mensajes a objetos de un nmero limitado
de clases
La jerarqua de herencias puede ser en forma de bosque (debilmente
acopladas) y rboles (acoplamiento fuerte). La jerarqua de herencias
elegida depende del tipo de problema
Mecanismos y visibilidad
4-30
Eleccin de implementaciones
Representacin
La representacin interna de una clase es un secreto
encapsulado de la abstraccin
La eleccin de la representacin es difcil y no unvoca
La modificacin de la representacin interna no debe violar
ninguno de los contratos con los clientes de la clase
Empaquetamiento
Elegir las clases y objetos que se empaquetan en cada mdulo
Los requisitos de ocultacin y visibilidad entre mdulos suelen
guiar las decisiones de diseo
Generalmente los mdulos tienen cohesin funcional y estn
dbilmente acoplados entre s
Hay factores no tcnicos que influyen en la definicin de
mdulos: reutilizacin, seguridad y documentacin.
4-31
Resumen
4-32
Autoevaluacin (I)
Un iterador es A) Una operacin que altera el estado de un objeto B) Una operacin que
accede al estado de un objeto, pero no altera este estado C) Una operacin que permite
acceder a todas las partes de un objeto en algn orden perfectamente establecido D) Todas
las afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta.
Un selector es A) Una operacin que altera el estado de un objeto B) Una operacin que
accede al estado de un objeto, pero no altera este estado C) Una operacin que permite
acceder a todas las partes de un objeto en algn orden perfectamente establecido D) Todas
las afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta.
Un modificador es A) Una operacin que altera el estado de un objeto B) Una operacin que
accede al estado de un objeto, pero no altera este estado C) Una operacin que permite
acceder a todas las partes de un objeto en algn orden perfectamente establecido D) Todas
las afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta.
Un constructor es A) Una operacin que libera el estado de un objeto y/o destruye el propio
objeto B) Una operacin que accede al estado de un objeto, pero no altera este estado C)
Una operacin que permite acceder a todas las partes de un objeto en algn orden
perfectamente establecido D) Todas las afirmaciones anteriores son correctas E) Ninguna
respuesta anterior es correcta.
Un destructor es A) Una operacin que altera el estado de un objeto B) Una operacin que
accede al estado de un objeto, pero no altera este estado C) Una operacin que permite
acceder a todas las partes de un objeto en algn orden perfectamente establecido D) Todas
las afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta.
El tiempo de vida de un objeto A) Se extiende desde que lo crea un constructor hasta que se
destruye por un destructor B) En lenguajes con recoleccin de basura se extiende desde que
se crea hasta que todas las referencias a el objeto se han perdido C) Si el objeto es
persistente el tiempo de vida transciende a la vida del programa que lo crea D) Todas las
afirmaciones anteriores son correctas E) Ninguna respuesta anterior es correcta.
Relaciones entre clases y objetos A) Las clases en C++ son estticas B) Los objetos en C++
son dinmicos C) En C++ todo objeto es instancia de alguna clase D) Todas las afirmaciones
anteriores son correctas E) Ninguna respuesta anterior es correcta.
Un constructor de una clase en C++ A) Siempre existe implcita o explcitamente B) Es una
operacin que accede al estado de un objeto, pero no altera este estado C) Una operacin
que permite acceder a todas las partes de un objeto en algn orden perfectamente
establecido D) Todas las afirmaciones anteriores son correctas E) Ninguna respuesta anterior
es correcta.
Un destructor A) Es una operacin que no existe en los lenguajes con recoleccin de basura
B) No existe en Java C) Siempre existe en C++ D) Todas las afirmaciones anteriores son
correctas E) Ninguna respuesta anterior es correcta
4-33
Autoevaluacin (II)
Sea el siguiente fragmento de cdigo en C++ que esta en un mdulo denominado avion.h
class Ala {...}; // Los ... indican que se ha implementado la clase
class Motor {...};
class TrenDeAterrizaje{...};
class Cabina{...};
class Avion {
Ala *a1, *a2;
Motor *m1, *m2;
TrenDeAterrizaje *t;
Cabina *c;
...}
Se puede decir A) Que la clase Avion hereda de las anteriores B) Que Ala es un mtodo virtual de
la clase Avion C) Que la clase Avion es una agregacin D) Todas las respuestas anteriores
son correctas E) Todas las respuestas son falsas.
Se puede afirmar A) La instruccin Avion A310; es una llamada a un mtodo constructor B) A310
es un objeto C) A310 se crea en tiempo de ejecucin D) Todas las respuestas anteriores son
correctas E) Todas las respuestas anteriores son falsas.
Siguiendo con el cdigo del apartado anterior se puede afirmar A) No se ejecuta el destructor
B) Si se ejecuta el destructor C) Para que se ejecute el destructor debe escribirse
obligatoriamente en C++ D) El objeto A310 es inmortal y no se destruye nunca E) Todas las
respuestas anteriores son falsas.
4-34
Referencias
4-35
Tema 5
5-1
5-2
Requisitos
Anlisis
Integracin
Mantenimiento
5-3
Esfuerzo
Prueba
Diseo
Implementacin
Anlisis
Tiempo
Juan Manuel Cueva Lovelle www.ootlab.uniovi.es
5-4
Anlisis
Documentos de anlisis
Especificacin de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y sub-escenarios
Prototipos
Diagramas de interaccin
Prueba
Diagramas de componentes
Diagramas de despliegue
Implementacin
Diagramas de actividades
Diagramas de estados
Diagramas de secuencia
Diagramas de colaboracin
Mantenimiento
Informes de errores
Nueva especificacin de requisitos. Nueva versin
5-5
5-6
Identificacin
Es necesario identificar todos los
elementos del proceso de desarrollo de
software de una forma unvoca
Todos los documentos deben estar
identificados
Ttulo
debe reflejar de la mejor forma posible sus fines
y su funcionalidad
Descripcin
Autores
Versin. Notacin decimal.
Revisin. Autores
Fecha
Cdigo de cada documento o diagrama
5-7
Documentos de anlisis
5-8
5-9
5-10
5-11
Especificacin de requisitos o
requerimientos
5-12
Ejemplos de requisitos
R.0
Requisitos generales
R.0.1 Tendremos en cuenta trabajar con fechas que codifiquen el ao con cuatro
cifras.
R.0.2 Las unidades monetarias debern poder trabajar con cifras decimales con
vistas al inmediato cambio de moneda que se nos aproxima.
R.1
Gestin de clientes
R.1.0 Requisitos generales de los clientes
R.1.0.1 Los clientes pueden ser fijos o eventuales
R.1.0.2 A los clientes se les asigna un nmero identificativo
R.1.0.3 Los clientes se definen por D.N.I., nombre, direccin, ciudad,
telfono, y departamento.
R.1.1 Aadir clientes
R.1.1.1Solamente los Usuarios con permiso de Administrador podrn aadir
clientes fijos.
R.1.2
Borrado de clientes.
R.1.2.1Solamente los Usuarios con permiso de Administrador podrn borrar
clientes.
R.1.2.2Para poder borrar clientes es necesario que este no tenga ningn
albarn pendiente de facturacin y que estos tengan una antigedad
mayor a cinco aos.
R.1.2.3Tambin es necesario que no tenga ninguna mquina reparndose
5-13
5-14
Caso de uso
Actor 3
Caso de uso 4
Caso de uso 5
Actor 1
Actor
Caso de uso 6
Caso de uso 7
Interaccin
Actor 2
Sistema
5-15
PEDIDOS
INFORMES
AVERIAS
RESERVAS
Responsable
de
mantenimiento
SUGERENCIAS
Responsable
de informtica
INFORME PARA
USUARIO
ACTIVIDAD
Usuario
5-16
2 .I N F O R M E S
T o d o s lo s in fo rm e s q u e s o n n e c e sa rio s p a ra e l fu n c io n a m ie n to d e la
e m p re s a : in fo rm e d e p e d id o , d e a m o rtiz a c io n e s , d e in a c tiv id a d , d e
c o m p o s ic i n d e e q u ip o s b s ic o s, d e c o m p o s ic i n d e o tro s e q u ip o s , d e
in v e n ta rio s o ftw a re y m a n u a le s, d e g a ra n ta s y d e d is p o n ib ilid a d . E s to s
in fo rm e s s o n re a liz a d o s p a ra e l R e s p o n sa b le d e In fo rm tic a .
3 .A V E R I A S
E n g lo b a to d a s ls o p e ra c io n e s re la tiv a s a la s a v e ra s ta n to e l a v is o
q u e p u e d e s e r re a liz a d o p o r c u a lq u ie r a c to r (R e s p o n s a b le d e In fo rm tic a , d e
M a n te n im ie n to o U s u a rio ) , c o m o e l p a rte d e a v e ra q u e e s re a liz a d o p o r e l
R e s p o n sa b le d e M a n te n im ie n to y e n tre g a d o a l R e s p o n sa b le d e In fo rm tic a .
4 .R E S E R V A S
E s ta n to la p e tic i n d e re s e rv a d e u n e q u ip o c o n u n a s c a ra c te rs tic a s
d e te rm in a d a s , q u e p u e d e s e r re a liz a d a p o r c u a lq u ie r u su a rio a l R e s p o n s a b le
d e In fo rm tic a , c o m o la c o n c e s i n d e u n a re s e rv a q u e re a liz a e ste ltim o a
u n u su a rio .
5 .S U G E R E N C I A S
E s u n a ln e a d e c o m u n ic a c i n e n tre lo s d ife re n te a g e n te s q u e
in te ra c c io n a n c o n e l s iste m a .
6 .I N F O R M E S P A R A E L U S U A R I O
E s u n in fo rm e e s p e c ia lm e n te re a liz a d o p a ra e l u s u a rio d o n d e e s te
p u e d e e n c o n tra r to d a la in fo rm a c i n q u e p u e d a n e c e s ita r e n u n m o m e n to
d e te rm in a d o s o b re u n e q u ip o , s u d is p o n ib ilid a d , so ftw a re o u n m a n u a l.
7 .A C T I V I D A D
R e a liz a d o p o r e l R e sp o n s a b le d e In fo rm tic a e n g lo b a to d o lo
re la tiv o a l b u e n fu n c io n a m ie n to d e l m a te ria l d e la e m p re sa : d a r d e b a ja
te m p o ra lm e n te u n e q u ip o c u a n d o e s ta e n re p a ra c i n , d a r d e b a ja
p e rm a n e n te m e n te u n e q u ip o c u a n d o n o tie n e a rre g lo y a c tu a liz a r ta n to
s o ftw a re c o m o lo s m a n u a le s .
5-17
Sistema Servidor
Bases de Datos
Administrador
Sistema Cliente
Administracin
Gestin albaranes
Gestin de clientes
Gestin mquinas
Gestin proveedores
Dependiente
Gestin pedidos
Gestin almacn
Gestin reparaciones
Gestin taller
Mecnico
Consultas
5-18
Descripcin de actores
Nombre de Actor: Administrador
Definicin: Es el encargado de administrar el sistema. Tendr todos
los permisos y libertad de movimientos por el sistema.
Notas:
El administrador es el encargado de manipular la
informacin contenida en el sistema.
Tiene acceso a toda la informacin del sistema y es el
nico que puede modificar todo lo que le de la gana..
Nombre de Actor: Mecnico
Definicin: Es el encargado de realizar las oportunas reparaciones en
las mquinas y a su criterio y valoracin queda el tomar
las decisiones oportunas respecto a que reparacin y si es
necesario o no el ingreso de la mquina en el taller.
Notas:
No lo encajamos en la figura de una persona concreta
sino que pueden ser varias personas las que puedan
encargarse de esta tarea.
El mecnico solo tiene acceso a la parte del sistema
referente a las mquinas a las reparaciones y al las
consultas, el acceso al resto le est vedado.
Dentro de la parte del sistema al que puede acceder no
se le permite el borrado de informacin, solo, aadir y
modificar.
Nombre de Actor: Dependiente
Definicin: Es la persona que est en contacto directo con los
clientes. Tiene acceso limitado a las operaciones del
sistema.
Notas:
El dependiente no podr dar de alta a clientes fijos,
pero si a clientes eventuales.
No podr borrar clientes, ni mquinas, ni artculos, ni
reparaciones.
No tiene acceso a la gestin de proveedores ni del taller
5-19
Sistemas
SISTEMA SERVIDOR
El Sistema Servidor, (en nuestro caso particular) estar formado por una mquina
Windows NT Server (tambin podra ser una mquina Unix) que ser atacado por sistemas
Clientes constituidos por mquinas Windows 95 Windows NT.
El gestor de la base de datos (CTSQL de MultiBase...), junto a la propia base de
datos, se encuentran en el servidor UNIX o Windows NT ( solo para el CTSQL).
Existir tambin la posibilidad de configurarlo en una sola mquina en Windows 95
Windows NT, en cuyo caso los programas de la aplicacin, el gestor de la base de datos y
la base de datos residiran en la misma mquina Windows.
SISTEMAS CLIENTES
Los programas de la aplicacin residen en la mquina cliente Windows95 o
Windows NT que atacan al servidor donde se encuentra instalada el gestor de la base de
datos junto con la base de datos correspondiente.
INTERFACES
INTERFAZ ADMINISTRADOR
El interfaz del Administrador le permite acceder a todas las opciones que presenta la
aplicacin
INTERFAZ DEPENDIENTE
El Dependiente solamente tendr acceso a algunas de las funciones que soporta la
aplicacin y dentro de estas su capacidad de maniobra estar limitada
INTERFAZ MECNICO
El mecnico tendr acceso solamente a las reparaciones y a la gestin del taller
adems de las consultas.
5-20
Los
de
su mantenimiento
reparacin.
Notas: Las mquinas vienen definidas por: n identificatorio,
nmero_cliente, tipo, marca y modelo.
Con
El
(fotocopiadora, fax...)
5-21
5-22
Escenarios y sub-escenarios
5-23
Ejemplo de escenarios
Caso de uso 1: Gestin de Clientes
Nombre de Escenario 1.1: Dar de alta un cliente eventual
Precondiciones: No existe ficha de cliente.
Postcondiciones: Todos los datos se han introducido correctamente.
El numero de clientes se incrementa en uno
Excepciones:
Iniciado por: Dependiente/Administrador.
Finalizado por: Dependiente/Administrador.
Detalle operaciones: Cliente acude a una tienda de la compaa.
Dependiente
cliente.
Dependiente
Excepciones
Iniciado por: Administrador.
Finalizado por: Administrador.
Detalle operaciones: Cliente acude a una tienda de la compaa.
Administrador obtiene los datos del cliente.
Administrador
5-24
Caso de uso
Actor
<<extend >>
5-25
Prototipos
[Piattini 96]
El rea de la aplicacin no est bien definida, bien por su dificultad o bien por falta de
tradicin en su automatizacin.
El coste del rechazo de la aplicacin por los usuarios, por no cumplir sus expectativas, es
muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organizacin.
Prototipado de la interfaz de usuario para asegurarse de que esta bien diseada, que
satisface las necesidades de quienes deben usarlo. Este tipo de prototipado es bastante
frecuente, no cuesta mucho y puede consistir en simples modelos de pantallas en papel,
simuladas con programas de dibujo o presentacin o autnticas simulaciones muy elaboradas
de la interfaz. No suele resultar ms caro que el trabajo tradicional y es muy efectivo para evitar
los mltiples cambios que suelen solicitar los usuarios en este aspecto.
Modelos de rendimiento para evaluar el posible rendimiento de un diseo tcnico,
especialmente en aplicaciones crticas en este aspecto. Estos modelos tienen un carcter
puramente tcnico y, por lo tanto, no son aplicables al trabajo de anlisis de requisitos.
Prototipado funcional. Cada vez ms utilizado, est relacionado con un ciclo de vida
iterativo. En este caso, en vez de seguir el procedimiento habitual (tirar el prototipo una vez
probado y empezar a desarrollar la aplicacin), el prototipo supone una primera versin del
sistema con funcionalidad limitada. A medida que se comprueba si las funciones
implementadas son las apropiadas, se corrigen, refinan o se aaden otras nuevas hasta llegar
al sistema fina
5-26
5-27
Clase
Responsabilidades
Superclase
Subclase
Colaboraciones
Atributos
5-28
Clase: Reunin
Superclase:
Subclases: Reunin de trabajo, Junta de Escuela, Clase de un curso
Atributos:
Orden del da
Lugar
Fecha
Hora de inicio
Asistentes
Equipo necesario
5-29
Ventajas
Es sencillo
Es didctico
Inconvenientes
5-30
Resumen
5-31
EJERCICIOS PROPUESTOS
5.1 Realizar el anlisis del juego del ajedrez. Se puede jugar dos personas entre s o una
persona contra el ordenador. En este ltimo caso debe ser posible seleccionar el nivel
de dificultad entre una lista de varios niveles. El juego de ajedrez permitir al jugador
elegir el color de las piezas. La aplicacin deber permitir detectar los movimientos
ilegales de las piezas, tiempos utilizados cada jugador, registro de jugadas y piezas
perdidas. Tambin determinar si se alcanzan tablas, y permitir abandonar la partida
a un jugador.
5.2 Realizar el anlisis de una aplicacin que realiza estudios de mercado para situar
grandes superficies (hipermercados). Se supone que cada gran superficie necesita un
mnimo de poblacin que pueda acceder a dicho hipermercado en menos de un tiempo
dado. La red de carreteras se puede representar mediante un grafo.
5.3 Realizar el anlisis para gestionar los fondos bibliogrficos y de socios de una
biblioteca por Internet.
5.4 Realizar el anlisis para gestionar un centro de enseanza (profesores, asignaturas,
alumnos, matriculacin, calificaciones de cada asignatura, expediente,...) por Internet.
5.5 Realizar el anlisis del juego de cartas del tute, para poder jugar con el ordenador.
5-32
Referencias Bibliogrficas
[Abbott 1983] Abbott, R.J.Program Design by Informal English Descriptions. Comunications of the ACM, 26(11),882-894.
1983.
[Bock/Odell 1994] C. Bock and J. Odell, A Foundation For Composition, Journal of Object-oriented Programming,
October 1994.
[Booch 1994] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings (1994). Versin
castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de Santos (1996).
[Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide. Addison-Wesley (1999).
Versin castellana El lenguaje unificado de modelado. Addison-Wesley (1999)
[Bellin 1997] D. Bellin and S. Suchman Simone.The CRC Card book. Addison-Wesley, 1997
[Coad 1991] P. Coad, E. Yourdon. Object-Oriented Analysis. Second Edition .Prentice-Hall, 1991.
[Cook 1994] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice-Hall
Object-Oriented Series, 1994.
[Eriksson 1998] H-E Eriksson & M. Penker. UML Toolkit. Wiley, 1998.
[Fowler 1997] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, ISBN 0-20132563-2, Addison-Wesely, 1997. Versin castellana UML gota a gota, Addison-Wesley 1999.
[Jacobson 1992] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented Software Enginneering. A use
Case Driven Approach., ISBN 0-201-54435-0, Addison-Wesely, 1992.
[Jacobson 1999] I. Jacobson, G. Booch, J. Rumbaugh. The unified software development process. Addison-Wesley
(1999).Versin Castellana. El Proceso Unificado de Desarrollo de Software. Prentice-Hall, 2000.
[Lee 1997] R. C.Lee & W. M. Tepfenhart. UML and C++, Prentice-Hall, 1997
[Piattini 1996] M.G. Piattini, J.A. Calvo-Manzano, J. Cervera, L. Fernndez. Anlisis y diseo detallado de aplicaciones
de gestin. RA-MA (1996)
[Rumbaught 1991] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented modeling and design.
Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos. Metodologa OMT. Prentice-Hall (1996)
[Rumbaught 1999] Rumbaught J., I. Jacobson, G. Booch. The Unified Modeling Language Reference Manual. AddisonWesley (1999). Versin castellana. El Lenguaje Unificado de Modelado. Manual de Referencia.Addison-Wesley, 2000.
[Reenskaug 1996] T. Reenskaug. Working with Objects. The Ooram Software Engineering Method.Prentice-Hall, 1996
[Schneider 1998] G. Schneider, J. Winters. Applying Use Cases: A Practical Approach. Addison-Wesley, 1998.
[Wilkinson 1995 ] N. M. Wilkinson. Using CRC Cards. An Informal Approach to Object-Oriented Development, 1995,
SIGS BOOKS, ISBN 1-884842-07-0
5-33
Referencias en la web
5-34
www.ootlab.uniovi.es
6-1
Diseo detallado
Es un refinamiento sucesivo de
diagramas de diseo
Juan Manuel Cueva Lovelle
www.ootlab.uniovi.es
6-2
Modelado de la
Arquitectura del Sistema
[Booch 99, captulos 1,2, 31]
www.ootlab.uniovi.es
6-3
Diagramas de Interaccin
Diagramas de estados
Diagramas de actividades
Diagramas de clases
Diagramas de objetos
Diagramas de interaccin
Diagramas de estados
Diagramas de actividades
Vista de implementacin
Caos de uso
Vista de procesos
Vista de diseo
Muestra los requisitos del sistema tal como es percibido por los usuarios
finales, analistas, y encargados de pruebas. Utiliza los diagramas:
Diagramas de Interaccin
Diagramas de Estados
Diagramas de Actividades
Vista de despliegue
Diagramas de Interaccin
Diagramas de Estados
Diagramas de Actividades
www.ootlab.uniovi.es
6-4
www.ootlab.uniovi.es
6-5
La dificultad de la clasificacin
Ejemplos de clasificacin
www.ootlab.uniovi.es
6-6
Abstracciones clave
son clases u objetos que forman parte del dominio del
problema [Booch 94]
www.ootlab.uniovi.es
6-7
www.ootlab.uniovi.es
6-8
www.ootlab.uniovi.es
6-9
Mecanismos
Denotan las decisiones estratgicas de diseo respecto
a la actividad de colaboracin entre muchos tipos
diferentes de objetos [Booch 94]
Identificacin de mecanismos
Bsqueda de mecanismos
Se utilizan escenarios
El interfaz de una clase individual es una
decisin tctica, sin embargo los mecanismos
son decisiones estratgicas en las que el
desarrollador elige entre un conjunto de
alternativas influyendo factores como coste,
fiabilidad, facilidad de fabricacin y seguridad
www.ootlab.uniovi.es
6-10
Diagramas de Interaccin
[Booch 99, captulo 18]
Diagramas de Secuencia
Diagramas de Colaboracin
www.ootlab.uniovi.es
6-11
www.ootlab.uniovi.es
6-12
Los diagramas de secuencia son mejores que los diagramas de colaboracin para
capturar la semntica de los escenarios en un momento temprano del ciclo de
desarrollo.
Un diagrama de secuencia destaca la ordenacin temporal de los mensajes
Se coloca a la izquierda el objeto que inicia la interaccin, y el objeto subordinado a la
derecha
La lnea de vida de un objeto es la lnea vertical.
www.ootlab.uniovi.es
6-13
www.ootlab.uniovi.es
6-14
www.ootlab.uniovi.es
6-15
en Rational Rose
www.ootlab.uniovi.es
6-16
*[i:=1..n]
o slo * si se quiere indicar iteracin sin indicar detalles
www.ootlab.uniovi.es
6-17
process
thread
www.ootlab.uniovi.es
6-18
www.ootlab.uniovi.es
6-19
www.ootlab.uniovi.es
6-20
www.ootlab.uniovi.es
6-21
www.ootlab.uniovi.es
6-22
www.ootlab.uniovi.es
6-23
en Rational Rose
www.ootlab.uniovi.es
6-24
Clases
Interfaces
Colaboraciones
Relaciones de dependencia, generalizacin y asociacin
www.ootlab.uniovi.es
6-25
www.ootlab.uniovi.es
6-26
www.ootlab.uniovi.es
6-27
Estereotipos en UML
Un estereotipo es una forma de clasificar las clases a alto nivel
Los estereotipos se muestran con un texto entre doble ngulo << y >>, por
ejemplo: <<control>>
Los estereotipos tambin se pueden definir con un icono
Muchas extensiones del ncleo de UML se pueden describir mediante una
coleccin de estereotipos
www.ootlab.uniovi.es
6-28
Clasificadores (I)
[Booch 99, captulo 9]
Clase
Interfaz
Tipo de dato
Seal
Componente
Nodo
Caso de Uso
Subsistema
www.ootlab.uniovi.es
6-29
Clasificadores (II)
[Booch 99, captulo 9]
public
protected
private
www.ootlab.uniovi.es
6-30
Interfaces
[Booch 99, captulo 11]
Termmetro
ISensor
<<interface>>
Isensor
estereotipo
Realizacin (forma expandida)
Activar()
Calibrar ()
Registrar()
Apagar()
Juan Manuel Cueva Lovelle
Veleta
operaciones
www.ootlab.uniovi.es
6-31
www.ootlab.uniovi.es
6-32
Diagramas de objetos
[Booch 99, captulo 14]
www.ootlab.uniovi.es
6-33
Diagramas de actividades
[Booch 99, captulo 19]
Los diagramas de actividades son uno de los cinco diagramas que modelan aspectos dinmicos del
sistema
Un diagrama de actividades muestra el flujo de actividades
Una actividad es una ejecucin no atmica en curso dentro de una mquina de estados
Las actividades producen finalmente una accin, que est compuesta de computaciones atmicas
ejecutables que producen un cambio en el estado del sistema o la devolucin de un valor.
Un diagrama de actividad contiene:
Transiciones
Objetos
Restricciones
www.ootlab.uniovi.es
6-34
Diagramas de actividades
Calles (Swimlanes)
[Booch 99, captulo 19]
www.ootlab.uniovi.es
6-35
Diagramas de actividades
Flujo de objetos
[Booch 99, captulo 19]
www.ootlab.uniovi.es
6-36
www.ootlab.uniovi.es
6-37
Diagramas de estados
[Booch 99, captulo 24]
www.ootlab.uniovi.es
6-38
Diagramas de componentes
[Booch 99, captulo 25]
www.ootlab.uniovi.es
6-39
Diagramas de despliegue
[Booch 99, captulo 26]
www.ootlab.uniovi.es
6-40
<<Interface>>
OVNI
Hangar
despegar()
volar()
aterrizar()
+Contenedor
Cabina
Aeronave
0..n
Helicptero
1..*
Globo
Dirigible
Avin
Hidroavin
Motor
AvinDespegue
Vertical
www.ootlab.uniovi.es
Autogiro
6-41
2.
3.
4.
5.
6.
7.
8.
9.
10.
Los de Chapuzosa disean el diagrama de clases en UML en la figura anterior. Se les puede
decir que A) La vida (creacin y destruccin) de los objetos de la clase Motor depende de la
vida de los objetos de las clases Avion y Helicoptero B) Los objetos de la clase Motor se
pueden crear y se destruir de forma independiente de las clases Avion y Helicoptero C) Los
objetos de la clase Cabina se pueden crear y se destruir de forma independiente de la clase
Aeronave D) Todas las respuestas son correctas E) Ninguna respuesta es correcta
Los de Chapuzosa estn experimentando con la herencia, tal y como se observa en el
diagrama anterior y te preguntan: Cuntos objetos de la clase Cabina tiene un objeto de la
clase Hidroavin? A) ninguno B) 1 C) Depende de la implementacin D) Todas las
respuestas anteriores son correctas E) Ninguna respuesta anterior es correcta.
Los de Chapuzosa se encuentran el diagrama anterior donde Hangar es un contenedor
polimrfico de punteros a objetos Aeronave, y se preguntan Qu cosas puede contener?. A)
El Hangar puede contener punteros a objetos de la clase Dirigible B) El hangar puede
contener directamente punteros a objetos Motor C) Hangar puede contener punteros a
objetos Cabina D) Todas las respuestas anteriores son correctas E) Ninguna respuesta
anterior es cierta
Los de Chapuzosa discuten sobre las interfaces de UML, y dicen que A) Los objetos
Autogiro tienen un mtodo volar B) Se pueden implementar en C++ usando clases abstractas
con mtodos abstractos puros C) La clase Aeronave debe implementar el mtodo despegar
D) Todas las respuestas anteriores son correctas E) Ninguna respuesta anterior es correcta
Los de Chapuzosa discuten sobre Patrones de Diseo, y dicen que el patrn Singleton es A)
Un patrn de creacin B) Es un patrn de comportamiento C) Un patrn estructural D)
Todas las respuestas anteriores son correctas E) Ninguna respuesta anterior es correcta.
Los de Chapuzosa discuten sobre Actores de UML, y dicen que A) Se identifican en el
Anlisis B) Se implementan con clases C) Son los que interactan con el sistema D) Todas
las respuestas anteriores son correctas E) Ninguna respuesta anterior es correcta
Los de Chapuzosa discuten sobre prototipos, y dicen que A) No son un tipo de diagrama
UML B) Son para evaluar los requisitos C) Son parte del Anlisis D) Todas las respuestas
anteriores son correctas E) Ninguna respuesta anterior es correcta
Los de Chapuzosa discuten sobre escenarios, y dicen que A) Son especializaciones de los
casos de uso B) Son parte del modelo anlisis C) No estn especificados en UML D) Todas
las respuestas anteriores son correctas E) Ninguna respuesta anterior es correcta
Los de Chapuzosa discuten sobre los Diagramas de Interaccin, y dicen que A) Modelan
aspectos dinmicos del sistema B) Son parte del diseo C) Son un caso particular de los
Escenarios D) Todas las respuestas anteriores son correctas E) Ninguna respuesta anterior
es correcta
Los de Chapuzosa discuten sobre Diagramas de Objetos, y dicen que A) Es necesario
hacerlos todos B) Son parte del modelo fsico C) Muestran los objetos y sus relaciones en un
instante determinado D) Todas las respuestas anteriores son correctas E) Ninguna
respuesta anterior es correcta
Respuestas: 1-b), 2-b), 3-a),4-d), 5-a), 6-d), 7-d) , 8-d), 9-d), 10-c)
www.ootlab.uniovi.es
6-42
Referencias
[Booch 94] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings
(1994). Versin castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin.
Addison-Wesley/ Daz de Santos (1996).
[Booch 99] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide. AddisonWesley (1999). Versin castellana El lenguaje unificado de modelado. Addison-Wesley (1999)
[Coad 97] P. Coad, M. Mayfield. Java design. Prentice-Hall, 1997.
[Cook 94] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with
Syntropy, Prentice-Hall Object-Oriented Series, 1994.
[Eriksson 98] H-E Eriksson & M. Penker. UML Toolkit. Wiley, 1998.
[Fowler 97] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling
Language, ISBN 0-201-32563-2, Addison-Wesely, 1997.
[Gamma 95 ] Gamma E. et al. Design Patterns. Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1995.Versin en castellano Patrones de Diseo. Pearson Educacin, 2002.
[Granham 97 ] I. Graham, B. Henderson-Sellers, H. Younessi. The OPEN Process Specification.
Addison-Wesley (1997).
[Grand 98 ] Grand M. Patterns in Java. Volume 1. Wiley, 1998.
[Grand 99 ] Grand M. Patterns in Java. Volume 2. Wiley, 1999.
[Henderson-Sellers, 97 ] B. Henderson-Sellers. OML: OPEN Modelling Language. SIGBOOKS, 1997.
[Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented software
Engineering. A use case driven Approach. Addison-Wesley (1992)
[Jacobson 99] I. Jacobson, G. Booch, J. Rumbaugh. The unified software development process.
Addison-Wesley (1999).
[Larman 98 ] C. Larman. Applying UML and Patterns. An Introduction to Object-Oriented Analysis
and Design. Prentice-Hall (1998). Versin castellana: UML y patrones. Introduccin al anlisis y
diseo orientado a objetos. Prentice-Hall (1999).
[Lee 97] R. C.Lee & W. M. Tepfenhart. UML and C++, Prentice-Hall, 1997
[Lpez 97] N. Lpez, J. Migueis, E. Pichon. Intgrer UML dans vos projects. Editions Eyrolles, 1998.
Versin castellana: Integrar UML en los proyectos. Ediciones Gestin 2000 (1998).
[Muller 97] Muller P-A Modlisation Object avec UML Eyrolles 1997. Versin castellana: Modelado
de objetos con UML, Gestin-2000, 1997
[Odell 98] J.J. Odell. Advanced Object-Oriented Analysis & Design Using UML. SIGS, 1998.
[OMG] www.omg.org
[OPEN] www.open.org.au
[Piattini 96] M.G. Piattini, J.A. Calvo-Manzano, J. Cervera, L. Fernndez. Anlisis y diseo detallado
de aplicaciones de gestin. RA-MA (1996)
[Rational] UML y herramienta Rational Rose en www.rational.com
[Rumbaught 91] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented
modeling and design. Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos.
Metodologa OMT. Prentice-Hall (1996)
[Rumbaught 99] Rumbaught J., I. Jacobson, G. Booch. The Unified Modeling Language Reference
Manual. Addison-Wesley (1999)
[Reenskaug 96] T. Reenskaug. Working with Objects. The Ooram Software Engineering
Method.Prentice-Hall, 1996
[Wilkinson 95 ] N. M. Wilkinson. Using CRC Cards. An Informal Approach to Object-Oriented
Development, 1995, SIGS BOOKS, 1-884842-07-0
www.ootlab.uniovi.es
6-43
Tema 7
El proceso de desarrollo
Principios bsicos
El microproceso de desarrollo
El macroproceso de desarrollo
Resumen
7-1
Principios bsicos
[Booch 94]
7-2
El microproceso de desarrollo
[Booch 94]
7-3
7-4
Actividades
Seleccionar escenario
Identificar las abstracciones
Relatar la actividad en el escenario
Iterar reasignando responsabilidades
7-5
Propsito
Productos
Se producen seis:
En esta fase no es deseable (ni posible) expresar todos los diagramas que
expresen todas las visiones concebibles. Tan slo se representan las ms
interesantes
Actividades
Especificacin de asociaciones
Hitos
Medidas de bondad
7-6
7-7
El macroproceso de desarrollo
[Booch 94]
7-8
Conceptualizacin
Establecer los requisitos principales del
software que se va a construir
7-9
Anlisis
Desarrollar un modelo del comportamiento
deseado del sistema
Productos
Casos de uso
Los escenarios: cada escenario denota algn punto funcional
Documento formal de anlisis que establece los requisitos del comportamiento
del sistema
Identificacin de reas de riesgos tcnicos
Actividades
Medidas de la bondad
Deber comunicar una visin del completa y simple del sistema a todo el
equipo de desarrollo
Informar a todo el equipo de desarrollo de las estimaciones de los riesgos
7-10
Diseo
Crear una arquitectura para la implementacin
Descripcin de la arquitectura
Diseo tctico
Enumerar las polticas comunes que deben seguir los elementos dispares de la
arquitectura
Para cada poltica comn desarrollar un escenario que describa la semntica de esa
poltica
Documentar cada poltica y efectuar recorridos siguindola por toda la arquitectura
Hitos
Actividades
7-11
Evolucin
Transformar la implementacin mediante
refinamientos sucesivos
7-12
Mantenimiento
Gestionar la evolucin postventa o postentrega
7-13
Resumen
7-14
Referencias
[Booch 1994] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings
(1994). Versin castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin.
Addison-Wesley/ Daz de Santos (1996).
[Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide.
Addison-Wesley (1999). Versin castellana El lenguaje unificado de modelado. Addison-Wesley
(1999)
[Buschman 1996 ] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, M. Stal. Pattern-Oriented
software architecture. Volume 1. Wiley, 1996.
[Buschman 2000 ] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerland, M. Stal. Pattern-Oriented
software architecture. Volume 2. Wiley, 2000.
[Cook 1994] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with
Syntropy, Prentice-Hall Object-Oriented Series, 1994.
[Cooper 2000 ] J.W. Cooper. Java Design Patterns. Addison-Wiley, 2000.
[Gamma 1995 ] Gamma E. et al. Design Patterns. Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1995.
[Grand 1998 ] Grand M. Patterns in Java. Volume 1. Wiley, 1998.
[Grand 1999 ] Grand M. Patterns in Java. Volume 2. Wiley, 1999.
[Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented software
Engineering. A use case driven Approach. Addison-Wesley (1992)
[Jacobson 1999] I. Jacobson, G. Booch, J. Rumbaugh. The unified software development process.
Addison-Wesley (1999).Versin Castellana El Proceso Unificado de Desarrollo de Software, 1999.
[Piattini 1996] M.G. Piattini, J.A. Calvo-Manzano, J. Cervera, L. Fernndez. Anlisis y diseo
detallado de aplicaciones de gestin. RA-MA (1996)
[Rumbaught 1991] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented
modeling and design. Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos.
Metodologa OMT. Prentice-Hall (1996)
[Rumbaught 1999] Rumbaught J., I. Jacobson, G. Booch. The Unified Modeling Language Reference
Manual. Addison-Wesley (1999). Versin Castellana El lenguaje Unificado de Modelado. Manual de
Referencia. Addison-Wesley, 1999.
7-15
Gestin y planificacin
Administracin de personal
Gestin de versiones
Reutilizacin
Control de calidad del software
Documentacin
Herramientas
Temas especiales
Las ventajas y los riesgos del desarrollo orientado a objetos
8-1
Gestin y planificacin
Es necesario un liderazgo fuerte que gestione y dirija el proyecto de
desarrollo de software
Planificacin de tareas
Recorridos de inspeccin
La direccin del proyecto debe revisar los aspectos del sistema que
conlleven decisiones de desarrollo estratgicas
En el anlisis pueden hacer revisiones incluso personal no
informtico para validar los escenarios planteados
8-2
Administracin de personal
Asignacin de recursos
Papeles principales
Otros papeles
Analista
Ingeniero de reutilizacin
Responsable de control de calidad
Jefe de integracin de subsistemas
Documentalista
Responsable de herramientas
Administrador del sistema
8-3
Gestin de versiones
Requisitos
Diagramas (interaccin, clases, objetos, mdulos, procesos)
Cdigo fuente
Documentacin
Prueba
8-4
Reutilizacin
Elementos de la reutilizacin
Institucionalizar la reutilizacin
8-5
8-6
Documentacin
Contenidos de la documentacin
8-7
Herramientas
Tipos de herramientas
Implicaciones en la organizacin
Debe haber
un responsable de herramientas
un ingeniero de reutilizacin (mantiene la biblioteca de clases)
8-8
Temas especiales
Transferencia tecnolgica
8-9
Competitividad
Mayor flexibilidad (reutilizacin y uso de componentes)
Calidad
Eficacia
Costes de puesta en marcha de una nueva tecnologa
8-10
Referencias
[Booch 94] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings (1994).
Versin castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de
Santos (1996).
[Booch 99] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide. Addison-Wesley
(1999). Versin castellana El lenguaje unificado de modelado. Addison-Wesley (1999)
[Cook 94] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, PrenticeHall Object-Oriented Series, 1994.
[Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented software Engineering. A
use case driven Approach. Addison-Wesley (1992)
[Jacobson 99] I. Jacobson, G. Booch, J. Rumbaugh. The unified software development process. Addison-Wesley
(1999).
[Piattini 96] M.G. Piattini, J.A. Calvo-Manzano, J. Cervera, L. Fernndez. Anlisis y diseo detallado de
aplicaciones de gestin. RA-MA (1996)
[Rumbaught 91] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented modeling and
design. Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos. Metodologa OMT.
Prentice-Hall (1996)
[Rumbaught 99] Rumbaught J., I. Jacobson, G. Booch. The Unified Modeling Language Reference Manual.
Addison-Wesley (1999)
8-11