Mdulo 1 Modelos y Proceso de desarrollo de Software.

1

1.1- Modelos, conceptos. Qu es un modelo y por qu modelamos? Los proyectos de software que fracasan lo hacen por circunstancias propias, pero todos los proyectos con xito se parecen en muchos aspectos. Entre todos los aspectos que hacen que un proyecto tenga xito uno en comn es el uso del modelado.

El modelado es una tcnica de Ingeniera probada y bien aceptada. Se construyen modelos arquitectnicos de casas y edificios para ayudar a sus usuarios a visualizar el producto final antes que el mismo est construido. Incluso podemos elaborar modelos matemticos para analizar los efectos de vientos o terremotos sobre los edificios.

Un modelo es una simplificacin de la realidad. Un modelo proporciona los planos de un sistema. Pueden ser planos generales, que ofrecen una visin global del sistema en consideracin, as como planos detallados. Un buen modelo incluye, para un nivel de abstraccin dado, los elementos que tienen gran influencia y omite aquellos menores que no son relevantes.

Todo sistema puede ser caracterizado desde diferentes perspectivas, utilizando diferentes modelos. Un modelo puede ser estructural resaltando la organizacin del sistema o puede ser de comportamiento, destacando su dinmica.

Se construyen modelos para comprender mejor el sistema que estamos desarrollando. A travs del modelado se persiguen los siguientes objetivos:

Los modelos ayudan a visualizar cmo es, o queremos que sea un sistema.

Los modelos permiten especificar la estructura o el comportamiento de un sistema.

Los modelos proporcionan plantillas que sirven de gua en la construccin de un programa.

2

Los modelos documentan las decisiones que se han adoptado.

Construimos modelos de sistemas complejos porque es difcil comprender el sistema en su totalidad. El ser humano tiene una capacidad limitada para comprender y abordar la complejidad, por ello a travs del modelado podemos reducir el problema que se est estudiando y enfocarnos en un aspecto a la vez.

En general, an en el proyecto ms simple, los desarrolladores siempre realizan alguna actividad de modelado como un bosquejo en hoja de papel o en algn software graficador. Sin embargo, estos modelos informales no proporcionan frecuentemente un lenguaje comn que pueda compartirse entre todos los desarrolladores y no siempre queda debidamente documentado.

As como existe un lenguaje comn para realizar planos en la industria de la construccin, en la Ingeniera Civil, Elctrica, entre otros, tambin es beneficioso para una empresa de software que todos sus desarrolladores utilicen un lenguaje comn para el modelado del software.

Principios bsicos de modelado Como se plantea en el libro El lenguaje Unificado de Modelado, la experiencia en el uso del modelado sugiere los siguientes cuatro principios bsicos (Booch G., Rumbaugh J. y Jacobson I., 1999, pgs. 7,8):

La eleccin de los modelos a crear tiene mucha influencia sobre cmo se aborda el problema y cmo de da forma a la solucin.

Esto quiere decir que hay que elegir bien los modelos. Los modelos adecuados pueden arrojar mucha luz sobre los problemas de desarrollo ms complicados, brindando una comprensin que no podramos obtener de otra manera. Ahora bien, si se incurre en la utilizacin de modelos errneos o inadecuados, stos desorientarn haciendo que uno se centre en cuestiones irrelevantes.

Todo modelo puede ser expresado a distintos niveles de precisin.

Los mejores tipos de modelos son aquellos que permiten elegir el grado de detalle dependiendo de quin est viendo el sistema y por qu necesita verlo. Lo que un usuario final espera de un modelo del sistema no es lo mismo que necesita un diseador. Un analista o un usuario final se centrarn en qu hace el sistema; un diseador/desarrollador se

3

centrar en el cmo. Tanto unos como otros querrn visualizar un sistema a diferentes niveles de detalle en diferentes momentos.

Los mejores modelos son los que estn ligados a la realidad.

Todos los modelos simplifican la realidad; lo importante es que esta simplificacin no enmascare ningn detalle importante. Es mejor tener modelos que tengan una clara conexin con la realidad y donde esta conexin sea dbil saber concretamente cmo se apartan estos modelos del mundo real.

No es suficiente confeccionar un nico modelo. Todo sistema no trivial se aborda mejor a travs de un conjunto de modelos casi independientes.

Si por ejemplo, se estuviera realizando la construccin de una casa, no hay un nico conjunto de planos que indiquen todos sus detalles sino que se necesitarn planos de planta, de electricidad, de lozas, de agua, entre otros. Lo mismo se aplica para los sistemas de software. Para comprender la arquitectura de tales sistemas se necesitan varias vistas complementarias y entrelazadas. Cuando se habla de modelos casi independientes se refiere a tener modelos que podemos construir y estudiar separadamente pero que estn interrelacionados.

1.2- Tipos de metodologas Concepto de Metodologa. En principio podemos definir una metodologa como ... un conjunto de filosofas, fases, procedimientos, reglas, tcnicas, herramientas, documentacin y aspectos de formacin para los desarrolladores de sistemas de informacin 2, segn lo expresa Piattini (2004, pg. 79)- citando a Maddison - . De acuerdo a esta definicin, una metodologa es entonces un conjunto de componentes que especifican:

Cmo dividir un proyecto en etapas.

Las tareas que se llevan a cabo en cada etapa.

4

Las salidas que se producen y cundo se deben producir.

Las restricciones se aplican.

Las herramientas que se van a utilizar.

Cmo se gestiona y controla un proyecto.

Considerando una definicin ms genrica, podemos decir que una metodologa de desarrollo es un conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar un nuevo software. Normalmente consistir en una serie de fases descompuestas en subfases (mdulos, etapas, pasos, entre otras formas de denominacin). Esta descomposicin del proceso de desarrollo gua a los desarrolladores en la eleccin de las tcnicas que debe elegir para cada estado del proyecto, as como facilita la planificacin, gestin, control y evaluacin de los proyectos.

Una metodologa, por lo tanto, representa el camino para desarrollar software de manera sistemtica.

Se mencionan a continuacin algunos conceptos relacionados con las metodologas:

Mtodos: Indican cmo construir tcnicamente un sistema. Abarcan un amplio espectro de tareas que incluyen la comunicacin, el anlisis de los requisitos, el modelado de diseo, la construccin de programas, la realizacin de pruebas y el soporte. Se basan en un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.

Tcnica: Es un mtodo estructurado y repetible para lograr una tarea especfica.

Herramientas: Suministran un soporte automatizado o semiautomatizado para el proceso y los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamada Ingeniera de Software Asistido por Computadora (CASE).

Objetivos de las Metodologas. Se pueden identificar, de forma general, tres necesidades principales que se intentan cubrir con una metodologa:

5

Mejores aplicaciones. De todos modos hay que tener en cuenta que el seguimiento de una metodologa no basta para asegurar la calidad del producto, sino que esto depende de muchos pequeos factores.

Un mejor proceso de desarrollo que identifica las salidas o productos intermedios de cada fase, lo que permite planificar y controlar el proyecto.

Un proceso estndar en la organizacin, lo que aporta entre otros beneficios una mayor integracin entre los proyectos de sistemas en marcha y una mayor facilidad en el cambio de personal de un proyecto a otro.

Entre los objetivos que pueden tener las metodologas, podemos mencionar:

Registrar los requisitos de un sistema de informacin de manera apropiada.

Proporcionar un mtodo sistemtico de desarrollo de forma que se pueda controlar su progreso.

Construir un sistema de informacin dentro de un tiempo apropiado y costos aceptables.

Construir un sistema bien documentado y que sea fcil de mantener.

Ayudar a identificar lo ms pronto posible cualquier cambio que sea necesario a realizar dentro del proceso de desarrollo.

Proporcionar un sistema que satisfaga a todas las personas afectadas por el mismo, ya sean clientes, directivos, auditores, usuarios.

Caractersticas deseables en una buena Metodologa. Entre las caractersticas deseables que debera incluir una metodologa se pueden destacar las siguientes:

6

Existencia de reglas predefinidas: La metodologa debera indicar formalmente reglas que definan sus fases, las tareas, productos intermedios, tcnicas y herramientas a utilizar.

Cobertura total del ciclo de desarrollo: Debe indicar los pasos a seguir para cubrir desde el planteamiento de un sistema hasta su mantenimiento.

Verificaciones intermedias: Debe contemplar la realizacin de verificaciones sobre los productos generados en cada fase para comprobar su correccin.

Enlace con procesos de gestin: Debe proporcionar una forma de desarrollar software de manera planificada, controlada y de calidad.

