manual uml actualizado 2009

Facultad de Ingeniería Industrial y de Sistemas

Modelamiento de Datos Pág. 1

CCAAPPIITTUULLOO 11

Introducción al Análisis y Diseño Orientado a Objetos. Ciclo de Vida del Software. Proceso de desarrollo utilizando UML. Descripción del Proceso Actual: El Modelo de Negocios.

Universidad Nacional de Ingeniería

Pág. 2 Modelamiento de Datos

I N T R O D U C C I Ó N A L A N Á L I S I S Y D I S E Ñ O

O R I E N T A D O A O B J E T O S .

Últimamente escuchamos con frecuencia los términos POO, AOO, DOO, BDOO.Existen evidencias de que la industria informática está dirigiéndose en conjunto a laTecnología Orientada a Objetos, alejándose de la tecnología estructurada que haprevalecido por más de 20 años. A todo esto le añadimos la proyección del desarrollode aplicaciones para Internet, denominados Intranets, Extranets y otros, usandojustamente esta tecnología.

La Tecnología Orientada a Objetos es un nuevo enfoque sobre la manera de organizarlas diferentes piezas que componen un sistema de información (software), como en elhardware (equipo físico), la base de datos e incluso, en organizaciones todas estaspiezas se denominan "objetos", los cuales son pequeños subsistemas independientescon datos propios sobre estos elementos y sus clases y tipos, rigen tales propiedadescomo herencia, comunicación con lenguajes, polimorfismos y otros que en conjuntopermiten ventajas prácticas.

Estas están incluidas en las versiones orientadas a objetos de metodología paraanálisis y diseño de programación y base de datos. Con esto, nos hemos referido a latecnología orientada a objetos aplicada a software. Sin embargo este enfoque tambiénes aplicado en la construcción de hardware, así como también es válido en el diseñoorganizativo.

La TOO se fundamenta en el proceso de construcción y utilización de conocimientos,por lo tanto, objetos y clases son los pasos más importantes en la búsqueda de unanueva revolución que reemplace, esta vez, parte del esfuerzo que implica laorganización y utilización del conocimiento, del mismo modo que en la primera, lasmáquinas reemplazaron el esfuerzo físico del hombre y de los animales, permitiendo elvertiginoso avance del mundo.

El Desarrollo de la Estructura del Pensamiento y laConstrucción del Conocimiento

Desde muy temprana edad, aproximadamente hasta los siete años, en losdenominados períodos Senso-motriz y Preparatorio de la inteligencia, en los que seafirma el esquema del objeto permanente, los seres humanos, a partir de laexperiencia de la observación y captación de cosas y hechos del mundo que nosrodea, construimos conceptos "concretos". Estos nos permiten ser consistentes yrazonar. Por ejemplo: Pelusa es un elemento del mundo real que es conceptualizadocomo Pelusa. En él almacenamos sus características (DATOS), por ejemplo: tienepelos, cuatro patas, dos orejas, dos años de edad, es de color blanco, otros. Junto conlos datos también almacenamos sus acciones (COMPORTAMIENTO), es decir, lo quepuede o no hacer (ladrar, correr, saltar, comer, etc.). Como consecuencia de estehecho (almacenamiento de los datos y comportamiento en una sola unidadconceptual), entre las muchas operaciones de nuestra mente, podemos razonar quePelusa no tiene alas, ni plumas, ni puede volar.



A las acciones que, cualquier elemento del mundo real, realiza como reacción frente aun estímulo las denominaremos Operaciones. Algunos comportamientos complejosson el resultado de la interacción o sucesión de varias operaciones, a éstos losdenominaremos Procesos. Sin embargo en nuestro enfoque, en la mayoría de loscasos y de manera genérica utilizaremos el término OPERACION.

Los conceptos se construyen modelando los aspectos y características de cualquierobjeto real, extrayendo los detalles (datos y comportamiento) necesarios ydescartando lo menos útil. Este proceso, natural en los seres humanos, compuesto pordiversas operaciones tales como observar, captar, fijar, comparar, conceptualizar yotros son denominados abstracción.

Cuando pensamos en un auto, no visualizamos cada mínimo detalle que lo describa,lo más probable es que tengamos en mente sólo las principales características físicasy, dependiendo de nuestra experiencia, algunos de los subsistemas importantes comola caja de cambios, o los sistemas de dirección y frenos.

En Tecnología Orientado a Objetos (TO) a los conceptos se les llama objetos, enconsecuencia, los OBJETOS son MODELOS de entes del mundo real. Los percibimosporque tienen límites que los esperan de su medio ambiente y de los demás(IDENTIDAD). Se encuentran en un ESTADO específico en el mundo.

Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo;pero siempre estará compuesto de DATOS y OPERACIONES.

En los siguientes ejemplos podemos reconocer sus componentes y entender porquéson objetos:

Un libro, una factura, una organización Una figura en un programa para dibujar Una pantalla con la cual el usuario interactúa Un campo o nodo en la pantalla de una herramienta CASE Un avión, el vuelo de un avión, una reserva de avión Un icono en la pantalla, a la que se puede señalar y abrir

Continuando con el desarrollo de la estructura del pensamiento, encontraremos queaproximadamente a partir de los siete años, en la denominada etapa de lasoperaciones concretas, el ser humano aprende a CLASIFICAR (separar y agruparobjetos de acuerdo a características y comportamientos comunes) y ORDENAR(establecer criterios de jerarquía que permitan la organización).

Por ejemplo: conocemos a Pluto y Valentino, y descubrimos que también tienen cuatropatas, ladran, muerden, etc. Y a partir de estos conceptos "concretos" formamos unnuevo concepto "abstracto" al que denominamos PERRO. Este contiene lascaracterísticas y el comportamiento de todos los semejantes a Pelusa. En otraspalabras, construimos conceptos tipos o Modelos.

Así construiremos los modelos GATO, CONEJO, y aún sin la experiencia directa de laobservación, TIGRE, ORNITORRINCO, etc. Este proceso es una consecuencia de lafunción simbólica (imitación diferida, juegos simbólicos, etc.).



De estos modelos se construirán otros, cada vez más abstractos, que contendrán a losanteriores, por ejemplo: CARNIVOROS, MAMIFEROS, VERTEBRADOS, ANIMALES,SERES VIVOS, etc. generándose una estructura muy organizada de CLASIFICACIONY ORDEN.

La clasificación es un medio por el cual organizamos elconocimiento.

Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemasrepresentativos (MODELOS), los cuales permiten: por un lado, reconocer si unconcepto (OBJETO) tiene o no las características de dicho esquema; y por otro,incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE).Posteriormente organizamos jerárquicamente en clases y superclases, construyendoen forma progresiva las grandes CLASIFICACIONES y las OPERACIONES DEORDEN.

Después de los doce años, en la etapa de las Operaciones combinatorias de lainteligencia (Pensamiento formal), el hombre construye SISTEMAS y aún TEORIAScomo producto del raciocinio de Hipótesis (propuestas de solución a interrogantes oproblemas), y de la representación en dimensiones simultáneas.

Un Sistema es un conjunto de componentes (conceptos y modelos, y aún de otrossistemas) que interactúan, en distintos planos, entre sí para alcanzar objetivosespecíficos. Cada Sistema construido es una manera de solucionar los diferentesproblemas que enfrenta el hombre a lo largo de su existencia, por ejemplo el Lenguaje,uno de los sistemas más elaborados, permite satisfacer la necesidad vital de lacomunicación.

Cuando un sistema tiene por objetivo explicar un hecho o fenómeno, y es aceptado,mientras no se demuestre lo contrario, u otro sistema lo explique mejor, se ledenomina TEORIA. Por ejemplo, la teoría de la relatividad, la teoría del conocimiento,etc.

En síntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma enque los seres humanos captamos el mundo real y operamos en él. La tecnología deObjetos intenta simular este hecho y sus fundamentos se sostienen en él.

A continuación desarrollaremos los tres más importantes:

SIMULACIÓN.

Representación directa de elementos que "maneja" el usuario en el mundo real.Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino derepresentarlo directamente. Por ello, en este enfoque, primero se identifican lascaracterísticas de los elementos del mundo real, los que se organizan en lasdenominadas ESTRUCTURAS DE DATOS. Luego se captan los comportamientos uoperaciones, los cuales se imitan o simulan mediante pequeños programas(procedimientos) a los que en adelante denominaremos METODOS. Y así como en lavida real conceptualizamos en una sola unidad (datos y comportamiento), en TO



simulamos este hecho colocando en una especie de "cápsula" las estructuras de datosy los métodos, a esta unidad denominamos OBJETO.

También se simula la manera en que los entes del mundo real se comunican entre sí,enviándose señales o "mensajes" a los que responden con una conducta ocomportamiento específico, de la misma manera se simulan las clasificaciones,ordenamiento, organización, e incluso la herencia de los seres vivos.

En síntesis, se trata de actuar de la misma manera en que los humanos, a los que eninformática, en general, se nos denomina usuarios, "manejamos" y operamos elmundo real.

ENCAPSULAMIENTO.

Utilización del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetardatos y operaciones en forma conjunta se llama ENCAPSULACION.

La encapsulación es el resultado (o acto) de ocultar, al usuario, los detalles de laimplementación de un objeto. El objeto oculta sus datos a otros objetos y sólo permiteaccesar a sus datos vía sus propios métodos mediante mensajes específicos, es decir,se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llamaocultamiento de información. La encapsulación protege los datos de un objeto de lacorrupción. Si todos los programas pudieran accesar a los datos (como actualmentesucede con la tecnología estructurada), fácilmente puede corromperse o perderse. Laencapsulación protege los datos del objeto del uso arbitrario y no intencionado. Así lacreación está protegida y la competencia garantizada.

La encapsulación tiene dos beneficios primordiales:

MODULARIDAD. El código de un objeto puede ser escrito y se puede mantenerindependiente del código de otros objetos. Un objeto se puede mover de sistema ensistema, se puede quitar, modificar y volver a colocar sin alterar el sistema general.

ESCONDER LA INFORMACIÓN ( INFORMATION HIDING ). Un objeto tiene una interfaz con laque otros objetos se pueden comunicar, pero puede mantener información privadapara sí misma que puede cambiar en cualquier momento, sin afectar a los objetos quedependen de ésta

REUTILIZACION.

Capacidad de reutilizar código sin alterarlo, programando solo lo adicional o diferente.Base de la Herencia.

Durante la vida de un sistema, las estructuras de datos se mantienen relativamenteestables, mientras que las operaciones sobre dichas estructuras cambian,dependiendo de situaciones. Por ello en el Análisis y Diseño Orientado a Objetos, seda énfasis primordial a los DATOS y al COMPORTAMIENTO de los objetos y tipos deobjetos (modelos).Los datos, como son relativamente estables, pueden ser utilizadosmuchas veces, modificando únicamente aquello que sea necesario para tal o cualsituación, en la misma forma se procede con los comportamientos. En cambio, en el



Análisis y Diseño Estructurado, se da énfasis a la descomposición funcional orientadaal proceso, en consecuencia, cualquier modificación requiere de una reconstrucción,normalmente, a partir de cero.

Conceptos Básicos

La ingeniería de software comprende las técnicas de desarrollo formal para el diseñode software. Problemas frecuentes del software tales como: Aumento de lacomplejidad, cambios continuos, no confiable, dificultad para verificarlo, dificultad paraespecificar los requerimientos, Estas son algunas de las razones por lo cual laprogramación orientada a objetos sea tan popular.

¿Qué son los objetos? ¿Qué no son los objetos?Objetos son "cosas": Space shuttle,empleado, paciente, casa, carro, objetoempleado, puede ser simple o complejo,puede ser real o imaginario.

Si tomamos como ejemplo el Objetocarro. Atributos de un objeto: velocidad,color, tamaño. Funciones del objeto: ir,parar, girar a la derecha, girar a laizquierda.

ENCAPSULAMIENTO DE OBJETOS

El encapsulamiento es combinar las funciones relacionadas, atributos y estados paraformar "objetos". El encapsulamiento implica autocontinencia, por ejemplo el objeto"Carro" encapsula o "reúne" sus atributos, funciones y estados en una unidadautocontenida, el encapsulamiento usa información oculta. Algunas partes del objetoson visibles a todas es decir, públicas.

