INSTITTUTO POLITCNICO NACIONAL ESCUELA SUPERIOR DE CMPUTO

1.1

CONCEPTOS

La Ingeniera de Software implica seguir en cualquier proyecto de software una metodologa de desarrollo y la utilizacin de distintas tcnicas y herramientas. Los diferentes procedimientos a seguir en cualquier proyecto de Ingeniera de software son: Definicin de requerimientos, Anlisis, Diseo, Verificacin y Validacin (Pruebas de Calidad del Software), Pruebas y Mantenimiento. El presente documento intenta dar a conocer y describir los conceptos y aspectos fundamentales del diseo orientado a objetos (DOO) dentro del desarrollo de un producto software, as como las tcnicas, metodologas y herramientas actuales de dicho paradigma en la Ingeniera de software. As pues, definimos Diseo de Software como la accin de construir soluciones que satisfagan los requerimientos del cliente. Existen varias etapas en el proceso de diseo de software, a saber son: Entendimiento del problema Identificar una o ms soluciones Describir abstracciones de la solucin Repetir el proceso para cada abstraccin identificada hasta que el diseo este expresado en trminos sencillos Pues bien, dentro del paradigma de la orientacin a objetos, el diseo OO es con mucho; ms complejo que el diseo estructurado clsico, ya que lo que se busca es crear un diseo genrico y abierto y no cerrado y concreto. El Diseo Orientado a Objetos se define como un diseo de sistemas que utiliza objetos auto-contenidos y clases de objetos. CLASES. Hay dos grandes categoras de objetos: clases e instancias. Los usuarios de la POO piensan en las clases como contenedores de la informacin necesaria para crear instancias, estos son, la estructura y las capacidades de una instancia estn determinadas por su correspondiente clase. Hay tres definiciones vlidas de clase:

1.

Una clase es un patrn, una plantilla para una categora de objetos con la misma estructura. Los tems creados con la clase se llaman instancias. Es como si la clase fuera un molde y la instancia un pastel. Una clase consiste en un patrn y en el mecanismo de crear tem basado en ese patrn. A esta clase se le puede ver como a una fbrica de instancias. Las instancias son tem manufacturado usando el mecanismo de creacin de tem de la clase. Una clase es un conjunto de tems creados usando un patrn especfico. Dicho de otra manera, la clase es el conjunto de todas las instancias de ese patrn.

2.

3.

SUPERCLASES. Una superclase es una clase cuyas instancias tambin son clases. Esto significa que cuando se use el mecanismo de creacin de instancias en una metaclase, la instancia creada ser una clase. Un concepto muy similar al de metaclase es el de clase parametrizada. Una clase parametrizada es una plantilla para una clase, es decir, una clase se crea rellenando la plantilla con los datos especficos de esa clase Nosotros usaremos el trmino de clase y haremos la distincin solo cuando sea necesario. Una definicin que tambin usaremos es la de instanciacin que tiene dos significados: Como verbo, instanciacin es el proceso de creacin de la instancia de una clase, y Como nombre, una instanciacin es una instancia de una clase. OBJETO Las personas tienen una idea clara de lo que es un objeto: conceptos adquiridos que nos permiten sentir y razonar acerca de las cosas del mundo. Un objeto podra ser real o abstracto, por ejemplo una organizacin, una factura, una figura en un dibujador, una pantalla de usuario, un avin, un vuelo de avin, etc. En el anlisis y diseo orientados a objetos (OO), interesa el comportamiento del objeto. Si se construye software, los mdulos de software OO se basan en los tipos de objetos. El software que implanta el objeto contiene estructuras de datos y operaciones que expresan dicho comportamiento. Las operaciones se codifican como mtodos. La representacin en software OO del objeto es entonces una coleccin de tipos de datos y objetos. Entonces, dentro del software orientado a objeto, un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos.

Un objeto puede estar compuesto por otros objetos. Estos ltimos a su vez tambin pueden estar compuestos por otros objetos. Esta intrincada estructura es la que permite construir objetos muy complejos. TIPO DE OBJETO Los conceptos que poseemos se aplican a tipos determinados de objetos. Por ejemplo, empleado se aplica a los objetos que son personas empleadas por alguna organizacin. Algunas instancias de empleado podran ser Juan Prez, Jos Martnez, etc. En el anlisis orientado a objetos, estos conceptos se llaman tipos de objetos; las instancias se llaman objetos. As, un tipo de objeto es una categora de objeto, mientras que un objeto es una instancia de un tipo de objeto. En el mundo de las bases de datos existen los tipos de entidad, como cliente o empleado. Existen muchas instancias de cada tipo de entidad (como Juan Prez o Jos Martnez para el tipo de entidad empleado). Del mismo modo, en OO se define tipos de objetos e instancias de tipo de objeto. Sin embargo, el trmino objeto tiene diferencias fundamentales con el trmino entidad, ya que la entidad slo se refiere a los datos, mientras que objeto se refiere a los datos y a los mtodos mediante los cuales se controlan a los propios datos. En OO, la estructura de datos y los mtodos de cada tipo de objeto se manejan juntos. No se puede tener acceso o control de la estructura de datos excepto mediante los mtodos que forman parte del tipo de objeto. MTODOS Los mtodos especifican la forma en que se controlan los datos de un objeto. Los mtodos en un tipo de objeto slo hacen referencia a la estructura de datos de ese tipo de objeto. No deben tener acceso directo a las estructuras de datos de otros objetos. Para utilizar la estructura de datos de otro objeto, deben enviar un mensaje a ste. El tipo de objeto empaca juntos los tipos de datos y su comportamiento. Un objeto entonces es una cosa cuyas propiedades estn representadas por tipos de datos y su comportamiento por mtodos. Un mtodo asociado con el tipo de objeto factura podra ser aquel que calcule el total de la factura. Otro podra transmitir la factura a un cliente. Otro podra verificar de manera peridica si la factura ha sido pagada y, en caso contrario, aadir cierta tasa de inters. ENCAPSULADO El empaque conjunto de datos y mtodos se llama encapsulado. El objeto esconde sus datos de los dems objetos y permite el acceso a los datos mediante sus propios mtodos. Esto recibe el nombre de ocultamiento de informacin. El encapsulamiento evita la corrupcin de los datos de un objeto. Si todos los programas pudieran tener acceso a los datos de cualquier forma que quisieran los usuarios, los datos se podran corromper o

utilizar de mala manera. El encapsulado protege los datos del uso arbitrario y no pretendido. El encapsulado oculta los detalles de su implantacin interna a los usuarios de un objeto. Los usuarios se dan cuenta de las operaciones que puede solicitar del objeto, pero desconocen los detalles de cmo se lleva a cabo la operacin. Todos los detalles especficos de los datos del objeto y la codificacin de sus operaciones estn fuera del alcance del usuario. As, encapsulado es el resultado (o acto) de ocultar los detalles de implantacin de un objeto respecto de su usuario. El encapsulado, al separar el comportamiento del objeto de su implantacin, permite la modificacin de sta sin que se tengan que modificar las aplicaciones que lo utilizan.

MENSAJES Para que un objeto haga algo, le enviamos una solicitud. Esta hace que se produzca una operacin. La operacin ejecuta el mtodo apropiado y, de manera opcional, produce una respuesta. El mensaje que constituye la solicitud contiene el nombre del objeto, el nombre de una operacin y, a veces, un grupo de parmetros. La programacin orientada a objetos es una forma de diseo modular en la que con frecuencia el mundo se piensa en trminos de objetos, operaciones, mtodos y mensajes que se transfieren entre tales objetos. Un mensaje es una solicitud para que se lleve a cabo la operacin indicada y se produzca el resultado. Los objetos pueden ser muy complejos, puesto que pueden contener muchos subobjetos, stos a su vez pueden contener otros, etc. La persona que utilice el objeto no tiene que conocer su complejidad interna, sino la forma de comunicarse con l y la forma en que responde. CLASE El trmino clase se refiere a la implantacin en software de un tipo de objeto. El tipo de objeto es una nocin de concepto. Especifica una familia de objetos sin estipular la forma en que se implanten. Los tipos de objetos se especifican durante el anlisis OO. As, una clase es una implantacin de un tipo de objeto. Especifica una estructura de datos y los mtodos operativos permisibles que se aplican a cada uno de sus objetos. HERENCIA Un tipo de objeto de alto nivel puede especializarse en tipos de objeto de bajo nivel. Un tipo de objeto puede tener subtipos. Por ejemplo, el tipo de objeto persona puede tener subtipos estudiante y empleado. A su vez, el tipo de objeto estudiante puede tener como

subtipo estudiante de pregrado y estudiante de postgrado, mientras que empleado puede tener como subtipo a acadmico y administrativo. Existe de este modo una jerarqua de tipos, subtipos, subsubtipos, etc. Una clase implanta el tipo de objeto. Una subclase hereda propiedades de su clase padre; una sub-subclase hereda propiedades de las subclases; etc. Una subclase puede heredar la estructura de datos y los mtodos, o algunos de los mtodos, de su superclase. Tambin tiene sus mtodos e incluso tipos de datos propios.
ATRIBUTO

Propiedad del objeto Determinan el estado del objeto Son los datos que contiene y encapsula una clase(ocultas al exterior) y se acceden por medio de algn mtodo Es un valor de un dato que est almacenado en los objetos de una clase Los atributos son llamados variables de instancia Podran verse como una variable global a toda la clase.
MTODO