Comunicacin efectiva: Debera proporcionar un medio de comunicacin efectiva entre los desarrolladores para facilitar el trabajo en grupo y con los usuarios.

Utilizacin sobre un abanico amplio de proyectos: Debe ser flexible para poder emplearse en proyectos de diverso tamao, variedad y entorno.

Fcil formacin: La organizacin debe formar a su personal en todos los procedimientos y tcnicas definidos por la metodologa.

Uso de herramientas CASE: La metodologa debe ser soportada por herramientas automatizadas que mejoren la productividad del equipo de desarrollo y la calidad de los productos obtenidos.

Contener actividades que mejoren el proceso de desarrollo: Es necesario definir mediciones que indiquen la calidad y el costo asociado a cada etapa del proceso. Estos datos se utilizarn para analizar y modificar el proceso para su mejora.

Soporte al mantenimiento: El campo de la evolucin del software debera ser tenido en cuenta por las metodologas para facilitar las modificaciones sobre los sistemas existentes.

Soporte de la reutilizacin de software: Se deberan incluir procedimientos para la creacin, mantenimiento y recuperacin de componentes reutilizables que no se limiten slo al cdigo. La aplicacin de patrones de software en las distintas etapas del proceso de desarrollo ayuda a la reutilizacin de soluciones de anlisis y diseo.

7

Tipos de Modelos de Proceso Como ya se mencion anteriormente, una metodologa debe cubrir todo el ciclo de desarrollo de un sistema de software desde su planteamiento hasta su evolucin. Dentro de este ciclo de vida una porcin muy importante lo constituye el desarrollo del sistema de software.

Cualquier organizacin de ingeniera de software debe describir un conjunto nico de actividades para el proceso de software que adopte para el desarrollo del sistema. Tambin debe completar cada actividad con un conjunto de acciones de ingeniera de software y definir cada accin en cuanto a un conjunto de tareas que identifique el trabajo y los productos del trabajo que deben completarse para alcanzar las metas de desarrollo.

Despus, la organizacin debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especfica de cada proyecto, a las personas que lo realizarn y el ambiente en el que se ejecutar el trabajo.

Se mencionan a continuacin algunos de los modelos prescriptivos de proceso que consideramos ms representativos tal como los presenta Roger Pressman (2006) en su libro Ingeniera de Software (ver Bibliografa), sin que esta enumeracin sea exhaustiva ni la nica manera de clasificar los mismos. Luego en la Unidad 2 se presentar el Proceso Unificado de Desarrollo.

El ciclo de vida clsico o en cascada.

El modelo en cascada, llamado tambin el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo de software tal como se visualiza en la siguiente figura:

Fuente: Libro Ingeniera del Software Roger Pressman (2006), Pg. 50.

8

El modelo en cascada es el ms antiguo para la Ingeniera de software, sin embargo las crticas realizadas a este modelo durante las dcadas precedentes ocasionaron que an sus ms fervientes seguidores se hayan cuestionado su eficacia.

Entre los problemas que presenta el modelo en cascada podemos enunciar:

Los proyectos reales rara vez siguen el flujo secuencial que propone el modelo.

Frecuentemente es difcil para el cliente definir todos los requisitos de manera explcita en el inicio del proyecto.

Una versin funcional de los programas slo estar disponible cuando el proyecto est bastante avanzado, por lo que el cliente deber tener paciencia.

La naturaleza lineal del modelo en cascada conduce a situaciones en las cuales algunos miembros del equipo de trabajo deben esperar a otros para terminar tareas dependientes, lo cual bloquea el avance del proyecto. Sin embargo, este modelo de proceso puede resultar til en casos donde los requerimientos estn fijos y donde el trabajo se realice en forma lineal hasta su conclusin.

Modelos de procesos incrementales.

Muchas veces los requisitos iniciales del software estn bien definidos de manera razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, es probable que sea necesario proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y luego refinarla y expandirla en las entregas posteriores del software. En estos casos es conveniente elegir un modelo de proceso diseado para producir el software de manera incremental.

Se presentan a continuacin dos modelos de proceso de este tipo.

a) El modelo incremental.

El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Como se muestra en la siguiente figura, este modelo aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario.

9

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 52.

Cada secuencia lineal produce incrementos en el software. Con frecuencia, el primer incremento es un producto esencial, es decir se consideran los requisitos bsicos pero muchas caractersticas complementarias an no se incorporan. El producto producido se muestra al cliente y como resultado de la evaluacin se desarrolla un plan para el incremento siguiente que afronta la modificacin del producto esencial a fin de satisfacer mejor las necesidades del cliente e incorporar caractersticas y funcionalidades adicionales.

Este proceso se repite despus de la entrega de cada incremento hasta producir el producto completo.

El desarrollo incremental es til cuando el personal necesario para una implementacin completa no est disponible; si el producto esencial es bien recibido se agrega el personal necesario para implementar el incremento siguiente. Adems los incrementos se pueden planear para manejar los riesgos tcnicos; por ejemplo, cierta funcionalidad puede requerir el uso de un hardware nuevo que an no est disponible entonces se planean los primeros incrementos de manera que se evite el uso de este hardware.

b) El modelo DRA.

El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Con una buena comprensin de los requisitos y se limita el mbito del proyecto, el proceso DRA permite que un equipo de desarrollo

10

obtenga el producto de software completamente funcional dentro de un perodo muy corto, por ejemplo entre 60 y 90 das.

En la siguiente figura se ilustra el proceso DRA:

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 54.

Si una aplicacin de negocios se puede modular de modo que cada gran funcin se pueda completar en menos de tres meses es una candidata para aplicar DRA. Cada gran funcin se puede abordar por un equipo separado aplicando DRA, luego se integran y se forma el todo.

Como todos los modelos de proceso, este enfoque presenta algunos inconvenientes:

Para proyectos grandes escalables se necesitan suficientes recursos humanos para crear el nmero correcto de equipos DRA.

Los proyectos DRA pueden fracasar si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar el sistema en tiempo breve.

Es problemtica la construccin de los componentes necesarios para el DRA si el sistema no se puede modular en forma apropiada.

Si el alto rendimiento es un aspecto importante y se alcanzar al convertir interfaces en componentes del sistema, este enfoque puede no funcionar.

11

El modelo DRA no es apropiado cuando los riesgos tcnicos son altos, por ejemplo cuando la nueva aplicacin requerir muchas nuevas tecnologas.

Modelos de procesos evolutivos.

Al igual que todos los sistemas complejos, el software evoluciona con el tiempo. Los requisitos del negocio y productos frecuentemente cambian durante el proceso de desarrollo; en estos casos una ruta lineal que conduzca al producto final no ser real. En estas situaciones los ingenieros de software necesitan un modelo de proceso que haya sido diseado de manera explcita para incluir un producto que evolucione con el tiempo.

Los modelos evolutivos son iterativos y se caracterizan por la forma en que permiten que se desarrollen versiones cada vez ms completas del software.

Se presentan a continuacin dos modelos de proceso de este tipo:

a) Construccin de prototipos.

Frecuentemente los clientes definen un conjunto de objetivos generales para el software pero no identifican los requisitos detallados de entrada, proceso o salida. En estos casos y en muchas otras situaciones un modelo de construccin de prototipos puede ser de utilidad.

En este modelo el proceso se inicia con la comunicacin, en la cual el ingeniero de software y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en las que se necesita ms definicin. Se plantea entonces con rapidez una iteracin de construccin de prototipos y se presenta el modelado en forma de un diseo rpido. Este diseo rpido se centra en una representacin de los aspectos del software que sern visible para el usuario final y conduce a la construccin de un prototipo. El cliente/usuario evala el prototipo y con la retroalimentacin se refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente.

12

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 55.

Si bien la construccin de prototipos se puede utilizar como un modelo de proceso independiente, se emplea ms comnmente como una tcnica que puede implementarse dentro del contexto de cualquiera de los modelos de proceso expuestos.

La construccin de prototipos tambin plantea algunos inconvenientes:

El cliente ve lo que parece una versin en funcionamiento del software sin saber que por la prisa de hacer funcionar el prototipo no se ha considerado la calidad del software global o la facilidad de mantenimiento a futuro y le cuesta comprender que debe construirse otra vez para mantener los altos niveles de calidad.

Muchas veces el desarrollador establece compromisos de implementacin para lograr que el prototipo funcione con rapidez y luego se familiariza con las selecciones realizadas y se olvidan las razones por las que son inapropiadas.

b) El modelo en espiral

