TECNICAS DE ANALISIS ORIENTADA A OBJETOS

CLASIFICACION DE LAS TECNICAS

3.1 Las Tcnicas Textuales: Las tcnicas denominadas textuales son aquellas que se basan en descripciones informales, pero precisas, escritas en lenguaje natural para identificar objetos, atributos y operaciones tanto del dominio del problema como del dominio de la solucin, a travs de un anlisis sintctico de sustantivos, adjetivos, verbos y adverbios. Las tcnicas de esta categora tienen su origen fuera del paradigma de la orientacin a objetos, especficamente en el trabajo de [Abbott83], que propone disear programa en Ada a partir de descripciones informales en ingls. Sin embargo, estas tcnicas son insuficientes para abordar problemas ms complejos

y pueden ser consideradas como sobrepasadas. Se consideran aqu slo por su relevancia histrica. 3.2 Las Tcnicas Evolutivas Las tcnicas evolutivas son aquellos productos de la extensin o evolucin de tcnicas dirigidas por alguna de las dimensiones del modelado (estructural, dinmica y/o funcional) y su complementacin con otros aspectos del modelado. Esta categora de tcnicas puede ser subdividida segn la dimen-sin dominante en dirigidas por datos, dirigidas por procesos y dirigidas por dinmica. Sin duda esta es la categora ms poblada por razones obvias: las tcnicas originales son todas ampliamente conocidas y probadas en el desarrollo de sistema de software. Entonces parece natural intentar extenderlas para la orientacin a objetos. 3.2.1 Las Tcnicas Dirigidas por Datos: Esta subcategora incluye las tcnicas que utilizan extensiones semnticas de modelos de datos o el denominado modelado de informacin. El modelo de datos ms ampliamente utilizado por su divulgacin y carcter intuitivo es el modelo entidad-relacionamiento extendido. Como la tcnica ms representativa en esta subcategora puede ser indicada Object-Oriented Analysis (OOA) de [Coad&Yourdon92]. La tcnica propone cinco actividades principales que resultan en un modelo multicitadas, donde cada camada es construida sobre la camada anterior. Las actividades son: 1) Ubicacin de clases y objetos. 2) Identificacin de estructuras. 3) Identificacin de asuntos. 4) Definicin de atributos. 5) Definicin de servicios. 3.2.2 Las Tcnicas Dirigidas por Procesos: Esta subcategora incluye las tcnicas que utilizan extensiones de modelos funcionales con descomposicin funcional. El modelo funcional ms ampliamente utilizado, tambin por su divulgacin y carcter intuitivo, es el diagrama de flujo de datos (DFD). Como la tcnica ms representativa en esta subcategora puede ser indicada Object-Oriented Requirements Specifications Method de [Bailin89]. Este mtodo de AOO se basa en los Entity Data Flow Diagrams que representan

tanto entidades (objetos) como funciones (mtodos). El mtodo propone los siguientes pasos: 1) Identificar las entidades (objetos) claves en el dominio del problema. 2) Distinguir entre entidades activas y pasivas. 3) Establecer flujos de datos entre las entidades activas. 4) Descomponer entidades (o funciones) en subentidades y/o funciones. 5) Buscar nuevas entidades. 6) Agrupar las funciones bajo las nuevas entidades. 7) Definir dominios apropiados para las entidades. 3.2.3 Las Tcnicas Dirigidas por Dinmica Esta subcategora incluye las tcnicas que utilizan extensiones de modelos dinmicos de alguna especie. Los modelos dinmicos ms utilizados son los diagramas de transicin de estados, los state charts de [Harel87] y las redes de Petri [Heuser90].Como tcnica representativa de esta subcategora puede ser indicada la propuesta de [Kappel&Schrefl91], que corresponde a una variante de diagrama de transicin de estado y redes predicado/transicin adaptada para la orientacin a objetos. 3.3 Las Tcnicas Integracionistas: Esta categora representa a aquellas tcnicas que integran modelos separados de las diferentes dimensiones. Como tcnica representativa de esta categora se encuentra la de [Rumbaugh91]. Los autores proponen una tcnica de desarrollo de software orientado a objetos denominada OMT (Object ModelingTechnique),que incluye explcitamente el AOO como la construccin de tres modelos, uno para cada dimensin, que especifiquen el dominio del problema considerando los requerimientos. El procedimiento del AOO est ntimamente ligado a la construccin de modelos de estos tres aspectos: modelado estructural, modelado dinmico y modelado funcional. El orden en que debe ser realizado el modelado es: 1) objetos, 2) dinmica y 3) funcionalidad. Para el modelado de objetos se utiliza una extensin del modelo entidadrelacionamiento. En el modelado dinmico es utilizada una variante de los state charts. En el modelado funcional son usados DFD extendidos con flujos de control. La integracin final de estos modelos, por ejemplo la asociacin de las funciones (del modelo funcional) y las acciones (del modelo dinmico) a los objetos, es hecha en una fase posterior denominada diseo de objetos.

