Desarrollo de proyectos de software

Introduccin

Una de las caractersticas ms destacadas de las sociedades modernas es el uso de la tecnologa en la cual en muchos de los caso se involucra el desarrollo de sistemas de software que apoyan las actividades diarias en empresa, en nuestra casa, en procesos de comunicacin donde interviene el manejo de informacin o en los sistemas de produccin donde se ha sustituido la mano del hombre por maquinas que controlan la produccin atreves de dispositivos programados y grabados en una placa de silicio.

El software es algo indispensable en nuestra vida diaria que de manera general se entiende como programas de computadora; el desarrollo de software es una actividad donde se involucra la ingeniera; que es el estudio y aplicacin, por especialistas, de las diversas ramas de la tecnologa. El desarrollo de sistemas de software no es el simple hecho de programar computadoras, instrucciones en una placa de circuitos integrados para que realice una determinada funcin o el realizar grandes programas que se ejecuta en una poderosa computadora que puede realizar miles de operaciones por segundo o que de igual manera se puede ejecutar en una PDA o en algn otro dispositivo electrnico; por lo que este proceso involucra a la Ingeniera de Software que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema (Somerville, 2005, p.6).

Desarrollar un software significa construirlo simplemente mediante su descripcin. Est es una muy buena razn para considerar la actividad de desarrollo de software como una ingeniera. Por lo que un producto de software no se limita solo a programas de computadora sino a la documentacin asociada a este en las distintas etapas que interviene desde su concepcin, anlisis, diseo, implementacin, pruebas y mantenimiento. El software no estara completo si no existiera una especificacin de requerimiento o un diseo de la arquitectura, crear software es muy similar a la creacin y diseo de muchas otras reas como la arquitectura donde podemos empezar diseando una casa o departamento hasta un gran rascacielos o el puente ms largo que comunica dos ciudades.

Desarrollo de proyectos de software

1. Conceptos introductorios

Un proyecto es un intento por lograr un objetivo especfico mediante un grupo nico de tareas interrelacionadas y la utilizacin efectiva de los recursos.

Un proyecto es un esfuerzo por lograr un objetivo especfico mediante una serie especial de actividades interrelacionadas y la utilizacin eficiente de los recursos.

Atributos que definen un proyecto: Tiene un objetivo claramente definido expresado en trminos de alcance, programa y costo. La responsabilidad del gerente de proyectos es asegurarse de que se logre el objetivo del proyecto y que se termine el alcance del trabajo con calidad, dentro del presupuesto, a tiempo y a satisfaccin del cliente. Un proyecto se lleva a cabo en una serie de actividades interdependientes. Esto es, actividades no repetitivas que han de cumplirse en determinada secuencia a fin de alcanzar el objetivo del proyecto. En un proyecto se echa mano de varios recursos para realizar las actividades, entre ellos personas, empresas, equipo, materiales e instalaciones. Por ejemplo, la boda es un proyecto que puede requerir recursos como un catador, un florista, una limusina y un saln de recepciones.

Un proyecto tiene un marco temporal especfico, conocido tambin como vida til finita. Tiene un tiempo y una fecha en que debe concluirse.

Un proyecto puede ser un esfuerzo nico o de una sola vez. Algunos, como el diseo y la construccin de una estacin espacial, son nicos porque nunca antes se ha intentado su realizacin. Otros, como el de sarrollo de un producto nuevo, la construccin de una casa o la planeacin de una boda lo son por las adaptaciones que exigen. As, una boda puede ser una ocasin simple e informal, con pocos amigos en una capilla o un evento glamoroso preparado para una princesa,

Un proyecto tiene un cliente. El cliente es aquel que aporta los fondos necesarios para su realizacin. Puede ser una persona, una empresa o un grupo de dos o ms personas o empresas. Cuando un contratista construye una casa diseada especialmente para una pareja, sta es el cliente que financia el proyecto. Cuando una empresa suministra los fondos para que un equipo de empleados perfeccione su sistema de informacin para la administracin, el trmino cliente adquiere una definicin ms amplia, pues comprende no slo al que financia el proyecto (la gerencia de la empresa) sino tambin a otros vinculados a ella; por ejemplo, las personas que sern los usuarios finales del sistema. El encargado y el equipo del proyecto han de lograr los objetivos de l para satisfacer al cliente o clientes.

