INSTITUTO UNIVERSITARIO DE TECNOLOGA DE ADMINISTRACION INDUSTRIAL REGIN CAPITAL

Integrante: Garcs Carlos C.I: 19.633.962

Conceptos basados en orientado a objetos

Un sistema es un conjunto de elementos que interactan entre si, en un sistema orientado a objetos los elementos toman el nombre de objetos Un sistema de informacin Orientado a Objetos no es Base de datos + programas, sino que es un conjunto de objetos colaborativos donde los objetos persistente son guardados en una Base de Datos. Un objeto:

Posee una identidad, la cual no es una caracterstica del objeto, es definida por el sistema propiamente y no puede ser cambiada. Tiene un estado, este puede ser descrito por las caractersticas (atributos) del mismo. Tiene un comportamiento, el cual puede ser descrito por los mtodos, estos forman parte del objeto y nos sirve como una interfaz para interactuar con el mismo.

Clasificacin: Es la abstraccin de las cualidades comunes. Tipos de objetos Cuando clasificamos los objetos estamos generalizando las propiedades que puede tener el objeto, el tipo de objeto es un patrn para todos los objetos de este tipo y esto se denomina tipo de dato abstracto o ms conocido como clase.

Encapsulamiento :
Los datos y los mtodos para manipular los datos son una sola unidad y estn encapsulados en este objeto, los datos que son parte del objeto pueden ser manipulados nicamente por la invocacin de los mtodos publicados en la interface del objeto. Entonces los datos atributos son descritos junto con la rutina (mtodo) que permite manipularlos.

Ocultamiento de la Informacin. Los detalles de la implementacin de los mtodos son ocultados para los clientes. Herencia. Un tipo de objeto puede tener subtipos los cuales son clases especializadas que heredan los atributos y mtodos de la clase general. Polimorfismo. Una subclase tiene la posibilidad de sobrescribir los mtodos heredados, con esto pueden existir dos clases que a pesar de poseer los mismos atributos e interfaces son diferentes. Persistencia Es preservar el estado de un objeto a travs del tiempo y del espacio (Se lo puede utilizar Base de datos OO)

Qu es UML?
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, disear, configurar, mantener y controlar la informacin sobre los sistemas a construir. UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. Un sistema se modela como una coleccin de objetos discretos que interactan para realizar un trabajo que finalmente beneficia a un usuario externo. El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas actuales en un acercamiento . UML no es un lenguaje de programacin. Las herramientas pueden ofrecer generadores de cdigo de UML para una gran variedad de lenguaje de programacin, as como construir modelos por ingeniera inversa a partir de programas existentes.

Elementos comunes en Diagramas

Notas : Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar informacin en un formato libre, cuando la notacin del diagrama en cuestin no nos permite expresar dicha informacin de manera adecuada. Una nota se representa como un rectngulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una lnea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.

Dependencias : La relacin de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habra que revisar el elemento origen). Una dependencia se representa por medio de una lnea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a l est la flecha).

Antecedentes
El lenguaje UML empez a generarse en octubre de 1994, cuando Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados investigadores en el rea de metodologa del software).

El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT (Object Modelling Tool). El primer borrador apareci en octubre de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la colaboracin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin de la primera versin de UML.

La notacin UML se deriva y unifica las tres metodologas de anlisis y diseos ms extendidas.

Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones. Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodologa de casos de uso (use case).

El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivar Jacobson y su compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE.

De las tres metodologas de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde el OMG, que es tambin el origen de CORBA, el estndar lder en la industria para la programacin de objetos distribuidos.

En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo orientado a objetos. UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un meta-modelo autoreferencial (cualquier lenguaje de modelado de propsito general debera ser capaz de modelarse a s mismo).

Tipos de Diagramas
Diagramas:
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeos subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema. Diagramas de Clases:

Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos diagramas son los ms comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseo esttica o la vista de procesos esttica (s incluyen clases activas). Diagramas de Objetos:
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los diagramas de clases y cubren la vista de diseo esttica o la vista de procesos esttica desde la perspectiva de casos reales o prototpicos.