El modelo en espiral que fue propuesto originalmente por B. Boehm es un modelo de proceso de software evolutivo que combina la naturaleza iterativa de la construccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada.

Cuando se aplica este modelo el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones la entrega tal vez consista en un documento del modelo del sistema o un prototipo, luego

13

durante las ltimas iteraciones se obtienen versiones cada vez ms completas del producto de software.

El modelo en espiral que se expone a continuacin es una variacin del modelo original, presentada en el libro Ingeniera de Software de Roger Pressman (2006) (ver Bibliografa).

Fuente: Libro Ingeniera del Software Roger Pressman (2006), pg. 58.

En el primer circuito del espiral quiz se genere la especificacin del producto y los pasos siguientes alrededor del espiral producirn el desarrollo de un prototipo y luego progresivamente, versiones ms elaboradas del software. En cada paso sobre la regin de planeacin se producen ajustes al plan del proyecto.

A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de todo el ciclo de vida del producto de software siguiendo la evolucin del mismo.

El modelo en espiral mantiene el enfoque sistemtico de los pasos que sugiere el modelo en cascada pero lo incorpora al marco de trabajo iterativo que se adapta menor al mundo real. Asimismo, permite a los desarrolladores aplicar la construccin de prototipos como un mecanismo para reducir riesgos y en general en cualquier etapa evolutiva del producto.

De todos modos este modelo, al igual que otros, no est libre de inconvenientes. Es difcil convencer a los clientes de que el enfoque evolutivo es controlable; si un riesgo importante no se descubre y administra apropiadamente, surgirn problemas.

14

1.3- Caractersticas de los Modelos Orientados a Objetos El Paradigma Orientado a Objetos En los Modelos Orientados a Objetos, el sistema se puede ver (en trminos de percepcin) como una coleccin de objetos que colaboran entre s para obtener un objetivo comn. Las operaciones que modifican el estado de los objetos son sencillas; los objetos se construyen a partir de otros objetos lo que lleva a que los sistemas se puedan construir a partir de componentes probados.

Por lo enunciado anteriormente, las tcnicas orientadas a objetos se pueden utilizar como medios para el diseo sencillo de sistemas complejos.

La orientacin a objetos es muy poderosa cuando se combinan varias tecnologas: metodologas de Anlisis y Diseo Orientado a Objetos, herramientas CASE (Ingeniera de Software Asistida por Computadora), Programacin Visual, Generadores de Cdigo, entre otras.

El anlisis y diseo orientado a objetos tiene algunas caractersticas importantes:

Cambian nuestra forma de pensar sobre los sistemas. Para la mayora de las personas la forma de pensar OO es ms natural. Comenzamos a aprender sobre ellos desde la infancia (por ejemplo, al agitar un sonajero ste hace ruido). Desde una etapa muy temprana categorizamos los objetos y descubrimos su comportamiento.

Los sistemas suelen construirse a partir de objetos ya existentes. Esto lleva a un alto grado de reutilizacin, a una disminucin de costos, un menor tiempo de desarrollo y una mayor confiabilidad del sistema.

La complejidad de los objetos que podemos utilizar sigue en aumento, puesto que nuevos objetos se construyen a partir de

15

otros, que a su vez estn constituidos por otros objetos, y as sucesivamente.

Ayuda a explotar la potencia expresiva de los lenguajes de programacin basados en objetos y orientados a objetos.

Elementos del Modelo de Objetos Para todo lo que se considere orientado a objetos (un lenguaje de programacin, un herramienta CASE, tcnicas de modelado, un proceso de desarrollo, por ejemplo) el marco de referencia conceptual es el modelo de objetos. Hay cuatro elementos fundamentales en este modelo:

Abstraccin

Encapsulamiento

Modularidad

Jerarqua

Al decir fundamentales se quiere significar que cualquier modelo que carezca de alguno de estos elementos no se considera orientado a objetos.

Desarrollamos a continuacin el concepto de cada uno de los elementos fundamentales.

Abstraccin

Como la define Grady Booch, la abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objeto y proporciona as fronteras conceptuales ntidamente definidas respecto a la perspectiva del observador. (Booch Grady, 1996, pg. 46).

Una abstraccin se centra en la visin externa de un objeto y sirve para separar el comportamiento esencial de un objeto de su forma de implementacin.

En el desarrollo del modelo de objetos de un sistema se tratar de construir abstracciones de entidades que imiten directamente el vocabulario de un determinado dominio de problema.

16

Se puede caracterizar el comportamiento de un objeto considerando los servicios que presta a otros objetos, as como las operaciones que puede realizar sobre otros objetos. Este punto de vista nos lleva a concentrarnos en la visin exterior del objeto, lo que algunos llaman el modelo contractual; la vista exterior de cada objeto define un contrato del que pueden depender otros objetos y que a su vez es llevado a cabo por la vista interior del propio objeto (a menudo en colaboracin con otros objetos). Este contrato abarca las responsabilidades de un objeto, es decir el comportamiento del que se le considera responsable.

Por ejemplo, en un banco uno de los servicios ofrecidos es del de Caja de Ahorro. Desde una vista externa una caja de ahorro en un objeto que sabe cul es su nmero de cuenta, a quin pertenece y cul es su saldo (de manera simplificada). Qu es su nmero de cuenta? Un valor numrico de ocho dgitos y su saldo ser un valor que represente el monto de dinero actualmente depositado en ella. Sus responsabilidades sern, entre otras:

Conocer su saldo actual

Conocer su nmero

Incrementar su saldo por un depsito

Disminuir su saldo por una extraccin

Conocer quin es su titular

Mostrar sus dato

Conocer su fecha de cierre

Encapsulamiento

La abstraccin y el encapsulamiento son conceptos complementarios: la abstraccin se centra en el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la implementacin que da lugar a este comportamiento. El encapsulamiento se consigue mediante la ocultacin de informacin, por el cual se ocultan todos los aspectos de un objeto que no contribuyen a sus caractersticas esenciales. Normalmente lo que se oculta es la estructura de datos de un objeto as como la implementacin o codificacin de sus mtodos.

Grady Booch define el encapsulamiento como el proceso de almacenar en un mismo compartimiento los elementos de una abstraccin que constituyen su estructura y su comportamiento; sirve para separar la

17

interfaz contractual de una abstraccin y su implantacin. (Booch Grady, 1996, pg. 54,56).

En nuestro ejemplo de la caja de ahorro, por ejemplo, la propiedad saldo podra estar internamente almacenada como:

Saldo: campo de tipo real con dos decimales

O podra estar almacenada de la siguiente manera:

Importe entero: campo entero que almacena la cantidad entera del saldo

Importe decimal: campo entero que almacena la cantidad decimal del saldo

Cualquier objeto titular que solicite a caja de ahorro que muestre su saldo recibir como respuesta, por ejemplo, $ 100,50 y nunca se enterar de qu manera est internamente guardado este dato, as como tampoco sabr cmo operan los mtodos de caja de ahorro para mostrar este saldo.

De igual manera, cuando a un objeto titular le llega una solicitud de servicio (mensaje) por el cual se le pide mostrar su nombre, ste retornar una cadena de caracteres en la que figuran su apellido, primer nombre y segundo nombre, si lo tuviera. El objeto que hizo la solicitud no sabe si el objeto titular tiene:

Un atributo apellidoYNombre Dos atributos: apellido

nombre Tres atributos: apellido

primerNombre segundoNombre

De este modo el encapsulamiento permite que se pueda cambiar la implementacin de un objeto y que ninguna otra parte del sistema deba ser modificada siempre que no modifique su interfaz (abstraccin), que es lo que los otros objetos conocen para poder comunicarse con este objeto.

Modularidad

Como afirma Booch citando a Liskov la modularizacin consiste en dividir un programa en mdulos que pueden compilarse separadamente, pero que tienen conexiones con otros mdulos. (Booch Grady, 1996, pg. 61).

18

En algunos lenguajes las clases y objetos forman la estructura lgica de un sistema; se sitan, entonces, estas abstracciones en mdulos para producir la arquitectura fsica del sistema.

Los mdulos sirven como contenedores fsicos en los que se declaran las clases y objetos del diseo lgico realizado. Especialmente para aplicaciones grandes en las que puede haber varios cientos de clases el uso de mdulos es esencial para ayudar a manejar la complejidad. Para problemas muy pequeos el desarrollador podra decidir declarar todas las clases en el mismo paquete. Para cualquier situacin que se salga de lo trivial, es mejor solucin agrupar las clases que se relacionan lgicamente en el mismo mdulo.