Una operacin que se podr realizar sobre un objeto Definen el comportamiento de la clase Servicios que ofrece la clase Permiten cambiar el estado del objeto, esto es, operan sobre los atributos. Los atributos son visibles en toda la clase En cualquier mtodo se puede hacer referencia a las variables de instancia Los mtodos pueden tener variables locales Son visibles slo dentro del mtodo.

POLIMORFISMO

Es la propiedad que tienen los objetos de permitir invocar genricamente un comportamiento (mtodo) cuya implementacin ser delegada al objeto correspondiente recin en tiempo de ejecucin. El polimorfismo tiende a existir en las relaciones de herencia, pero no siempre es as.

1.2 Caractersticas del paradigma Orientado a Objetos

La programacin orientada a objetos o POO (OOP segn sus siglas en ingls) es un paradigma de programacin que usa objetos y sus interacciones, para disear aplicaciones y programas informticos. Est basado en varias tcnicas, incluyendo herencia, abstraccin, polimorfismo y encapsulamiento. Su uso se populariz a principios de la dcada de los aos 1990. En la actualidad, existe variedad de lenguajes de programacin que soportan la orientacin a objetos.

La programacin orientada a objetos, intenta simular el mundo real a travs del significado de objetos que contiene caractersticas y funciones. Los lenguajes orientados a objetos se clasifican como lenguajes de quinta generacin.

Como su mismo nombre indica, la programacin orientada a objetos se basa en la idea de un objeto, que es una combinacin de variables locales y procedimientos llamados mtodos que juntos conforman una entidad de programacin. Entre los lenguajes orientados a objetos se destacan los siguientes:

ABAP -> SAP Lenguaje orientado a eventos ABL Lenguaje de programacin de OpenEdge de Progress Software ActionScript ActionScript 3 Ada C++ C# Clarion Clipper (lenguaje de programacin) (Versin 5.x con librera de objetos Class(y)) D Object Pascal (Embarcadero Delphi) Gambas Genie Harbour Eiffel Fortran 90/95 Java JavaScript (la herencia se realiza por medio de la programacin basada en prototipos) Lexico (en castellano) Objective-C Ocaml Oz R Perl (soporta herencia mltiple. La resolucin se realiza en preorden, pero puede modificarse al algoritmo linearization C3 por medio del mdulo Class::C3 en CPAN) PHP (a partir de su versin 5) PowerBuilder Python Ruby Smalltalk (Entorno de objetos puro) Magik (SmallWorld) Vala VB.NET Visual FoxPro (en su versin 6) Visual Basic 6.0

Visual DataFlex Visual Objects XBase++ Lenguaje DRP Lenguaje de programacin Scala (lenguaje usado por Twitter) http://www.scalalang.org/page.jsp

Muchos de estos lenguajes de programacin no son puramente orientados a objetos, sino que son hbridos que combinan la POO con otros paradigmas. Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados aadiendo extensiones orientadas a objetos a un lenguaje de programacin clsico. Un nuevo paso en la abstraccin de paradigmas de programacin es la Programacin Orientada a Aspectos (POA). Aunque es todava una metodologa en estado de maduracin, cada vez atrae a ms investigadores e incluso proyectos comerciales en todo el mundo. Existe un acuerdo acerca de qu caractersticas contempla la "orientacin a objetos", las caractersticas siguientes son las ms importantes:

Abstraccin: denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin. El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar. Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente. Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica

cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. Herencia: las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple. Recoleccin de basura: la recoleccin de basura o garbage collector es la tcnica por la cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C++ u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente.

1.3 METODOLOGAS ORIENTADA A OBJETOS

Metodologa Orientada a Objetos (OMT). Rumbaugh

El anlisis y diseo orientado a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que son tiles para comunicarse con expertos en esa aplicacin, modelar empresas, preparar documentacin, disear programas y bases de datos. Un modelo es una abstraccin de algo, cuyo objetivo es comprenderlo antes de construirlo. Dado que los modelos omiten los detalles no esenciales, es ms sencillo manipularlos que manipular la entidad original. La abstraccin es una capacidad humana

fundamental que nos permite enfrentarnos a la complejidad. Los ingenieros, artistas y artesanos han estado construyendo modelos durante miles de aos para probar los diseos antes de ejecutarlos. El desarrollo de sistemas hardware y software no es una excepcin. Para construir sistemas complejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfacen los requisitos del sistema y aadir, gradualmente, detalles para trasformar los modelos en una implementacin. (Rumbaugh, 1996) La esencia del anlisis y diseo orientado a objetos es la identificacin y organizacin de conceptos del dominio de la aplicacin, y no de su presentacin final en un lenguaje de programacin, es decir, es un proceso conceptual independiente de s el lenguaje es orientado a objetos. Cabe resaltar que los sistemas construidos hoy en da son ms complejo que los sistemas construidos en los aos 70s y 80s. La complejidad funcional es menos preocupante de como lo era antes, lo que ahora ha tomado una prioridad alta es el modelar la comprensin del dominio del problema y las responsabilidades del sistema, por lo que metodologas como la OMT (Object Modeling Technique) se han convertido en una herramientas necesaria y de mucha importancia para el desarrollo de software. La metodologa OMT fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General Electric. Cabe resaltar que Rumbaugh se uni a Rational Software en 1994, y trabaj all con Ivar Jacobson y Grady Booch ("los Tres Amigos") para desarrollar UML. Ms tarde fusionaron sus metodologas de desarrollo de software, OMT, OOSE y Booch en el Proceso Unificado Racional (RUP), una de las metodologas ms utilizadas en la actualidad. En su momento, OMT fue una de las metodologas de anlisis y diseo orientada a objetos, ms maduras y eficientes. La gran virtud aportada por esta metodologa fue su carcter de abierta (no propietaria), que le permiti ser de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Lo que facilit su evolucin para acoplarse a las necesidades futuras de la ingeniera de software. Tiene una fase de diseo no muy compleja y se centra mucho en un buen anlisis.

Divide el ciclo de vida del software en cuatro fases consecutivas: 1. Anlisis de objetos: se centra en entender y modelar el problema en el dominio de la aplicacin. 2. Diseo del sistema: se determina la arquitectura del sistema en trmino de subsistemas. 3. Diseo de objetos: se refina y optimiza el anlisis de objetos para implementarlo. 4. Implementacin: se codifica y prueba lo ya diseado.
OMT (OBJECT MODELING TECHNIQUE) La tcnica de modelado de objetos (OMT) es un lenguaje de modelado de objetos para software de modelado y diseo. Se desarroll alrededor de 1991 por Rumbaugh, Blaha,

Premerlani, Eddy y Lorensen como un mtodo para desarrollar sistemas orientados a objetos y apoyar orientada a objetos Modelo de objetos programming.Describes o estructura esttica del sistema. OMT se desarroll como un enfoque para el desarrollo de software. Los propsitos de modelado de acuerdo con Rumbaugh son: probando entidades fsicas antes de su construccin (simulacin), comunicacin con los clientes, visualizacin (presentacin alternativa de la informacin), y reduccin de la complejidad.

OMT ha propuesto tres tipos principales de modelos: Modelo del objeto: El modelo de objetos representa los fenmenos estticos y estables en el dominio de modelado principales conceptos son clases y asociaciones con atributos y operaciones. Agregacin y generalizacin (con herencia mltiple) son relaciones predefinidas. Modelo dinmico: El modelo dinmico representa una vista de estado / transicin del modelo. Principales conceptos son estados, transiciones entre estados y eventos para desencadenar transiciones. Las acciones pueden ser modelados como algo que ocurre dentro de los estados. La generalizacin y agregacin (de acuerdo-neda) son relaciones predefinidas. Modelo funcional: El modelo funcional se encarga de la perspectiva de proceso del modelo, que corresponde aproximadamente a los diagramas de flujo de datos. Principales conceptos son procesar, almacenar datos, flujo de datos, y los actores. OMT es un predecesor del Lenguaje de Modelado Unificado (UML). Muchos elementos de modelado OMT son comunes a UML. UNIFIED PROCESS (UP) El Proceso Unificado no es simplemente un proceso, sino ms bien un marco extensible que debe ser personalizado para las organizaciones o proyectos especficos. El Proceso Unificado Racional es, asimismo, un marco personalizable. Como resultado a menudo es imposible decir si un refinamiento del proceso se deriva de UP o de RUP, y as los nombres tienden a ser utilizados de forma intercambiable. El Proceso de nombre unificado en oposicin a Rational Unified Process se utiliza generalmente para describir el proceso genrico, incluyendo aquellos elementos que son comunes a la mayora de los criterios de bsqueda. El nombre de Unified Process se utiliza tambin para evitar posibles problemas de infraccin de marca desde Rational Unified Process y RUP son marcas comerciales de IBM. El primer libro para describir el proceso fue titulado El Proceso Unificado de Desarrollo de Software (ISBN 0-201-571692), y publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh. Desde entonces, varios autores no afiliados a Rational Software ha publicado libros y artculos

10

