ANÁLISIS Y MODELADO DE SISTEMAS DE INFORMACIÓN

ANTOLOGÍA UNIDAD 1. El modelo del proceso del software 1.1. Conceptualización de tecnología orientada a objetos.

Conceptos de la Programación tradicional.

En la programación tradicional, también conocida como programación estructurada, un programa o aplicación consta de múltiples datos y funciones “globales”. El término “global” describe el hecho que todos los datos o funciones son “visibles” en todo el programa y, por lo tanto pueden ser llamados desde cualquier ubicación en la aplicación.

Esta forma de programación tiene sus orígenes en las primeras computadoras modernas basadas en la arquitectura Von Neuman de 1945 donde las instrucciones de un programa se guardaban en memoria creando el concepto de programa almacenado. Las instrucciones de un programa definidas dentro de funciones o procedimientos, eran ejecutadas por el procesador de manera secuencial afectando los datos del programa, los cuales eran almacenados en otras secciones de la memoria. Esta arquitectura es similar a la que actualmente se usa en la mayoría de las computadoras personales. Debido a esta separación de funciones y datos en la memoria, se ha desarrollado un gran número de lenguajes de programación que explotan este concepto. Sin embargo este tipo de programación tiene dos problemas principales:

a) Que el programador debe organizar su programa de acuerdo a la arquitectura de la computadora, o que piense como la máquina.

b) Los datos se vuelven globalmente visibles al estar separados de las funciones. Dado esto cualquier cambio en la estructura de los datos pudiera llegar a requerir la modificación de todas las funciones del programa en correspondencia con los cambios en los datos.

Conceptos de la Programación Orientada a Objetos

A diferencia de la programación tradicional, la orientada a objetos tiene una estructura de más alto nivel llamada objeto, que ofrece dos ventajas sobre la tradicional:

a) Permite al programador que organice su programa de acuerdo con abstracciones de más alto nivel, siendo éstas más cercanas a la manera de pensar de la gente. En otras palabras, los objetos son las unidades de

representación de las aplicaciones, por ejemplo, cuentas de bancos, reservaciones de vuelo, etc.

b) Los datos globales desaparecen, siendo éstos junto con las funciones parte interna de los objetos. Por lo tanto cualquier cambio en la estructura de alguno de los datos solo deberá afectar las funciones definidas en ese mismo objeto y no en los demás.

En general, un programa orientado a objetos, se define exclusivamente en términos de objetos y sus relaciones.

Fig. Programación orientada a objetos

Los datos y funciones se guardan dentro de los objetos, como se muestra en la figura.

Objeto

Fig. Programación orientada a objetos: objetos globales que contienen datos y funciones locales

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. Es que para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos.

La programación orientada a objetos es una de las formas más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos años. Esta acogida se debe a sus grandes capacidades y ventajas frente a las antiguas formas de programar.

objeto objeto

objeto

Funciones

Datos

Una Perspectiva Histórica

Tradicionalmente, la programación fue hecha en una manera secuencial o lineal, es decir una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.

Los lenguajes basados en esta forma de programación ofrecían ventajas al principio, pero el problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos al estilo “espaguetti” no ofrecen flexibilidad y el mantener una gran cantidad de líneas de código en sólo bloque se vuelve una tarea complicada.

Frente a esta dificultad aparecieron los lenguajes basados en la programación estructurada. La idea principal de esta forma de programación es separar las partes complejas del programa en módulos o segmentos que sean ejecutados conforme se requieran. De esta manera tenemos un diseño modular, compuesto por módulos independientes que puedan comunicarse entre sí. Poco a poco este estilo de programación fue reemplazando al estilo “espaguetti” impuesto por la programación lineal.

Entonces, vemos que la evolución que se fue dando en la programación se orientaba siempre a ir descomponiendo más el programa. Este tipo de descomposición conduce directamente a la programación orientada a objetos.

Pues la creciente tendencia de crear programas cada vez más grandes y complejos llevó a los desarrolladores a crear una nueva forma de programar que les permita crear sistemas de niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades ya no bastaba la programación estructurada ni mucho menos la programación lineal. Es así como aparece la programación

orientada a objetos (POO). La POO viene de la evolución de la programación estructurada; básicamente la POO simplifica la programación con la nueva filosofía y nuevos conceptos que tiene. La POO se basa en la dividir el programa en pequeñas unidades lógicas de código. A estas pequeñas unidades lógicas de código se les llama objetos. Los objetos son unidades independientes que se comunican entre ellos mediante mensajes.

Origen

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de Programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP

en su versión 5 se ha modificado, soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

¿Cuáles son las ventajas de un lenguaje orientado a objetos?

Fomenta la reutilización y extensión del código. Permite crear sistemas más complejos. Relacionar el sistema al mundo real. Facilita la creación de programas visuales. Construcción de prototipos Agiliza el desarrollo de software Facilita el trabajo en equipo Facilita el mantenimiento del software

Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

El modelo Orientado a Objetos

Conceptos básicos: Objetos, Clases, Herencia, Envío de mensajes (métodos)

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

Los objetos son entidades que tienen un determinado comportamiento (método) e identidad.

El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.

La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Conceptos fundamentales

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.

Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.

Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.

Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un

método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

Componentes de un objeto: atributos, identidad, relaciones y métodos. Identificación de un objeto: un objeto se representa por medio de una

tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Características de la POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las características siguientes son las más importantes:

Abstracción: denota las características 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 cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño 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 abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad de diversas formas.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos 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 abstracción. La aplicación 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 invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. 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 común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, 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 asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.

Repasando, la programación orientada a objetos es un paradigma que utiliza objetos como elementos fundamentales en la construcción de la solución. Surge en los años 70. Un objeto es una abstracción de algún hecho o ente del mundo real que tiene atributos que representan sus características o propiedades y métodos que representan su comportamiento o acciones que realizan. Todas las propiedades y métodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases.

Lenguajes orientados a objetos

Simula (1967) es aceptado como el primer lenguaje que posee las características principales de un lenguaje orientado a objetos. Fue creado para hacer programas de simulación, en donde los "objetos" son la representación de la información más importante. Smalltalk (1972 a 1980) es posiblemente el ejemplo canónico, y con el que gran parte de la teoría de la programación orientada a objetos se ha desarrollado.

Entre los lenguajes orientados a objetos se destacan los siguientes:

ABAP ABL Lenguaje de programación de OpenEdge de Progress Software ActionScript ActionScript 3 Ada C++ C# Clarion Clipper (lenguaje de programación) (Versión 5.x con librería de objetos

Class(y)) D Object Pascal (Embarcadero Delphi) Gambas Harbour Eiffel Java

JavaScript (la herencia se realiza por medio de la programación basada en prototipos)

Lexico (en castellano) Objective-C Ocaml Oz R Perl (soporta herencia múltiple. La resolución se realiza en preorden, pero

puede modificarse al algoritmo linearization C3 por medio del módulo Class::C3 en CPAN)

PHP (a partir de su versión 5) PowerBuilder Python Ruby Smalltalk (Entorno de objetos puro) Magik (SmallWorld) Vala VB.NET Visual FoxPro (en su versión 6) Visual Basic 6.0 Visual Objects XBase++ Lenguaje DRP Lenguaje de programación Scala (lenguaje usado por Twitter)

http://www.scala-lang.org/page.jsp

