Instituto Tecnolgico Superior de

Felipe Carrillo Puerto.

Ingeniera en Sistemas Computacionales. Desarrollo de Proyectos de Software.
Ing. Eduardo Castillo Moo

Unidad I Conceptos Introductorios.

Inv. Desarrollo Orientado A Objetos y Diagramas UML: Clasificacin y Tipos. Alumno: Moo Poot Francisco Javier.

Noveno Semestre Grupo: B, ISC, I4

Felipe Carrillo Puerto, Q. Roo a Martes 10 de sept. 2013

Desarrollo de Proyectos de Software.

Introduccin.

El software es algo indispensable en nuestra vida diaria que de manera general se entiende como programas de computadora. Cuando se va a construir un sistema de software es necesario conocer un lenguaje de programacin, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solucin sea cuidadosamente diseada. Se debe seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis y el diseo, y cmo se relacionan los productos de ambos, entonces la construccin de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas.

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 mucha otra rea 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.

Desarrollo Orientado A Objetos.

El desarrollo orientado por objetos es una nueva forma de pensar acerca del software basado sobre abstracciones que existen en el mundo real. En este contexto, el desarrollo es referido a la primera parte del ciclo de vida del software: anlisis, diseo e implantacin El mtodo de desarrollo orientado a objetos no fija una metodologa estricta, sino que define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse segn las condiciones del proyecto que se est llevando a cabo. Este proceso aplica los ltimos avances en Ingeniera del Software, y adopta un enfoque eminentemente prctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportacin consiste en atar los cabos sueltos que anteriores mtodos dejan.

La notacin que se usa es la proporcionada por UML, que se ha convertido en el estndar en cuanto a notacin orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentacin, pues es de esperar que cualquier desarrollador experto en orientacin a objetos conozca y use UML (o se est planteando su uso).

El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. As no se pierde de vista la motivacin principal que debera estar en cualquier proceso de construccin de software: el resolver una necesidad del usuario/cliente.

Enfoque de Orientacin a Objetos.

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). 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 3

Desarrollo de Proyectos de Software.

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 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.

Clasificacin. Objetos.
Un objeto es una entidad fsica o abstracta que tiene un comportamiento antes ciertos estmulos, tanto externos como de otros objetos especficos que se encuentran dentro del sistema. 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. Mtodos. 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. Qu se puede considerar como objeto? Persona Equipo Hardware

Desarrollo de Proyectos de Software.

Materiales Informacin Software Procesos Procedimientos Relaciones o asociaciones entre objetos Incluso Entes matemticos o lgicos Clases e Instancias 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.

Tipos.
Encapsulamiento. 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.

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. 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.

Diagramas UML.
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar de facto de la industria, debido a que ha sido concebido por los autores de los tres mtodos ms usados de orientacin a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.

Clasificacin.
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. Diagrama de Estructura Esttica o 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.

Figura 1.7: Clase.

Desarrollo de Proyectos de Software.

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.

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.

10

Desarrollo de Proyectos de Software.

Figura 1.9: Diagrama de casos de uso. Diagramas de Secuencia. 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. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o actor tiene una lnea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren. Figura 1.10.

Figura 1.10: Diagrama de secuencia.

11

Desarrollo de Proyectos de Software.

Diagramas de Colaboracin. 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). 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. 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.

12

Desarrollo de Proyectos de Software.

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.

Tipos.
a) Segn Importancia Para poder priorizar los casos de uso que identifiquemos los vamos a distinguir entre: Primarios: Representan los procesos principales, los ms comunes, como Realizar Reintegro en el caso del cajero automtico. Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales como Aadir Nueva Operacin. Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la solucin, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la implementacin. Un caso de uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin. Por el contrario, un caso de uso real describe concretamente el proceso en trminos del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas. Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero automtico tenemos la siguiente descripcin del Curso Tpico de Eventos:

13

Desarrollo de Proyectos de Software.

Accin del Actor 1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en la ranura para tarjetas. 3. Introduce el PIN a travs del teclado numrico. 5. etc.

Respuesta del Sistema 2. Pide el PIN (Personal Identification Number). 4. Presenta las opciones de operaciones disponibles. 6. etc.

En principio, los casos de uso reales deberan ser creados en la fase de Diseo y no antes, puesto que se trata de elementos de diseo. Sin embargo, en algunos proyectos se plantea la definicin de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida. No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de compromiso con el Diseo es un continuo, y una descripcin especfica de un caso de uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros.

14

Desarrollo de Proyectos de Software.

Conclusin.

El desarrollo orientado a objetos y diagramas UML es un mtodo para modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Involucra como en todo proyecto un ciclo o fases dirigidas por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios. As no se pierde de vista la motivacin principal que debera estar en cualquier proceso de construccin de software Hay que tener muy en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan solo se trata de una notacin. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo, a nuevos miembros y compartir con otros equipos la documentacin.

15

Desarrollo de Proyectos de Software.

Fuentes de informacin. Libros: No Medios electrnicos:

http://www.tesoem.edu.mx/alumnos/cuadernillos/2011.009.pdf http://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf http://julleny4801.blogspot.mx/2012/09/12-desarrollo-orientado-objetos.html http://www.pinelo.com/blog/postimgs/2009/03/24/POO.pdf

16