que utilizan el Proceso Unificado de nombre, mientras que los autores afiliados a Rational Software han favorecido el nombre de Proceso unificado racional. Caractersticas Unified Process El Proceso Unificado es un proceso iterativo e incremental de desarrollo. Las fases de elaboracin, construccin y transicin se dividen en una serie de iteraciones timeboxed. (La fase inicial tambin se puede dividir en iteraciones para un proyecto grande.) Cada uno de los resultados de iteracin en un incremento, que es una versin del sistema que contiene funcionalidad ni mejorado en comparacin con la versin anterior. Aunque la mayora de iteraciones incluir el trabajo en la mayora de las disciplinas de procesos (por ejemplo, requisitos, diseo, implementacin, pruebas) el esfuerzo relativo y el nfasis va a cambiar con el transcurso del proyecto Caso de uso Driven En el Proceso Unificado, casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. Cada iteracin toma un conjunto de casos de uso o escenarios de los requisitos de todo el camino hasta la implementacin, prueba y despliegue. Ciclo de vida del proyecto El Proceso Unificado divide el proyecto en cuatro fases: comienzo elaboracin construccin transicin RATIONAL UNIFIED PROCESS (RUP) Segn Jacaboson, I., Booch, G., Rumbaugh J. (1998)1 El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El Proceso Unificado de Rational (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye informacin entrelazada de diversos artefactos y descripciones de las diversas

11

actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo con las necesidades Ciclo de vida El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara.

Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios

12

Modelado visual del software Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso). Fases

Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso

LA CALIDAD DE LOS SISTEMAS SOFTWARE

La calidad del software. La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad. Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que tambin pueden implicar una falta de calidad. La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin.

13

A partir del siguiente grfico se observa la interrelacin existente entre la Gestin de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.

La gestin de la calidad
Gestin de la calidad: "Aspectos de la funcin de gestin que determinan y aplican la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la calidad". Dentro de la gestin de la calidad se observa:

Gestin de la calidad de software (ISO 9000): Conjunto de actividades de la funcin general de la direccin que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificacin de la calidad, el control de la calidad, el aseguramiento (garanta) de la calidad y la mejora de la calidad, en el marco del sistema de calidad Poltica de calidad (ISO 9000): Directrices y objetivos generales de una organizacin, relativos a la calidad, tal como se expresan formalmente por la alta direccin.

La gestin de la calidad se aplica normalmente a nivel de empresa. Tambin puede haber una gestin de calidad dentro de la gestin de cada proyecto.

El aseguramiento de la calidad

14

Ante todo se debe conocer:

Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad". Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollarla. Hay quienes prefieren decir garanta de calidad en vez de aseguramiento. La garanta, puede confundir con garanta de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del software est presente en:

Mtodos y herramientas de anlisis, diseo, programacin y prueba. Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del software. Estrategias de prueba multiescala. Control de la documentacin del software y de los cambios realizados. Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera de ellos). Mecanismos de medida (mtricas). Registro de auditoras y realizacin de informes.

Las actividades para el aseguramiento de calidad del software se detallan en:

Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisin e inspeccin). La gestin de la configuracin del software.

Algunos mtodos del aseguramiento:

Revisiones tcnicas y de gestin (su objetivo es la evaluacin). Inspeccin (su objetivo es la verificacin). Estamos construyendo el producto correcto?. Pruebas (su objetivo es la validacin). Estamos construyendo el producto correctamente?. Auditorias (su objetivo es la confirmacin del cumplimiento).

El control de la calidad
Se debe conocer:

15

Control de calidad: "Conjunto de tcnicas y actividades de carcter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio". Control de la calidad del software: Tcnicas y actividades de carcter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de la calidad del software est centrado en dos objetivos fundamentales:

Mantener bajo control un proceso. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

En general, se puede decir que el control de de la calidad del software son las actividades para evaluar la calidad de los productos desarrollados. Las estrategias de trabajo se representan como sigue:

16

Sistema de calidad
Sistema de calidad: Estructura organizativa, procedimientos, procesos y recursos necesarios para implantar la gestin de calidad. El sistema de calidad se debe adecuar a los objetivos de la calidad de la empresa. La direccin de la empresa es la responsable de fijar la poltica de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad. Un sistema de calidad consta de varias partes:

Documentacin Manual de calidad. Es el documento principal para establecer e implantar un sistema de calidad. Puede haber manuales a nivel de empresa, departamento, producto, especficos (compras, proyectos,). Parte fsica: locales, herramientas ordenadores, etc. Aspectos humanos:
o o o

Formacin de personal. Creacin y coordinacin de equipos de trabajo.

Normativas: ISO 9000: Gestin y aseguramiento de calidad (conceptos y directrices generales).Recomendaciones externas para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003). Recomendaciones internas para aseguramiento de la calidad (ISO 9004).

MALCOM BALDRIGE NATIONAL QUALITY AWARD. Software Engineering Institute (SEI) Capability Maturity Model (CMM) for software.

Qu es un sistema de gestin de la calidad?

Sistema de gestin de la calidad: "Estructura de la organizacin, responsabilidades, procedimientos, procesos y recursos que se establecen para llevar a trmino la gestin de calidad". Un sistema de gestin de la calidad es la forma en la que una empresa o institucin dirige y controla todas las actividades que estn asociadas a la calidad. Las partes que componen el sistema de gestin son:

Estructura organizativa: departamento de calidad o responsable de la direccin de la empresa. Cmo se planifica la calidad. Los procesos de la organizacin.

17

Recursos que la organizacin aplica a la calidad. Documentacin que se utiliza.

Que una empresa tenga implantado un sistema de gestin de la calidad, slo quiere decir que esa empresa gestiona la calidad de sus productos y servicios de una forma ordenada, planificada y controlada. Las normas de producto son diferentes a las normas de sistemas de gestin de la calidad. Una norma de producto puede ser el marcado CE, la marca N de producto homologado por AENOR, la marca GS de TV Product, y nos indican las caractersticas mnimas que el producto cumple en materia de seguridad. Normas de sistemas de gestin las hay de calidad (ISO 9001), de medioambiente (ISO 14001), del sector de automocin (ISO/TS 16949) y de seguridad (OSHAS). Las ventajas de implantar un sistema de gestin de la calidad son las siguientes:

Aumento de beneficios. Aumento del nmero de clientes. Motivacin del personal. Fidelidad de los clientes. Organizacin del trabajo. Mejora de las relaciones con los clientes. Reduccin de costes debidos a la mala calidad. Aumento de la cuota de mercado.

Para entender bien la relacin de estos aspectos, es preferible observar la siguiente grfica:

18

Atributos de calidad y entidades de diseo En primer lugar debemos acotar el contexto en el que nos movemos, ya que la calidad, en el software, se puede entender como calidad de proceso o de producto. La calidad de proceso ha sido objeto de mucho inters en las ltimas dcadas (Humphrey,1989) y su desarrollo ha concienciado a los profesionales de la necesidad de aplicar la calidad a otros aspectos del software. En nuestro caso estamos claramente centrados en la calidad del producto software y, dentro de ella, en el producto derivado de la fase de diseo ( Software design, part 2 , 2004). Fenton y Pfleeger (1998) explican que es un paso previo al establecimiento de las mtricas el definir qu atributos o propiedades de qu elementos son los que queremos medir. Posteriormente podremos establecer si para medir dichos atributos es necesario medir otros y derivar los que nos interesan de ellos o bien se puede hacer directamente. En nuestro caso la nica norma que hemos encontrado en la literatura que da una definicin de calidad de producto software en base a atributos es ISO 9126 (ISO/IEC, 2001). Dicha norma establece que la medicin de la calidad de un producto software debe hacerse en base a sus atributos, siendo stos internos, propiedades caractersticas de cmo se estructura el software, o externos, cualidades observables an sin conocer cmo est construido. De hecho no se habla de calidad, en general, sino de calidad interna y calidad externa, afirmndose que la calidad interna de un producto software influye directamente en su calidad externa. De algn modo se est diciendo que mejorando la calidad interna se mejora directamente la calidad observada en atributos de uso del producto software. Tanto la calidad interna como la externa se definen, en ISO 9126, como un conjunto de 6caractersticas: Funcionalidad: La capacidad del software de proveer las funciones que cumplen con las necesidades implcitas y explcitas cuando el mismo es utilizado bajo ciertas condiciones. Fiabilidad: La capacidad del software de mantener un nivel especfico de rendimiento bajo determinadas condiciones de uso. Usabilidad: La capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando se usa bajo ciertas condiciones. Eficiencia: La capacidad del software de ofrecer el rendimiento apropiado con respecto a la cantidad de recursos utilizados, bajo condiciones prefijadas. Mantenibilidad: La capacidad del producto de ser modificado. Dichas modificaciones pueden incluir correcciones, mejoras o adaptaciones a cambios en el entorno y en los requisitos y especificaciones funcionales. Portabilidad: La capacidad del software de ser trasladado de un entorno (informtico) a otro. Estas caractersticas son generales para cualquier tipo de programa informtico o software independientemente de si el paradigma empleado para construirlo es el Orientado a Objetos, el estructurado u otro cualquiera, sin embargo s que afectar a la manera de medirlas. Dichas caractersticas se dividen a su vez en subcaractersticas tal como se puede ver en el siguiente esquema.

19

20

2.2 MTRICAS Una Mtrica de un proyecto es la medida de alguna propiedad de un entregable del proyecto o del proceso de administracin de proyectos, efectuada para conocer el avance o los desvos al plan original. Si se definen mtricas acerca de un entregable especfico, estas mtricas son particulares al proyecto. Las mtricas relacionadas al proceso de administracin de proyectos pueden usarse en todo tipo de proyectos. Las mtricas pueden ser usadas para medir el estado, efectividad o progreso de las actividades de un proyecto y as contribuir a tomar decisiones estratgicas ante los desvos, incidentes o diferentes problemas que surgen en la ejecucin. Para qu sirven las Mtricas?