Muchos de estos lenguajes de programación no son puramente orientados a objetos, sino que son híbridos que combinan la POO con otros paradigmas.

Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados añadiendo extensiones orientadas a objetos a un lenguaje de programación clásico.

Un nuevo paso en la abstracción de paradigmas de programación es la Programación Orientada a Aspectos (POA). Aunque es todavía una metodología en estado de maduración, cada vez atrae a más investigadores e incluso proyectos comerciales en todo el mundo.

Estructura de un objeto

Un objeto puede considerarse como una especie de cápsula dividida en tres partes: relaciones, propiedades, métodos. Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

Encapsulamiento y ocultación

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuida la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información. Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. Deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas órdenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.

El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construido, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.

Organización de los objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.

Existen varios tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "árbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.

-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más alto de la estructura y suele recibir un nombre muy

genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.

-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.

-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

1. Relaciones. Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.

Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos). Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organización jerárquica compleja un hijo puede tener varios padres).

-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización. Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo. La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las

Matemáticas, la Física, la Química y la Geología. El tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.

Como ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es, evidentemente, semántica, pues no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos.

La existencia de esta relación nos permitirá responder a preguntas como: ¿Quién trabajó en óptica?, ¿En qué trabajó Newton?, ¿Quien trabajó en Física?

Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyándonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos que definir para todo el diccionario será mínima.

2. Propiedades. Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas "variables" de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de valores más o menos estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite. Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes:

-Propiedades propias. Están formadas dentro de la cápsula del objeto.

-Propiedades heredadas. Están definidas en un objeto diferente, antepasado de éste (padre, "abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase.

3. Métodos. Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.

Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.

Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:

-Métodos propios. Están incluidos dentro de la cápsula del objeto.

-Métodos heredados. Están definidos en un objeto diferente, antepasado de éste (padre, "abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.

Polimorfísmo

Una de las características fundamentales de la OOP es el polimorfísmo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)

Beneficios que se obtienen del desarrollo con OOP

Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfaces hombre-máquina "a-la-Windows" suele ser bastante conveniente.

Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.

Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en

consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta conceptual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea más intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.

Problemas derivados de la utilización de OOP en la actualidad

Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:

Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.

Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia múltiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importantes.

Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se esté desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.

Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la

memoria aumentan, la situación mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.

Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debería existir una metodología fácil de aprender e independiente del lenguaje, y fácil de reestructurar que no drene la performance del sistema.

Bibliografía consultada

Revista COMPU MAGAZINE, Número 51, Octubre '92

Revista COMPU MAGAZINE, Número 50, Septiembre '92

1.2. Metodologías emergentes de desarrollo de software. Proceso. Un proceso define quién hace qué, cuándo y cómo para alcanzar cierto objetivo. El éxito de las organizaciones radica en gran medida en la correcta definición y empleo de sus procesos. Los sistemas de software pueden llegar a ser muy complejos, para administrar dicha complejidad es necesario contar con modelos de procesos y tecnologías de software apropiadas. Modelo de proceso. Define cómo solucionar la problemática del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de su proceso, las cuales se conocen como el ciclo de vida de desarrollo de software. Un modelo de proceso debe considerar aspectos como el conjunto de personas, estructuras organizacionales, reglas, políticas, actividades, componentes de software, metodologías y herramientas.

No existe un solo modelo de proceso aplicable a cualquier proyecto, pues el modelo de proceso depende del tipo particular de proyecto:

Primer proyecto de su tipo. Se crea desde cero, requiere de más tiempo para especificarlo y analizarlo, la incertidumbre crea riesgos adicionales.

Segundo proyecto de su tipo. Se busca agregar nueva funcionalidad a un o conocido.

Variación de un proyecto. Se extiende un sistema ya existente, lo cual involucra introducir componentes de software reutilizables como un marco de trabajo (framework), crear nuevos componentes o simplemente extender la aplicación existente mediante nueva funcionalidad. Dependiendo de la estrategia a utilizar, el modelo del proceso debe variar.

Proyecto de reescritura de legado (legacy). Se busca transformar o hacer una reingeniería de un sistema ya existente, desarrollado bajo tecnologías anteriores y transformarlo a tecnologías nuevas.

Proyecto de creación de software reutilizable. Se busca crear uno o más componentes de software reutilizables, debe ser diseñado de tal manera que se asegure de que el diseño sea lo suficientemente general para ser útil en otras situaciones desconocidas, por ello no hay muchos proyectos así.

Proyecto de mejora de sistema o mantenimiento. Se busca modificar los componentes básicos de un sistema para apoyar a una nueva funcionalidad. Son regularmente pequeños y afectan solo a partes del sistema.

Componentes de un modelo de proceso

Arquitectura. Estructura general de un sistema y varía de acuerdo con el tipo de sistema a desarrollarse:

Transformación en lote (batch). Sistemas de transformación sobre un conjunto de entradas de valor constante, para generar un conjunto de salidas, ejemplo un compilador.

Transformación continua. Sistemas de transformación sobre un conjunto de entradas de valor constante, para generar un conjunto de salidas que difieren en el tiempo, ejemplo sistema de control de señales.

Sistemas interactivos. Regidos por interacciones externas, por lo general un usuario, son controlados por manejadores de eventos, encargados de procesar acontecimientos generados por el usuario, ejemplo un click o presionar una tecla.

Simulación dinámica. Sistemas que simulan sistemas del mundo real y evolucionan con el tiempo, ejemplo simuladores de sistemas financieros, redes neuronales, etc.

Sistemas de tiempo real. Regidos por restricciones estrictas en el tiempo y requieren garantías en el tiempo de respuesta, ejemplos controladores de procesos industriales y dispositivos de comunicación.

Administración de transacción. Sistemas para interactuar con las bases de datos y que incluyen acceso concurrente y distribuido de múltiples usuarios, ejemplo reservaciones de vuelo y control de inventario.

También la arquitectura involucra las interfaces (elementos gráficos), la funcionalidad (reglas del negocio), los datos y las funciones (elementos internos de los objetos) Actividad. Es una unidad o paso básico de un proceso. En el proceso de software las actividades definen los pasos necesarios para lograr las metas y los objetivos. Las actividades básicas del proceso de desarrollo de software son conocidas como el ciclo de vida:

Requisitos. Para especificar aspectos funcionales del sistema, que describen cómo interactuaría un usuario con la aplicación, se genera un Modelo de Requisitos.

Análisis. Para dar al sistema una estructura o arquitectura robusta y extensible, se genera un Modelo de Análisis.

Diseño. Para adoptar y refinar la arquitectura del sistema y adaptarla sl ambiente de implementación, se genera un Modelo de Diseño (de estructuras o de objetos y de sistema).

Implementación. Para codificar el sistema, se genera un Modelo de Implementación (lenguajes de programación, bases de datos).

Integración. Para combinar componentes del sistema, se genera un Modelo de Integración.

Pruebas. Para validar y verificar el sistema, se genera un Modelo de Pruebas (validación de acuerdo a la especificación del cliente y verificación si el sistema está siendo desarrollado correctamente).

Documentación. Para describir los diversos aspectos del sistema, se generan los manuales de usuario, programador, operador, administrador).

Mantenimiento. Para extender la funcionalidad del sistema, es la continuación del ciclo de vida, una vez concluida la primera versión del sistema.

Métodos y Metodologías. Los métodos definen las reglas para las transformaciones internas de las actividades, mientras que las metodologías definen el conjunto de métodos. Un método es un procedimiento que define tareas o acciones a realizar, donde cada tarea incluye condiciones de entrada y de salida que se deben satisfacer antes y después de completarse. Los métodos deben:

Apoyar conceptos básicos significativos para resolver problemas. Se deben utilizar en distintos dominios de aplicación según las arquitecturas: secuencial, concurrente, distribuido, en tiempo real.

Deben ajustarse al ciclo de vida del proceso, apoyando a todas las actividades.

Deben proveer técnicas para recopilar información.

Deben apoyar su propia extensibilidad, su propia documentación.

Deben permitir la generación de modelos a partir de la información recopilada por el método.

Deben apoyar la integridad de los modelos generados, verificando y evitando errores de consistencia.

Deben ofrecer entradas y salidas bien definidas que permitan la integración de varios métodos.

Deben contar con notaciones específicas y estandarizadas para representar los modelos desarrollados, los cuales deben incluir elementos gráficos, de texto o combinación de ambos.

Deben tener confianza en los métodos y las herramientas correspondientes; para lo cual se debe contemplar que éstos se mantendrán en el mercado y, que cuenten con capacitación y apoyo técnico.

Existen una gran variedad de métodos y metodologías en apoyo al proceso de software, como son las estructuras y orientadas a objetos.

Estructuradas: Se enfocan en la descomposición funcional de un sistema. El objetivo es lograr una definición completa del sistema, estableciendo los datos de entrada y salida. Estas metodologías se conocen como análisis y diseño estructurado (SA/SD Structured Analysis and Structured Design) y se basan en herramientas como:

o Diagramas de flujo de datos. Modelado de transformación de datos entre funciones del sistema. Se compone de procesos, flujo de datos, actores, y almacenamiento de datos (DFD).

o Diagramas de transición de estado. Sirven para modelar el comportamiento a través del tiempo, describen el efecto de eventos externos en los procesos y funciones.

o Diagramas entidad-relación. Para modelar un almacenamiento de datos.

Orientadas a objetos: Se enfocan en el modelado de un sistema en términos de objetos. Se identifican inicialmente los objetos del sistema para luego especificar su comportamiento y usan las herramientas siguientes:

o Diagramas de clase. Describen los componentes esenciales de la arquitectura de un sistema. A diferencia de los DFD, los de clases muestran relaciones de asociación entre clases y no flujo de datos entre ellas.

o Diagramas de casos de uso. Especifican un sistema en términos de su funcionalidad. A diferencia de las metodologías estructuradas los de casos de uso no son descompuestos en funciones de programación.

o Diagramas de transición de estado. Describen los cambios de estado de los objetos.

o Diagramas de secuencia. Describen los aspectos dinámicos de sistema, mostrando el flujo de eventos entre objetos en el tiempo.

o Diagramas de colaboración. Describen la comunicación entre objetos de un sistema.

o Diagramas de subsistemas. Se usan para describir agrupaciones de clases en un sistema.

Estrategias. Una estrategia es como un plan para lograr un objetivo. Afectan aspectos como la arquitectura del sistema, el orden en que se llevarán a cabo las actividades del proceso y las metodologías a utilizarse. Las estrategias incluyen la selección del tipo de proyecto a desarrollarse, selección de una tecnología y lenguaje de programación (ej. Tecnología OO y lenguaje JAVA), otras estrategias aceptadas son los prototipos (versión preliminar de un sistema) y la reutilización (componentes desarrollados anteriormente).

Herramientas. Aplicaciones que apoyan la administración del proceso de software y el conjunto de estas herramientas se le conoce como ingeniería de software asistida por computadora (CASE, Computer-Aided Software Engineering), cuyo objetivo es asistir al desarrollador durante las diferentes actividades del ciclo de vida del proceso de software: Editores de texto, generadores de modelos gráficos (diagramas), generadores de código, compiladores, depuradores, verificadores, validadores, medidores (monitores), administración de configuración y administradores de proyecto. Metodologías de desarrollo de software

1970s

Programación estructurada sol desde 1969

Programación estructurada Jackson desde 1975

1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la información (IE/IEM) desde 1981

1990s

Rapid application development (RAD) desde 1991.

Programación orientada a objetos (OOP) a lo largo de la década de los 90's

Virtual finite state machine (VFSM) desde 1990s

Dynamic Systems Development Method desarrollado en UK desde 1995.

Scrum (desarrollo), en la última parte de los 90's

Rational Unified Process (RUP) desde 1999.

Emergentes

Ganar-ganar (win-win). Extiende el modelo de espiral, haciendo énfasis en la identificación de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y los riesgos correspondientes. Se consideran cuatro ciclos compuestos de cuatro actividades: 1. Elaborar los objetivos, restricciones y alternativas del proceso y producto

del sistema y subsistema. 2. Evaluar las alternativas con respecto a los objetivos y restricciones.

Identificar y resolver las fuentes principales de riesgo en el proceso y el producto.

3. Elaborar la definición del producto y el proceso.

4. Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la partición del sistema en subsistemas para ser considerados en ciclos paralelos.