Desarrollo de proyectos de software

Por ltimo, un proyecto supone un poco de incertidumbre. Antes de iniciar uno, se prepara un plan a partir de ciertas suposiciones y estimaciones.

A continuacin se dan algunos ejemplos de proyectos: Montar una obra teatral. Desarrollar e introducir un producto nuevo. Disear e implementar un sistema de cmputo. Acuar una moneda de un dlar. Modernizar una fbrica. Disear y producir un folleto. Construir un centro comercial.

FACTORES QUE RESTRINGEN EL XITO DE UN PROYECTO

costo

programa

alcance

Satisfaccin del cliente

Desarrollo de proyectos de software

CICLO DE VIDA DE UN PROYECTO
Esfuerzo
Identificar una necesidad Desarrollar una propuesta de solucin Realizar el proyecto

La primera fase del ciclo de vida del proyecto incluye la identificacin de una necesidad , un problema, o una oportunidad y puede dar como resultado que el cliente solicite propuestas a personas, a un equipo de proyectos, o a organizaciones (contratistas), para resolver una necesidad identificada o solucionar un problema. La segunda fase del ciclo de vida del proyecto es el desarrollo de una solucin propuesta a la necesidad o al problema. Esta fase da como resultado la entrega de una propuesta al cliente por parte de una o ms personas o contratistas, o del equipo del proyecto. La tercera fase del ciclo de vida del proyecto es la puesta en prctica de la solucin propuesta. sta fase, que se conoce como desarrollo del proyecto , da como resultado el logro del objetivo definido de modo que el cliente quede satisfecho de que se complet el alcance del trabajo con calidad, dentro del presupuesto y a tiempo.

La fase final del ciclo de vida del proyecto es su terminacin, que se refiere a evaluar su ejecucin con el fin de mejorar proyectos futuros.

En la administracin de proyectos primero se establece un plan y despus se pone en prctica para el logro del objetivo del proyecto. Este esfuerzo de planeacin incluye definir con claridad los objetivos, dividir y subdividir el alcance del proyecto en "piezas" importantes denominadas paquetes de trabajo, definir las actividades especficas que necesitan realizarse para cada paquete de trabajo, presentarlas en forma grfica bajo la forma de un diagrama de red, estimar cunto tiempo necesitar cada una para terminarse, definir los tipos de recursos y cunto se necesita de cada recurso para cada actividad, estimar su costo y calcular un programa y un presupuesto para el proyecto. El beneficio definitivo de poner en prctica mtodos o tcnicas de administracin de proyectos es tener a un cliente satisfecho, tanto si usted es el cliente de su propio proyecto como si lo es un negocio (contratista), a quien le paga el cliente para realizar un proyecto. El completar el alcance total del proyecto con calidad, a tiempo y dentro del presupuesto proporciona una gran sensacin de satisfaccin para todos los que participan en el proyecto.

Desarrollo de proyectos de software

Evolucin del software

Desarrollo de proyectos de software

Recoleccin de requisitos y planificacin del proyecto inciales Planificacin basada en los comentarios del cliente

Desarrollo de proyectos de software

Recoleccin de requisitos Estrategia de diseo Implementacin en L4G Prueba

Figura 1.10 Tcnicas de cuarta generacin

El software se ha convertido en el elemento clave de la evolucin de los sistemas y productos informticos. En las pasadas cuatro dcadas, el software ha pasado de ser una resolucin de problemas especializada y una herramienta de anlisis de informacin, a ser una industria por s misma. Pero la temprana cultura e historia de la "programacin" ha creado un conjunto de problemas que persisten todava hoy. El software se ha convertido en un factor que limita la evolucin de los sistemas informticos.