La función "steering wul" en el objeto "Carro" representa una interface pública la cual"enciende" el carro. Algunas partes del objeto son ocultas (privadas), "encender" esúnicamente visible a la función "steering wheel", por lo tanto privada.

La información oculta permite al detalle del objeto cambiar sin afectar los programasque usan la clase, la información oculta elimina los problemas que se presentan almodificar el código y promueve la reutilización del código.

ObjetoEs cualquier cosa real o abstracta, acerca de la cualalmacenamos datos y los métodos que controlandichos datos.

Ejm.- una factura, una organización, una figura en unprograma como Corel Draw, una pantalla con la queinteractúa un usuario, un campo o nodo de lapantalla de una herramienta CASE, una avión, todoun plano de ingeniería, el proceso para llenar unpedido, etc. Daniel Ramos también sería un objeto, por las características que posee.



Tipo de ObjetoEs una categoría de un objeto; y un objeto es una instancia de un tipo de objeto.

Ejm.- empleado se aplica a los objetos que son personas empleadas por unaorganización; algunas instancias de empleado podrían ser Viviana Rivasplata, MajuMantilla, etc.

MétodosEspecifican la forma en que se controlan los datos de un objeto. Los métodos en untipo de objeto sólo hacen referencia a las estructuras de datos de ese tipo de objeto.Un objeto es entonces una cosa cuyas propiedades están representadas por tipo dedatos y su comportamiento por métodos.

Ejm.- Un método asociado con el tipo de objeto factura podría ser aquél que calcule eltotal de una factura. Otro podría transmitir la factura a un cliente, etc.

EncapsuladoEl empaque conjunto dedatos y métodos se llamaencapsulado. El objetoesconde sus datos de losdemás objetos y permiteel acceso a los datosmediante sus propiosmétodos, esto recibe elnombre de ocultamientode la información. Elencapsulado evita lacorrupción de los datosde un objeto,protegiéndolos del usoarbitrario y no pretendido.

Ejm.- Un Cajero Automático es un ejemplo de objeto. Tiene tipos específicos decomportamiento. Un “cajero globalnet” es un tipo de objeto y un cajero automáticoindividual sería una instancia de dicho objeto. Todas los Cajeros Automáticos delmismo tipo tienen los mismos métodos. Los cajeros contienen muchos componentescomplejos, la mayoría de los cuales también contienen otros componentes, pero unono necesita conocerlos.

MensajesPara que un objeto haga algo, le enviamos una solicitud, esta hace que se produzcauna operación. El mensaje que constituye la solicitud contiene el nombre del objeto, elnombre de una operación y, a veces, un grupo de parámetros.

Un mensaje es una solicitud para que se lleve a cabo la operación indicada y seproduzca el resultado; en consecuencia, las implantaciones OO se refieren a losmensajes como solicitudes.



Una solicitud invoca una operación específica, con uno o más objetos comoparámetros.

Ejm.- se puede comunicar con el TV al enviarle solicitudes por medio de unsintonizador de control remoto. Responde el aparato mediante determinada acción ypresenta las respuestas en pantalla.

ClaseEl término clase se refiere a la implantación en software de un tipode objeto. Especifica una estructura de datos y los métodosoperativos permisibles que se aplican a cada uno de sus objetos. Elmétodo es parte de la clase, pero no parte del objeto. El método nisiquiera podría ser parte de la clase; pero podría ser parte de laclase de mayor nivel en la jerarquía de clases.

Ejm.- una clase empleado incluiría datos del seguro social, puesto, salario, extensióntelefónica, etc. Además, cada clase define un conjunto de operaciones permisibles quepermiten el acceso y modificación de los datos del objeto.

HerenciaUn tipo de objeto de alto nivelpuede especializarse en tipos deobjeto de bajo nivel. Un tipo deobjeto puede tener subtipos. Unaclase implanta el tipo de objeto.Una sub-clase heredapropiedades de su clase padre;una sub-clase hereda propiedadesde las subclases, etc.

Ejm.- Un tipo de objeto persona puede tener subtipos civil y militar. Militar puede tenersubtipos oficial y subalterno. Oficial puede tener subtipos teniente, capitán, mayor, etc.

Herencia de ClaseEs una implantación de la generalización. La generalización establece que laspropiedades de un tipo se aplican a sus subtipos. La herencia de clase hace que laestructura de datos y operaciones sean disponibles para sus reutilización por parte desus subclases.

PolimorfismoSe aplica a una operación que adopta varias formas de implantación. Una de lasventajas del polimorfismo es que se puede hacer una solicitud de una operación sinconocer el método que debe ser llamado. Estos detalles quedan ocultos para elusuario; la responsabilidad descansa en el mecanismo de selección de la implantaciónOO.

Ave

Ave

Faisan GallinaPato



AbstracciónEs el acto o resultado de eliminar diferencias entre los objetos, de modo que podamosver los aspectos comunes. Todo objeto es único, sin embargo, la abstracción eliminaalgunas distinciones para que podamos ver los aspectos comunes entre los objetos.Se debe considerar lo siguiente:

Características esenciales que distinguen un objeto de otro. Dependen del dominio del problema. Dependen del Observador. Definen conceptos. Distintos tipos: "Entidades" y "Asociaciones".

Un protocolo denota la manera en que un objeto puede actuar y reaccionar.

GeneralizaciónEs el acto o el resultado de distinguir un concepto que es más general que otro. Lageneralización nos permite examinar si los conceptos tienen algo en común.

EventoEs un cambio en el estado de un objeto. En el análisis orientado a objetos el mundo sedescribe en términos de los objetos y sus estados, así como de los eventos quemodifican esos eventos. Así, los eventos sirven como indicadores de los instantes enque ocurren los cambios de estado.

ModularidadEs la propiedad de un sistema que ha sido dividido en componentes. Los módulos sonla división física de la abstracción lógica. Hay que considerar lo siguiente:

Criterios de descomposición: Encapsulación vs. Visibilidad, Reusabilidad ySegmentación; y Necesidades no técnicas.

Los diseñadores lógicos y físicos involucran decisiones independientes.

Ciclo de Vida del Software.Para iniciar, debemos de tener en cuenta que, el software, es un elemento del sistemaque es de tipo lógico, a diferencia del hardware que es de tipo físico.

Otro, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehículopara entregarlo. Como producto, hace entrega de la potencia informática que incorporael hardware informático o, más ampliamente, una red de computadoras que esaccesible por hardware local. Si reside dentro de un teléfono celular (como elBlackBerry de mi amigo Carlitos Chunga) u opera dentro de una computadora central,el software es un transformador de información, produciendo, gestionando,adquiriendo, modificando, mostrando o transmitiendo información que puede ser tansimple como un solo bit, o tan complejo como una presentación en multimedia. Comovehículo utilizado para hacer entrega del producto, el software actúa como la base de



control de la computadora (sistemas operativos), la comunicación de información(redes) y la creación y control de otros programas (herramientas de software).

Quizás algunas características que debemos de tener en cuenta al momento dedesarrollar un software, son las siguientes:

El software se desarrolla, no se fabrica en un sentido clásico. El software no se estropea o malogra, pero si se puede deteriorar según las

actualizaciones que este pudiera tener. Aunque hoy en día se habla de construir ensamblados o componentes, la

mayoría del software se construye a medida. El software puede aplicarse en cualquier situación en la que se haya definido

previamente un conjunto específico de pasos procedimentales (es decir, unalgoritmo), claro, excepciones notables a esta regla son el software de lossistemas expertos y de redes neuronales. El contenido y el determinismo de lainformación son factores importantes a considerar para determinar lanaturaleza de una aplicación de software. El contenido se refiere al significadoy a la forma de la información de entrada y salida.

Sobre los sistemas

Algo que debemos de tener en cuenta es, que todo sistema a desarrollar, por maspequeño o grande que sea, siempre va a requerir de datos para poder funcionar, estosserán procesados, para poder obtener la información.

A su vez, nuestro sistema puede retomar la información generada, para devolverinformación mas refinada, en un proceso conocido como Feedback oRetroalimentación, el cual es posible por el uso de las Bases de Datos.



Ciclo de Desarrollo

Hay que entender que, esto es un proceso, ahora, debemos de marcar un punto departida para todo este desarrollo, y ese es cuando el especialista en desarrollo desistemas interactúa (Analista) con el Cliente (el cual, habitualmente es el Dueño de laEmpresa, el Gerente General o algún Gerente de Área, quienes son los que tienen lapotestad de desembolso de dinero). Aquí es donde se determina si hay posibilidadesde poder desarrollar un sistema de información

En el Análisis de Requerimientos se realiza la comprobación de lo recopilado en elEstudio Preliminar, através de entrevistas que se realizaran al personal del áreainvolucrada, de tal manera que se puedan conocer sus requerimientos reales, lasfunciones que desempeñan y el procedimiento que siguen, así como los documentosque utilizan.

Todo esto debe de reflejarse en un documento que muestre la situación actual de laempresa, los problemas y las causas que las originan, así como las solucionespropuestas.

Proceso de desarrollo utilizando UML.UML ha nacido como un lenguaje, pero es mucho más que un lenguaje deprogramación. Aunque en su génesis se parece a C++ o a Java, en realidad se hadiseñado y construido un lenguaje que ha nacido con una madurez muy acentuada sise le compara, incluso, con los últimos desarrollos de HTML, Java y XML, loslenguajes por excelencia del mundo Internet.



UML se ha diseñado realizandocombinaciones de una gran cantidadde estándares, si bien se rige através de tres metodologíasprocedentes de la colaboración delos tres creadores de UML, que son:James Rumbaugh, Grady Booch eIvar Jacobson, así como delanálisis y estudio de alrededor de 20métodos estándares que a su vez sehan integrado en otro estándar, eneste caso, UML; esta fue una graniniciativa de los tres creadores quepusieron las especificaciones deUML a la consideración de lacomunidad informática mundial,antes de su publicación. El diseñode UML ha sido completo desde elprincipio, al contrario que HTML queha cambiado gradualmente, deforma que XML ha tratado deresolver los problemas de HTML y Java, que sigue todavía en el proceso deestandarización con la nueva versión 2.0. Al contrario que HTML/XML que sonlenguajes de marcación (markup), UML es un lenguaje para modelar; que es elprocedimiento que emplean los ingenieros para el diseño de software antes de pasar asu construcción, al igual que sucede con cualquier producto manufacturado ofabricado en serie.

UMIL ayuda al usuario a entender la calidad de la tecnología y la posibilidad de quereflexione antes de invertir y gastar grandes cantidades en proyectos que no esténseguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construcciónde las piezas que constituirán el modelo.

Sin embargo, desde el punto de vista puramente tecnológico, UML tiene una grancantidad de propiedades que han sido las que, realmente, han contribuido a hacer deUML el estándar de facto de la industria que es en realidad. Algunas de laspropiedades de UML como lenguaje de modelado estándar son:

Concurrencia, es un lenguaje distribuido y adecuado a las necesidades deconectividad actuales y futuras.

Ampliamente utilizado por la industria desde su adopción por OMG. Reemplaza a decenas de notaciones empleadas con otros lenguajes. Modela estructuras complejas. Las estructuras más importantes que soportan tienen su fundamento en las

tecnologías orientadas a objetos tales como: objetos, clases, componentes ynodos.

Emplea operaciones abstractas como guía para variaciones futuras, añadiendovariables si acaso es necesario.

Comportamiento del sistema: casos de uso, diagramas de secuencia y decolaboraciones, que sirven para evaluar el estado de las máquinas.



Descripción del Proceso Actual: El Modelo de Negocios.La importancia que tiene el elaborar un modelo de negocios, antes de modelar elsistema informático, es el siguiente:

Maneja información que le pertenece al negocio. Será utilizado en organizaciones que ejecutan procesos del negocio cada vez

más automatizable. Se adaptará al entorno de la organización que lo usará. Para identificar con facilidad donde están los problemas y oportunidades de

crecimiento y mejora. Porque desde la perspectiva de los sistemas, no es posible automatizar

procesos que no estén claramente definidos.

Conceptos Fundamentales para Modelar Negocios

Proceso Conjunto de actividades que emplean un insumo. Agregan valor. Suministran un producto a un consumidor.

Proceso de Negocio Conjunto o grupo de tareas o actividades. Secuencia u orden lógico. Emplean recursos de la organización. Ofrece resultados de interés a alguien. Apoya algún objetivo de la organización.

