P. 1
Diseño Orientado a Objetos

Diseño Orientado a Objetos

|Views: 1.089|Likes:
Publicado porLuisVB

More info:

Published by: LuisVB on Aug 19, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

05/05/2013

pdf

text

original

Diseño Orientado a Objetos

En esencia es una técnica de construcción y manipulación de abstracciones. La potencia de este paradigma, reside en que se basa en un enfoque, a la hora de realizar el  diseño y análisis de aplicaciones, muy similar a la realidad que nos rodea.  Ofreciendo una serie de ventajas como enfoque más natural, abstracción, reutilización, mayor  robustez, menor acoplamiento, mayor cohesión y mayor capacidad funcional. Por el contrario tiene como inconvenientes, un mayor coste del diseño de módulos reutilizables,  lenguajes de programación orientado a objetos son poco eficientes, y dificultad de rastreo a la hora  de depurar programas Clases y Objetos Hay que distinguir entre dos conceptos similares, pilares en los que sustenta el paradigma que estamos viendo. • Clase: Abstracción de un concepto, (idea o realidad), del mundo dentro de la ingeniería del  software. • Objeto: Es una instanciación o materialización de una clase. Para simplificar ambos conceptos, podíamos decir que la clase es un molde y los objetos el  resultado final y palpable de dicho molde. A modo de ejemplo, una clase sería un molde pastelero con una forma determinada, y los objetos  cada una de las galletas con dicha forma que se realizaran con el molde. Por tanto distintos objetos pueden pertenecer a la misma clase, y siempre clases diferentes  generan distintos objetos. Las clases están compuestos de dos partes, una estática que serían la compuesta por los atributos  o propiedades que son las variables que muestran el estado del objeto, y la parte dinámica,  compuesta por métodos que son las funciones y que pueden ser de acceso, actualización, y unos 

especiales constructores y destructores. Los objetos se instancian o crean mediante un mensaje que no es más que la invocación del  método constructor de la clase, de la misma manera dejan de existir por medio del mensaje  correspondiente, al invocar al método destructor. Por todo ello y a modo esquemático, podríamos determinar que la vida de un objeto e define en 3  pasos 1. Instanciación, mediante la invocación del mensaje constructor. 2. intercambio de mensajes con otros objetos y/o entorno 3. Finalización, mediante la invocación del método destructor  Visibilidad  Según la interfaz que especifiquemos a las distintas partes de la estructura de una clase. Tenemos 3 tipos • Pública: Todo lo definido con este tipo de interfaz, (métodos o atributos), son accesibles por  cualquier objeto. • Protegida: Todo lo definido bajo esta interfaz, será accesible por objetos de la misma clase o  subclase. • Privada: Es la interfaz más restrictiva, todo lo definido bajo este tipo es únicamente accesible por objetos de la misma clase. Relaciones entre Clases  Hay 3 tipos • Generalización: Relación entre clase origen, (subclase), y otra más genérica (superclase),  concepto asociado a “es un”, en donde cada objeto de la subclase es un objeto de la superclase.  Se implementa mediante la herencia

• Agregación: Se traduce como que una clase “es parte de”, (ej asignatura es parte de un plan de  estudios). El objeto que contiene a los otros se llama agregado y los contenidos son componentes.  Tenemos dos tipos • Fuerte: Componentes se crean al establecer el agregado y no tiene sentido su existencia sin este • Débil: Componentes pueden existir sin que esté el agregado que los contiene. • Asociación: Conexión semántica entre clases no relacionadas, (ej profesor y asignatura son  independientes, pero puede haber una relación de asociación pues los profesores imparten  asignaturas). Características de la Orientación a Objetos Por otro lado, el paradigma orientado a objetos tiene una serie de propiedades que le identifican como son: • Encapsulación: Los atributos de la clase/objeto son inaccesibles desde el exterior, dejando  accesible solo lo necesario para poder interactuar, sin mostrar nada más en cuanto al detalle de su  implementación sino por medio de su interfaz con la que nos comunicaremos por medio de  mensajes, (invocación de métodos), que tienen la forma objeto receptor.metodo (argumento[s]) 1 • Herencia: Capacidad de una clase para utilizar estructuras y métodos de clases ascendentes o  superclase. Una clase hija dispone de todos los métodos y estructura de la que hereda. Puede  realizarse la Anulación o Sustitución por medio de la cual redefinimos el método heredado  especializándolo. Existe dos tipos que son herencia simple, (desciende de una sola clase); y herencia múltiple,  (desciende de 2 o más clases)  Sustentado en este concepto, tenemos el de Jerarquía de Clases por medio del cual las clases se  estructuran definiendo relaciones entre ellas que ya hemos visto existen clases a las que se les  denomina clase virtual o abstracta de las cuales solo interesa su papel de superclase, existiendo  únicamente como “cabeza” de la pirámide dentro de la jerarquía, que solo contiene la definición de  métodos sin implementar y que se desarrollarán en las clases hijas por medio de la sobrecarga.