Desde nuestra perspectiva, concluye Booch, la modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados. (Booch Grady, 1996, pg. 61).

Jerarqua

La jerarqua es una forma de clasificar u ordenar las abstracciones. Frecuentemente un conjunto de abstracciones forma una jerarqua y la identificacin de estas jerarquas en el anlisis y diseo simplifica en gran medida la comprensin del problema.

Las dos jerarquas ms importantes son:

Su estructura de clases: la jerarqua de clases est dada por la herencia.

Su estructura de objetos: la jerarqua de objetos est dada por la agregacin.

No desarrollamos aqu estos conceptos porque se vern ms adelante en las secciones Relaciones entre Clases y Relaciones entre Objetos.

Objetos y Clases OBJETO.

Concepto

Como lo plantea Booch, desde la perspectiva de la cognicin humana un objeto puede ser:

19

- Una cosa tangible y/o visible.

- Algo que puede comprenderse intelectualmente.

- Algo hacia lo que se dirige un pensamiento o accin. (Booch Grady, 1996, pg. 96).

A esta definicin informal podemos agregar que un objeto modela alguna parte de la realidad y es por lo tanto algo que existe en el tiempo y en el espacio.

Ahora bien, los objetos del mundo real no son el nico tipo de objeto de inters en el desarrollo de software. Existen otros tipos importantes de objetos que son invenciones del proceso de diseo cuyas colaboraciones con objetos semejantes sirven como mecanismos para desempear algn comportamiento de nivel superior. Esto nos lleva a una definicin mejorada segn la cual un objeto representa un elemento, unidad o entidad individual e identificable, ya sea real o abstracta, con un papel bien definido en el dominio del problema.

Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares estn definidos en su clase comn.

Estado:

Booch nos proporciona la siguiente definicin el estado de un objeto abarca todas las propiedades (normalmente estticas) del mismo ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades. (Booch Grady, 1996, pg. 98).

Una propiedad es una caracterstica inherente o distintiva, un rasgo o cualidad que hace que ese objeto sea ese y no otro. Las propiedades suelen ser estticas porque estos atributos suelen ser inmutables y fundamentales para la naturaleza del objeto.

Todas las propiedades tienen algn valor. Este valor puede ser una mera cantidad o puede denotar otro objeto. Se dice que los valores son normalmente dinmicos porque en algunos casos los valores son estticos, como en nuestro ejemplo de Caja de Ahorro la propiedad (o atributo) nmero no cambia, va a cambiar seguramente el valor del atributo saldo y probablemente el del atributo fechaDeCierre...

Siguiendo con este ejemplo el estado de un objeto caja de ahorro estar dado por los valores que adopte la propiedad saldo y fechaDeCierre. As los estados posibles sern:

20

Con saldo: si el valor de saldo es mayor a cero

Sin saldo: si el valor de saldo es igual a cero

Cerrada: si el valor de fechaDeCierre es distinto a vaco.

Comportamiento:

Ningn objeto existe de forma aislada. Los objetos reciben acciones y ellos mismos actan sobre otros objetos.

El comportamiento es cmo acta y reacciona un objeto, en trminos de sus cambios de estado y paso de mensajes (Booch Grady, 1996, pg. 101). es decir, el comportamiento de un objeto representa su actividad visible y comprobable exteriormente. Una operacin representa un servicio que todos los objetos de una clase ofrecen a sus clientes. Se reconocen cinco tipos de operaciones sobre un objeto. Los tres tipos ms comunes de operaciones son los siguientes:

Modificador: Una operacin que altera el estado de un objeto (modifica el valor de alguno/s de sus atributos. Por ejemplo: depositar, extraer, transferir para un objeto cajaDeAhorro.

Selector: Una operacin que accede al estado de un objeto (a alguno/s de sus atributos) pero no altera ese estado. Por ejemplo: mostrarTitular, mostrarSaldo, mostrarNumeroCuenta.

Iterador: Una operacin que permite acceder a todas las partes de un objeto en algn orden perfectamente establecido. Por ejemplo, si un objeto Titular tiene una propiedad nroTelfono con mltiples valores (para el telfono particular, laboral, celular) la operacin mostrarTelfono ser una operacin iteradota.

Hay otros dos tipos de operaciones habituales, que representan la infraestructura necesaria para crear y destruir objetos (instancias de una clase):

Constructor: Una operacin que crea un objeto y/o inicializa su estado.

Destructor: Una operacin que libera el estado de un objeto y/o destruye el propio objeto.

Unificando las definiciones de estado y comportamiento, Rebecca Wirfs-Brock defini las responsabilidades de un objeto de manera que stas incluyen el conocimiento que un objeto mantiene y las acciones que puede llevar a cabo.

21

Las responsabilidades de un objeto son todos los servicios que ste proporciona.

Identidad:

En el paradigma orientado a objetos, la identidad es la propiedad que tiene un objeto que le permite distinguirse de todos los dems objetos. La mayora de los sistemas de bases de datos utilizan claves de identificacin para distinguir objetos persistentes, mezclando el valor de un dato con la identidad.

En el mundo de los objetos podemos tener dos de ellos con valores iguales en todas sus propiedades y seguir siendo dos objetos distintos cada uno con su propia identidad. Por ejemplo, puede haber dos objetos Persona que tengan exactamente el mismo nombre, apellido, direccin y telfono, pero eso no significa que sean la misma persona (tenemos muchos casos conocidos de padres e hijos con los mismos nombres y mientras vivan en la misma casa tambin la misma direccin); en el paradigma orientado a objetos cada uno de esos objetos tiene su propia identidad y son perfectamente identificables.

Los sistemas de bases de datos relacionales son incapaces de distinguir entre dos objetos o instancias con valores iguales, por ello se hace indispensable contar con una clave identificatoria, que en nuestro ejemplo de padre e hijo sera por ejemplo el nmero de documento. Esta ser una cuestin importante a considerar si llegado el momento de decidir la forma de persistencia de nuestro modelo orientado a objetos la elegida es una base de datos relacional. En este momento habr que disponer de un mecanismo que salve las diferencias de ambos esquemas de representacin.

CLASE

Concepto:

Los conceptos de clase y objeto estn estrechamente relacionados, porque no puede hablarse de un objeto sin atencin a su clase. Sin embargo, existen diferencias entre ambos trminos. Mientras que un objeto es una entidad concreta que existe en el tiempo y en el espacio, una clase representa slo una abstraccin, la esencia de un objeto.

En el contexto del anlisis y diseo orientado a objetos, Booch define una clase como un conjunto de objetos que comparten una estructura comn y un comportamiento comn (Booch Grady, 1996). Esto significa que una

22

clase es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.

Las clases son los bloques de construccin ms importantes de cualquier sistema orientado a objetos. Se pueden utilizar para capturar el vocabulario del sistema que se est desarrollando. Estas clases pueden incluir abstracciones que formen parte del dominio del problema, as como clases que constituyen el dominio de una determinada solucin tecnolgica. Se pueden utilizar clases para representar cosas que sean software, hardware o puramente conceptuales.

Responsabilidades de una clase:

Una responsabilidad es un contrato o una obligacin de una clase. Al crear una clase, se est expresando que todos los objetos de esa clase tienen el mismo tipo de estado y el mismo tipo de comportamiento. A un nivel ms abstracto, estos atributos y operaciones son simplemente las caractersticas por medio de las cuales se llevan a cabo las responsabilidades de una clase.

Al modelar clases, un buen comienzo consiste en especificar las responsabilidades de los elementos del vocabulario. Una clase puede tener cualquier nmero de responsabilidades, aunque en la prctica cada clase bien estructurada tiene al menos una responsabilidad y a lo sumo unas pocas. Al ir refinando el modelo se traducirn estas responsabilidades en el conjunto de atributos y operaciones que mejor satisfagan las responsabilidades de la clase.

Las responsabilidades se enuncian como texto libre: una frase, una sentencia o, como mucho, un prrafo corto.

Vistas de una clase:

Debemos distinguir entre la visin externa (interfaz), y la visin interna, (implementacin), de una clase.

La interfaz de una clase proporciona su visin externa y por lo tanto enfatiza la abstraccin a la vez que oculta su estructura y su comportamiento. Esta interfaz se compone principalmente de las declaraciones de todas las operaciones aplicables a instancias de esta clase (objetos), pero tambin puede incluir la declaracin de constantes, variables y excepciones que se necesiten para completar la abstraccin.

23

Por otro lado, la implementacin de una clase es su visin interna, que engloba los secretos de su comportamiento. La implementacin de una clase se compone de la implementacin de todas las operaciones definidas en la interfaz de la misma.

Se puede especificar la interfaz de una clase con cualquiera de los tres niveles de visibilidad disponibles:

Pblica: Una declaracin accesible a todos los clientes de esa clase.

Protegida: Una declaracin accesible slo a la propia clase, sus subclases y clases amigas.

Privada: Una declaracin accesible slo a la propia clase y sus clases amigas.

A lo que nos indica la bibliografa clsica podemos agregar un tipo ms de visibilidad generalmente soportado por los lenguajes orientados a objetos y las herramientas automatizadas de modelado que es la visibilidad de paquete, esto significa que el elemento el pblico dentro del paquete o subsistema en el que se encuentre alojado.

La implementacin de estas caractersticas depender de cmo lo maneje el lenguaje de programacin elegido.

A continuacin se muestra una forma de representacin grfica para una clase, utilizada en UML (Lenguaje Unificado de Modelado, ver Unidad 2 de este mdulo)

Nombre: Cada clase ha de tener un nombre que la distinga de otras clases. Una clase puede dibujarse mostrando slo su nombre, como se muestra a continuacin:

24

Atributos: Un atributo es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener cualquier nmero de atributos o no tener ninguno. Un atributo representa alguna propiedad del elemento que se est modelando que es compartida por todos los objetos de esa clase. Un atributo es una abstraccin de un tipo de dato o estado que puede incluir un objeto de la clase.

Operaciones: Una operacin es la implementacin de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre su comportamiento, es decir, una operacin es una abstraccin de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase. Una clase puede tener cualquier nmero de operaciones y por lo menos una operacin. A menudo, pero no necesariamente, la invocacin de una operacin sobre un objeto cambia los datos o el estado del objeto. En nuestro ejemplo sera el caso de las operaciones depositar() y extraer(). Dependiendo del nivel de abstraccin en que se est modelando nos referiremos a responsabilidades (a nivel modelado de requisitos y anlisis), operaciones (en general a nivel diseo) y mtodos (normalmente durante la etapa de implementacin/codificacin), para referirnos a los servicios que prestan los objetos de una clase.

RELACIONES ENTRE OBJETOS

Un objeto por s mismo no es demasiado interesante. Los objetos contribuyen al comportamiento de un sistema colaborando con otros. Hay dos tipos de relaciones que se pueden dar entre objetos: enlaces y agregacin.

Enlaces:

Como nos cita Booch el trmino enlace es definido por Rumbaugh como una conexin fsica o conceptual entre objetos. (Booch Grady, 1996).

Un objeto colabora con otros a travs de sus enlaces con stos. Esto quiere decir que un enlace denota la asociacin especfica por la cual un

25

objeto (el cliente) utiliza los servicios de otro objeto (el servidor) o a travs de la cual un objeto puede comunicarse con otro.

Un concepto esencial en el paradigma orientado a objetos, es el hecho de que los objetos colaboran entre s para llevar a cabo un comportamiento superior.

Una colaboracin representa la solicitud de un servicio desde un objeto cliente a un objeto servidor para cumplir una responsabilidad del cliente. Los objetos de una clase pueden cumplir una responsabilidad por s solos o pueden requerir la asistencia de otros objetos (de otras clases).

Se dice que un objeto S colabora con otro objeto C, si el objeto C para cumplir con una responsabilidad, necesita enviar algn mensaje a S solicitndole un servicio. Desde el punto de vista del cliente, C, cada una de sus colaboraciones estn asociadas con una responsabilidad particular implementada por el servidor, S.

Un mensaje enviado de un objeto a otro representa la existencia de un enlace entre ambos. Los mensajes se muestran como lneas dirigidas, que representan su direccin, con una etiqueta que nombra al propio mensaje. Aunque el paso de mensajes es iniciado por el cliente y dirigido hacia el servidor los datos pueden fluir en ambas direcciones a travs de un enlace:

del cliente al servidor: parmetros

del servidor al cliente: respuesta

Supongamos que el objeto cajaDeAhorro, que conoce quin es su titular, como parte de su responsabilidad de mostrar sus datos completos debe mostrar el nombre del titular. Entonces necesita pedirle al objeto Titular que le retorne su nombre, para ello le enviar un mensaje indicndole tal solicitud. El objeto Titular responder retornndole su nombre. As se manifiesta el enlace entre ambos objetos. Esto puede representarse grficamente de la siguiente manera:

El grfico donde se muestran los enlaces entre objetos se denomina Diagrama de Colaboraciones y en general se utiliza durante el modelado de anlisis.

26

Agregacin:

La agregacin denota una jerarqua todo/parte, en la cual un objeto del todo tiene o contiene objetos de la parte.

La agregacin puede o no denotar contencin fsica. Por ejemplo, un aeroplano se compone de alas, motores, tren de aterrizaje: es un caso de contencin fsica. En otro ejemplo, un accionista tiene acciones, pero las acciones no son de ninguna manera parte fsica del accionista. Esta ltima relacin todo/parte es ms conceptual y por lo tanto menos directa que la agregacin fsica de las partes que forman un aeroplano.

Se desarrolla este tema con ms detalle en el punto siguiente, Relaciones entre Clases.

RELACIONES ENTRE CLASES

Las clases, al igual que los objetos, no existen aisladamente. Antes bien, para un dominio de problema especfico las abstracciones clave suelen estar relacionadas por vas muy diversas e interesantes, formando la estructura de clases.

Existen tres tipos bsicos de relaciones entre clases, en UML:

Generalizacin/Especializacin, que denota una relacin del tipo es un, padre/hijo, conocida como herencia.

Asociacin, que denota alguna dependencia semntica entre clases de otro modo independientes.

Dependencia, es una relacin de uso, se usarn cuando se quiera indicar que un elemento utiliza a otro. Uno de los usos ms frecuentes de la dependencia es para modelar una visibilidad temporal desde los objetos de una clase hacia los objetos de otra.

Herencia:

La herencia es una implantacin de la generalizacin. La generalizacin establece que las propiedades de un tipo se aplican a sus subtipos. La herencia hace que la estructura de datos y operaciones de una clase (padre) estn disponibles para su reutilizacin por parte de sus subclases

27

(hijos). La herencia de las operaciones de una superclase permite que las clases compartan el cdigo (en vez de volverlo a definir). La herencia de estructura de datos permite la reutilizacin de la estructura.

En trminos sencillos, la herencia es una relacin entre clases en la que una clase comparte la estructura y/o el comportamiento definidos en una (herencia simple) o ms clases (herencia mltiple). La clase de la que otras heredan se denomina superclase o clase padre y la clase que hereda de otra o ms clases se denomina subclase o clase hija.

A menudo, una subclase aade atributos y operaciones a los que hereda de sus padres, pero tambin puede redefinir el comportamiento heredado. Una operacin de un hijo con la misma signatura (nombre, parmetros y valor de retorno) que una operacin del padre, redefine la operacin heredada del padre; esto se conoce como polimorfismo, haciendo alusin a una operacin que adopta varias formas de implementacin segn haya sido redefinida en las clases hijas.

Una clase puede tener uno o ms padres o bien no tener ninguno. Una clase sin padres y uno o ms hijos se denomina raz o clase base. Una clase sin hijos se denomina clase hoja. Una clase con un nico padre se dice que utiliza herencia simple; una clase con ms de un padre se dice que utiliza herencia mltiple.

Las clases hojas son de las que se espera que existan instancias, es decir objetos, por ello se las denomina tambin clases concretas. Las clases sin instancias se llaman clases abstractas. Una clase abstracta se redacta con la idea de que las subclases aadan elementos a su estructura y comportamiento, usualmente completando la implementacin de sus mtodos. De modo que nunca existirn objetos de una clase abstracta.

Grficamente, la generalizacin se representa como una lnea dirigida continua, con una punta de flecha vaca apuntando al padre, como se muestra en el siguiente ejemplo:

28

Asociacin:

Una asociacin es una relacin estructural que especifica que los objetos de una clase estn conectados con los objetos de otra. Una asociacin slo denota una dependencia semntica entre dos clases pero no establece la forma exacta en que una clase se relaciona con la otra; slo puede denotarse esa semntica nombrando el papel que desempea cada clase en relacin con la otra.

Dada una asociacin entre dos clases se puede navegar desde un objeto de una clase hasta un objeto de la otra.

Grficamente, una asociacin se representa como una lnea continua que conecta la misma o diferentes clases:

Observacin: La simbologa que se est utilizando para graficar las relaciones entre clases es la establecida por UML.

29

Un concepto importante a modelar respecto de una asociacin es la navegacin. La navegacin de una asociacin especfica que dado un objeto perteneciente a la clase de un extremo se puede llegar fcil y directamente a los objetos de la clase del otro extremo, normalmente debido a que el objeto inicial almacena algunas referencias a los objetos en el destino. La direccin de la navegacin indica qu clase es la que contiene la referencia hacia la otra (determina quin conoce a quin).

Puede ocurrir que en algunos casos la asociacin necesite ser navegable en ambos sentidos. Por ejemplo:

Para mostrar los datos completos de una factura es necesario que factura conozca al cliente al que corresponde.

Para mostrar un resumen de cuenta de un cliente es necesario que cliente conozca las facturas que le corresponden.

Esta situacin se modela de la siguiente manera:

30

O tambin se puede modelar as:

Es legal que ambos extremos de una asociacin estn conectados a la misma clase. Esto significa que, dado un objeto de una clase, se puede conectar con otro/s objeto/s de la misma clase. A este tipo de asociaciones se les denomina reflexivas. Por ejemplo:

En este ejemplo se recurri a otro elemento con el que podemos adornar una asociacin: la definicin de un rol. Cuando una clase participa en una asociacin, tiene un rol especfico que juega en la asociacin; un rol es simplemente la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo.

En muchas situaciones de modelado, es importante sealar cuntos objetos pueden conectarse a travs de una instancia de la asociacin. Este cuntos se denomina multiplicidad de la asociacin y se escribe como una expresin que se evala a un rango de valores o a un valor explcito. Cuando se indica una multiplicidad en un extremo de una asociacin se est especificando que para cada objeto de la clase en el extremo opuesto

31

debe haber tantos objetos en este extremo. Se puede indicar una multiplicidad de exactamente uno (1), cero (0), muchos (*), uno o ms (1..*) o un valor exacto (por ejemplo, 5). La multiplicidad se indica en el extremo que corresponde a la navegacin.

Agregacin:

La agregacin es un tipo especial de asociacin. Las relaciones de agregacin entre clases tienen un paralelismo directo con las relaciones de agregacin entre los objetos correspondientes a esas clases. La agregacin es una relacin todo/parte en la cual una clase representa una cosa grande (el todo), que consta de elementos ms pequeos (las partes). Representa una relacin del tipo tiene un, o sea, un objeto del todo tiene objetos de la parte.

Grficamente la agregacin se representa como se muestra a continuacin:

La agregacin puede o no denotar contencin fsica. Tenemos entonces dos posibilidades en cuanto a la relacin de agregacin:

32

Agregacin por Valor: Es un tipo de relacin, en la que el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es tambin llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

En este tipo de relacin el objeto parte no existe independientemente del objeto todo que lo contiene. Esto significa que el tiempo de vida de ambos objetos est ntimamente relacionado: cuando se crea una instancia del todo, se crea tambin por lo menos una instancia de la parte; cuando se destruye el objeto todo esto implica la destruccin de todos los objetos parte relacionados a l.

En el ejemplo, cuando se crea una instancia de Pedido (un objeto pedido) es porque existe al menos una instancia (objeto) de la clase DetallePedido.

Agregacin por Referencia: Es un tipo de relacin, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento). Algunos autores llaman tambin a esta forma de agregacin compartida porque es posible que un objeto parte o contenido corresponda a ms de un objeto todo o contenedor Por ejemplo:

Esta forma de graficar la agregacin es opcional. No es obligatorio determinar el tipo de agregacin sobre todo durante el modelado de requerimientos o anlisis, pero es til comprender el significado de ambas y es ms til determinar concretamente el tipo de agregacin en la actividad de diseo.

33

Dependencia:

Este tipo de relacin se define en el libro de UML como una relacin de uso que declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza, esto representa la dependencia que tiene una clase de otra. (Booch, Rumbaugh y Jacobson, 1999)

Generalmente las dependencias se utilizan para indicar que una clase utiliza a otra como argumento en la signatura de una operacin, esto significa que la clase dependiente obtiene visibilidad de la otra clase porque recibe un objeto como parmetro de alguna operacin. Esto es claramente una relacin de uso: si la clase utilizada cambia, la operacin de la otra clase puede verse tambin afectada, porque la clase utilizada puede presentar ahora una interfaz o comportamientos diferentes.

Grficamente estas relaciones se representan con una lnea discontinua dirigida hacia la clase de la cual se depende, como se muestra a continuacin:

La dependencia se utiliza para representar la visibilidad de parmetro. En nuestro ejemplo CondicionPago se hace visible para Cuota porque un objeto de esta ltima clase recibir como parmetro de entrada para su operacin calcularRecargo, un objeto de la clase CondicionPago.

DIAGRAMA DE CLASES

Los diagramas de clases son los ms utilizados en el modelado de sistemas orientados a objetos. Un diagrama de clases muestra un conjunto de clases as como sus relaciones.

Los diagramas de clases se utilizan para modelar la vista de diseo esttica de un sistema (ver el punto 2.1 Vistas de UML en este mismo mdulo). Principalmente esto incluye modelar el vocabulario del sistema. Un

34

diagrama de clases se puede utilizar para modelar las clases lgicas, que son tpicamente la clase de cosas de las que habla la gente de negocios de una organizacin (los usuarios). En este caso se usa el diagrama de clases para modelar el dominio del problema pero tambin se utiliza el diagrama de clases para mostrar las clases de implementacin, que son las cosas con las que trabajan los programadores. Este enfoque se aplica a partir de la actividad de Diseo de un sistema.

En un diagrama de clases podemos encontrar:

Clases

Relaciones: herencia, asociacin (su variante: agregacin), dependencia.

Indicadores de multiplicidad y navegabilidad

Nombre de Rol

En este diagrama podemos representar las clases indicando slo su nombre (en este caso sera un diagrama abreviado) o mostrando tambin los atributos y/o operaciones.

A continuacin se muestra un fragmento de un diagrama de clases uniendo algunos de los ejemplos individuales ya vistos:

Simbologa del Diagrama de Clases

En el grfico que figura a continuacin, se resumen todos los elementos que pueden estar presentes en un diagrama de clases:

35

1.4- Metodologas estructuradas vs. Metodologas Orientadas a Objetos El tema del carcter del software es tratado por Grady Booch entre otros autores, al explicar que la complejidad innata del software se deriva de:

36

La complejidad del dominio del problema.

La dificultad de gestionar el proceso de desarrollo.

La flexibilidad que se puede alcanzar a travs del software.

Los problemas de caracterizar el comportamiento de sistemas discretos.

La tcnica para dominar la complejidad de un sistema es descomponerlo en partes ms y ms pequeas, cada una de las cuales se puede refinar en forma independiente. Tenemos dos formas de descomponer un sistema complejo:

Descomposicin algortmica: Es la forma de descomposicin sustentada por el anlisis y diseo estructurado. En este caso se divide el sistema en elementos funcionales relacionados estructuralmente entre s. Esta visin enfatiza el orden de los eventos.

Descomposicin orientada a objetos: En este caso la descomposicin consiste en determinar un conjunto de agentes autnomos (objetos) que colaboran para llevar a cabo algn comportamiento de nivel superior. Esta visin resalta los agentes que causan acciones o son sujetos de estas acciones.

En el libro Lenguaje Unificado de Modelado (ver bibliografa) se plantea que una de las debilidades de las tcnicas de anlisis y diseo estructurado es el hecho de que hay una desconexin bsica entre el modelo de anlisis y el modelo de diseo del sistema; no poder salvar este abismo genera que el sistema concebido y el sistema construido difieran a medida que transcurre el tiempo. En los sistemas orientados a objetos, es posible conectar todas las vistas casi independientes de un sistema en un todo semntico.

Los mtodos de diseo estructurado surgieron para guiar a los desarrolladores que intentaban construir sistemas complejos utilizando los algoritmos como bloques fundamentales para su construccin. El diseo estructurado tiene un enfoque descendente: la unidad fundamental de descomposicin es el subprograma y se va modelando en forma de un rbol de modo que cada subprograma realiza su funcin llamando a otros subprogramas.

Por otro lado, el diseo estructurado no contempla los problemas de abstraccin de datos y ocultacin de informacin, tampoco responde bien al cambio de tamao cuando se aplica a sistemas muy complejos.

37