Área Funcional Grupo de Trabajo.

Objetivos Comprender la estructura y la dinámica de la organización objetivo.



Comprender los problemas actuales del organización objetivo e identificar elcampo de acción incluido en donde hay un potencial de crecimiento y mejoras.

Evaluar el impacto del cambio en la organización objetivo. Asegurar que los clientes, usuarios finales, desarrolladores y otros roles tengan

un entendimiento común de la organización objetivo. Obtener, de forma preliminar, los requerimientos del sistema que necesita la

organización objetivo.

ESTEREOTIPOS

Actividades del Modelo de Negocio. Evaluar la organización objetivo. Encontrar los actores y casos de uso del negocio. Construir el modelo de casos de uso del negocio. Encontrar los trabajadores y entidades del negocio. Detallar los casos de uso del negocio. Construir el modelo de análisis del negocio. Mantener las reglas del negocio. Capturar un vocabulario común. Definir las actividades a automatizar.

El actor del negocio representa un rol ejecutado por alguien oalgo externo al negocio, pero que interactúa o se relaciona conél.El BA se beneficia o afecta por los resultados del proceso.Generalmente se identifican como: Clientes, Proveedores,Autoridades, Entidades Legales y/o reguladoras, Sistemas deinformación localizados fuera del negocio.NO debe representar áreas, departamentos o partes de unaorganización, sino roles de ejecución.



El caso de uso del negocio, identifica un proceso específico delnegocio que produce un resultado de valor medible, y esperadopor un actor en particular.Representa la secuencia de actividades desarrolladas paralograr ese valor.Reconoce los procesos del tipo de giro del negocio, porcomparación con el de otras empresas o a partir del estudio dela cadena de valor.Son procesos complejos del negocio, no son actividadessimples.

El trabajador del negocio, representa aquel personaje que tienealgún tipo de responsabilidad dentro del área de estudio, valedecir, que realiza algún tipo de tarea dentro de la misma, o tienealguna responsabilidad.

Creación del Modelo en Rational Rose

Para poder implementar el modelo antes mencionado, haremos uso de la HerramientaCASE “Rational Rose”.

1. una vez instalado el producto, boton Inicio, luego Ejecutar y escribir ROSE,mostrándose la siguiente pantalla.

2. para trabajar con un modelo de análisis, seleccionaremos “Rational UnifiedProcess”.



3. una vez que nos encontremos en la pantalla principal, pondremos especialatención al área del Browser, que se encuentra al lado izquierdo, dondedesplegaremos el elemento Use Case View.



4. realizar un doble click sobre el objeto Main, abriendose una nueva venta, detipo Use Case Diagram.

5. seguidamente, crearemos un paquete de nombre Modelo de Negocio, sobrela ventana que se muestra, ver lo que ocurre en el Browser.



6. luego, hacer doble clic sobre el paquete Modelo de Negocio, debiéndose abriruna nueva ventana, donde empezaremos a desarrollar nuestro modelo.



CCAAPPIITTUULLOO 22

Del Modelo de Negocios al Modelo del Sistema. Funcionalidad del Sistema: Use Case Diagram. Tipos de asociación entre CU’s. Documentando los CU’s.



D E L M O D E L O D E N E G O C I O S A L M O D E L O

D E L S I S T E M A .

Una vez que hemos logrado interpretar la forma de trabajo de la empresa, nosdedicaremos a tratar de automatizar la mayor cantidad de procesos posibles, para ellotengamos en cuenta lo siguiente:

Para poder representar la funcionalidad que va a tener nuestro sistema deinformación, haremos uso del diagrama de casos de uso.

Funcionalidad del Sistema: Use Case Diagram.La vista de casos de uso captura el comportamiento de un sistema, de un subsistema,o de una clase, tal como se muestra a un usuario exterior. Reparte la funcionalidad delsistema en transacciones significativas para los actores-usuarios ideales de unsistema. Las piezas de funcionalidad interactiva se llaman casos de uso. Un caso deuso describe una interacción con los actores como secuencia de mensajes entre elsistema y uno o más actores. El término actor incluye a los seres humanos, así como aotros sistemas informáticos y procesos.



ACTOR

Un actor es una idealización de una persona externa, de un proceso, ode una cosa que interactúa con un sistema, un subsistema, o una clase.Un actor caracteriza las interacciones que los usuarios exteriores puedentener con el sistema. En tiempo de ejecución, un usuario físico puedeestar limitado a los actores múltiples dentro del sistema. Diferentesusuarios pueden estar ligados al mismo actor y por lo tanto puedenrepresentar casos múltiples de la misma definición de actor.

Cada actor participa en uno o más casos de uso. Interactúa con el caso de USO (y porlo tanto con el sistema o la clase que posee el caso de uso), intercambiandomensajes. La implementación interna de un actor no es relevante en el caso de uso;un actor puede ser caracterizado suficientemente por un conjunto de atributos quedefinen su estado.

Los actores pueden ser definidos en jerarquías de generalización, en las cuales unadescripción abstracta del actor es compartida y aumentada por una o másdescripciones específicas del actor.

Un actor puede ser un ser humano, otro sistema informático, o un cierto procesoejecutable. Se dibuja a un actor como una persona pequeña con trazos lineales y elnombre debajo de él.

CASO DE USO

Un caso de uso es una unidad coherente de funcionalidad,externamente visible, proporcionada por una unidad del sistemay expresada por secuencias de mensajes intercambiados por launidad del sistema y uno o más actores. El propósito de un casode uso es definir una pieza de comportamiento coherente, sinrevelar la estructura interna del sistema. La definición de un caso de uso incluye todoel comportamiento que implica: las líneas principales, las diferentes variaciones sobreel comportamiento normal, y todas las condiciones excepcionales, que pueden ocurrircon tal comportamiento, junto con la respuesta deseada. Desde el punto de vista delos usuarios, éstas pueden ser situaciones anormales. Desde el punto de vista de lossistemas, son las variaciones adicionales que deben ser descritas y manejadas.

En el modelo, la ejecución de cada caso de uso es independiente de las demás,aunque una implementación de casos de uso puede crear dependencias implícitasentre ellas, debido a los objetos compartidos. Cada Caso de Uso representa una piezaortogonal de la funcionalidad, cuya ejecución se puede mezclar con la ejecución deotros casos de uso.

La dinámica de un caso de uso se puede especificar por las interacciones de UML,mostradas como diagramas de estado, diagramas de secuencia, diagramas decolaboración, o descripciones informales de texto. Cuando se implementan, los casosde uso son realizados mediante colaboraciones entre clases del sistema. Una clasepuede participar en múltiples colaboraciones y, por lo tanto, en múltiples casos de uso.En el nivel de sistema, los casos de uso representan el comportamiento externo detodo sistema tal y como se muestra a los usuarios exteriores. Un caso de uso es como



una operación de sistema, una operación invocada por un usuario exterior. Sinembargo, a diferencia de una operación, un caso de uso puede continuar recibiendo laentrada de sus actores durante su ejecución. Los casos de uso también se puedenaplicar internamente a unidades más pequeñas de un sistema, tales comosubsistemas y clases individuales. Un caso interno de uso representa elcomportamiento que una parte del sistema presenta al resto del sistema. Por ejemplo,un caso de uso para una clase representa una pieza coherente de la funcionalidad queuna clase proporciona a otras clases que desempeñen ciertos roles dentro delsistema. Una clase puede tener más de un caso de uso.

Un caso de uso es una descripción lógica de una parte de funcionalidad del sistema.No es una construcción manifiesta en la implementación de un sistema. En su lugar,cada caso de uso se debe corresponder con las clases que implementan un sistema.

El comportamiento del caso de uso se corresponde con las transiciones y operacionesde las clases. Ya que una clase puede desempeñar roles múltiple en laimplementación de un sistema, puede por lo tanto realizar porciones de múltiplescasos de uso. Una parte de la tarea del diseño es encontrar las clases deimplementación que combinen claramente los roles apropiados para implementartodos los casos de uso, sin introducir complicaciones innecesarias. La implementaciónde un caso de uso se puede modelar como un conjunto de una o más colaboraciones.Una colaboración es una realización de un caso de uso.

Un caso de uso puede participar en varias relaciones, además de poderse asociar conactores.

Un caso de uso se dibuja como una elipse con su nombre dentro o debajo de ella. Seconecta por líneas con trazo continuo con los actores que se comunican con ella.

Tipos de asociación entre CU’s.Un caso de uso es una descripción lógica de una parte de funcionalidad del sistema.

Un caso de uso puede participar en varias relaciones con otros casos de uso, ademásde poderse asociar con actores.

Aunque cada instancia de un caso de uso es independiente, la descripción de un casode uso se puede descomponer en factores de otros casos de uso más simples. Estoes similar a la manera en que la descripción de una clase se puede definirincrementalmente a partir de la descripción de las superclases. Un caso de uso puedeincorporar simplemente el comportamiento de otros casos de uso como fragmentos desu propio comportamiento. Esto se llama relación de inclusión. En este caso, el nuevocaso de uso no es un caso especial del caso de uso original, y no se puede sustituirpor él.

Un caso de uso se puede también definir como una extensión incremental de un casode uso base. Esto se llama relación de extensión. Puede haber varias extensiones delmismo caso de uso base, que pueden ser aplicadas conjuntamente. Las extensiones aun caso de uso base se agregan a su semántica; que es el caso de uso base instanciado, no los casos de uso de la extensión.



Las relaciones de inclusión y extensión se dibujan como flechas de líneas discontinuascon la palabra clave «include» o «extend». La relación de inclusión apunta al caso deuso a ser incluido; la relación de extensión señala el caso de uso que se extenderá.

Relación Función Notación

Comunicación Solo se produce entre un Actor y unCaso de Uso.

ExtensiónLa inserción de comportamiento

adicional en un CU base que no tieneconocimiento sobre él.

GeneralizaciónRelación entre un CU general y un CUmás específico, que hereda y añade

propiedades.

InclusiónInserción de comportamiento adicional

en un CU base, que describeexplícitamente la inserción.

Comunicación

Las instancias de actores se comunican con el sistema mediante el envío y recepciónde instancias de mensajes (señales y llamadas) desde y hacia instancias de casos deuso, y en el nivel de realización, desde y hacialos objetos que implementan el caso de uso.Todo lo anterior se expresa medianteasociaciones entre el actor y el caso de uso.

Un actor puede listar el conjunto de señalesque envía y que recibe, y mantener una lista delas interfaces que ofrece y que requiere. Las interfaces de un actor deben sercompatibles con las de los casos de uso con los que se comunica. En otras palabras,un actor debe recibir todas las señales que un Caso de uso sea capaz de enviarle y nodebe mandarle al caso de uso señales que éste no sea capaz de recibir. Las interfacesde un actor restringen las clases con las que pueda corresponderse (que puedanimplementar su comportamiento). Un actor puede también tener una lista de atributosque caracterice su estado.



Generalización

Pueden existir semejanzas entre dos o más actores;esto es, pueden comunicarse COn el mismo conjunto decasos de uso de la misma manera. Esta semejanza seexpresa mediante la generalización en otro actor,posiblemente abstracto, que modele los aspectoscomunes. Los actores descendientes heredaran los rolesy relaciones con casos de uso del actor antecesor. Unainstancia de un actor descendiente siempre se puedeutilizar en aquellos casos en los que se espera unainstancia del actor antecesor (principio de capacidad desustitución). Un descendiente incluye los atributos yoperaciones de sus antecesores.

Inclusión

La relación de inclusión conecta un caso de uso base con un caso de uso incluido. Elcaso de uso incluido que figura en esta relación no es un clasificador instanciableindependientemente. Lo que hace es describir explícitamente una secuencia adicionalde comportamiento que se inserta en una instancia de caso de uso que estáejecutando el caso de uso base. A este mismo caso de uso base se le pueden aplicarmúltiples relaciones de inclusión. El mismo caso de uso incluido se puede incluir enmúltiples casos de uso base. Esto no indica ninguna relación entre los casos de usobase. Puede haber, incluso, múltiples relaciones de inclusión entre el mismo caso deUSO incluido y casos de uso base, siempre y cuando cada inserción se haga en unaposición diferente de la base.