Identifican eventos y tendencias importantes en los proyectos y otorgan a la organizacin la informacin necesaria para la toma de decisiones. Sirven como vocabulario comn entre el grupo de personas que participa de la implementacin de los proyectos, y el grupo que los patrocina (Sponsors, Stakeholders). Sirven como motivacin para el equipo, porque relacionan en esfuerzo personal de los miembros con los resultados generales del proyecto.

Hay distintos tipos de MOO, como por ejemplo: Mtricas orientadas a clases Mtricas orientadas a operaciones Mtricas para pruebas orientadas a objetos Mtricas para proyectos orientados a objetos

Algunos mtodos de este tipo de mtricas son: Mtodos ponderados por clase (C&K) rbol de profundidad de herencia (C&K) Nmero de Descendientes (C&K) Tamao de Clase (Lorenz y Kidd) ndice de Especializacin (Lorenz y Kidd)

Mtricas CK Chidamber y Kemerer Son mtricas orientadas a clases: clases individuales, herencia y colaboraciones. Es uno de los conjuntos de mtricas ms referenciado. a) Mtodos ponderados por clase (WMC: Weighted Methods per Class). Calcula la suma de la complejidad ciclo matica de los mtodos de una clase: WMC=i..n mci , siendo mci la complejidad ciclo matica del mtodo i.

21

El WMC debe ser lo ms bajo posible. Cuanto ms alto es el valor WMC, ms complejo el rbol de herencia y menos reutilizable. Las principales interpretaciones de esta mtrica son las siguientes: El nmero y la complejidad de los mtodos son indicadores del tiempo necesario para desarrollar/mantener la clase. Cuanto mayor sea el n de mtodos mayor impacto potencial tendr en los hijos, sus herederos potenciales. Las clases con gran n de mtodos sern de aplicacin especfica, y por lo tanto ms difciles de reutilizar. b) Profundidad en el rbol de herencia (DIT: Depth Inheritance Tree). Es la distancia desde una clase a la raz del rbol de herencia. Cuanto ms alto es el mayor valor de DIT, mayor complejidad hay en el diseo y cuanto ms alto sea el valor de DIT de una clase ms posibilidades existen de que reutilice/refine mtodos heredados. Las principales interpretaciones de esta mtrica son las siguientes: A mayor profundidad de la clase, ms mtodos puede heredar y es ms difcil de explicar su comportamiento. A mayor profundidad de una clase, mayor posibilidad de reutilizacin de mtodos heredados. c) Nmero de hijos inmediatos en el rbol de herencia (NOC: Number Of Children). En principio, cuanto ms alto es el valor de NOC, una clase es ms reutilizable pero tambin la probabilidad de que se hayan hecho extensiones no apropiadas de la clase es mayor. Las principales interpretaciones de esta mtrica son las siguientes: Cuanto mayor sea NOC ms reutilizacin habr por herencia. Si NOC es muy grande hay un fallo en la abstraccin de la clase padre, falta algn nivel intermedio. NOC da una idea del peso que la clase tiene en el diseo, y de los recursos que se deben dedicar a probar sus mtodos. d) Acoplamiento entre clases (CBO: Coupling Between Object Classes). Es el nmero de clases acopladas a una clase. Dos clases estn acopladas cuando los mtodos de una de ellas usan variables o mtodos de una instancia de la otra clase. Si existen varias dependencias sobre una misma clase es computada como una sola. No es deseable que CBO > 14. Cuanto ms alto es el ms dificil ser el mantenimiento y el reuso y en general el cdigo ser ms propenso a fallos. Las interpretaciones de esta mtrica son las siguientes: Cuanto mayor es CBO, peor es la modularidad y la reutilizacin. Cuanto mayor es CBO, peor es el encapsulamiento y ms cuesta mantenerlo. e) Respuesta para una clase (RPC: Response for a Class). Es el nmero de mtodos que pueden ser ejecutados en respuesta a un mensaje recibido por un objeto de esa clase.

22

Cuanto mayor sea RPC, mayor esfuerzo se requiere para su comprobacin, y ms complejo es el diseo. Existen dos variaciones de esta mtrica: I. RPC: Slo considera el primer nivel del rbol de llamadas: nmero de mtodos de una clase ms el nmero de mtodos remotos llamados directamente por una clase.

Las principales interpretaciones de esta mtrica son las siguientes a. Cuanto mayor sea la respuesta de una clase, ms complicadas sern las pruebas y el mantenimiento. b. Cuanto mayor sea la respuesta de una clase, mayor ser la complejidad de la clase. f) Carencia de cohesin (LCOM: Lack of Cohesion). Cada mtodo de una clase tiene acceso a uno o ms atributos. LCOM calcula el conjunto de atributos comunes en los mtodos de una clase. Dos mtodos son similares si comparten al menos un atributo de la clase. A mayor nmero de atributos similares, mayor cohesin hay en la clase. Ejemplos: III. Si ningn mtodo accede a sus atributos, LCOM=0. IV. Una clase tiene 6 mtodos y 4 de ellos tienen un atributo en comn, LCOM=4 Es interesante conseguir valores bajos de LCOM. Las principales de esta mtrica son las siguientes: a. A mayor cohesin mayor encapsulamiento. b. Un valor grande puede indicar que la clase debe dividirse. c. Baja cohesin indica alta complejidad y alta probabilidad de error en el desarrollo.

Mtricas de Li-Henry a) APM Acoplamiento por paso de mensajes: nmero de mensajes o mtodos invocados enviados por una clase a otras clases del sistema. b) AAD Acoplamiento por abstraccin de datos: (se considera una definicin ambigua con dos posibles interpretaciones): I. Nmero de tipos de datos abstractos definidos en una clase. II. Nmero de atributos de una clase que se referencian desde otra clase. c) NML Nmero de mtodos localmente definidos en la clase. d) Tamao: nmero de atributos y mtodos locales de una clase.

23

Mtricas de Bansiya y Davis

2.3 Modelo 4+1 Un gran problema que sucede cuando se intenta adoptar una arquitectura para modelar un sistema. Pero sucede que los diagramas que se utilizan para esto intentan agrupa diferentes estilos de arquitectura en un solo modelo. Al mismo tiempo puede ocurrir que se pone demasiado nfasis en alguno de los aspectos de ingeniera de software. El modelo de 4+1 vistas fue desarrollado para remediar estos problemas. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. La arquitectura del software se trata de abstracciones, de descomposicin y composicin, de estilos y esttica. Tambin tiene relacin con el diseo y la implementacin de la estructura de alto nivel del software. Los diseadores construyen la arquitectura usando varios elementos arquitectnicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, as como tambin otros requisitos no funcionales tales como conabilidad, escalabilidad, portabilidad y disponibilidad del sistema.

24