Los mtodos de diseo orientado a objetos surgieron para ayudar a los desarrolladores a aprovechar la potencialidad de la programacin orientada a objetos que utiliza las clases y objetos como bloques bsicos de construccin. La descomposicin orientada a objetos produce sistemas ms pequeos a travs de la reutilizacin de mecanismos comunes; a su vez los sistemas orientados a objetos son tambin ms resistentes al cambio y por lo tanto estn mejor preparados para evolucionar en el tiempo ya que su diseo est basado en formas intermedias estables.

2.1- Vistas de UML Qu es UML? Como lo presentan sus creadores, Grady Booch, James Rumbaugh e Ivar Jacobson, el Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es un lenguaje estndar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software.

UML, como lo establecen sus autores, es apropiado para modelar desde sistemas de informacin en empresas hasta aplicaciones distribuidas basadas en la Web.

UML, es slo un lenguaje (no es una metodologa) y, por lo tanto, es slo una parte de un mtodo de desarrollo de software; fue diseado de forma independiente del modelo de proceso de software a aplicar, aunque para utilizarlo ptimamente, sus autores aconsejan utilizar un proceso que sea: dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental.

Cuando decimos que UML es un lenguaje nos referimos a que un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo de posibilitar la comunicacin. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representacin conceptual y fsica de un sistema. El modelado proporciona una comprensin de un sistema. Nunca es suficiente con un nico modelo, a menudo se necesitan mltiples modelos conectados entre s. El vocabulario y las reglas de UML indican cmo crear y leer modelos bien formados, pero no dicen qu modelos se deben crear ni cundo se deberan crear. sta es la tarea del proceso de desarrollo de software. Un

38

proceso bien definido guiar a los desarrolladores a decidir qu artefactos producir, qu actividades y qu personal se emplea para crearlos y gestionarlos.

UML es un lenguaje que permite:

Visualizar: Un modelo explcito facilita la comunicacin. Algunas cosas se modelan mejor textualmente, otras se modelan mejor de forma grfica. En todos los sistemas hay estructuras que trascienden lo que puede ser representado en un lenguaje de programacin. UML es uno de estos lenguajes grficos, es algo ms que un conjunto de smbolos grficos. Detrs de cada smbolo en la notacin UML hay una semntica bien definida. As, un desarrollador puede construir un modelo en UML y otro desarrollador o incluso otra herramienta, puede interpretar ese modelo sin ambigedad.

Especificar: En este contexto especificar significa construir modelos precisos, no ambiguos y completos. UML cubre la especificacin de todas las decisiones de anlisis, diseo e implementacin que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software.

Construir: UML no es un lenguaje de programacin visual, pero sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programacin. Esto significa que es posible hacer correspondencias desde un modelo UML a un lenguaje de programacin como Java, C++ o Visual Basic, incluso a tablas en una base de datos relacional o al almacenamiento persistente de una base de datos orientada a objetos. Esta correspondencia permite ingeniera directa: la generacin de cdigo a partir de un modelo UML en un lenguaje de programacin.

Documentar: Una organizacin de software que trabaje bien produce toda clase de artefactos adems de cdigo ejecutable. Estos artefactos incluyen, entre otros: requisitos, arquitectura, diseo, cdigo fuente, planificacin de proyectos, pruebas, prototipos, versiones. Artefacto es un trmino general para cualquier tipo de informacin creada, cambiada o utilizada por los trabajadores en el desarrollo del sistema.

39

Principales elementos del lenguaje Los tres elementos principales de UML son: los bloques bsicos de construccin de UML, las reglas que dictan cmo pueden combinarse esos bloques y algunos mecanismos comunes que se aplican a lo largo del lenguaje.

En los siguientes cuadros se resumen los elementos principales de UML.

Los elementos estructurales, en su mayora, son las partes estticas de un modelo y representan cosas que son conceptuales o materiales:

40

41

Los elementos de comportamiento son las partes dinmicas de los modelos UML, representan comportamiento en el tiempo y el espacio:

Los elementos de agrupacin, son las partes organizativas de los modelos UML, representan las cajas en las que puede descomponerse un modelo. Hay un elemento de agrupacin principal: los paquetes, que representan un mecanismo de propsito general para organizar elementos en grupos. Un paquete es puramente conceptual, slo existe en tiempo de desarrollo. Grficamente se visualiza como una carpeta:

Los elementos de anotacin, son las partes explicativas de los modelos UML, son comentarios que se pueden aplicar para hacer observaciones sobre cualquier elemento del modelo. Hay un tipo principal de elemento de anotacin llamado nota, que se grafica de la siguiente manera:

En el siguiente cuadro se explica brevemente el concepto de cada uno de los tipos de relaciones en UML:

42

A continuacin se explica brevemente el concepto de cada uno de los tipos de diagramas en UML:

43

Vistas de un sistema con UML Cada uno de los involucrados en el proyecto de desarrollo (usuarios finales, analistas, desarrolladores, integradores de sistemas, encargados de las pruebas, encargados de la documentacin, jefes de proyecto, entre otros) realizan diferentes actividades a lo largo del proyecto y cada uno mira al sistema de formas diferentes.

La arquitectura de un sistema es el artefacto ms importante que se puede emplear para manejar estos distintos puntos de vista. Tal como se plantea en el libro de UML, entendemos por arquitectura el conjunto de decisiones significativas sobre:

La organizacin de un sistema de software.

La seleccin de elementos estructurales y sus interfaces.

Su comportamiento (colaboraciones entre esos elementos).

La composicin de los elementos estructurales y de comportamiento en subsistemas cada vez ms grandes.

44

El estilo arquitectnico que gua esta organizacin (los elementos estticos y dinmicos y sus interfaces, colaboraciones y su composicin).

La arquitectura de un sistema se puede describir a travs de cinco vistas relacionadas entre s, como se muestra en el siguiente grfico:

Grfico de las vistas 4+1 Fuente: Libro El Lenguaje Unificado de Modelado Grady Booch y otros (1999), Pg. 27.

45

2.2- El proceso unificado de desarrollo Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En la ingeniera de software el objetivo es construir un producto de software o mejorar uno existente de modo que satisfaga las necesidades del usuario de forma eficiente y predecible.

Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software.

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros (2000), pg.4.

La comunidad de desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso que integre las mltiples facetas del desarrollo. Necesita un mtodo comn, un proceso que:

Proporcione una gua para ordenar las actividades de un equipo.

Dirija las tareas de cada desarrollador por separado y del equipo como un todo.

Especifique los artefactos que deben desarrollarse.

Ofrezca criterios para el control y la medicin de los productos y actividades del proyecto.

El Proceso Unificado es un proceso de desarrollo de software que utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema de software y fue propuesto por los mismos creadores de UML: Grady Boock, James Rumbaugh e Ivar Jacobson.

UML, como ya se ha mencionado es bastante independiente del proceso, lo que significa que se puede utilizar con diferentes procesos de ingeniera de

46

software. El Proceso Unificado es uno de los procesos de desarrollo que se adapta especialmente bien a UML.

Los aspectos definitorios del Proceso Unificado se resumen en tres frases claves: est dirigido por casos de uso, centrado en la arquitectura y es un proceso iterativo e incremental. Estas son las caractersticas esenciales de este proceso y son los puntos que se desarrollan a continuacin.

2.2.1- Dirigido por caso de uso Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requisitos funcionales del sistema para cada usuario.

Los casos de uso, adems de especificar los requisitos de un sistema, guan su diseo, implementacin y prueba; es decir, guan el proceso de desarrollo. Esto es as porque basndose en el modelo de casos de uso, los desarrolladores crean una serie de modelos de diseo e implementacin que llevan a cabo los casos de uso. Los ingenieros de prueba prueban la implementacin para garantizar que se han implementado correctamente los casos de uso.

De esta manera, los casos de uso adems de iniciar el proceso constituyen el hilo conductor del mismo. Sin embargo, los casos de uso no se desarrollan aisladamente, sino a la par de la arquitectura del sistema.

2.2.2- Centrado en la arquitectura Para comprender mejor el papel que juega la arquitectura en la construccin de un sistema de software, comparmosla con la arquitectura en la construccin de una casa. Una casa contempla distintos puntos de vista: la estructura, los conductos de gas, electricidad, agua, fontanera, entre otros aspectos. Esto permite al constructor tener una imagen completa de la casa antes de comenzar la edificacin.

De la misma manera la arquitectura de un sistema de software se describe mediante distintas vistas, que incluyen los aspectos estticos y dinmicos ms significativos del sistema. Las distintas vistas y el conjunto de decisiones significativas que abarca la arquitectura se trataron ya en el punto Vistas de un Sistema con UML (pg.60). El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms significativos del sistema.

47