3.4 Las Tcnicas Reversas: Las tcnicas reversas son aquellas originadas a partir de necesidades de implementacin, como por ejemplo el soporte a conceptos de lenguajes de programacin orientados a objetos especficos (por ejemplo Smalltalk, C++, Eiffel o Ada). Esta categora puede ser fcilmente confundida con otras, pues al soportar conceptos de un lenguaje de programacin orientado a objetos puede ser apropiado utilizar enfoques, notaciones y procedimientos de otra naturaleza. La tcnica escogida como ms representativa es la propuesta por [Nerson92], que define una tcnica de anlisis y diseo orientados a objetos para el lenguaje Eiffel [Meyer88], usando la notacin de objetos mejorada (Better Object Notation o BON). Esta tcnica consiste en tres pasos: 1) Identificacin, designacin y clustering de clases. 2) Identificacin de eventos y protocolos de comunicacin entre objetos. 3) Definicin de clases y diseo preliminar de la arquitectura bsica. 3.5 Las Tcnicas Comportamentales Las tcnicas comportamentales renen tcnicas en las cuales los objetos son derivados a partir del comportamiento externo que debe exhibir el sistema. Actuando de esta forma, en general se pospone el encapsulamiento de los atributos y/o mtodos en los objetos hasta ms adelante en el procedimiento, porque inicialmente interesa el comportamiento global del sistema y la interaccin de componentes al interior del sistema que satisfacen este comportamiento global. Estos componentes sern potencial es objetos del sistema. El mejor representante de esta categora es Object-Oriented Software Engineering (OOSE) de [Jacobson92] (una simplificacin de la metodologa Objectory de los mismos autores) que contempla la fase de anlisis. Para esta fase, OOSE sugiere los siguientes pasos: 1) Identificacin de actores. 2) Construccin de los casos de uso (use case model). 3) Descripcin de las interfaces. 4) Modelado de objetos del dominio del problema. 5) Refinamiento del modelo de requerimientos. 6) Construccin del modelo de anlisis. El modelo de casos de uso es el modelo fundamental de esta tcnica. Con los actores (papeles de usuarios del sistema) identificados se construye un modelo que describe un aspecto de la funcionalidad del sistema. Este modelo representa diversas maneras especficas de usar el sistema. Cada caso de uso describe un

Escenario completo de eventos iniciados por un actor y especifica la interaccin que ocurre entre el actor y el sistema.

HERRAMIENTAS DEL SOFTWARE AL APOYAR EL ANLISIS ORIENTADO A OBJETOS.