• Polimorfismo: Capacidad de referirse a distintos objetos de distintas clases de una jerarquía con  el mismo elemento, (necesariamente sería referencia a clase padre o a clase donde se ha  definido). Existen distintos tipos de polimorfismo, así tenemos • Sobrecarga: Métodos o los atributos pueden tener varias formas de invocación o uso, pueden  existir tantas versiones de un método como diferentes parámetros pueda llevar su invocación. Puede existir incluso la sobrecarga de operadores, (+,­,...) 2   

1 Pudiendo provocar dos tipos de problemas.        1. Herencia Repetida donde tomando un ejemplo la clase profesor­universitario hereda de las  clases profesor y universitario, heredará 2 veces el atributo persona.        2. Ambigüedad se produce al tener 2 atributos con el mismo nombre 2 Por ejemplo + puede ser el símbolo de suma entre números o la concatenación de contenidos  entre cadenas de caracteres   

• Genericidad o Polimorfismo Paramétrico: Forman clases que describen estructuras genéricas,  (ej Imprime (T objeto), donde Objeto puede ser de cualquier tipo) 3 • Polimorfismo Dinámico: Se produce cuando al manipular objetos utilizamos uno de una clase  hija como si fuera objeto de la clase padre. Hay 3 tipos  • Dinámico Subtipado: Subclase cubre todo el comportamiento de la clase padre. • Dinámico Normal: Clase derivada tiene un comportamiento diferente al de la clase base.  (lenguaje C++ con punteros a objetos)  • Enlace Dinámico: Lenguajes no soportan lo visto, los métodos van precedidos de la partícula  virtual.

Proceso de Desarrollo Orientado a Objetos Compuesto de 3 fases 1. Planificación y Especificación de Requisitos 2. Construcción      a. Diseño de Alto Nivel      b. Diseño de Bajo Nivel      c. Implementación      d. Pruebas 3. Instalación y Puesta en Marcha Mediante enfoque iterativo, tomando en cada ciclo una serie de requisitos hasta que se completan, creciendo por tanto el sistema en cada ciclo. Planificación y Especificación de Requisitos Tiene como objetivo determinar si es apropiado el abordar el problema desde el paradigma  orientado a objetos, definiéndose u plan a seguir, creando lo primero un informe preliminar donde  se definen los requisitos, registramos los términos en un glosario, (tendrá continuidad en las  siguientes fases), opcionalmente se crea un prototipo y se define un modelo de casos de uso 4  junto con el borrador del modelo conceptual y de la arquitectura del sistema. De la Especificación de Requisitos resaltar que identifica aquello que es relevante teniendo una  repercusión importante cualquier error en esta fase Como resultado final, se obtiene un documento, (no definido en UML), habitualmente escrito en  lenguaje natural y con el siguiente contenido • Propósito • Ámbito

• Funciones • Atributos Al definir los límites del sistema determinamos lo externo, (representado por actores) y lo interno,  (que suele ceñirse al hardware y al software).   

3 Java no lo soporta 4 Instrumento narrativo que nos muestra una secuencia de eventos de un actor (agente externo,),  que utiliza el sistema para completar un proceso. Consta de Sistema (ámbito del problema), Actor  (Agente externo que interactúa con el sistema) y Escenario (Relación de interacciones entre los dos  anteriores).   

Casos de uso Instrumento narrativo que muestra la secuencia de eventos de un actor o agente externo,  (entendiendo como tal cualquier entidad o persona), que utiliza el sistema para completar un  proceso, denominado Caso de Uso La identificación de los casos de uso puede ser • Basándose en Actores: Identifica los actores, obteniendo para cada uno los procesos que inicia  o en los que participa. • Basándose en Eventos: Identifica los eventos a los que el sistema debe responder y se  relacionan con actores. Una vez identificados, conviene tratarlos con el mayor grado de abstracción posible, definiéndose  para ello casos de uso de alto nivel, especificando nombre, actores, descripción y tipo que puede  ser Primarios, (procesos principales), Secundarios, (uso menor) y Opcionales. Desde el punto de vista del nivel de detalle tenemos