La ingeniera del software es una disciplina que integra mtodos, herramientas y procedimientos para el desarrollo del software de computadora. Se han propuesto varios paradigmas diferentes, cada uno exhibiendo ventajas y desventajas, pero todos tienen una serie de fases genricas en comn. 1.1 Arquitectura 4+1 vistas Introduccin a las arquitecturas En los inicios de la informtica, la programacin se consideraba un arte, debido a la dificultad que entraaba para la mayora de los mortales, pero con el tiempo se han ido desarrollando metodologas para conseguir esos propsitos. Y a todas estas tcnicas se les ha dado en llamar Arquitectura de Software. Una Arquitectura de Software, tambin denominada Arquitectura lgica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construccin del software para un sistema de informacin. La Arquitectura de Software establece los fundamentos para que analistas, diseadores, programadores, etc. trabajen en una lnea comn que permita alcanzar los objetivos del sistema de informacin, cubriendo todas las necesidades.

Desarrollo de proyectos de software

Una arquitectura de software se selecciona y disea con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de informacin, pero no solamente los de tipo funcional, tambin otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interaccin con otros sistemas de informacin. Las restricciones son aquellas limitaciones derivadas de las tecnologas disponibles para implementar sistemas de informacin. Unas arquitecturas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no son aptas para determinadas arquitecturas. La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin ente ellos. Toda arquitectura debe ser implementable en una arquitectura fsica, que consiste simplemente en determinar qu computadora tendr asignada cada tarea. La arquitectura de software, tiene que ver con el diseo y la implementacin de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeo de un sistema, as como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad. En los aos 1960 ya se acariciaba el concepto de arquitectura de software en los crculos de investigacin. No obstante, toma popularidad en los aos 1990 tras reconocerse la denominada crisis del software y como tema de inters de la incipiente disciplina de la ingeniera del software Cada paradigma de desarrollo exige diferente nmero y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura: La visin esttica: describe qu componentes tiene la arquitectura. La visin funcional: describe qu hace cada componente. La visin dinmica: describe cmo se comportan los componentes a lo largo del tiempo y como se almacenan. Las vistas o modelos de una arquitectura pueden expresarse mediante uno o varios lenguajes. El ms obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas de estado, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje nico para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de informacin (o expresarlas de manera incomprensible).

Desarrollo de proyectos de software

Arquitecturas ms comunes

Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de informacin. Lo habitual es adoptar una arquitectura conocida en funcin de sus ventajas e inconvenientes para cada caso en concreto. As, las arquitecturas ms universales son: Monoltica. Donde el software se estructura en grupos funcionales muy acoplados. Cliente-servidor. Donde el software reparte su carga de cmputo en dos partes independientes pero sin reparto claro de funciones. Arquitectura de tres niveles. Especializacin de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentacin (interfaz de usuario), otra para el clculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). La arquitectura 4+1 vistas Todos hemos visto muchos libros y artculos donde se intenta capturar todos los detalles de la arquitectura de un sistema usando un nico diagrama. Pero si miramos cuidadosamente el conjunto de cajas y flechas que muestran estos diagramas, resulta evidente que sus autores han trabajado duramente para intentar representar ms de un plano que lo que realmente podra expresar la notacin. Es acaso que las cajas representan programas en ejecucin? O representan partes del cdigo fuente? O computadores fsicos? O acaso meras agrupaciones de funcionalidad? Las flechas representan dependencias de compilacin? O flujo de control? Generalmente es un poco de todo. El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Tal como se muestra en la Figura 1.1, cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. La vista lgica describe el modelo de objetos del diseo cuando se usa un mtodo de diseo orientado a objetos. Para disear una aplicacin muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algn otro tipo de vista lgica, tal como diagramas de entidad-relacin. La vista de procesos describe los aspectos de concurrencia y sincronizacin del diseo. La vista fsica describe el mapeo del software en el hardware y refleja los aspectos de distribucin. La vista de desarrollo describe la organizacin esttica del software en su ambiente de desarrollo.

Desarrollo de proyectos de software

10