La Arquitectura Lgica La arquitectura lgica apoya principalmente los requisitos funcionales lo que el sistema debe brindar en trminos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas (Principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aqu se aplican los principios de abstraccin, encapsulamiento y herencia. Esta descomposicin no slo se hace para potenciar el anlisis funcional, sino tambin sirve para idnticar mecanismos y elementos de diseo comunes a diversas partes del sistema. Usamos el enfoque de Booch/Rational para representar la arquitectura lgica, mediante diagramas de clases y templetes de clases. Un diagrama de clases muestra un conjunto de clases y sus relaciones lgicas: asociaciones, uso, composicin, herencia y similares. Grupos de clases relacionadas pueden agruparse en categoras de clases. Los templetes de clases se centran en cada clase individual; enfatizan las operaciones principales de la clase, e idntican las principales caractersticas del objeto. Si es necesario denir el comportamiento interno de un objeto, esto ser realiza con un diagrama de transicin de estados o diagrama de estados. Los mecanismos y servicios comunes se denen como utilidades de la clase. Notacin. La notacin para la lgica se deriva de la notacin de Booch. Esta se simplica considerablemente de tal modo de tener en cuenta solamente los tems relevantes para la arquitectura. En particular, los numerosos adornos disponibles son bastante intiles a este nivel de diseo. Usamos Rational Rose para apoyar el diseo lgico de la arquitectura.

25

La Vista de Procesos La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribucin, integridad del sistema, de tolerancia a fallas. La vista de procesos tambin especica en cul hilo de control se ejecuta efectivamente una operacin de una clase identicada en la vista lgica. La arquitectura de procesos se describe en varios niveles de abstraccin, donde cada nivel se reere a distintos intereses. El nivel ms alto la arquitectura de procesos puede verse como un conjunto de redes lgicas de programas comunicantes (llamados procesos) ejecutndose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. Mltiples redes lgicas pueden usarse para apoyar la separacin de la operacin del sistema en lnea del sistema fuera de lnea, as como tambin para apoyar la coexistencia de versiones de software de simulacin o de prueba. Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tcticamente (i.e., comenzar, recuperar, recongurar, y detener). Adems, los procesos pueden replicarse para aumentar la distribucin de la carga de procesamiento, o para mejorar la disponibilidad. Notacin. La notacin que usamos para la vista de procesos se expande de la notacin originalmente propia por Booch para las tareas de Ada y se centra solamente en los elementos arquitectnicamente relevantes (Figura 3).

Vista de Desarrollo La vista de desarrollo se centra en la organizacin real de los mdulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeas bibliotecas de programas o sub sistemas que pueden ser desarrollados por uno o un grupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua de capas, cada una de las cuales brinda una interfaz estrecha y bien denida hacia las capas superiores.

26

La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, administracin del software, reutilizacin y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programacin que se use. La vista de desarrollo apoya la asignacin de requisitos y trabajo al equipo de desarrollo, y apoya la evaluacin de costos, la planicacin, el monitoreo de progreso del proyecto, y tambin como base para analizar reus, portabilidad y seguridad. Es la base para establecer una lnea de productos. La vista de desarrollo de un sistema se representa en diagramas de mdulos o subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa slo puede describirse completamente cuando todos los elementos del software han sido identicados. Sin embargo, es posible listar las reglas que rigen la arquitectura de desarrollo particin, agrupamiento, visibilidad antes de conocer todos los elementos. Notacin. Tal como se muestra en la Figura 5, usamos una variante de la notacin de Booch limitndonos a aquellos items relevantes para la arquitectura.

Arquitectura Fsica Mapeando el software al hardware La arquitectura fsica toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, con abilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identicados redes, procesos, tareas y objetos requieren ser mapeados sobre los variados nodos. Esperamos que diferentes conguraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente exible y tener un impacto mnimo sobre el cdigo fuente en s. Notacin. Los diagramas fsicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto toman diversas formas, con o sin l mapeo de la vista de procesos.

27

Escenarios Todas las partes juntas. Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjunto pequeo de escenarios relevantes instancias de casos de uso ms generales para los cuales describimos sus Scripts correspondientes (secuencias de interacciones entre objetos y entre procesos) tal como lo describen Rubn y Goldberg. Los escenarios son de alguna manera una abstraccin de los requisitos ms importantes. Su diseo se expresa mediante el uso de diagramas de escenarios y diagramas de interaccin de objetos. Notacin. La notacin es muy similar a la vista lgica para los componentes (ver Figura 2), pero usa los conectores de la vista de procesos para la interaccin entre objetos (ver Figura 3). Ntese que las instancias de objetos se denotan con lneas slidas. Para el diagrama lgico, capturamos y administramos los diagramas de escenarios de objetos usando Rational Rose. 2.4 UML y el Modelado El Lenguaje Unicado de Modelado preescribe un conjunto de notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos signican. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Diagramas de Casos de Uso para modelar los procesos business. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboracin para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura esttica de las clases en el sistema. Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema. Diagramas de Componentes para modelar componentes.

28

 Diagramas de Implementacin para modelar la distribucin del sistema. UML es una consolidacin de muchas de las notaciones y conceptos ms usados orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares IMPORTANCIA DE MODELAR

Para modelar los programas de forma grfica, viendo las relaciones entre las clases y cmo colaboran unos objetos con otros, se prefiere utilizar una notacin estndar. De esta manera, el alumno va conociendo parte de la notacin, UML en este caso, lo cual le ser til por varias razones: Le permite ir familiarizndose con un lenguaje de modelado estndar que ver en otras asignaturas de la titulacin. Le permite entender modelos con esta notacin
Principios bsicos del modelado Existen cuatro principios bsicos, estos principios son fruto de la experiencia en todas las ramas de la ingeniera. a) La eleccin de qu modelos se creen influye directamente sobre cmo se acomete el problema. Hay que seleccionar el modelo adecuado para cada momento y dependiendo de que modelo se elija se obtendrn diferentes beneficios y diferentes costes. En la industria software ese ha comprobado que un modelado orientado a objetos proporciona unas arquitecturas ms flexibles y readaptables que otros por ejemplo orientados a la funcionalidad o a los datos. b) Todo modelo puede ser expresado a diferentes niveles de precisin. Esto es, es necesario poder seleccionar el nivel de detalle que se desea ya que en diferentes partes de un proyecto y en diferentes etapas se tendrn unas determinadas necesidades. c) Los mejores modelos estn ligados a la realidad. Lo principal es tener modelos que nos permitan representar la realidad lo ms claramente posible, pero no slo esto, tenemos que saber, exactamente cuando se apartan de la realidad para no caer en la ocultacin de ningn detalle importante. d) Un nico modelo no es suficiente. Cualquier sistema que no sea trivial se afronta mejor desde pequeos modelos casi independientes, que los podamos construir y estudiar independientemente y que nos representen las partes ms diferenciadas del sistema y sus interrelaciones.

Qu es UML? El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un lenguaje estndar, basado en una notacin grfica, que se utiliza para modelar software. Es un lenguaje de propsito general que pretende ser un estndar mundial y se utiliza para visualizar, especificar, construir y documentar las diferentes piezas de un sistema.

29

3.1 HERRAMIENTAS CASE Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigacin Preliminar, Anlisis, Diseo, Implementacin e Instalacin. CASE se define tambin como: Conjunto de mtodos, utilidades y tcnicas que facilitan la automatizacin del ciclo de vida del desarrollo de sistemas de informacin, completamente o en alguna de sus fases. La sigla genrica para una serie de programas y una filosofa de desarrollo de software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas. Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa con un potencial efecto profundo en la organizacin. Se puede ver al CASE como la unin de las herramientas automticas de software y las metodologas de desarrollo de software formales. Estas herramientas pueden proveer muchos beneficios en todas las etapas del proceso de desarrollo de software, algunas de ellas son: Verificar el uso de todos los elementos en el sistema diseado. Automatizar el dibujo de diagramas. Ayudar en la documentacin del sistema. Ayudar en la creacin de relaciones en la Base de Datos. Generar estructuras de cdigo. La principal ventaja de la utilizacin de una herramienta CASE, es la mejora de la calidad de los desarrollos realizados y, en segundo trmino, el aumento de la productividad. Para conseguir estos dos objetivos es conveniente contar con una organizacin y una metodologa de trabajo, adems de la propia herramienta. Algunos de los diagramas y modelos utilizados con mayor frecuencia son: Diagrama de casos de uso Diagrama de clase Diagrama de secuencia Diagrama de colaboracin. Diagrama de estados Diagrama de actividad. Diagrama de componentes Diagrama de despliegue. Diagrama de composicin estructural

La Vista de Casos de Uso Los modelos de objetos son apropiados para representar la estructura de los objetos, sus asociaciones, y como interactan dinmicamente. Sin embargo no son modelos apropiados para capturar y comunicar requerimientos funcionales de la aplicacin, ni para verificar si el modelo de objetos se corresponde con la realidad. El primer modelo del sistema que se debe construir debe ser comprensible tanto para los usuarios como para los desarrolladores. Los modelos de objetos son muy complejos para

30

este propsito. Un sistema real, aunque pequeo, puede consistir de alrededor de 100 objetos. Sistemas ms grandes pueden implicar varios cientos o miles de objetos. Por lo tanto, el primer modelo del sistema no debe ser un modelo de objetos. Debe ser un modelo que describa el sistema, su entorno, y como se relaciona con el mismo .En otras palabras debe describir el sistema tal como se lo ve desde el exterior, con una vista de caja negra. Los casos de uso son una forma de especificar esta vista de caja negra. Un caso de uso es una forma de usar el sistema. El usuario interacta con el sistema interactuando con sus casos de uso. La vista de casos de uso captura el comportamiento del sistema, de un subsistema, o de una clase, tal como se muestra a un usuario desde el exterior .Particiona la funcionalidad del sistema en transacciones significativas para los actores-usuarios del sistema. Un caso de uso describe una interaccin como secuencia de mensajes entre el sistema y uno o ms actores. Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Existen algunas diferencias entre los casos de uso y los eventos. Las principales son: 1) Los eventos se centran en describir qu hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cmo es el dilogo entre el usuario y el sistema. 2) Los eventos son atmicos: se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interaccin del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos. 3) Para los eventos, lo importante es qu datos ingresan al sistema o salen de l cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la informacin que se intercambia es secundaria. Segn esta tcnica, ya habr tiempo ms adelante en el desarrollo del sistema para ocuparse de este tema. Los casos de uso combinan el concepto de evento del anlisis estructurado con otra tcnica de especificacin de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta tcnica, si bien gan pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aqul que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es ms fcil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que stos comprendern fcilmente la forma en la que estn expresados. Los casos de uso son una tcnica para especificar el comportamiento de un sistema: Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Todo sistema de software ofrece a su entorno aquellos que lo usan una serie de servicios. Un caso de uso es una forma de expresar cmo alguien o algo externo a un sistema lo usa. Cuando decimos alguien o algo hacemos referencia a que los sistemas son usados no slo por personas, sino tambin por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que est ejecutando el caso de uso ingresando pedido.

31