• Esencial: Describen el proceso a nivel abstracto, (independientemente de la tecnología de la  implementación).

• Real: Describen el proceso en detalle, en términos de solución específica. Los diagramas se dibujan como una caja, siendo el caso de uso lo que hay en su interior, los  actores están fuera y ambos están relacionados por medio de líneas. Los casos de uso más importantes, se describen con un detalle mayor mediante un formato  expandido que contendrá aparte de lo especificado anteriormente, referencias, (a otros casos de  uso y requisitos), curso típico de eventos, (interacción sistema – actores mediante acciones  numeradas), curso alternativo, (puntos donde pueden existir alternativas con su descripción). Finalmente el proceso de planificación mediante casos de uso sería • Tras listar los requisitos, se definen los límites, se identifican los actores • Se escriben todos los casos de uso en formato de alto nivel clasificándose en prioritarios,  secundarios y opcionales.

• Se dibuja el diagrama • Se detallan e ilustran las relaciones entre casos de uso • Se ordenan según prioridad • Los más prioritarios se describen en formato expandido, el resto se describirá de esta forma en  sucesivas interacciones. Fase de Construcción. ­ Diseño de Alto Nivel Su objetivo es obtener una óptima comprensión del problema por parte del equipo de desarrollo sin entrar en los detalles de la implementación. Las actividades para llevar esto a cabo serían: • Definir casos de uso esenciales en formato expandido 5 • Refinar diagrama • Especificar el Modelo Conceptual    

5 Si no están hechos ya   

• Refinar el Glosario • Definir Diagramas de Secuencia • Definir Contratos de operación • Definir Diagramas de Estados 6 Modelo Conceptual: Trata de identificar los conceptos que conforman el dominio del problema, por  medio de un diagrama de estructura estática. Busca la representación de conceptos, no la de  componentes software.  Tiene 3 pasos

• Identificar Conceptos: Basándonos en la especificación de requisitos.  Un concepto se representa en UML como apreciamos en la figura de la  derecha. • Identificar Relaciones: Pudiendo existir 3 tipos        * Asociación: Relación entre conceptos indicando las conexiones con sentido de interés en el  conjunto de casos de uso que tratamos. Se representa media te una línea que une conceptos indicando nombre, sentido de la relación,  (mediante punta de flecha), roles de cada concepto y multiplicidad 7 

        * Agregación: Donde 1 o n conceptos son “parte de” otro. Se representa mediante un rombo al  lado del concepto que representa el agregado, siendo Fuerte si está relleno o débil caso contrario.        * Generalización: Varios conceptos pueden actuar sustituyendo a otro más genérico, pues son  especializaciones del concepto que descienden.

• Identificar Atributos: Tomar valores simples, (los complejos los modelamos como conceptos y  se relacionan mediante asociaciones). Teniendo todo esto, conseguimos el modelo conceptual que se irá refinando a lo largo del  desarrollo como podemos apreciar en la ilustración Glosario: Se irá generando según avanza el desarrollo y conteniendo una descripción textual de  cualquier elemento evitando ambigüedades. Diagramas de Secuencia: Permite investigar el  comportamiento del sistema, mostrando la iteración  entre actores y el sistema. Muestra por cada caso de uso los eventos que genere  el usuario, su orden y los eventos que se  intercambian entre sistemas Por cada caso de uso se  realizará un diagrama para curso típico y otro para las  alternativas de mayor interés. Se representa el sistema con un cuadrado y una línea  vertical debajo, haciendo lo mismo por cada actor identificado, partiendo

del texto del curso típico de eventos, opcionalmente es posible incluir texto al margen a modo de  comentario. Todos los mensajes parten del actor y llegan al sistema, careciendo de sentido lo contrario y siendo  un error. Nunca habrá mensajes entre actores   

6 Opcional 7 Puede ser un nº fijo, (3); rango, (1..3); asterisco, (2..*) que representa 2 o más y solo asterisco,  (*), que representa de 0 a n   