Programación Extrema (XP, eXtreme Programming. ………….. desde 1999

Proceso Unificado (UP, Unified Process). Es una extensión al proceso objectory (object factory), que tiene sus orígenes en la década de 1980. Se basa especialmente en la especificación de requerimientos de un sistema mediante casos de uso; parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental; integra aspectos como ciclos, fases, flujos de trabajo, mitigación de riesgo, control de calidad, administración de proyecto y control de configuración; considera las 4 “P” del desarrollo del software (personas, proyecto, producto y proceso); y se basa en las creencias de que para que un sistema sea exitoso se debe saber qué quiere y necesita el usuario, así como que las arquitecturas de los sistemas de software deben permitir visualizar un sistema desde diferentes perspectivas (como los edificios –electricidad, estructura, etc.-) y que dividir en etapas es práctico porque el desarrollo y la implementación pueden durar mucho tiempo.

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en varias metodologías específicas. Estos enfoques son los siguientes:

Modelo en cascada: Framework lineal.

Prototipado: Framework iterativo.

Incremental: Combinación de framework lineal e iterativo.

Espiral: Combinación de framework lineal e iterativo.

RAD: Rapid Application Development, framework iterativo.

1.3. Métodos de desarrollo de software orientado a objetos. (Alfredo Weitzenfeld)

Métodos de desarrollo de software orientados a objetos

Siglas Método

RDD Responsability-Driven Design

CRC Tarjetas Clase-Responsabilidad-Colaboración

OOAD Object-Oriented Analysis and Design

OOD Object-Oriented Design

OMT Object Modeling Technique

OOSE Object Oriented Software Engineering

OOK/MOSES Object-Oriented Knowledge

OOSA Object-Oriented System Analysis

OBA Object Behavior Analysis

OORA Object-Oriented Requirements Analysis

Synthesis Synthesis Method

OOSD Object-Oriented System Development

OOAD/ROSE Object-Oriented Analysis and Design

FUSION Object-Oriented Development

UP Unified Software Development Process

Actividad Método Notación Métodos de requisitos

OBA

FUSION UP Actor 1 Casos de uso en UML Actor 2

Métodos de análisis

OBA

FUSION UP Asociación de clases en UML

Métodos de diseño

UML

FUSION

RDD Asociación de clases en UML

Métodos de codificación class Clase 1 extends Clase X

Técnicas de JAVA …..

Técnicas de C++

Técnicas de Smalltalk

Fig. Contraste de las actividades, métodos y notaciones de desarrollo de software

1.4. El proceso de desarrollo unificado – RUP. El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario. Este modelo puede trabajar como un contrato entre el desarrollador y el cliente o usuario del sistema, por lo que deberá proyectar lo que el cliente desea según la percepción del desarrollador. Por ello, es esencial que los clientes lo comprendan. El modelo de requisitos es el primero en desarrollarse, y es la base para formar todos los demás modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias a este nivel que posteriormente. El modelo de requisitos que se desarrollará se basa en la metodología Objectory (Jacobson, 1992), que tiene su fundamento en el modelo de casos de uso. Actualmente esta metodología es parte del Proceso Unificado Racional (RUP, Rational Unified Process). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos.

Requisitos

Análisis

Implementación

Diseño

Clase 1 Clase 2

Clase 1

Clase 2

El proceso unificado de desarrollo de software es el conjunto de actividades necesarias para transformar requisitos de usuarios en software. La tendencia actual en el software lleva a la construcción de sistemas más grandes y más complejos. El UP (proceso unificado) nació bajo la premisa de renovar la manera de desarrollar software empleando lo mejor de las viejas prácticas y adoptando nuevas y más eficientes maneras, de tal manera que el UP es un intento de obtener lo mejor de otros modelos. El proceso unificado está basado en componentes interconectados a través de interfaces bien definidas, utiliza las bases del UML (Lenguaje Unificado de Modelado –Unified Modeling Languaje), se resume en tres fases clave: Dirigido por casos de uso, Centrado en la arquitectura, Iterativo e incremental. El UP está dirigido por casos de uso. Para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. El término usuario no hacer referencia solo a humanos sino también a otros sistemas, así el término usuario representa a alguien o algo que interactúa con el sistema en desarrollo, ejemplo, un persona utiliza un cajero automático, inserta la tarjeta de plástico, responde a las preguntas que le hace la máquina mediante la pantalla y recibe su dinero; con este proceso se llevan a cabo una secuencia de acciones que proporcionan al usuario un resultado. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado, los casos de uso representan los requisitos funcionales, todos los casos de uso juntos constituyen el “modelo de casos de uso”, el cual describe la funcionalidad total del sistema (qué debe hacer el sistema), los casos de uso guían el diseño, implementación y prueba del sistema, es decir el proceso de desarrollo de software Centrado en la arquitectura. El papel de la arquitectura de software es parecido al papel que juega la arquitectura de la construcción de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios, calefacción, fontanería, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construcción. Analógicamente, la arquitectura de un sistema de software se describe mediante diferentes vistas del sistema. La arquitectura se ve influida por la plataforma de software y surge de las necesidades de la empresa y se refleja en los casos de uso (arquitectura hardware, sistema operativo, sistemas de gestión de bases de datos, protocolos de red), los bloques de construcción reutilizables, consideraciones de implantación, sistemas heredados, y requisitos no funcionales (rendimiento, fiabilidad). La arquitectura y los casos de uso se relacionan en que todo producto de software tiene tanto una forma como una función, los casos de uso representan la función (funcionalidad) y la arquitectura representa la forma (que permite el desarrollo inicial y las adecuaciones en el futuro).

El arquitecto: crea un borrador de la arquitectura (plataforma), debe tener en mente los casos de uso generales; continúa con un subconjunto de casos de uso en detalle (subsistemas, clases, componentes); a medida que los casos de uso se especifican y maduran, se descubre mejor la arquitectura, esto lleva a más casos de uso y continúa hasta que se considera la arquitectura ya es estable. Iterativo e incremental. El proceso de desarrollo puede durar meses hasta un año o más. Por tal motivo es práctico dividir el trabajo en partes o miniproyectos, cada miniproyecto es una iteración (pasos en el flujo de trabajo) que resulta en un incremento (crecimiento del producto). Los desarrolladores basan su implementación en dos factores: La iteración trata un grupo de casos de uso y juntos amplían la utilidad del producto desarrollado hasta ahora; y La iteración trata los riesgos más importantes. Los beneficios del proceso iterativo controlado:

La iteración reduce el costo del riesgo, ya que se van controlando a la vez que se visualizan, con lo que se fortalece el producto desde el principio y no se van arrastrando riesgos que en el futuro podrían llevar al producto de software al fracaso; así la organización sólo perdería el esfuerzo empleado en la iteración y no de todo el producto.

La iteración controlada reduce el riesgo de no sacar al mercado el producto en el tiempo previsto, se reconoce mejor el problema desde el principio y no hasta la fase de pruebas.

La iteración controlada acelera el ritmo del esfuerzo de desarrollo porque los desarrolladores trabajan más eficientemente para obtener resultados claros a corto plazo y no tener un periodo de desarrollo prolongado.

La iteración controlada reconoce una realidad que a menudo se ignora: que las necesidades del usuario y sus requisitos no pueden definirse completamente al principio, pues éstas se refinan en iteraciones sucesivas; esto hace más fácil la adaptación a requerimientos cambiantes.

La arquitectura proporciona la “estructura” para guiar la iteración y los casos de uso definen “objetivos” y dirigen el trabajo de cada iteración. La VIDA del UP, FASES del proceso unificado. (I. Jacobson, 2000) Se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema, donde cada ciclo es una versión del producto, las fases del ciclo de vida son: Requisitos, Análisis, Diseño, Implementación, Pruebas. Nacimiento Muerte Tiempo Ciclos/versiones

Fases del proceso unificado. (Roger P., 2010)

Elaboración Concepción

Construcción

Transición Lanzamiento Producción Concepción. Agrupa actividades tanto de comunicación con el cliente como de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión, los requerimientos fundamentales del negocio se describen por medio de un conjunto de casos de uso preliminares que detallan las características y funciones que desea cada clase principal de usuarios. La planeación identifica los recursos, evalúa los riesgos principales, define un programa de actividades y establece una base para las fases que siguen. Elaboración. Incluye las actividades de planeación y modelado del modelo general del proceso. La elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de concepción y aumenta la representación de la arquitectura para incluir cinco puntos de vista distintos del software; en algunos casos en este punto se crea una versión ejecutable. La planeación incluye aspectos como la estimación, programación de tiempos y análisis de riesgos; el modelado incluye aspectos de análisis, diseño). Construcción. En esta fase se hacen operativos los casos de uso para los usuarios finales; se obtiene el código fuente y a medida que se va codificando se van desarrollando pruebas unitarias y poco a poco las actividades de integración (ensamble de componentes y pruebas de integración). Transición. Incluye la entrega y la retroalimentación, es donde se proporciona a los usuarios para la prueba beta, para que reporten los defectos y los cambios necesarios. El

Incremento del software

equipo de software genera la información de apoyo necesaria (manuales de usuario, guías de solución de problemas, procedimientos de instalación, etc.) que se requieren para el lanzamiento. Incluye a las actividades de construcción y despliegue. Producción. No siempre las fases son secuenciales, pueden darse en forma escalonada o bien pueden desarrollarse algunas a la vez. Coincide con la actividad del despliegue, durante la producción se vigila el uso que se le da al software, se brinda apoyo para la operación y se reportan defectos y solicitudes de cambio para su evaluación. Las cuatro “P” en el desarrollo de software. (I. Jacobson, 2000) El resultado final de un proyecto de software es un producto que toma forma durante su desarrollo gracias a la intervención de muchos tipos distintos de personas. Un proceso de desarrollo de software guía los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que explica los pasos necesarios para terminar el proyecto. Todo proceso de software está automatizado por medio de una herramienta o conjunto de ellas.