El caso de uso incluido puede acceder a atributos o a operaciones del caso de usobase. La inclusión representa un comportamiento encapsulado que, potencialmente,puede reutilizarse en múltiples casos de uso base. El caso de uso base ve al caso deuso incluido, que puede dar valores a los atributos del caso de uso base. Pero el casode uso base no debe acceder a los atributos del caso de uso incluido, porque el casode uso incluido habrá concluido cuando el caso de USO base recupere el control.Obsérvese que se pueden anidar las adiciones (sea cual fuere su clase). Por tanto,una inclusión puede servir como base para otra inclusión, extensión o generalizaciónposterior.



Extensión

Una relación desde un caso de uso extensor a un caso de uso base, que especificacómo se puede insertar el comportamiento definido para el caso de uso extensor en elcomportamiento definido para el caso de uso base. El caso de uso extensor modificaincrementalmente el caso de uso base de forma modular.

El caso de uso extensor en esta relación, no es necesariamente un clasificadorinstanciable separado. Consiste en uno o más segmentos que describen lassecuencias adicionales de comportamiento que modifican incrementalmente elcomportamiento del caso de uso base. Cada segmento en un caso de uso extensor sepuede insertar en una localización separada en el caso de uso base. La relación deextensión tiene una lista de los nombres de los puntos de extensión, igual en númeroal número de segmentos en el caso de uso extensor. Cada punto de extensión sedebe definir en el caso de uso base.

Un caso de uso extensor en una relación de extensión puede tener acceso y modificarlos atributos definidos por el caso de uso base. El caso de uso base, sin embargo, nopuede ver las extensiones y puede no tener acceso a sus atributos u operaciones. Elcaso de uso base define un marco modular en el cual puedan ser agregadasextensiones, pero la base no tiene visibilidad sobre las extensiones. Las extensionesmodifican implícitamente el comportamiento del caso de uso base.

Como identificar un Actor

1. ¿Quién está interesado en un requerimiento concreto?

2. ¿En qué dominios de la organización se usará el sistema?

3. ¿Quién será beneficiario de la nueva funcionalidad?

4. ¿Quién proveerá, usará y/o retirará información?

5. ¿Quién dará soporte y administrará el sistema?

6. ¿Usará el sistema un recurso externo?

7. ¿Un usuario actuará con diferentes roles?

8. ¿Diferentes usuarios actuarán con un mismo rol?

9. ¿Interaccionará el nuevo sistema con un sistema antiguo?



Como identificar un Caso de Uso

1. ¿Cuáles son las tareas y responsabilidades de cada actor?

2. ¿Algún actor creará, almacenará, cambiará, borrará o leerá información del

sistema?

3. ¿Qué casos de uso crearán, almacenarán, cambiarán, borrarán o leerán esta

información?

4. ¿Es necesario que un Actor informe al sistema sobre cambios externos?

5. ¿Es necesario que un Actor sea informado sobre ciertas incidencias del

sistema?

6. ¿Qué Casos de Uso darán soporte y mantendrán el sistema?

7. ¿Pueden ser realizados por los CU todos los requerimientos funcionales

documentados?

Ventajas de los Casos de Uso

1. Lenguaje de comunicación entre usuarios y desarrolladores.

2. Comprensión detallada de la funcionalidad del sistema.

3. Acotación precisa de las habilidades de los usuarios.

4. Gestión de riesgo más eficiente para gobernar la complejidad.

5. Estimación más exacta para determinar tiempo, recursos y prioridades en la

dosificación de esfuerzo de desarrollo.

6. Fiel trazabilidad para verificar la traducción de requerimientos en código

ejecutable.

7. Mayor control para mantener las sucesivas revisiones de los programas.

8. Certificación contractual cliente-desarrollador.

9. Documentación orientada al usuario: help, manual de procedimientos, reglas

del negocio.

10. Documentación orientada al administrador del sistema: soporte de

mantenimiento.



Documentando los CU’s.Los casos de uso representan funcionalidades que va a tener el sistema, sin embargo,estos agrupan varias tareas o actividades, razón por la cual es necesario describirlas,con el objetivo de que los demás miembros del proyecto, puedan conocer los detallesde cada una de las tareas y/o responsabilidades que los actores podrán hacer posiblecon el uso del sistema.

A continuación, se procederá a describir el CU “Identificando Riesgos”, tener en cuentaque esta información, luego se observará en el diagrama de Actividad, el cual mostrarála lógica que tiene el sistema.




Para poder retomar nuestro proyecto de sistema, lo primero que haremos será abrir elarchivo donde se encuentra nuestro Modelo de Negocio, para luego seguir lossiguientes pasos:

1. desplegar desde el Browser el paquete Use Case View, y hacer doble clicsobre el objeto Main, al abrirse la ventana, crearemos un nuevo paquete, denombre CU del Sistema.



2. seguidamente haremos un doble clic sobre dicho paquete, de tal manera quese abra una nueva ventana, donde empezaremos a diseñar nuestro modelo.



CCAAPPIITTUULLOO 33

Capturando el Modelo de Objetos. Uso de: Objetos, Clases, Encapsulamiento, Herencia, Polimorfismo. Diagramas de Clases. Tipos de Asociación entre Clases.



C A P T U R A N D O E L M O D E L O D E O B J E T O S .

A continuación conjugaremos las características del UML con los conceptos de laorientación a objetos.

Aquí refinarán su conocimiento de la orientación a objetos al tiempo que aprendemosotras cosas del UML.

Uso de: Objetos, Clases, Encapsulamiento, Herencia,Polimorfismo.

Clase

En el UML un rectángulo es el símbolo que representa una clase. El nombre de laclase es por convención una palabra con la primera letra en mayúscula ynormalmente se coloca en la parte superior del rectángulo. Si el nombre de su claseconsta de dos palabras únalas e inicie cada una con mayúscula.

Otra estructura del UML el paquete, puede jugar un papel en el nombre de la clase unpaquete es la manera en que el UML organiza un diagrama de elementos. Tal vezrecuerde que el UML representa un paquete como una carpeta tabular cuyo nombrees una cadena de texto.

Si la clase "GuíaCompra" es parte de paquete llamado "DocumentosContables",podrá darle el nombre " DocumentosContables:: GuíaCompra ", El par de dospuntos separa al nombre del Paquete, que está a la izquierda del nombre de la clase,que va a la derecha. A este tipo de nombre de clase se conoce como nombre de ruta.

Atributos

Un atributo es una propiedad o característica de una clase y describe un rango devalores que la propiedad podrá contener en los objetos (esto es, instancias) de laclase. Una clase podrá contener varios o ningún atributo Por convención, si el atributoconsta de una sola palabra se escribe en minúsculas; por otro lado, si el nombrecontiene más de una palabra cada palabra será unida a la anterior y comenzará conuna letra mayúscula, a excepción de la primer palabra que comenzará en minúscula



La lista de nombres de atributos iniciará luego de una línea que la separe del nombrede la clase como se aprecia en la figura.

Todo objeto de la clase tiene un valor específico en cada atributo. La figura lemuestra un ejemplo. Observe que el nombre de un objeto inicia con una letraminúscula y está procedido de dos puntos que a su vez están procedidos del nombrede la clase y todo el nombre está subrayado.

El UML le da la opción de indicar información adicional de los atributos. En el símbolode la clase podrá especificar un tipo para cada valor del atributo. Entre los posiblestipos se encuentran cadena (string) número de punto flotante (float), entero (integer)y booleano (boolean) así como otros tipos enumerados. Para indicar un tipo, utilicedos puntos (:) para separar el nombre del atributo de su tipo. También podrá indicar unvalor predeterminado para un atributo La figura le muestra las formas de estableceratributos.

Operaciones

Una operación es algo que la clase puede realizar, o queusted (u otra clase) pueden hacer a una clase. De lamisma manera que el nombre de un atributo el nombre deuna operación se escribe en minúsculas si consta de unasola palabra.

Si el nombre constara de más de una palabra únalas einicie todas con mayúscula exceptuando la primera. Lalista de operaciones se inicia debajo de una Línea quesepara al de las operaciones de los atributos como semuestra en la figura.

Así como es posible establecer información adicional delos atributos, también lo es en lo concerniente a lasoperaciones En los paréntesis que preceden al nombre dela operación podrá mostrar el parámetro con el que



funcionará la operación junto con su tipo de función, que es un tipo de operación,devuelve un valor luego que finaliza su trabajo. En una función podrá mostrar el tipo devalor que regresará,

Estas secciones de información acerca de una operación se conocen como la firma dela operación.

Si usted tiene una larga lista de atributos u operaciones podrá utilizar un estereotipopara organizarla de forma que sea más comprensible. Un estereotipo es el modo enque el UML le permite extenderlo es decir crear nuevos elementos que sonespecíficos de un problema en particular que intente resolver Como lo mencioné en lahora l. usted muestra un estereotipo como un nombre bordeado por dos pares deparéntesis angulares. Para una lista de atributos podrá utilizar un estereotipo comoencabezado de un subconjunto de atributos como en la figura.

La idea es incluir información suficiente para describir una clase de forma inequívoca

Una manera más formal es agregar una restricción un texto libre. Bordeado porllaves; este texto especifica una o varias reglas que sigue la clase.

Notas Adjuntas

Por encima y debajo de los atributos, operaciones responsabilidades Yrestricciones puede agregar mayor información a una clase en la figura de notasadjuntas

Con frecuencia agregará una nota a un atributo u operación. La figura le muestra unanota que se refiere a una norma gubernamental que indica dónde encontrar la maneraen que se generan los números de serie para los objetos de la clase Lavadora

GuiaCompranroGuiafechaEmisioncondicionPagoobservaciones

nuevaGuia()imprimir()cerrar()anular()

documento que seemite al Prov eedor



Diagramas de Clases.Las clases son el vocabulario y tecnología de un área del conocimiento conformehable con los clientes, analice su área de conocimiento y diseñe sistemas decomputación que resuelvan los problemas de dicha área, comprenderá la terminologíay modelará los términos como clases en el UML.

En sus conversaciones con los clientes preste atención a los sustantivos que utilizanpara describir las entidades de sus negocios; ya que dichos sustantivos se convertiránen las clases de su modelo También preste atención a los verbos que escuche dadoque constituirán las operaciones de sus clases .Los atributos surgirán comosustantivos relacionados con los nombres de la clase. Una vez que tenga una listabásica de las clases pregunte a los clientes que es lo que cada clase hace dentrodel negocio. Sus respuestas le indicarán las responsabilidades de la claseSuponga que usted es un analista que generará un modelo del juego debaloncesto. y que entrevista a un entrenador para comprender el juego Laconversación podría surgir como sigue:

Analista: "Entrenador, ¿de que se trata el juego?Entrenador: "Consiste en anotar el balón a través de un aro, conocido como cesto, yhacer una mayor puntuación que el oponente, Cada equipo consta de cinco jugadoresdos defensas dos delanteros y un central. Cada equipo lleva el balón al cesto delequipo oponente con el objetivo de hacer que el balón sea encestado."Analista: "¿Cómo se hace para llevar el balón al cesto?"Entrenador: "Mediante pases y dribles. Pero el equipo tendrá que encestar antes deque termine el lapso para tirar."Analista: "¿El lapso para tirar?"Entrenador: "Así es, son 24 segundos en el baloncesto profesional, 30 en un juegointernacional, y 35 en el colegial para tirar el balón luego de que un equipo tomaposesión de él."Analista: "¿Cómo funciona el puntaje?"Entrenador: "Cada canasta vale dos puntos, a menos que el tiro baya sido hechodetrás de la Línea de los tres puntos En tal caso, tres puntos Un tiro libre contará comoun punto. A propósito, un tiro libre es la Penalización que paga un equipo por cometeruna infracción Si un jugador infracciona a un oponente. se detiene el juego y eloponente puede realizar diversos, tiros a! cesto desde la Línea de tiro libre."

Analista: "Hábleme más acerca de lo que hace cada jugador,"Entrenador: "Quienes juegan de defensa son, en general, quienes realizan la mayorparte de los dribles y pases, Por lo general tienen menor estatura que los delanteros, yéstos, a su vez, son menos altos que el central (que también se conoce como 'poste')Se supone que Iodos los jugadores pueden burlar, pasar, tirar y rebotar los delanterosrealizan la mayoría de los rebotes y los disparos de mediano alcance, mientras que elcentral se mantiene cerca del cesto y dispara desde un alcance corto,"Analista: "¿Qué hay de las dimensiones de la cancha? Y ya que estamos en eso¿cuánto dura el juego?"Entrenador: "En un juego internacional, la cancha mide 28 metros de longitud y 15 deancho; el cesto se encuentra a 3.05 m del piso, En un juego profesional, el juego dura48 minutos, divididos en cuatro cuartos de 12 minutos cada uno, En un juego colegiale internacional, la duración es de 40 minutos, divididos en dos mitades de 20 minutos,Un cronómetro del juego lleva un control del tiempo restante"