Reutilizacin: Las clases para maximizar la reutilizacin deben ser construidas de manera que puedan ser personalizadas. Un repositorio debera ser cargado con una coleccin de clases reutilizables. Un objetivo permanente de las tcnicas Orientadas a Objetos, es conseguir la reutilizacin masiva en la construccin de software. Estabilidad: Las clases diseadas para la reutilizacin repetida, llegan hacer estables de la misma manera que los microprocesadores y otros chips que son bastante estables. Las aplicaciones sern construidas utilizando chips de software, el encapsulamiento oculta los detalles y hace fcil el uso de clases complejas Construccin de Objetos de complejidad Creciente: Esto posibilita construir componentes de software complejos y los mismos se utilizarn para construir otros bloques de software ms complejos. Una buena manera de fabricar es construir tomando una lista de materiales de partes y sub-partes existentes. Confiabilidad: EL software construido a partir de una librera de clases es tablas, es probable que se encuentre libre de errores, respecto a construir software desde el inicio. Cada mtodo en una clase es el s mismo, simple y diseado para ser confiable. Verificacin de Correcciones: El Diseo Orientado a Objetos con tcnica formal para la creacin de mtodos, puede generar potencialmente software de alta confiabilidad. Usan tcnicas para verificar y garantizar la operacin correcta de una clase, probablemente estn disponibles en nuevas generaciones de herramientas CASE Orientadas a Objetos. Diseo Rpido: Las aplicaciones son creadas tomando componentes preexistentes. Muchos componentes son construidos de tal forma que, puedan ser observados, personalizados, para un diseo particular. Los componentes pueden ser visto y enlazados en la pantalla de la herramienta CASE.

TECNICAS DE DISEO ORIENTADA A OBJETOS

El Diseo Orientado a Objetos se define como un diseo de sistemas que utiliza objetos auto-contenidos y clases de objetos. Para crear un sistema orientado a objetos es necesario analizar y disear orientado a objetos, UML no es suficiente, necesitamos usar tcnicas adicionales para ayudarnos. Alguna de estas tcnicas que podemos usar para detectar clases, secuencias y otros son:

Narrativa de Casos de Uso: Tcnica para describir la serie de pasos para llevar a cabo una funcionalidad en el sistema. Anlisis CRC: Tcnica para descubrir los objetos de negocio, ms tarde en la etapa de diseo se convierten en clases. Anlisis de Robustez o Modelo de Anlisis: Tcnica para encontrar la secuencia de llamadas entre los objetos involucrados en la solucin de 1 caso de uso. Diagrama de Capas y Niveles: Tcnica que le ayuda al arquitecto a identificar la tecnologa requerida en un sistema multicapa.

Te has preguntado: Cmo obtengo las clases de negocio del sistema? Las clases core o de negocio pueden y deben obtenerse desde la fase de anlisis, no se descubren hasta la construccin, para ello puede aplicar la experiencia o usar esta tcnica mientras te vuelves experto. No es la nica tcnica pero es muy efectiva El producto es un diagrama de clases de negocio llamado Modelo de Dominio. No contiene detalles tcnicas como getters o atributos estticos, ms bien tipos bsicos, asociaciones, cardinalidad y navegacin.

Pasos para aplicar esta Tcnica: Identificar Abstracciones Clave (Objetos de negocio).

1. Subrayar sustantivos en los documentos fuente de requerimientos: de Casos de Uso, Reportes, Requerimientos del SRS, minutas, etc. 2. Colocar los sustantivos en la lista de Abstracciones Clave candidatas.

Identificar Responsabilidades: Atributos y operaciones. 3. Crear una tarjeta CRC por cada abstraccin. 4. Identificar propiedades de cada abstraccin candidata. Identificar atributos simples y compuestos. Anotarlos en la seccin de responsabilidades. 5. Identificar operaciones de cada abstraccin candidata. Identificar acciones, verbos que se aplican sobre la abstraccin. Anotarlas en la seccin de responsabilidades.

Identificar Colaboraciones. 6. Identificar si la abstraccin mantiene una relacin tiene un depende de contiene a con otra. Anotarla se la seccin de colaboracin. Si hay una propiedad compuesta crear otra tarjeta, sacarla de la lista de propiedades y anotar su colaboracin en ambas tarjetas.

Eliminar abstracciones no clave. 7. De la lista de candidatos eliminar las abstracciones clave que no colaboran o no forman parte como propiedad con otra abstraccin.

Documentar el resultado del anlisis. 8. Crear diagrama de objetos de negocio (modelo de dominio). Anotar el nombre del objeto, cardinalidad, navegacin. Introducir objetos intermedios para relaciones muchos a muchos.

ANALISIS DE ROBUSTEZ:

El sistema no se forma solo de clases de negocio, Cmo obtener las dems clases que intervienen en el sistema? Esta tcnica no es muy conocida pero es muy til, responde a las preguntas anteriores y adems ayuda a separar los elementos del sistema por capas, validar la narrativa del caso de uso y facilita la creacin de los diagramas de secuencia. El resultado del anlisis robusto es un diagrama de colaboracin con el detalle de la secuencia de llamadas entre objetos que participan en un caso de uso.