Plantilla Participantes Automatización

Resultado

Personas. Los principales autores de un proyecto de software son los arquitectos, desarrolladores, ingenieros de prueba y el personal de gestión que les da soporte, además de los usuarios, clientes y otros interesados. Las personas son decisivas y los procesos afectan el comportamiento de las personas, considerando el modo en que se organizan y gestionan los proyectos de software, conceptos como la viabilidad del proyecto (la gente no se siente cómoda trabajando en un proyecto que parece imposible, se afecta la moral de las personas), la gestión del riesgo (cuando la gente siente que los riesgos no han sido analizados y reducidos, se sienten incómodos), la organización de los equipos (la gente trabaja mejor en equipos o grupos pequeños de seis a ocho miembros), la planificación del proyecto (en ocasiones la gente cree que la planificación de un proyecto no es realista, lo cual la moral se afecta, pensando en que nunca se acabará con el proyecto de software) y la facilidad de comprensión del proyecto (a la gente le gusta saber lo que está haciendo, requieren tener una comprensión global de lo que se está haciendo) tienen un papel importante, así como una sensación de cumplimiento (en un ciclo de vida iterativo, la gente recibe retroalimentación frecuentemente, lo que hace llegar a conclusiones y la retroalimentación constante acelera el ritmo de trabajo, esto aumenta la sensación de progreso) . Proyecto. Elemento organizativo a través del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versión de un producto.

Proceso

Personas Herramientas

Producto

Proyecto

Producto. Artefactos que se crean durante la vida del proyecto, como los modelos, código fuente, ejecutables y documentación. Un artefacto es un término general para cualquier tipo de información creada, producida, cambiada o utilizada por los trabajadores o desarrolladores del sistema, como ejemplo: diagramas UML y su texto asociado, los bocetos de la interfaz de usuario y los prototipos, los componentes, los planes de prueba y los procedimientos de prueba. Hay dos tipos de artefactos: artefactos de ingeniería (creados durante las distintas fases del proceso de software –requisitos, análisis, diseño, implementación y prueba-), se verá más ampliamente durante las unidades 2, 4 y 5; y artefactos de gestión (análisis de riesgo, plan de desarrollo –incluyendo el plan de iteraciones y versiones-, un plan para la asignación de personas –puestos y responsabilidades de los usuarios, ingenieros de prueba, diseñadores, analistas, jefe de proyecto, arquitectos-), se verá más ampliamente en la unidad 3. Un modelo es una abstracción del sistema, el proceso de construcción de modelos es un artefacto usado para construir un sistema, utilizando distintos modelos para describir todas las perspectivas diferentes del sistema, la elección de los modelos para un sistema es una de las decisiones más importantes del equipo de desarrollo. A través de los modelos se describen elementos importantes como los actores. Proceso. Un proceso de ingeniería de software es una definición del conjunto completo de actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es una plantilla para crear productos. El proceso dirige los proyectos, en la forma de desarrollo de software tradicional se usan los diagramas de flujo para describir el proceso en partes pequeñas, en cambio en este modelo unificado se identifican primero los distintos tipos de trabajadores que participan en el proceso, después se identifican los artefactos necesarios para cada tipo de trabajador o desarrollador. Una vez que se ha identificado, se puede describir cómo fluye el proceso a través de los diferentes trabajadores, y cómo ellos crean, producen, y utilizan los diferentes artefactos, de aquí surgen los Diagramas de Actividad que describen el flujo de trabajo en el modelado de casos de uso, y con ello se pueden identificar claramente las actividades que los trabajadores (también son los usuarios y/o clientes) deben realizar cuando se activan. En otras palabras, se describe el proceso entero en partes llamadas flujos de trabajo en términos de UML, un flujo de trabajo es un estereotipo de colaboración, en el cual los trabajadores y los artefactos son los participantes. Los procesos de desarrollo de software no son de aplicabilidad universal, varían según su contexto, según restricciones del negocio como plazos, costos, calidad, fiabilidad: existen factores que influyen en el tipo de procesos y son: factores organizativos (estructura organizacional, cultura empresarial, organización y gestión del proyecto, aptitudes y habilidades, experiencias de desarrollo de software previas), factores del dominio (proceso de negocio, clientes, competencia), factores del ciclo de vida (tiempo de salida al mercado, la tecnología, la experiencia o conocimiento de las personas en el desarrollo de software y las versiones planificadas y futuras), factores técnicos (lenguajes de programación, herramientas de desarrollo, bases de datos, marcos de trabajo y arquitecturas estándar, comunicaciones).

Herramientas. Software que se utiliza para automatizar las actividades definidas en el proceso (CASE- Computer Assisted Software Engineering). Soportan los procesos de desarrollos modernos, las herramientas influyen en el proceso, ya que son buenas para automatizar procesos repetitivos, mantener las cosas estructuradas, gestionar grandes cantidades de información y para guiarnos a lo largo del desarrollo; son usadas para aumentar la calidad, la productividad y para reducir el tiempo de desarrollo. Existen herramientas que soportan todos los aspectos del ciclo de vida del software, orientadas a la funcionalidad:

Gestión de requisitos. Se utiliza para almacenar, examinar, revisar, hacer el seguimiento y navegar por los diferentes requisitos de un proyecto de software.

Modelado visual. Se utiliza para automatizar el uso de UML, es decir, para modelar y ensamblar una aplicación visualmente. Con esta herramienta se consigue la integración con entornos de programación y se asegura que el modelo y la implementación sean consistentes.

Herramientas de programación. Editores, compiladores, depuradores, detectores de errores y analizadores de rendimiento.