Diagramas de Casos de Usos: Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista esttica de los casos de uso y son especialmente importantes para el modelado y organizacin del comportamiento. Diagramas de Secuencia y de Colaboracin: Tanto los diagramas de secuencia como los diagramas de colaboracin son un tipo de diagramas de interaccin. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboracin muestran la organizacin estructural de los objetos que envan y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboracin sin perdida de informacin, lo mismo ocurren en sentido opuesto.

Diagramas de Estados: Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboracin. Diagramas de Actividades:

Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Diagramas de Componentes: Muestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista de la implementacin esttica y se relacionan con los diagramas de clases ya que en un componente suele tener una o ms clases, interfaces o colaboraciones Diagramas de Despliegue: Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura y se relacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms componentes.

Diagramas de casos de uso

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del sistema, y con el cliente, y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.

Elementos en los diagramas de casos de uso

Elementos: Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Actores : Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores.

Casos de Uso : Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema.

Relaciones entre Casos de Uso :

Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la documentacin de casos de uso. Para el caso de que queramos utilizar estos casos de uso ms pequeos, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial comn a varios casos de uso.

Diagrama de casos de uso 1

Diagrama de casos de uso 2

Diagrama de casos de uso 3

Diagrama de casos de uso 4

Diagrama de casos de uso 5

Diagrama de casos de uso 6

Diagrama de casos de uso 7

Diagrama de casos de uso 8

Diagrama de casos de uso 9

Pasos para crear casos de uso

Identificar actores: Los actores son mejor dicho, los roles que un usuario o usuarios del sistema llevan a cabo en algn momento del tiempo. Tambin pueden ser otros sistemas con los que el 'sistema' en proceso de modelado tiene interaccin. Ejemplo: Para un sistema de ventas (directas y por catalogo), nuestros actores pueden ser: Vendedor, Cliente, Supervisor de Ventas. Identificar Metas : (Metas, objetivos generales o responsabilidades). Todos los actores en el entorno a modelar tienen metas u objetivos, o en su defecto responsabilidades, o en su defecto, acciones que desean realizar u obtener del sistema. Por ejemplo: Para el sistema de Ventas, el Vendedor tiene como meta, objetivo o responsabilidad (Ofrecer productos, Cerrar Venta, Ganar mucho dinero va Cobrar comisiones).

Obtener o identificar los Casos de Uso a partir de las Metas:

Las metas son importantes porque a partir de su identificacin pasamos a realizarlas y estas se convierten en los Casos de Uso, de esta forma tan sencilla obtenemos la informacin de funcionalidad que requiere nuestro sistema. Especificar cada Caso de Uso: Una vez identificados seguimos a especificarlos uno a uno, es probable que en el inter, de esos sencillos pasos algunos casos de uso desaparezcan o se fusionen con otros, por ambigedades detectadas o por detalles que se hayan escapado durante el proceso. Es importante recordar que de eso se trata el modelado, no es indispensable que quede al cien por ciento el modelo desde la primera vez, por eso hay que hacerlo en iteraciones o ciclos. La especificacin de los casos de uso contiene varias partes, las fundamentales son Nombre, Descripcin, Actores, Flujo Principal y Flujos Alternos. Este grupo de elementos constituyen lo que se conoce como plantilla (Template), y nos podemos encontrar un sinnmero de plantillas en la red.

Descripcin textual de casos de uso

Herramientas para crear Diagramas

1. 1st chart 2. Jgraphpad 3. yEd- java graph editor 4. Graphviz 5. Unified Modeling Language 6. XML/SWFCharts 7. DIA 8. JFreeCHart 9. Omnigraffle 10. Microsoft Visio 11. Mindjet MindManager 12. SmartDraw

Referencias
http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html http://alvearjofre.galeon.com/ http://www.clikear.com/manuales/uml/index.aspx http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf http://www.lawebdelprogramador.com/cursos/UML/4421Aprendiendo_UML_en_24_horas.html http://softtlan.blogspot.com/2007/03/tutorial-de-casos-de-uso-paso.html
http://cosassencillas.wordpress.com/2007/01/19/herramientas-para-crear-diagramasgraficas-y-diagramas-de-flujo/