Descripcin de los Casos de Uso Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. A continuacin se muestra una parte simplificada de la descripcin del caso de uso Ingresando Pedido. Caso de Uso: Ingresando Pedido. Actor: Empleado de Ventas. 1) El cliente se comunica con la oficina de ventas, e informa su nmero de cliente 2) El oficial de ventas ingresa el nmero de cliente en el sistema 3) El sistema obtiene la informacin bsica sobre el cliente 4) El cliente informa el producto que quiere comprar, indicando la cantidad 5) El sistema obtiene la informacin sobre el producto solicitado, y confirma su disponibilidad. 6) Se repite el paso 4) hasta que el cliente no informa ms productos Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir un sistema en el cual la interaccin con el usuario es muy simple: ingresa un conjunto bsico de datos, y con esos datos el sistema realiza una gran cantidad de clculos, aplicando complejas frmulas. Cmo hago con un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de texto informal. Por lo tanto, deberemos usar una nueva notacin para especificar este comportamiento interno, algo equivalente a los diagramas de flujo de datos del anlisis estructurado. En UML se propone usar una notacin llamada Diagrama de Actividad, el moderno heredero del diagrama de flujo, o flowchart. Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la descripcin del caso, las decisiones e iteraciones. De esta forma, es comn que en las descripciones de los casos se deba recurrir a frases como Se repite el paso X hasta que ocurre C, o Si ocurre C se pasa al paso X. En estas situaciones lo importante no es la forma en la que se expresan las condiciones e itraciones, sino hacerlo de una forma consistente. Si la descripcin del caso fuera muy compleja, es conveniente usar notaciones grficas, por ejemplo los diagramas de actividad.

MODELADO DEL PROCESO DE NEGOCIOS Business Process Modelling (BPM) _ BPM tambin (Business Process Management) [Ko 2009][Ko 2009b] _ Representar los procesos de negocio de una empresa u organizacin con objeto de que puedan ser analizados y mejorados: Validacin: Se realizan todas la tareas, ciclos Simulacin: Ahorro de costes antes de la implementacin

32

Principales responsables: Analistas, Arquitectos/ diseadores, desarrolladores del sistema de informacin Elementos de un Modelo de Proceso de Negocio Tpicamente: _ Objetivo(s) o motivo del proceso _ Entradas _ Salidas _ Recursos utilizados _ Secuencia de Actividades _ Eventos que dirigen el proceso _ Roles/participantes involucrados

ELEMENTOS DEL DIAGRAMA DE ACTIVIDADES Representa el comportamiento interno de una operacin o de un caso de uso, bajo la forma de un desarrollo por etapas, agrupadas secuencialmente. El propsito del diagrama de actividad es: Modelar el flujo de tareas Modelar las operaciones

Muestra los aspectos dinmicos de un sistema Puede describir procesos o casos de uso. Permite elegir el orden en que pueden hacrselas cosas. Establece las reglas de secuencia a seguir.

33

34

4.1 VISTA LGICA

Muestra el diseo de la funcionalidad del sistema en sus dos aspectos esenciales: su estructura, es decir, los componentes que lo integran, y su comportamiento, expresado en trminos de la dinmica de interaccin de dichos componentes. Es utilizada fundamentalmente por los equipos de diseo y desarrollo, y consta de los siguientes diagramas. Para la descripcin de estructura: Diagramas de Clases y de Objetos Para la descripcin del comportamiento: Diagramas de Estado, Secuencia, Colaboracin y Actividad.

4.2 Elementos del Diagrama de Clases

Los diagramas de clases se utilizan para modelar la visin esttica de un sistema. Esta visin soporta los requisitos funcionales del sistema, en concreto, los servicios que el sistema debera proporcionar a sus usuarios finales. Normalmente contienen: clases, interfaces y relaciones entre ellas: de asociacin, de dependencia y/o de generalizacin.

Asociaciones

RELACIONES

35

36

37

4.3 Tarjetas CRC

CRC (Class-Responsibility-Collaboration) es una tcnica de diseo orientado a objetos propuesta por Kent Beck (introductor de la metodologa de programacin extrema) y Ward Cunningham (tambin muy conocido entre otras muchas materias, por sus aportaciones a dicha metodologa). El objetivo de la misma es hacer, mediante tarjetas, un inventario de las clases que vamos a necesitar para implementar el sistema y la forma en que van a interactuar, de esta forma se pretende facilitar el anlisis y discusin de las mismas por parte de varios actores del equipo de proyecto con el objeto de que el diseo sea lo ms simple posible verificando las especificaciones del sistema. Un esquema tpico de tarjeta CRC puede ser aquel en el que se indiquen los siguientes datos: - Nombre de la clase. - Nombre de las superclases y subclases (si procede). - Las responsabilidades de la clase. - Las clases con las que va a colaborar para poder realizar las responsabilidades indicadas. - Autor, fecha, etc En lugar de utilizar diagramas para desarrollar modelos, como lo hacan la mayora de los metodlogos, Cunningham y Beck representaron las clases en tarjetas 4 x 6 [pulgadas]. Y en lugar de indicar atributos y mtodos en las tarjetas, escribieron responsabilidades. Ahora bien, qu es una responsabilidad? En realidad es una descripcin de alto nivel del propsito de una clase. La idea es tratar de eliminar la descripcin de pedazos de datos y procesos y, en cambio, captar el propsito de la clase en unas cuantas frases. El que se haya seleccionado una tarjeta es deliberado. No se permite escribir ms de lo que cabe en una tarjeta

38

La segunda C se refiere a los colaboradores. Con cada responsabilidad se indica cules son las otras clases con las que se tiene que trabajar para cumplida. Esto da cierta idea sobre los vnculos entre las clases, siempre a alto nivel. Uno de los principales beneficios de las tarjetas de CRC es que alientan la disertacin animada entre los desarrolladores. Son especialmente eficaces cuando se est en medio de un caso de uso para ver cmo lo van a implementar las clases. Los desarrolladores escogen tarjetas a medida que cada clase colabora en el caso de uso. Conforme se van formando ideas sobre las responsabilidades, se pueden escribir en las tarjetas. Es importante pensar en las responsabilidades, ya que evita pensar en las clases como simples depositarias de datos, y ayuda a que el equipo se centre en comprender el comportamiento de alto nivel de cada clase. Un error comn que veo que comete la gente es generar largas listas de responsabilidades de bajo nivel. Este procedimiento es completamente fallido. Las responsabilidades deben caber sin dificultad en una tarjeta. Yo cuestionara cualquier tarjeta que tenga ms de tres responsabilidades. Plantese la pregunta de si se deber dividir la clase y si las responsabilidades se podran indicar mejor integrndolas en enunciados de un mayor nivel.

4.3.2 MODELADO DE CLASES, RESPONSABILIDADES Y COLABORACIONES

Una vez que se han desarrollado los escenarios de uso bsicos para el sistema, es el momento de identificar las clases candidatas e indicar sus responsabilidades y colaboraciones. El modelado de clases-responsabilidades colaboraciones (CRC) aporta un medio sencillo de identificar y organizar las clases que resulten relevantes al sistema o requisitos del producto. Se describe el modelado CRC de la siguiente manera: Un modelo CRC es realmente una coleccin de tarjetas ndice estndar que representan clases. Las tarjetas estn divididas en tres secciones. A lo largo de la cabecera de la tarjeta usted escribe el nombre de la clase. En el cuerpo se listan las responsabilidades de la clase a la izquierda y a la derecha los colaboradores. En realidad, el modelo CRC puede hacer uso de tarjetas ndice virtual o real. El caso es desarrollar una representacin organizada de las clases. Las responsabilidades son los atributos y operaciones relevantes para la clase. Puesto de forma simple, una responsabilidad es cualquier cosa que conoce o hace la clase. Los colaboradores son aquellas clases necesarias para proveer a una clase con la informacin necesaria para completar una responsabilidad. En general, una colaboracin implica una solicitud de informacin o una solicitud de alguna accin.

39

4.4 Elementos de Diagrama de Objetos

Los diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. Un diagrama de Objeto se puede considerar un caso especial de un diagrama de clase. Los diagramas de objetos usan un sub conjunto de elementos de un diagrama de clase para enfatizar la relacin entre las instancias de las clases en algn punto en el tiempo. Estos son tiles para entender los diagramas de clases. Estos no muestran nada diferente en su arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles.

4.5 Elementos de Diagrama de Secuencia

El diagrama de secuencia de uml muestran la forma en que los objetos se comunican entre si al transcurrir el tiempo. Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interaccin de objetos, se utilizan con frecuencia para validar los casos de uso. El diagrama muestra:

Los objetos participando de la interaccin La secuencia de mensajes intercambiados Un diagrama de secuencia contiene: Objetos con su lnea de vida Mensajes intercambiados entre objetos de una secuencia ordenada Lnea de vida activa

40

OBJETOS

Los diagramas de secuencia constan de objetos que se representan de modo usual: rectngulo con nombre, mensajes entre los objetos representados por lneas continas con una punta de flecha y el tiempo representado como una progresin vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama. La extensin que est debajo (en forma descendente) de cada objeto ser una lnea discontinua conocida como la lnea de vida de un objeto, junto con la lnea de vida de un (objeto rectngulo) se le conoce como activacin, el cual una operacin que realiza el objeto la interpreta como la duracin de la activacin.

LINEA DE VIDA

Una lnea de vida representa un participante individual en un diagrama de secuencia. Una lnea de vida usualmente tiene un rectngulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la lnea de vida representa el clasificador que posee el diagrama de secuencia.

MENSAJE

Un mensaje que va de un objeto a otro pasa de la lnea de vida de un objeto al de otro. Un objeto puede enviarse un objeto a si mismo es decir de su lnea de vida as propia lnea de vida.

Un mensaje puede ser simple, sncrono y asncrono

Mensaje simple: es la transferencia del control de un objeto a otro. Mensaje sncrono: es cuando el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo. Mensaje asncrono: es cuando el objeto no espera la respuesta a ese mensaje antes de continuar.