La plática podría continuar, pero hagamos una pausa y veamos con qué contamos,Aquí hay varios sustantivos que ha descubierto balón, cesto, equipo, jugadores,defensas, delanteros, cesto (o poste), tiro, lapso para tirar, línea de los 3 puntos, tirolibre, infracción, línea de tiro libre, cancha, cronómetro del juego y los verbos: tirar,avanzar, driblar (o burlar), pasar, infraccionar, rebotar. También cuenta con ciertainformación adicional respecto a algunos de los sustantivos (como las estaturasrelativas de los jugadores de cada posición. las dimensiones de la cancha, la cantidadtotal de tiempo en un lapso de tiro y la duración de un juego)

Finalmente, su propio sentido común podría entrar en acción para generar ciertosatributos por usted mismo. Usted sabe, por ejemplo, que el balón cuenta con ciertosatributos, como volumen y diámetro

A partir de esta información, podrá crear un diagrama como el de la figura En él semuestra las clases y se proporcionan ciertos atributos, operaciones y restriccionesEl diagrama también muestra las responsabilidades. Podría usar este diagramacomo fundamento para otra., conversaciones con el entrenador para obtener mayorinformación.

Balonvolumendiametro

driblar()tirar()pasar()avanzar()

Jugadornombreestaturapeso

dribalrBalon()pasarBalon()tirarBalon()rebotar()infraccionarOponente()

Equipo

CestoTiroLibre Defensa

Cancha

Infraccion

Tipos de Asociación entre ClasesUna vez que tengamos todas nuestras clases, será necesario que estas se asocien,con el fin de mostrar la dependencia entre ellas.

Las clases se pueden asociar de la siguiente manera:

Asociación (Binaria)

Cuando una clase se vincula con otra clase, para ello se trazará una línea que la una,donde, adicionalmente se indicará la multiplicidad entre ellos.



Cuando una clase se asocia con otra cada una de ellas juega un papel dentro de talasociación. Puede representar estos papeles en el diagrama escribiéndolos cerca dela Línea que se encuentra junio ala clase que juega el papel correspondiente.

Clases de Asociación (Atributos de Enlace)

Una asociación al igual que una clase puede contener atributos y operaciones.Cuando este sea el caso usted tendrá una clase de asociación.

Puede concebir a una clase de asociación de la misma forma en que lo haría con unaclase estándar y utilizará una línea discontinua para conectarla a la línea de asociaciónUna clase de asociación puede tener asociaciones con otras clases

FacturanroFacturafechaEmisionsubTotaligvTotalfechaCancelado

ProductonombreprecioVentastock

1..*0..* 1..*0..*

DetalleFacturacantidadimporte

Tener en cuenta que, esta asociación solo se produce cuando existe una relación conmultiplicidad de muchos a muchos, y adicionalmente, existan atributos quedescriban la relación.



Asociaciones Reflexivas

En ocasiones una clase es una asociación consigo misma Esto puede ocurrir cuandouna clase tiene objetos que pueden jugar diversos papeles Un OcupanteAutomovilpuedo ser un Conductor o un Pasajero. En el papel del conductor elOcupanteAutomovil puede llevar ninguno o más OcupanteAutomovil quienes jugaránel papel de pasajeros Esto lo representará mediante el trazo de una Línea deasociación a partir del rectángulo de la clase hacia el mismo rectángulo de la clase. yen la línea de asociación indicará los papeles nombre de la asociación dirección de laasociación y multiplicidad corno ya lo hizo antes La figura le presenta este ejemplo:

OcupanteAutomovil

0..*

11

0..*

+conductor

+pasajeroconduce

Herencia Y Generalización

Uno de los sellos distintivos de la orientación a objetos es que captura uno de losmayores aspectos del sentido común en cuanto a la vida diaria: si usted conoce algode una categoría de cosas automáticamente sabrá algunas cosas que podrátransferir a otras categorías Si usted sabe que algo es un electrodoméstico, yasabrá que contará con un interruptor, una marca y un numero de serie

La jerarquía de la herencia no tiene que finalizar en dos niveles: una clase secundariapuede ser principal para otra clase secundaria Un Mamífero es una clase secundariade Animal y Caballo es una clase secundaria de Mamífero que algo es un animaldará por hecho que come, duerme, tiene una forma de nacer de trasladarse de unlugar a otro y algunos otros atributos (y operaciones) que podría listar si pensara enello por algunos instantes.



VehiculoTransporte

AereoTerrestre Maritimo

TrenAutomovil Barco Avion

La orientación a objetos se refiere a esto como herencia. El UML también lodenomina generalización. Una clase (la clase secundaria o subclase) puede heredarlos atributos y operaciones de otra (la clase principal o superclase). La claseprincipal (o madre) es más genérica que la secundaria (o hija).

Agregación / Composición

Un objeto no es algo compacto ni indivisible, por el contrario, el objeto puede estarconformado por otros objetos, ocasionando que existan relaciones mas fuertes queotras.Cuando un objeto esta conformado por otros objetos, pero si prescinde de ellos nopierde su esencia o razón de ser, se dice que la relación es por Agregación.

Automóvil Radio

Pero cuando el objeto pierde sus facultades o esencia ante la ausencia de algún otroobjeto, entonces se dice que la relación es por Composición.

Automóvil Motor


Para poder crear nuestro Diagrama de Clases, empecemos abriendo nuestroproyecto en Rational, luego:

1. desplegar desde el Browser el Logical View y hacer doble clic sobre el objetoWelcome.



2. luego, crear un paquete para que contenga las clases a definir.

3. hacer doble clic sobre el paquete, y crear las clases dentro de ella, junto consus asociaciones.



CCAAPPIITTUULLOO 44

Definiendo la Lógica del Sistema. Utilizando el Diagrama de Actividad. Definiendo Escenarios. Diagramas de Interacción: Secuencia y Colaboración.



D E F I N I E N D O L A L Ó G I C A D E L S I S T E M A .

Ahora veremos un tipo de diagrama que podría parecerle familiar, este diagrama lemuestra los pasos en una operación o proceso

En este tema se tratarán los siguientes temas:

• Que es un diagrama de actividades• Aplicación de los diagramas de actividades• Marcos de responsabilidad• Adiciones al panorama

Si alguna vez ha tomado algún curso básico de programación, ya conocerá losdiagramas de flujo Siendo uno de los primeros modelos visuales que se aplicaron a lacomputación el diagrama de flujo muestra una secuencia de pasos, procesos, puntosde decisión y bifurcaciones. A los programadores novatos se les invita a que utiliceneste diagrama para conceptualizar problemas y derivar sus soluciones. La idea esconvertir al diagrama de flujo en la base del código con sus diversas características ytipos de diagramas el UML es en cierta medida un diagrama de flujo con esteroides

El diagrama de actividades del UML. El tema de esta parte. es muy parecido a losviejos diagramas de flujo. Le muestra los pasos (conocidos como actividades) asícomo puntos de decisión y bifurcaciones es útil para mostrar lo que ocurre en unproceso de negocios u operación. Los encontrará como parte integral del análisis deun sistema

Utilizando el Diagrama de Actividad.Para empezar, un diagrama de actividades ha sido diseñadopara mostrar una visión simplificada de lo que ocurredurante una operación o proceso es una extensión de undiagrama de estados mismo que ya conoció El diagrama deestados muestra los estados de un objeto y representa lasactividades como flechas que conectan a los estados. Eldiagrama de actividades resalta precisamente a lasactividades

A cada actividad se le representa por un rectángulo con lasesquinas redondeadas (más angosto y ovalado que larepresentación del estado). El procesamiento dentro de unaactividad se lleva a cabo y. al realizarse se continúa con lasiguiente actividad Una flecha representa la transición deuna a otra actividad Al igual que el diagrama de estados elde actividad cuenta con un punto inicial (representado porun circulo relleno) y uno final (representado por unadiana).

NewActivity

NewActivity2



Decisiones

Casi siempre una secuencia de actividades llegará a un punto donde se realizaráalguna decisión ciertas condiciones le llevaran por un camino y otras por otro (peroambas son mutuamente exclusivas).

Podrá representar un punto de decisión de una de dos formas: la primera es mostrarlas rutas posibles que pasen directamente de una actividad y la segunda es llevar latransición hacia un rombo reminiscencias del símbolo de decisión en un diagrama deflujo y que de allí salgan las rutas de decisión (como usuario de los antiguosdiagramas de flujo. prefiero la segunda opción). De cualquier forma, indicará lacondición con una instrucción entre corchetes junto a la ruta correspondiente La figurale muestra las posibilidades.

NewActivity

NewActivity2

NewActivity3

NewActivity4

Rutas Concurrentes

Conforme modele actividades tendrá laoportunidad de separar una transición endos rutas que se ejecuten al mismo tiempo(es decir de forma concurrente) y luegose reúnan para representar esta divisiónutilizará una línea gruesa perpendicular a latransición y las rutas partirán de ella. Pararepresentar la reincorporación ambasrutas apuntarán a otra línea gruesa.

NewActivity

NewActivity2 NewActivity3



Teniendo en cuanta lo antes mencionado, procederemos a mostrar el diagrama desecuencia para la funcionalidad Validar Ingreso al Sistema.

intentos=0

mostrarformulario

ingresar datosusuario

verificar autenticidadde datos

mostrar formularioproncipal

mostrarmensaje error

intentos++

válido?

si

no

intentos < 3

si

no

exito

fracaso

Definiendo Escenarios (Calles).En algunas ocasiones, es útil organizar las actividades en un modelo según suresponsabilidad, por ejemplo, agrupando juntas todas las actividades manejadas poruna organización del negocio. Esta clase de asignación puede mostrarse organizandolas actividades en regiones distintas separadas por líneas en el diagrama. Debido a suaspecto, cada región se llama calle.



RESUMEN

El diagrama de actividades del UML es muy parecido a un diagrama de flujo muestralos pasos, puntos de decisión y bifurcaciones Este tipo de diagrama es útil pararepresentar las operaciones de un objeto y los procesos de negocios

El diagrama de actividades es una extensión del diagrama de estados Losdiagramas de estados destacan los estados y representan actividades como flechasentre los estados .Los de actividades se enfocan en las actividades Cada actividadse representa como un rectángulo con esquinas redondeadas, más ovalados enapariencia que la representación de un estado. El diagrama de actividades utiliza losmismos símbolos que el de estados para los puntos de inicio y final.

Diagramas de Interacción: Secuencia y Colaboración.Los diagramas de interacción, permiten mostrar como los objetos interactúan entresi, para cumplir con la funcionalidad establecida.



Diagrama de Secuencia

El diagrama de secuencias consta de objetos que se representan del modo usual conrectángulos con nombre (subrayado), mensajes representados por líneas continuascon una punta de flecha y el tiempo representado como una progresión vertical

OBJETOS

Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derechay se acomodan de manera que simplifiquen al diagrama La extensión que esta debajo(y en forma descendente) de cada objeto será una línea discontinua conocida comola Línea de vida de un objeto. Junto con la línea de vida de un objeto se encuentra unpequeño rectángulo conocido como activación, el cual representa la ejecución de unaoperación que realiza el objeto. La longitud del rectángulo se interpreta como laduración de la activación. La figura muestra un objeto, su línea de vida y su activación.

MENSAJE

Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a la deotro .Un objeto puede envía un mensaje a si mismo es decir desde su Línea de vidahacia su propia línea de vida Un mensaje puede ser simple, sincrónico oasincrónico

Un mensaje simple es la transferencia del control de un objeto a otro. Si un objetoenvía un mensaje sincrónico esperara la respuesta a tal mensaje antes de continuarcon su trabajo. Si un objeto envía un mensaje asincrónico no esperará una respuestaantes de continuar. En el diagrama de secuencias los símbolos del mensaje varíanpor ejemplo la punta de la flecha de un mensaje simple está formada por dos o mas lapunta de la flecha de un mensaje sincrónico está llena y la de un asincrónico tieneuna sola línea como se aprecia en la figura.