Contrato de Operaciones: Documento declarativo que describe una operación sin entrar en el  detalle del como, mediante pre y post condiciones respecto a los cambios de estado. Tras identificar las operaciones en el diagrama de secuencia, construimos un contrato por cada  una, especificando el propósito en el apartado de responsabilidades, rellenando las  postcondiciones y describiendo los cambios de estado de los objetos del modelo conceptual. Es necesario añadir las asociaciones a los objetos creados. Diagramas de Estado: Sirven para modelar el comportamiento. Se pueden aplicar a una clase  software, un concepto, un caso de uso, aunque en el diseño de alto nivel solo se puede aplicar a  los dos últimos Muestra la secuencia permitida de eventos externos reconocidos y tratados por el sistema. El diagrama de estado del sistema, será una combinación de diagramas de estado de todos los  casos de uso. Se representa mediante un grafo, cuyos nodos son los estados y los arcos las transiciones con los 

nombres de los eventos. El estado será una caja 1 o 2 compartimentos, en uno aparece el nombre  y en el otro, (opcional), las acciones de E/S y acciones internas, (ejecuta un evento que no produce  cambio de estado), representándose como entrada/acción asociada; salida/acción asociada. Puede representar ciclos continuos o vida finita donde hay ∙pseudoestados” iniciales de creación 8  y final de destrucción 9. 

  

8 Representado mediante un círculo relleno o sólido 9 Representado mediante un círculo relleno o sólido, rodeado de otro círculo     Fase de Construcción ­ Diseño de Bajo Nivel El objetivo es la creación de una solución a nivel lógico basado en el conocimiento adquirido en la etapa anterior. Las actividades de esta fase son • Definir Casos de Uso Reales • Definir Informes e Interfaces de Usuario • Refinar la Arquitectura del Sistema • Definir Diagramas de Iteración

• Definir Diagramas de Clases de Diseño (en paralelo) Casos de Uso Reales: Describe el diseño real del caso de uso con una tecnología concreta de  implementación y E/S, añadiendo esbozos de la interfaz de usuario. Su formato es similar a un  caso de uso expandido. Diagramas de Iteración: Muestra el intercambio de mensajes entre objetos para cumplir las post­ condiciones del contrato. Existen 2 tipos • Diagramas de Colaboración: con mayor expresividad y mejor acomodo espacial • Diagramas de Secuencia Es una de las actividades más importantes, pues se toman decisiones clave acerca del  funcionamiento del sistema. Se representan, (según notación UML), de la siguiente manera. Diagramas de Colaboración: muestra objetos entre los que hay enlaces Clases: caja, en su interior aparecerá el nombre Objetos: se representa como el anterior, pero el nombre se especifica subrayado precedido de : o  subrayado como nombre objeto:clase 

Enlaces: línea que muestra la conexión entre 2 objetos por donde se intercambian

mensajes  Mensajes: Asociado al anterior, contiene el nombre del mensaje, parámetros, dirección a la que va  dirigida, valor de retorno y tipo. Todos tienen asociado un nº secuencia, (excepto el que representa  la operación de sistema de inicio del diagrama) El formato básico puede ampliarse indicando * Alternativa: Ejecución de uno u otro va en función de una condición, que asociamos a cada  mensaje entre corchetes a continuación del número de secuencia identificados por letra minúscula  distinta por alternativa. * Anidamientos: Muestra número del mensaje con el formato x.y, que indica que la secuencia X,  no finalizará hasta que no se ejecuten todos los Y.

* Iteraciones: Antepone un asterisco al nº de secuencia, pudiendo añadirse entre corchetes la  condición para que el bucle permanezca como vemos en la figura También es posible representar  colecciones de objetos, Los mensajes dirigidos a colecciones de objetos, son recogidos por la  colección y NO por los objetos que componen la estructura Lo ideal será un diagrama por cada  operación, definida mediante contratos especificados en etapas anteriores. Las operaciones del  sistema asociado con cada diagrama será el mensaje inicial, aún así si el mensaje se complica, lo  mejor es dividirlo.

Partiendo del apartado de responsabilidades 10 y post­condiciones de contrato y de las  descripciones de los casos de uso, se diseñará un sistema de objetos que interaccionan  Diagramas de Clases de Diseño:  Formada por todas las clases (obtenidos de diagramas de colaboración y otros con  responsabilidades específicas), y sus relaciones. Es una especificación de clases software que  incluye Clases, asociaciones y atributos; Interfaces con operaciones y constantes; métodos;  navegabilidad y dependencias. Cuando una clase conoce a otra por un medio distinto de un atributo, es necesario representarlo  mediante dependencias, (línea discontinua). Si un objeto debe conocer a otro para invocar a sus métodos, el primero tiene “visibilidad”sobre el  segundo, siendo la manera más directa por medio de un atributo. En un diagrama de clases, tenemos que representar también • Parámetro: Cuando a un método se le pasa como parámetro un objeto de otra clase, El 1º tiene  visibilidad de parámetro sobre el 2º, etiquetando dicha relación como <>