Elementos del anlisis robusto:

Boundary o Interfaz de usuario: Son objetos Que muestran o piden datos. Representa unas pantallas, ventana, pgina, reporte. Service o Control: Son objetos Que hacen. Son componentes que invocan, coordinan a otros objetos, realizan clculos, consultan o modifican objetos de negocio. Entity u Objeto de Negocio: Son objetos Que son. Son los objetos detectados en el modelo de dominio, casi siempre son persistentes, es decir, se guardan en un repositorio de datos. REGLAS: Para poder hacer este anlisis es imprescindible tener la narrativa el caso de uso y las clases de negocio.

Se toma un caso de uso y se coloca el actor que inicia la funcionalidad del caso de uso. Todo actor que inicie una interaccin con el sistema debe iniciar con un objeto Boundary.
8

 Los Boundaries se detectan en la narrativa de casos de uso cuando se mencionan los conceptos: pantalla, pgina, ventana. Si en la narrativa no se detecta un Boundary inicial entonces hay un error en el caso de uso. los servicios se detectan cuando en el caso de uso se menciona: El Sistema realiza, El Sistema ejecuta. Los entities son las clases de negocio u objetos del modelo de dominio que se detectaron con el anlisis CRC. La interaccin se indica trazando una lnea entre los objetos y se coloca un nmero y el nombre del mensaje a lado de la lnea. El acceso a un objeto entity se hace a travs de un objeto service. Las operaciones CRUD son realizadas directamente por los objetos entity.

Caractersticas principales del Diseo Orientado a Objetos:

 Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas. Los objetos son independientes y encapsulan el estado y la representacin de Informacin. La funcionalidad del sistema se expresa en trminos de servicios de los objetos. Las reas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parmetros. Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en paralelo. Ventajas del Diseo Orientado a Objetos: Fcil de mantener, los objetos representan entidades auto-contenidas. Los objetos son componentes reutilizables. Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del sistema. Desarrollo Orientado a Objetos: El anlisis, diseo y programacin orientada a objetos estn relacionados pero son diferentes. El anlisis orientado a objetos concierne al desarrollo del modelo de objetos del dominio de la aplicacin. El Diseo Orientado a Objetos trata del desarrollo del modelo del sistema orientado a objetos para implementar los requerimientos.

Mtodos de Diseo Orientado a Objetos: Algunos mtodos que fueron originalmente basados en funciones (mtodo de Yourdon) han sido adaptados al diseo orientado a objetos. Otros

mtodos como el mtodo de Booch han sido especficamente desarrollados especficamente para el Diseo Orientado a Objetos. El Diseo Orientado a Objetos es un mtodo de diseo desarrollado para soportar la programacin en Ada.
10

 JSD (Jackson system development) tiene una cierta orientacin a objetos pero no contiene informacin sobre estados entidad. Componentes del Diseo Orientado a Objetos:

La identificacin de objetos, sus atributos y servicios. La organizacin de objetos dentro de una jerarqua. La construccin de descripciones dinmicas de objetos que muestran cmo se usan los servicios. La especificacin de interfaces de objetos.

Objetos, Clases y Herencia: Los objetos son entidades en un sistema de software que representan instancias de entidades del mundo real. Las clases objetos son templates para objetos. Pueden usarse para crear objetos. Las clases objetos pueden heredar atributos y servicios de otras clases objetos. Objetos: Un objeto es una entidad que tiene un estado y un conjunto definido de operaciones que operan sobre este estado. El estado se representa mediante un conjunto de atributos del objeto. Las operaciones asociadas con el objeto proveen servicios a otros objetos (clientes) que requieren estos servicios cuando necesitan realizar alguna actividad de cmputo. Los objetos se crean de acuerdo a una definicin de la clase objeto. La definicin de la clase objeto sirve como template para los objetos. Esta incluye las declaraciones de todos los atributos y servicios los cuales deben