La arquitectura del sistema surge de las necesidades de la empresa, como las perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambin se ve influida por muchos otros factores, como la plataforma en que tiene que funcionar el software (arquitectura de hardware, sistema operativo, sistema de gestin de base de datos, protocolos para comunicacin en red), los bloques de construccin reutilizables de los que se dispone, consideraciones de implantacin, sistemas heredados y requisitos no funcionales (por ejemplo, rendimiento, fiabilidad, seguridad).

Se necesita una arquitectura para:

Comprender el sistema.

Organizar el desarrollo.

Fomentar la reutilizacin.

Hacer evolucionar el sistema.

Si nos preguntamos cmo relacionar los casos de uso con la arquitectura, debemos recordar que cada producto tiene tanto una funcin como una forma. Se trata de dos fuerzas que deben estar equilibradas para obtener un producto con xito. En este contexto la funcin corresponde a los casos de uso y la forma a la arquitectura. Los casos de uso deben encajar en la arquitectura cuando se lleven a cabo y, a su vez, la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos.

Podemos resumir el trabajo de un arquitecto de un sistema (el que desarrolla la arquitectura), en los siguientes pasos:

1. Crear un esquema en borrador de la arquitectura, comenzando por la parte que no es especfica de los casos de uso (por ejemplo, la plataforma). Aunque esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe poseer una comprensin general de los casos de uso antes de comenzar la creacin del esquema arquitectnico.

2. Trabajar con un subconjunto de los casos de uso especificados, aquellos que representen las funciones clave del sistema. Cada caso de uso se especifica detalladamente en trminos de subsistemas, clases y componentes.

3. A medida que se especifican y maduran los casos de uso, se descubre ms de la arquitectura; esto a su vez lleva a la maduracin de ms casos de uso.

4. Se debe continuar este proceso hasta que la arquitectura sea estable.

48

2.2.3- Iterativo e Incremental El desarrollo de un producto de software puede demandar un tiempo considerable. Es prctico dividir el trabajo en partes ms pequeas o miniproyectos. Cada miniproyecto es una iteracin que resulta en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo y los incrementos, al crecimiento del producto. Para lograr efectividad, las iteraciones deben estar controladas, es decir deben seleccionarse y ejecutarse en forma planificada.

Lo que se implementar en una iteracin se selecciona en base a dos factores:

1. La iteracin trata un grupo de casos de uso que amplan la utilidad de lo desarrollado hasta el momento.

2. La iteracin trata los riesgos ms importantes.

En cada iteracin se identifican y especifican los casos de uso relevantes, se crea un diseo utilizando la arquitectura seleccionada como gua, se implementa el diseo mediante componentes y se verifica que los componentes satisfacen los casos de uso (es decir, que en cada iteracin se hace anlisis, diseo, implementacin y prueba).

Si una iteracin cumple con sus objetivos, se contina con la siguiente; de lo contrario los desarrolladores deben hacer una revisin y probar nuevos enfoques.

2.3- Fases dentro de un ciclo El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versin del producto para los clientes.

Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin. Cada fase a su vez puede tener varias iteraciones:

49

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros (2000), Pg.8.

Cada ciclo produce una nueva versin del sistema, que es un producto preparado para su entrega. Consta de cdigo fuente incluido en componentes que puede compilarse y ejecutarse, manuales y otros productos asociados. Para llegar a ese producto, debern desarrollarse los siguientes modelos:

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros (2000), pg. 9.

50

Fases del Proceso Unificado Cada ciclo del Proceso Unificado se divide en cuatro fases, cada una de las cuales puede tener varias iteraciones, como ya vimos. Estas fases son las siguientes:

Fase de Inicio

Principalmente esta fase responde a las preguntas sobre cules son las principales funciones del sistema para sus usuarios ms importantes, cmo podra ser la arquitectura del sistema y cul es el plan del proyecto, adems de cunto costar desarrollar el sistema.

Se realiza un modelo de casos de uso simplificado, con los ms crticos; la arquitectura es un esbozo que muestra los principales subsistemas, se identifican y priorizan los riesgos, se planifica en detalle la fase de elaboracin y se estima el proyecto.

Fase de elaboracin

Se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema.

La arquitectura se expresa en forma de vistas de todos los modelos del sistema (decimos vista de los modelos porque no son los modelos completos, ya que faltan incorporar casos de uso). Se crea una lnea base de la arquitectura.

Fase de construccin

Aqu la lnea base de la arquitectura crece hasta convertirse en el sistema completo, obteniendo as un producto preparado para ser entregado a los usuarios.

Fase de transicin

En esta fase el producto se convierte en una versin beta. Un nmero reducido de usuarios, con experiencia, prueba el sistema e informa defectos y deficiencias.

Los desarrolladores corrigen los problemas e incorporan las mejoras sugeridas. Esta fase incluye adems las tareas de formacin del cliente, ayuda en lnea y asistencia.

51

Conceptos bsicos del Proceso Los trminos que se definen a continuacin se utilizarn a lo largo de todo el desarrollo del proceso unificado.

Flujo de Trabajo (Workflow)

Es un conjunto de actividades. Un flujo de trabajo determina cmo fluye el trabajo de un trabajador a otro. Para ello se ha identificado primero qu tipos de trabajadores participan en el proceso. Luego se identifica qu artefactos se necesitan crear durante el proceso por cada tipo de trabajador. Entonces se puede describir cmo fluye el proceso a travs de los distintos trabajadores y cmo ellos crean, producen y utilizan los artefactos de los dems.

Un ejemplo de un flujo de trabajo es el flujo de trabajo de los requisitos. Incluye a los siguientes trabajadores: analista de sistemas, arquitecto, especificador de casos de uso y diseador de interfaz del usuario. Se producen los siguientes artefactos: modelos de casos de uso, prototipo de interfaz, modelo del dominio, entre otros.

Artefacto

Es un trmino general para cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores en el desarrollo del sistema. Por ejemplo, los diagramas UML y su texto asociado, los bocetos de la interfaz del usuario, componentes de cdigo fuente, componentes ejecutables, entre otros.

Trabajador

Se denomina as a los puestos de trabajo a los cuales se pueden asignar personas dentro del proyecto.

Un tipo de trabajador es un papel que una persona puede desempear en el desarrollo de software. Puede ser un especificador de casos de uso, un arquitecto, un ingeniero de componentes, un ingeniero de pruebas, por mencionar algunos. Cada trabajador es responsable de un conjunto completo de actividades y de producir un nmero determinado de artefactos.

52

Actividades

Son trabajos significativos para una persona que acta como trabajador.

Flujos de trabajo fundamentales En cada una de las iteraciones del ciclo de vida del Proceso Unificado se recorre cada uno de los flujos de trabajo fundamentales que son:

Requisitos

Anlisis

Diseo

Implementacin

Prueba

Sobre estos flujos de trabajo, las actividades que se realizan en ellos, los trabajadores que intervienen y los artefactos que se producen, tratan las unidades que siguen.

En la figura que se muestra a continuacin se visualiza cmo se combinan los flujos de trabajos por cada iteracin en cada una de las fases.

53

Fuente: Libro El Proceso Unificado de Desarrollo de Software Ivar Jacobson y otros (2000), pg. 11.

54

Bibliografa Bell Donald, UML BasicsPart III: TheClassDiagram, artculo publicado en

el sitio IBM Rational en Noviembre/2003.

Booch Grady, Anlisis y diseo orientado a objetos, con aplicaciones, EE.UU, Editorial Addison-Wesley Iberoamericana S.A., (1996).

Captulos: 1, 2, 3

Booch Grady, Rumbaugh James, Jacobson Ivar, (1999), El lenguaje de Modelado Unificado, Espaa, Editorial Addison Wesley Iberoamericana.

Captulos: 1, 2, 4, 5, 8

Evans Gary, GettingfromUse.CasetocodePart 1: Use Case Analysis, artculo publicado en el sitio IBM Rational en Julio/2004.

Jacobson Ivar, Booch Grady, Rumbaugh James, (2000), El Proceso Unificado de Desarrollo de Software, Espaa, Editorial Addison Wesley.

Captulos: 1, 3, 4, 5

Piattini Mario, Calvo-Manzano, Cervera, Fernndez, (2004), Anlisis y Diseo de aplicaciones informticas de gestin. Una perspectiva de Ingeniera de Software, Alfaomega Grupo Editor.

Captulo: 4

Pressman Roger, (2006), Ingeniera de Software. Un enfoque prctico 6ta. edicin, Ed. McGraw Hill

www.uesiglo21.edu.ar