Aseguramiento de la calidad. Se utilizan para probar aplicaciones y componentes, para uso de las pruebas de estrés y carga (cómo responderá el sistema cuando se estén utilizando 10,000 usuarios concurrentes.

Además de éstas, hay otras que abarcan todo el ciclo de vida: control de versiones, gestión de la configuración, seguimiento de defectos, documentación, gestión de proyecto y automatización de procesos. 1.5. El lenguaje de modelado unificado – UML.

http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-modelado-2/ http://www.docirs.cl/uml.htm definiciones de diagramas UML http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf

Una parte esencial de todas las tareas del desarrollo del software, y de las especificaciones

de requisitos y diseño en particular, es la utilización de una notación que permita

representar los aspectos esenciales de las mismas y que al mismo tiempo permita una

mecanización parcial del proceso de desarrollo. Dado que en la actualidad la fase de

implementación se suele realizar con tecnologías orientadas a objetos y que adicionalmente

este tipo de enfoque también es aplicable en otras fases del desarrollo, es importante que el

alumno conozca, al menos los principios básicos, de las notaciones orientadas a objetos, y

en especial la más extendida últimamente, como es el UML (Unified Modelling Language,

Lenguaje Unificado de Modelado).

Modelos

Cuando alguien intenta resolver un problema complejo lo primero que hace es estudiarlo:

Ver cuales son sus componentes, establecer relaciones entre las partes, comprender sus

propiedades e imaginar como funciona de un modo dinámico. Pero como la mente humana

es perezosa, no estarán todos los detalles, sólo los esenciales. Esto no es importante, con tal

de que la representación mental funcione igual que el problema real los detalles se pueden

abstraer. El resultado de este proceso es un modelo. Por tanto, modelo es una

representación de la realidad donde se abstrae lo no esencial. Para un mismo sistema se

puede establecer más de un modelo diferente en función de que aspecto interese resaltar o

del nivel de detalle que se quiera conseguir.

``UML'' son las siglas de Unified Modeling Language y como su nombre indica es un

lenguaje de modelado, es decir, su utilidad está en que sirve para expresar modelos. No es

nada más que eso, no indica cómo se debe hacer el análisis o el desarrollo orientados a

objetos y en consecuencia, no es una metodología de desarrollo, tan solo es una notación,

ahora bien, es la notación que se ha convertido en el estándar de facto de la mayor parte de

las metodologías de desarrollo orientado a objetos que existen hoy en día.

Su utilidad está en la especificación, visualización, construcción y documentación. De esta

frase, la palabra visualización es la más importante; UML es un lenguaje basado en

diagramas y está pensado para entrar por los ojos, tanto a los desarrolladores como a los

clientes.

Este capítulo no pretende ser exhaustivo, debe entenderse más bien como una introducción

inicial abreviada.

Historia

Grady Booch, Jim Rumbaugh e Ivar Jacobson (los tres amigos) desarrollaron las tres

metodologías de desarrollo orientado a objetos más seguidas de la industria. Rumbaugh con

su OMT (Object Modeling Technique) y Booch unificaron sus métodos, de ello nació la

primera versión del UML en el año 1994. Posteriormente, Jacobson, creador del método

OOSE (Object-Oriented Software Engineering) se unió al grupo. Actualmente el UML va

por la versión 1.3 y la 2.0 está en preparación

Elementos del lenguaje UML

A continuación se verán una serie de elementos notacionales pero sin entrar en detalle en la

esencia de lo que es el concepto de cada cosa (que se da por supuesto), sino solo en la

forma de dibujarlo en UML.

1.3.2.1 Clase

Es el gráfico más importante. En la figura 1.8 podemos ver que tiene cuatro partes que se

disponen de arriba a abajo en el orden siguiente:

Figure 1.8: Plantilla para una clase en UML

1. Nombre: Si aparece en cursiva la clase es abstracta. 2. Atributos: Pueden mostrar mucha información.

1. Tipo: Atributo:Tipo 2. Valor predeterminado: Atributo:Tipo=Valor ó Atributo=Valor 3. Restricciones: Las restricciones se pueden poner como se ha visto en el gráfico,

pero UML cuenta con un método aún más formal que es el lenguaje OCL. 4. Alcance: Un atributo puede ser público(+), protegido(#) o privado(-). 5. Ámbito: Hay dos tipos

Instancia: Cada objeto tiene su propio valor. Archivador: Solo hay un valor en todas las instancias de una clase (como

las variables static en Java). Estos atributos aparecen subrayados.

Toda esta información es opcional, de hecho la mayoría de las veces se pone sólo el

nombre del atributo.

3. Métodos: Al igual que los atributos también pueden especificar su alcance o ámbito. Además pueden indicar el tipo de los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parámetros como si no deben llevar un paréntesis abierto y otro cerrado al final del nombre.

4. Responsabilidades: Es una descripción de lo que hace la clase en su conjunto. Está información casi nunca está en los diagramas.

La información que se ha puesto en la figura de ejemplo es mucho más de la que se suele mostrar,

una clase puede representarse con un simple rectángulo con su nombre, como se ve en la figura

1.9.

Figure: La clase más sencilla posible

Además se puede omitir parte de la información de un apartado. Los puntos suspensivos

que hay en el ejemplo al final de las secciones de atributos y métodos indican que la clase

está abreviada, o lo que es lo mismo, faltan atributos y métodos. Sólo se pone lo necesario

para expresar la idea del diagrama.

Los estereotipos son una forma de introducir nuevos términos sobre el vocabulario propio

de un dominio. Los paquetes son agrupaciones de clases relacionadas de alguna forma

entre sí (su representación se ilustra en la figura 1.10). Las notas son un texto explicativo

de algún elemento y se representa de la forma indicada en la figura 1.11.

Figure 1.10: Un paquete que se puede encontrar en Java

Figure: Una anotación relativa a una clase

1.3.2.2 Objetos

Los objetos son instancias de clases (sus atributos tienen valores específicos) y, como se

indica en la figura 1.12, se representan poniendo el nombre de la instancia a la izquierda,

dos puntos y el nombre de la clase de la que deriva a la derecha.

Figure: Símbolo en UML de un objeto

1.3.2.3 Relaciones

Las clases no están aisladas, entre ellas pueden relacionarse de muchas maneras. La

representación básica de las relaciones es una línea (con otros elementos adicionales como

flechas, rombos, texto, etc.) entre las clases relacionadas.

1.3.2.3.1 Asociaciones

Es una relación conceptual, que no es inherente a la naturaleza de las clases, sino al papel

que juegan en el modelo y especifica que las instancias de una clase están conectadas con

las de otra. No es una relación fuerte, es decir, el tiempo de vida de un objeto no depende

del otro.

Como se puede ver en la figura 1.13, la relación tiene un nombre que indica en que consiste

y su dirección, indicada con un triángulo relleno. Se puede indicar además (de forma

opcional) cual es el papel (rol) que representa cada una de las partes en la relación.

Figure: Ejemplo de una asociación

Es posible que dos clases estén relacionadas entre sí por más de una relación en ambos

sentidos o que una clase esté relacionada con muchas. Se dice que una relación es reflexiva

cuando una clase está asociada consigo misma. Es posible que una instancia de una clase

pueda estar relacionada con un número variable de instancias de otra. La notación para

expresar esa multiplicidad es flexible:

1. Números concretos. Un número exacto: A. Por ejemplo: 5 (significa exactamente 5). 2. Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6). 3. Asterisco. El símbolo * significa muchos. Si está en un intervalo se pone en el extremo

superior. A..* se lee: A o más. Por ejemplo: 3..* (es 3 o más). Si el * está solo significa que puede ser un número cualquiera, cero incluido.

4. Combinación de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que significa entre 1 y 4, ó 6, ó 9 ó más de 9, es decir, los valores 0, 5, 7 u 8 no estarían permitidos); 2,4,6 (es los valores 2, 4 ó 6 y ninguno más).

En el siguiente ejemplo, representado en la figura 1.14, se hacen las siguientes suposiciones:

Figure 1.14: Relaciones entre alumnos, asignaturas y profesores

Un alumno puede estar matriculado como mínimo en una asignatura (si no está en ninguna no es alumno) y como máximo en 11.

En una asignatura se pueden matricular un número ilimitado de alumnos pero tiene que haber al menos uno o de lo contrario la asignatura no existe.

Un alumno puede estar haciendo o no el proyecto fin de carrera. En caso afirmativo tendrá un profesor asignado como coordinador.

Existen asignaturas que tienen prácticas y algunas de ellas son entre varios. Un alumno puede estar asociado con un número variable de compañero para hacerlas, puede ser que con nadie, uno, dos, ...

1.3.2.3.2 Navegabilidad

Es una propiedad del rol. Indica la posibilidad de ir desde el objeto fuente al objeto destino.

Significa visibilidad, o sea que generalmente se ``ven'' los atributos. Por defecto la

navegabilidad es bidireccional, pero a veces no será posible viajar en ambas direcciones.

Por ejemplo, en el caso de la figura 1.15 no es posible la bidireccionalidad debido a que

dado un password no se puede conocer el usuario al que pertenece (al menos en principio).

