Capitulo 03 - DiseñoAplicacionesOOP

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos.
3.1. Clases y Estructuras.

Dentro del Common Type System (CTS) en .Net Framework, tenemos dos construcciones bsicas: las clases y las estructuras. En esencia, ambas son estructuras de datos que encapsulan un conjunto de datos y comportamientos relacionados como una unidad lgica. Se llaman miembros de la clase o estructura, a los datos y comportamientos que incluyen: mtodos, propiedades, eventos, etc. Las clases y estructuras se utilizan para crear instancias u objetos en tiempo de ejecucin. Se puede crear tantas instancias como se desee de un tipo de clase y, cada una de estas instancias, contener datos distintos. Una clase es un objeto que es creado como un tipo por referencia. Cuando creamos un objeto de esa clase (instancia), la variable a la que se asigna slo incluye una referencia al espacio en memoria donde se encuentra la clase. Cuando la referencia se asigna a una nueva variable, esta contiene igualmente la referencia al objeto original. En este caso cuando una de las dos variables cambia el contenido de su valor o valores, automticamente cambia la otra. Ver cdigo y esquema para la Clase Persona.
protected void Page_Load(object sender, EventArgs e) { //LLamamos a la clase Persona y realizamos una instancia en la variable DatosPer Persona DatosPer= new Persona("Pedro", "Lpez"); lblVer.Text = "El nombre completo es: " + DatosPer.Nombre + " " + DatosPer.Apellidos; } class Persona { public Persona(string Nomb, string Apell) { Nombre = Nomb; Apellidos = Apell; } public string Nombre { get; set; } public string Apellidos { get; set; } }
Captulo 3. Diseo de Aplicaciones Orientadas a Objetos
Pgina 1
Esquema del resultado en memoria al instanciar una clase:

Clase Persona
Instancia de la Clase Persona
Variables de la clase Persona string Nombre string Apellidos

Valores de las variables
Valores por Referencia
Variable de la Instancia AB13 43CB
Direcciones Hexadecimales
Como se puede ver en el esquema, los datos de la clase estn en un lugar y las referencias a ese lugar en otro. Cuando accedemos a la clase para grabar un dato o ver un valor, el sistema mira la referencia (direcciones hexadecimales) y a continuacin saca o coloca el valor en el sitio que le indica esa referencia. Cuando realizamos una copia de la instancia, slo se copian las referencias y no los datos. Ambas, copia y original, apuntan a los mismos datos. Por eso, un dato cambiado en cualquiera de las dos afecta a la otra. Una estructura es un objeto que es creado como un tipo por valor. Cuando se crea la estructura, la variable que se asigna incluye los datos y la propia estructura. Si asignamos esta variable a otra variable, a diferencia de las clase, hace una copia ntegra del objeto (en las clases slo copia las referencias). En este caso e igualmente a diferencia de las clases, los cambios en una de las variables no afecta a la otra. Ver cdigo y esquema.
protected void Page_Load(object sender, EventArgs e) { //LLamamos a la clase Persona y realizamos una instancia en la variable DatosPer Persona DatosPer= new Persona("Pedro", "Lpez"); lblVer.Text = "El nombre completo es: " + DatosPer.Nombre + " " + DatosPer.Apellidos; } struct Persona { public string Nombre, Apellidos; public Persona(string Nomb, string Apell) { Nombre = Nomb; Apellidos = Apell; } }
Pgina 2
Esquema de instanciar una estructura
En las estructuras, podemos ver, que a pesar de ser instanciadas de la misma forma, su comportamiento es diferente. En las estructuras, la variable de la instancia, en el ejemplo DatosPer, contiene los datos y las variables de la estructura, a diferencia de la clase que slo contena las referencias a los datos. Bsicamente las clases se utilizan cuando necesitamos un comportamiento ms complejo o datos que se piensan modificar una vez creado el objeto.
Estructura Persona
Instancia de la Estructura Persona
Variables de la clase Persona string Nombre string Apellidos

Valores de las variables
Las estructuras son ms indicadas cuando manejamos pequeas estructuras de datos y no se piensan modificar una vez creados. Ms adelante se ver un resumen de cuando es mejor una eleccin u otra. Para poder trabajar en programacin orientada a objetos (POO) dentro de .NET usaremos las clases. La POO tiene en la clase un mecanismo potente para realizar sus funciones e incluye dos caractersticas igualmente importantes: encapsulamiento y herencia. Cuando trabajamos en un programa orientado a objetos, lo que realmente estamos creando es un conjunto de clases, desde las cuales se crean los objetos necesarios para nuestro programa.
Pgina 3
3.2. Las Clases.

Qu es un objeto? Por ejemplo, si quisiramos hacer un flan, tendramos que el molde es la clase y los flanes son los objetos. Si queremos hacer un flan de vainilla tenemos unos ingredientes: leche, azcar, vainilla, etc, pero no todos los flanes tendrn la misma proporcin de ingredientes. Adems, no tienen porque todos los flanes ser de vainilla, tambin pueden ser de huevo. Una clase equivale a generalizar un tipo especfico de objetos, pero cada objeto que construyamos de esa clase contendr sus propios datos. El objeto en la clase es creado en el momento en que se invoca mediante el operador new: Flan vainilla = new Flan(); Una aplicacin de C# tpica se compone de clases definidas por el programador, junto con clases de .NET Framework. Una clase es en s misma un tipo personalizado por el programador mediante la agrupacin de variables de otros tipos, tanto de tipos bsicos como de tipos desarrollados por otros programadores. En la clase se define el tipo y el comportamiento del tipo. Si la clase no se declara como esttica se instancia con una variable, usando la palabra clave new, tal y como hemos visto antes. Esa variable declarada para ese tipo es administrada por el CLR hasta que termina su mbito de ejecucin, en cuyo caso, el CLR la marca para recoleccin y el Garbage Collector la limpiara de la memoria. Por el contrario, si es esttica, slo existe una copia de la clase en memoria y no permite instanciarla sobre una variable. Si queremos acceder a ella es necesario hacerlo a travs de la propia clase y no por una copia de una variable instanciada. A diferencia de las estructuras, las clases permiten herencia, que es un pilar bsico en la programacin orientada a objetos. 3.2.1. Cmo se define una clase en C#? Para la definicin de una clase en C# se utiliza la palabra class seguido del nombre de la clase y dentro de las llaves el cdigo. Ejemplo: class Flan { Implementacin de los mtodos, propiedades y atributos de la clase. }
Pgina 4
Cuando se define una clase en C# existe un concepto denominado nivel de acceso que indica desde donde se puede acceder o utilizar la clase. Por ejemplo, una clase declarada como Public, puede ser accedida desde cualquier proyecto, por el contrario, si se declara Private, slo es accesible por el propio contenedor de la clase. El nivel de accesibilidad predeterminada para una clase es Private. Los niveles de acceso van delante de la palabra class. Ejemplo: public class Flan Tabla de Niveles de acceso para la clase.
public protected Acceso no restringido. Acceso limitado a la clase contenedora o a los tipos derivados de esta clase. Acceso limitado al proyecto actual. Acceso limitado al proyecto actual o a los tipos derivados de la clase contenedora. Acceso limitado al tipo contenedor.
internal protected internal private
Cualquier mtodo, propiedad o atributos deben de estar siempre contenidos dentro de las llaves de una clase. Aunque muchas veces se habla de que un objeto es una class, en realidad, una clase define un tipo de objeto, pero no es propiamente un objeto. Cuando creamos una estancia de la clase con la palabra reserva new, se crea una referencia al objeto, por ejemplo: Empleado objEm = new Empleado(); En este ejemplo, objEm es una referencia a un objeto basado en Empleado. Esta referencia apunta al nuevo objeto, pero no contiene los datos del objeto, tal y como pudimos ver en el esquema de instancia de una clase al principio del captulo. Podemos crear slo la referencia, sin apuntar a datos, por ejemplo: Empleado objEm; En este caso, el objeto no apunta a ningn dato y si intentamos usar la variable objEm, dara un error de ejecucin. Pero podemos usarlo para el siguiente ejemplo: Empleado objEmBase = new Empleado(); Empleado objEm = objEmBase; En este ejemplo, instanciamos la variable objEmBase y a continuacin le pasamos las referencias de objEmBase a objEm, lo que significa que ambas
Captulo 3. Diseo de Aplicaciones Orientadas a Objetos Pgina 5
estn apuntando a los mismos datos. Si cambiamos un valor del objeto en una, lo cambiamos automticamente en la otra (valores por referencia). Las clases se agrupan en espacios de nombre (namespace). La palabra clave namespace se utiliza para declarar un mbito. Este mbito permite organizar el cdigo y proporciona una forma de crear tipos globalmente nicos. Un espacio de nombres puede contener varias clases y subclases, as como otros espacios de nombres. Por ejemplo: namespace MisClases { public class ClasePrincipal { // Instrucciones } class ClaseInterna { // Instrucciones } } 3.2.2. Qu son los atributos? Son caractersticas individuales que diferencia un objeto de otro. Es decir, como hemos comentado anteriormente, cada objeto puede tener unos valores diferentes (ingredientes). Se manejan mediante variables que se declaran de un tipo especfico y que deberan ser privadas a la clase. Ejemplo: class Flan { private int Azucar; private int Leche; private string TipoFlan; } En el ejemplo anterior hemos definido tres atributos: dos de tipo int y uno de tipo string. Son privados a la clase y se usarn en los distintos mtodos y propiedades de la clase. Por regla general los atributos de la clase son privados para que los programadores desde fuera no tengan acceso a ellos. Un programador que use nuestra clase Flan no podr acceder directamente a estas variables. Para poder acceder al contenido de un atributo, podemos usar las Propiedades.
Pgina 6
3.2.3. Qu es una Propiedad? Las propiedades tienen un aspecto anlogo a un mtodo. Utilizan descriptores de acceso para controlar cmo se establecen y devuelven valores de los atributos a los que se refieren. Los descriptores son rutinas de cdigo declaradas dentro de la propiedad. El descriptor GET, recupera su valor y el descriptor SET establece su valor. Ejemplo:
class Flan { // Definicin de Atributos. private int Azucar; // Definicin de Propiedades. public int CantidadAzucar { get { return Azucar; } set { Azucar = value; } } }
La propiedad tiene que ser public o internal para poder acceder a ellas desde fuera (private suele ser el atributo, pero no es obligatorio). Evidentemente, se aplica la misma norma de modificador de acceso que para el caso de las clases. No tiene porque llevar siempre el get y el set, puede tener slo uno de los dos. Cuando slo tiene el get, se llama propiedad de slo lectura y cuando tiene slo el set, propiedad de slo escritura. En Net Framework 3.5 y superior, las propiedades ya no necesitan tener vinculado obligatoriamente una variable o atributo, aunque se puede usar si se quiere. Hasta la versin 3.5 de Net, cuando definamos una propiedad, estbamos obligados a definir un atributo que era, al fin y al cabo, la variable que contena realmente el valor. Por lo tanto, si slo queremos guardar y leer un valor en una propiedad, podemos realizar el ejemplo anterior de la siguiente forma:
class Flan { // Definicin de Propiedades. public int CantidadAzucar { get; set; } }
Pgina 7
3.2.4. Mtodos en C#. Un mtodo es un bloque de instrucciones cuyo objetivo es realizar una tarea concreta. Podemos usar un mtodo para calcular el resultado de una frmula matemtica, para grabar o leer datos en ficheros, para imprimir, etc. Los mtodos tienen que ser definidos dentro de una clase o estructura. En C#, toda instruccin tiene que ser ejecutada dentro de un mtodo. La forma de llamar al mtodo es usando su nombre y el doble parntesis. Por ejemplo: MiMetodo(); Un mtodo es en realidad una parte de cdigo que se decide agrupar para poder ejecutarlo cuando se necesite. Por tanto, el mtodo puede contener cualquier instruccin del lenguaje que se est utilizando, as como variables y dems objetos. Si bien podemos usar variables que nos permiten almacenar datos dentro del mtodo, el mtodo en s no puede guardar valores. Dentro del mtodo, cualquier variable declarada, hace que su uso est restringido al propio mtodo. Estructura de un mtodo:
1. Modificador de acceso 2. Tipo de dato devuelto 3. Nombre del mtodo 4. Argumentos de entrada
private void NombreMetodo(argumentos de entrada) { // Instrucciones }
1. Modificador de acceso. El modificador de acceso permite especificar desde donde puede ser accedido el mtodo. Un mtodo slo puede ser llamado desde un objeto que tenga el nivel de acceso adecuado al mtodo. Tipos de acceso: Private. Slo es accesible por el contenedor. Es el nivel de acceso ms restringido. Si no aparece en el mtodo modificador de accedo, el mtodo es por defecto Private. Public. Es accesible para las clases heredadas, para el proyecto en el que se encuentra el mtodo y para cualquier otro proyecto. Es el nivel de acceso ms amplio y se le conoce como acceso no restringido. Protected. Slo es accesible por la clase contenedora y por las clases que heredan de la clase que contiene el mtodo. Internal. Slo es accesible por el ensamblado, es decir por el propio proyecto que contiene el mtodo.
Protected Internal. Slo es accesible por la clase contenedora del mtodo, as como por las clases que heredan de la clase y por el propio proyecto. 2. Tipo de dato devuelto. Si el mtodo no tiene que devolver ningn valor cuando es invocado, se utiliza la palabra reservada void. Por el contrario, si tiene que devolver un dato, hay que especificar el tipo de dato en lugar de void. Un mtodo acepta cualquier tipo bsico, as como cualquier tipo referenciado. El siguiente ejemplo devolvera un nmero de tipo decimal: private decimal Numero(). Cuando el mtodo no devuelve nada (void), el mtodo ha de ser llamado como vimos al principio, es decir, nombre del mtodo y el doble parntesis. Pero cuando el mtodo devuelve un valor y queremos usar ese valor, debemos de almacenar el valor en una variable del tipo devuelto. Por ejemplo, si el mtodo devuelve un string, la forma de llamarlo sera: string texto; texto = MiMetodo(); Cuando un mtodo devuelve un tipo de dato, es necesario devolverlo con la palabra reservada return, seguido de la variable que contiene el tipo, o un tipo directamente. Ejemplo:
//Devuelve el valor contenido en strVariable.
return strVariable;
//Devuelve un string porque el mtodo donde se encuentra devuelve string.
return texto; La instruccin return tiene que ir al menos en la ltima lnea de cdigo del mtodo. Un mtodo que tiene que devolver un valor y no se le coloca la instruccin return provoca un error. Puede haber mltiples lneas con return dentro del mtodo, pero cuando se ejecuta una, automticamente se sale del mtodo. Es posible que un mtodo que no devuelve un tipo use la instruccin return. En este caso, lo que provoca, es la terminacin de la ejecucin del mtodo. No es necesario darle un valor para devolver. 3. Nombre del Mtodo. En el nombre del mtodo podemos usar cualquier carcter numrico y alfabtico, no recomendndose el uso de otros caracteres (a excepcin del guin bajo) ni acentos. El espacio en blanco est prohibido. 4. Argumentos de entrada. Cuando necesitamos que un mtodo reciba datos para procesarlos internamente, decimos que hay que pasarle argumentos de entrada. Esos argumentos se les conoce como
parmetros. Un parmetro es en realidad una variable que se define introduciendo el tipo de dato y el nombre de la variable dentro de los parntesis que van junto al nombre del mtodo. Un mtodo puede tener mltiples parmetros todos ellos separados por comas. Ejemplos: El primer mtodo acepta un parmetro de entrada de tipo int y no devuelve nada(void); el segundo, acepta tres parmetros de entrada: dos de tipo int y uno de tipo string, adems de devolver un valor string. private void Metodo1(int numero) { //Instrucciones } private string Metodo2(int num1, int num2, string texto) { //Instrucciones } Se conoce como firma del mtodo, a la estructura del mtodo, en concreto, a los parmetros de entrada. Aunque se estudiar ms adelante, como parte de la firma del mtodo no se incluye el tipo devuelto para el caso de sobrecarga de mtodos. Por el contrario, si se considera el tipo devuelto para la firma del mtodo en el caso de Delegados (tambin se estudiar ms adelante) 3.2.4.1. Los mtodos estticos. La palabra clave STATIC La palabra reservada static en la declaracin del mtodo, indica que el compilador slo debe de permitir que exista una copia en memoria del mtodo. El mtodo Main(), es un mtodo de tipo static porque sera catastrfico que existieran mltiples puntos de entrada a la aplicacin en memoria. La palabra static va despus del modificador de acceso y antes del tipo de dato que devuelve el mtodo. Ejemplo: private static void Metodo1() Cuando un mtodo es declarado como static, automticamente todo objeto que quiera ser llamado desde el mtodo static tiene que ser declarado de la misma manera. Es decir, si fuera de un mtodo static se quiere definir una variable que ser utilizada por el mtodo, se deber de definir esa variable con la palabra static, con la misma estructura que para el caso del mtodo. Ejemplo: Vamos a definir una variable dentro de la clase, llamada texto, que ser usa por un mtodo del tipo static: private static string Texto;
Ejemplo de uso de mtodos:

class Program { static void Main(string[] args) { string textodevuelto; Datos(); // Llamamos al mtodo Datos para que se ejecute. // Llamamos al mtodo pedir texto y devuelve un valor de Tipo string y lo almacena en la variable textodevuelto. textodevuelto = PedirTexto(); Console.WriteLine("El texto enviado por el mtodo es: " + textodevuelto); Console.ReadLine(); } // Definicin del mtodo llamado Datos que no devuelve ningn valor (tipo void). static private void Datos() { Console.WriteLine("Se est ejecutando el programa..."); Console.WriteLine("Pulse return para continuar..."); Console.ReadLine(); } // Definicin del mtodo llamado PedirTexto, que devuelve un string cuando es llamado. static private string PedirTexto() { Console.Write("Introduce un texto: "); string texto = Console.ReadLine(); return texto; } }
3.2.4.2. Opciones en los parmetros de entrada Hemos visto que en un mtodo su firma est marcada por el tipo y el nmero de parmetros de entrada. En el caso de los parmetros de entrada, existen tres palabras reservadas que nos van a permitir especificar la forma en la que estos parmetros son pasados al mtodo. La palabra clave ref Cuando en un parmetro de entrada lleva la palabra clave ref, significa que ese parmetro se est pasando por referencia y no por valor. El resultado de pasar un parmetro por valor, es que cualquier cambio que se produzca sobre su valor, este es actualizado inmediatamente en el origen una vez que se haya terminado de ejecutar el mtodo. Si el parmetro no es pasado como ref, dispondremos de un valor dentro del mtodo y otro distinto en la llamada.
Un parmetro que se pasa por referencia tiene que ser inicializado a un valor (para evitarlo se puede usar la palabra reservada out, que se ver ms adelante). En el esquema siguiente se puede observar que si una variable es pasada a un mtodo como parmetro por referencia, al terminar la ejecucin su valor habr cambiado. Si la pasamos por valor no cambiar.
Diferencias entre llamar a un mtodo con un parmetro por valor o por referencia
int Numero = 20; Llama a Metodo sin ref: Metodo(Numero); int Numero = 20; Llama a Metodo con ref: Metodo(ref Numero);
private void Metodo(int Num) { Num = Num * 2; }
private void Metodo(ref int Num) { Num = Num * 2; }
Resultados: Valor de Numero = 20; Valor de Num = 40;
Resultados: Valor de Numero = 40; Valor de Num = 40;
Esquema de diferencias entre un parmetro por valor o por referencia
Como podemos observar, el comportamiento de los parmetros es distinto en el caso de pasarlos por valor o por referencia. Cuando se programa, se debe de decidir cul de las dos opciones es ms beneficiosa para nuestra aplicacin. Notas a ref: Conviene saber que un objeto pasado por referencia ocupa menos espacio en memoria ram que uno que sea pasado por valor (ver grfico ms adelante). Si no queremos que el objeto original cambie sus valores y slo queremos que cambien durante la ejecucin de un mtodo, entonces nuestra solucin sera pasarlo por valor. Como hemos visto, es necesario inicializar los objetos con un valor para poder pasarlos como ref. La palabra ref tiene que ser puesta cada vez que un parmetro tiene que ser pasado por referencia. En un mtodo pueden convivir parmetros con ref y parmetros sin ref.
Si el objetivo final de pasar un objeto a un mtodo es cambiar su valor, lo razonable sera hacerlo por referencia para evitar copias innecesarias del objeto en memoria, tal y como se puede ver en el siguiente esquema:
Diferencias en la gestin de la memoria al pasar a un mtodo un parmetro por valor o por referencia
int [ ] Numeros = new int[ 5 ]; Llama a Metodo sin ref: Metodo(Numeros); Se realiza una copia exacta del objeto en memoria
Matriz NUMEROS
Referencias Valores
Matriz METODO
Referencias Valores
0 1 2 3 4
AA2C 1472 16DE BC74 FB12
21 2 10 24 15
Valores en la memoria
0 1 2 3 4
AA2C 1472 16DE BC74 FB12
21 2 10 24 15
Direcciones de memoria en Hexadecimal
int [ ] Numeros = new int[ 5 ]; Llama a Metodo con ref: Metodo(ref Numeros); Se realiza una copia en memoria pero slo de las referencias
Matriz NUMEROS
Referencias Valores
Matriz METODO
Referencias
0 1 2 3 4
AA2C 1472 16DE BC74 FB12
21 2 10 24 15
0 1 2 3 4
AA2C 1472 16DE BC74 FB12
3.2.4.3. La palabra clave OUT Su objetivo es idntico a ref, es decir, pasar parmetros por referencia en lugar de por valor. La diferencia radica en que out no obliga a inicializar los valores de las variables que son pasadas a los mtodos.
Al igual que ref, un parmetro puesto como out exige que tanto el mtodo como la llamada tengan la palabra out. Ejemplo: static void Main(string [ ] args) { string MiTexto = Texto de Prueba; Metodo(out MiTexto); } private static void Metodo(out string Texto) { Texto = Nuevo Texto de Prueba; } Ejemplo de pasar una matriz a un mtodo para que sea inicializada por el mtodo. Usaremos la palabra out en lugar de ref, ya que ref nos obligara a inicializarla antes de enviarla:
public partial class Principal : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { // Declaramos la matriz pero no la inicializamos con // valores. string[] Matriz; // Enviamos la matriz al mtodo para que sea incializada. // Usamos la palabra clave out para que no de error. DarValorMatriz(out Matriz); // Mostramos los datos que ha rellenado el mtodo en la // matriz Console.WriteLine("Los elementos en la matriz son:"); foreach (string Dato in Matriz) lblVer.Text = Dato + </br>; } private static void DarValorMatriz(out string[] arr) { // Damos valores a la matriz arr = new string[6] {"Luis", "Pedro", "Luca", "Antonio", "Mara", "Marcos"}; } }
Si bien no es necesario inicializar la variable para pasarla al mtodo usando la palabra out, una vez dentro del mtodo debe, obviamente, tomar un valor antes de devolverla. 3.2.4.4. La palabra clave PARAMS Hasta ahora, todos los mtodos, exigen que los parmetros de entrada deban de ser enviados obligatoriamente. Es decir, no podemos hacer una
llamada a un mtodo, en la cual, nos falta rellenar algn parmetro. En el caso de necesitar un mtodo que disponga de parmetros variables, usaremos la palabra clave params. Ejemplo: private void Metodo(params string [ ] ListaParametros) { foreach(string Parametro in ListaParamentros) lblVer.Text = Valor del Parametro: + Parametro; } No se permiten parmetros adicionales despus de la palabra clave params, ni tampoco la existencia de varios params. 3.2.4.5. Mtodos sobrecargados Los mtodos sobrecargados son cuando varios mtodos se llaman igual, pero tienen distintos argumentos de entrada, es decir, es como tener distintas versiones del mismo mtodo. La sobrecarga de mtodos obliga a que los parmetros de entrada sean diferentes, sin importar el tipo devuelto. Por ejemplo, un mtodo void y un mtodo que devuelve un string, si no hay ms cambios en la firma del mtodo, al compilar, dar un error. Ejemplo: private void MiMetodo(string Texto) { // Instrucciones } private void MiMetodo(int Numero) { // Instrucciones } En este ejemplo, MiMetodo, dispone de dos versiones: la primera admite un string y, la segunda, un int. Esto es a lo que se conoce como sobrecarga de mtodos. Ejemplo de sobrecarga de mtodos:
public partial class Principal : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { string[] MatrizNombres; int[] MatrizNumeros; DarValorMatriz(out MatrizNombres); DarValorMatriz(out MatrizNumeros); }
Pgina 15
//Primera versin del mtodo DarValorMatriz que admite una matriz string private static void DarValorMatriz(out string[] arr) { // Damos valores a la matriz de tipo string arr = new string[6] {"Luis", "Pedro", "Luca", "Antonio", "Mara", "Marcos"}; } //Segunda versin del mtodo DarValorMatriz que admite una matriz int private static void DarValorMatriz(out int[] arr) { // Damos valores a la matriz de tipo int arr = new int [] { 1, 4, 21, 2, 24, 3 }; } }
En este ejemplo, como se puede ver, al llamar al mtodo DarValorMatriz, la primera llamada, DarValorMatriz(out MatrizNombres), llama y ejecuta el mtodo que es string. En la segunda, DarValorMatriz(out MatrizNumeros), llama al mtodo que es int. Estas asignaciones, o elecciones del mtodo a ejecutar las hace NetFramework por si slo sin necesidad de especificrselo. Esto es posible porque comprueba la firma del mtodo en la invocacin y lo ajusta a la firma correcta. Este es el motivo por el cual no puede haber dos mtodos con el mismo nombre e idntica firma de parmetros de entrada, ya que no sabra a cual asignar. Notas a la sobrecarga de mtodos: Puede haber tantos mtodos sobrecargados como se desee. No existe lmite. Los modificadores ref y out son tratados en ejecucin de forma diferente, pero en compilacin se tratan de la misma forma, lo que significa que no podemos definir dos firmas iguales de parmetros de entrada en las que slo cambia la palabra ref o out. Por ejemplo la siguiente definicin de mtodos sobrecargados dara el siguiente error en la compilacin: no se puede definir mtodos de sobrecarga que difieran slo en ref y out. private void MiMetodo(out string Nombre) private void MiMetodo(ref string Nombre) Si slo cambiamos el parmetro de salida, es decir void o el tipo devuelto, no se considera sobrecarga y dara un error de compilacin. La siguiente definicin dara el siguiente error en la compilacin: ya define un miembro denominado 'MiMetodo' con los mismos tipos de parmetros. private int MiMetodo(string Nombre) private void MiMetodo(string Nombre)
Ms adelante en este mismo captulo, es estudiar los modificadores abstract y sealed.
3.2.5. Qu es un constructor de la clase? Cuando queremos instanciar la clase utilizamos el operador new: Flan Vainilla = new Flan(); El constructor de la clase es activado en ese momento y permite que se cree el objeto del tipo de la clase. Esto es posible porque existe un mtodo especial llamado el constructor de la clase que se ejecuta una vez hemos utilizado el operador new. Este mtodo se identifica porque es el nico que se llama igual que la clase. Es decir, si la clase se llama Flan su constructor ser: public Flan() { } Si el programador no disea un mtodo constructor de la clase, .NET crea por omisin un constructor sin parmetros, cuya nica funcin es crear la clase. En el constructor podemos hacer las mismas cosas que se hacen en cualquier mtodo. Normalmente se suele usar para inicializar los atributos de la clase que se usarn desde las propiedades, o para realizar operaciones previas a la creacin del objeto. Cuando creamos un constructor, sustituye automticamente al constructor por defecto. Los mtodos constructores permiten la sobrecarga, es decir, puede haber ms de un constructor de la clase (todos con el mismo nombre y distintos parmetros).
Pgina 17
3.2.6. Constructores estticos. Un constructor esttico se utiliza para inicializar cualquier dato esttico o realizar operaciones que slo se harn una vez. Es llamado automticamente antes de crear la primera instancia o de hacer referencia a cualquier miembro esttico. Ejemplo:
class ConstructorEstatico { //Esta variable debe de ser inicializada la primera vez que se //llame a la clase. Es una variable de slo lectura. static readonly DateTime HoraOperacion; //Constructor esttico que dar valor a la variable la primera //vez. Se ejecuta antes de que se cree la primera instancia o se //acceda a cualquier miembro. static ConstructorEstatico() { HoraOperacion = DateTime.Now; } }
Un constructor esttico tiene las siguientes caractersticas: No tiene modificadores de acceso ni admite parmetros. Se llama de forma automtica para iniciar la clase antes de crear la primera instancia o de hacer referencia a cualquier miembro esttico. El constructor esttico no puede ser llamado directamente. El usuario no puede controlar cuando se ejecuta el constructor esttico en el programa. Los constructores estticos se utilizan normalmente cuando la clase hace uso de un archivo de registro y el constructor escribe entradas en dicho archivo. Ver ejemplo: Uso ConstructoresEstaticos 3.2.7. Qu es un destructor de la clase? En el proceso de creacin del objeto del tipo de la clase, .NET asigna la cantidad de memoria necesaria para su manejo. Si no hay suficiente memoria, se lanza un mensaje del tipo: System.OutOfMemoryException. NET se encarga de liberalizar la memoria cuando ya no se necesita el objeto que se cre mediante el Garbage Collector (GC) (se ver ms adelante su funcionamiento). Esto ocurre en el momento en el que un objeto que se ha definido dentro de un mbito concreto deja de tener validez al termina de ejecutarse ese mbito. Por ejemplo, una variable de un bucle for, cuando termina el bucle (fin de mbito), entonces el Garbage Collector se encarga de limpiar la memoria que ocupaba esa variable y todos los objetos definidos dentro de ese bucle.
Antes de su destruccin permite invocar a un mtodo destructor, que nos permitir, por ejemplo, guardar informacin sobre estado de objetos, memoria, limpieza de objetos, cierre de conexiones, etc. El mtodo destructor llamar automticamente al mtodo Finalize de la clase Object (se ver ms adelante su funcionamiento). Slo puede haber un mtodo destructor por clase y es invocado automticamente. Antes de que un objeto sea destruido, .NET llama al mtodo destructor de la clase, si lo hubiera, para realizar las operaciones que el mtodo destructor tiene implementadas, como puede ser, cerrar una conexin a base de datos. Para aadirle un mtodo destructor a la clase, usaremos el smbolo ~ (alt + 126), seguido del nombre de la clase. Ejemplo: ~Flan() { // Cdigo a ejecutar. } Una clase slo puede tener un destructor. No permite modificadores de acceso ni tiene parmetros, adems no permite la sobrecarga. No se le puede llamar explcitamente, porque se hace de forma automtica por el CLR. Ver el ejemplo: Uso DestructorWin. 3.2.8. La gestin de la memoria. El Garbage Collector. Un Garbage Collector es un sistema implcito de gestin de la memoria que implementan algunos lenguajes de programacin de tipo interpretado o semi-interpretado, como son los que hay en .Net o Java. El sistema operativo pone a disposicin de los programas una cantidad de memoria, para que estos gestionen esta memoria con las siguientes caractersticas: De la memoria asignada, deben de hacer una reserva de espacios para uso del programa y los datos que contiene. Tienen que encargarse de liberar los espacios de memoria que fueran previamente reservados y ya no se necesitan. Adems, una vez liberados ciertos espacios de memoria, puede que queden espacios en blanco (memoria sin usar), entre el resto de los datos que s se estn usando y, por tanto, ha de compactar estos espacios para hacerlos consecutivos entre s (eliminado los espacios en blanco).
Pgina 19
Y por ltimo, controlar que espacios de la memoria asignada por el sistema operativo para el programa estn libres y cules no. El Garbage Collector (Recolector de Basura) es el encargado de limpiar los objetos que ya no se usan. Su funcionamiento es arbitrario y se tiene poco control sobre el momento exacto en el que se elimina el objeto, tal y como se puede observar en el ejemplo: Uso DestructorWin. Cuando un lenguaje dispone de recoleccin de basura, el programador no tiene que encargarse de la reserva de memoria, ya que este proceso es realizado por el Garbage Collector. Cada vez que declaramos un objeto en nuestro programa, se asigna de forma automtica una cantidad de memoria. Esta cantidad, en principio, no la conocemos ni la manejamos. Cuando se compila el programa automticamente se incluye en ste una subrutina que corresponde al recolector de basura. Esta subrutina tambin es invocada peridicamente sin la intervencin del programador.
Esquema del Limpieza y Compactacin del Garbage Collector El Garbage Collector verifica y asigna espacios de memoria Objeto A Objeto B
Objeto C Objeto D Objeto E
El Garbage Collector limpia el Objeto B Objeto A Objeto C Objeto D Objeto E
El Garbage Collector compacta la memoria Objeto A Objeto C
Objeto D Objeto E
El recolector de basura es informado de todas las reservas de memoria que se producen en el programa. Adems, el compilador colabora para que Memoria sin usar sea posible llevar una cuenta de todas las referencias que existen a un determinado espacio de memoria reservado. EL CLR de .Net exige que todos los recursos deban de asignarse a un concepto llamado memoria administrada, conocido como Heap. El heap no es ms que una zona reservada de memoria para ir guardando los objetos y datos que nuestra aplicacin va a usar. El CLR, por mediacin de Garbage Collector, se encarga de hacer reservas de espacio para nuestros objetos y eliminar esas reservas de espacio cuando el objeto ya no se usa. Esto es un proceso automtico, que evita los problemas que se dan en otros lenguajes, donde puede ocurrir que intentemos acceder a un recurso que no se le asigno memoria, o a un recurso que por causas desconocidas ya no est disponible. El proceso automtico de recoleccin de basura (termino que se aplica a objetos que ya no se usan), est basado en algoritmos optimizados para su uso en distintos escenarios, con el fin de obtener el mejor rendimiento en cada momento.
Su funcionamiento se realiza por mediacin de un puntero, que controlan si existe espacio suficiente para almacenar el objeto en la zona reservada. Cuando instanciamos una clase con el operador new, automticamente, el CLR, verifica que existe espacio disponible entre el puntero y el espacio total de memoria reservada. Si existe, coloca el objeto y desplaza el puntero al final de la reserva de memoria del nuevo objeto, tal y como podemos ver en el siguiente grfico. Si no dispone de memoria, realiza una recoleccin por mediacin del mtodo Collect, que veremos ms adelante.
Esquema del Heap o Memoria Administrada
Memoria Administrada Intentamos instanciar el objeto D, el CLR verifica que hay espacio disponible para su tamao entre el puntero y el final de memoria reservada. Si hay espacio, lo coloca, en caso contrario hace un Collect. Memoria Administrada
Memoria Reservada para la aplicacin, pero libre de asignacin

Posicin del Puntero Objeto C
Memoria Reservada
Posicin del Puntero
Objeto D
Objeto C ClaseD obj = new ClaseD();
Las clases, cuando son instanciadas con el operador new, son localizadas por mediacin del CLR en el montn administrado.
Objeto B
Objeto B
Objeto A
Objeto A
Las recolecciones se efectan cuando es necesaria ms memoria, o cuando pasa un tiempo concreto. Las recolecciones, efectuadas por el mtodo Collect de la clase GC, se basan en un concepto llamado Generaciones, que consiste en crear los objetos en nmeros concreto de generaciones, de tal forma, que los objetos son clasificados por su antigedad de creacin. Una generacin es una unidad de medida de la edad relativa de los objetos en la memoria. El nmero de generacin o la edad de un objeto indica la generacin a la que pertenece. Los objetos creados ms recientemente forman parte de las ltimas generaciones y tienen nmeros de generacin ms bajos que los objetos creados en fases anteriores del perodo de duracin de la aplicacin. Los objetos de la generacin ms reciente pertenecen a la generacin cero. En realidad, las generaciones son mecanismos aplicados por el Garbage Collector para mejorar el rendimiento del uso de memoria y, por extensin, nuestra aplicacin. La finalidad es que los objetos creados ms recientemente, formen parte de generaciones nuevas, mientras que los creados al principio, formen parte de generaciones antiguas. El GC realiza tareas de limpieza de la memoria por el nmero de generacin, en lugar de hacerlo para todo la memoria administrada, que sera una prdida de tiempo innecesaria. Siempre empieza
limpiando las generaciones antiguas, aunque existe la posibilidad de hacer una limpieza a una generacin concreta. Si a pesar de hacer recolecciones, an no ha sido posible liberar memoria suficiente para colocar el nuevo objeto, el sistema notifica una excepcin del tipo: OutOfMemoryException. 3.2.8.1. Cmo sabe el Garbage Collector que un objeto no se usa? El Garbage Collector, como explicamos anteriormente, limpia de la memoria todos aquellos objetos que ya han dejado de tener utilidad para la aplicacin. El conocer que un objeto est libre para su destruccin es posible gracias a un concepto llamado races (roots). Toda aplicacin tiene un conjunto de races que apuntan a los objetos que se encuentran en el Heap. Por ejemplo, todas las referencias globales y estticas que apuntan a la memoria administrada; cualquier variable local con punteros a objetos de la pila de subprocesos; registros de la CPU que apuntan tambin a objetos del Heap, forman parte de las races de la aplicacin. Todas las races activas son mantenidas por el compilador Just-In-Time(JIT) y el CLR, hacindolas accesibles a los algoritmos de limpieza del Garbage Collector. El Garbage Collector inspecciona todas las races mirando no slo a que objeto apuntan, sino tambin si ese objeto apunta a su vez a otro objeto de la memoria administrada. AL final, acaba obteniendo una grfica de que objetos estn relacionados con quien y cual est activo y cual no. Ver el siguiente esquema.
Esquema de Races (roots) dentro del Garbage Collector

Aplicacin
RAICES (roots)
Heap
Memoria Reservada
Limpieza de objetos
Objeto H Objeto G Objeto F Objeto E
Aplicacin
RAICES (roots)
Heap
Globales y Estticas
Globales y Estticas
Memoria Reservada
Objeto G Locales Objeto E Objeto D Registros CPU Objeto B Objeto A
Locales
Objeto D Objeto C
Registros CPU
Objeto B Objeto A
Toda raz activa tiene un puntero al objeto dentro del Heap. Un objeto pude apuntar a otro objeto dentro del Heap, como el objeto D al objeto G. Esto tambin se considera una raz activa. Si no hay una raz se considera basura por parte del GC.
Un objeto que despus de recorrer las races no ha sido localizado por ninguna, es un objeto que ya no se usa y por tanto puede ser recolectado en el
siguiente Collect, es lo que se llama un objeto basura. El recolector va recorriendo los objetos de forma recursiva. 3.2.8.2. La Clase GC, el Garbage Collector de .Net Dentro del espacio de nombres System, existe la clase GC. Esta clase es el Garbage Collector de .Net. El Recolector no se ejecuta como parte de nuestra aplicacin, sino que es un proceso aadido a la misma que consume recursos. Por tanto, Microsoft recomienda que su uso sea realizado de forma automtica y que no se fuerce su ejecucin. A pesar de esto, si uno quiere trabajar directamente sobre el Garbage Collector y manipularlo, existe la clase GC, que incluye ciertos mtodos para su manejo. Los mtodos de esta clase influyen en el momento en que se realiza la recoleccin de elementos no utilizados de un objeto y en el momento en que se liberan los recursos asignados por un objeto. Las propiedades de esta clase proporcionan informacin sobre la cantidad de memoria total disponible en el sistema y la categora de edad, o generacin, de la memoria asignada a un objeto. El recolector de elementos no utilizados realiza un seguimiento de los objetos asignados en la memoria administrada, y los reclama. De forma peridica, el recolector de elementos no utilizados reclama la memoria asignada a los objetos para los que no existen referencias vlidas (las races de la aplicacin, o referencias entre objetos). La recoleccin de elementos no utilizados se produce de forma automtica, cuando una solicitud de memoria no puede satisfacerse utilizando la memoria libre que queda disponible. Una aplicacin tambin puede provocar la recoleccin de elementos no utilizados mediante el mtodo Collect. La recoleccin de elementos no utilizados consta de los siguientes pasos: El recolector de elementos no utilizados busca los objetos administrados a los que se hace referencia en el cdigo administrado. El recolector de elementos no utilizados intenta finalizar los objetos a los que no se hace referencia. El recolector de elementos no utilizados libera los objetos a los que no se hace referencia y reclama la memoria utilizada por estos objetos. Durante la recoleccin de elementos no utilizados, el recolector no liberar un objeto si encuentra una o varias referencias al mismo en el cdigo administrado. El recolector de elementos no utilizados no reconoce, sin
embargo, las referencias a objetos desde el cdigo no administrado y puede liberar objetos que se estn utilizando exclusivamente en cdigo no administrado, a menos que se le impida hacerlo de forma explcita. El mtodo KeepAlive proporciona un mecanismo que impide que el recolector de elementos no utilizados recoja objetos que an estn en uso en el cdigo no administrado. Salvo en el caso de las asignaciones de memoria administrada, las implementaciones del recolector de elementos no utilizados no incluyen informacin sobre los recursos mantenidos por un objeto, como los identificadores de archivo o las conexiones de base de datos. Cuando un tipo utiliza recursos no administrados que deben liberarse antes de que se reclamen las instancias del tipo, ste puede implementar un finalizador. En la mayora de los casos, los finalizadores se implementan reemplazando el mtodo Finalize; no obstante, los tipos escritos en C# o C++ implementan destructores (vistos anteriormente), que los compiladores convierten en un reemplazo del mtodo Finalize. En la mayora de los casos, si un objeto tiene un finalizador, el recolector de elementos no utilizados llama a dicho finalizador antes de liberar el objeto. Sin embargo, el recolector de elementos no utilizados no debe llamar a los finalizadores en todas las situaciones; por ejemplo, el mtodo SuppressFinalize evita explcitamente que se llame a un finalizador. Adems, el recolector de elementos no utilizados no tiene por qu utilizar un subproceso especfico para finalizar objetos ni tampoco tiene por qu garantizar el orden en que se llama a los finalizadores para objetos que se hacen referencia mutuamente pero que sin embargo estn disponibles para su recoleccin. En los escenarios en los que los recursos deben liberarse en un momento determinado, las clases pueden implementar la interfaz IDisposable, que contiene el mtodo Dispose que realiza tareas de administracin y limpieza de recursos. Las clases que implementan Dispose deben especificar, como parte de su contrato de clase, si los consumidores de la clase van a llamar al mtodo para limpiar el objeto y cundo van a hacerlo. El recolector de elementos no utilizados no llama al mtodo Dispose de forma predeterminada; sin embargo, las implementaciones del mtodo Dispose pueden llamar a los mtodos de la clase GC para personalizar el comportamiento de finalizacin del recolector. Aunque no es obligatorio, se recomienda que los recolectores de elementos no utilizados admitan la caducidad de objetos mediante el uso de generaciones. Una generacin es una unidad de medida de la edad relativa de los objetos en la memoria. El nmero de generacin o la edad de un objeto indica la generacin a la que pertenece. Los objetos creados ms recientemente forman parte de las ltimas generaciones y tienen nmeros de
generacin ms bajos que los objetos creados en fases anteriores del perodo de duracin de la aplicacin. Los objetos de la generacin ms reciente pertenecen a la generacin cero. Mtodos usuales de la clase esttica GC (Garbage Collector): Collect(). Fuerza al recolector a ejecutarse limpiando los objetos no usados y compactando la memoria. Si se quiere hacer un uso de este mtodo, podra ser una idea hacerlo antes de asignar memoria para un objeto, es decir, antes de instanciarlo. CollectionCount(int). Devuelve el nmero de veces que se ha producido una recoleccin. Si implementamos nuestra propia administracin de recursos, es posible que se necesite forzar la recoleccin de elementos no utilizados peridicamente llamando al mtodo Collect. Dado que sta es una operacin costosa, se puede mejorar el rendimiento si se omite la llamada cuando se ha producido recientemente una recoleccin de elementos no utilizados. Para conseguirlo, hay que guardar el valor devuelto por CollectionCount justo despus de llamar a Collect. La prxima vez que se necesite llamar a Collect, se compara el valor actual devuelto por CollectionCount y el valor guardado. Si los dos valores son iguales significa que no se ha producido ninguna recoleccin en ese perodo de tiempo y sera razonable volver a llamar a Collect. Se puede ver un ejemplo de todo esto en Uso de GarbageCollector. GetGeneration(object). Especificando un objeto, nos devuelve el nmero de generacin en la que se encuentra. GetTotalMemory(bool). Permite conocer la memoria total asignada en bytes. Si se pone true en la llamada al mtodo, entonces esperar a recolectar los objetos inutilizados para dar el valor de la memoria. En caso de false, devuelve la cantidad de bytes ocupados sin hacer una recoleccin de objetos previa. KeepAlive(objeto). La finalidad del mtodo KeepAlive es garantizar la existencia de una referencia a un objeto que tenga probabilidades de ser reclamado prematuramente por el recolector de elementos no utilizados. Un escenario comn en el que podra darse esta situacin es cuando no existen referencias al objeto en el cdigo administrado o en los datos, pero el objeto todava se utiliza en el cdigo no administrado, como en las API Win32, las DLL no administradas o los mtodos que utilizan COM. SuppressFinalize(objeto). Solicita al sistema que no llame al finalizador del objeto seleccionado.
Pgina 25
Propiedades para GC MaxGeneration. Devuelve el nmero mximo de generaciones que admite en ese momento el sistema. El nmero de generacin o la edad es una medida relativa a duracin de un objeto que se define en la implementacin. Los objetos creados ms recientemente pertenecen a la generacin cero y los objetos ms antiguos pertenecen a una generacin menor o igual a la generacin devuelta por la propiedad MaxGeneration. El recolector de elementos no utilizados asume que la memoria ms nueva tiene ms posibilidades de ser elegida para la recoleccin de elementos no utilizados que la memoria ms antigua. Por lo tanto, el recolector de elementos no utilizados mejora su rendimiento ajustando los nmeros de generacin cada vez que reclama memoria, y el valor de la propiedad MaxGeneration puede aumentar con el tiempo. Si se implementa la edad de los objetos, la propiedad MaxGeneration devuelve el nmero de generacin mximo utilizado por el sistema; en caso contrario, esta propiedad devuelve cero. Para esta implementacin, se garantiza que el valor devuelto por la propiedad MaxGeneration se va a mantener constante durante el perodo de duracin de una aplicacin en ejecucin. Esta propiedad se utiliza para determinar el valor mximo que puede especificarse al llamar al mtodo Collect cuando toma un parmetro de generacin. 3.2.8.3. El mtodo Object.Finalize() Este mtodo se invoca de forma automtica cuando un objeto pase a ser inaccesible, salvo que previamente y mediante el mtodo SuppressFinalize de la clase GC, haya sido excluido del proceso de finalizacin. Slo se realiza una llamada al mtodo Finalize para una instancia especfica, a menos que el objeto vuelva a registrarse mediante un mecanismo como ReRegisterForFinalize y no se haya llamado posteriormente a SuppressFinalize. Cualquier implementacin de Finalize en un tipo derivado (herencia), deben llamar a la correspondiente implementacin de tipo base de Finalize.
Este es el nico caso en el que se permite al cdigo de la aplicacin llamar a Finalize. Las operaciones de Finalize tienen las siguientes limitaciones: El momento exacto en que se ejecuta el finalizador durante la recoleccin de elementos no utilizados no est definido. No se garantiza la liberacin de recursos en un momento concreto, a menos que se llame a un mtodo Close o a un mtodo Dispose. No se garantiza que los finalizadores de dos objetos se ejecuten en un orden determinado, aunque un objeto haga referencia al otro. Es decir, si el objeto A hace referencia al objeto B y ambos tienen finalizadores, puede que el objeto B ya haya terminado cuando se inicie el finalizador del objeto A. No se ha especificado el subproceso en el que se ejecuta el finalizador. Puede que el mtodo Finalize no se ejecute hasta su finalizacin o puede que no llegue a ejecutarse en las siguientes circunstancias excepcionales: Otro finalizador se ha bloqueado de forma indefinida (entra en un bucle infinito, intenta obtener un bloqueo que nunca puede conseguir, etc.). Como el motor en tiempo de ejecucin intenta ejecutar los finalizadores hasta su terminacin, puede que no se llame a otros finalizadores si un finalizador se bloquea de forma indefinida. El proceso termina sin que el motor en tiempo de ejecucin pueda efectuar una limpieza. En este caso, la primera notificacin de terminacin del proceso por parte del motor en tiempo de ejecucin es una notificacin DLL_PROCESS_DETACH. Finalize puede llevar a cabo cualquier accin, como el restablecimiento de un objeto (es decir, hacer que el objeto vuelva a ser accesible, tambin conocido como revivir) despus de su limpieza durante la recoleccin de elementos no utilizados. Sin embargo, el objeto slo puede restablecerse una vez; no se puede llamar a Finalize en objetos restablecidos durante la recoleccin de elementos no utilizados. Los destructores de la clase son el mecanismo de C# para realizar operaciones de limpieza. Proporcionan mecanismos de proteccin apropiados, como la llamada automtica al destructor de tipo base. De todas formas, un tipo debe implementar Finalize cuando utiliza recursos no administrados, como identificadores de archivo o conexiones de base de datos que deben liberarse cuando se reclama el objeto administrado que los utiliza. Por mediacin del mtodo Dipose de la clase IDisposable, podemos tener un medio complementario y ms controlable de eliminar recursos.
3.2.8.4. El mtodo IDisposable.Dispose() Este mtodo se utiliza para cerrar o liberar recursos no administrados como son archivos, secuencias e identificadores que una instancia mantiene de la clase que implementa esta interfaz. El objetivo es liberar todos los recursos de un objeto o todas las tareas relacionadas con la preparacin de un objeto para que este vuelva a utilizarse. Cuando realizamos una implementacin del mtodo Dispose() en nuestra clase, debemos de asegurarnos que se liberan todos los recursos utilizados mediante la propagacin de la llamada a travs de la jerarqua de contencin. Por ejemplo, Si el Objeto A, llama al objeto B y este al objeto C, en ese caso, la implementacin del Dispose de A debe llamar al Dispose de B y este a su vez al Dispose de C. Si se implementa la interfaz IDisposable, adems, el mtodo Dispose de la clase debe de llamar al mtodo Dispose de la clase Base. Igualmente, debemos de controlar en la implementacin del mtodo Dispose, que slo se le llama una vez, descartando todas las llamadas que se realicen al mtodo, despus de la primera. Si llamamos varias veces al mtodo Dispose, este realizar una excepcin del tipo ObjectDisposeException, debido a que ya se han desechado los recursos. Como debe llamarse al mtodo Dispose de forma explcita, los objetos que implementan IDisposable tambin deben implementar un finalizador para controlar la liberacin de los recursos cuando no se llama a Dispose. De forma predeterminada, el recolector de elementos no utilizados llama automticamente al finalizador de un objeto antes de reclamar su memoria. Sin embargo, una vez que se ha llamado al mtodo Dispose, no suele ser necesario que el recolector de elementos no utilizados llame al finalizador del objeto desechado. Para evitar una finalizacin automtica, las implementaciones de Dispose pueden llamar al mtodo SuppressFinalize, del Garbage Collector. 3.2.9. Las Partial Class Una clase parcial, o Partial Class, es una clase que est definida en varias declaraciones de clases con el mismo nombre, pero todas con la palabra partial por delante y ubicadas en el mismo espacio de nombres, o espacio de tipo. A la hora de la compilacin, todas las partial son fusionadas en una. Sola clase. Ejemplo de declaracin de una clase partial: public partial class ClaseA
Pgina 28
3.3. Las Estructuras

Las estructuras son similares a las clases en que pueden representar estructuras de datos que pueden contener miembros de datos y miembros de funcin. No obstante, a diferencia de las clases, las estructuras son tipos de valores y no requieren asignacin del montn. Una variable de un tipo de estructura contiene directamente los datos de la estructura, mientras que una variable de un tipo de clase contiene una referencia a los datos, que se conocer posteriormente como objeto. Las estructuras son particularmente tiles para estructuras de datos pequeas que tienen semnticas de valor. Los nmeros complejos, los puntos de un sistema de coordenadas o los pares de valores clave de un diccionario son buenos ejemplos de estructuras. La clave de estas estructuras de datos es que tienen pocos miembros de datos, que no necesitan utilizar herencia o identidad referencial y que pueden ser implementadas convenientemente utilizando semnticas de valor donde la asignacin copia el valor en lugar de la referencia. Definicin de una estructura: public struct PostalAddress { Implementacin de campos, propiedades, mtodos y eventos. } Toda estructura, al igual que las clases tiene un modificador de acceso, que en este caso, puede ser solamente: Public, Internal o Private. Los modificadores Protected y Protected Internal, no son aplicables dado que las estructuras a diferencia de las clases, no permiten herencia. A continuacin del modificador de acceso lleva la palabra reservada struct, que indica que este fragmento de cdigo es una estructura. Por ltimo el nombre de la estructura, que mantiene las mismas condiciones que para una clase, no se puede utilizar espacios en blanco ni algunos caracteres especiales. El modificador partial, al igual que en las clases, indica que esa declaracin de estructura es una declaracin de tipo parcial. Lo que significa que puede haber ms implementaciones de estructuras con el mismo nombre dentro del mismo espacio de nombres, pero todas con la palabra partial por delante. A la hora de la compilacin, todas las estructuras partial son fusionadas en una sola.
Pgina 29
Aunque no pueden heredar ni de clases, ni de otras estructuras, si que pueden implementar interfaces. Ejemplo de uso de estructuras: Uso Estructuras.
public struct CoOrds { public int x, y; public CoOrds(int p1, int p2) { //Si no se pasan valores en la llamada al //constructor. //Pone valores por defecto para el tipo. x = p1; y = p2; } } class Program { static void Main(string[] args) { // Inicializa los valores: CoOrds coords1 = new CoOrds(); CoOrds coords2 = new CoOrds(10, 10); // Muestra el resultado: Console.Write("CoOrds 1: "); Console.WriteLine("x = {0}, y = {1}", coords1.x, coords1.y); Console.Write("CoOrds 2: "); Console.WriteLine("x = {0}, y = {1}", coords2.x, coords2.y); } }
3.3.1. Diferencias entre Clases y Estructuras Casi todas las estructuras comparten la misma sintaxis que las clases, aunque estn ms limitadas que stas: Dentro de una declaracin de estructura, los campos no se pueden inicializar a menos que se declaren como constantes o estticos. Una estructura no puede declarar un constructor predeterminado (es decir, un constructor sin parmetros) ni un destructor. Las estructuras no pueden heredar de clases u otras estructuras. Las estructuras se copian en la asignacin. Cuando se asigna una estructura a una nueva variable, se copian todos los datos, y cualquier modificacin que se realice en la nueva copia no afecta a los datos de la copia original. Las estructuras son tipos de valor y las clases son tipos de referencia.
A diferencia de las clases, se pueden crear instancias de las estructuras sin utilizar un operador new. Las estructuras pueden declarar constructores que tienen parmetros. Una estructura no puede heredar de otra estructura o clase, ni puede ser la base de una clase. Todas las estructuras heredan directamente de System.ValueType, que hereda de System.Object. Una estructura puede implementar interfaces. Una estructura se puede utilizar como tipo que acepta valores null y se le puede asignar un valor null. Los tipos de estructura nunca son abstractos y son siempre sellados implcitamente. Por lo tanto, los modificadores abstract y sealed no estn permitidos en una declaracin de estructura. Debido a que las estructuras no permiten la herencia, la accesibilidad declarada de un miembro de estructura no puede ser protected ni protected internal. Los miembros de funcin de una estructura no pueden ser abstract ni virtual, y slo se permite el modificador override para invalidar mtodos heredados de System.ValueType. La asignacin a una variable de un tipo struct crea una copia del valor que se asigne. Esto difiere de la asignacin a una variable de un tipo de clase, que copia la referencia pero no el objeto identificado por la referencia. De forma similar a una asignacin, cuando se pasa una estructura como parmetro de valor o se devuelve como resultado de un miembro de funcin, se crea una copia de la estructura. Una estructura se puede pasar por referencia a un miembro de funcin utilizando un parmetro ref u out. Cuando una propiedad o un indizador de una estructura es el destino de una asignacin, la expresin de instancia asociada con el acceso a la propiedad o indizador debe estar clasificada como una variable. Si la expresin de instancia est clasificada como un valor, se produce un error de compilacin En cuanto a los constructores estticos (static) para estructuras, siguen la mayora de las mismas reglas que las clases. La ejecucin de un constructor esttico para un tipo struct la desencadena el primero de los siguientes eventos que se produzcan en un dominio de aplicacin: Se hace referencia a un miembro de instancia del tipo struct. Se hace referencia a un miembro esttico del tipo struct. Se llama a un constructor explcitamente declarado del tipo struct.
Pgina 31
3.4. La Herencia de clases

La herencia es una de las cualidades ms importantes de la Programacin Orientada a Objetos (POO), porque permite que una clase herede todas las caractersticas definidas en la clase base, o la clase de la que hereda. Lo nico que no se puede heredar son los mtodos constructores y los destructores. La herencia se realiza a travs de una derivacin, lo que significa que una clase se declara utilizando una clase base de la cual hereda los datos y el comportamiento. Para declarar una herencia, debemos de colocar dos puntos en el nombre de la class que estamos definiendo y, a continuacin el nombre de la clase base, o clase de la que hereda. Ejemplo: Class Empleado : EmpleadoBase { //Atributos, propiedades y mtodos. } En este ejemplo, la clase empleado hereda de EmpleadoBase. Todas las clases mantiene una estructura jerrquica. Toda clase pertenece siempre a una clase superior o superclase (se conoce con el nombre de clase base). Una clase puede contener una o varias subclases, tambin llamadas clases derivadas. Existe una clase llamada Object, que es la clase raz de toda la jerarqua de clases de la biblioteca .NET. Por tanto, todas las clases que diseemos, pertenecern en ltima instancia a la clase Object. En C#, a diferencia de C++, la herencia es simple, es decir, slo puede heredar de una clase a la vez. Sin embargo, dado que una clase base puede a su vez heredar de otra clase, tenemos que una clase puede en realidad heredar de varias. Ver los siguientes esquemas:
Super Clase Object
Clase EmpleadoBase
Clase Empleado
Pgina 32
El siguiente esquema muestra como los distintos, atributos propiedades y mtodos de una clase son pasados a la siguiente por mediacin de la herencia:
Esquema de la Herencia entre clases
Object : EmpleadoBase Super Class Object Equals() GetHashCode() GetType() ToString() Class EmpleadoBase Equals() GetHashCode() GetType() ToString() int IDEmpleado string NomEmpleado string ApellidosEmple string DNI EmpleadoBase : Empleado Class Empleado Equals() GetHashCode() GetType() ToString() int IDEmpleado string NomEmpleado string ApellidosEmple string DNI CalcularSalario() Miembros Heredados. float Salario
Ejemplo: Uso HerenciadeClases. Una subclase puede incorporar nuevos mtodos, propiedades y atributos. Dado que el constructor de la clase no es heredable, podemos hacer un constructor en la subclase que tome los valores del constructor de la clase superior. Esto se consigue utilizando la palabra clave: base. Ejemplo: Uso HerenciadeClasesConstructor.
3.4.1. Cambiar el funcionamiento de miembros en la subclase. Modificacin de los mtodos. 3.4.1.1. La palabra clave New. Una clase derivada o subclase nos permite modificar cualquier mtodo heredado de clase base. El objetivo de esta funcionalidad es redefinir el funcionamiento del mtodo en la subclase. El mtodo ha redefinir se llamar igual que en la clase base, con los mismo parmetros y devolver el mismo tipo de informacin. Tan slo se puede cambiar el contenido del mtodo, es decir, el espacio entre las dos llaves. Para ello, se usa la palabra new antes del tipo devuelto por el mtodo: public new void MetodoPrincipal(int numero)
Pgina 33
El nuevo mtodo redefinido sustituye (oculta) al que tena la clase base, pero no lo elimina. Si instanciamos la subclase y en algn momento deseamos llamar al mtodo pero tal y como est en la clase base, utilizaremos la palabra reservada base. Ejemplo: Uso HerenciaClasesRedefinir Cuando usamos new como modificador del mtodo, oculta explcitamente un miembro heredado de una clase base. En este caso, la ocultacin reemplaza a la versin de la clase base. Aunque se puede ocultar mtodos de la clase base sin usar la palabra new, el compilador dar un mensaje de advertencia. Usando new, desaparece esta advertencia y registra la versin derivada como un reemplazo del mtodo de la clase base. El modificador New puede ser aplicado tambin atributos, propiedades, constantes, clases y estructuras. Ejemplo de uso aplicado a un mtodo:
public class ClaseA { public int x; public void MetodoInvoke() { } } public class ClaseDerivadaA : ClaseA { new public void MetodoInvoke() { } }
Ejemplo de uso aplicado a una variable o atributo de la clase:

public class ClaseB { public static int x = 55; public static int y = 22; } public class ClaseDerivadaB : ClaseB { // Oculta el campo X en la clase derivada. new public static int x = 100; public void Metodo() { // Muestra el nuevo valor de x: MessageBox.Show(X); // Muestra el valor oculto de x: MessageBox.Show(ClaseB.x); // Muestra el valor no oculto de y: MessageBox.Show(y); } }
Pgina 34
Ejemplo aplicado a Clases:

public class ClaseC { public class AnidadaC { public int x = 200; public int y; } } public class DerivadaC : ClaseC { // Oculta la clase AnidadaC de la ClaseC. new public class AnidadaC { public int x = 100; public int y; public int z; } static void Main() { // Creando Objetos desde la clase AnidadaC que oculta // a la clase AnidadaC de la clase Base: AnidadaC c1 = new AnidadaC(); // Creando Objetos desde la clase AnidadaC original: ClaseC.AnidadaC c2 = new ClaseC.AnidadaC(); MessageBox.Show (c1.x); MessageBox.Show (c2.x); } }
Este ltimo ejemplo est ocultando una clase anidada (AnidadaC), perteneciente a la clase de la que ha heredado: DerivadaC. Cuando usamos en el cdigo directamente AnidadaC, oculta la de la clase base y utiliza la clase que lleva el modificador new. Para usar la original, debemos de llamar primero a ClaseC y a continuacin a AnidadaC: ClaseC.AnidadaC c2 = new ClaseC.AnidadaC();
3.4.1.2. La palabra clave Override. El modificador Override es necesario para ampliar o modificar la implementacin abstracta o virtual de un mtodo, propiedad, indizador o evento heredado. Un mtodo override proporciona una nueva implementacin del miembro que se hereda de una clase base. El mtodo invalidado por una declaracin override se conoce como mtodo base invalidado. El mtodo que invalida al heredado, debe de tener la misma firma. Es decir, slo se puede cambiar el contenido o funcionalidad del mtodo, nunca la firma.
No se puede intentar invalidar un mtodo esttico o no virtual. Es decir, es necesario definir el mtodo en la clase base como virtual, abstract u override para poder aplicar el modificador override en la clase derivada. Si se trata de modificar un mtodo definido como override en la clase base, no podemos usar en la clase derivada los modificadores: new, static, virtual o abstract. Si nos referimos a propiedades de la clase, no podemos invalidar una propiedad en la clase derivada sin especificar el mismo modificador de acceso, tipo y nombre que la propiedad heredada. La propiedad invalidada debe ser virtual, abstract u override.
3.4.1.3. La palabra reservada Abstract El modificador abstract se puede utilizar con clases, mtodos, propiedades, indizadores y eventos. Se usa para indicar que la clase o miembro de la clase, debe de ser implementado por clases derivadas a la clase abstracta, o miembro abstracto. Las clases de tipo abstract presentan las siguientes caractersticas: No se pueden crear instancias de una clase abstracta. Una clase abstracta puede contener descriptores de acceso y mtodos abstractos. No se puede modificar una clase abstracta con el modificador sealed porque sealed impide que se herede la clase. Una clase no abstracta derivada de una clase abstracta debe incluir implementaciones reales de todos los descriptores de acceso y mtodos abstractos heredados. Utilice el modificador abstract en una declaracin de mtodo o propiedad para indicar que el mtodo o la propiedad no contienen implementacin. Los mtodos abstractos presentan las siguientes caractersticas: Un mtodo abstracto es, implcitamente, un mtodo virtual. Las declaraciones de mtodos abstractos slo se permiten en clases abstractas. Debido a que una declaracin de mtodo abstracto no proporciona una implementacin, no existe cuerpo del mtodo; la declaracin de mtodo finaliza simplemente con un punto y coma y sin llaves ({ }) despus de la firma. Por ejemplo: public abstract void MyMethod();
La implementacin la proporciona un mtodo de reemplazo override, que es miembro de una clase no abstracta. Utilizar los modificadores static o virtual en una declaracin de mtodo abstracto produce un error. Las propiedades abstractas funcionan como los mtodos abstractos, salvo las diferencias en la sintaxis de las declaraciones y llamadas. Es incorrecto utilizar el modificador abstract para una propiedad esttica. Una propiedad abstracta heredada se puede reemplazar en una clase derivada si se incluye una declaracin de propiedad que utilice el modificador override. Una clase abstracta debe proporcionar implementaciones para todos los miembros de la interfaz. Una clase abstracta que implementa una interfaz podra asignar los mtodos de la interfaz a mtodos abstractos. Por ejemplo:
interface MiInterface { void Metodo(); } abstract class C : MiInterface { public abstract void Metodo(); }
Ejemplo de clases y miembros abstractos: Uso Abstract. En el ejemplo, la clase ClaseDerivada se deriva de una clase abstracta ClaseBase. La clase abstracta contiene un mtodo abstracto, AbstractMethod, y dos propiedades abstractas, X e Y. En la ClaseDerivada, por mediacin de override, se invalidan los miembros abstract por sus implementaciones. 3.4.1.4. La palabra reservada Sealed El modificador sealed, cuando se aplica a una clase, impide que otras clases hereden de esa clase. Por ejemplo:
class ClaseA { internal int Numero; } sealed class ClaseB : ClaseA { internal string Texto; }
En este ejemplo, la ClaseB es sealed, lo que significa que no deja que se herede de ella. Pero eso no le impide que esta clase pueda heredar de otras clases, como por ejemplo, de la ClaseA.
El modificador sealed tambin puede utilizarse en un mtodo o propiedad que invalide un mtodo o propiedad virtual en una clase base. De esta forma, se puede permitir la derivacin de clases de la clase e impedir que se invaliden determinados mtodos o propiedades virtuales. Ver el siguiente ejemplo del uso de sealed:
class ClaseX { protected virtual void F() { MessageBox.Show("X.F"); } protected virtual void F2() { MessageBox.Show("X.F2"); } } class ClaseY : ClaseX { sealed protected override void F() { MessageBox.Show("Y.F"); } protected override void F2() { MessageBox.Show("X.F3"); } } class ClaseZ : ClaseY { // Si se intenta invalidar el mtodo F en esta clase, tal y // como se puede ver: // protected override void F() { MessageBox.Show("C.F"); } // dara el error CS0239 durante la compilacin: // Por el contrario, al no ser un mtodo sealed, F2, si // permite su invalidacin. protected override void F2() { MessageBox.Show ("Z.F2"); } }
Conclusin a la herencia: 1. La subclase hereda todos los mtodos y propiedades de la clase base. 2. Asimismo la subclase puede incorporar nuevos mtodos y propiedades. Si la subclase crea un mtodo con idntico nombre al de la superclase, el mtodo de esta ltima se oculta y no puede ser accedido directamente. Para poder hacerlo se usar la palabra reservada base, seguido del nombre del mtodo: base.NombreMetodoPrincipal 3. Los objetos Private de la Superclase no son accesibles por la subclase. 4. Los objetos Protected, Intenal y Public s son accesibles por la subclase. 5. Los mtodos Protected se comportan como si fueran Private para otros mtodos de otras clases, pero no para los mtodos de la subclase, con
independencia del espacio de nombres al que pertenezcan, para lo cual son a todos los efectos Public. 6. Los miembros heredados por una subclase, pueden a su vez, ser heredados por otras subclase, lo que se conoce como propagacin de la herencia.
Pgina 39
3.5. Polimorfismo
Se conoce como polimorfismo la posibilidad de asumir muchas formas. En nuestro caso, es la posibilidad de que un mtodo definido en una superclase pueda ser redefinido en sus clases derivas, pero usando siempre el acceso por referencia a la Superclase. En C#, el polimorfismo se consigue definiendo los mtodos de la superclase que se deben comportar as como virtual y los mtodos del mismo nombre en las clases derivadas, como override. En .Net, cada tipo es polimrfico porque todos los tipos, incluidos los tipos definidos por el usuario, heredan de Object. A menudo se hace referencia al polimorfismo como el tercer pilar de la programacin orientada a objetos, tras la encapsulacin y la herencia. El trmino polimorfismo es una palabra griega que significa "con muchas formas" y tiene dos aspectos que lo caracterizan: En tiempo de ejecucin, los objetos de una clase derivada se pueden tratar como objetos de una clase base en lugares como parmetros de mtodo y colecciones o matrices. Cuando esto sucede, el tipo declarado del objeto ya no es idntico a su tipo en tiempo de ejecucin. Las clases base pueden definir e implementar mtodos virtuales y las clases derivadas pueden invalidarlos (override), lo que significa que proporcionan su propia definicin e implementacin. En tiempo de ejecucin, cuando el cdigo de cliente llama al mtodo, CLR busca el tipo en tiempo de ejecucin del objeto e invoca esta invalidacin del mtodo virtual. As, en el cdigo fuente puede llamar a un mtodo de una clase base y provocar la ejecucin de la versin de clase derivada del mtodo. Los mtodos virtuales permiten trabajar con grupos de objetos relacionados de una manera uniforme. Por ejemplo, supongamos que disponemos de una aplicacin de dibujo que permite a un usuario crear varios tipos de formas en una superficie de dibujo. En tiempo de compilacin no se conocen los tipos especficos de formas que crear el usuario. Sin embargo, la aplicacin tiene que realizar el seguimiento de los diferentes tipos de formas que se crean y tiene que actualizarlos como respuesta a las acciones del usuario. Se puede utilizar el polimorfismo para resolver este problema en dos pasos bsicos: Se creea una jerarqua de clases en la que cada clase de forma especfica derive de una clase base comn. Se utiliza un mtodo virtual para invocar el mtodo adecuado de una clase derivada a travs de una nica llamada al mtodo de clase base.
Ver Ejemplo: Uso Polimorfismo. Explicacin del ejemplo: En primer lugar, se crea una clase base llamada Shape y clases derivadas como Rectangle, Circle y Triangle. Se incluye en la clase Shape un mtodo virtual llamado Draw y se invalida en cada clase derivada para dibujar la forma determinada que representa la clase. Se crea un objeto List<Shape> y se agrega elementos Circle, Triangle y Rectangle a l. Para actualizar la superficie de dibujo, se utiliza un bucle foreach para recorrer en iteracin la lista y llamar al mtodo Draw en cada objeto Shape de la lista. Aunque cada objeto de la lista tiene un tipo declarado de Shape, es el tipo en tiempo de ejecucin (la versin invalidada del mtodo en cada clase derivada) al que se invocar.
Pgina 41
3.6. Interfaces
Las interfaces, al igual que las clases, definen un conjunto de miembros, pero a diferencia de estas, no proporcionan la implementacin para los miembros. Una interface slo puede contener como miembros: mtodos, propiedades, eventos e indizadores. Una interfaz tiene un modificador de acceso, al igual que las clases y con los mismas aplicaciones; a continuacin la palabra clave interface; y despus el nombre de la interfaz. Ejemplo:
public interface IFecha { int Dia(); int Mes(); int Year(); } class CuentaAhorro : Cuenta, IFecha { public int Dia() { return DateTime.Now.Day; } public int Mes() { return DateTime.Now.Month; } public int Year() { return DateTime.Now.Year; } }
En este ejemplo que acabamos de ver, hemos definido una clase llamada, CuentaAhorro, que hereda de una clase base llamada Cuenta. Adems, hereda de una interfaz llamada IFecha, pero IFecha slo contiene la firma de los mtodos que debemos implementar en la clase. Por eso, dentro de la clase CuentaAhorro, hacemos la implementacin del cdigo de los mtodos que fueron definidos en la interfaz IFecha. Una interfaz puede heredar de ms de una interfaz y puede ser definida dentro de un espacio de nombres o dentro de una clase. Aunque en C# slo admite la herencia bsica, es decir, slo puede heredar de una clase, en cuanto a la herencia de interfaz, permite tantas como se quiera. La siguiente declaracin de una class estara permitida: class CuentaAhorro : Cuenta, IFecha, IDatos
Una clase que implementa una interfaz puede implementar explcitamente miembros de esa interfaz. A un miembro implementado explcitamente slo se puede tener acceso mediante una instancia de la interfaz, y no mediante una instancia de la clase. Todos los miembros de una interfaz tienen nivel de acceso public de forma automtica. Por ejemplo: si una clase implementa dos interfaces que contienen un miembro con la misma firma, la implementacin de ese miembro en la clase har que ambas interfaces usen ese miembro como implementacin. Por ejemplo:
interface IControl { void Paint(); } interface ISurface { void Paint(); } class EjemploInterfaz : IControl, ISurface { //Ambas:ISurface.Paint y IControl.Paint llaman a este mtodo. public void Paint() { } }
Si el mtodo Paint de las dos interfaz tuviera una firma diferente en cada una de ellas, esta implementacin que acabamos de ver dara un error. Para solucionarlo, es necesario implementar la interfaz y su mtodo de forma explcita. Para ello, usamos una instancia de la interfaz, en lugar de una instancia de la clase, tal y como podemos ver en el siguiente ejemplo:
interface IControl { void Paint(); } interface ISurface { string Paint(); } public class EjemploInterfazExpli : IControl, ISurface { void IControl.Paint() { MessageBox.Show("IControl.Paint"); } string ISurface.Paint() { MessageBox.Show ("ISurface.Paint"); return " "; } }
Pgina 43
public partial class Principal : Form { private void Metodo(object sender, EventArgs e) { EjemploInterfazExpli objEjemplo = new EjemploInterfazExpli(); //Instanciamos la Interfaz en lugar de la Class IControl objIControl = (IControl)objEjemplo; objIControl.Paint(); //Muestra en pantalla "IControl.Paint" ISurface objISurface = (ISurface)objEjemplo; objISurface.Paint(); //Muestra en pantalla "ISurface.Paint" } }
Para implementar un miembro de interfaz, el miembro correspondiente de la clase debe ser pblico, no esttico y tener el mismo nombre y la misma firma que el miembro de interfaz. Las propiedades e indizadores de una clase pueden definir descriptores de acceso adicionales para una propiedad o indizador definidos en una interfaz. Por ejemplo, una interfaz puede declarar una propiedad con un descriptor de acceso get, pero la clase que implementa la interfaz puede declarar la misma propiedad con descriptores de acceso get y set. Sin embargo, si la propiedad o el indizador utiliza una implementacin explcita, los descriptores de acceso deben coincidir. Las interfaces pueden heredar otras interfaces. Es posible que una clase herede una interfaz varias veces, a travs de las clases base o interfaces que hereda. En ese caso, la clase slo puede implementar la interfaz una vez, siempre que sta se declare como parte de la nueva clase. Si la interfaz heredada no est declarada como parte de la nueva clase, la clase base que la declar proporcionar su implementacin. Es posible que una clase base implemente miembros de interfaz a travs de miembros virtuales. En ese caso, la clase que hereda la interfaz puede cambiar el comportamiento de la interfaz reemplazando los miembros virtuales. Una interfaz tiene las siguientes propiedades: Una interfaz es como una clase base abstracta: cualquier tipo no abstracto que hereda la interfaz debe implementar todos sus miembros. No se pueden crear instancias directamente de una interfaz. Las interfaces pueden contener eventos, mtodos, indizadores y propiedades. Las interfaces no contienen implementaciones de mtodos. Las clases y estructuras se pueden heredar de ms de una interfaz. Una interfaz se puede heredar de varias interfaces.
Pgina 44
Objetivo de la Interface: 1. Declarar mtodos que una o ms clases deben de implementar en determinadas situaciones. 2. Publicar la interface de programacin de una clase sin descubrir cmo estn implementados los mtodos. 3. Permitira agrupar las clases en matriz objetos y aplicar polimorfismo.
Las clases Static y su miembros

Una clase esttica es bsicamente igual que una clase no esttica, pero existe una diferencia: no se pueden crear instancias de una clase esttica. En otras palabras, no se puede utilizar la palabra clave new para crear una variable del tipo clase. Dado que no hay ninguna variable de instancia, el acceso a los miembros de una clase esttica se realiza mediante el propio nombre de clase. Por ejemplo, si tenemos una clase esttica que llamada Persona e incluye un mtodo pblico denominado BuscarPersona, la llamada al mtodo se realiza tal y como se muestra en el ejemplo siguiente: Persona.BuscarPersona(); Como sucede con todos los tipos de clase, Common Language Runtime (CLR) de .NET Framework carga la informacin de tipo de una clase esttica cuando se carga el programa que hace referencia a la clase. El programa no puede especificar exactamente cuando se carga la clase. Sin embargo, se garantiza que se ha cargado, que sus campos se han inicializado y que se ha llamado a su constructor esttico antes de que se haga referencia a la clase por primera vez en el programa. Solo se llama una vez a un constructor esttico y una clase esttica permanece en memoria durante el perodo de duracin del dominio de aplicacin donde reside el programa. Las clases estticas son de tipo sealed y, por consiguiente, no pueden heredarse. No pueden heredar de cualquier clase, excepto Object. Las clases estticas no pueden contener un constructor de instancia; sin embargo, pueden contener un constructor esttico. Las clases no estticas tambin deben definir un constructor esttico si contienen miembros estticos que requieren una inicializacin.
Pgina 45
3.7. Documentacin de Cdigo. Uso de etiquetas XML.

Las aplicaciones actuales de XML son casi infinitas, desde el ao 2000 que empez a tomarse como un estndar apropiado para el intercambio de datos entre plataformas, el uso y aplicacin del mismo ha ido creciendo de una forma exponencial. En Net Framework disponemos de la posibilidad de documentar nuestro cdigo utilizando etiquetas XML dentro del cdigo, para de esta forma, tener la ayuda y la documentacin tcnica sin necesidad de crearla por separado como ocurra antiguamente. A continuacin vemos las etiquetas ms utilizadas en .Net:
<summary>. La etiqueta <summary> se utiliza para describir un tipo o un

miembro de tipo. Utilice <remarks> para suministrar informacin adicional a una descripcin de tipo. El texto de la etiqueta <summary> es la nica fuente de informacin sobre el tipo en IntelliSense y tambin se muestra en el Examinador de objetos. Ejemplo:
/// <summary> /// Informacin sobre la clase /// </summary>
<remarks>. La etiqueta <remarks> se utiliza para agregar informacin sobre

un tipo, de modo que completa la informacin especificada con <summary>. Esta informacin se muestra en el Explorador de objetos.
/// <summary> /// Informacin sobre la clase /// </summary> /// <remarks> /// Contenido Adicional sobre la clase. /// </remarks> class Program {}
<c> y <code>. La etiqueta <c> proporciona un modo de indicar que el texto

de una descripcin se debe marcar como cdigo. Utilice <code> para marcar varias lneas como cdigo. Ejemplo:
/// <summary> /// Se resetea el valor para <c>ContadorID</c> /// </summary>
Pgina 46
/// /// /// ///
<code> Producto obj = new Producto(); obj.IdProducto = 4 </code>
<example>. La etiqueta <example> permite especificar un ejemplo de cmo

utilizar un mtodo u otro miembro de una biblioteca. Generalmente, esto supone utilizar la etiqueta <code> Ejemplo:
public class Empleado { /// <remarks> /// <example> Ejemplo de uso del campo <c>IDEmpleado</c> /// <code> /// Empleado obj = new Empleado(); /// obj.IDEmpleado = 21 /// </code> /// </example> /// </remarks> public int IDEmpleado; }
<exception>. Especifica las excepciones que se pueden producir.

Sintaxis:
<exception cref="member">Descripcin</exception>
Parmetros: cref. Referencia a una excepcin disponible desde el entorno de compilacin actual. El compilador comprueba si existe la excepcin dada y convierte member al nombre de elemento cannico en el resultado XML. member debe aparecer entre comillas dobles (" "). Descripcin. Descripcin de la excepcin. Se utiliza la etiqueta <exception> para especificar las excepciones que se pueden producir. Esta etiqueta se aplica a una definicin de mtodo. Ejemplo:
/// <exception cref="System.Exception">Lanzar cuando Matriz es null</exception> static void Main(string[] args) { string[] Matriz; }
<include>. La etiqueta <include> permite hacer referencia a comentarios

colocados en otro archivo que describen los tipos y miembros del cdigo fuente. sta es una alternativa al mtodo habitual de colocar los comentarios
de la documentacin directamente en el archivo de cdigo fuente. La etiqueta <include> utiliza la sintaxis XPath de XML. Sintaxis:
<include file='fichero' path='tagpath[@nombre="id"]' />
Parmetros: Fichero. Nombre del archivo que contiene la documentacin. El nombre de archivo se puede completar con una ruta de acceso. Agregue filename entre comillas simples (' '). Tagpath. Ruta de acceso de las etiquetas de filename que conduce a la etiqueta name. La ruta de acceso va entre comillas simples (' '). Nombre. Especificador de nombre en la etiqueta que precede a los comentarios; Nombre poseer un id. Id. Identificador para la etiqueta que precede a los comentarios. El id va entre comillas dobles (" ").
Ejemplo:
/// <include file='xml_include_tag.doc' /// path='MyDocs/MyMembers[@name="test"]/*' /> class Test {}
<list>. El bloque <listheader> se utiliza para definir la fila de encabezado de

una tabla o de una lista de definiciones. Cuando se define una tabla, slo es necesario suministrar una entrada para un trmino en el encabezado. Cada elemento de la lista se especifica con un bloque <item>. Cuando se crea una lista de definiciones, se debern especificar tanto term como description. Sin embargo, para una tabla, lista con vietas o lista numerada, slo es necesario suministrar una entrada para description. Una lista o una tabla pueden tener tantos bloques <item> como sean necesarios. Sintaxis:
<list type="bullet" | "number" | "table"> <listheader> <term>Termino</term> <description> Descripcin...</description> </listheader> <item> <term>term</term> <description>Descripcin...</description> </item>
Pgina 48
Parmetros Term. Trmino que se define en description. Description. Elemento de una lista numerada o con vietas, o definicin de un term. Ejemplo:
/// <summary>Ejemplo de tipo Dato: /// <list type="Dato"> /// <item> /// <description>Item 1.</description> /// </item> /// <item> /// <description>Item 2.</description> /// </item> /// </list> /// </summary> static void Main() { }
<para>. La etiqueta <para> se utiliza dentro de otra etiqueta, tal como

<summary>, <remarks> o <returns>, y permite dar una estructura al texto. Ejemplo:
/// <summary>Mtodo Principal de la Aplicacin /// <para>Aqu se puede hacer un segundo prrafo en la descripcion /// <see cref="System.Console.WriteLine(System.String)"/> /// para informacin acerca de los parmetros de salida.</para> /// <seealso cref="TestClass.Main"/> /// </summary>
<param>. La etiqueta <param> se debe utilizar en el comentario de una

declaracin de mtodo para describir uno de los parmetros del mtodo. El texto para la etiqueta <param> se mostrar en IntelliSense, el Examinador de objetos y en el Informe Web de comentario de cdigo. Sintaxis:
<param name='nombre'>description</param>
Parmetros Name. Nombre de un parmetro de mtodo. Colocar el nombre entre comillas dobles (" "). Description. Descripcin del parmetro.
Pgina 49
Ejemplo:
/// <param name="Int1">Se usa para indicar el valor.</param> public static void DoWork(int Int1) { }
<paramref>. La etiqueta <paramref> proporciona una forma de indicar que

una palabra en los comentarios del cdigo, por ejemplo en un bloque <summary> o <remarks>, hace referencia a un parmetro. El archivo XML se puede procesar para dar formato a esta palabra de alguna manera distinta, como con una fuente en negrita o en cursiva. Sintaxis:
<paramref name="name"/>
Parmetros Name. Nombre del parmetro al que hay que hacer referencia. Ponga el nombre entre comillas dobles (" "). Ejemplo:
/// <summary>Este mtodo realiza clculos matemticos. /// El <paramref name="Int1"/> toma un valor entero. /// </summary>
<permission>. La etiqueta <permission> permite documentar el acceso de

un miembro. La clase PermissionSet permite especificar el acceso a un miembro. Sintaxis:
<permission cref="member">description</permission>
Parmetros Cref = "member". Referencia a un miembro o campo al cual se puede llamar desde el entorno de compilacin actual. El compilador comprueba si el elemento de cdigo dado existe y convierte member al nombre de elemento cannico en el resultado XML. member debe aparecer entre comillas dobles (""). Description. Descripcin del acceso al miembro. Ejemplo:
/// <permission cref="System.Security.PermissionSet"> /// Este mtodo es de acceso pblico.</permission> public static void Acceso() {} Captulo 3. Diseo de Aplicaciones Orientadas a Objetos Pgina 50
<returns>. La etiqueta <returns> se debe utilizar en el comentario de una

declaracin de mtodo para describir el valor devuelto. Sintaxis:
<returns>description</returns>
Parmetros Description. Descripcin del valor devuelto. Ejemplo:

/// <returns>devuelve la matriz con las filas /// encontradas.</returns> public static string[] GetZero() { return new string[2]; }
<see>. La etiqueta <see> permite especificar un vnculo desde dentro del

texto. Se utiliza <seealso> para indicar que el texto debe colocarse en una seccin. Sintaxis:
<see cref="member"/>
Parmetros: cref = "member". Referencia a un miembro o campo al cual se puede llamar desde el entorno de compilacin actual. El compilador comprueba si el elemento de cdigo dado existe y pasa member al nombre de elemento en el resultado XML. Se agrega member entre comillas dobles (" "). Ejemplo: En el ejemplo de la etiqueta <para> se encuentra una aplicacin de <see>.
<seealso>. La etiqueta <seealso> permite especificar el texto que se desea

que aparezca en una seccin. Se utiliza <see> para especificar un vnculo desde dentro del texto. Sintaxis:
<seealso cref="member"/>
Pgina 51
Parmetros cref = "member". Referencia a un miembro o campo al cual se puede llamar desde el entorno de compilacin actual. El compilador comprueba si el elemento de cdigo dado existe y pasa member al nombre de elemento en el resultado XML. member debe aparecer entre comillas dobles (" "). Ejemplo:
/// <summary>Mtodo para mostrar datos /// <seealso cref="TestClass.Metodo"/> /// </summary> public static void Metodo(int Int1) { }
<typeparam>. La etiqueta <typeparam> se debera utilizar en el comentario

de una declaracin de tipo o mtodo genrico para describir un parmetro de tipo. Agregue una etiqueta para cada parmetro de tipo del tipo o mtodo genrico. El texto de la etiqueta <typeparam> se mostrar en IntelliSense, el informe Web de comentario de cdigo de Explorador de objetos. Sintaxis:
<typeparam name="name">description</typeparam>
Parmetros: Name. Nombre del parmetro de tipo. El nombre va entre comillas dobles (" "). Description. Descripcin del parmetro de tipo. Ejemplo: Ver <typeraramref>
<typeparamref>. Se usa esta etiqueta para permitir a los consumidores del

archivo de documentacin dar formato a la palabra de una manera distinta, por ejemplo en cursiva. Sintaxis:
<typeparamref name="name"/>
Parmetros: Name. Nombre del parmetro de tipo. El nombre va entre comillas dobles (" ").
Pgina 52
Ejemplo:
/// <summary> /// Crea una matriz de tipo genrico <typeparamref name="T"/> /// </summary> /// <typeparam name="T">Indica el elemento tipo de la /// matriz</typeparam> public static T[] mkArray<T>(int n) { return new T[n]; }
<value>. La etiqueta <value> permite describir el valor que representa una

propiedad. Hay que tener en cuenta que al agregar una propiedad a travs de un asistente para cdigo en el entorno de desarrollo de Visual Studio .NET, se agregar una etiqueta <summary> para la nueva propiedad. A continuacin, se debe agregar manualmente una etiqueta <value> que describa el valor que representa la propiedad. Sintaxis:
<value>property-description</value>
Parmetros property-description. Descripcin de la propiedad. Ejemplo:

/// <summary>La propiedad Nombre representa el nombre /// del producto.</summary> /// <value>La propiedad permite leer y grabar el nombre.</value> public string Nombre { get; set; }
Pgina 53
3.8. Diagramas de Flujo.

Qu es un diagrama de flujo? Un diagrama de flujo es una representacin grfica de un algoritmo o funcin. Su aplicacin es muy amplia y cubre aspectos que no estn directamente relacionados con la programacin como son: procesos industriales, actividades empresariales, econmicas etc. Todo diagrama de flujo utiliza para su representacin un conjunto de elementos grficos que permiten identificar los procesos o funciones a realizar en la parte del diagrama de flujo donde aparecen. Cmo se debe realizar o planificar un diagrama de flujo? La planificacin del diagrama de flujo es muy importante, centrndose sobre todo en dos aspectos clave: hay que tener muy clara cul es la tarea a diagramar y; sobre todo; el diagrama debe representar lo ms fielmente posible el proceso real. Todo diagrama de flujo usa una simbologa y una metodologa que debe de ser conocida por todas las personas que forman parte del proyecto. El desarrollo del diagrama de flujo permitir trabajar con claridad en el proyecto y ayudar en el futuro a los analistas y programadores que implementen y mejoren nuevas caractersticas de la aplicacin. Un diagrama de flujo, como ya hemos indicado, es una representacin grfica de la secuencia de pasos necesaria para realizar una funcin. Los diagramas de flujos se usan en multitud de actividades diarias, incluida la programacin. En un equipo de programacin existe un responsable o responsables que se encargan de planificar las tareas a realizar. Se debe de aportar la mayor informacin posible sobre la tarea a planificar para que no existan lagunas en el desarrollo que afecten negativamente a la imagen del esquema y, por tanto, a la programacin del mismo. Antes de implementar un diagrama de flujo se hace una lista con los procesos y secuencias que permitirn realizar la actividad a programar. Una aplicacin consta normalmente de mltiples diagramas de flujo, cada uno de ellos vinculado a una actividad o funcin concreta de la aplicacin. Estos diagramas pueden ser independientes unos de otros, aunque todos ellos forman la funcionalidad de la aplicacin.
Pgina 54
Simbologa ms habitual de un diagrama de flujo:
SIMBOLO
DESCRIPCIN
Inicio o fin del diagrama
Realizacin de un proceso o tarea
Anlisis de situacin y toma de decisin
Opciones de entrada y salida
Conexin o relacin entre partes de un diagrama
Base de datos
Salida por pantalla
Proceso predefinido como un mtodo
Pgina 55
Es necesario hacerse las preguntas necesarias para poder desarrollar perfectamente el diagrama de flujo. Por ejemplo: Qu datos hay que pedir o solicitar? Los datos son obtenidos de la base de datos o del usuario? Es necesario mostrar informacin al usuario? Qu informacin y a quien (niveles de seguridad)? Cules son los pasos a seguir para conseguir un objetivo? Con toda la informacin recogida, los responsables del diagrama de flujo realizarn el esquema para comunicar a los programadores cual es la tarea a realizar. En el ejemplo que podemos ver en esta pgina es un programa que suma todos los nmeros que estn entre el 0 y el 9. Esta implementacin de un diagrama de flujo corresponde a un bucle for que va sumando los nmeros mientras que el valor de i sea menor de 10. Una vez que el bucle for ha terminado, se muestra el resultado de la suma. Lo primero que hay que ver de este diagrama, es la falta de especificacin de la capa grfica, de hecho, Mostrar Suma, podra ser realizado en Windows, en Consola o en la Web.
Inicio
Suma = 0 i=0
I = i +1
Suma = Suma + i
Es i < 10?
No
Mostrar Suma
Fin
El nivel de detalle del diagrama depende mucho de las caractersticas de cada empresa. Existen dos Ejemplo Diagrama de Flujo filosofas de diseo de diagramas: muy detallados, donde el programador apenas interviene y, ms comnmente usado, un nivel de detalle ms abstracto donde el programador es el que toma muchas decisiones que tienen que ver con la programacin.
Pgina 56
3.9. Introduccin al UML.

El Lenguaje Unificado de Modelado (UML) es el esquema de representacin grfica ms utilizado hoy en da para modelar sistemas de programacin orientados a objetos (POO). Por qu he de utilizar un sistema de esquemas en el diseo de una aplicacin? Uno puede ponerse a programar directamente, sin seguir ningn diseo e intentar hacer una buena aplicacin. Para ejemplos o ejercicios sencillos este planteamiento puede funcionar, pero qu ocurre si la aplicacin es muy grande o si formamos parte de un equipo de trabajo y nos han asignado una parte del mismo? La respuesta a esta pregunta es muy simple: difcilmente podramos hacerlo. Slo tenemos que imaginarnos una aplicacin compleja con mltiples pantallas, opciones, consultas a bases de datos, etc., para darnos cuenta de lo problemtico de su desarrollo.
Pedir Producto
Seguir Pidiendo Productos
Procesar Pedido
Efectuar Pedido
Confirmar Pedido Usuario
Es cierto que en el mundo de los programadores existe una tendencia a desarrollar el cdigo sin prestar inters al Enviar Pedido al Cliente modelo grfico. Un programador suele centrase en el cdigo desatendiendo el modelo grfico o de esquemas. Si este es un planteamiento de trabajo habitual, por la Figura 3.1 Imagen de esquema de actividades de UML. experiencia de muchos desarrolladores, sabemos que incrementa los costes en horas de trabajo: el no planificar adecuadamente una aplicacin suele generar problemas que acaban haciendo que se reescriba cdigos ya desarrollados. Adems este tipo de desarrollos suele generar tambin un problema de consolidacin de la aplicacin y revisiones futuras de la misma. Es necesario siempre plantear un esquema o boceto de las necesidades de la aplicacin para conseguir dos objetivos claros: por un lado obtener una idea visual del contenido del proyecto para poder asignar funciones y; segundo, la escalabilidad de una aplicacin es ms fcil si se ha estudiado y desarrollado esquemas fcilmente interpretables.
Adems de las ventajas que aporta a la empresa el uso de diagramas, existe una razn todava ms para utilizarlos: qu es ms fcil que interprete un cliente: cdigo o un diagrama? Por ejemplo, es ms fcil explicar a un cliente un esquema como el que aparece en la imagen de la figura 3.1, que realmente mostrarle un montn de pginas de cdigo y decirle que intente interpretarlo. En un principio podemos realizar un esquema del tipo visto anteriormente, para que sea el cliente el que evale si lo que proponemos es lo que l espera de nosotros. Si el cliente da su visto bueno, pasaremos a disear modelos de UML mucho ms precisos, pero cuya finalidad es dar informacin para que Analistas Funcionales, Analistas Orgnicos y programadores, puedan trabajar con garantas de que su trabajo est correctamente planteado y por tanto no se perder tiempo en rectificar ni reprogramar partes ya desarrolladas del proyecto. Cuando tenemos que crear una aplicacin es necesario que sigamos un proceso detallado que nos permita analizar los requerimientos del proyecto (es decir, determinar exactamente qu es lo que har la aplicacin) y desarrollar un diseo que permita identificar y realizar concretamente esos requerimientos. Antes de escribir cualquier cdigo, es necesario que se revise el modelo para evitar problemas y tener que reescribir o acabar haciendo una aplicacin difcilmente ampliable en un futuro. Son varias las personas que deberan revisar y coordinar los distintos modelos a desarrollar, para de esta forma, encontrar errores de concepto y diseo que ms tarde sern un problema. Hoy da es muy difcil trabajar en un proyecto que no use algn tipo de lenguaje de programacin orientado a objetos (POO). Cuando analizamos y diseamos un modelo para un proyecto desarrollado con herramientas orientadas a objetos, se llama Anlisis y Diseo Orientado a Objetos (A/DOO). A/DOO es el trmino genrico para el proceso de analizar un problema y desarrollar un mtodo para resolverlo. Cuando los requerimientos de aplicaciones no son muy sofisticados, como por ejemplo cuando realizamos ejemplos para aprender un lenguaje de programacin, con el uso del seudocdigo, nos valdra. El seudocdigo es un medio informal basado en texto para expresar la lgica de un programa. Cuando el proyecto ya tiene cierto tamao el seudocdigo no es una tcnica muy apropiada para trabajar. Existen muchos procesos de A/DOO distintos, pero slo existe un nico Lenguaje Grfico para comunicar los resultados de cualquier diseo A/DOO: el UML. El UML fue desarrollado a mediados de los 90 por tres expertos en metodologas de software: Grady Booch, James Rumbaught e Ivar Jacobson.
Es el esquema de representacin ms utilizado para modelar sistemas orientados a objetos. Una caracterstica muy importante del UML, es la extensibilidad (es decir, capaz de mejorar mediante nuevas caractersticas) e independientemente de cualquier proceso A/DOO tradicional. Los modelos desarrollados con UML se componen de diagramas o imgenes. Uno de los objetivos del UML es poder desarrollar y experimentar de una forma ms barata que si utilizramos cdigo directamente. Es necesario planificar en qu momento dejamos de dibujar y codificamos, o si el modelo se ajusta o no. Aunque normalmente entregamos documentos de texto con la explicacin de la aplicacin (normalmente nadie se los lee), un diseo grfico permite que personas que no tengan conocimientos de programacin sean capaces de seguir y proponer soluciones o dudas, que utilizando slo el cdigo y el texto no podramos conseguir. 3.9.1. Tipos de Diagrama de UML En principio, UML, dispone de varios tipos distintos de diagramas. Cada uno cumple una funcin concreta en el desarrollo del proyecto, as, disponemos de modelos para anlisis, para diseo y para implementacin. Aqu analizaremos algunos de los que ms se usan. Estos diagramas son: Diagramas de cajas de usos. Son simples y suelen utilizar el smbolo del actor (representado por un mueco) y el valo que representa la caja de uso. Ejemplo:
-Fin1 -Fin2 * * Actor1 Hacer Pedido
Figura 3.2. Diagrama de cajas de usos.
Diagramas de actividades. Un diagrama de actividades es la versin UML de un diagrama de flujo. Los diagramas de actividades se usan para analizar los procesos y, si es necesario, volver a realizar todo el diseo del proceso. Un ejemplo es la Figura 3.1 que vimos anteriormente.
Diagramas de clases. Se usan para mostrar las clases que componen un sistema y las relaciones que existen entre ellas. Evidentemente es posible que una misma clase aparezca en varios diagramas de clases y, por supuesto, no es necesario que la aplicacin se muestre con un solo
diagrama de clases. El objetivo principal es mostrar las clases y sus relaciones desde varias perspectivas, de una manera que permita comprender mucho mejor la forma en que las clases interactan dentro del proyecto. Ejemplo:
PropiedadesPedido Pedido
Almacen
Figura 3.3. Diagrama de clases.
Diagramas de interaccin. Un diagrama de clases no explica cmo se comportan las clases y las iteraciones entre ellas, slo explica que contienen y las relaciones entre las mismas. Para conocer cmo funciona cada clase, disponemos de los diagramas de interaccin. En este tipo de diagramas existen dos modelos: de secuencia y de colaboracin. Los dos transmiten la misma informacin, pero desde perspectivas diferentes. Los diagramas de secuencia muestran las clases a lo largo de su ejecucin y de los mensajes que se envan entre las mismas. Por otro lado, el diagrama de colaboracin, usa el mismo esquema pero mostrado en una disposicin espacial. El diagrama secuencial muestra las acciones segn se van produciendo, mientras que el diagrama de colaboracin, al no ser secuencial en el tiempo, las acciones se numeran para conocer cul es el orden de ejecucin de los mismos. De los dos, es ms comn desarrollar el de secuencias. Existen programas de modelado de UML que a partir del diagrama de secuencias, generan automticamente el diagrama de colaboracin.
Pgina 60
Ejemplo Diagramas Interaccin:
Pedido
Almacen
PropiedadesPedido
Solicitar Productos
Verificar Producto Disponible
Producto Disponible
Generar Pedido
Enviar Pedido Cliente
Figura 3.4. Diagrama Interaccin modelo secuencia.
Pedido
1. Solicitar Producto
2. 4. Genera r Pedido 3 . Ve r i 5. Enviar Co fic Pedido al ar nfi Cliente r m Pr o ar du Di sp cto A on ibi lma lid cn ad de Pr Almacen od uc to
Figura 3.5. Diagrama de interaccin modelo colaboracin.
PropiedadesPedido
Diagramas de estado. Mientras que los diagramas de interaccin muestran los objetos y los mensajes que se pasan entre ellos, un diagrama de estado muestra el estado cambiante de un solo objeto, conforme ste pasa por un sistema. Si continuamos con el ejemplo, nos centraremos en el pedido y veremos cmo va sucediendo las acciones.
Pgina 61
Solicitar hacer un pedido
Iniciar Pedido
Indicar Producto
Comprobar Disponibilidad Producto Producto no disponible
Producto Disponible
Agragar Carro Compra
Ms Productos
Seguir Comprando
Terminar Compra
Enviar Pedido
Figura 3.6. Diagrama de estado.
Diagramas de componentes. Un diagrama de componentes en realidad se usa ms para la implementacin. En concreto se usan a la hora de mostrar el producto final. Este tipo de diagramas se asemeja ms a uno de clases pero utilizando smbolos de componentes. Una vez vistos algunos de estos diagramas, podemos pensar que es necesario hacerlos todos para poder disear una aplicacin. En realidad, depende de las necesidades: ni son necesarios todos, no el hecho de usarlos todos complica la aplicacin. Cada caso requerir de los diagramas que se acuerden dentro del equipo de desarrollo. En cuanto al tamao de los modelos, tampoco existe un tamao de referencia. Esto ir determinado por el alcance del detalle que se quiere aplicar. Tambin es recomendable que la documentacin de cada diagrama vaya dentro del diagrama y no en un documento de texto separado.
Pgina 62
3.9.2. Diagramas de actividad para las instrucciones bsicas:
3.9.2.1. Diagrama if Ejemplo de cdigo de un if: if ( nota >= 5) lblVer.text = Aprobado; Ejemplo de Diagrama de ese if:
[Nota >= 5] Escribir Aprobado [Nota < 5]
Figura 3.7 Diagrama if
Pgina 63
3.9.2.2 Diagrama if else Ejemplo de cdigo de un if else: if ( nota >= 5) lblVer.Text = Aprobado; else lblVer.Text = No Aprobado; Ejemplo de diagrama de ese if else:
Escribir Suspendido
[Nota < 5]
[Nota >= 5] Escribir Aprobado
Figura 3.8 Diagrama if - else
Pgina 64
3.9.2.3. Diagrama while Ejemplo de cdigo de un while: While (numero == 0) { Console.Write(Introduce un nmero: ); string strTexto = Console.ReadLine(); int.TryParse(strTexto, out numero); } Ejemplo de diagrama de ese while:
Fusin
Decisin
[Numero = 0]
Pedir Nmero
[Numero > 0]
Console.Write(Introduce un nmero: ); string strTexto = Console.ReadLine(); int.TryParse(strTexto, out numero);
Figura 3.9 Diagrama While
Pgina 65
3.9.2.4. Diagrama for Ejemplo de cdigo de un for: for (int i = 0; i < 10; i++9 { lblVer.Text += Valor de i: + i.ToString(); } Ejemplo de diagrama de ese for:
Inicializar la variable de control
int Contador = 1;
Fusin
Decisin
[Contador < 10]
Mostrar Nmero
[Contador >= 10]
Incrementar Contador
Console.Write(Valor de contador: " + Contador.ToString());
Figura 3.10 Diagrama for
Pgina 66
3.9.2.5. Diagrama do - while Ejemplo de cdigo de un do - while: { lblVer.Text = El contador es: + Contador.ToString(); Contador++; } do while(Contador < 10) Ejemplo de diagrama do - while:
Console.Write("Valor del contador: " + Contador.ToString());
Muestra el valor del contador [Contador < 10]
Contador++;
Incrementa la variable de control
Al final comprueba si el ciclo debe seguir
[Contador >= 10]
Figura 3.11 Diagrama do - While
Pgina 67
3.9.2.6. Diagrama switch Ejemplo de cdigo de un switch: Switch (opcin) { case 1: lblVer.Text = Estamos en el caso 1; break; case 2: lblVer.Text = Estamos en el caso 2; break; case 3: lblVer.Text = Estamos en el caso 3; break; . Ms Case default: lblVer.Text = Se ha entrado en el caso por defecto; break; } do while(Contador < 10)
Pgina 68
Ejemplo de diagrama switch:
Case 1 [true] Realizar Opcin case 1 [false] break
Case 2
[true] Realizar Opcin case 2 [false] break
Case 3
[true] Realizar Opcin case 3 break
[false] Case 8 [true] Realizar Opcin case 8 break
Realizar Acciones del Default
break
Figura 3.12 Diagrama Switch
Pgina 69
3.9.3. Diagramas de clases UML.
Dentro del desarrollo de diagramas en UML, el de clases ser uno de los ms utilizados. Este diagrama tambin se le conoce con el nombre de esttico, porque no representa ninguna accin: slo representa objetos y sus relaciones. Elementos del diagrama de clase. En un diagrama de clase existe dos elementos bsicos: los rectngulos, que representan las clases; y lneas, que son conectores que muestran las relaciones entre las clases. En cuanto al rectngulo, dentro de los diagramas de clase, se le conoce como el clasificador. Los diagramas de clases tambin se les conoce con el nombre de estticos. Tcnicamente una clase definida en UML contiene dos elementos: comportamiento y atributos. Se les conoce coloquialmente como caractersticas o miembros de la clase. Un atributo puede ser una variable (campo), una propiedad o ambos a la vez. Por su parte un comportamiento, en realidad es el mtodo. Un objeto, en la definicin de programacin orientada a objetos, se compone de mtodos y atributos.
Producto Representacin de una Clase en el diagrama UML. En los rectangulos en blanco que aparecen debajo del nombre de la clase, en este caso Producto, se definen en primer lugar los atributos de la clase y, en el siguiente, los mtodos o comportamiento de la clase.
Ciruelas
Este diagrama representa un objeto. Se diferencia de la clase en que el objeto es en realidad una muestra, o ejemplo, de como es la clase.
interface ITipoProducto
Una Interfaz es equivalente a una clase abstracta pura. En la herencia, varias clases, pueden heredar de una misma interfaz. Igualmente y, aunque en C# la herencia a nivel de clases es simple (slo se puede heredar de una clase a la vez), en las interfaces la herencia es mltiple. Es decir, podemos heredar en una clase de varias interfaces a la vez.
Parmetro1 Mercancia
Genricos o plantillas. En UML, a los genricos se les conoce como tipos parametrizados, o clase parametrizada. Durante la ejecucin, se le especifica un tipo de dato. Por tanto no tiene un tipo definido previamente, sino que cada vez que se llama al objeto se le pasa un tipo distinto. En C# y Java se les conoce como genricos y en C++ como plantillas.
datatype Proveedor
Un tipo de dato es una clase que se utiliza para definir un tipo de dato. Normalemente se podra ver este diagrama para representar, por ejemplo, el tipo int, etc. Algunas veces se usa para modelar los atributos de una clase.
metaclass MiProducto
Una metaclase en C# no se soporta directamente. En su luga, en C# se usa un objeto "type" (tipo) que representa la especie de un ejemplo de una metaclase universal; toda clase tiene un metaobjeto asociado que permite conocer de que tipo es ese objeto y todas sus caractersticas. En C# podemos descubir un tipo de la clase y su informacin y tiempo de ejecucin.
Figura 3.13 Smbolos de los diagramas de clase
Pgina 70
La Clase. Es el objeto ms utilizado en este tipo de diagramas de UML. En un diseo de una aplicacin para un almacn de productos podramos definir cada producto como una clase, o una clase nica que se llame Producto y que tenga los atributos y mtodos comunes a cualquier tipo de producto. Luego podramos tener clases especficas que hubieran heredado de la clase Producto. Adems, necesitaremos desarrollar clases que permitan interactuar con la base de datos y otras relacionadas con la gestin del propio almacn.
Producto
Por tanto, una clase puede definir elementos de informacin y otras definen elementos de actividades a realizar. Esta es la parte difcil: disear y crear las relaciones entre las clases. Dentro del clasificador (nombre del rectngulo que representa la clase), el rectngulo que se encuentra en la parte inmediatamente inferior al nombre de la clase, se utiliza para describir los atributos o variables que forman parte de la clase. El segundo rectngulo se utiliza para describir los mtodos (comportamiento) de la clase. El objeto. Tcnicamente un objeto en un diagrama UML es una muestra o ejemplo de cmo es la clase. Por ejemplo, de la clase Producto, podramos decir que Ciruelas es un ejemplo o muestra de ese tipo de clase. Se distingue de la clase en el hecho de que el nombre aparece subrayado, a diferencia de la clase que no aparece subrayado.
Ciruelas
La Interfaz. Un interfaz es en realidad una clase abstracta. Slo define los miembros que componen la interfaz pero sin desarrollar su implementacin. Es utilizada para disear caractersticas comunes entre objetos pero que esas caractersticas son desarrolladas especficamente para cada uno de esos objetos. Por ejemplo, si disponemos de un mando universal que nos permita controlar todos los dispositivos electrnicos de nuestra casa (televisin, equipo de msica, DVD, etc.), podemos hacer que el botn de subir y bajar el canal, siendo el mismo, funcione de diferente forma en cada equipo. Por ejemplo, en la televisin podemos hacer que funcione para subir o bajar el nmero de canal; en el equipo de msica, se utilizar para buscar el siguiente dial si est en modo radio, o la siguiente cancin si est en modo CD. Todos usan el botn para subir o bajar, el qu, lo define cada objeto por separado.
interface ITipoProducto
Tipos parametrizados o genricos. En C# un genrico es un parmetro que en tiempo de ejecucin se le especifica Mercancia cul es su tipo. Por ejemplo podemos desarrollar un mtodo con un parmetro de entra o salida que sea genrico. Durante la ejecucin del cdigo, el parmetro tomar el tipo que se le pase en ese momento. Puede ser un string, un int, un short, o
Parmetro1
Pgina 71
cualquier tipo. Al igual que lo hemos aplicado a un mtodo, tambin lo podemos aplicar a una clase. Cuando se aplica un genrico a una clase buscamos separar la implementacin del tipo de datos. Por ejemplo: Diseamos una clase genrica que permite con unos mtodos insertar y borrar elementos en la matriz. Si no usamos genricos, habra que desarrollar un mtodo insertar y otro borrar para cada tipo que quisiramos controlar. Por el contrario, si usamos genricos, slo diseamos un mtodo insertar y otro borrar y, los parmetros de entrada y salida los definimos como genricos. Tipo de Dato. Un tipo de dato es por ejemplo un int, o un string. Normalmente se suelen utilizar para representar tipos sencillos que estemos desarrollando. Aunque tambin podemos usarlo para indicar tipos desarrollados por nosotros, por ejemplo, el tipo Producto (es una clase que en realidad representa un tipo de dato).
datatype Proveedor
Las Metaclases. Una Metaclase es una clase de una clase. Es la solucin para poder obtener informacin sobre las clases en tiempo de ejecucin. En la prctica, podemos pasar una Metaclase como un objeto para pode obtener la informacin de la clase. En C# no soporta directamente las Metaclase, pero se usa un objeto type (tipo) que representa toda la informacin que contiene ese tipo. Con el mtodo GetType de los objetos en C#, podemos saber en tiempo de ejecucin toda la informacin sobre la clase.
metaclass MiProducto
Las Clases. Como hemos podido ver antes, el objeto Class (llamado clasificador en UML), se compone de tres reas rectangulares: a) Nombre de la Class. En el primer rectngulo, encontramos el nombre de la class. b) Atributos. El segundo rectngulo est Producto destinado a indicar cules son los atributos +Nombre : string de la clase. Recordemos que tcnicamente un atributo puede ser una variable de la class, una propiedad o, una propiedad con variable. Cada uno de los atributos se les puede asignar un smbolo que indica su nivel de acceso: el smbolo menos ( - ) indica que el acceso es Private; el smbolo ms ( + ) indica que el acceso es Public y; por ltimo, el smbolo conocido como almohadilla ( # ) indica que el acceso no es Public ni Private (en C# podra ser Internal, Protected o Protected Internal). En realidad UML slo identifica con el smbolo # el nivel protected. Cuando vemos en un diagrama de clases el objeto clase, en los atributos lo primero que aparece es el smbolo del nivel de acceso, a
continuacin el nombre del atributo y despus de un smbolo de dos puntos ( : ) el tipo del atributo. En el ejemplo que tenemos aqu, vemos que la clase Producto tiene un atributo llamado, Nombre, que es de acceso Public ( + ) y el tipo para ese atributo es string. A veces, sobre todo si el tipo de atributo no es un atributo primitivo, sino que es un tipo obtenido de una clase diseada por nosotros o por una tercera persona, su representacin podra hacerse utilizando una asociacin.
Declaracin de Atributos: Con y sin asociacin.

Sin asociacin:
Libreria +InformacionLibro : Libros
Con asociacin:
Libros Libreria 1 +InformacionLibro +Titulo : string +Autor : string +Editorial : string +ISBN : string +Precio : float
Nota: ambas representaciones son admitidas y representan lo mismo.

Figura 3.14 Representacin de atributos en UML con y sin asignacin.
En el esquema de la figura 3.14, vemos que sin asociacin del atributo va especificado dentro de la seccin de atributos como si el tipo fuera un tipo primitivo (string, float, int, etc.). Por el contrario, cuando usamos la asociacin lo que pretendemos es dar ms informacin sobre la estructura en la que el tipo de objeto, en este caso Libros, est constituido. Si todos los atributos fueran creados con relaciones de asociacin, nuestro diagrama de UML sera muy engorroso de interpretar. Por tanto, se recomienda slo usar este tipo de relaciones cuando el atributo sea un atributo de una clase, por ejemplo Libros. Cuando usamos una relacin, el smbolo + que aparece a la izquierda del tipo del atributo en la relacin (+InformacionLibro), significa que es Public. No hace falta que dentro de la clase Librera mostremos
informacin sobre el atributo, de hecho, es la relacin la que contiene esa informacin. Los atributos de la asociacin tambin pueden contener una multiplicidad, que indica cuntos de cada elemento intervienen en la relacin. En nuestro ejemplo de la figura 3.14, la relacin es 1 a 1. Significa que por cada objeto Librera se crear otro objeto Libro. En la siguiente tabla podemos ver los identificadores que se usan para la relacin de multiplicidad y su significado: Indicador 1 * 0..1 0..* 1..1 1..* Significado Slo 1 Infinito Cero o 1 Una cota inferior a cero y una superior a infinito; esto equivale a * Uno y slo uno; es equivalente a 1 Una cota inferior de por lo menos uno y una superior de infinito.
Tambin podemos aplicar un concepto llamado unicidad, que consiste, es especificar si un atributo de una clase es una campo clave en una tabla, si su valor es nico (slo puede haber un elemento con ese valor en toda la tabla), o bien si no es nico. +InformacionLibro: Libros {nico} Igualmente existe otro arreglo para considerar si los datos estn o no ordenados. Para ello se le indica de la misma forma que para el caso de la unicidad. De todas formas, en los diagramas UML no siempre se llega a un nivel tan detallado. c) Operaciones o Mtodos. En UML operaciones, comportamientos y mtodos se refieren a lo mismo. Por regla general, cuando diseamos en UML decimos operaciones o comportamientos y, cuando codificamos, lo llamamos mtodo. En el tercer rectngulo del clasificador del esquema de class est dedicado a las operaciones o mtodos. Las operaciones pueden contener un tipo de dato de retorno; un nombre; una lista de parmetros de entrada que incluye nombres de variables, tipos y modificadores (ref, out), junto con modificadores adicionales a la operacin que pueden indicar si una operacin es esttica, virtual o alguno otro tipo de
modificador disponible (en funcin del lenguaje donde se va a programar). Un diagrama de clases consta bsicamente, como ya explicamos anteriormente, de clasificadores (rectngulo que representa la class) con atributos y operaciones as como de conectores que describen las relaciones entre las clases. Esto se suele usar en la mayora de los diagrama de clases. Podemos ampliar mucho ms el nivel de detalle, pero normalmente con lo que acabamos de describir es suficiente para poder codificar nuestra aplicacin desde el diagrama UML de Clases. Las Asociaciones Las relaciones dentro de un diagrama de clases incluyen: generalizacin, herencia, realizacin, composicin, agregacin, dependencia y asociacin. Con un mayor nivel de definicin, los conectores describen las relaciones y pueden ser dirigidos o no dirigidos, junto con bidireccionales o no direccionales, adems pueden expresar multiplicidad (al igual que en el caso de los atributos). En los diagramas de clase, las asociaciones se marcan por mediacin de los conectores de asociacin, que es una lnea continua (ver figura 4.3). Cuando la asociacin es dirigida, entonces la lnea continua puede tener una flecha simple en cualquiera de los dos extremos o en ambos. Si existe una flecha, en cualquiera de los dos extremos de una asociacin, entonces se dice que la asociacin es dirigida o direccional. El extremo que tiene la flecha es el objetivo o el objeto hacia el que se puede navegar. El extremo sin flecha se llama fuente. Por ejemplo:
Asociacin bidireccional o no dirigida

Producto * * Proveedor
Producto * *
Proveedor
Asociacin direccional o dirigida

Producto 1..*
Figura 3.15 Asociacin entre dos clases.
Proveedor *
Pgina 75
Explicacin de la figura 3.15: En una asociacin bidireccional o no dirigida, un atributo de la clase Proveedor aparece en la clase Producto y, en el otro sentido, un atributo de la clase Producto aparece en la clase Proveedor. En una asociacin direccional o dirigida, la clase Producto tiene un atributo que es del tipo clase Proveedor. La agregacin y composicin. Las relaciones de agregacin y composicin tienen que ver con las relaciones de totalidad y parte. Cuando se requieren objetos que son instancias de clases definidas por el desarrollador de la aplicacin, disponemos de la agregacin y la composicin. La agregacin es representa por un diamante en blanco, mientras que la composicin el diamante es negro. El diamante siempre va en la class que es el todo. Ver figura 3.16.
Agregacin
Todo * * Parte
Composicin
Todo 1 * Parte
Figura 3.16 Esquemas de agregacin y composicin
Composicin: Es un tipo de relacin esttica (por valor), en donde el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. El objeto base se construye a partir del objeto incluido, es decir, es parte/todo. Agregacin: Es un tipo de relacin dinmica (por referencia), en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. El objeto base utiliza al incluido para su funcionamiento. La herencia de clases. En UML, la herencia se la conoce con el nombre de generalizacin. La generalizacin se refiere a una relacin del tipo es un(a) o de posibilidad de sustitucin y se muestra en el diagrama por mediacin de un conector de lnea continua que termina con un triangulo hueco en uno de los extremos. El triangulo apunta hacia la clase base o superclase (tambin llamada padre) y el
otro extremo se conecta a la clase que hereda o tambin llamada hijo (ver figura 3.17)
Herencia o generalizacin
Clase A Clase B
Figura 3.17 Modelado de la herencia.
En la figura 3.17., la clase A hereda de la clase B, de ah que la flecha est apuntando a la clase B. Si la flecha apuntara a la clase A, entonces, es la clase B la que hereda de la clase A. En una relacin de herencia, el hijo recibe todas las caractersticas de la clase Padre y, adems, las caractersticas que se hubieran podido crear en la clase hijo. A pesar de que la clase hijo toma todas las caractersticas de la clase Base, son los modificadores de acceso los que permitirn finalmente acceder a los miembros de la clase Base. Cualquier miembro prvate no podr ser accedido desde la clase heredada. La Herencia de interfaces. La herencia de interfaces en UML se le conoce con el nombre de relaciones de realizacin. El conector es casi idntico a uno de generalizacin, excepto que la lnea de conexin es punteada con un triangulo hueco. Cualquier clase que herede un interfaz, asume que slo hereda mtodos y propiedades, pero no su implementacin, ya que esta debe de ser realizada en la propia clase hijo. Las interfaces slo proporcionan informacin sobre los miembros, no su implementacin.
Herencia Interfaces o realizacin
Clase A interface iVisualizar
Clase A iVisualizar
Figura 3.18 Herencia de interfaces o realizacin
Modelado de Dependencia. Las dependencias se utilizan para indicar que un objeto, llamado cliente, depende de otro objeto llamado Proveedor y por tanto para poder construir el objeto cliente es necesario tener las referencias del objeto proveedor. Se representa con una lnea punteada que termina en una flecha simple. En el grfico que se muestra a continuacin, una clase llamada ManejoProducto (Cliente) depende de otra clase llamada Producto (Proveedor)
ManejoProducto
Producto
Figura 3.19 Herencia de interfaces o realizacin
Un tema importante es destacar que una dependencia no es una herencia de objeto. Un objeto puede depender de otro sin ser herencia.
Pgina 78
3.10. Entidad Relacin

Introduccin En el modelo de tres capas, que podemos ver en la siguiente figura, especifica la forma en la que deberamos de disear nuestra aplicacin. La Capa Presentacin es la responsable de visualizar y solicitar datos al usuario. Por su parte, la Capa de Negocio, tiene como finalidad desarrollar toda la lgica relacionada con la aplicacin, es decir, como funciona y que restricciones tiene; adems de servir de vinculo entre la Capa Presentacin y la Capa de Datos. Por ltimo, la Capa de Datos, tiene como finalidad almacenar los datos de la aplicacin que, normalmente, ser un gestor de base de datos relacional.
Capa Presentacin
Capa de Datos
Capa de Negocio
Figura del modelo de tres capas
Todas las capas pueden disponer de un equipo completo de analistas y programadores para su diseo y desarrollo. Pero dado que la Capa de Datos contiene o almacena los datos de la aplicacin, requiere de un estudio muy completo sobre los requerimientos de la aplicacin y la forma en la que los datos sern procesados. De todas es quizs la ms crtica. Si esta capa la diseamos mal, toda la aplicacin estar mal y ser muy complicado corregirla. Debe de ser la primera en estudiar y la primera en desarrollar su diseo. Las otras dos se basan en esta, por tanto, sera un error empezar a disear Capa Negocio y Capa Presentacin si no tenemos claro que es lo que se va a guardar y como. El diseo de una Base de Datos implica determinar qu elementos son susceptibles de ser almacenados y de qu forma esos elementos se relacionan entre s, lo que se conoce como Base de Datos Relacional. Para disear una base de datos disponemos de un tipo de diagrama llamado Diagrama Entidad Relacin, que nos permite de una forma grfica, explicar que objetos forman parte de la base de datos, que contienen esos objetos y, como se relacionan entre s. Tan importante es definir un algoritmo ptimo en la Capa de Negocio, o una interfaz rpida y efectiva en la Capa de Presentacin, es el disear una
buena base de datos. Una base de datos mal diseada arrastra sin remedio a toda la aplicacin. Un modelo de entidad relacin es un conjunto de herramientas conceptuales para describir datos, sus relaciones, su significado y sus restricciones. En el esquema siguiente, podemos observar los tres diseos que son necesarios a la hora de desarrollar la Capa de Datos. Cada diseo tiene su propio Esquema. Antes de realizar cualquier diseo, es necesario hablar con el cliente, para conocer cules son los requisitos de informacin que se van a emplear en el diseo, as como las limitaciones y restricciones que deberan de tener los datos. Una vez que tenemos los requisitos previos, pasamos a modelarlos con los distintos diseos que se aplican para la implementacin de esta capa.
Diseo de la Base de Datos

Fases de Diseo de la Capa de Datos
Diseo Conceptual
Esquema Conceptual
Diseo Lgico
Esquema Lgico
Diseo Fsico
Esquema Fsico
Bsicamente disponemos de tres modelos: Diseo Conceptual. Es un modelo que inicialmente es desarrollado desde los requerimientos previos del usuario. Es muy general y por consiguiente muy abstracto. En realidad muestra una visin de lo que es el modelo de negocio a implementar y, el esquema de esta fase, es una descripcin de alto nivel de la estructura de la Base de Datos. Esta fase es independiente del Gestor de Base de Datos (SGBD) que se va a utilizar como almacn de la informacin. El esquema conceptual se utiliza para transmitir al cliente lo que hemos entendido sobre la informacin que se quiere manejar. El modelo Entidad Relacin es un buen modelo para realizar el Diseo Conceptual de la Base de Datos.
Pgina 80
Diseo Lgico. Consiste en realizar un esquema con la informacin que maneja la empresa, basndonos en el modelo de base de datos que implantaremos, independientemente del SGBD que se vaya a utilizar. Si bien el esquema inicial parte de la idea de desarrollarlo al margen de SGBD donde se va a implementar, en el Diseo Lgico acabamos plasmando estos esquemas en el SGBD concreto. Los esquemas pueden ser el modelo relacional, el modelo jerrquico, o el modelo orientado a objetos. El Diseo Lgico es fundamental para posibles ampliaciones del sistema, ya que permite que los futuros cambios sean plasmados de una forma correcta en la Base de Datos. Tanto el diseo conceptual, como el Diseo lgico, son de vital importancia para el correcto desarrollo de la aplicacin. Si no hacemos una representacin fiel de los requerimientos y de lo que se desea conseguir, obviamente ser muy complicado poder implementar la base de datos y hacer que funcione correctamente. Igualmente hay que pensar siempre en la escalabilidad de la Base de Datos y prever posibles ampliaciones. Conforme desarrollamos el esquema lgico, se realizan pruebas que nos permiten verificar que el modelo cumple con los requisitos del usuario. Siempre que se disea un modelo de entidad relacin, es necesario no pensar fsicamente en el modelo, sino hacerlo como algo conceptual. No hay que pensar en procesos, sino en estructuras de datos. Tampoco hay que caer en el error de pensar en lo que se conoce como navegacin, sino que hay que pensar en trminos de relaciones de datos. Diseo Fsico. Es el esquema que se implementa en el manejador de las bases de datos (DBMS). Consiste bsicamente en construir las entidades, los atributos y las relaciones existentes sobre el SGBD que se selecciono para almacenar los datos. Es muy posible que durante esta fase sea necesario cambiar detalles o elementos del Diseo Lgico. Normalmente no es un problema de diseo, sino que est ms relacionado con el aumento de rendimiento y prestaciones del SGBD.
3.10.1. Diseo Conceptual. El Modelo Entidad - Relacin En realidad un modelo Entidad Relacin es un modelo conceptual de datos orientado a entidades. Es una forma de representacin grfica que incorpora la informacin relativa a datos y relaciones entre ellos. Todo modelo ha de tener una representacin grfica, para el caso de datos, el modelo ms popular es el modelo entidad-relacin o tambin llamado diagrama E/R.
Es un diagrama que slo refleja la existencia de datos, no lo que se hace con ellos. Es necesario que incluya todos los datos que forman el sistema. Adems es independiente del SGBD que se va a utilizar y su objetivo (siempre que se disee bien) es permitir la escalabilidad de los datos. El modelo Entidad-Relacin fue introducido por el Peter Chen en el ao 1976. Se basa en un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y lingsticas. Este diagrama tiene este nombre porque permite representar relaciones entre entidades (objeto del modelado de datos). El modelo se compone de: Entidades, Atributos, Relaciones, Dominios y Jerarqua de Generalizacin. En sus orgenes, el modelo Entidad-Relacin slo contemplaba conceptos de entidad, relacin y atributo. Posteriormente, se aadieron otros conceptos, como los atributos compuestos y las jerarquas de generalizacin, en lo que se ha denominado el modelo Entidad-Relacin extendido.
Elementos del Modelo Entidad - Relacin.

Entidad Atributo Entidad Dbil
Relacin
Atributo Compuesto
Relacin Dbil
Identificador
Atributo Multivaluado
Atributo Derivado
Jerarqua de Generalizacin
Pgina 82
3.10.1.1. Entidades. Entidades son todo lo que existe y es capaz de ser descrito. Por ejemplo: Persona, Coche, Casa. A este tipo de entidades se las conoce como entes o entidades concretas. Tambin disponemos de entidades abstractas como puede ser un pedido o una reserva. Las entidades son representadas con un rectngulo y en su interior el nombre de la entidad. 3.10.1.2. Atributo. El atributo es una caracterstica o propiedad de una entidad que puede hacer tres cosas: Identificar, Relacionar o Describir. En el siguiente ejemplo, podemos ver atributos como son el Nombre, Apellidos, DNI y Direccin para una entidad llamada Personas. Para cada atributo es posible tener valores repetidos o no, pero no puede existir una entidad concreta con los mismos valores que otra entidad. Siempre tenemos que poder identificar de una forma inequvoca cada entidad dentro del conjunto de entidades.
Personas
Pedro Lpez Snchez 67364753-K C/Nueva 18, 1A
Ana
Blanco Moreno
938274-L
C/Alta 21, 2A
Miguel
Del Ro Rubio
231454-P
C/Mayor 56, 4B
Conjunto de ocurrencias de la entidad Personas, con valores para los atributos Nombre, Apellidos, DNI y Direccin.
En el esquema anterior disponemos de una entidad que es la Persona, que contiene a su vez un conjunto de atributos: Nombre, Apellidos, DNI y Direccin. Una ocurrencia es el conjunto de valores de atributos para uno de los miembros de una entidad. Por ejemplo, Pedro Lpez Snchez, junto con sus dems valores, es una ocurrencia de la entidad Personas. Los atributos permiten que identifiquemos a una ocurrencia concreta en un conjunto de ocurrencias dentro de la entidad. Los identificadores de un atributo permiten identificar una ocurrencia en la entidad de forma inequvoca. Pueden ser identificadores primarios e identificadores alternativos. Solo puede haber un identificador primario y tantos alternativos como necesitemos. Como hemos comentado, es necesario poder identificar cada ocurrencia en la entidad de forma inequvoca. Esa identificacin se realiza por mediacin
de atributos de identificacin. Un atributo definido como de identificacin tiene dos condiciones a cumplir: a) No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador. Por ejemplo, si usamos el atributo DNI como identificador, asumimos que jams habr en el conjunto de datos, dos valores con el mismo DNI: b) Podemos hacer que un identificador sea la combinacin de varios atributos. Si se omite cualquier atributo del identificador, la condicin anterior deja de cumplirse. Toda entidad tiene obligacin de tener al menos un identificador y puede tener varios identificadores alternativos. Las relaciones (que veremos ms adelante) no tienen identificadores. En diseo tambin se puede considerar los siguientes tipos de atributos: Simples o Compuestos: Puede que el atributo sea un todo o bien este compuesto. Por ejemplo el DNI es simple, toma el valor de DNI de la persona, por el contrario, Nombre, puede ser slo el nombre o el nombre y los apellidos. En este supuesto sera un atributo compuesto. Con valores Simples o Multivaluados: Son si tenemos en cuenta que pueden guardar un nico valor (Simples) o varios valores(Multivaluados). Por ejemplo, trabajo o, trabajos. Derivados o calculados: Son los que se calculan en base a otros atributos. Por ejemplo en una nmina el salario neto. Propios. Son los atributos de las relaciones. Se representan unidos al rombo de la relacin. Los atributos adems disponen de un concepto llamado cardinalidad que especifica cuantos valores puede almacenar el atributo para una ocurrencia determinada de la entidad. Por defecto se especifica uno a uno (1 , 1); es decir, el atributo debe obligatoriamente de tener exactamente un valor para toda la ocurrencia de la entidad. En los atributos considerados multivaluados, la cardinalidad por defecto es uno a muchos (1 , n). Por el contrario si lo que queremos es indicar que un atributo puede contener valores nulos, se utiliza la forma cero a uno (0 , 1). Los multivaluados como hemos visto podemos especificar rangos infinitos, o rangos finitos. Por ejemplo, para el atributo Idiomas de un empleado, podemos especificar (0 , 4), que significa que para un empleado podemos almacenar hasta cuatro idiomas. Cada atributo tiene un conjunto de valores asociados denominado Dominio (se estudiara ms adelante). El dominio define todos los valores
posibles que puede tomar un atributo. Un mismo dominio puede estar sirviendo como definicin para varios atributos. 3.10.1.3. Relaciones. Las relaciones son correspondencias o asociaciones entre 2 o ms entidades. Las relaciones se representan de una forma grfica mediante rombos y su nombre aparece en el interior. Por lo general son verbos o formas verbales.
Relaciones entre la Entidad Cliente y la Entidad Producto
CLIENTE
COMPRA
PRODUCTO
Las relaciones disponen tambin del concepto de cardinalidad especificado por el nmero de ocurrencias de una entidad asociadas a una ocurrencia de la otra entidad. Disponemos de tres cardinalidades posibles: Relacin de Uno a Uno (1 : 1). Se da cuando una ocurrencia en la entidad EC, le corresponde una ocurrencia en la entidad ER y viceversa. Ejemplo:
Relaciones y Cardinalidad Uno a Uno entre la Entidad EC y la Entidad EP 1:1
EC Relacin EP
Entidad EC
EC - 1
Entidad EP
EP - 1
EC - 2
EP - 2
EC - 3
EP - 3
Relacin Uno a Muchos (1 : N). Se produce cuando una ocurrencia en la entidad EC le corresponden varias ocurrencias en la entidad EP y, a cada ocurrencia de la entidad EP, le corresponde slo una ocurrencia en la entidad EC. Ejemplo:
Pgina 85
Relaciones y Cardinalidad Uno a Muchos entre la Entidad EC y la Entidad EP 1:N

EC Relacin EP
Entidad EC
EC - 1
Entidad EP
EP - 1
EC - 2
EP - 2
EC - 3
EP - 3
EP - 4
Relacin de Muchos a Muchos (N : N). Se produce cuando a cada ocurrencia de la Entidad EC le corresponden varias ocurrencias de la Entidad EP. Igualmente, a cada ocurrencia de la entidad EP, le corresponden varias ocurrencias de la entidad EC. Ejemplo:
Relaciones y Cardinalidad Muchos a Muchos entre la Entidad EC y la Entidad EP N:N
EC Relacin EP
Entidad EC
EC - 1
Entidad EP
EP - 1
EC - 2
EP - 2
EC - 3
EP - 3
Grados existentes en una relacin. En una relacin podemos distinguir los siguientes tipos de relaciones: a) Reflexivas. Son aquellas que se producen dentro de la misma entidad. La relacin es de una ocurrencia de la entidad con otra ocurrencia de la
misma entidad. Por ejemplo, en una entidad de empleados, puede haber empleados que son supervisores de otros.
Relaciones Reflexivas
Supervisor (0, 1) Subordinado (0, n)
Empleado
Supervisa
b) Binarias o de Grado 2. Son las relaciones en las que participan dos entidades distintas. Por ejemplo, la entidad Empleados y la entidad Departamentos. En este caso, una ocurrencia de la entidad Departamentos, puede tener varias ocurrencias en la entidad Empleados. Pero cada ocurrencia en la entidad Empleados slo puede tener una ocurrencia en la entidad Departamentos.
Relaciones Binarias (Grado 2) N:N
Empleado (1, 1) Pertenece (1, n) Departamento
Ternarias o de Grado 3. Son las relaciones donde participan tres entidades. Para calcular las participaciones mnimas y mximas se compara un par de ocurrencias (a, b) de las entidades Empleado y Cliente con una ocurrencia c de la entidad Producto (y as con las otras dos combinaciones).
Relaciones Ternarias (Grado 3) N:N
Empleado (0, n) Vende (0, n) Cliente
(0, n)
Producto
En el ejemplo, la combinacin determinada por empleado cliente puede estar relacionada con de 0 a n productos (un empleado puede vender a un cliente varios productos).
Adems la combinacin determinada por Empleado Producto puede estar relacionada con de 0 a n clientes (el mismo empleado puede vender el mismo producto a varios clientes en distintas ocasiones). Y por ltimo, la combinacin determinada por Producto Cliente puede estar relacionada con de 0 a n empleados (el mismo producto puede haber sido vendido al mismo cliente por varios empleados en distintas ocasiones). Relaciones Fuertes y Relaciones Dbiles. Cuando las entidades participan en relaciones, pueden generar relaciones fuertes o dbiles. En las relaciones dbiles podemos observar dos modelos: Relacin Dbil de Dependencia de Existencia. Esta relacin es aquella en la que la entidad depende de otra entidad para relacionarse. Esto genera una vinculacin, en la cual, la entidad de nivel inferior necesita obligatoriamente la entidad de nivel superior para existir. Las entidades dbiles son mostradas con un doble rectngulo. Ejemplo:
Relaciones con Dependencia Dbil
IdCliente
IdCliente
1:N
Cliente (1, 1) Realiza (0, n) Pedido
En este ejemplo un pedido slo pertenece a un cliente. Si no hay cliente no puede haber pedido (dependencia dbil). Pero un cliente puede tener mltiples pedidos. Si borramos un cliente, todos los pedidos de ese cliente no podran existir. Esto es lo que se conoce como prdida de integridad referencial en las Bases de Datos. Relacin Dbil de Dependencia de Identificacin. Es aquella en la que la entidad dbil no tiene suficientes atributos para garantizar la identificacin o distincin de sus ocurrencias.
Pgina 88
Relaciones con Dependencia de Identificacin
ISBN
UNIDADES
1:N
LIBRO (1, 1) Dispone (0, n) EJEMPLARES
Podemos tener una relacin entre la entidad Libro y la entidad Ejemplares en la que las ocurrencias de esta ltima entidad, necesitan de forma inequvoca, los identificadores de la entidad fuerte libro, junto con el identificador de la entidad dbil Unidades. El par de atributos <ISBN, Unidades> s que permite identificar la ocurrencia correspondiente. Por ejemplo, como sabemos que en el atributo Unidades si aparece un 20, podamos identificar a que libro pertenece. Si no tenemos el ISBN, no podemos identificarlo, por eso se dice que esta es una dependencia de identificacin. Normalmente, los atributos de identificacin dbiles que pertenecen a entidades dbiles, se suelen mostrar con un subrayado doble. Al igual que en el caso anterior, si eliminamos un libro de la Entidad Libro, todos los ejemplares del libro desaparecern. Una dependencia de identificacin implica tambin dependencia en existencia. La cardinalidad en un diagrama entidad relacin tambin puede ser mostrada as:
Proveedor
Suministra
Productos
Muchos proveedores suministran de cero a muchos productos. Esta forma de visualizar se usa tanto como la anterior. No existe una norma que diga cuales de las dos formas es la mejor o la ms clara. Si preguntramos a un Analista de cada una de ellas, la respuesta sera siempre que la que aplica es la ms clara y concisa. Lo que est claro es que no hay que mezclar las dos formas de visualizacin de la cardinalidad.
Si queremos usar el modelo de cardinalidad que hemos visto en ese ejemplo, en la siguiente figura podemos ver los diagramas disponibles.
Forma de Expresar Cardinalidad en el modelo Entidad - Relacin
Muchos
Uno
De cero a muchos
De uno a muchos
De cero a uno
3.10.1.4. Dominios Un dominio es un conjunto de valores homogneos con un nombre que lo identifica. Cada atributo simple de una entidad est asociado a un dominio, el cual representa el conjunto de valores que puede tomar el atributo. Para cada ocurrencia de una entidad un atributo tendr un valor perteneciente al dominio del atributo. Puede ocurrir que varios atributos distintos o, atributos de distintas entidades y relaciones, puedan pertenecer al mismo dominio. Un dominio lleva siempre asociado un predicado que permite comprobar si un determinado valor pertenece al dominio: D = { Vi | P(Vi) } Para cada dominio especificamos el tipo de datos al cual pertenecen los valores que constituyen el mismo. Asimismo, podremos especificar el formato y la unidad correspondiente. Los dominios han de ser especificados en el diccionario de datos. Es obligatoria la especificacin del nombre del dominio, el tipo y la descripcin. Pero es opcional la especificacin del formato y la unidad. El formato se especifica siguiendo estos criterios. Tipo Concatenacin Disyuncin Opcionalidad Repeticin Frmula Componente1 + Componente2 [Componente1 | Componente2] (Componente) {Componente}min, max {Componente}x(ponemos x si min = max)
Pgina 90
Como hemos comentado todos los dominios se encuentran en el Diccionario de Datos del esquema conceptual. Por ejemplo: Dominio dNombre Tipo Formato Texto(20) {Letra}1, 20 Unidad Valores Descripcin Nombre de persona. Apellidos de persona. Dni de la persona
la la
dApellidos Texto(50) {Letra}1, 50 dDNI {Dgito}8 + {Letra} dDireccion Texto(80) {Letra} 1, 80 dEdad dSalario Nmero Nmero {Dgito}1,3 {Dgito}3, 5 Euros Texto(9)
Direccin de la persona Fecha Actual Fecha Edad de la persona

Nacimiento
Salario Neto persona
de
la
3.10.1.5. Generalizacin y Jerarqua de Generalizacin Una generalizacin es un mecanismo de abstraccin que permite especializar una entidad en subtipos, o lo que es lo mismo generalizar los subtipos en el supertipo (representado por la entidad). Una generalizacin se da cuando unos atributos son comunes a varias entidades, y unos atributos especficos que identifican unas caractersticas. En una generalizacin los atributos que son comunes a las entidades describen a la entidad supertipo y el resto de atributos son especficos de los subtipos. Existe el concepto de herencia, por el cual, los atributos de un supertipo son siempre heredados por los subtipos. Si hacemos que un supertipo participe en una relacin, automticamente los subtipos tambin lo hacen. En la siguiente figura podemos los distintos grficos que se usan para definir una generalizacin:
Figuras Representacin Jerarqua de Generalizacin
Exclusiva y Total
Exclusiva y Parcial
Solapada y Total
Solapada y parcial
Pgina 91
Hoy da se tiende a simplificar estos diagramas por el que se describi al principio de este apartado en la simbologa del diagrama entidad relacin. Una generalizacin puede ser: Exclusiva y Total. Si no hay ocurrencias en el supertipo que no pertenecen a ningn subtipo, es decir, si una ocurrencia en el supertipo slo puede ser de un subtipo. Por ejemplo, en la figura que podemos ver a continuacin, ser exclusiva y total porque un empleado slo puede ser dependiente o autnomo. Solapada y Total. Si en el caso anterior, existe la posibilidad de que una ocurrencia de subtipo puede ser de otro subtipo, se llama solapada. En este caso en el ejemplo sera como decir que un empleado puede ser autnomo y dependiente a la vez. Exclusiva y Parcial. Es si existe la posibilidad de que un supertipo tenga una ocurrencia que no sea de ningn subtipo. Por ejemplo que un empleado no fuera ni autnomo, ni dependiente. Solapada y Parcial. Esta es la nica que no tiene restricciones. Al ser solapada significa, por ejemplo, que un empleado puede ser autnomo y dependiente. Es parcial porque hay un empleado que no es ni Autnomo, ni dependiente.
Ejemplo de Jerarqua de Generalizacin
Telefono Direccion Departamento
Categoria
Empleado
Fecha Alta
Autnomo
Dependiente
Proyecto
Importe Especializacin
Pgina 92
La cardinalidad en estas relaciones es (1, 1) para el supertipo y (0, 1) para los subtipos si son exclusivas. Para las solapadas son (0, 1) para el supertipo y (1, 1) para los subtipos. 3.10.1.6. Procedimiento para realizar un Diseo Conceptual. Siempre que trabajamos en la Capa Datos y, dada la importancia que esta capa tiene en el desarrollo de la aplicacin, deberemos de realizar un estudio lo ms preciso posible sobre la informacin que tenemos que manejar. El primer paso siempre es el Diseo Conceptual. Un diseo, que como hemos comentado, provoca un esquema conceptual independiente del SGBD que vamos a utilizar como gestor de datos. En cualquier proyecto es necesario realizar varios esquemas conceptuales, cada uno de los cuales, va relacionado con cada una de las reas funcionales sobre las que se programa, como pueden ser: departamento financiero, almacn, etc. Para obtener los esquemas hay que estar muy atentos a todas las reas que se van a programar, as como a las personas que interviene en los procesos. Al final, esto es una bsqueda del conjunto de datos a informatizar, la forma en la que se usan y cuando se usan. La informacin puede estar en mltiples soportes: papel, tablas Excel, distintas Bases de Datos, etc. Es necesario buscar y preguntar hasta tener una descripcin de datos y requisitos lo ms amplia y detalla posible. A esta forma de agrupar la informacin se la conoce con el nombre de Vista. Cada esquema conceptual que se aplica a un rea o funcin de trabajo se le denomina esquema conceptual local. Cada esquema se compone de entidades, atributos, dominios, relaciones, as como identificadores. Todo esquema conceptual no slo hay que crearlo, sino que tambin es necesario documentarlo lo ms preciso posible. Pasos a realizar para conseguir un buen esquema conceptual: a) Identificar Entidades. Debemos de buscar toda aquella informacin que forma parte de los requisitos o especificaciones propuesta por el usuario. Buscamos nombres y/o los sintagmas nominales como pueden ser Nombre de empleado, apellidos, DNI, etc. Buscamos objetos importantes como pueden ser Producto, Persona, pero han de ser conceptos concretos y no propiedades de otros objetos. Por ejemplo, podemos agrupar en una entidad llamada Persona, los datos de Nombre, Apellidos y DNI; asimismo podemos agrupar en una entidad llamada Producto, el Nombre del producto, su precio, sus unidades.
Pgina 93
Es bueno busca objetos que sean en s mismos independientes y considerados como tal, por ejemplo, el caso de Producto o de Empleado, seran entidades en s mismas. Es una tarea muy difcil porque el usuario no est acostumbrado a realizar una descripcin de sus tareas desde un punto de vista de estructuras, habla de conceptos concretos usando para ello ejemplos o analogas. Por ejemplo te comentan que un proveedor concreto trae pedidos, pero esos pedidos son especficos de ese proveedor (no te hablan de proveedor como algo genrico, sino de uno en concreto) con sus limitaciones y caractersticas especficas. Los Analistas de Base de Datos pueden hacer interpretaciones de la informacin y una entidad puede ser muy clara para uno, pero para otro analista no es ms que un atributo o atributos. Todas las variantes pueden llegar a ser vlidas y en diseo de Bases de Datos, como en casi todas las cosas, la experiencia es muy importante. A las entidades hay que darles nombres que identifiquen claramente a la entidad, sobre todo, para que el cliente en el anlisis de conjunto que debemos de hacer para matizar el esquema conceptual, pueda interpretar el modelo de una forma comprensible. A medida que vamos desarrollando las entidades, debemos de ir dndolas de alta en el diccionario de datos. Si una entidad puede tener varios nombres, estos han de ser inscritos en el diccionario como alias o sinnimos. Las entidades hay que darlas de alta en el diccionario de datos del modelo conceptual con la siguiente estructura: Nombre. Describe el nombre de la Entidad. Descripcin. Indica cual es el objetivo de esa entidad. las relaciones con sus
A continuacin daramos de alta caractersticas como veremos en el punto b).
b) Identificar las relaciones. Una vez que tenemos las entidades, debemos de estudiar qu relaciones pueden existir entre ellas. En este caso debemos de plantearnos, por ejemplo, los siguientes planteamientos: un empleado tiene una oficina, empleado gestiona proveedores, un producto es de un proveedor y, as sucesivamente. Normalmente, se dar el caso de que relaciones generen nuevas relaciones. Si en la especificacin de requisitos de la aplicacin existen relaciones, estn son muy importantes y por tanto han de aparecer dentro del esquema conceptual. No todas las relaciones tienen que ser importantes, ni estar contenidas. Por ejemplo de la relacin empleado gestiona proveedor y
producto es de un proveedor, podramos llegar a pensar como una relacin la de empleado gestiona producto, cuando en realidad podra no hacernos falta porque no est incluida en las especificaciones de los requerimientos. Siempre hay que repasar las especificaciones de los requerimientos para verificar que todas las relaciones solicitadas, adems de las que han ido apareciendo estn incluidas en el modelo. Si no hay muchas entidades, una buena cosa sera probar relaciones con sus valores entre entidades. De todas formas, alguna relacin que se nos haya pasado aparecer cuando se valide el esquema con las transacciones a realizar. Un ltimo paso sera mostrar la cardinalidad entre las relaciones con sus valores mnimo y mximo. De este modo representamos de una forma ms explcita el modelo. La cardinalidad es en realidad una restriccin que se aplicara cuando se decida actualizar datos en la base de datos, para por ejemplo, saber si la actualizacin de esos datos cumple o no las normas establecidas. El siguiente paso en el diseo sera identificar a los atributos y sus relaciones. c) Identificar Atributos. Una vez hemos definido las entidades, el siguiente paso es identificar atributos para entidades y sus relaciones. Un atributo visualiza una propiedad, cualidad, identificadores o caractersticas de entidades o relaciones. Para poder desarrollar la bsqueda de atributos, un buen consejo sera empezar buscando qu informacin se necesita saber de algo. Por ejemplo, de Producto qu debo saber? Pero la mayor parte de las veces son los usuarios los que responden de una forma ms precisa a esa pregunta. Pero como en el punto a), nos encontramos con la misma dificultad de entendimiento. A la hora de definir un atributo debemos de saber si ese atributo es simple o compuesto. Por ejemplo, Direccin es la Calle o la Calle, el nmero, el piso; o son atributos separados. Igualmente buscaremos si el atributo es derivado o calculado, como por ejemplo, el Salario Neto de una nmina. En diseo del esquema conceptual, algunos analistas no incluyen los atributos derivados en el modelo, sino que lo hacen en el diseo fsico del modelo. Si se incluyen en el esquema conceptual es necesario indicarlo de una forma clara, as como la forma o frmula que hay que aplicar para obtener su valor. Si durante el proceso (suele ocurrir) detectamos una nueva entidad, hay que volver al principio y ver si se relaciona con otras entidades. Como consejo, es mejor hacer una lista con los atributos e ir asignndolos a
entidades. Si al final, hay atributos no relacionados con entidades, seguramente faltan entidades por definir. Qu hacemos si un atributo podemos relacionarlo con ms de una entidad? El hecho de que un atributo pueda ser vinculado a ms de una entidad puede ser el resultado de: Estamos usando Entidades que podran ser consideradas como una sola, por ejemplo las entidades Jefes y Empleado podran ser englobadas las dos dentro de Empleado. Un Jefe es un empleado, de un rango superior, pero es empleado. Este sera un ejemplo para usar jerarqua de generalizacin, o dejar las entidades para representar a cada puesto de empleado. Otra posibilidad sera que hemos identificado una relacin entre entidades. En este caso debemos de asignar el atributo a una sola de la entidades y asegurarse de que tenamos contralada la relacin.
Al igual que para las entidades, los atributos deben de ser alojados en el Diccionario de Datos del esquema conceptual con la siguiente informacin: Nombre. Nombre que le damos al atributo. Descripcin. Indica que es el atributo y que guarda. Alias o Sinnimos. Si hubiera, hay que indicar porque otros nombres se conoce al atributo. Tipo de Dato y Longitud. Dentro del diccionario de datos, en el apartado de dominios, especificamos tipos de datos. Aqu se indica un tipo que previamente este dado de alta en el apartado de dominios. Valores por Defecto. Si tuviera valores por defecto pueden ser definidos aqu o en el diccionario de datos, apartado de dominios. Restricciones. Si el atributo permite o no tener valores nulos, si es de autoincremento, si es necesario que su valor este dado de alta previamente en otra entidad, etc. Atributo Derivado. Si es derivado o calculado, se indicara cual es la forma o frmula para obtener su valor. Atributo Multivaluado. Si es multivaluado mostrar especificar que posibles valores puede almacenar
d) Dominios de los atributos. Un esquema conceptual no est terminado hasta que no definimos los dominios de los atributos. Un dominio, como ya vimos, permite definir el tipo del atributo (char, numrico, etc.), los valores que puede admitir y una descripcin de ese tipo. Por ejemplo: Id, permitira indicar que en cualquier entidad, un atributo de este tipo es el identificador nico de la ocurrencia. Los datos a guardar son:
Dominio. Nombre del dominio que se aplica al atributo. Tipo. Tipo de dato que contiene, ajustado al SGBD sobre el que se va a implementar. Por ejemplo en Sql Server: nvarchar, numeric, binary, etc. Formato. Si son dgitos o nmeros y su longitud. Unidad. Ciertos atributos podemos necesitar especificar la unidad. Por ejemplo el precio podemos decir euros o dlares. El peso en Kilos o libras. Valores. Ciertos atributos derivados o calculados podemos especificarlos concretamente en el dominio, en lugar de la tabla de atributos. Por ejemplo la edad: Fecha Actual Fecha Nacimiento. Descripcin. Describe las caractersticas de ese dominio. Por ejemplo, para el dominio dProducto, podemos decir que es el nombre del producto.
e) Identificadores de Entidad. El siguiente paso sera buscar al menos un identificador para cada entidad. Podemos usar identificadores simples o compuestos. Por ejemplo: Apellidos o Apellidos y Nombre. De los identificadores que se vean para cada entidad, en la fase de diseo lgico, se escoger uno para ser la clave primaria de la entidad. En las entidades existen entidades fuertes y dbiles. Para distinguirla tenemos un planteamiento claro: si en una entidad existe al menos un atributo que es un identificador, entonces la entidad es fuerte. Tambin se las conoce como entidades propietaria o dominante. Por el contrario sino tiene atributos que le sirvan de identificador, es dbil. Tambin se las conoce como dependiente o subordinado. f) Jerarquas de generalizacin. Ser necesario realizar un estudio para observar que entidades de las que se hayan identificado hasta el momento, comparten atributos, tienen atributos exclusivos. El objetivo es ver si hay entidades que tienen caractersticas comunes y realmente son subentidades de una nueva entidad genrica. Hay que determinar si es total o parcial y exclusiva o solapada. g) Dibujar el diagrama entidad relacin y analizar con el cliente. El ltimo paso ser dibujar el diagrama entidad relacin para cada esquema local, para posteriormente hablar con el/los responsables por parte del usuario para su matizacin y definicin final. Es usual que existan cambios que obliguen a volver a implementar todos los pasos anteriores.
Pgina 97
3.10.2. Diseo Lgico Base de Datos. Una vez que tenemos los esquemas conceptuales locales, el objetivo de la fase del Diseo Lgico es convertir esos esquemas en un esquema lgico global que se ajuste al modelo de SGBD sobre el que se va a implementar. El Diseo conceptual cumple la misin de comprender y expresar los esquemas locales. Por el contrario, un diseo lgico busca una representacin que use, del modo ms eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y modelar las restricciones. Existen varios modelos de bases de datos, de los cuales, el ms extendido es el modelo relacional, pero existen el de red; el jerrquico y ltimamente ha aparecido el modelo orientado a objetos, pero no es un modelo con un estndar concreto. Los modelos relacionales carecen de ciertos rasgos de abstraccin que se usan en los modelos conceptuales. Por lo tanto, una primera fase ser la de convertir los mecanismos de representacin de alto nivel en trminos de estructuras de bajo nivel disponibles en el modelo relacional. En el modelo de diseo lgico existen dos fase: 1 Construir y validar los esquemas lgicos locales. a) Convertimos los esquemas conceptuales locales en esquemas lgicos locales. En este paso deberemos de eliminar en el esquema conceptual las estructuras de datos que los sistemas relacionales no modelan directamente: - Eliminamos las relaciones de muchos a muchos creando entidades intermedias, entidades que por otro lado sern dbiles, ya que sus ocurrencias dependern de las ocurrencias de las otras entidades. - Eliminar las relaciones entre tres o ms entidades. Sustituyendo cada una de ellas por una nueva entidad dbil intermedia que se relacione con cada una de las entidades originales. - Eliminaremos las relaciones recursivas. Se sustituirn por una nueva entidad dbil cada una de ellas, realizando dos relaciones binarias de esta nueva entidad con la entidad original. - Eliminaremos los atributos multivaluados. Sustituyendo el atributo por una nueva entidad dbil y una relacin binaria de uno a muchos con la entidad original. - Revisaremos las relaciones uno a uno entre entidades, ya que existe mucha probabilidad de que las entidades sean en realidad
el mismo objeto. En este caso, integramos las dos en una sola entidad. Eliminaremos las relaciones redundantes. Si disponemos de una relacin que nos da la misma informacin que otra relacin, en ese caso, hablamos de relaciones redundantes. Habr que estudiarlo porque puede ser que no sea redundante. Que dos caminos lleven al mismo sitio puede ser malo o razonable.
b) Obtener un conjunto de relaciones (tablas) para cada esquema lgico local. Creamos las relaciones (tablas) para cada uno de los esquemas lgicos locales en donde se representan las entidades y relaciones entre entidades, descritas en cada una de las vistas que cada usuario tiene del modelo. Las relaciones tienen un nombre y el nombre de sus atributos aparecer, a continuacin, entre parntesis. Los atributos que forman la clave principal se subrayan y las claves ajenas, mecanismo que se utiliza para representar las relaciones entre entidades del modelo relacional, se especifican aparte indicando la relacin (tabla) a la que hacen referencia. c) Validar cada esquema mediante la normalizacin. Este un proceso cuya finalidad es mejorar el esquema lgico. El objetivo es evitar la duplicidad de datos por mediacin de ciertas restricciones. La normalizacin garantiza que el esquema resultante se encuentra ms prximo al modelo de la empresa, que es consistente y tiene la mnima redundancia de datos. En la normalizacin se decide a qu entidad pertenece cada atributo. Uno de los conceptos bsicos del modelo relacional es que los atributos se agrupan en relaciones (tablas) porque estn relacionados a nivel lgico. Las razones para conseguir un esquema normalizado son: - Un esquema normalizado organiza los datos de acuerdo a sus dependencias funcionales, es decir, de acuerdo a sus relaciones lgicas. - El esquema lgico no tiene porque ser el esquema final. Debe representar lo que el diseador entiende sobre la naturaleza y el significado de los datos de la empresa. Si se establecen unos objetivos en cuanto a prestaciones, el diseo fsico cambiar el esquema lgico de modo adecuado. A veces, alguna relacin normalizada, pasa a ser desnormalizada. En principio, podra parecer un problema vinculado al hecho de haber perdido el tiempo. En realidad nos permite conocer mucho mejor la informacin y la forma en la que se agrupa.
Pgina 99
Un esquema normalizado es robusto y carece de redundancias, por lo que est libre de ciertas anomalas que stas pueden provocar cuando se actualiza la base de datos. La normalizacin puede generar carga en el Servidor de Datos, ya que hoy da es posible disear bases de datos fciles de manejar, pero realizando un trabajo extra en el Servidor. Hoy da y, gracias a los nuevos equipos, tanto de Hardware como de Software, no debera de ser un problema. Por ltimo, una caracterstica importante de la normalizacin, es que genera esquemas muy flexibles que pueden extenderse con facilidad.
d) Validar cada esquema frente a las transacciones del usuario. En esta fase comprobamos que las transacciones que fueron solicitadas por el usuario y contempladas en la descripcin de requisitos, se pueden realizar. Hay que estudiar todas las relaciones, probndolas de forma manual utilizando el diagrama entidad relacin, el diccionario de datos y las conexiones que establecen las claves ajenas de las relaciones. Si todas pueden hacerse, el esquema queda validado, sino ser necesario volver a verlo y ver donde nos falta alguna relacin, entidad o atributo. e) Dibujar el Diagrama y Definir las restricciones de integridad. Se dibuja el diagrama de entidad-relacin para cada vista de usuario. A continuacin diseamos las normas de restriccin de integridad, cuya finalidad ser proteger la base de datos. Hay cinco tipos de restricciones de integridad: No admitir Nulos. Hay muchos atributos que no pueden contener valores nulos, es decir, si damos de alta la ocurrencia, el atributo de esa ocurrencia tiene que tener un valor. Hoy da se recomienda que el mayor nmero posibles de atributos no permitan nulos. Es un tema importante para mantener la integridad referencial. Restricciones de Dominio. Todos los atributos tienen un dominio asociado, que es el conjunto de valores que cada atributo puede tomar. Integridad de Entidades. El identificador de una entidad no puede ser nunca nulo. Este es el motivo de porque las claves primarias nunca admiten nulos. Integridad Referencial. Una clave ajena, que enlaza datos entre entidades, tiene el mismo valor que la clave principal de la entidad dominante. Cuando queremos borrar una ocurrencia en la entidad dominante, previamente hay que borrar las ocurrencias en la
Pgina 100
entidad hija, para no perder la integridad referencial. Este caso, sera en el que hemos borrado la clave de bsqueda y no podramos localizar los valores correspondientes en la entidad hija. Reglas de Negocio. Cualquier restricciones a los datos que haya sido definida, ha de ser comprobada antes de dar de alta los datos. Las restricciones de este tipo deben de estar registradas en el diccionario de datos.
2 Construir y validar el esquema lgico global. a) Mezclar los esquemas lgicos locales en un esquema lgico global. Todos los esquemas locales han de ser fusionados en uno slo para tener una visin global del proyecto. Validamos los esquemas y procedemos a dibujar el diagrama final entidad-relacin, para por ltimo, revisar con el usuario que todo est bien.
3.10.3. Diseo Fsico para la Base de Datos. En esta fase, el objetivo es crear las estructuras de datos y los mtodos de acceso a los mismos. En una primera fase, pasaremos el esquema lgico global a un esquema concreto dentro del SGBD seleccionado. Crearemos las relaciones incluyendo su nombre, la lista de atributos, la clave primaria y las claves ajenas, si las tiene, as como las reglas de integridad de las claves ajenas. En cuanto a los atributos, disponemos de su informacin en el Diccionario de Datos que incluye: Dominio (tipo datos, longitud y restricciones), el valor por defecto, si admite nulos y, si es derivado y la forma de calcularlo. Por ltimo diseamos las vistas para cada usuario y realizamos pruebas para verificar que todo est correcto. En este punto tambin se programan procedimientos almacenados que permitirn acceder a los datos de una forma concreta y obtener o modificar valores de una forma ms segura que dejar que los programadores de capa intermedia accedan directamente con instrucciones.
Pgina 101
Ejercicios:
Todos los ejercicios deben de ser documentados por mediacin de las etiquetas XML. 1. Desarrollar una clase llamada Aleatorios y espacio de nombres GenerarCombinaciones, que incluya los siguientes miembros: Mtodos: 1.1. Mtodo ObtenerAleatorio. Su funcionalidad ser la de generar un numero aleatorio para un rango definido por los lmites inferior y superior. Para obtener nmeros aleatorios disponemos de la clase Random: Random obj = new Random(); int valor = obj.Next(limiteInferior, limiteSuperior +1); La firma del mtodo ser: internal int ObtenerAleatorio(int LimiteInf, int LimiteSup) Una vez se ha obtenido el nmero aleatorio, el mtodo devolver el nmero. 1.2. Mtodo NumerosAleatorios. Su funcionalidad es similar al del mtodo ObtenerAleatorio, pero en su lugar, devuelve una matriz de nmeros aleatorios, en lugar de devolver un solo nmero. La cantidad de nmeros que devuelve es un parmetro de la firma del mtodo:
internal int [ ] NumerosAleatorios(int LimiteInf, int LimiteSup, int Numeros)
Numeros es el valor que nos indica cuantos nmeros aleatorios debe de generar el mtodo. 2. Desarrollar una clase llamada Ordenador y espacio de nombres GestionOrdenadores, que incluya los siguientes miembros: Propiedades: IdOrdenador (int), Marca (string), Modelo (string), TipoProcesador (string), CantidadRAM (string), CantidadHD (string), OrdenadorON (bool), MonitorOn (bool)
Pgina 102
Mtodos: 2.1. Metodo Monitor. Su funcionalidad es poner la propiedad MonitorOn en true o en false: debe de funcionar como un conmutador. Su firma es: internal void Monitor() 2.2. Mtodo CPU. Su funcionalidad es poner la propiedad OrdenadorON en true o en false: debe de funcionar como un conmutador. Su firma es: internal void CPU() 3. Desarrollar una clase de tipo esttica llamada Verificar y espacio de nombres GestionString. La clase Verificar contiene los siguientes miembros: Mtodos: 3.1. Mtodo ComprobarLetras. Su funcionalidad es verificar si un string facilitado como parmetro del mtodo tiene solo letras. Si slo contiene letras devuelve true, en caso contrario devuelve false. Firma del mtodo: internal bool ComprobarLetras(string Cadena) Cadena es el string que queremos comprobar. 3.2. Mtodo ComprobarNumero. Su funcionalidad es verificar si un string facilitado como parmetro del mtodo tiene solo nmeros. Adems y, por mediacin de un parmetro, analizaremos igualmente si contiene una coma decimal (slo puede haber una). Si slo contiene nmero o nmeros con la coma decimal (en el caso que estuviera permitido), devuelve true, en caso contrario devuelve false. Firma del mtodo: internal bool ComprobarNumero(string Cadena, bool Coma) Cadena es el string que queremos comprobar. Coma es un valor de tipo bool que indica con true que permitimos que exista una coma decimal y; con false, que no puede haber coma. 3.3. Mtodo ComprobarTexto. Su funcionalidad es verificar si en un string se contiene un texto facilitado como parmetro del mtodo. Si
el texto est en el string, el mtodo devuelve true, en caso contrario devuelve false. Firma del mtodo: internal bool ComprobarCaracter(string Cadena, string Buscar) Cadena es el string que contiene el texto donde vamos a buscar. Buscar es un string que contiene el texto a buscar en la variable Cadena. 4. Desarrollar una DLL llamada BibliotecaDLL, que incluya una clase llamada Libro y espacio de nombres GestionBiblioteca: La clase libro contiene los siguientes miembros: Propiedades: IdLibro (int), Titulo(string), ISBN (long), NombreAutor(string), NombreEditorial(string), Precio (float), Descripcion(string) 5. Agregar a la DLL anterior una clase llamada GestionLibros y espacio de nombres GestionBiblioteca, que incluya los siguientes miembros: Mtodos: 5.1. Mtodo AgregarLibro. Su finalidad ser agregar un nuevo libro a una matriz del tipo Libro. La firma del mtodo es: internal void AgregarLibro(ref Libro [ ] Matriz, Libro NuevoLibro 5.2. Mtodo EliminarLibro. Su finalidad ser eliminar un libro existen en una matriz de tipo libro. Es necesario que el mtodo busque primero si el libro existe en la matriz y, si es as, eliminar la fila completa de la matriz. El criterio para buscar se utilizar: IdLibro, Titulo o ISBN. La firma del mtodo es:
internal bool EliminarLibro(ref Libro [ ] Matriz, Libro BorrarLibro, byte Opcion) Opcion ser: 1 Borrar por IdLibro; 2 Borrar por ttulo; 3 Borrar por ISBN
Si el libro aparece en el criterio de bsqueda, en ese caso, procedemos a eliminarlo y devolvemos true. Si el libro no aparece, devolvemos false.
Pgina 104
5.3. Mtodo BuscarLibro. Su finalidad ser buscar un libro por uno de los siguientes criterios: IdLibro, Titulo e ISBN. La firma del mtodo es:
internal bool BuscarLibro(ref Libro [ ] Matriz, Libro BuscarLibro, byte Opcion) Opcion ser: 1 Buscar por IdLibro; 2 Buscar por ttulo; 3 Buscar por ISBN
Si el libro es localizado, devolvemos el nmero de fila de la matriz donde se encuentra el libro que cumple con el criterio de bsqueda. Si el libro no aparece en la matriz, devolvemos como valor un -1. 5.4. Mtodo BuscarVariosLibros. Su finalidad ser buscar en la matriz todos los libros que cumplan con el criterio de bsqueda, para despus ser devueltos en una matriz del tipo Libro con las filas de la matriz que cumplieron con el criterio. La firma del mtodo es:
internal Libro [ ] BuscarVariosLibros(ref Libro [ ] Matriz, Libro BuscarLibro, byte Opcion)
Opcin ser: 1 - Buscar por Autor exacto; 2 Buscar por Autor pero con el mtodo Contains de los string; 3. Buscar por Editorial exacto; 4. Buscar por Editorial pero con el mtodo Contains de los string, 5 Buscar por Descripcin pero con el mtodo Contains de los string. Las filas que hayan coincidido con el criterio de bsqueda se irn ingresando en una matriz del tipo Libro que, una vez recorrida toda la matriz en la que se realiza la bsqueda, ser devuelta por el mtodo.
6. Disear una clase llamada Cuenta y espacio de nombres GestionBanco, con los siguiente miembros: Propiedades: NumeroCuenta (int), CodigoCuenta (Guid), NombreTitular (string), ApellidosTitular (string), DNITitular (string), AceptaDescubierto (bool), MaximoDescubierto(int), Saldo (decimal), Intereses (float). La propiedad Intereses debe de ser declarada como una propiedad virtual, para que en la herencia con otras clases estas puedan redefinir la propiedad.
Pgina 105
Nota. Generar un nmero Guid: Guid numero = Guid.NewGuid(); Mtodos: 6.1. Mtodo Ingresar. Su finalidad ser incrementar el saldo de la cuenta. El mtodo devolver true si el ingreso ha podido realizarse y false en caso de que no se pueda realizar el ingreso. Antes de realizar la operacin de ingreso se verificar que la cantidad a ingresar no es cero ni un valor negativo. La firma del mtodo es: internal bool Ingresar(decimal Ingreso) Ingreso es la variable que contiene la cantidad a incrementar en el saldo. 6.2. Mtodo Retirar. Su finalidad ser decrementar el saldo de la cuenta. El mtodo devolver true si el reintegro ha podido realizarse y false en caso que no se pueda realizar. Antes de realizar la operacin es necesario comprobar que hay saldo disponible para cubrir el importe del reintegro. Si no hay importe suficiente hay que ver si existe la posibilidad de retirar fondos con el saldo en negativo (propiedad AceptaDescubierto en true). Si permite, verificamos el importe mximo al que puede llegar el descubierto. Si no se cubre la totalidad del lmite de descubierto, realizamos la operacin, en caso contrario devolvemos false y no ejecutamos el reintegro. 6.3. Mtodo AplicarIntereses. Su finalidad es aplicar el tipo inters para la cuenta, e incrementar el valor de los intereses al saldo de la cuenta. La firma del mtodo es: internal void AplicarIntereses() 7. Desarrollar una clase llamada CuentaCorriente y espacio de nombres GestionBanco. Esta cuenta hereda de Cuenta e incluye los siguientes miembros: Propiedades: Interes (float) y modificador override El tipo de inters en esta cuenta por defecto es el 1%.
Pgina 106
8. Desarrollar una clase llamada CuentaAhorro y espacio de nombres GestionBanco. Esta cuenta hereda de Cuenta e incluye los siguientes miembros: Propiedades: Interes (float) y modificador override El tipo de inters en esta cuenta por defecto es el 4%. 9. Aplicar a las clases de los ejercicios 6, 7 y 8, el mtodo ToString(), con el modificador override, para que el mtodo devuelva los apellidos y nombre del titular cuando se llame a este mtodo heredado de la superclase Object.
Prcticas: Prctica A. Desarrollar el diagrama de clases del ejercicio 4 y 5 del captulo 3. Prctica B. Desarrollar el diagrama de clases del ejercicio 6, 7, 8 y 9 del mismo captulo. Prctica C. Desarrollar el diagrama de actividad del ejercicio 4 y 5 del captulo 3. Prctica D. Desarrollar el diagrama de actividad del ejercicio 6, 7, 8 y 9 del captulo 3.
Ejercicios: 10. Desarrollar los diagramas de clases para una aplicacin que necesita llevar el control de un producto que tiene tres valores: Nombre, Unidades y Precio/Unidad. Ser necesario realizar cuatro funciones bsicas: Agregar un producto, Buscar un producto, borrar un Producto y por ltimo llevar un control de los stock del producto con las siguientes caractersticas: Podemos realizar bsquedas para conocer cules son los productos que tienen un stock mximo; los que tienen un stock mnimo; los que tengan un stock igual a cero; adems, podemos consultar para un producto cual es el importe total almacenado y; cuanto es el importe total para todos los productos almacenados. 11. Desarrollar el diagrama de clases y el diagrama de actividad para una DLL que permita utiliza genricos para el manejo de matrices. Las funciones a aplicar son: Alta de elemento, intercambio de elementos. Adems de hacer las clases, es necesario desarrollar la aplicacin que
compruebe el correcto funcionamiento del mismo. Deberemos de comprobar que podemos crear una matriz con al menos dos tipos distintos, as como intercambiar los ndices en cada una de las matrices. Prctica E. Desarrollar un modelo de tres capas para la implementacin de una aplicacin que lleve el control de una biblioteca. Prctica F. Desarrollar el modelo de tres capas para la implementacin de una aplicacin que lleve el control de una coleccin de discos.
Pgina 108

Capitulo 03 - DiseñoAplicacionesOOP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Capitulo 03 - DiseñoAplicacionesOOP

Uploaded by

Copyright:

Available Formats

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos.

3.1. Clases y Estructuras.

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Esquema del resultado en memoria al instanciar una clase:

Variables de la clase Persona string Nombre string Apellidos

Valores por Referencia

Variable de la Instancia AB13 43CB

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Esquema de instanciar una estructura

Variables de la clase Persona string Nombre string Apellidos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

3.2. Las Clases.

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

internal protected internal private

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

private void NombreMetodo(argumentos de entrada) { // Instrucciones }

Ejemplo de uso de mtodos:

private void Metodo(int Num) { Num = Num * 2; }

private void Metodo(ref int Num) { Num = Num * 2; }

Resultados: Valor de Numero = 20; Valor de Num = 40;

Resultados: Valor de Numero = 40; Valor de Num = 40;

Esquema de diferencias entre un parmetro por valor o por referencia

AA2C 1472 16DE BC74 FB12

AA2C 1472 16DE BC74 FB12

Direcciones de memoria en Hexadecimal

Direcciones de memoria en Hexadecimal

AA2C 1472 16DE BC74 FB12

AA2C 1472 16DE BC74 FB12

Direcciones de memoria en Hexadecimal

Direcciones de memoria en Hexadecimal

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Ms adelante en este mismo captulo, es estudiar los modificadores abstract y sealed.

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Objeto C Objeto D Objeto E

El Garbage Collector limpia el Objeto B Objeto A Objeto C Objeto D Objeto E

El Garbage Collector compacta la memoria Objeto A Objeto C

Memoria Reservada para la aplicacin, pero libre de asignacin

Posicin del Puntero

Objeto C ClaseD obj = new ClaseD();

Esquema de Races (roots) dentro del Garbage Collector

Objeto G Locales Objeto E Objeto D Registros CPU Objeto B Objeto A

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

3.3. Las Estructuras

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

3.4. La Herencia de clases

Super Clase Object

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Ejemplo de uso aplicado a una variable o atributo de la clase:

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Ejemplo aplicado a Clases:

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

Las clases Static y su miembros

Captulo 3. Diseo de Aplicaciones Orientadas a Objetos

3.7. Documentacin de Cdigo. Uso de etiquetas XML.

<summary>. La etiqueta <summary> se utiliza para describir un tipo o un

<remarks>. La etiqueta <remarks> se utiliza para agregar informacin sobre