estar asociados con un objeto de esta clase. Comunicacin entre Objetos: Conceptualmente los objetos se comunican mediante paso de mensajes.
11

 Mensajes. El nombre del servicio requerido por algn objeto que llama. Copias de la informacin requerida para ejecutar el servicio y el nombre de quien tiene esta informacin. En la prctica, los mensajes se implementan a menudo mediante llamadas de procedimientos. Nombre = nombre de procedimiento. Informacin = lista de parmetros.

Herencia: Los objetos son miembros de clases que define tipos de atributos y operaciones. Las clases pueden organizarse en jerarquas de clases donde una clase se deriva de una clase existente (superclase). Una sub-clase hereda los atributos y operaciones de su super-clases y puede aadir nuevos mtodos o atributos propios. Herencia y Diseo Orientado a Objetos

Existen distintos puntos de vista de la herencia respecto al Diseo Orientado a Objetos. Punto de vista 1. Identificar la jerarqua de herencias es una parte fundamental del diseo orientado a objetos. Obviamente esto solo puede implementarse utilizando lenguajes de programacin orientados a objetos. Punto de vista 2. La herencia es un concepto til para implementacin que permite reusar los atributos y las operaciones. La identificacin de la jerarqua de herencias en la fase de diseo pone muchas restricciones en la

implementacin.

Identificacin de Objetos: La identificacin de objetos es la parte ms difcil del diseo orientado a objetos.
12

 No hay una frmula mgica para la identificacin de objetos. Se base en la experiencia y el conocimiento del dominio de los diseadores del sistema. La identificacin de objetos es un proceso iterativo. Es difcil que salga bien la primera vez.

DIAGRAMAS DE ENTIDAD RELACION ORIENTADA A OBJETOS

Conceptos previos vistos anteriormente: Los modelos de datos son el conjunto de conceptos o herramientas conceptuales que sirven para describir la estructura de una BD: los datos, las relaciones y las restricciones que se deben cumplir sobre los datos. Se denomina esquema de la BD a la descripcin de una BD mediante un modelo de datos. Este esquema se especifica durante el diseo de la BD. Modelos de datos lgicos basados en objetos: Se usan para describir datos en el nivel conceptual y en el externo. Se caracterizan porque permiten especificar estructuras flexibles y restricciones de datos. Por ejemplo, el Modelo Entidad-Relacin y el Modelo Orientado a Objetos. El Modelo Entidad-Relacin (o Modelo E-R o Modelo Entidad-Interrelacin) fue propuesto por Peter Chen en 1976 para la representacin conceptual de los

problemas del mundo real. Este modelo de datos representa los datos utilizando grafos y smbolos grficos, adems de tablas para la representacin de los datos y sus relaciones.

13

Conceptos bsicos usados en el Modelo E-R: 1. Entidad: Es un objeto del mundo real que tiene inters para la empresa. Por ejemplo, la entidad ALUMNO de un centro escolar o la entidad CLIENTE de una empresa. Se representan con rectngulos con el nombre en el interior. 2. Conjunto de Entidades: Es un grupo de entidades del mismo tipo, y no tienen que ser conjuntos disjuntos, es decir, puede haber una entidad que pertenezca a varios conjuntos de entidades a la vez. Por ejemplo, el conjunto de entidades ALUMNOS de un centro escolar. 3. Entidad Fuerte: Es una entidad que no depende de otra entidad para su existencia. Por ejemplo, la entidad ALUMNO es fuerte pues no depende de otra para existir como entidad, mientras que la entidad NOTA es una entidad dbil pues necesita a la entidad ALUMNO para existir. 4. Atributos o Campos: Son las unidades de informacin que describen propiedades de las entidades. Por ejemplo, la entidad ALUMNO posee los atributos: nmero de matrcula, nombre, direccin, poblacin, cdigo postal, provincia, y telfono. Los atributos toman valores, por ejemplo, el atributo provincia podra ser SEVILLA, CDIZ, etc. Se representan mediante una elipse con el nombre en el interior.

5. Dominio: Es el conjunto de valores permitidos para cada atributo. Por ejemplo, el dominio del atributo nombre puede ser el conjunto de cadenas de texto de una longitud determinada. 6. Identificador o Superclave: Es el conjunto de atributos que identifican de forma nica a cada entidad. Por ejemplo, la entidad EMPLEADO, con los atributos: nmero de la seguridad social, dni, nombre, direccin, fecha de
14