Figure 1.15: Navegabilidad

1.3.2.3.3 Calificación

Cuando se tiene una relación uno a muchos existe el problema de la búsqueda, es decir,

localizar la instancia correcta en el lado ``muchos''. Para reducir el número de instancias a

uno se utiliza un atributo de la relación, representado como se ve en la figura 1.16.

Figure: Calificación

1.3.2.3.4 Agregación

Es un tipo de relación del tipo todo/parte y se representa como se muestra en la figura 1.17.

Sirve para modelar elementos que se relacionan utilizando expresiones como: ``es parte

de'', ``tiene un'', ``consta de'', etc. Todo lo que se ha dicho antes acerca de la multiplicidad

es válido aquí.

Figure: Agregación

1.3.2.3.5 Composición

Es un tipo de agregación donde cada componente pertenece a un todo y sólo a uno (en el

ejemplo anterior no se cumple esto, por ejemplo, la antigua Unión Soviética tenía una parte

europea y una parte asiática). En la figura 1.18 vemos un ejemplo de este tipo de relación.

Figure: Composición

1.3.2.3.6 Herencia y generalización

Indica que una subclase o clase secundaria hereda los métodos y atributos definidos en una

superclase o clase principal. La superclase es más genérica que la subclase. Este tipo de

conexión se lee como ``es un tipo de''. En UML se utiliza el término generalización en vez

de herencia, pero es lo mismo. En la figura 1.19 se muestra un ejemplo de representación.

Figure 1.19: Herencia. Las clases abstractas van en cursiva

1.3.2.3.7 Dependencias

Es un tipo de relación en la que una clase usa a la otra. Por ejemplo: Una interfaz de un

programa de dibujo tiene varios objetos en la pantalla. La clase Pantalla tiene el método

DibujarObjetoGrafico(o:OG) y dibujará una recta, un punto, etc en función de lo que sea

ese objeto. Esta relación se representa como en la figura 1.20.

Figure 1.20: Dependencias

1.3.2.3.8 Interfaces

Son un conjunto de operaciones que especifican parte de la funcionalidad proporcionada

por una clase. Una interfaz es como una clase pero sin atributos. Se representa de dos

formas como se muestra en la figura 1.21. En una como una clase con el estereotipo

interfaz y en otra abreviada, sin mostrar los métodos. Entre los interfaces también existe

herencia. Una clase puede implementar varios interfaces, y un interfaz puede ser

implementado por más de una clase. Todos los métodos de un interfaz son públicos.

Figure 1.21: Interfaces

1.3.3 Diagrama de clases

Es el diagrama más importante en UML. Es un modelo estático del sistema que contiene los

siguientes elementos:

Clases Interfaces Colaboraciones: Conjunto de clases, interfaces y demás que exhiben un comportamiento. Relaciones de dependencia, colaboración y asociación.

Se puede utilizar para modelizar tres cosas:

1. Los elementos del sistema. 2. Colaboraciones. 3. Esquema lógico de bases de datos.

Veamos el modelado con diagrama de clases con el ejemplo de una estructura documental. Un

objeto documental es, por ejemplo, un ejemplar de ``La divina comedia'' o la ``enciclopedia

Espasa'', que está compuesto por varios volúmenes. Cada libro tiene una portada y un texto que se

pueden ver. Los libros se pueden consultar, abrir, etc; tienen título, autor y un número de páginas.

Cada ejemplar puede haber sido editado por una editorial en una fecha determinada. Un libro

puede haber sido traducido a varios idiomas y ser citado en algunos diccionarios, los cuales a su

vez pueden ser de un único tipo: multivolumen, que están compuestos (como es lógico) por varios

volúmenes. Los tipos de libros que existen son: con anexo o hipermedia. Los de tipo hipermedia

pueden tener sonido o enlaces. En la figura 1.22 vemos cómo se puede representar todo esto en

un diagrama de clases.

Figure 1.22: Ejemplo completo de un diagrama de clases tomado de http://do.ole.com/personal6/biblioteconomie/articulos/art8.html

1.3.4 Diagrama de objetos

Es un diagrama que contiene objetos y enlaces entre ellos. Pueden también agruparse en

paquetes y se puede mostrar las clases si se considera oportuno para mostrar los objetos que

vienen de una clase concreta. Sirve para tomar una instantánea del sistema en un momento

dado del funcionamiento. También es un modelo estático porque no representa la evolución

a través del tiempo, sino un momento concreto. Como se puede ver en el ejemplo de la

figura 1.23, la notación correspondiente es:

1. Se pone el objeto en un rectángulo. 2. El nombre es opcional pero se debe poner la clase a la que pertenece precedida por dos

puntos, todo ello subrayado: NombreObjeto:Clase 3. Puede tener variables con su valor. 4. Al igual que las clases los objetos pueden estereotiparse. 5. Los objetos pueden estar relacionados por enlaces, que son instancias de las asociaciones

definidas en el diagrama de clases.

Figure 1.23: Diagrama de objetos

1.3.5 Diagrama de casos de uso

Los casos de uso son una descripción de una interacción con el sistema por parte de algo

externo al sistema que se llama actor. Por ejemplo: un usuario pulsa el botón de llamada de

un ascensor. El nombre del caso de uso se pone en la elipse, como en el de la figura 1.24.

Un caso de uso es un patrón o comportamiento que exhibe el sistema. Los casos de uso

representan requisitos funcionales. Los casos de uso se escriben desde el punto de vista del

actor, que es el usuario o sistema externo que interactúa con el sistema.

Figure 1.24: Caso de uso

Relaciones que nos podemos encontrar en los casos de uso (ver figura 1.25):

Figure 1.25: Relaciones entre casos de uso

1. Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en común se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo.

2. Extends: Significa que un caso de uso B es igual al A al cual extiende añadiendo algunos pasos.

3. Comunicates: Comunica un actor con un caso de uso o con otro actor.

1.3.5.0.1 Modelado del contexto

Hay que modelar la relación que tiene el sistema con los elementos externos. Los pasos a

seguir son:

1. Identificar los actores que interactúan con el sistema. 2. Organizar los actores. 3. Especificar las vías de comunicación con el sistema.

1.3.5.0.2 Modelado de requisitos

Esto significa incorporar los casos de uso necesarios, tanto los que son visibles

externamente como los que no. Para ello las actividades a seguir son:

1. Establecer su contexto. 2. Identificar las necesidades de los elementos del contexto. 3. Nombrar esas necesidades y darles nombre de casos de uso. 4. Identificar que casos de uso pueden ser especializaciones de otros y buscar

especializaciones comunes para los casos de uso ya encontrados. Los casos de uso se verán con detalle más adelante.

1.3.6 Diagrama de estados

Un sistema evoluciona en el tiempo pasando por una serie de estados. Parte de un estado

inicial y llega a un estado final. Un estado tiene:

Nombre. Variables. Actividades, que pueden ser de dos tipos:

o Acciones. Programadas por los desarrolladores o Eventos: Sucesos a los que reacciona el sistema. Pueden ser de tres tipos:

Entry: Actividades que se realizan al entrar al estado. Exit: Eventos al abandonar el estado. Do: Actividades mientras se está en el estado.

Y constan de las siguientes partes:

Signature: Nombre y lista de parámetros. o Guard condition: Expresión lógica que habilita o no la transición. o Acción: Acción interna a ser ejecutada. o Mensaje: Evento enviado a otro objeto (o a varios).