TIEMPO

El diagrama representa al tiempo en dirección vertical El tiempo se inicia en la partesuperior y avanza hacia la parte inferior Un mensaje que esté más cerca de la partesuperior ocurrirá antes que uno que esté cerca de la parte inferior

Con ello el diagrama de secuencias tiene dos dimensiones. La dimensión horizontales la disposición de los objetos. y la dimensión vertical muestra el paso del tiempo Lafigura muestra al conjunto básico de símbolos del diagrama de secuencias con lossímbolos en funcionamiento conjunto La figura muestra a un actor que inicia lasecuencia aunque en sentido estricto la figura adjunta no es parte del conjunto desímbolos del diagrama de secuencias.

: <Actor Name> : <Actor Name>

Objeto1Objeto1 Objeto2Objeto2

Para ver en acción a esta importante herramienta del UML apliquémosla en losejemplos que hemos visto anteriormente. Cada aplicación le mostrará algunosconceptos importantes que se relacionan con los diagramas de secuencias

LA SECUENCIA

Suponga que el usuario de una GUI presiona una tecla alfanumérica; si asumimos queutiliza una aplicación como un procesador de textos el carácter correspondientedeberá aparecer de inmediato en la pantalla ¿Qué ocurre tras bambalinas para queesto suceda?




Diagrama de actividad1. abrir el paquete que contiene el diagrama de Casos de Uso.

2. hacer clic derecho sobre el caso de uso a describir su lógica, y luego del menúcontextual, seleccionar Sub Diagrams, luego New Activity Diagram.



3. seguidamente, procederemos a colocar las actividades correspondientes,según la lógica adecuada para el caso de uso correspondiente.

Diagrama de Secuencia1. regresar a la ventana que tiene el diagrama de casos de uso.



2. hacer clic derecho sobre el caso de uso del cual se elaborará el diagrama desecuencia, luego, seleccionar la opción Open Specification.

3. de la ventana que se muestra, seleccionar la ficha Diagrams, luego, en el árealibre, hacer clic derecho, y del menú contextual seleccionar Insert SequenceDiagram.

4. darle un nombre al nuevo gráfico, como se ve en la figura, seguidamente,hacer un doble clic sobre el, para que se apertura una nueva ventana, dondeprocederemos a realizar nuestro diagrama.



CCAAPPIITTUULLOO 55

El comportamiento de los objetos. Uso del Diagrama de Estados. Diagrama de Componentes. Diagrama de Despliegue.



E L C O M P O R T A M I E N T O D E L O S O B J E T O S .

Hasta ahora ha comprendido los importantes elementos estructurales del UML. Ahoraverá un elemento que le muestra cómo modificar los procedimientos con el tiempoEn esta parte se tratarán los siguientes temas:

• Qué es un diagrama de estados• Sucesos, acciones y condiciones de seguridad• Subestados: secuenciales y concurrentes• Estados históricos• Por que son importantes los diagramas de estados• Adición del diagrama de estados al panorama del UML

Cada año trae consigo nuevos estilos en ropas y automóviles las estaciones cambianel color de las hojas de los árboles y cada año que pasa deja entrever el crecimiento ymadurez de los niños. Al pasar el tiempo y conforme suceden las cosas hay cambiosque afectan a los objetos que nos rodean.

Esto también se aplica en cualquier sistema conforme el sistema interactúa con losusuarios y (posiblemente) con otros sistemas los objetos que lo conforman pasaranpor cambios necesarios para ajustar las interacciones. Si va a modelar sistemasnecesitará contar con un mecanismo para los cambios en el modelo

Uso del Diagrama de Estados.Una manera para caracterizar un cambio en un sistema es decir que los objetos que locomponen modificaron su estado como respuesta a los sucesos y al tiempo

He aquí algunos ejemplos rápidos

• Cuando acciona el interruptor, la fuente de luz cambia su estado de apagada a• encendida.• Cuando presiona un botón de un control remoto, una televisión cambia su

estado para mostrarle un canal u otro• Luego de un lapso adecuado una lavadora cambia su estado de "Lavar" a

"enjuagar'

El DIAGRAMA DE ESTADOS UML captura este tipo de cambios presenta los estadosen los que puedo encontrarse un objeto junto con las transiciones entre los estados, ymuestra los puntos inicial y final de una secuencia de cambios de estado,

UN DIAGRAMA DE ESTADOS MUESTRA LAS CONDICIONES DE UN SOLOOBJETO.



SIMBOLOGÍA

La figura le muestra el rectángulo de vértices redondeados que representa a un estadojunto con una línea continua y una punta de flecha mismas que representan a unatransición. La punta de la flecha apunta hacia el estado donde se hará la transición. Lafigura también muestra un círculo relleno que simboliza un punto inicial y la diana querepresenta a un punto final.

SUCESOS Y ACCIONES

También puede agregar ciertos detalles a las líneas de transición. Puede indicar unsuceso que provoque una transición (desencadenar un suceso), y la actividad decómputo (la acción) que se ejecute y haga que suceda la modificación del estado. Alos sucesos y acciones los escribirá cerca de la línea de transición mediante unadiagonal para separar un suceso desencadenando de una acción En ocasiones unevento causará una transición sin una acción asociada. y algunas veces una transiciónsucederá dado que un estado finalizará una actividad (en lugar de hacerlo por unsuceso). A este tipo de transición se le conoce como transición no desencadenada LaGUI (interfaz gráfica de usuario) con que interactúe le dará ejemplos de detalles de latransición. Por el momento, asumamos que la GUI puede establecerse en uno de tresestados:

• Inicialización• Operación• Apagar

Cuando encienda su equipo se ejecutará un proceso de arranque. Al encender la PCse desencadena un suceso que provoca que la GUI aparezca luego de una transicióndesde el estado de Inicialización y el arranque es una acción que se realiza durantetal transiciónComo resultado de las actividades en el estado de inicialización la GUI entra al modode Operación. Cuando desea apagar su PC desencadena un suceso que provoca latransición hacia el estado de Apagado y con ello la PC se apaga. La figura muestra eldiagrama de estados que captura los estados y transiciones en la GUI

Inicializacion

entry/ hacer Arrancar...

Apagar

Operacion

Encender PC

Apagado



CONDICIONES DE SEGURIDAD

La anterior secuencia de estados de la GUI deja mucho que desear Por ejemplo: sideja solo su equipo o si realizara alguna actividad en la que no tocará al ratón o alteclado podría aparecer un protector de pantallas que evitarla el desgaste de supantalla Para decir esto en términos de cambio de estado si ha pasado cieno tiemposin que haya interacción con el usuario. la GUI hará una transición del estadoOperación a un estado que no aparece en la figura el estado de Protector depantallas .El intervalo se especifica en el panel de control de su sistema operativo(Windows en este caso). Por lo general es de 15 minutos Cualquier opresión de unatecla o movimiento del ratón provocará una transición del estado Protector depantallas al estado Operación.

El intervalo de 15 minutos es una condición de seguridad: cuando se llega a ella serealiza la transición. La figura muestra el diagrama de estados de la GUI con elestado Protector de pantalla y la condición de seguridad aludida. Vea que lacondición de seguridad se establece como expresión booleana.

Inicializacion

entry/ hacer Arrancar...

Apagar

Operacion

Encender PC

Protectorde Pantalla

Apagado

lapso transcurrido

¿Por qué son Importantes los Diagramas de Estados?

Es necesario contar con diagramas de estados dado que permiten a los analistas,diseñadores y desarrolladores comprender el comportamiento de los objeto, de unsistema Un diagrama de clases y el diagrama de objetos correspondiente sólomuestra lo, aspectos estáticos de un sistema Muestran las jerarquías y asociaciones, yle indican qué son la, operaciones Pero no le muestran los detalles dinámicos de lasoperaciones

Los desarrolladores, en particular, deben saber la forma en que lo, objetos se suponeque se comportaran, ya que son ellos quienes tendrán que establecer talescomportamientos en el software No es suficiente con implementar un objeto losdesarrolladores deben hacer que tal objeto haga algo, Los diagramas de estados se



aseguran que no tendrán que adivinar lo que se supone que harán lo, objetos, Conuna clara representación del comportamiento del objeto, aumenta la probabilidad deque el equipo de desarrollo produzca un sistema que cumpla con los requerimientos.

Diagrama de Componentes.Un componente de software es una parte física de un sistema, y se encuentra en lacomputadora, no en la mente del analista. ¿Qué puede tomarse como componente?Una tabla, archivo de datos, ejecutable, biblioteca de vínculos dinámicos, documentosy cosas por el estilo.

¿Cuál es la relación entre un componente y una clase? Imagine a un componentecomo la personificación en software de una clase. La clase representa una abstracciónde un conjunto de atributos y operaciones. Un importante punto por recordar de loscomponentes y clases es que un componente puede ser la implementación de más deuna clase.

Si el componente se encuentra en una computadora y es la parte funcional delsistema, ¿para qué preocuparse por él? Tendrá que modelar componentes y susrelaciones para que:

1. Los clientes puedan ver Ja estructura del sistema finalizado.2. Los desarrolladores cuenten con una estructura con la cual trabajar en

adelante.3. Quienes escriban las notas técnicas y La documentación puedan entender de

qué escribirán.4. Usted se aliste para volver a utilizar los componentes.

Exploremos el último punto. Uno de los aspectos más importantes de los componenteses el potencial que tienen de volver a ser utilizados. Con las necesidades actuales delos negocios de soluciones rápidas, entre más rápido presente un sistema paraproducción, mayor será su competitividad. Si puede crear un componente para unsistema y puede volver a utilizarlo en otro, usted habrá contribuido a esacompetitividad. Tómese el tiempo y esfuerzo para modelar un componente que loayude a que esta reutilización pueda llevarse a cabo.

NewComponent

TIPOS DE COMPONENTES

Conforme avance en su carrera como modelador, se encontrará con tres tipos decomponentes:

1. Componentes de distribución, que conforman el fundamento de los sistemasejecutables (por ejemplo, DLL, ejecutables, controles ActiveX y Java Bcans).



2. Componentes para trabajar en e! producto, a partir de los cuales se han creadolos componentes de distribución (como archivos de base de datos y de código).

3. Componentes de ejecución, creados como resultado de un sistema enejecución.

Si es usted un usuario de Windows, encontrará ejemplos de los tres tipos decomponentes cuando utilice la ayuda, aunque tal vez no lo sepa. El componente dedistribución es el archivo .HLP (Archivo de Ayuda): Cuando haga clic en uno, se abriráel cuadro de diálogo de los temas de la ayuda y empezará a buscar el tema que elija.La primera vez que haga clic en la ficha Buscar, verá una pequeña animación que leindicará que se está creando un índice. Un archivo .CNT (tema de contenido) describeel esquema del contenido. Dado que este archivo le ayuda a crear un componente dedistribución (puede utilizar la página de índice por siempre), es un componente paratrabajar en el producto. A su vez, el índice creado se encuentra en un archivo .FTS(btísqueda de texto completo). Finalmente, la primera vez que abra la ayuda, se crearáun archivo .GID (índice general), que es resultado de un análisis del sistema de ayudade Windows que agiliza el acceso a los temas del archivo de ayuda. Con ello, losarchivos .FTS y .GID son componentes de ejecución.

DisposicionAnimacion

<<ActiveX>>

ImagenEsfera<<ActiveX>>

CronometroEsfera

<<ActiveX>>

BotonEjecutar<<ActiveX>>

BotonDetener<<ActiveX>>

BotonReiniciar<<ActiveX>>

CuadroComboCronometro

<<ActiveX>>CuadroComboDistancia

<<ActiveX>>

Animacion.html

VBScript

esfera.jpg



Diagrama de Despliegue.Es momento de concentrarnos en el hardware. Como podrá ver, hemos trascendidodesde los elementos (como las clases) que se encuentran en los análisis, hasta loscomponentes en los equipos de cómputo y al hardware existente.

Claro está que el hardware es un tema primordial en un sistema de varioscomponentes. En el mundo actual de la computación, un sistema podría abarcardiversos tipos de plataformas en ubicaciones dispersas. Un diseño sólido dedistribución de hardware es básico para el diseño del sistema. El UML nos da lossímbolos para crear una imagen clara de la forma en que deberá lucir el hardwarefinal.