7. nacimiento y telfono, podra tener como identificador slo el dni (pues no habr 2 empleados con el mismo dni), o slo el nmero de la seguridad social, o el conjunto de 3 atributos nombre, fecha de nacimiento y telfono (pues es difcil que hay 2 empleados en la misma empresa que tengan los mismos valores en esos 3 atributos). 8. Clave Candidata: Es cada una de las Superclave formadas por el mnimo nmero de campos posibles. En el ejemplo anterior habra 2 claves candidatas de un nico atributo: dni o nmero de la seguridad social. 9. Clave Primaria o Clave Principal (Primary Key): Es la clave candidata seleccionada por el diseador de la BD para identificar a cada entidad. Una clave primaria no puede tener valores nulos (vacos), ha de ser sencilla de crear y no ha de variar con el tiempo. El atributo o conjunto de atributos que forman parte de la clave primaria se representan subrayados. 10. Clave Ajena o Clave Fornea (Foreign Key): Es el atributo o conjunto de atributos de una entidad que constituyen la clave primaria de otra entidad. Las claves forneas representan las relaciones entre entidades. Por ejemplo, la entidad ARTCULO con los atributos: cdigo de artculo, descripcin de artculo, precio de venta y stock en almacn, y la entidad VENTA con los atributos: cdigo de venta, fecha de venta, cdigo de artculo y unidades vendidas; pues el atributo cdigo de artculo es clave fornea en la entidad VENTA, pues la relaciona con la entidad ARTCULO, debido a que ese atributo es clave primaria de la entidad ARTCULO. 11. Relacin: Es una asociacin entre diferentes entidades. Se representan mediante un rombo con su nombre, un verbo, en su interior. 12. Conjunto de Relaciones: Es un grupo de relaciones del mismo tipo. Por ejemplo, entre los conjuntos de entidades ARTCULOS y VENTAS puede

haber varias relaciones distintas, pues todas ellas pueden formar un conjunto de relaciones, que vinculan el conjunto de entidades ARTCULOS con el de VENTAS. Una relacin puede tener atributos descriptivos, por ejemplo, supongamos que la entidad CLIENTE est relacionada con la entidad CUENTA a travs de una relacin
15

OPERA; se necesitara el atributo FECHA_OPERACIN en el conjunto de relaciones CLIENTE_CUENTA, que especificara la ltima fecha en la que el cliente tuvo acceso a su cuenta bancaria.

Diagramas de estructuras de datos en el modelo E-R: Los diagramas E-R representan la estructura lgica de una BD de manera grfica. Los smbolos utilizados son: 1. 2. 3. 4. Rectngulos para representar entidades. Elipses para los atributos. Rombos para las relaciones Cada atributo se unir a la entidad o a la relacin a la que pertenezca con lneas simples. 5. Las lneas podrn tener forma de flecha en una relacin. Donde est la punta de la flecha estar el MUCHOS (N), y donde no hay punta de flecha

en la lnea estar el UNO (1). La orientacin de la flecha seala la cardinalidad de la relacin.

6. Cada componente grfico se etiqueta con el nombre que lo representa.

16

Grado y cardinalidad de las relaciones: El grado de una relacin es el nmero de conjuntos de entidades que participan en el conjunto de relaciones, es decir, el nmero de entidades que participan en una relacin. Lo normal es que las relaciones sean binarias (relaciones de grado 2), es decir, que en las relaciones participen 2 entidades. No obstante, puede haber relaciones ternarias (de grado 3) o incluso de otro grado, aunque son poco comunes. Las relaciones en las que slo participa una entidad se llaman anillo o de grado 1 o relaciones reflexivas.

Un ejemplo de relacin de anillo sera el siguiente: la entidad EMPLEADO puede tener una relacin SER JEFE DE consigo misma, pues un empleado es jefe de muchos empleados y, a la vez, el jefe es un empleado. Otro ejemplo sera la relacin SER DELEGADO DE los alumnos de un curso, pues el delegado es tambin alumno del curso.

17

18