41

TIEMPO El diagrama representa el tiempo en direccin vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que est ms cerca de la parte superior ocurrir antes que uno que est cerca de la parte inferior. Con ellos el diagrama de secuencia tiene 2 dimensiones: la dimensin horizontal (es la disposicin de los objetos) y la dimensin vertical (muestra el paso del tiempo). La siguiente figura muestra el conjunto bsico de smbolos del diagrama de secuencia, junto con los smbolos de su funcionamiento.

RECURCIVIDAD En ocasiones un objeto posee una operacin que se invoca a si misma. A esto se le conoce como recursividad y es una caracterstica fundamental de varios lenguajes de programacin. La siguiente figura muestra este tipo de representacin.

OBJETIVO Descubrir las interfaces requeridas para cada objeto y validar que cada interface se usa realmente. El diagrama de Secuencias modela interacciones entre objetos. Ya que estas interacciones pueden ser muy complejas, se modelan un pequeo juego de interacciones como un solo escenario.

EJEMPLO Juego del ajedrez

42

4.6 Elementos de Diagrama de Estados

Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

5.1 Diseo de la Interfaz grfica del usuario

La interfaz grfica de usuario, conocida tambin como GUI (del ingls graphical user interface) es un programa informtico que acta de interfaz de usuario, utilizando un conjunto de imgenes y objetos grficos para representar la informacin y acciones disponibles en la interfaz. Su principal uso, consiste en proporcionar un entorno visual sencillo para permitir la comunicacin con el sistema operativo de una mquina o computador. Habitualmente las acciones se realizan mediante manipulacin directa, para facilitar la interaccin del usuario con la computadora. Surge como evolucin de las interfaces de

43

lnea de comandos que se usaban para operar los primeros sistemas operativos y es pieza fundamental en un entorno grfico. Como ejemplos de interfaz grfica de usuario, cabe citar los entornos de escritorio Windows, el X-Window de GNU/Linux o el de Mac OS X, Aqua. En el contexto del proceso de interaccin persona-ordenador, la interfaz grfica de usuario es el artefacto tecnolgico de un sistema interactivo que posibilita, a travs del uso y la representacin del lenguaje visual, una interaccin amigable con un sistema informtico.

5.2 Diseo del modelado de datos

Est basado en una coleccin de objetos. Un objeto contiene valores almacenados en variables ejemplares dentro de este objeto. Contiene fragmentos de cdigo que operan dentro del mismo y a stos se les llama mtodos. La nica manera en que pueden acceder a la base de datos es a travs del paso de mensajes a otro objeto. Los objetos que contienen los mismos tipos de valores y los mismos mtodos se agrupan en clases.

Los objetos acceden a los datos de otros objetos mediante el envo de mensajes.

44

JERARQUERIZADA Almacena su informacin en una forma ordenada (del grande al chico o inverso). DE RED Su diferencia fundamental es al modificacin del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerrquico). RELACIONAL En este modelo, el lugar y la forma en que se almacenan los datos no tienen relevancia MULTIDIMENSIONALES Son bases para desarrollar aplicaciones muy concretas, como creacin de cubos OLAP. ORIENTADAS A OBJETOS Este modelo es bastante reciente, y propio de los modelos informativos orientados a objetos, trata de almacenar en la base los objetos completos. DOCUMENTALES Permite la indexacin a textos completos, y lneas generales realizar bsquedas mas potentes. DEDUCTIVAS Permite hacer deducciones a travs de inferencias se basa en reglas y hechos que son almacenados.

45

5.2.1 Mapeo Objeto-Relacin

El mapeo objeto-relacional (ms conocido por su nombre en ingls, Object-Relational mapping, o sus siglas O/RM, ORM, y O/R mapping) es una tcnica de programacin para convertir datos entre el sistema de tipos utilizado en un lenguaje de programacin orientado a objetos y el utilizado en una base de datos relacional, utilizando un motor de persistencia. En la prctica esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto posibilita el uso de las caractersticas propias de la orientacin a objetos (bsicamente herencia y polimorfismo). Hay paquetes comerciales y de uso libre disponibles que desarrollan el mapeo relacional de objetos, aunque algunos programadores prefieren crear sus propias herramientas ORM. En la programacin orientada a objetos, las tareas de gestin de datos son implementadas generalmente por la manipulacin de objetos, los cuales son casi siempre valores no escalares. Para ilustrarlo, considere el ejemplo de una entrada en una libreta de direcciones, que representa a una sola persona con cero o ms nmeros telefnicos y cero o ms direcciones. En una implementacin orientada a objetos, esto puede ser modelado por un "objeto persona" con "campos" que almacenan los datos de dicha entrada: el nombre de la persona, una lista de nmeros telefnicos y una lista de direcciones. La lista de nmeros telefnicos estara compuesta por "objetos de nmeros telefnicos" y as sucesivamente. La entrada de la libreta de direcciones es tratada como un valor nico por el lenguaje de programacin (puede ser referenciada por una sola variable, por ejemplo). Se pueden asociar varios mtodos al objeto, como uno que devuelva el nmero telefnico preferido, la direccin de su casa, etc. Lenguajes de programacin orientada a objetos Los lenguajes de programacin orientados a objetos tratan a los programas como conjuntos de objetos que se ayudan entre ellos para realizar acciones. Entendiendo como objeto a las entidades que contienen datos. Permitiendo que los programas sean ms fciles de escribir, mantener y reutilizar.

Los objetos tienen toda la informacin (atributos) que los diferencia de otros pertenecientes a otra clase. Por medio de unos mtodos se comunican los objetos de una misma o diferente clase produciendo el cambio de estado de los objetos. Esto hace que a los objetos se les trate como unidades indivisibles en las que no se separan la informacin ni los mtodos usados en su tratamiento. Este lenguaje tiene su origen en un lenguaje que fue diseado por los profesores OleJohan Dahl y Kristen Nygaard en Noruega. Este lenguaje de programacin orientado a objetos fue el Simula 67 que fue un lenguaje creado para hacer simulaciones de naves. Son lenguajes dinmicos en los que estos objetos se pueden crear y modificar sobre la marcha. Esta programacin orientada a objetos (POO) tomo auge a mediados de los aos ochenta debido a la propagacin de las interfaces grficas de usuarios, para lo que los

46

lenguajes de programacin orientados a objetos estn especialmente dotados. Entre los principales lenguajes de este tipo tenemos: Ada, C++, C#, VB.NET, Clarion, Delphi, Eiffel, Java, Lexico (en castellano), Objective-C, Ocaml, Oz, PHP, PowerBuilder, Python, Ruby y Smalltalk. No todos estos lenguajes son especficamente orientados a objetos. Sino que algunos de ellos se le han aadido extensiones orientadas a objetos. Un nuevo paso en los lenguajes de programacin es la Programacin orientada a aspectos (POA). Actualmente esta en fase de desarrollo, pero cada vez atrae a ms investigadores y empresas de todo el mundo. En la programacin orientada a objetos la modularidad se considera de la siguiente manera: Un programa grande siempre ser ms complicado que la suma de varios programas pequeos, con lo que se considera ventajoso dividir un gran sistema en diversos mdulos. En la programacin orientada a objetos tenemos la jerarqua, la cual consiste en la clasificacin y organizacin de las abstracciones segn su naturaleza. El ms claro ejemplo de jerarqua es la herencia. En la programacin orientada a objetos se define la herencia como una jerarqua de extracciones, y la relacin entre clases, donde se comparte la estructura y el comportamiento de una o ms clase considerada como clases superiores o una superclase, con lo cual se resume que la herencia es una unidad independiente por si misma heredada de una abstraccin o superclase. Un ejemplo cotidiano lo encontramos en las aplicaciones que existen actualmente en el mercado, donde un formulario cualquiera hereda las caractersticas de una ventana del sistema operativo Windows (Maximizar, Minimizar, Cerrar)

47

Vista Fsica Diagrama de Componentes a nivel de Hardware Este diagrama modela los componentes de hardware que se utilizan en un sistema, en este diagrama cada cuadro representa un servidor o un cliente, tambin se deben modelar los usuarios y a travs de que computadoras hacen uso del sistema. Es importante destacar que las lneas de comunicacin son la forma en que se comunican los equipos haciendo uso de las diferentes tecnologas de redes (fibra ptica, cableada, inalmbrica) y de los diferentes protocolos de comunicacin a nivel capa transporte y sesin.

El diseo fsico traduce el diseo lgico en una solucin implementable y costoefectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:

Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo).

48

El diseo fsico debe involucrar:

El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red. El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso) El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud. El diseo con el manejo de errores y prueba de eventos: o Validando los parmetros- a la entrada antes de continuar con cualquier proceso. o Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria. o Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos. o Debugging crear una versin para limpiar errores. o Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.

El diseo fsico comprende las siguientes tareas:

Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico

49

5.4 Diagrama de Distribucin

Algunos sistemas corren sobre una misma plataforma, mientras que otros estn distribuidos en una serie de mquinas. Existen diversas razones para construir soluciones distribuidas. UML utiliza el diagrama de distribucin para mostrar que el sistema corre a travs de diferentes plataformas. Los diagramas de distribucin consisten de nodos los cuales representan algn dispositivo de hardware como servidores, estaciones de trabajo, PCs, sensores, telfonos, entre otros y muestran la configuracin de los nodos, procesos, componentes y objetos que residen en ellos en tiempo de ejecucin. Las conexiones entre los nodos corresponden a las conexiones de red entre ellos, presentadas como estereotipos