El elemento primordial del hardware es un nodo, que es un nombre genérico para todotipo de recurso de cómputo. Es posible usar dos tipos de nodos: un procesador, el cualpuede ejecutar un componente, y un dispositivo que no lo ejecuta. Normalmente, undispositivo (como impresora o monitor) tiene contacto de alguna forma con el mundoexterior.En el UML. un cubo representa a un nodo. Deberá asignar un nombre para el nodo, ypodrá utilizar un estereotipo para indicar el tipo de recurso que sea.

El nombre es una cadena de texto. Si el nodo es parte de un paquete, su nombrepuede contener también el del paquete. Puede dividir al cubo en compartimientos queagreguen información (como componentes colocados en el nodo).

<processor name>

preemptive

<process name><thread name>

<device name>



CCAAPPIITTUULLOO 66

Del Modelo de Objetos al Modelo de Datos. Refinando el Modelo de Datos. El Proceso de Normalización. Restricciones según las Reglas del Negocio.



D E L M O D E L O D E O B J E T O S A L M O D E L O D E

D A T O S .

La capa de datos del diagrama de clase se puede usar para implementardirectamente un diseño orientado a objetos de una base de datos, o, como extensiónde UML, puede ser referenciado en un diagrama de relación de entidad para másanálisis de relaciones de entidad. Está en el diagrama de relación de entidad elcual relaciona entre entidades que pueden ser modeladas basadas en atributos clave.

El diagrama de relación de entidad lógico ofrece una base desde la cual construir undiagrama físico representando las tablas y relaciones actuales de la base de datosrelacional.

Tengamos en cuenta algo, el modelo de objetos no es todavía nuestra Base de Datos,para ello hay que realizar un proceso de refinamiento y verificación, puesto que las BDque vamos a utilizar son de tipo relacional, y estas tienen una antigüedad de mas de30 años (exactamente 39, contando desde 1970)

Lo primero que tendríamos que realizar sería convertir el modelo de objetos a unmodelo de datos, para lo cual Rational tiene sus propias especificaciones.



Refinando el Modelo de Datos.Tengan en cuenta que, esta es la interpretación que realiza el Rational, nosotrostodavía tenemos la potestad de poder mejorar este modelo.

Observemos este detalle, a nivel de objetos la concepción es válida, pero ¿esrealmente aplicable en un modelo de dato?

ComprobantePagofechaEmision : Datetotal : Currency

FacturanroFactura : StringsubTotal : Currencyigv : Currency

BoletanroBoleta : String



Fíjense como lo interpreta el Rational.

T_ComprobantePagof echaEmision : DATETIMEtotal : MONEYT_ComprobantePago_ID : INTT_Cliente_ID : INT

<<PK>> PK_T_ComprobantePago10()<<FK>> FK_T_ComprobantePago4()<<Index>> TC_T_ComprobantePago15()

<<Identif y ing>><<Identif y ing>>

1

0..1

1

0..1

T_FacturanroFactura : VARCHAR(255)subTotal : MONEYigv : MONEYT_ComprobantePago_ID : INT

<<PK>> PK_T_Factura14()<<FK>> FK_T_Factura7()<<Index>> TC_T_Factura16()

T_BoletanroBoleta : VARCHAR(255)T_ComprobantePago_ID : INT

<<PK>> PK_T_Boleta15()<<FK>> FK_T_Boleta8()<<Index>> TC_T_Boleta17()

A nivel de BD no me resulta nada práctico, para este caso, lo mejor seria prescindir deestas tablas, y manejarlo todo desde la tabla ComprobantePago.



De esta forma, nuestra base de datos tendría la siguiente forma:

Definición de Base de Datos

Una Base de Datos es un conjunto de datos almacenados en una estructura física ycon otra lógica por la cual se relacionan, siendo independiente de las aplicaciones.

Tan importante como los datos, es la estructura conceptual con la que se relacionanentre ellos. Un sistema de gestión de bases de datos (DBMS) consiste en unacolección de datos interrelacionados y un conjunto de programas para acceder a esosdatos. El objetivo primordial de un DBMS es proporcionar un entorno que sea a la vezconveniente y eficiente para ser utilizado al extraer y almacenar información de labases de datos. Toda base de datos es una colección de datos tendiente a minimizarla redundancia. Dicha colección de datos permite que los mismos se encuentren

1. Interrelacionados2. Almacenados en conjuntos3. Sin redundancias innecesarias o perjudiciales4. Independientes de los programas que los utilizan

Todo modelo de bases de datos debe gozar de las siguientes características:Independencia de datos

1. Regulación de acceso2. Protección de integridad3. Sin redundancia4. Facilidad de Ordenamiento



5. Manejo centralizado

Modelo Entidad Relación ( E-R )

El modelo entidad-relación se basa en una percepción de un mundo real queconsiste en un conjunto de objetos básicos llamados entidades y de relaciones entreestos objetos.

Está pensado como una notación orientada al diseño del esquema conceptual, puespermite la descripción del esquema conceptual sin preocuparse por problemas dediseño físico o de eficiencia.

Se supone que en una etapa posterior, los diagramas entidad-relación son llevados aotros modelos, ya sea manual o automáticamente. Dentro del modelo entidad relaciónse tienen:

ENTIDADES

Una entidad está representada por un conjunto de atributos. Para cada atributo existeun rango de valores permitidos, llamado dominio del atributo. Cualquier objetodistinguible que pueda representarse en la Base de Datos.

Conjunto de entidadesEs un grupo de entidades del mismo tipo. Por ejemplo: un conjunto de alumnos.



RELACIONES

Es una asociación entre (varias) entidades

Ejemplo: curso es-inscrito por alumno.

Conjunto de relacionesEs un grupo de relaciones de un mismo tipo.

DIAGRAMA ENTIDAD-RELACIÓN

La estructura lógica general de una base de datos puede expresarse en forma gráficapor medio de un diagrama entidad relación, que se integra con los siguientescomponentes:

Simbología utilizada en el Diagrama Entidad / Relación



El diagrama E/R se representa de dos formas, una para representar las entidades ysus relaciones llamada Diagrama o Modelo Entidad Relación y la otra, pararepresentar sus atributos, llamada Modelo Relacional:

Terminología De Bases De Datos

ENTIDAD

Es algo que puede ser identificado por si mismo (personas, lugares, cosas oconceptos) acerca de la cual se requiere guardar información. Un tipo de entidadrepresenta a una clase de entidades que tienen los mismos atributos.

RELACIÓN

Es una asociación entre entidades, o sea es la forma en que se asocian las entidades.

ATRIBUTO

Es la característica de una entidad

DATO

Son los valores que se le asignan a un atributo de una determinada entidad.



DOMINIO

Es un conjunto de valores que puede tomar un atributo en una relación.

TIPO DE RELACIONES

Relación uno a uno ( 1 : 1 )Una entidad en A esta asociada a lo sumo con una entidad B, y una entidad B estaasociada a lo sumo con una entidad A.

Relación uno a muchos ( 1 : M )Una entidad en A esta asociada con un numero cualquiera de entidades B. Unaentidad B, sin embargo, puede estar asociada a lo sumo con una entidad A.

Relación muchos a muchos ( M : M )Una entidad en A esta asociada con un numero cualquiera de entidades en B, y unaentidad en B esta asociada con un numero cualquiera de entidades en A.



Modelo De Datos

Concepto De Modelos De DatosEl principal proceso en el diseño de una base de datos es la creación de un modelo dedatos. Un modelo de datos es la representación en escala de la realidad. En estemodelo reflejaremos la estructura de negocio de la organización, por medio de datos yrelaciones.

MODELO CONCEPTUAL

El modelo conceptual deberá reflejar todas las relaciones lógicas y es totalmenteindependiente de su implementación física. Este es un modelo de entidad relación.

MODELO LÓGICO

Este modelo es el puente entre el modelo conceptual y el modelo físico; describe comose verán los datos. Existen en el diseño de bases de datos 3 modelos lógicos:

1. Jerárquico2. Red3. Relacional

MODELO FÍSICO

El modelo físico esta construido sobre las bases del modelo lógico y describe como losdatos son almacenados. Este es el nivel mas bajo de abstracción.

El Proceso de Normalización.Es la técnica utilizada para dividir las estructuras de datos en pequeñas unidades. Enestas unidades, cada atributo es totalmente dependiente de la clave primaria de laentidad a la cual pertenece.

La normalización nos permite:

• Minimizar la redundancia• Minimizar el impacto de futuros cambios de datos• Minimiza el mantenimiento de datos



Dependencia Funcional

Es la relación existente entre dos atributos, por lo que el conocimiento de uno de ellosdetermina el valor del otro. Si un elemento A es funcionalmente dependiente de otroelemento B, queda automáticamente definido A. El nombre de un buque esfuncionalmente dependiente de su numero de matricula, pero no es cierto que alconocer el nombre del buque se conozca su numero de matricula.

Dependencia Funcional Completa

Se produce la dependencia funcional completa cuando un atributo tiene dependenciafuncional de un conjunto de atributos, pero de ninguno de ellos en particular.

Dependencia Funcional Transitiva

Se produce la dependencia funcional transitiva cuando un atributo tiene dependenciade otro y este a su vez de un tercero. En este caso, el primero tendrá dependenciatransitiva al tercero. Si se tiene los elementos A, B, C, si A es funcionalmentedependiente de B, y B es funcionalmente dependiente de, entonces A estransitivamente dependiente de C.

PRIMERA FORMA NORMAL

Una entidad esta en primera forma normal si no existen grupos repetitivos.

SEGUNDA FORMA NORMAL

Una entidad esta en segunda forma normal, si esta en primera forma normal, y todoslos atributos que no integran la clave están en completa dependencia funcionalrespecto de la clave.

TERCERA FORMA NORMAL

Una entidad esta en tercera forma normal, si esta en segunda forma normal y noexisten atributos que no integren la clave que tengan dependencias funcionalesrespecto de otros atributos no claves veamos un ejemplo en base a bases de datos



Restricciones según las Reglas del Negocio.Toda empresa se basa en sus Reglas de Negocio, esto es, las reglas y/o forma enque esta se dirige, tanto sus empleados como aquellas otras personas que interactúancon ella, esto también se refleja en los documentos que utilizan.

Nosotros no podemos ir a tratar de inventar documentos, ni mucho menos crearnuevos procesos, nuestra tarea es interpretar la forma de trabajo de ellos en nuestrosistema, y algo que lo soporte, como sería la BD.

Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas,normas, operaciones, definiciones y restricciones presentes en una organización y queson de vital importancia para alcanzar los objetivos misionales.

Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año esun cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% enpedidos superiores a 3.000".

Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas otácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc.Pueden residir en la cabeza de algunas personas o en el código fuente de programasinformáticos.

En los últimos años se viene observando una tendencia a gestionar de formasistemática y centralizada las reglas de negocio, de modo que sea fácil y sencilloconsultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar unmotor de reglas de negocio. El motor de reglas de negocio es un sistema que seconfigura para dar servicio a las necesidades de negocio a través de la definición deobjetos y reglas de negocio, el software se rige por flujos que derivanresponsabilidades a los distintos cargos de la empresa repartiendo así el trabajoequitativamente y cuantitativamente, cuando, quien y donde tiene que desempeñar latarea asignada.

Las reglas de negocio son un medio por el cual la estrategia es implementada. Lasreglas especifican - en un nivel adecuado de detalle - lo que una organización debehacer.



CCAAPPIITTUULLOO 77

Del modelo de Datos a la Base de Datos. El proceso de Migración a la BD. Ingeniería Inversa. Desarrollo de Caso Práctico.



D E L M O D E L O D E D A T O S A L A B A S E D E

D A T O S .

Como se vio en el capitulo anterior, todavía tenemos la posibilidad de mejorar nuestromodelo de datos, generado a partir del modelo de objetos.

A continuación procederemos a crear nuestra base de datos, tomando como base, elmodelo de datos refinado.

El proceso de Migración a la BD.El proceso lo iniciaremos, visualizando el modelo de datos, interpretado por elRational, seguidamente, haremos clic derecho sobre el schema que contiene elmodelo de datos.



Seguidamente, se activará el asistente para la generación de la base de datos.

En esta pantalla, podremos seleccionar los tipos de elementos que conformaránnuestra base de datos, todos ellos pueden ser creados directamente desde elRational.