Los diseadores de software pueden organizar la descripcin de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista. La arquitectura evoluciona parcialmente a partir de estos escenarios. Arquitectura del software = {Elementos, Formas, Motivacin/Restricciones} Para cada vista definimos un conjunto de elementos (componentes, contenedores y conectores), captamos la forma y los patrones con que trabajan, y captamos la justificacion y las restricciones, relacionando la arquitectura con algunos de sus requisitos. Cada vista se describe en lo que llamamos diagrama que usa su notacin particular. Los arquitectos tambin pueden usar estilos de arquitectura para cada vista, y por lo tanto hacer que coexistan distintos estilos en un mismo sistema. La arquitectura del software se trata de abstracciones, de descomposicin y composicin, de estilos y esttica. Tambin tiene relacin con el diseo y la implementacin de la estructura de alto nivel del software. Los diseadores construyen la arquitectura usando varios elementos arquitectnicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, as como tambin otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema.

Figura 1.1: Modelo de 4+1 vistas

Desarrollo de proyectos de software

11

La Arquitectura Lgica La arquitectura lgica apoya principalmente los requisitos funcionales lo que el sistema debe brindar en trminos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas (principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aqu se aplican los principios de abstraccin, encapsulamiento y herencia. Esta descomposicin no slo se hace para potenciar el anlisis funcional, sino tambin sirve para identificar mecanismos y elementos de diseo comunes a diversas partes del sistema. La Vista de Procesos La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribucin, integridad del sistema, de tolerancia a fallas. La vista de procesos tambin especfica en cul hilo de control se ejecuta efectivamente una operacin de una clase identificada en la vista lgica. Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tcticamente (comenzar, recuperar, reconfigurar, y detener). Adems, los procesos pueden replicarse para aumentar la distribucin de la carga de procesamiento, o para mejorar la disponibilidad. Particin. El software se particiona en un conjunto de tareas independientes: hilo de control separado que puede planificarse para su ejecucin independiente en un nodo de procesamiento. Podemos entonces distinguir: tareas mayores son elementos arquitectnicos que pueden ser manejados en forma univoca. Se comunican a travs de un conjunto bien definido de mecanismos de comunicacin inter-tarea: servicios de comunicacin sncrona y asincrnica basados en mensajes, llamados a procedimientos remotos, difusin de eventos, etc. Las tareas mayores no debieran hacer suposiciones acerca de su localizacin con otras tareas dentro de un mismo proceso o un mismo nodo de procesamiento. tareas menores son tareas adicionales introducidas localmente por motivos de implementacin tales como actividades cclicas, almacenamiento en un buffer, time-out, etc.). Pueden implementarse en Ada por ejemplo, o como hilos de control liviano (threads). Pueden comunicarse mediante rendezvous o memoria compartida. El flujo de mensajes y la carga de procesos pueden estimarse en base al diagrama de procesos. Tambin es posible implementar una vista de procesos vaca, con cargas dummy para los procesos y medir entonces su performance en el sistema objetivo.

Desarrollo de proyectos de software

Vista de Desarrollo

12