Los Diagramas de Distribucin muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que generalmente tiene algo de memoria y, a menudo, capacidad de procesamiento. Los nodos se utilizan para modelar la topologa del hardware sobre el que se ejecuta el sistema. Representa tpicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes.

5.4.1 Vista de desarrollo

La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos software en el entorno de desarrollo. El software es empaquetado en pequeos trozos (libreras de programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas jerrquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo, gestin del software (reparto de requisitos, trabajo del equipo), evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin

50

Esta organizacin del software se suele apoyar en diagramas de mdulos o de subsistemas que muestran las relaciones de exportacin (export) e importacin (import). Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software.

Notacin: La notacin ms usada es UML, y dentro de esta diagramas de componentes y paquetes. Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de desarrollo. Una regla de diseo es que un subsistema puede solamente depender de subsistemas en la misma capa o en las menores. Esto minimiza las dependencias entre mdulos a favor de una ms simple estrategia capa capa.

5.4.2 Diagrama de componentes

Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos, etc. que conformarn un sistema. Un diagrama de Componentes tiene un nivel ms alto de abstraccin que un diagrama de clase usualmente un componente se implementa por una o ms clases (u objetos) en tiempo de ejecucin. Estos son bloques de construccin, como eventualmente un componente puede comprender una gran porcin de un sistema.

51

Un nodo representa un proceso o un dispositivo sobre los cuales se pueden desplegar los componentes. Similitudes: tienen nombre pueden anidarse Etc.

5.5 Diagramas de paquetes

Los diagramas de paquetes se usan para reflejar la organizacin de paquetes y sus elementos. Cuando se usan para representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualizacin de los espacios de nombres. Los usos ms comunes para los diagramas de paquete son para organizar diagramas de casos de uso y diagramas de clase, a pesar de que el uso de los diagramas de paquete no es limitado a estos elementos UML. Los Paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas lneas maestras sobre la mesa, los paquetes son buenos elementos de gestin. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

52

5.6 Pruebas del Sistema

53

Visin sistemtica de la prueba

Figura: Procesos de prueba del sistema

Otras pruebas del sistema

54

6.1 Patrones de diseo

Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno y describe tambin el ncleo de la solucin al problema, de forma que puede utilizarse un milln de veces sin tener que hacer dos veces lo mismo.(Alexander(arquitecto/urbanista)) Un patrn de diseo es: una solucin estndar para un problema comn de programacin una tcnica para flexibilizar el cdigo hacindolo satisfacer ciertos criterios un proyecto o estructura de implementacin que logra una finalidad determinada un lenguaje de programacin de alto nivel una manera ms prctica de describir ciertos aspectos de la organizacin de un programa conexiones entre componentes de programas la forma de un diagrama de objeto o de un modelo de objeto. Elementos de un patrn: Nombre: describe el problema de diseo. El problema: describe cundo aplicar el patrn. La solucin: describe los elementos que componen el diseo, sus relaciones, responsabilidades y colaboracin. Clasificacin de los patrones Segn su propsito: De creacin: conciernen al proceso de creacin de objetos. De estructura: tratan la composicin de clases y/o objetos. De comportamiento: caracterizan las formas en las que interactan y reparten responsabilidades las distintas clases u objetos.

55

6.2 Lenguaje de Restriccin de objetos (OCL)

OCL (Object Constraint Language, lenguaje de restricciones de objetos) es un nuevo lenguaje notacional un subconjunto del UML estndar industrial, que permite a los desarrolladores de software escribir restricciones sobre modelos de objetos (pre y postcondiciones, guardas, invariantes, valores derivados, restricciones sobre operaciones, etc.). Estas restricciones son particularmente tiles, en la medida en que permiten a los desarrolladores crear un amplio conjunto de reglas que rigen el aspecto de un objeto individual. OCL tiene las caractersticas de un lenguaje de expresiones, un lenguaje de modelos y un lenguaje formal: Lenguaje de expresiones OCL es un lenguaje de expresiones puro. Una expresin OCL garantiza que quedar sin efecto. Esto no puede cambiar nada en el modelo. Esto significa que un estado del sistema nunca cambiar debido a una expresin OCL, incluso una expresin OCL podra usarse para describir tal cambio de estado (p.e. en una postcondicin).Todos los valores de todos los objectos, incluidos los enlaces, no cambiarn. En cualquier momento en que se evala una expresin OCL, simplemente devuelve un valor.

56

Lenguaje de modelos OCL es un lenguaje de modelos y no un lenguaje de programacin. No se puede escribir un programa lgico o un flujo de control en OCL. Especialmente, no se puede invocar procesos o activar operaciones no de consulta en OCL. Debido a que OCL es en primer lugar un lenguaje de modelos, no se puede asegurar que todo sea directamente ejecutable. Como lenguaje de modelos, todos los aspectos de implementacin estn fuera de alcance y no pueden expresarse en OCL. Cada expresin OCL es conceptualmente atmica. El estado de los objetos en el sistema no pueden cambiar durante la evaluacin.

Lenguaje formal OCL es un lenguaje formal donde todos los constructores tienen un significado formal definido. La especificacin de OCL es parte de la especificacin de UML. OCL no tiene la intencin de reemplazar los lenguajes formales existentes.

Los lenguajes formales tradicionales se usaban por personas con conocimientos matemticos, pero dificulta su uso para la mitad de empresas y modeladores de sistemas. OCL ha sido desarrollado para llenar este hueco. Puesto que en un proyecto hay mucha gente involucrada (usuario, expertos, personas que despus se debern encargar de su mantenimiento, etc.) los modelos deben ser entendidos por una amplia y variada audiencia. OCL es fcil de aprender y usar por los desarrolladores sin amplios conocimientos matemticos. OCL tiene ciertas caractersticas que permiten a los desarrolladores adoptarlo a su ritmo y slo donde lo necesiten. Hace accesibles las especificaciones formales con un trasfondo matemtico limitado. Otro aspecto importante es que OCL no es un lenguaje completo en s mismo. Muchos lenguajes formales mandan (o al menos se supone) que la especificacin completa se escriba en el mismo lenguaje. Con OCL, no se necesita, incluso se tiene la posibilidad de escribir las especificaciones completas en OCL. La intencin de OCL es la de utilizarlo en combinacin con los modelos visuales UML. Muchos aspectos de modelaje pueden expresarse mucho mejor usando diagramas visuales y OCL no intenta reemplazarlos por sus propios mecanismos. Por el contrario, toma la informacin expresada en los modelos visuales y permite al desarrollador acceder a esta informacin en las expresiones OCL.

57

BIBILIOGRAFIA * http://es.wikipedia.org/wiki/Mapeo_objeto-relacional * http://www.articulandia.com/premium/article.php/25-09-2006Lenguajes-de-programacionorientada-a-objetos.htm * http://www.lenguajes-de-programacion.com/programacion-orientada-a-objetos.shtml * http://audiemangt.blogspot.mx/2010/05/diagramacion.html * http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html * http://es.scribd.com/doc/50359989/53/Diagrama-de-Distribucion * http://arevalomaria.wordpress.com/2010/12/02/uml-modelado-dinamico-diagramas-dedistribucion/ * https://sites.google.com/site/jgarzas/4mas1 * http://www.sparxsystems.com.ar/resources/tutorial/uml2_componentdiagram.html *http://www.sparxsystems.com.ar/resources/tutorial/uml2_packagediagram.html *http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Sistema.pdf *http://mit.ocw.universia.net/6.170/6.170/f01/pdf/lecture-12.pdf *http://siul02.si.ehu.es/~alfredo/iso/06Patrones.pdf *http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCAQF jAA&url=http%3A%2F%2Fusers.dsic.upv.es%2Fasignaturas%2Ffacultad%2Flsi%2Ftrabajos%2F1320 00.doc&ei=uMFCULGbNIHs2QXezYHQDA&usg=AFQjCNFcH4yXRYcgo8sgO-jfR_e5hrfTjA

BIBLIOGRAFIA *http://dpinto.cs.buap.mx/semadoo/mario.pdf *http://glbrtlmb.blogdiario.com/i2006-09/ *http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos#Caracter.C3.ADsticas_de _la_POO * http://sistemas2psm.aprenderapensar.net/files/2011/09/Metodolog%C3%ADa-Orientada-aObjetos-OMT.-Rumbaugh.pdf

58

* http://en.wikipedia.org/wiki/Object-modeling_technique * http://en.wikipedia.org/wiki/Unified_Process * http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational * http://www.monografias.com/trabajos59/calidad-software/calidad-software2.shtml *http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf * http://es.scribd.com/doc/490192/3/Principios-basicos-del-modelado *http://es.scribd.com/doc/49826815/Modelo-4-1-vista *http://www.escet.urjc.es/~smontalvo/umlToJava_v2.pdf * http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r42816.PDF * http://webdocs.cs.ualberta.ca/~pfiguero/soo/uml/ * G. Booch, I. Jacobson, J. Rumbaugh; El Lenguaje Unificado de Modelado. Manual de Referencia. Addison Wesley. * http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf * http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf * http://www.ugr.es/~mnoguera/collaborative_systems-business_processes_10-11.pdf * http://es.scribd.com/doc/2568098/UML-Diagramas-de-actividad

59