• Local: Cuando en un método de una clase, se define una variable local que es objeto de otra  clase. Se etiqueta como <> • Global: Variable global del sistema y los métodos de dicha clase utilizan dicha variable. Se  etiqueta como <> No es necesario representar una relación de dependencia entre clases, (están relacionadas por  asociación). Solo se incluye para conocer los elementos a revisar cuando hay cambios en el diseño  de elementos del sistema. Para crear un diagrama de clases se necesitan los siguientes pasos: • Identificar todas las clases mediante diagramas de iteración • Representarlas en Diagramas de Clases • Añadir atributos de los conceptos del modelo conceptual y los métodos según el diagrama de  iteración • Añadir información del tipo a métodos y atributos. • Añadir asociaciones para soportar visibilidad, (líneas), añadiendo flechas orientadas • Añadir relaciones de dependencia, (líneas discontinuas), indicando visibilidad no de atributos Solo deben mostrarse las clases que tengan interés en cuanto que tengan algún tipo de  responsabilidad. No hay una transición directa del modelo conceptual al diagrama de clases de diseño, uno busca la  comprensión del dominio y el otro la solución software, (añadiendo detalles como el lenguaje de  programación).   

10 Responsabilidades son obligaciones de un objeto en cuanto a su comportamiento, no es lo  mismo que un método, pero estos se implementan para satisfacer las responsabilidades   

Los atributos y métodos, deben llevar la visibilidad 11 asignada y se incluirán valores por defecto,  así como detalles de implementación 

    Navegabilidad Es una propiedad que nos indica la posibilidad de “navegar” unidireccionalmente de objetos de la  clase origen a objetos de la clase destino, implicando visibilidad de atributo en clase origen. Se implementa mediante una referencia a clase destino en la clase origen. En los diagramas, las asociaciones deben ser necesarias, de otra manera deberán eliminarse. Situaciones más comunes: A envía un mensaje a B A crea una instancia de B A necesita una conexión con B   

 Patrones de Diseño Son soluciones que se pueden aplicar en un contexto particular, es recurrente, (relevante a otras  situaciones). Son de gran ayuda pues capturan la experiencia y la hacen accesible a los no  expertos. El conjunto de patrones, genera un vocabulario específico, ayudando a los desarrolladores a  comunicarse mejor, facilitando la reestructuración del sistema. Con ellos se obtiene una grandísima rehusabilidad. Existe la siguiente clasificación • Patrones de Creación: Inicialización y configuración de clases y objetos • Patrones Estructurales: Tratan de Desacoplar, interfaz e implementación de clases y objetos • Patrones de Comportamiento: Interacciones dinámicas entre clases y objetos No es aconsejable  la utilización de variables globales por los efecto colaterales que generan, aunque en ocasiones  sería interesante clases que solo tuvieran una instancia, (un solo objeto), en donde varios objetos  de otras clases pueden invocar al método del objeto mencionado siendo accesible de forma global. Se implementa mediante métodos de clase, (estáticos) y se etiquetan con el estereotipo <>    11 + pública # protegida ­ privada Diseño Orientado A Objetos José Mª Zamora Bausá

Datos del Autor  Nombre     José Maria Zamora Bausá  Ubicación  Toledo ­ España 1991 ­ 1994 CARRERA TÉCNICA DE INFORMÁTICA DE GESTIÓN, avalada por la University of  Cambridge con título de Analista ­ Programador. Escuela De Sistemas Informáticos (E.S.I.) 1994 ­ 1995  MASTER EIDOS PARA DESARROLLADORES 1996 ­ 1997  NANFOR IBERICA . Master en programación C++ bajo Windows 3.x / 95 (Borland C 

++ v. 5) 1997 ­ 1998  KERNELL. Master en programación visual de entornos MS. (Visual Basic, Visual C++,  Visual J++). 1998              AIG S.L. Formación interna en Oracle y Developer 2000. Actualmente estoy matriculado en la carrera de ingeniería técnica en informática de gestión de la Universidad de Educación a Distancia (U.N.E.D.)

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->