Las transiciones entre estados pueden tener parámetros. Cada transición tiene un evento

asociado. Cuando se terminan las actividades de un estado hay una transición.

Por ejemplo, supongamos que tenemos un ascensor que cuando está en el sótano (área

restringida a la que sólo se puede acceder con llave) sube a los pocos segundos para evitar

que si alguien se ha colado pueda acceder a las viviendas. Por otra parte el ascensor puede

estar subiendo, bajando o parado. Cuando se está bajando al sótano se considera como un

estado especial y el hecho de estar en el sótano también. Esto se puede representar como en

la figura 1.26.

Figure 1.26: Diagrama de estados para un ascensor

1.3.7 Diagrama de secuencias

Muestra los objetos y los mensajes intercambiados entre ellos teniendo en cuenta la

temporalidad con la que ocurren. Pueden mostrarse también los componentes porque son

objetos reutilizables y los casos de uso porque se muestran como objetos que implementan

el caso de uso. Sirven para documentar el diseño y validar los casos de uso. Gracias a estos

diagramas se puede ver cuales don los cuellos de botella del sistema observando el tiempo

que consume el método invocado. Los conceptos a tener en cuenta son:

1. Línea de vida de un objeto: Es una representación de la actividad del objeto durante el tiempo que dura el escenario. El tiempo transcurre de arriba abajo. Se representa con una cabecera con un rectángulo con el nombre del objeto y una línea vertical de puntos por debajo. Durante el tiempo en el cual el objeto tiene un método funcionando la línea de puntos se convierte en un rectángulo como se muestra en el ejemplo.

2. Activación: Es el proceso por el que un objeto pasa a tener un método en ejecución. Esto puede ocurrir o bien porque otro objeto ha invocado alguno de sus métodos o porque lo ha invocado el mismo (self-delegation). Cuando un objeto activa a otro siguen en actividad.

3. Mensaje: Un mensaje es un objeto que invoca el método de otro. La notación es una flecha horizontal desde la línea de vida de un objeto hasta otro.

4. Tiempos de transición: Es el tiempo que hay entre un mensaje y otro. 5. Condicionales: Si se desea representar una alternativa o threads. El mensaje sólo se envía

si la condición es verdadera. La condición se escribe entre corchetes y puede referenciar a otro objeto (ver figura 1.27).

Figure 1.27: Diagrama de secuencias. Condicionales

6. Iteración: Se pone el símbolo * previo a la condición. Se repite la acción mientras la condición es verdadera (ver figura 1.28).

Figure: Diagrama de secuencias. Iteración

7. Creación y destrucción de un objeto: La creación de un objeto se representa con un mensaje de creación sobre un rectángulo. La destrucción se representa con un aspa al final de su línea de vida (ver figura 1.29).

8. Métodos recursivos: Se representan poniendo un rectángulo superpuesto al que está activo en el momento (ver figura 1.29).

Figure: Diagrama de secuencias. Métodos recursivos y destrucción de objetos

Las boundary classes, o clases de frontera, sirven para capturar y documentar los requisitos de

interfaz. Muestran la interacción con el usuario o con un sistema externo. Las clases de entidad

son las inherentes al modelo del dominio y las de control son las que gestionan el caso de uso

asociado al diagrama de secuencias.

1.3.7.0.1 Reglas a seguir:

La primera columna debe corresponder al actor que inicia el caso de uso. La segunda columna debe ser un objeto de frontera, que se comunica con el actor. La tercera columna debe ser un objeto de control que gestiona el caso de uso.

Los objetos de control son creados por el objeto de frontera que inicia el caso de uso. Los objetos de frontera son creados por objetos de control. Los objetos de entidad son accedidos por objetos de control y frontera. Los objetos de entidad nunca tienen acceso a los objetos de frontera o control. De esta

forma estos objetos pueden ser reutilizados en varios casos de uso distintos.

1.3.8 Diagrama de actividades

Son un caso especial de los diagramas de estados. Modela el comportamiento del sistema y

la participación de las clases en ese comportamiento. Describen el comportamiento interno

de una clase en vez del comportamiento en función de los eventos. Para construirlos se

puede seguir la siguiente estrategia:

1. Identificar una clase que participa en el comportamiento cuyas actividades de proceso deban ser especificadas.

2. Identificar las distintas actividades que se van a modelar. 3. Identificar: estados, flujos y objetos.

Este diagrama es útil para modelar el flujo de trabajo de un negocio a alto nivel (ver ejemplo en la

figura 1.30) y consta de los siguientes elementos:

Figure: Diagrama de actividades. Concurrencia, bifurcación e indicación

1. Punto inicial. Se representa por un círculo negro. 2. Punto final. Es una diana. 3. Actividades. Son rectángulos con bordes redondeados. 4. Transiciones. Son el paso de una actividad a otra. Se representan con flechas. 5. Actividades concurrentes. Se representan por sus correspondientes actividades y una

barra negra de la cual parten las flechas que las inician. 6. Bifurcaciones: Se representan con un rombo o sencillamente con dos flechas que salen de

una actividad a otras dos. En cualquier caso, la condición se indica en cada uno de los ramales entre corchetes.

7. Indicaciones: Se pueden enviar o recibir. El envío se representa con un rectángulo acabado en flecha. El que las recibe con una figura complementaria de la anterior. Una indicación modela el envío y recepción de eventos.

1.3.9 Diagrama de componentes

Modelan la vista estática del sistema. Ilustran la organización y las dependencias entre

componentes software. Un componente puede ser: código fuente, un programa ejecutable,

tablas, o cualquier otro tipo de documento que forme parte del sistema. No tienen que estar

presentes todos los componentes, suele mostrarse una parte. Un componente puede

implementar una interfaz (ver figura 1.31).

Figure 1.31: Diagrama de componentes

El estándar de UML define cinco estereotipos: executable, library, table, file y document.

1.3.9.0.1 Ejecutables

Para modelarlos (ver ejemplo en la figura 1.32) los pasos a seguir son:

Figure: Ejecutable que usa una librería de manipulación de listas

1. Identificar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar un diagrama por cada nodo que se quiera modelar.

2. Identificar cada componente con su estereotipo correspondiente (executable, library, etc). 3. Relacionar los componentes entre sí.

1.3.9.0.2 Código fuente

Podemos usar estos diagramas (ver ejemplo en la figura 1.33) para expresar las

dependencias que existen entre los módulos para formar librerías o programas ejecutables.

Figure: Dependencias entre el código

1.3.10 Diagrama de colaboración

Dibuja las interacciones entre objetos organizadas a través de los objetos y los enlaces que

hay entre ellos. Este diagrama (ver ejemplo en la figura 1.34) es otra forma de ver la

secuencia de eventos. Es lo mismo que los diagramas de secuencia (se puede generar de un

modo automático un tipo de diagrama a partir del otro).

Figure: Diagrama de colaboración

1.3.11 Diagrama de distribución

Refleja la organización del hardware. El elemento principal de este diagrama es el nodo.

Hay dos tipos: los nodos con capacidad de ejecutar componentes y los que no pueden

ejecutar. La información que hay en un nodo es: nombre del nodo y componentes del nodo

(se puede poner sólo sus nombres o un diagrama de componentes). Los nodos a su vez

pueden estar físicamente conectados con otros, lo que se representa con una línea que los

une. La utilidad principal de este tipo de diagramas es la modelización de una red (ver

ejemplo en la figura 1.35).

Figure: Diagrama de distribución