A continuación, especificaremos el lugar donde se guardará el script de la base dedatos, tener en cuenta que el archivo a generar, por defecto tendrá la extensión ddl,así que mejor le colocamos la extensión sql para identificarla rápidamente.



Finalmente, hacemos clic en el botón Finish, para que el modelo se complete.



Ingeniería Inversa.El proceso de ingeniería inversa consiste en transformar una base de datos o en sudefecto un script, a un modelo de objetos, para ello realizaremos el siguiente proceso:

1. abrir un proyecto nuevo y seleccionar Tools, luego Data Modeler,seguidamente Reverse Enginner…

2. seguidamente, se muestra el asistente.



3. seleccionar el tipo de origen de datos.

4. especificar el tipo de base de datos origen.



5. probar la conexión de datos.

6. seleccionar el schema que proporcionará los datos.



7. seleccione los tipos de elementos que serán recuperados desde la base dedatos.

8. la base de datos se esta transformando a un modelo de datos.



9. el proceso se a completado con éxito.

10. observemos como se a creado un schema que contiene los elementos de labase de datos migrada.



11. inmediatamente, crearemos un paquete en el Logical View, con el objetivo deque reciba los objetos desde el modelo de datos.

12. una vez creado, busquemos el schema.



13. hacer clic derecho, y del menú contextual, seleccionar Data Modeler, luegoTransform to Object Model.

14. de la ventana, seleccionar el paquete que recibirá las clases.



15. indicar algún tipo de prefijo para las clases, en este caso, no lo usaremos.Adicionalmente, dejemos activado el check Include Primary Keys.

16. completada la transformación, llevar el paquete a Welcome.



17. finalmente, procederemos a arrastrar las clases generadas a un ClassDiagram previamente creado.

Desarrollo de Caso Práctico.Aquí se proponen los siguientes casos, para que puedan ser comparados con losresultados que indique su profesor de curso.

1. Se trata de diseñar la base de datos para la administración de un consorcio dehospitales, que permita gestionar datos acerca del personal así como de lospacientes de los mismos. De cada hospital interesa almacenar además de sunombre dirección, teléfono, fax, etc.

• El personal de los hospitales (del que interesa almacenar su DNI,nombre, apellidos, dirección y teléfono) se divide en personaladministrativo y personal sanitario (dentro de este se distingue a suvez ATS y médicos).

• Los médicos tienen una especialidad que interesa conocer (pediatría,obstetricia, etc.) y sólo trabajan, al igual que el resto del personal, enun hospital.

• Los pacientes pueden acudir a varios hospitales del consorcio,pudiendo ser atendidos por varios médicos.

• Se desea conocer los datos personales de los pacientes que van aingresar en el hospital, así como el número de seguridad social,



compañía aseguradora, la fecha de admisión y la sala (habitación)en la que deben permanecer.

• Cada sala se identifica por un número de sala dentro de cada hospital yse desea conocer el número de camas de las que dispone cada sala.

• Cada admisión de un paciente en el hospital lleva asociada una ovarias fichas de tratamiento en las que se indica la enfermedad y elmédico que la atiende. Cada tratamiento se identifica por el nombre dela enfermedad del tratamiento que es único para cada admisión.

• Además, cada tratamiento da lugar a distintos resultados que permitenrealizar el seguimiento de cada enfermedad de un paciente. Elresultado debe indicar la fecha y hora en que éste tuvo lugar, así comoun comentario (por ejemplo, indicando si el paciente tiene fiebre etc.).Para un mismo tratamiento sólo puede haber un resultado en un mismodía, a una misma hora.

2. La empresa “X” desea llevar un control de sus departamentos, empleados yproyectos según las siguientes especificaciones:

• Se desea conocer el nombre, salario y número de la seguridadsocial de cada empleado, así como el nombre, fecha de nacimientoy estudios que cursa, de cada uno de sus hijos. Existen varios tipos deempleados: directores (encargados de un departamento),representantes de ventas (se ocupan de la representación en unnúmero de regiones) e ingenieros (encargados de realizar los proyectosde la empresa); hay, además, otros empleados, como secretarios,auxiliares de laboratorio, etc. Un director no puede ejercer ninguna otrafunción; sin embargo, un representante de ventas puede desempeñartambién las funciones de un ingeniero y viceversa.

• Los distintos departamentos concede becas de estudio a los hijos delos empleados. Estas becas no están tipificadas, sino que son ayudasque se conceden dependiendo del presupuesto del que disponga eldepartamento. Se desea conocer la fecha de concesión de cadabeca así como la cuantía de ésta. Un ingeniero puede tener variasespecialidades que se desean conocer. De los departamentos senecesita saber, el nombre, localización y empleados que trabajan enél. Un departamento tiene, como mínimo 2 empleados y como máximo30 y está al cargo de un único director. Cada departamento tiene undirector distinto.

• Un departamento puede controlar un número de proyectos, de losque se desea conocer su nombre y fecha de comienzo.

• En la realización de un proyecto no puede haber involucrados más de 5ingenieros. Todo ingeniero debe estar asociado a 1 proyecto comomínimo y a 2 como máximo. En el caso de que un departamento notenga ningún proyecto, sus empleados podrán estar trabajando enproyectos de otros departamentos.



CCAAPPIITTUULLOO 88

Publicando una Web de Documentación. Examen Final.



P U B L I C A N D O U N A W E B D E D O C U M E N T A C I Ó N .

Desde el Rational Rose, tenemos la posibilidad de poder publica en el internet, unaweb con todo nuestro proyecto, de tal manera que podamos compartir con todos losintegrantes del equipo de desarrollo, todos los diagramas que conforman nuestroproyecto.

Para ello, debemos de seguir los siguientes pasos:

1. Ir a la barra de menú y seleccionar Tools, luego Web Publisher.

2. de la ventana que se muestra, especificar la ruta y nombre del archivo de iniciode la web.



3. podemos escoger el tipo de formato que van a tener las imágenes, para ello,hacer clic en el botón Diagrams.

4. una vez realizados todos los cambios, hacer clic sobre el botón Publish, paraque se inicie el proceso de publicación, una vez terminado, ir a la carpeta/rutaespecificada y ejecutar el archivo de inicio, luego puede ser enviado al Interneto el sitio web especificado.

NOTA: Una vez completado el proceso de generación del web, nos ubicamos en lacarpeta donde se guardo el archivo de inicio HTML, el cual se recomienda, tenga elsiguiente nombre: Index.html. Hacemos doble clic sobre el archivo, e inmediatamentese abrirá una ventana con el Browser que tenga instalado en su equipo (InternetExplorer, Netscape Navigator, Mozilla, Chrome, FireFox, etc.)



5. Seguidamente, seleccionamos el cuadro de navegación, desde dondepodremos seleccionar el grafico que deseamos ver, haciendo doble clic sobreel mismo.



6. Luego, nos ubicamos sobre el paquete que deseamos ver, haciendo un clicsobre él, tan igual como si fuera un hipervínculo.

7. Adicionalmente, se puede ver información detallada sobre cada uno de losobjetos que se muestran en el diagrama.



8. Lo mismo ocurre para los paquetes que se tienen.



Í N D I C E

Capitulo 1.................................................................................................................... 1Introducción al Análisis y Diseño Orientado a Objetos. ...................................... 2

El Desarrollo de la Estructura del Pensamiento y la Construcción delConocimiento ........................................................................................................ 2

La clasificación es un medio por el cual organizamos el conocimiento. ............. 4Simulación. .................................................................................................... 4Encapsulamiento............................................................................................ 5Reutilizacion................................................................................................... 5

Conceptos Básicos ............................................................................................ 6Encapsulamiento de objetos .......................................................................... 6

Ciclo de Vida del Software. ................................................................................... 9Sobre los sistemas ...........................................................................................10Ciclo de Desarrollo ...........................................................................................11

Proceso de desarrollo utilizando UML. .................................................................11Descripción del Proceso Actual: El Modelo de Negocios......................................13

Conceptos Fundamentales para Modelar Negocios..........................................13Estereotipos ..................................................................................................14

Creación del Modelo en Rational Rose.............................................................15

Capitulo 2...................................................................................................................19Del Modelo de Negocios al Modelo del Sistema..................................................20

Funcionalidad del Sistema: Use Case Diagram....................................................20Actor .............................................................................................................21Caso de uso..................................................................................................21

Tipos de asociación entre CU’s. ...........................................................................22Comunicación...................................................................................................23Generalización..................................................................................................24Inclusión ...........................................................................................................24Extensión..........................................................................................................25Como identificar un Actor..................................................................................25Como identificar un Caso de Uso .....................................................................26Ventajas de los Casos de Uso..........................................................................26

Documentando los CU’s.......................................................................................27Creación del Modelo en Rational Rose.............................................................28

Capitulo 3...................................................................................................................31Capturando el Modelo de Objetos. .......................................................................32

Uso de: Objetos, Clases, Encapsulamiento, Herencia, Polimorfismo. ..................32Clase ................................................................................................................32Atributos ...........................................................................................................32Operaciones .....................................................................................................33Notas Adjuntas .................................................................................................34

Diagramas de Clases. ..........................................................................................35Tipos de Asociación entre Clases ........................................................................36

Asociación (Binaria)..........................................................................................36Clases de Asociación (Atributos de Enlace)......................................................37Asociaciones Reflexivas ...................................................................................38Herencia Y Generalización ...............................................................................38Agregación / Composición ................................................................................39



Creación del Modelo en Rational Rose............................................................ 39

Capitulo 4.................................................................................................................. 43Definiendo la Lógica del Sistema. ....................................................................... 44

Utilizando el Diagrama de Actividad. ................................................................... 44Decisiones ....................................................................................................... 45Rutas Concurrentes......................................................................................... 45

Definiendo Escenarios (Calles). .......................................................................... 46resumen....................................................................................................... 47

Diagramas de Interacción: Secuencia y Colaboración......................................... 47Diagrama de Secuencia................................................................................... 48

objetos ......................................................................................................... 48mensaje ....................................................................................................... 48tiempo .......................................................................................................... 49la secuencia ................................................................................................. 49

Creación del Modelo en Rational Rose............................................................ 50

Capitulo 5.................................................................................................................. 55El comportamiento de los objetos....................................................................... 56

Uso del Diagrama de Estados. ........................................................................... 56SIMBOLOGÍA .................................................................................................. 57SUCESOS Y ACCIONES ................................................................................ 57CONDICIONES DE SEGURIDAD.................................................................... 58¿Por qué son Importantes los Diagramas de Estados? ................................... 58

Diagrama de Componentes................................................................................. 59Tipos de componentes ................................................................................. 59

Diagrama de Despliegue. .................................................................................... 61

Capitulo 6.................................................................................................................. 63Del Modelo de Objetos al Modelo de Datos. ....................................................... 64

Refinando el Modelo de Datos. ........................................................................... 65Definición de Base de Datos............................................................................ 67Modelo Entidad Relación ( E-R )...................................................................... 68

entidades ..................................................................................................... 68relaciones..................................................................................................... 69diagrama entidad-relación............................................................................ 69

Terminología De Bases De Datos.................................................................... 70entidad ......................................................................................................... 70relación ........................................................................................................ 70atributo......................................................................................................... 70dato.............................................................................................................. 70Dominio........................................................................................................ 71tipo de relaciones ......................................................................................... 71

Modelo De Datos ............................................................................................. 73Modelo Conceptual ...................................................................................... 73Modelo Lógico.............................................................................................. 73Modelo Físico............................................................................................... 73

El Proceso de Normalización. ............................................................................. 73Dependencia Funcional ................................................................................... 74Dependencia Funcional Completa ................................................................... 74Dependencia Funcional Transitiva ................................................................... 74

Primera Forma Normal................................................................................. 74Segunda Forma Normal ............................................................................... 74



Tercera Forma Normal ..................................................................................74Restricciones según las Reglas del Negocio. .......................................................78

Capitulo 7...................................................................................................................79Del modelo de Datos a la Base de Datos. ............................................................80

El proceso de Migración a la BD. .........................................................................80Ingeniería Inversa. ...............................................................................................84Desarrollo de Caso Práctico.................................................................................92

Capitulo 8...................................................................................................................95Publicando una Web de Documentación. ............................................................96

manual uml actualizado 2009

Documents