La vista de desarrollo se centra en la organizacin real de los mdulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeas bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o un grupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores. La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, administracin del software, reutilizacin y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programacin que se use. La vista de desarrollo apoya la asignacin de requisitos y trabajo al equipo de desarrollo, y apoya la evaluacin de costos, la planificacin, el monitoreo de progreso del proyecto, y tambin como base para analizar reus, portabilidad y seguridad. Es la base para establecer una lnea de productos. La vista de desarrollo de un sistema se representa en diagramas de mdulos o subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa slo puede describirse completamente cuando todos los elementos del software han sido identificados. Sin embargo, es posible listar las reglas que rigen la arquitectura de desarrollo particin, agrupamiento, visibilidad antes de conocer todos los elementos. Arquitectura Fsica Mapeando el software al hardware La arquitectura fsica toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (rendimiento), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados redes, procesos, tareas y objetos requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mnimo sobre el cdigo fuente en s. Escenarios Todas las partes juntas Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjunto pequeo de escenarios relevantes instancias de casos de uso ms generales para los cuales describimos sus scripts correspondientes (secuencias de interacciones entre objetos y entre procesos. Los escenarios son de alguna manera una abstraccin de los requisitos ms importantes. Su diseo se expresa mediante el uso de diagramas de escenarios y diagramas de interaccin de objetos.

Desarrollo de proyectos de software

Esta vista es redundante con las otras (y por lo tanto +1), pero sirve a dos propsitos principales:

13

Como una gua para descubrir elementos arquitectnicos durante el diseo de arquitectura tal como lo describiremos ms adelante Como un rol de validacin e ilustracin despus de completar el diseo de arquitectura, en el papel y como punto de partido de las pruebas de un prototipo de la arquitectura. Correspondencia entre las Vistas Las distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista estn conectados a los elementos de las otras vistas siguiendo ciertas reglas y heursticas de diseo. De la vista lgica a la vista de procesos. Identificamos varias caractersticas importantes de las clases de la arquitectura lgica: Autnoma: Los objetos son activos, pasivos o protegidos? Un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus propias operaciones, y tiene el control completo sobre la invocacin de sus operaciones por parte de otros objetos. Un objeto pasivo nunca invoca espontneamente ninguna operacin y no tiene ningn control sobre la invocacin de sus operaciones por parte de otros objetos. Un objeto protegido nunca invoca espontneamente ninguna operacin pero ejecuta cierto arbitraje sobre la invocacin de sus operaciones. Persistencia: Los objetos son permanentes o temporales? Qu hacen ante la falla de un proceso o un procesador? Subordinacin: La existencia o persistencia de un objeto depende de otro objeto? Distribucin: Estn el estado y las operaciones de un objeto accesibles desde varios nodos de la arquitectura fsica, y desde varios procesos de la arquitectura de procesos? En la vista lgica de la arquitectura consideramos que cada objeto es activo y potencialmente concurrente, teniendo comportamiento en paralelo con otros objetos, y no prestamos ms atencin al grado preciso de concurrencia que requerimos para alcanzar este efecto. Por lo tanto, la arquitectura lgica tiene en cuenta slo el aspecto funcional de los requisitos.

Desarrollo de proyectos de software

14

Sin embargo, cuando definimos la arquitectura de procesos, implementar cada objeto con su propio thread de control (e.g., su propio proceso Unix o tarea Ada) no es muy prctico en el estado actual de la tecnologa debido a la gran sobrecarga que esto impone. Ms an, si los objetos son concurrentes, debera haber alguna forma de arbitraje para invocar sus operaciones. Por otra parte, se requieren mltiples threads de control por varias razones: Para reaccionar rpidamente a ciertas clases de estmulos externos, incluyendo eventos relativos al tiempo Para sacar partido de las mltiples CPUs en un nodo, o los mltiples nodos en un sistema operativo Para aumentar la utilizacin de la CPU, asignando la CPU otras actividades mientras algn thread de control est suspendido esperando que otra actividad finalice (e.g., acceso a cierto dispositivo externo, o acceso a otro objeto activo) Para priorizar actividades (y potencialmente mejorar la respuesta) Para apoyar la escalabilidad del sistema (con procesos adicionales que compartan la carga) Para separar intereses entre las diferentes reas del software Para alcanzar una mayor disponibilidad del sistema (con procesos de backup)

De la lgica al desarrollo. Una clase se implementa generalmente como un modulo, por ejemplo un tipo de la parte visible de un paquete. Las clases grandes se descomponen en mltiples paquetes. Colecciones de clases ntimamente relacionadas categoras de clases se agrupan en subsistemas. Deben tambin considerarse otras restricciones para la definicin de subsistemas tales como la organizacin del equipo de desarrollo, el tamao esperado del cdigo (tpicamente 5K a 20K SLOC por subsistema), grado de reso y comparacin esperado, principio de distribucin en capas (visibilidad), polticas de liberacin, y administracin de la configuracin. Por lo tanto, generalmente terminamos con una vista que no tiene necesariamente una relacin uno a uno con la vista lgica. Las vistas lgica y de desarrollo son muy cercanas, aunque se refieren a distintos asuntos. Hemos encontrado que cuanto mayor es el proyecto, mayor es tambin la distancia entre estas dos vistas. Similarmente para las vistas de procesos y fsica: cuanto mayor el proyecto, mayor es la distancia entre estas vistas.

Confeccionando el Modelo No toda arquitectura de software requiere las 4+1 vistas completas. Las vistas que no son tiles pueden omitirse de la descripcin de arquitectura, tales como la vista fsica si hay un nico procesador, y la vista de procesos si existe un solo proceso o programa. Para sistemas muy pequeos, es posible que las vistas lgica y de desarrollo sean tan similares que no requieran descripciones independientes. Los escenarios son tiles en todas las circunstancias.

Desarrollo de proyectos de software

1.2 Desarrollo orientado a objetos. Enfoque de Orientacin a Objetos

15

El enfoque de orientacin a objetos es una forma de observar la realidad. El enfoque como su nombre lo indica se basa en el concepto de objeto: Es todo aquello que tiene caractersticas que lo hacen nico e indivisible dentro del entorno al que pertenece. Siempre es posible establecer propiedades o atributos de un objeto, lo mismo que su grado de respuesta a estmulos externos (comportamientos del objeto). Normalmente interactuamos con todo tipo de objetos a nuestro alrededor y los percibimos tal cual por sus caractersticas y su respuesta ante el entorno. Un elemento notable es que las caractersticas de un objeto pueden ser por s mismas otros objetos. La orientacin a objetos promete mejoras de amplio alcance en la forma de diseo, desarrollo y mantenimiento del software ofreciendo una solucin a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo que es difcil de modificar, ciclos de desarrollo largos y tcnicas de codificacin no intuitivas. Un lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas bsicas: basado en objetos, basado en clases y capaz de tener herencia de clases.

El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organizacin. Esta definicin especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto nmero de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organizacin jerrquica o de otro tipo. Estructura de un Objeto

Un objeto puede considerarse como una especie de cpsula dividida en tres partes: 1. RELACIONES. Las relaciones permiten que el objeto se inserte en la organizacin y estn formadas esencialmente por punteros a otros objetos. 2. PROPIEDADES Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organizacin 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 organizacin. 3. METODOS. Los mtodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarn incorporados en forma de programas (cdigo) que el objeto es capaz de ejecutar y que tambin pone a disposicin de sus descendientes a travs de la herencia.

Desarrollo de proyectos de software

Clases e Instancias

16

Dentro de la definicin de objetos hay algunos que sern muy parecidos ya sea que comparten la misma definicin de caractersticas. Una clase es una ayuda notacional en el anlisis para establecer las propiedades y funciones que sern comunes a todos los objetos que se generen a partir de ella, tal y como lo muestra la figura 1.2.

Figura 1.2 Clase en notacin UML En la notacin de la metodologa UML se utiliza un rectngulo con tres divisiones para definir una clase. En la primera se indica el nombre de la clase, la segunda contendr todas las propiedades del objeto y la tercera contiene las funciones por media de las cuales el objeto responde a estmulos de su entorno. En el enfoque orientado a objetos, todos los objetos se generan a partir de clases. Incluso cuando solo se genere uno, de forma que todo objeto est asociado a la clase a partir de la que se gener y se dice que dicho objeto es una instancia de clase que puede usar directamente las caractersticas y funciones asociadas a la clase. La clase es un elemento conceptual que permite definir y modelar, el objeto o instancia de clase es una ejemplificacin de clase. Una instancia de clase tiene valores de atributos y puede invocar sus mtodos.

Desarrollo de proyectos de software

Encapsulamiento

17

Cuando interactuamos con un objeto nicamente nos interesa conocer las caractersticas y atributos que nos permiten establecer dicha interaccin, es decir el objeto publica ciertas caractersticas y mtodos, pero encapsula las dems ya que no es fundamental para el exterior conocerlas para poder interactuar con el objeto. nicamente se requiere conocer aquellas que se exhiban como pblicas. Polimorfismo El polimorfismo se define como la caracterstica de que un objeto que pide la ejecucin de una funcin a otro objeto no necesita saber la naturaleza del objeto dueo de la funcin. El polimorfismo ms comn lo tenemos en un operador como el de suma o multiplicacin, ya que la operacin se realiza aun cuando los operndoos sean distintos. La implementacin del operador tiene el cuidado de hacer correctamente la operacin para el tipo de datos que est participando como se muestra en la figura 1.3.

Figura 1.3. La clase animal y las subclases len y pjaro. Polimorfismo

Herencia El concepto de herencia va asociado a la Generalizacin Especializacin- en el que se establece que cierta clase de objetos puede tener clases de objetos ms especializados las cuales por ser especializaciones, tendrn todos los elementos de la clase genrica y modificarn la funcionalidad heredada o agregarn nueva funcionalidad para especializarse. En la notacin UML la relacin de herencia entre dos clases se indica por medio de una flecha hueca que apunta a la clase ascendiente, esto es porque, en una relacin de herencia el padre no se construye teniendo en cuenta que se pueden derivar de l clases ms especializadas. Por otro lado las clases que son descendientes es importante que sepan quin es su ascendiente pues de l estn tomando propiedades y funciones. Ejemplo de herencia la figura 1.4.

Desarrollo de proyectos de software

18

Figura1.4. Herencia de clase Las clases que no generan directamente instancias se denominan abstractas, y aquellas que generan directamente objetos se les denominan concretas. Asociaciones estticas Permiten la estructuracin de los objetos incorporando reglas del negocio. En su forma ms simple es un vnculo entre dos objetos. Al nivel de anlisis se documentan como vnculos entre clases, sin embargo, es importante recordar que las clases son definiciones generales de un tipo de objeto, lo que implica que no son colecciones de objetos y por lo tanto las asociaciones estticas no son asociaciones entre conjuntos de objetos como se pueden dar en el modelo Entidad Relacin tradicional. La asociacin se indica con una lnea uniendo a las dos clases. La lnea puede tener una etiqueta que indique la forma en la que se est interpretando la asociacin. Muchas reglas del negocio se refieren a los niveles mximos y mnimos de vinculacin entre distintos objetos de la aplicacin. Por ejemplo, un objeto Cliente solo debe estar asociado a un solo agente de Ventas, aunque un Agente Vendedor puede estar vinculado a ms de un cliente. Este tipo de informacin es la multiplicidad o cardinalidad de la asociacin y se indica colocando un rango en los extremos de la asociacin. Existen casos en los que una clase se asocia con ms de una clase, en donde es conveniente no slo mostrar la multiplicidad, sino tambin cmo el analista concibe el vnculo de la clase en cada asociacin. En estos casos se le define un rol a la clase en a cada asociacin que participa como se muestra en la figura 1.5.

Figura 1.5: Asociaciones estticas

Desarrollo de proyectos de software

Asociaciones de agregacin o composicin.

19

Un caso particular de asociacin esttica, es cuando se encuentra que un objeto no slo est asociado con otro, sino que adems uno es parte del otro. Este tipo de situacin se le llama asociacin de agregacin. La agregacin podemos establecerla en dos tipos: por composicin y por agregacin simple como se muestra en la figura 1.6. En la primera, los objetos y la asociacin se dieron simultneamente y cuando desaparezca un objeto, el otro tambin desaparecer, as como la asociacin. Por lo regular se da cuando modelamos un objeto como propiedad de otro objeto.

Figura 1.6 Agregacin y composicin. La agregacin simple es la ms comn y se da cuando tenemos documentos, tales como facturas, rdenes de entrada de almacn, recibos de pago, etc. Ya que el documento es el objeto central y tiene una serie de caractersticas con cierto grado de opcionalidad, que hacen no necesiten estar los dos para que la agregacin se d. En UML la agregacin se denota con un rombo en el extremo de la asociacin en donde se encuentra la clase a la que se le estn agregando objetos. La agregacin por composicin se denota con el rombo slido, mientas que la agregacin simple es con el rombo vaco. En general es conveniente indicar las asociaciones de agregacin pues sugieren que las operaciones de mantenimiento a esos objetos tienen que hacerse dentro de una misma transaccin, lo cual ayuda a identificar la complejidad de los modelos de objetos que se estn obteniendo. Siempre ser ms fcil dar mantenimiento a una familia de objetos que a dos o ms familias de objetos como lo sugieren las asociaciones de agregacin.

Desarrollo de proyectos de software

20

1.3 Diagramacin Modelos. Un modelo representa a un sistema software desde una perspectiva especfica. Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes: Diagrama de Estructura Esttica. Diagrama de Casos de Uso. Diagrama de Secuencia. Diagrama de Colaboracin. Diagrama de Estados.

Diagramas de clases Los diagramas de clases proporcionan una perspectiva esttica del sistema (representan su diseo estructural), son los bloques de construccin ms importantes de cualquier sistema orientado a objetos y es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Como muestra la Figura 1.7 Esta notacin (UML) permite visualizar una abstraccin independientemente de cualquier lenguaje de programacin especfico y de forma que permite resaltar las partes ms importantes de una abstraccin: su nombre, sus atributos y sus operaciones.

Desarrollo de proyectos de software

21

Figura 1.7: Clase Cada clase ha de tener un nombre que la distinga de otras clases. El Nombre es una cadena de texto. Ese nombre slo se denomina nombre simple. Una clase puede dibujarse mostrando slo su nombre. 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 operacin es la implementacin de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento, En otras palabras, 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 o ninguna, en la figura 1.8 muestra el diagrama completo del dominio conceptual de una aplicacin.

Desarrollo de proyectos de software

22

Figura. 1.8. Diagrama de clases Diagrama de Casos de Uso. Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior como se muestra en la figura 1.9. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea.

Desarrollo de proyectos de software

23

Figura 1.9: Diagrama de casos de uso Diagramas de Interaccin. En los diagramas de interaccin se muestra un patrn de interaccin entre objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la misma informacin, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboracin. Un diagrama de Secuencia muestra una interaccin ordenada segn la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo. Figura 1.10.

Desarrollo de proyectos de software

24

Figura 1.10: Diagrama de secuencia Un Diagrama de Colaboracin muestra una interaccin organizada basndose en los objetos que toman parte en la interaccin y los enlaces entre los mismos (en cuanto a la interaccin se refiere vase figura 1.11). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboracin muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecucin concurrentes deben determinarse explcitamente mediante nmeros de secuencia.

Figura 1.11: Diagrama de colaboracin

Desarrollo de proyectos de software

25

En cuanto a la representacin, un Diagrama de Colaboracin muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que circulan, y con el nombre del mensaje y los parmetros (si los tiene) entre parntesis. Cada mensaje lleva un nmero de secuencia que denota cul es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva nmero de secuencia. Se pueden indicar alternativas con condiciones entre corchetes. Diagramas de Estado. Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En l se indican qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera. En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transicin se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado vase figura 1.12. El segundo compartimento es opcional, y en l pueden aparecer acciones de entrada, de salida y acciones internas.

Figura 1.12: Diagrama de Estados Modelado Fsico De Un Sistema OO. Componentes. Los componentes pertenecen al mundo fsico, es decir, representan un bloque de construccin al modelar aspectos fsicos de un sistema. Una caracterstica bsica de un componente es que debe definir una abstraccin precisa con una interfaz bien definida, y permitiendo reemplazar fcilmente los componentes ms viejos con otros ms nuevos y compatibles.

Desarrollo de proyectos de software

26

En UML todos los elementos fsicos se modelan como componentes. UML proporciona una representacin grfica para estos como se puede ver en la Figura 1.13, en la que XXXX.dll, es el nombre del componente.

Figura 1.13. Componente fsico Cada componente debe tener un nombre que lo distinga de los dems. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la Figura1.14.

Figura 1.14. Componente fsico especifico. Agrupacin de Elementos Mediante Paquetes Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Cualquier grupo de elementos, sean estructurales o de comportamiento, puede incluirse en un paquete. Incluso pueden agruparse paquetes dentro de otro paquete. Un paquete se representa como un rectngulo grande con un pequeo rectngulo sobre la esquina superior izquierda a modo de lengeta. Si no se muestra el contenido del paquete entonces el nombre del paquete se coloca dentro del rectngulo grande. Si, por el contrario, se quiere mostrar el contenido del paquete, entonces el contenido va dentro del rectngulo grande y el nombre del paquete va en la lengeta.

Desarrollo de proyectos de software

27

Figura 1.15. Agrupacin por Paquetes. Se pueden indicar relaciones de dependencia entre paquetes mediante una flecha con la lnea a trazos. Como se muestra en la figura 15.